本地大模型速度实测：llmspeed 硬件数据解读

本地跑大模型到底能有多快？这是每个想把手头硬件变成私人 AI 工作站的人最先关心的问题。llmspeed 做了一件很实在的事：为 30 台机器、15 个模型估算每秒 token 数（tokens per second），把「我的显卡能跑多快」从玄学变成可查的参考值。这篇文章拆解它的数字到底意味着什么、背后的内存带宽规律，以及为什么 prefill 阶段对编码智能体格外重要。

llmspeed 在测什么：30 台机器 × 15 个模型的速查表

llmspeed 的核心产出是一张「硬件 × 模型」的速度矩阵。横向是模型，纵向是机器，交叉点是每秒生成的 token 数。这种组织方式的价值在于，它回答的不是「某个模型跑分多少」，而是「同一模型换硬件差多少」「同一硬件换模型差多少」。

对普通用户来说，这解决了一个高频决策问题：升级内存、换显卡、还是换更小的量化版本，哪种投入回报最高。对开发者来说，这张表是估算用户体验的起点——一个 5 tokens/s 的本地模型和一个 40 tokens/s 的本地模型，在产品形态上完全是两回事。

需要清醒的是，这类数字天然是估算。量化方式、上下文长度、batch size、推理框架（llama.cpp、vLLM、MLX 等）都会让实测值上下浮动。llmspeed 给出的量级参考意义大于精确复现值。

内存带宽：决定解码速度的隐形天花板

llmspeed 数据背后最重要的规律是：自回归解码阶段的速度主要由内存带宽决定，而不是算力。

原因是机制性的。生成每个 token 都要把模型权重（或当前激活的部分）从显存/内存读一遍，计算量相对访存量很小。所以解码速度大致等于「内存带宽 ÷ 每 token 需要读取的字节数」。这解释了几个常见现象：

• 同一张显卡跑 7B 和 70B 模型，速度差距往往接近参数量比例，因为要搬的权重变多了。
• 苹果 M 系列统一内存的带宽优势，让它在相同价位段常能跑出不错的解码速度。
• 量化到 4bit 不只是省显存，更是直接减少每 token 的搬运量，从而提升速度。
• 显存不够、模型溢出到系统内存时速度断崖式下跌，本质是带宽换成了慢得多的通道。

所以看 llmspeed 的数字时，带宽是比 TFLOPS 更值得关注的硬件参数。这也意味着，如果你的场景是单用户、短输出的交互式对话，解码速度就是体感的核心；而如果是批量吞吐场景，规律会不一样。

算力（FLOPS）与内存带宽的分工：GPU 的峰值算力通常以 TFLOPS 表示，衡量的是每秒能完成多少次浮点运算；而内存带宽以 GB/s 表示，衡量的是每秒能从显存中搬运多少数据。大模型推理分为两个性质截然不同的阶段：prefill 阶段是矩阵乘矩阵，计算量大、访存量相对小，属于「计算密集型」，受算力限制；解码阶段是矩阵乘向量，每生成一个 token 只需极少的计算，却要把全部权重读一遍，属于「内存密集型」，受带宽限制。因此同一张卡在跑不同任务时瓶颈会切换，这也解释了为什么游戏显卡的 TFLOPS 很高，跑大模型解码却未必比统一内存的苹果芯片快——后者的带宽在同等价位下往往更充裕。

Prefill 为什么对编码智能体格外关键

llmspeed 特别强调 prefill 的影响，这一点常被速度表忽略。prefill 是模型在处理输入提示词时一次性并行计算所有 token 的阶段，它是计算密集型的，和逐 token 解码的瓶颈完全不同。

编码智能体恰好是 prefill 压力最大的场景之一。原因很直接：代码任务的上下文极长——整个仓库、多个文件、报错日志、对话历史叠加起来，动辄数万 token。每次智能体发起新一轮推理，这段长上下文都要重新 prefill（除非有前缀缓存命中）。

这带来两个实际影响。第一，首 token 延迟（time to first token）可能远大于你从「tokens/s」数字里预期的值。用户感知到的是「按下回车后干等」，而不是生成速度慢。第二，支持 KV cache 复用和前缀缓存的推理框架，在编码场景中的收益被显著放大——同样的硬件，配置得当能省掉大量重复 prefill。

因此，评估一台机器是否适合跑编码智能体，只看解码 tokens/s 会得出错误结论，需要同时看 prefill 吞吐和缓存策略。

KV cache 与前缀缓存：自回归生成时，模型会把已处理 token 的 Key 和 Value 向量缓存下来（即 KV cache），后续生成新 token 时直接复用，避免重复计算历史部分。但 KV cache 只对「同一个生成过程」有效；当智能体开启新一轮请求、上下文前缀完全相同时，就需要「前缀缓存」（prefix caching）来跨请求复用。主流框架如 vLLM 的 Automatic Prefix Caching、llama.cpp 的 prompt cache 都实现了这一机制。命中前缀缓存时，数万 token 的重复 prefill 可以近乎跳过，首 token 延迟从数秒降到毫秒级。不过 KV cache 本身占用显存，上下文越长占用越大，这也是长上下文场景显存吃紧的重要原因之一。

怎么用这张速度表做决策

把这些数字落到实际选择上，可以按场景分层：

交互式对话与写作：解码速度是主指标。20 tokens/s 以上基本流畅，低于 10 tokens/s 会有明显等待感。此时优先选带宽高、能容纳目标模型量化版本的硬件。

编码智能体与长上下文任务：prefill 吞吐和首 token 延迟更重要，同时关注框架是否支持前缀缓存。上下文越长，这项权重越大。

批量处理与离线任务：吞吐量（总 token 数/时间）优先于单请求延迟，此时算力和并行度重新变得重要，与解码阶段的带宽逻辑形成互补。

一个容易被忽略的点是：llmspeed 的估算值适合用来排除明显不合适的组合（比如用核显跑 70B），而不是精确预测你的实测结果。拿到候选硬件后，用你自己的模型、量化格式和框架跑一次基准，才是最终依据。

量化对速度与质量的双重影响：4bit 量化之所以在本地部署中流行，是因为它同时缓解了显存占用和带宽压力——权重从 16bit 降到 4bit，每 token 需搬运的字节数降到约四分之一，解码速度理论上接近四倍。但量化并非无损，低比特量化（尤其是 2-3bit 或粗糙的 4bit 方案）会带来精度下降，表现为长上下文推理退化、代码生成错误率上升等。不同量化格式（GGUF 的 Q4_K_M、AWQ、GPTQ、MLX 的 4bit 等）在速度和质量上也有差异。因此看 llmspeed 的数字时，要确认它对应的是哪种量化级别，直接拿 4bit 的速度去对比 16bit 的硬件组合会得出误导性结论。

小结

llmspeed 的真正贡献不是给出精确数字，而是把「本地大模型速度」拆成了可解释的维度：解码看内存带宽，长上下文看 prefill，场景决定权重。理解了这两条规律，速度表就从一堆数字变成了可迁移的判断框架——换一台没被收录的机器，你也能大致推断它能不能跑、跑起来体感如何。

对于编码智能体这类长上下文重负载场景，尤其不要被单一的 tokens/s 迷惑，首 token 延迟和缓存命中率才是决定「好不好用」的关键。