13 款本地大模型长上下文实测：prefill 才是关键

一位长期在本地运行大模型做 agentic 工具调用的用户，对 13 款 5GB–18GB 的开源模型（5 款 dense、6 款 MoE、1 款 Mamba2 混合、1 款 MLA MoE）在 65K–131K 上下文下做了完整基准测试，跑满约 21 小时后得出若干反直觉结论。测试平台为 RX 7900 XT 20GB（Vulkan / llama.cpp），覆盖 512、4K、16K、65K、131K 五档上下文，以及 Q8K/Q4V、Q8K/Q8V、F16 三种 KV cache 量化方案，分别记录纯 prefill（pp）与 prompt+gen（pg）耗时。

prefill 占 94–99%，decode 几乎可忽略

在典型 agentic 场景（65K 上下文输入、300 token 输出）下，多款模型的 prefill 阶段占总等待时间的 94%–97%。以 Trinity-Mini（MoE 3B/26B）为例：prefill 46.2s、decode 仅 2.0s；Qwen3.6-35B-A3B 为 51.7s vs 2.7s；Devstral-24B 为 209.5s vs 7.2s。这意味着对于短输出工具调用，tg128（每秒生成 token 数）作为头条指标具有误导性，真正决定体验的是 pp65K / pp131K 这类纯 prefill 指标。

KV 头数比参数量更关键

在 128K 上下文下，相同 dense 类别中 9B 的 Ornith-9B（4 个 KV 头 × 128 维，每 token KV 64 KB）比 15B 的 Apriel-1.6-15B（8 个 KV 头 × 128 维，160 KB/token）快约 4.4 倍。原因在于每次注意力计算都要扫描全部 KV cache：KV 头数翻倍意味着每 token 多扫描 2.5 倍数据。实测的 prefill 速度衰减（以 pp4K 为基准）也印证了这一点——4 KV 头的模型在 131K 时仍保留 32%–42% 速度，8 KV 头模型多数跌至 14%–23%。结论是：评估长上下文模型时，应优先看 n_kv_heads 与 head_dim，而非参数总量。

Mamba2 混合架构：长上下文近乎线性

IBM 的 Granite-4.0-H-Small（4 层 attention + 36 层 Mamba2）从 4K 到 131K 仅衰减 1.45 倍（1271 → 875 t/s），而所有 Transformer 模型衰减均超过 2.5 倍，dense 8KV 模型甚至达 7.4 倍。原因在于 Mamba2 使用固定大小的循环状态而非增长式 KV cache，仅 4 层 attention 贡献 KV 增长。不过该架构 decode 较慢（71 t/s），且推理质量有限，更适合「大上下文、短输出」这类典型 agentic 工具调用模式。

F16 KV 反而比 Q8/Q4 更快：dequantization 悖论

传统观点认为应量化 KV cache 以减小带宽，但实测显示在 65K 上下文下：

MoE 模型：F16 比 Q8K/Q8V 快 11%–53%（Gemma-4-26B-A4B 从 1015 提升到 1554 t/s）；
小型 dense 模型：F16 快 21%–44%；
8 KV 头的密集模型：F16 慢 18%–66%（Apriel-1.6-15B 从 351 跌至 120 t/s）。

背后机制是 Q8/Q4 KV 需要逐 token 反量化，计算成本随上下文线性增长，在 65K 时超过带宽节省；而 F16 无反量化开销。MoE 模型因只有活跃参数（约 3B/35B）跨 PCIe，GTT spill 惩罚小；8KV 密集模型则承受「更大 cache + 全权重 spill」双重惩罚。

选型建议

长上下文 agentic 负载：优先关注 pp65K / pp131K，而非 tg128；
同族模型对比：先看 n_kv_heads，4 vs 8 头在 128K 下可差 3–4 倍；
KV cache 量化：MoE 与小 dense 用 F16；8KV 头且 >10GB 的 dense 用 Q8K/Q8V。