买显卡前先跑一遍：llmspeed 把本地推理速度做成可分享预估，我们补了一组实机数据

本地跑大模型的第一个问题从来不是"哪个模型最强"，而是"我这台机器上它每秒能吐几个字、装不装得下"。过去回答它只有两条路：买回来实测，或者翻 reddit 上的零散跑分。10 月 17-18 日 Hacker News 的 Show HN 头条 llmspeed（llmspeed.dev）想当第三条路：选一块硬件、选一个模型和量化档位，网页直接把生成"流"给你看——按预估的 tok/s 逐字出现，首 token 前还有符合该配置的等待时间；两列并排还能跑竞速模式，比如 5090 对 Mac Studio。README 里的示例够挑衅：“RTX 5090 vs Mac Studio M5 Ultra 512GB on GLM-5.3 Flash (Q8). The 5090 can’t load it.”

这类工具值不值得信、该在决策里占多大权重，恰好可以用一组真实数据检验。我们在自己的 Apple Silicon 机器（128GB 统一内存）上跑了 ollama 的 qwen3.8 27B Q4_K_M，同时把社区对 llmspeed 的批评意见梳理出来。结论先放前面：llmspeed 适合做粗排和装填判断，不能当采购依据；而它值得抄的地方是把预估的不确定性做成了产品的一部分。

它怎么算的数

README 公开了完整方法论。有实测数据的硬件-模型组合直接收集自 r/LocalLLaMA、localscore.ai、llama.cpp 讨论区等来源，经过验证入库；没有实测的组合回退到第一性原理：生成速度受内存带宽约束（每个 token 要把活跃权重读一遍，MoE 只算活跃参数），prefill 受算力约束（FP16 TFLOPS），两边各用按实测校准的后端效率系数，再叠加长上下文减速；部分卸载（模型放不进显存、溢到系统内存）用混合模型算——驻留 GPU 的部分按显存带宽、溢出部分按有效内存带宽，卸载运行的实测来校准系数。装填判断上，Mac 按统一内存的约 75%、独显按显存的约 93% 作为可用量，计入权重、KV 缓存和运行时开销。

这套物理近似的方向是对的：decode 阶段确实是带宽游戏，MoE 的活跃参数才是带宽消耗者。HN 评论区的实测派也对上了这个逻辑——有人在 9 年前的 GTX 1070 本子上用 llama.cpp 分支跑 35B-A3B MoE 四比特，131K 上下文拿到 16-19 tk/s、prefill 350-500 tk/s，而"任何前沿模型或这类基准都会告诉你这台机器最好只能跑个 crappy 9B"。这就是第一类系统性偏差的来源：小众量化和引擎分支不在它的数据集里，评论区已经有人点名"tiny quants 默认档位太小"、不含投机解码、不含并行推理、双卡配置不支持。

预估偏差还有第二类，对高配用户更疼：有人反馈自己的 4090 上 Q3.8 27B UD-Q4_K_XL 加 3 draft 投机解码、110K 上下文能到 80 tok/s，“sim shows mid 20s”——预估不到真实速度的一半，因为引擎优化（投机采样、UD 量化这类）根本没进入它的校准分布。它自己的 README 在局限性一节也承认单设备假设。换句话说：方向性可信，绝对值要按你自己是否使用激进优化来打折或打满。

它做对了的一件事是诚实分级。每一个数字标注可信度等级（有实测、有外推、纯第一性原理各不相同），“How we calculated this"折叠在页面里。数据贡献走 PR 流程，要求附 llama-bench 完整输出、prefill_tps、prompt_tokens、可验证的 source_url——把跑分管道做成开源仓库的 review 流程，这在同类"体感工具"里少见。10-19 经 GitHub API 核实：nicorobinreal/llmspeed，MIT，101 星，创建于 8 月 28 日，最近推送就在昨天，issue 只有 2 个；HN 帖 226 分 75 评，站的是产品页，仓库本身还很新。

实机锚点：先把自家机器的真数测出来

为了给"预估能不能信"建一个锚点，我们在自有环境跑了一组受控测试，同时检验引擎口径与墙钟口径的差：128GB 统一内存的 Apple Silicon，ollama API（stream=false、temperature=0、num_predict=64），模型 qwen3.8:27b-hermes64k（Q4_K_M，27.3B 参数）。冷启动一次含加载：墙钟 17.67 秒，引擎报 6.75 tok/s；模型驻留后再跑：墙钟 10.07 秒，引擎 6.62 tok/s，墙钟口径 6.35 tok/s，同一次 prefill 从 13.8 tok/s 升到 50.04 tok/s（冷启动时权重还在进内存）。

两个口径的差距本身就是要点之一：引擎自报 tok/s 和含往返的墙钟 tok/s 是不同指标，llmspeed 页面展示的是接近后者的"体感”，而 llama-bench 类跑分报的是前者。短输出任务里加载和调度会把墙钟拖得很低——冷启动那轮引擎报 6.75 tok/s，墙钟口径只有 3.62 tok/s，相差近一倍；模型驻留后两轮基本重合（6.62 vs 6.35）。这组数字没有和 llmspeed 页面逐项对比，它演示的是正确用法：任何预估工具上线之前，先在自己机器上用最小脚本测一组同口径的真数，哪怕只有两轮。测速脚本就是十几行 urlopen，成本十五分钟，换来的是判断"预估能不能信"的锚点。

评论区另一条评论把 MoE 能救活老显卡的原因拆到了参数层面：A3B 表示单次前向活跃约 3B 参数，4-bit 下每字节约装 2 个参数，活跃部分只有 1.5GB 量级，才塞得进 8GB 显存；那位 1070 用户的配置里还专门把一部分 MoE 层放 CPU 侧（n-cpu-moe），dense 模型没有这种腾挪空间。同一条评论线的第二个教训是长上下文断崖：超过约 100K 后速度从 16-19 掉到 9。评论区给出的第三条出路是核显+独显混合（Vulkan 在 iGPU 跑低活跃 MoE、CUDA 在 dGPU 跑 dense）。这三个场景 llmspeed 的矩阵都不覆盖——它的 30 GPU × 15 模型粒度面向"主流组合的主流跑法"。

谁该用、谁别用

给还没买硬件的人：当"装得下吗"的预筛用——权重+KV+运行时三件套的内存账它比你自己拍脑袋算得准；当"8 tok/s 和 60 tok/s 差多少"的体感教具用——看着文字按速度流出来，比读数字直观。别拿它当两卡之间的采购裁决：引擎分支、投机解码、量化格式的方差比两台硬件之间的差距还大。

给已经在跑本地模型的人：它的价值在分享链接——把你的配置+预估发进讨论帖，别人回复时至少共享同一个坐标系。README 的贡献字段规范（prefill_tps 一行注明取 pp512 结果，PR 描述要求贴完整 llama-bench 输出）就是在给社区讨论建立统一口径。

这类工具的长期竞争力只有一个：数据管道。校准集靠 PR 收集，提交带完整可验证输出，这决定了它三年后是"速度计算器"还是"本地推理实测的维基百科"。仓库才 101 星，答案显然还没写出来——在它的数据覆盖到你的配置之前，可信的绝对值只能靠自己那组同口径真数。