算力够不够？一本把 QPS 算明白的开源案头手册

做推理部署的人大多经历过这样的对话：产品经理问"能扛多少并发"，你心里没有数，嘴上不能没有数。于是诞生了两个派别——拍脑袋派报一个吉利数字，压测派烧一周时间测完再上线。这份开源手册想终结的，正是这种两难。

综述

这是一份开源的大模型推理容量案头手册，解决的问题很具体：给定 GPU 算力，模型能扛多少 QPS。手册给出的方法框架包含四个关键词：三层模型、三面墙、排队论与开环压测。它的价值定位不是"又一个 benchmark 榜单"，而是一套工程师可以照着做、做完能写进容量规划文档的方法论。

值得注意它的载体：文档本身就是开源交付物。对一个以"教人算容量"为主题的项目来说，代码和公式是次要的，可复现的步骤与判断框架才是核心资产——这决定了它的生命力取决于更新频率与社区校准。

专业分析

拆开四个关键词看它的工程思维。

"三层模型"解决的是"系统里到底谁在排队"的认知问题——请求层、推理层、硬件层各自有吞吐与延迟特性，瓶颈不会总在显存上。"三面墙"则是对约束的形象化：显存墙决定装不装得下，带宽墙决定喂不喂得动，算力墙决定算不算得完。这三个约束在推理路径上依次出现，先撞哪堵墙，瓶颈就在哪。

排队论是这套方法的理论骨架。推理服务本质是一个排队系统：请求到达率、服务时间分布、队列长度与响应延迟之间有着确定的关系。手册把排队论从课本语言翻译成"你该看哪个指标、该调哪个旋钮"的工程语言。

开环压测则是验证手段——闭环压测（等响应再发下一个）测的是单请求体验，开环压测（不管响应持续灌请求）才测得出系统真实吞吐与排队行为。这个区分，恰恰是很多团队压测半天得出"性能很好"幻觉的原因。

关联信息与影响

把这份手册放进本周情报，它与 FreeToken 恰好是一枚硬币的两面：FreeToken 回答"怎么让模型跑起来"，手册回答"跑起来之后怎么知道够不够用"。前者解决显存墙，后者解决规划墙——本地部署与云上推理其实共享同一套容量焦虑。

对行业更深的影响在于文档形态：AI 工程化的知识正在从"论文+博客"走向"可执行的案头手册"。当 GitHub 上出现越来越多"照着做就行"的工程手册，说明这个行业正在完成从研究社区到工程社区的转身。

未来展望

短期，手册的价值取决于两点：是否有人按它的方法跑出真实案例并回填（社区校准），以及公式与工具链是否随新硬件（HBM 带宽变化、新的量化格式）及时更新。中期，它可能衍生出配套的小工具——输入显存与模型规模，输出容量估算表。长期，这类方法论会被吸收进更成熟的容量管理平台，就像当年"数据库调优手册"最终变成了云厂商的自动伸缩能力。

信号强度

大模型厂商：容量估算方法越普及，客户对"贵"与"慢"的判断越专业，厂商需要把服务协议里的性能承诺写得越来越具体。

研究者：推理系统研究（调度、批处理、投机解码）多了一个从工程需求倒推问题的入口。

开发者与运维工程师：最直接的受益者——上线前能给出有依据的容量数字，规划采购与弹性伸缩时有方法论支撑，跟老板和客户沟通时不再靠"感觉"。

独立开发者：用消费级卡跑小规模服务的场景同样适用——先算清楚再决定买不买第二张卡。

关联产业链：GPU 采购决策、云实例选型、IDC 扩容规划都会被这种"可计算性"改变——当容量能算出来，销售话术里"性能强劲"的模糊地带就越来越小。

这份手册没有给出神奇的加速倍数，它给的是另一种东西：让"够不够"从一道玄学题变成一道算术题。在 AI 工程化的进程里，后者可能比前者更有价值。