本地部署 LLM 时 prefill 速度常被忽视？社区讨论其 ROI 价值
Reddit 用户讨论指出，prefill 吞吐量常达 decoding 的数十倍，但在本地 LLM 的 ROI 讨论中…
在讨论本地部署大语言模型的投入产出比（ROI）时，输出速度（decoding）几乎总是核心指标，而输入速度（prefill）却鲜被提及。近日 Reddit r/LocalLLaMA 上一则技术讨论指出，prefill 吞吐量在实际部署中可能远高于 decoding，其对硬件 ROI 的影响或许被严重低估。
案例数据：4 块 DGX Spark 上的并发推理
讨论者引用了 X 平台上一位用户的部署方案：使用 4 块 NVIDIA DGX Spark 运行某 GLM 系列模型（帖文称 GLM 5.2，采用 4bit 量化与推测解码等优化），在 6 名用户并发场景下达到约 60 output tokens/s 的输出速度。
按此速度推算，若以 24/7 全天候智能体（agentic）工作负载运行，每天可生成约 518 万个输出 token。按 4.40 美元/百万输出 token 的价格折算，单日输出侧价值约为 22 美元。仅从输出角度看，这已经是一组相当亮眼的数字。
被忽视的另一面：prefill 吞吐量
讨论者进一步指出，同一套部署在 prefill 阶段的吞吐量约为 3000 tokens/s，是输出速度的约 50 倍。尽管 prefill 单价较低（约 1.40 美元/百万输入 token），但其吞吐量优势十分显著：
- 输出 token 单价约为输入的 3–5 倍；
- 但 prefill 速度通常比 decoding 快 10–30 倍；
- 在该案例中，这一比值甚至达到约 50 倍。
按此推算，prefill 阶段的「硬件单位时间产出」在数量级上明显高于 decoding，理论上应在成本模型中占据更显著的位置。
为什么 prefill 容易被低估？
讨论者对此现象感到困惑，质疑为何在衡量本地 LLM ROI 时几乎无人将 prefill 纳入考量。从纯吞吐量角度看，prefill 的硬件利用效率远高于 decoding，似乎更值得讨论。
帖文最后也抛出了疑问：实际应用中的输入/输出 token 比例，是否与讨论者的假设存在较大差距？这或许是 prefill 常被忽略的关键原因——在多数生成式工作负载下，单次请求的输出 token 数量往往远超输入，使得 decoding 阶段更容易成为延迟与成本的瓶颈，从而吸引了绝大部分注意力。
一点提醒
需要指出的是，该帖文引用的「GLM 5.2」并非已公开的智谱模型版本，且 X 平台原帖的硬件配置与吞吐数据均未在官方渠道得到验证，相关数字仅可作为思路参考而非可复现的基准。对于真正计划评估本地部署 ROI 的团队，仍应以自己工作负载的输入/输出 token 比例，结合实测吞吐数据进行测算。