# 为什么 llama.cpp 跑混合线性架构会慢 20 倍？我把它的源码翻了一遍

> 项目地址：https://github.com/SunnyClaw-cx/SunnyNet （Apache-2.0）
> llama.cpp 源码取自 master 分支的稀疏克隆，涉及文件：`src/models/delta-net-base.cpp`、`src/models/qwen3next.cpp`、`src/llama-context.cpp`、`ggml/src/ggml-cpu/ops.cpp`、`ggml/src/ggml-cpu/ggml-cpu.c`、`ggml/src/ggml-cpu/ggml-cpu.cpp`、`ggml/src/ggml-cpu/vec.cpp`、`ggml/src/ggml-cpu/vec.h`。
> SunnyNet 的数字来自本机实测，原始 JSON 在仓库 `experiments/results/`，报告在 `docs/EXPERIMENT_REPORT.md`。
> 测试机：i7-8750H（Coffee Lake，6C12T，AVX2，无 AVX-512 / 无 VNNI / 无 AMX）。
> 标题里的「20 倍」是两个可查乘数的量级叠加，不是一次实验直接测出的单一倍数——下面第一段把这个数字拆开讲清楚。

---

## 先说这个「20 倍」是哪来的

Qwen3-Next 这一类模型是混合线性架构。llama.cpp 里逐层判定走哪条注意力：

```cpp
// qwen3next.cpp:163
if (hparams.is_recr(il)) {
    // Linear attention layer (gated delta net)
    cur = build_layer_attn_linear(inp->get_recr(), cur, il);
} else {
    // Full attention layer
    cur = build_layer_attn(inp->get_attn(), cur, inp_pos, il);
}
```

线性层和全注意力层交错，中间隔着若干层。Gated DeltaNet 的状态是一个矩阵，不是向量，每步递推都要在它上面做一次读写。这个设计在 GPU 上问题不大，一旦有任意一层落回 CPU，代价会以乘数形式叠加。

两个可查的乘数：

**乘数一，卸载惩罚。** 一份 RTX 5060 Ti 16GB 上的 Qwen3.8 27B 实测记录里，同一个量化文件、同一个 prompt 生成 600 token，`-ngl 99` 全卸载跑 39.9 tok/s，`-ngl 58` 部分卸载跑 13.0 tok/s，掉幅接近 70%，也就是 3 倍。

**乘数二，CPU 侧的 GDN 实现本身。** 落到 CPU 之后，这个算子在 llama.cpp 里没有架构特化——同类算子 GLA 有 AVX2 / AVX-512 / SVE / NEON 的手写分支，GDN 一个都没有，`ggml/src/ggml-cpu/arch/` 下搜不到一处实现。一个每 token 要完整遍历矩阵四遍的递推，底层压在标量三重循环上。作为量级参照：SunnyNet 那个处理同类递推的 C 内核对向量化基线是 9.90× 中位、最高 19.29×。

两个乘数分属不同口径，不能直接相乘得到一个精确倍数——「20 倍」是把它们放在同一个量级上说事。真正能确认的是两点：CPU 卸载本身就有 3 倍量级的代价，而 CPU 侧那条 GDN 路径完全没有做过架构特化。

还有一个更隐蔽的现场：llama.cpp 在 `GGML_USE_MUSA` 下曾经直接禁用了 `GGML_OP_GATED_DELTA_NET`，后果是 hybrid 模型每 4 层有 3 层跑在 CPU 上，`-ngl 999` 却照常报成功。补丁作者记录的 Qwen3.5-27B IQ4_XS 数据是 pp512 从 2.09 提到 59.72 t/s，tg64 从 0.86 提到 3.11 t/s。GPU 使用率 0–7%，CPU 被 llama-bench 顶到 700%。

这不算配置错误，是架构层面的结构性问题。

---

## 翻源码：三条路径，一层失守全盘失守

GDN 在 llama.cpp 里的图构建在 `src/models/delta-net-base.cpp`。`build_delta_net()` 做路径选择：

```cpp
// delta-net-base.cpp:422
if (n_seq_tokens == 1) {
    if (cparams.fused_gdn_ar) return build_delta_net_fused(...);
    return build_delta_net_autoregressive(...);
}
if (cparams.fused_gdn_ch) return build_delta_net_fused(...);
return build_delta_net_chunking(...);
```

三条路径的算子数量差距很大。数一遍 `ggml_*()` 调用：

| 路径 | 总算子数 | chunk 循环体内 | 适用场景 |
|---|---|---|---|
| `build_delta_net_fused` | 10 | — | 融合算子可用 |
| `build_delta_net_autoregressive` | 16 | — | 解码（T=1） |
| `build_delta_net_chunking` | 99 | 9 | prefill 回退 |

prefill 走 chunking 时，99 个算子调用里有 9 个在 chunk 循环体内反复执行：4 个 `mul_mat`、2 个 `add`、1 个 `sub`、1 个 `set_inplace`、1 个 `mul`。9 个独立的 kernel launch，每个都要走一遍调度、访存边界检查、线程池唤醒。

真正决定快慢的是这条：

```cpp
// llama-context.cpp:609 resolve_fused_ops()
ggml_backend_t backend_fused = ggml_backend_sched_get_tensor_backend(sched.get(), node.tensor);
ggml_backend_dev_t device_fused = backend_fused ? ggml_backend_get_device(backend_fused) : nullptr;
ggml_backend_dev_t device_layer = model.dev_layer(node.il);

if (device_fused != device_layer) {
    LLAMA_LOG_WARN("%s: layer %d is assigned to device %s but %s is assigned to device %s "
            "(usually due to missing support)\n", ...);
    device_mismatch = true;
    break;
}
...
if (device_mismatch) { enabled = false; ... }
```

逐层比对融合算子所在的设备和该层所在的设备。**只要有一层对不上，整个 `fused_gdn_ch` / `fused_gdn_ar` 就被置为 false**，全体回退到 chunking。日志里只留一行 WARN。

探针本身也是按 token 数硬编码的：

```cpp
// llama-context.cpp:131
static const llm_fused_op_probe llm_fused_op_gdn_ar_probe = {
    LLM_FUSED_OP_GDN_AR, "fused Gated Delta Net (autoregressive)", /*.n_tokens_per_seq =*/ 1 };
static const llm_fused_op_probe llm_fused_op_gdn_ch_probe = {
    LLM_FUSED_OP_GDN_CH, "fused Gated Delta Net (chunked)",        /*.n_tokens_per_seq =*/ 16 };
```

llama.cpp 的 PR #26177 修过一个直接相关的 bug：用 `--fit` 加载 MTP GGUF 时，NextN/MTP 块没被计入 `ngpulayers`，导致少卸载一层、layer 0 留在 CPU，顺带把整个融合 GDN GPU kernel 关掉了。修复后 Qwen3.6-35B-A3B 的 token 生成快了 10%。一个层的计数错误就能让整条融合路径失效，机制就是上面那段 `break`。

---

## CPU 后端里的 GDN：一个矩阵，四遍遍历

CPU 侧的实现全在 `ggml/src/ggml-cpu/ops.cpp:11214` 的 `ggml_compute_forward_gated_delta_net_one_chunk()`。

状态在 `src_state` 里是 `[S_v, S_v, H, n_seqs]`，每个 head 一个 S_v × S_v 的矩阵。注释写明了它转置存储，为的是让行连续访问：

```cpp
// state is stored transposed: s_out[j*S_v + i] = S[i][j]
// so row j of s_out = column j of S (contiguous access)
```

每个 token 的四步：

```cpp
// 1. 衰减：整个 S_v×S_v 矩阵逐元素乘
for (int64_t j = 0; j < S_v; ++j)
    ggml_vec_mul_f32(S_v, &s_out[j * S_v], &s_out[j * S_v], delta);

// 2. delta：S_v 次向量点积
for (int64_t j = 0; j < S_v; ++j) {
    float sum = 0.0f;
    ggml_vec_dot_f32(S_v, &sum, 0, &s_out[j * S_v], 0, k_d, 0, 1);
    delta[j] = (v_d[j] - sum) * beta_val;
}

// 3. 外积更新：S_v 次向量乘加
for (int64_t j = 0; j < S_v; ++j)
    ggml_vec_mad_f32(S_v, &s_out[j * S_v], k_d, delta[j]);

// 4. 读出：S_v 次向量点积
for (int64_t j = 0; j < S_v; ++j) {
    float sum = 0.0f;
    ggml_vec_dot_f32(S_v, &sum, 0, &s_out[j * S_v], 0, q_d, 0, 1);
    attn_data[j] = sum * scale;
}
```

四个循环，每个都完整扫一遍那个 S_v × S_v 的矩阵。一个 head 的状态是 S_v² 个 float；S_v = 128 时是 64 KB，每 token 每 head 过四遍，就是 256 KB 的读写。而 `ggml_vec_dot_f32` 那两处传的 `nrc = 1`，每次只处理一行，`k_d` 在循环里被反复重新加载。

状态的实际尺寸由模型 hparams 决定，代码里有两种取法：

```cpp
// qwen3next.cpp:57   建张量时按 state size 取
const int64_t head_v_dim = hparams.ssm_d_state;

// qwen3next.cpp:403  实际 reshape 时按 inner size 除 head 数
const int64_t head_v_dim = d_inner / num_v_heads;
...
// qwen3next.cpp:462
state = ggml_reshape_4d(ctx0, state, head_v_dim, head_v_dim, num_v_heads, n_seqs);
```

最终状态占 `head_v_dim × head_v_dim × num_v_heads` 个 float。层数乘以 head 数，就是这个矩阵每 token 要搬运的总量——这个量不随上下文长度增长，但每步都要完整过一遍。

最关键的缺口在这里：`ggml/src/ggml-cpu/arch/` 下没有任何 GDN 的实现。

```
$ grep -rn "gated_delta_net" ggml/src/ggml-cpu/arch/
（无输出）
```

而同一个 `ops.cpp` 里，GLA 的手写分支是这样的：

```cpp
// ops.cpp:10981, 位于 ggml_compute_forward_gla_f32() 内
#if defined(__AVX__) && !defined(__AVX512F__)
    #define GGML_F32X GGML_F32x8
    ...
    #define GLA_VECTOR_SIZE 8
#elif defined(__AVX512F__)
    #define GGML_F32X GGML_F32x16
    ...
    #define GLA_VECTOR_SIZE 16
#elif defined(__ARM_FEATURE_SVE) && defined(__aarch64__)
    ...
#elif defined(__ARM_NEON) && defined(__aarch64__)
    ...
```

GLA 有 8-lane AVX2、16-lane AVX-512、SVE、NEON 四套特化，GDN 没有。GDN 调用的是 `ggml_vec_dot_f32` / `ggml_vec_mad_f32` / `ggml_vec_mul_f32` 这几个通用原语。`vec.cpp:11` 里 `ggml_vec_dot_f32` 是按 `GGML_SIMD` 宏切多个架构分支的向量化实现，最内层确实吃到了 SIMD；但外层那个逐行循环、状态矩阵的四遍遍历、`nrc=1` 的调用粒度，都是标量逻辑——每行单独调一次，每次都重新加载 `k_d`。SIMD 只在最内层那 128 个 float 上生效，出不了这一层。

prefill 路径依赖的两个算子也是同理：

```cpp
// vec.h:1646
inline static void ggml_vec_cumsum_f32(const int n, float * y, const float * x) {
    for (int i = 0; i < n; ++i) {
        if (i == 0) y[i] = x[i];
        else y[i] = y[i - 1] + x[i];   // 串行依赖，SIMD 无从下手
    }
}
```

```cpp
// ops.cpp:11188 ggml_compute_forward_solve_tri_f32()
for (int64_t i00 = 0; i00 < n; ++i00) {
    float sum = 0.0f;
    for (int64_t t = 0; t < i00; ++t) sum += A_batch[i00 * n + t] * X_batch[t * k + i01];
    X_batch[i00 * k + i01] = (B_batch[i00 * k + i01] - sum) / diag;
}
```

chunked 路径要靠 cumsum 和三角求解把递推拆成块并行，而这两个都是纯标量三重循环。chunk 循环体里那 9 个算子，底层就压在这上面。

线程切分同样受限：

```cpp
// ops.cpp:11372
int64_t nr = V->ne[1] * V->ne[3];   // = H × n_seqs
int nth_scaled = nth * 4;
int64_t chunk_size = (nr + nth_scaled - 1) / nth_scaled;
```

并行单元是 (head, seq)。每层的 value head 数有限，一层切不出多少任务；T 维度因为递推依赖，天然串行。`ggml-cpu.c:2291` 里 GDN 的 `n_tasks = n_threads`，工作区按 `per_thread = S_v + (K > 1 ? S_v * S_v : 0)` 每线程分配——解码路径 K=1，每线程只要 S_v 个 float 的 scratch，状态本体在主存里被反复读写。

还有一件事要确认：CPU 后端**是支持** GDN 的。

```cpp
// ggml-cpu.cpp:424 ggml_backend_cpu_device_supports_op()
switch (op->op) {
    ...
    case GGML_OP_SSM_SCAN: return ggml_get_op_params_i32(op, 0) == 1 || op->src[3]->ne[0] == 1;
    default: return true;    // GDN 走这里
}
```

GDN 没有被任何显式分支拦下，走 `default: return true`。所以慢的原因不是「不支持」，而是「支持，但实现是按最朴素的矩阵递推写的」。

---

## SunnyNet 的做法：状态是向量，热路径只碰两个向量

SunnyNet 的核心递推式是一对凸组合：

```
s_t = p_t ⊙ s_{t-1} + (1 - p_t) ⊙ u_t ,   p_t ∈ [1-δ_i, 1]
```

两个系数非负且和为 1，所以 `|s_t| ≤ max(|s_{t-1}|, |u_t|)`——状态幅度由构造保证有界。每个通道的保留下限绑定一个记忆跨度 `H_i`，在 `[2, 8192]` 上按对数铺开，一层就能覆盖从两个 token 到八千个 token 的时间尺度。

这个式子的 C 实现 `sunnynet/runtime/recur.c` 是这样：

```c
// recur.c:24
for (; d + 8 <= N; d += 8) {
    __m256 s = _mm256_loadu_ps(s0b + d);
    for (int t = 0; t < T; ++t) {
        const size_t off = (size_t)t * N + d;
        __m256 av = _mm256_loadu_ps(ab + off);
        __m256 bv = _mm256_loadu_ps(bbb + off);
        if (gated) bv = _mm256_mul_ps(_mm256_sub_ps(one, av), bv);
        s = _mm256_fmadd_ps(av, s, bv);
        _mm256_storeu_ps(ob + off, s);
    }
    _mm256_storeu_ps(seb + d, s);
}
```

对照着看，差别在结构而不在指令：

| | llama.cpp GDN | SunnyNet recur |
|---|---|---|
| 状态形状 | S_v × S_v 矩阵（每 head） | d 维向量 |
| 每 token 遍历 | 4 遍矩阵 | 1 遍，读 a / b 两个向量 |
| T 循环内 | 矩阵逐元素 + 点积 + 外积 | 一条 `vfmadd` |
| 门控融合 | 分布在 4 个循环里的 mul / sub | `(1-a)*b` 在向量寄存器内一次算完 |
| 架构特化 | 无 | AVX2 手写，沿 N 向量化 |

向量化维度选在 N（通道）上而不是 T（时间）上。T 有递推依赖，本来就串行；N 维度完全独立，8 个通道一条指令。闸门 `(1 - a_t) ⊙ u_t` 也不单独物化——它被折进 FMA 的加数项里，省掉一次全量读写。

`recur.h` 里把这个内核的适用范围写清楚了：

```c
/*   s_t = a_t * s_{t-1} + b_t            逐通道独立
 *   gated 模式 b_t = (1 - a_t) * u_t     (u 由调用方给定, 不物化 b) */
```

RWKV 的 wkv、Mamba/S6 与 H3 的对角 SSM、S4、线性注意力的 KV 累加、以及 SunnyNet 自己的滚动状态，全部归约到这两种形式之一。Gated DeltaNet 不在其中——它的状态是矩阵，带一个 rank-1 移除项，不是逐通道递推。

---

## 实测：这个内核对向量化基线快多少

`experiments/_runtime_bench.py`，每格独立子进程、单线程、B=1、10 次取中位。基线是 torch 的向量化分块扫描（`ops.gated_scan`，cumsum 闭式解），不是 Python 循环：

| T | N | 模式 | 向量化 ms | 内核 ms | 倍数 |
|---|---|---|---|---|---|
| 256 | 128 | FMA | 0.391 | 0.043 | 9.08× |
| 1024 | 128 | FMA | 1.256 | 0.132 | 9.54× |
| 4096 | 128 | GATED | 8.500 | 0.806 | 10.55× |
| 4096 | 640 | FMA | 26.944 | 7.574 | 3.56× |

中位 9.90×，范围 3.56–19.29×。N=640 掉到 3.6–4.0×，是单线程撞上内存带宽。

数值方面，内核三分支与 torch 各架构的 PyTorch 递推逐元素比对（B=2 / T=128 / N=128 / fp32），max|diff| 落在 1.2e-07 到 1.9e-06 之间：

| 架构递推形式 | 映射 | max\|diff\| |
|---|---|---|
| RWKV-4 wkv | `a=p`, `b=k*v` | 9.5e-07 |
| Mamba / S6 SSM | `a=decay`, `u=bu` | 2.4e-07 |
| H3 对角 SSM | `a=decay`, `u=v` | 1.2e-07 |
| 线性注意力累积 KV | `a=1`, `b=k v^T` | 0.0 |
| SunnyNet 滚动状态 | `a=p`, `u=u` | 1.9e-06 |
| S4 对角 SSM | `a=A_bar`, `b=B_bar x` | 7.2e-07 |

整模型单步解码也进了 C。`runtime/sunnynet.c`，B=1 单线程，prefill T=256/1024/2048 对 torch 是 1.53× / 2.05× / 1.97×，3 轮 C 全胜。

v0.2.0 做了一次访存重构：权重在 `sn_load` 时翻成行主序 `(out,in)`，GEMV 按输出通道并行、每行连续读。`p100mw`（105.36M）单步解码 76.60 → 25.72 ms/token（2.98×），有效带宽 6.10 → 18.18 GB/s。并行度取物理核而非逻辑核——访存受限的活儿超线程帮倒忙：6 核 26.69 ms，12 逻辑核 36.05 ms。

fp16 路径把 5 个 GEMV 矩阵和 LM head 在载入时截断到 fp16，单步实读从 467.6 MB 降到约 222.3 MB；`gemv_h` 一次读 16 个 half（32 B）再转 fp32 做 FMA，保持相同的加载宽度。`p100mw` 单步 24.67 → 18.60 ms/token（1.33×，11 轮交错 11/11 占优），logits max|diff| 4.181e-03、argmax 64/64。

这三个数字能对照到前面那个乘数二：**llama.cpp 的 GDN 在 CPU 上没有架构特化，而一个同样处理递推、把门控折进 FMA、沿通道维向量化的手写内核，对向量化基线是 9.90× 的中位差距。**

---

## 这条路的边界在哪

上面那些数字有三个前提，不写清楚会被误读。

**第一，Gated DeltaNet 的递推跑不进这个 C 内核。** 状态是矩阵，更新式 `S_t = S_{t-1} + k_t ⊗ δ_t` 是外积累加，`SN_FMA` / `SN_GATED` 的逐通道形式表达不了。SunnyNet 里有一条 numpy 参考路径 `runtime/deltanet.py` 实现了它（真 rank-1 校正，`S ← S + k ⊗ δ`），接的是 `fla-org` 的 DeltaNet 340M 官方权重，秩 1 形式与显式 `(I − β k kᵀ) S + β k vᵀ` 写法的独立实现 max|diff| 4.578e-05，分段续算逐位 0.0，贪心输出连贯——但那是 91.46 ms/token 的参考实现，不是速度结果。矩阵值递推是本 Runtime 目前唯一尚未 C 化的层级，要补的是一个 rank-1 递推内核。Mamba-2 和 GLA 因为衰减外积可分解，不需要这一层。

**第二，SunnyNet 在 O(N) 阵营里不是最快的。** 解码这条线上 RWKV 在每一个测过的长度都快 1.9–2.6×。前向在 T=4096 对参数对齐的 Transformer 是 22.7×，但按逐格排名它是**随 T 改善的追赶者而非常胜者**：T=256 第 6、T=512 第 5、T=1024 第 5、T=2048 第 4、T=4096 第 3，全程未登顶，hyena 在所有长度都更快（0.40–0.52×）。训练步上与 RWKV 统计上打平（9 轮配对，中位比 1.042），比 H3 / Mamba / Hyena / 线性注意力快 16–41%。短序列是结构性弱项，拐点在 T≈384，原因就是算子数量。

**第三，量化在本机是反向优化。** AVX2 没有原生 FP16/BF16 运算，Coffee Lake 没有 VNNI，torch 走模拟回退：fp16 matmul 0.593 GFLOPS 对 fp32 的 295.8，慢约 477×；INT8 1.443 GFLOPS，慢约 205×。数值上也不成立——扫描累积的 fp32 相对误差 4.7e-07（T=2048 仍为 4.5e-07），bf16 则到 2.75%。

---

## 收束

llama.cpp 的 GDN 实现本身没什么可挑剔的——状态转置存储换行连续访问、K>1 时给多快照预分配 slot、NUMA 下自动关掉 chunking，这些细节都在。问题在于它是一段通用回退实现：没有架构特化，热路径上是矩阵的四遍遍历，而融合快路径被一个逐层设备比对开关统一控制，一层失守就全体降级。

混合线性架构的算力优势在长上下文，代价在状态是矩阵、每步都要碰。这个代价在 GPU 上被带宽吃掉，在 CPU 上被放大到另一个量级。

SunnyNet 选的是另一条路：把状态压成向量，让热路径只剩一条 FMA，把门控折进指令里，把 SIMD 铺在通道维上。这条路走不到 Gated DeltaNet 那种矩阵状态上，但在它够得着的范围内，一个手写的递推内核能拿出来的是 9.90× 的中位差距和 3.56–19.29× 的区间。

项目开源在 https://github.com/SunnyClaw-cx/SunnyNet ，Apache-2.0。全部数字、包括负结果，都在 `docs/EXPERIMENT_REPORT.md` 和 `experiments/results/*.json` 里。

为什么 llama.cpp 跑混合线性架构会慢 20 倍？我把它的源码翻了一遍 项目地址：https://github.com/SunnyClaw-cx/SunnyNet （Apache-2.0） llama.cpp 源码取自 master 分支的稀疏克隆，涉及文件：src/models/delta-net-base.cpp、src/models/qwen3next.cpp、src/llama-c

《为什么 llama.cpp 跑混合线性架构会慢 20 倍？我把它的源码翻了一遍》

编程语言

llama.cpp运行混合线性架构（如Qwen3-Next）慢20倍源于双重瓶颈：CPU卸载损失约3倍性能，及Gated DeltaNet算子缺少AVX2等架构特化，导致矩阵递推在标量循环中执行。设备不匹配时融合路径整体降级为chunking模式，加剧开销。SunnyNet通过向量化状态与FMA热路径实现9.9倍中位加速，验证了优化潜力。

GitHub

Kernel

JSON

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

llama.cpp运行混合线性架构（如Qwen3-Next）慢20倍源于双重瓶颈：CPU卸载损失约3倍性能，及Gated DeltaNet算子缺少AVX2等架构特化，导致矩阵递推在标量循环中执行。设备不匹配时融合路径整体降级为chunking模式，加剧开销。SunnyNet通过向量化状态与FMA热路径实现9.9倍中位加...

《为什么 llama.cpp 跑混合线性架构会慢 20 倍？我把它的源码翻了一遍》-腾讯云开发者社区-腾讯云

《为什么 llama.cpp 跑混合线性架构会慢 20 倍？我把它的源码翻了一遍》

《为什么 llama.cpp 跑混合线性架构会慢 20 倍？我把它的源码翻了一遍》

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐