先分清三种「快」

本地模型的速度不是一个数字。首 token 延迟（TTFT）决定你按下回车后要等多久；解码速度（decode tok/s）决定长回答吐得多快；提示词处理速度（prompt processing）决定你贴进去一份长文档时要不要等。聊天场景对 TTFT 敏感，批处理场景更看总吞吐——同一个模型、同一台机器，在这三种任务里的体感可以完全不同。

所以第一步不是选卡，而是把你真正要跑的任务写成可测的形状。否则你会在「7B 很快」和「32B 太慢」之间反复横跳，却不知道慢的是模型、上下文长度，还是并发。

第一步：把任务写成可测的三行

写三个数就够了：输入大概多少 token、输出大概多少 token、同时有几个人用。比如「贴 2,000 token 的合同，让它输出 500 token 的摘要，单人使用」；或者「8,000 token 的代码库上下文，输出 1,500 token 的改动说明，3 人并发」。这三个数会贯穿后面的估算与实测，别用「短提示词」「长文本」这种模糊描述。

再补一条约束：你能接受的首 token 延迟是多少。有人能等 3 秒，有人超过 1 秒就觉得卡。这个阈值不是技术指标，但它会直接决定你该选多大模型、要不要量化。

第二步：用 llmspeed 缩小候选

打开 llmspeed，先按硬件筛，再按模型筛。它的页面把硬件（RTX 3090 / 4090 / 5090、Mac Studio M5 Ultra、Strix Halo、DGX Spark、RTX Spark 笔记本等）和模型（Qwen 3.6/3.8、Gemma 4、GLM-5.3、DeepSeek V4.1 Flash、GPT-OSS 等）做成两组入口，给出的是「短提示词、单设备」下的速度估计。

关键看它标的来源：measured 来自 r/LocalLLaMA、localscore.ai 等社区实测，projected 是按相似配置或规格推算的。后者可以用来排除明显不合适的组合，但不能当作你机器的结论。先做第一轮过滤：显存装不下就直接淘汰，别指望「跑起来再说」。

第三步：把估算值记下来，但别当结论

把候选缩到两三个，记下每个组合的估算 tok/s、显存需求、以及页面标的是 measured 还是 projected。同一个模型换一种量化（Q4 / Q8 / FP8）、换一个推理后端（llama.cpp / vLLM / MLX），数字会明显变化；页面不可能覆盖你所有的驱动与后端组合。

这一步的产出不是「买哪张卡」，而是一张待验证清单：哪两个组合值得上机测、每个组合最可能卡在哪（显存、带宽、还是提示词处理）。

第四步：在目标机器上跑一次真实任务

用 Ollama 的话，跑 ollama run <模型> --verbose，它会在回答结束后打印 eval rate（解码 token/s）等统计；用 llama.cpp 的话，用 llama-bench -m <模型.gguf> -p 2048 -n 512 分别看提示词处理与解码速度。两者都跑三次，丢掉第一次（冷启动与缓存还没稳定），取后两次的中位数。

如果你要通过 API 接进产品，再单独记一次首 token 延迟：从发请求到收到第一个流式 token 的时间。这个数在 Ollama 的 verbose 输出里没有，得在你的客户端打点。测的时候用第一步写的那三个数，不要用「你好」这种几十 token 的提示词——它测不出长上下文的开销。

第五步：把「能跑」和「够用」分开

模型能加载不等于任务能跑。看两个余量：显存余量（加载后还剩多少，给上下文和并发留空间）与上下文长度（你真正需要的最大长度，不是模型卡上的最大值）。一张 8GB 卡跑 7B Q4 可能很轻松，但把上下文拉到 32K、再开两个并发，就可能开始溢到内存、速度断崖式下降。

做法很直接：用你业务里最长的那份输入再跑一次，而不是只用平均值。如果最长输入下的 TTFT 或显存已经不可接受，说明这个组合只适合「短任务本地、长任务走 API」的混合方案。

第六步：算一笔包含电费与维护的账

单 token 成本不要只算硬件价格。用一个粗糙但够用的公式：每小时成本 = 硬件价格 /（预计使用小时数）+ 整机功耗（kW）× 电价（元/kWh）+ 维护时间折算。再把每小时能产出的 token 数除进去，得到「每百万 token 成本」，和 API 报价放在同一张表里比。

别忘了两项隐性成本：失败重试与空转。本地服务为了随时可用通常常开，空闲时的电费也要摊进去；模型答错后重跑的 token，在本地不体现在账单上，但体现在时间上。把这些写进表里，结论通常会比「本地一定更便宜」更保守。

第七步：写一张决策卡

最后只留一张三列表：任务（输入/输出/并发）、实测（TTFT / tok/s / 显存峰值）、成本（每百万 token 本地 vs API）。结论分三档：全本地、混合（敏感或高频任务本地，突发走 API）、全 API。每档写清触发条件，比如「TTFT 超过 2 秒就切 API」「显存峰值超过 80% 就降上下文」。

这张卡的有效期不长：换驱动、换量化、换后端、模型升级，都可能让数字变。把它和测试日期放在一起，下次升级后按同一道题重跑一遍，比重新做一轮选型省事得多。

边界：估算不是 benchmark

llmspeed 的数字是估计，不是你这台机器的 benchmark；它的价值在于帮你快速排除明显不合适的组合，而不是替你做最终决定。反过来说，如果本地实测慢一点，但数据不出内网、或者省下了按 token 计费的不可控账单，本地仍然可能是对的——速度只是决策的一个维度，不是全部。