想象你要开一家面向大众的连锁餐厅。开工前，你得回答几个问题：一天能接待多少桌客人？后厨需要几口锅？备菜台要留多大空间？客人点完菜后多久能吃上？在 AI 世界里，运营一个大语言模型（LLM）推理服务，遇到的正是同样的问题——只不过“菜品”变成了文本，“食材单位”变成了 Token，“后厨”变成了 GPU 显卡，“备菜台”变成了显存。Token 吞吐量估算，就是为 LLM 服务写的“开店预算表”：把模型参数、序列长度和硬件火力这些变量，转化成可预测的产能指标。学会了这套估算方法，你就掌握了 LLM 服务的“餐饮管理学”——既能算清楚当下需要多少显卡，也能预判流量高峰要提前备多少“灶台”，还能在延迟和吞吐之间找到那个最舒服的平衡点。

岗位关联

对 AI 从业者而言，掌握 Token 吞吐量估算是从“能跑模型”迈向“能稳定运营模型”的分水岭——它让你能回答老板最关心的问题：这套 AI 服务到底需要多少机器、花多少钱、扛得住多少并发。

目录
  1. 可视化演示
  2. 吞吐量定义：先定“食材单位”，再谈产能
  3. 硬件算力评估：灶台火力决定翻炒上限
  4. KV Cache 内存：备菜台上的“记忆便签”
  5. 批处理增益：一锅同时炒多道菜
  6. 并发度规划：餐桌数量与“在座人数”
  7. 容量规划实践：从需求到预算表的落地攻略
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Token吞吐量随批处理增长的增益曲线、KV Cache显存约束对最大并发度的限制、以及预填充与解码两阶段的吞吐特征对比。

本节配有交互动效（进入视口后自动加载，约 3KB）。

吞吐量随批处理增长 连续批处理动态加入请求提升利用率 吞吐随批大小增长但收益递减 Tps=f(batch) 批处理增益由并发度与调度窗口决定

吞吐量定义：先定“食材单位”，再谈产能

开餐厅前，主厨会先定标准：一盘宫保鸡丁算几份菜？是论克、论盘还是论客？标准不统一，后厨产能报告就是一笔糊涂账。LLM 服务也一样——大家口中的“模型一次能生成多少字”，必须先统一成 Token 这个“食材单位”。Token 是文本被切分后的最小单元，一个中文字通常对应 1～2 个 Token，英文一个单词大约 1.3 个 Token。Tokenizer 就像餐厅的“切菜标准”，把任意文本切成一盘盘规格统一的“食材丁”。

有了单位，吞吐量（Throughput）的定义就顺理成章：单位时间内模型总共生成的 Token 数量，公式写出来就是总 Token 数除以总耗时。但这里有个重要的行话——LLM 推理分为 Prefill（预填充）和 Decode（逐字生成）两个阶段。Prefill 像“备菜”，一次性把客人的整张菜单读进去，计算密集；Decode 像“上菜”，一个 Token 一个 Token 地往外蹦，内存密集。两个阶段的耗时特性完全不同，所以容量规划时通常分开看：TTFT（首 Token 时间）衡量备菜速度，TPOT（每个 Token 的生成时间）衡量上菜节奏。

有了标准化的“食材单位”和“出菜率”，我们才能回答下一层问题：一家店的产能上限，到底由什么决定？答案首先是灶台火力——也就是显卡算力。

吞吐量=总生成 Token 数总耗时=QtokensTtotal\text{吞吐量} = \frac{\text{总生成 Token 数}}{\text{总耗时}} = \frac{Q_{\text{tokens}}}{T_{\text{total}}}
这个公式像餐厅的“出菜率”：一天做了 1000 道菜，用了 10 个小时，出菜率就是每小时 100 道。简单直接，但拆分到备菜和上菜两个环节，才能找到瓶颈在哪。
  1. 分子总生成 Token 数：指服务在统计周期内实际吐出并交付给所有请求的 Token 总量，如同一家店一天卖出的全部菜品份数。
    Qtokens=∑i=1NLiQ_{\text{tokens}} = \sum_{i=1}^{N} L_i
  2. 分母总耗时：从第一个请求到达服务开始，到最后一个响应完整返回为止的墙钟时间，如同从开门到打烊的营业时长。
    Ttotal=Tend−TstartT_{\text{total}} = T_{\text{end}} - T_{\text{start}}
  3. 比值吞吐率：两者相除得到单位时间产能，这是容量规划中最顶层的指标，所有后续估算最终都要汇聚到这一个数字上。
    吞吐量=QtokensTtotal\text{吞吐量} = \frac{Q_{\text{tokens}}}{T_{\text{total}}}

硬件算力评估：灶台火力决定翻炒上限

餐厅的产能天花板，说到底是炉灶决定的。火力旺的灶台，一锅菜三分钟出锅；火力弱的，翻来覆去炒不熟。GPU 的算力就是 LLM 服务的“灶台火力”，以 FLOPs（每秒浮点运算次数）为单位。一块 H100 的 FP16 算力约为 990 TFLOPS，听起来是个天文数字，但模型前向计算同样贪婪。估算一条铁律：跑一次前向计算所需的 FLOPs，大约是模型参数量的两倍乘以处理的 Token 数——每个参数在每一层都要经历一次乘法和一次加法，这“一乘一加”就是两次浮点运算。

其中 $P$ 是模型参数量（如 70B = 700 亿参数），MFU（Model FLOPs Utilization）是实际利用率——反映了“灶台火力被真正用来炒菜的比例”。真实场景里 MFU 常常只有 30%～50%，因为 GPU 要等显存中搬运的数据、要等别的计算单元、还要给通信留时间，就像厨师再快也得等配菜、等锅热、等传菜的人。

灶台火力算清了，但餐厅还有第二个物理约束——备菜台。火再旺，备菜台塞不下也一样干不了活。这个“备菜台”，就是显存里的 KV Cache。

单 Token 计算量≈2×P\text{单 Token 计算量} \approx 2 \times P
理论吞吐上限=GPU 算力×MFU2×P\text{理论吞吐上限} = \frac{\text{GPU 算力} \times \text{MFU}}{2 \times P}
用 70B 模型举例：单 Token 需要约 $2 \times 70 \times 10^9 = 1.4 \times 10^{11}$ 次浮点运算。一块 H100 按 40% 利用率算，每秒可处理约 $990 \times 10^{12} \times 0.4 \div 1.4 \times 10^{11} \approx 2828$ 个 Token——这就是单卡的理论吞吐锚点。注意，这里完全没提并发，它只是“灶台全速运转一台灶”的极限产能。
  1. 参数量 $P$模型权重总数，7B、13B、70B 里的“B“就是十亿，它决定了每处理一个 Token 要动多少次”乘法加法”。
    P=70×109(70B 模型)P = 70 \times 10^{9} \quad (70\text{B 模型})
  2. 单 Token 计算量前向传播中每个参数需完成一次乘法和一次加法，合计两次浮点操作，故乘 2。
    FLOPsper token≈2P=1.4×1011\text{FLOPs}_{\text{per token}} \approx 2P = 1.4 \times 10^{11}
  3. 理论吞吐上限GPU 每秒可执行的浮点次数除以单 Token 所需次数，再乘实际利用率 MFU，得到真实可期待的吞吐锚点。
    吞吐peak=GPUFLOPs×MFU2P\text{吞吐}_{\text{peak}} = \frac{\text{GPU}_{\text{FLOPs}} \times \text{MFU}}{2P}

KV Cache 内存：备菜台上的“记忆便签”

客人点了一份佛跳墙，后厨不会把整本菜谱背下来再开始做，而是把这道菜需要的食材清单抄在便签上，边做边查。LLM 生成文本时也一样：模型处理每个新 Token 时，都需要“回忆”这个对话之前所有 Token 的内容。为了不重新算一遍历史，推理框架把每个历史 Token 的 Key 和 Value（注意力机制的键值对）缓存在显存里——这就是 KV Cache，一张张越攒越厚的“记忆便签”。便签不占灶台火力，但占备菜台空间：序列越长，便签越厚；同时服务的请求越多，便签叠得越高。

KV Cache 的显存占用有一个精确公式：每一层的每个注意力头、每个历史 Token 都要存一组 Key 和 Value，各占一定的字节数。于是总占用等于层数、头数、头维度、序列长度、批大小这五个维度的乘积，再乘以 2（Key 和 Value 各一份）和每个数值的字节数（FP16 占 2 字节）。

以 LLaMA-70B 为例：80 层、64 个 KV 头、头维度 128，当批大小 32、平均序列长度 2048 时，显存占用高达 $2 \times 80 \times 64 \times 128 \times 2048 \times 32 \times 2 \approx 171.8$ GB——一张 H100 的 80GB 显存根本装不下。这个公式是容量规划里的“硬天花板”：KV Cache 占用的显存越多，留给模型权重和数据搬运的空间就越少，能同时服务的并发请求数（Batch 大小）就越低。

灶台火力和备菜台面积都有了，聪明的后厨主管会想到：能不能一锅炒多道菜？这就是批处理的魔力。

MKV Cache=2×L×Nhead×dhead×S×B×bytesM_{\text{KV Cache}} = 2 \times L \times N_{\text{head}} \times d_{\text{head}} \times S \times B \times \text{bytes}
Bmax≤MGPU−Mweights−Mactivation2×L×Nhead×dhead×S×bytesB_{\text{max}} \leq \frac{M_{\text{GPU}} - M_{\text{weights}} - M_{\text{activation}}}{2 \times L \times N_{\text{head}} \times d_{\text{head}} \times S \times \text{bytes}}
这个约束说明：KV Cache 是容量规划里“房间的大小”。灶台火力再猛，备菜台摆不下就没法同时开炒。这也是为什么 KV Cache 量化（用 8-bit 甚至 4-bit 存便签）、PagedAttention（像操作系统的分页内存一样按页分配显存）、以及共享前缀（多个请求复用同一段对话历史的便签）会成为热门优化方向——都是为了在同样的备菜台里塞下更多便签。
  1. 层数与头数的乘积Transformer 每一层都有独立的注意力机制，Key/Value 在每个注意力头各存一份，层数 × 头数决定了“便签本”共有多少栏位。
    L×Nhead=80×64L \times N_{\text{head}} = 80 \times 64
  2. 每个 Token 的 Key 和 Value每个历史 Token 在每个注意力头都要存一组 K、V 向量，向量长度即头维度，乘 2 是因为 Key 和 Value 是两份不同的便签。
    2×dhead=2×1282 \times d_{\text{head}} = 2 \times 128
  3. 序列长度与批大小序列越长每张便签越厚，批越大同时服务的请求越多，这两项在分母上直接限制并发度 $B_{\text{max}}$。
    S×B×bytes=2048×32×2S \times B \times \text{bytes} = 2048 \times 32 \times 2

批处理增益：一锅同时炒多道菜

单炒一道菜，锅的热量大部分散在等待里；一锅炒三样菜，热量被三份食材一起吸收——批处理（Batching）就是这套逻辑。LLM 推理中，把多个请求的 Token 拼在一起做矩阵乘法，GPU 的算力利用率会大幅提升。计算的核心是矩阵乘法：处理一个批大小为 $B$、序列长度为 $S$ 的数据，计算量约为 $2P \times B \times S$——注意，参数量 $P$ 没有被乘 $B$ 次，权重矩阵被整个批次共享了。这意味着，批大小翻倍，计算量并不翻倍，吞吐量却几乎线性上升，这就是“亚线性增益”。

但天下没有免费的午餐：批大小增大，每个请求的排队时间和单个 Token 的生成时间都会变长，延迟呈线性增长。于是存在一个“吞吐翻转点”——批大小超过某个阈值后，吞吐的边际增量越来越小，而延迟还在加速上升。容量规划的目标就是在吞吐曲线和延迟红线之间找到“甜区”。

灶台火力、备菜台、炒菜批次都定了，最后一个问题是：餐厅该摆多少张桌子？这就是并发度规划。

增益=批大小 B 的吞吐B=1 时的吞吐≈B×SS+(B−1)S2=2BB+1\text{增益} = \frac{\text{批大小 } B \text{ 的吞吐}}{B=1 \text{ 时的吞吐}} \approx \frac{B \times S}{S + \frac{(B-1)S}{2}} = \frac{2B}{B+1}
回到可视化演示里的那两条曲线：绿色吞吐曲线先陡后缓，红色延迟曲线始终匀速爬升。最佳工作点通常在两者交汇之前的区域——批大小再大，多赚的吞吐还不够补偿超时的请求。这也解释了为什么现代推理框架都在做连续批处理（Continuous Batching）：不等一批全部生成完，谁完成了就立刻把新请求插进空位，相当于“流水线换菜”，让每一口锅的热量都被持续利用。
  1. 批计算量公式批处理时权重参数全体共享，计算量中 $P$ 只出现一次，而 Token 总量 $B \times S$ 线性放大，这是增益的根源。
    FLOPs=2P×B×S\text{FLOPs} = 2P \times B \times S
  2. 增益近似相比逐个处理，批处理省去了重复读取权重的开销。理想情况下吞吐增益接近 $\frac{2B}{B+1}$，当 $B=16$ 时约等于 1.88 倍，已接近 2 倍上限。
    增益≈2BB+1\text{增益} \approx \frac{2B}{B+1}
  3. 延迟代价批越大，单个请求在队列里等待的时间越长，延迟约线性增加，这是必须用 SLA（服务等级协议）锁死的红线。
    延迟≈a×B+固定开销\text{延迟} \approx a \times B + \text{固定开销}

并发度规划：餐桌数量与“在座人数”

餐厅的大堂摆了 100 张桌，但后厨的灶台火力只够同时炒 10 份菜——那 100 张桌就是摆设，客人坐下后只能干等。并发度（Concurrency）是容量规划里最容易搞混的概念：它不等于 QPS（每秒请求数），而是“任意时刻正在被处理的请求数”。两者靠一条著名的“小餐馆定律”（Little's Law）联系起来：在稳定状态下，在座人数 = 入座率 × 平均用餐时长。对应到系统里：

举个例子：线上 QPS 是 50，平均每个请求要 2 秒才能完成，那么系统中同时“在座”的请求就是 $50 \times 2 = 100$ 个。这 100 个请求的 KV Cache 便签都要占显存，都要被批处理调度。所以并发度直接决定了 KV Cache 的下限和所需的 GPU 数量。

过度订阅（Over-subscription）是常见事故：为了“榨干” GPU，把并发请求数调到超过 KV Cache 和算力能承受的水平。短期看吞吐上去了，但一旦流量毛刺到来，所有请求一起变慢，延迟雪崩，最后连健康请求也超时——就像餐厅为了翻台率让 200 个客人挤在 100 个座位上，结果菜全卡在后厨，差评如潮。

所有理论砖块都齐了，最后一步是做一张“开店预算表”——把它们组装成可执行的容量规划流程。

并发度=QPS×平均响应时间\text{并发度} = \text{QPS} \times \text{平均响应时间}
所需 GPU 数=并发度单 GPU 可承载并发=QPS×响应时间单 GPU 并发上限\text{所需 GPU 数} = \frac{\text{并发度}}{\text{单 GPU 可承载并发}} = \frac{\text{QPS} \times \text{响应时间}}{\text{单 GPU 并发上限}}
容量规划中要始终记住：并发度是“因”，吞吐和延迟是“果”。我们无法同时把 QPS、延迟、GPU 数三个变量都压到最低——只能根据业务需求锁定其中两个，再算出第三个。餐饮业叫“不可能三角”，LLM 服务里同样成立。
  1. 平均响应时间从请求到达服务器到完整响应返回的总时间，包括排队、Prefill、Decode 全链路，对应客人的“用餐时长”。
    Tresp=Tqueue+Tprefill+TdecodeT_{\text{resp}} = T_{\text{queue}} + T_{\text{prefill}} + T_{\text{decode}}
  2. 并发度计算稳定状态下系统内“同时存在”的请求数量等于到达率乘以停留时间，这是 Little's Law 的直接应用。
    C=QPS×TrespC = \text{QPS} \times T_{\text{resp}}
  3. GPU 数量估算用总并发度除以单卡能承载的并发上限，得到硬件需求的起点，再乘以安全系数 1.3～1.5 应对流量毛刺。
    NGPU=CCper GPU×安全系数N_{\text{GPU}} = \frac{C}{C_{\text{per GPU}}} \times \text{安全系数}

容量规划实践：从需求到预算表的落地攻略

开店的最后一步是把所有参数汇总成预算表。第一步是需求评估：收集线上业务的 QPS 峰值、每个请求的平均提示长度（Prompt Length）和平均生成长度（Generation Length）。这三个数字就是餐厅的“客流量、平均点菜量、平均用餐时长”。第二步是单实例估算：按第二节的算力公式算出单 GPU 的理论吞吐，再按第四节批处理增益打折得到实际吞吐锚点；同时按第三节 KV Cache 公式算出单 GPU 能承载的最大并发度。第三步是实例数计算：用需求 QPS 除以单实例的吞吐能力，再乘上安全余量。

但公式只是起点，没有一家餐厅的翻台率是靠理论算出来的——必须试营业。负载测试是容量规划不可省略的一环：用真实流量回放或合成请求打到推理服务上，逐步加压，记录吞吐、TTFT、TPOT 与 KV Cache 占用率，画出与可视化演示中类似的“吞吐-延迟-批大小”三维曲线，校准公式中 MFU 和延迟系数的估计偏差。测试后进入调优环节：调整最大批大小限制、KV Cache 分配策略、是否启用连续性批处理与 PagedAttention，观察哪些参数的边际收益最高。

N实例=⌈QPS峰值×Tresp单实例并发容量×(1+余量)⌉N_{\text{实例}} = \left\lceil \frac{QPS_{\text{峰值}} \times T_{\text{resp}}}{\text{单实例并发容量}} \times (1 + \text{余量}) \right\rceil
完整链路可以概括为“建模-估算-测试-调优”四步。建模用公式框定理论边界，估算给出初始机器数量，测试暴露真实瓶颈，调优把余量压到合理区间。容量规划不是一次性项目，而是一套随业务增长持续迭代的流程——正如成熟餐厅会按季度复盘翻台率，调整菜谱和桌椅配比。
  1. 需求总量峰值 QPS 乘以平均响应时间，得到所需支撑的总并发数，这是预算表的“需求方”。
    C需求=QPS峰值×TrespC_{\text{需求}} = QPS_{\text{峰值}} \times T_{\text{resp}}
  2. 单实例容量单 GPU 可承载的并发上限受限于 KV Cache 显存和算力，两者取较小值——“备菜台”和“灶台”哪个先到顶，哪个就是瓶颈。
    C单=min⁡(算力吞吐Savg, MGPU−M权重MKV per token)C_{\text{单}} = \min\left(\frac{\text{算力吞吐}}{S_{\text{avg}}},\ \frac{M_{\text{GPU}} - M_{\text{权重}}}{M_{\text{KV per token}}}\right)
  3. 实例数向上取整除法结果不能有半台机器，向上取整并乘安全系数，得到最终采购数量。
    N实例=⌈C需求C单×1.4⌉N_{\text{实例}} = \left\lceil \frac{C_{\text{需求}}}{C_{\text{单}}} \times 1.4 \right\rceil
text1 行
需求采集 → 单实例估算 → 实例数计算 → 负载测试校准 → 配置调优 → 回归复测

AI 应用场景

大模型 API 服务的成本预算与扩容决策

阶段：容量规划与成本优化

解决的问题：创业公司上线一个基于 70B 模型的编程助手 API，预估峰值 QPS 为 200，平均提示长度 1500 Token，平均生成长度 800 Token。没有量化工具时只能“先买 100 张卡再说”，成本失控；用 Token 吞吐估算模型，先用算力公式算出单卡理论吞吐，再用 KV Cache 公式算出单卡并发上限，两步一对比就发现瓶颈在显存而非算力，实际只需 32 张卡，成本直接砍掉三分之二。

具体案例：某 AI 编程助手团队在发版前用估算模型 + 负载测试完成了容量规划。他们先以 70B 模型、H100 显卡为输入跑通估算流程，得到单卡约 2800 tok/s 的锚点；再用真实请求做压测，发现实际吞吐 1800 tok/s（MFU 约 25%），于是把安全系数从 1.4 调到 1.8，最终既保证了高峰期 P95 延迟达标，又避免了下个月的“加卡恐慌”。

推理服务 SLA 保障与弹缩策略

阶段：线上监控与自动扩缩容

解决的问题：上线后流量是波动的，凌晨三点和晚上八点的并发差十倍。没有吞吐模型，弹性伸缩只能靠“CPU 超过 80% 就加机器”的粗放规则，经常加晚了或者缩多了。基于 Token 吞吐估算建立弹性策略：把吞吐锚点和 KV Cache 占用率作为扩缩容指标，在队列积压超过单实例吞吐承载阈值时提前 5 分钟扩容，在低峰期合并请求降低实例数。

具体案例：某客服机器人团队用 KV Cache 占用率作为主要扩缩容信号：当显存中 KV Cache 占用超过单卡上限的 70% 时，Predicted 未来 10 分钟将持续超限，则触发扩容一台；低于 30% 持续 30 分钟则缩容。这套规则上线后，账单下降 40%，同时 P95 延迟保持稳定。

Python 演示

python44 行
import math def kv_cache_bytes(layers, kv_heads, head_dim, seq_len, batch, dtype_bytes=2):    return 2 * layers * kv_heads * head_dim * seq_len * batch * dtype_bytes def decode_throughput(gpu_tflops, mfu, param_b):    flops_per_token = 2 * param_b * 1e9    return gpu_tflops * 1e12 * mfu / flops_per_token def max_batch_by_memory(gpu_mem_gb, weight_gb, layers, kv_heads,                        head_dim, seq_len, dtype_bytes=2):    kv_bytes_per_token = 2 * layers * kv_heads * head_dim * dtype_bytes    free_bytes = (gpu_mem_gb - weight_gb) * 1024 ** 3    return int(free_bytes // (kv_bytes_per_token * seq_len)) def plan_capacity(qps, avg_output, avg_prompt, layers, kv_heads,                  head_dim, param_b, gpu_tflops, gpu_mem_gb,                  weight_gb, mfu=0.4, safety=1.4):    single_tps = decode_throughput(gpu_tflops, mfu, param_b)    seq_total = avg_prompt + avg_output    batch_peak = max_batch_by_memory(gpu_mem_gb, weight_gb, layers,                                     kv_heads, head_dim, seq_total)    batch_opt = int(batch_peak * 0.7)    single_qps = single_tps / seq_total    total_qps = qps * safety    instances = math.ceil(total_qps / single_qps)    return {        "single_tps": round(single_tps),        "kv_cache_gb": round(kv_cache_bytes(layers, kv_heads, head_dim,                             seq_total, batch_opt) / 1024 ** 3, 2),        "batch_peak": batch_peak,        "batch_opt": batch_opt,        "instances": instances,    } if __name__ == "__main__":    result = plan_capacity(        qps=100, avg_output=512, avg_prompt=1024,        layers=80, kv_heads=64, head_dim=128,        param_b=70, gpu_tflops=990, gpu_mem_gb=80,        weight_gb=140, mfu=0.4, safety=1.4,    )    for key, value in result.items():        print(f"{key}: {value}")
目的：实现正文中的 Token 吞吐量估算模型——输入 QPS、模型结构与硬件参数，输出单卡吞吐锚点、KV Cache 显存占用、最优批大小和所需 GPU 实例数。
  1. decode_throughput(gpu_tflops, mfu, param_b)用算力公式计算单卡每秒能生成的 Token 数，对应“灶台火力”的理论吞吐上限。
  2. max_batch_by_memory(...)用 KV Cache 公式反推显存最多能支撑的批大小，即“备菜台最多能同时摆多少份便签”。
  3. kv_cache_bytes(...)复现正文公式 2 × L × kv_heads × head_dim × seq_len × batch × bytes。
  4. batch_opt = int(batch_peak * 0.7)不把显存用满，留 30% 余量给权重搬运和激活值，对应正文的安全系数哲学。
  5. instances = math.ceil(total_qps / single_qps)需求除以单机产能后向上取整，得到采购机器台数。
  6. seq_total = avg_prompt + avg_output平均提示长度 + 平均生成长度 = 每个请求占用的 Token 总量，决定了“每桌客人要占多少张便签”。

常见误区

误区我用 990 TFLOPS 和 70B 参数一除，算出单卡能跑 2800 tok/s，就直接按这个数规划容量了，结果上线第一天就延迟爆炸。公式算出来的数字难道是假的吗？

正解理论吞吐是“灶台火力全开、食材永不间断”的实验室数据。实际运行中，显存搬运、注意力计算、通信开销、甚至输入输出的长短不一都会让效率打折。正文中的 MFU（实际利用率）就是用来修正这个差距的：先用公式算理论值，再乘 0.3～0.5 的经验利用率，最后一定要用负载测试校准。公式给的是“上限”，不是“承诺”。

为何常见：因为算力公式形式上太简洁了——一个除法就出结果，很容易让人忽略它省略了“利用率”这个关键系数，忽略了真实系统的各种损耗。

误区用户输入了 1000 个 Token，我就按序列长度 1000 算 KV Cache 大小。但实际显存里好像多了很多，这是模型出 bug 了吗？

正解KV Cache 存的是“已生成的所有历史 Token”，而生成是逐 Token 进行的——一个请求从输入到生成完毕，最长可能膨胀到 1000 + 2000（生成长度）= 3000。容量规划必须按最大序列长度（Max Sequence Length）而非输入长度计算，而且还要加上系统预留的 KV Cache 池（比如 PagedAttention 的预分配块）。就像餐厅按“客人最多可能点 8 道菜”备料，而不是按“平均点 3 道菜”备料。

为何常见：日常观察中大家习惯把“输入长度”当成请求的尺寸，忽略了 LLM 是生成式模型，输出会持续扩大 Token 总数，越长的对话越吃显存。

误区线上 QPS 是 200，我就把并发度设成 200，结果请求大量超时。并发度不就是每秒请求数吗？

正解QPS 是“每秒新来多少客人”，并发度是“此刻餐厅里坐着多少人”。每个请求从进来到离开要花好几秒，所以并发度 = QPS × 平均响应时间。当响应时间 2 秒时，200 QPS 对应的并发度是 400 而不是 200。这两者的混淆是容量规划翻车的第一大原因——你以为摆了 200 张桌，实际需要的桌数是 400。

为何常见：计算机领域的传统服务常把并发与 QPS 混着说，因为无状态服务处理快、响应时间短，两者数值接近；但 LLM 生成式推理动辄几秒到几十秒，这个差距被急剧放大。

误区吞吐量随批大小增加而上升，那把批大小调到最大不就能榨干 GPU 了吗？我把 max_batch_size 调满，结果 P99 延迟直接翻了三倍。

正解批处理增益是亚线性的——批大小翻倍，吞吐并没有翻倍（曲线越来越平）；但延迟是线性的——批大小翻倍，每个请求的等待时间近似翻倍。容量规划要找到“吞吐翻转点”：批大小超过该点后，每增加一个批次位置换来的吞吐增量，已经弥补不了延迟超时带来的损失。正确的做法是给批大小设上限，并配合动态批处理让请求随到随处理。

为何常见：多数人在学习批处理时只看到“吞吐收益”的一面，忽略了它同时是延迟放大器的另一面。可视化演示中两条曲线的对比，正是对这个误区最直观的校正。

误区我在网上看到别人说连续批处理和 KV Cache 量化能提升 2 倍吞吐，抄过来一用，结果我的场景反而变慢了。是这些优化没用吗？

正解容量规划是“估算 + 实测”的双循环。参数是否有效取决于具体负载：长序列对话场景下 KV Cache 量化收益巨大，但短问答场景下收益就有限；连续批处理在高并发时优势明显，但低并发时反而增加调度开销。用公式估算出初始参数，再做负载测试扫描关键参数（批上限、KV Cache 分配率、并发度），以实测曲线为准，才能找到自己的“甜区”。

为何常见：因为从众心理和对比报告的误导——别人发出来的 benchmark 数字是在他们的负载、硬件、框架版本下测出来的，直接迁移到自己的场景往往水土不服。

面试题

Q1. LLM 推理中的"Token"最恰当的理解是？

单选题 · easy

  • A.文本切分后的最小处理单元← 正确答案
  • B.一个完整的英文单词
  • C.模型层的数量参数
  • D.GPU 的浮点运算次数

答案：A。Token 是文本被切分后的最小单元，中文一个字约 1~2 个 Token，英文一个单词约 1.3 个。它如同餐厅的“食材丁”，是度量吞吐量的标准单位；B 把 Token 与单词混淆，C 是模型结构，D 是硬件指标。

Q2. LLM 推理的 Prefill 阶段相当于餐厅流程中的哪个环节？

单选题 · easy

  • A.客人排队等位
  • B.后厨一次性备齐食材← 正确答案
  • C.服务员逐道传菜
  • D.收银台结账

答案：B。Prefill 阶段一次性处理整个输入提示，计算密集，如同后厨按整张菜单一次性备菜；Decode 阶段逐 Token 生成，如同逐道传菜。区分这两个阶段对分析 TTFT 和 TPOT 非常关键。

Q3. 一块 GPU 理论算力 990 TFLOPS，模型 70B 参数，MFU 为 40%，则单 Token 的理论吞吐上限约是多少？

单选题 · mid

  • A.约 707 tok/s
  • B.约 2828 tok/s← 正确答案
  • C.约 7070 tok/s
  • D.约 14140 tok/s

答案：B。单 Token 计算量约 2×70×10⁹=1.4×10¹¹ FLOPs；可用算力 = 990×10¹²×0.4=3.96×10¹⁴；两者相除得约 2828 tok/s。选项 A 漏乘了 MFU 对应的 990（只算了 0.4/2×70 的近似），C 和 D 则是把参数量或利用率搞错。

Q4. KV Cache 的显存占用与下列哪组因素成正比？

单选题 · mid

  • A.层数、注意力头数、头维度、序列长度、批大小← 正确答案
  • B.模型参数量、GPU 算力、批大小
  • C.学习率、上下文窗口、词表大小
  • D.层数、词表大小、GPU 显存总量

答案：A。KV Cache 公式为 2×L×N_head×d_head×S×B×bytes，五个结构维度的乘积决定显存占用。B 中的算力、C 中的学习率、D 中的显存总量都不在公式中；词表大小影响模型权重而非 KV Cache。

Q5. Little's Law 在 LLM 服务中的正确表述是？

单选题 · mid

  • A.并发度 = QPS × 平均响应时间← 正确答案
  • B.吞吐量 = 并发度 × GPU 数量
  • C.延迟 = 批大小 × 平均生成长度
  • D.QPS = 并发度 × 响应时间

答案：A。Little's Law 指出系统内平均请求数 = 到达率 × 平均停留时间，即并发度 = QPS × 平均响应时间。B 混淆了并发与吞吐，C 把延迟与批大小强行关联，D 把除法写成了乘法——响应时间 2 秒时，200 QPS 需要 400 并发，这是规划的核心算式。

Q6. 批处理中“吞吐翻转点”指的是？

单选题 · hard

  • A.批大小超过该点后吞吐开始下降
  • B.批大小超过该点后边际吞吐增量为零
  • C.批大小超过该点后延迟增幅开始超过吞吐增益← 正确答案
  • D.批大小等于 GPU 显存上限的点

答案：C。吞吐随批大小亚线性上升、延迟线性上升，翻转点正是“再多加一个批次位置，延迟代价已大于吞吐收益”的工作点。注意 A 不对：吞吐不会下降，只是增速放缓；容量规划应把工作点设在翻转点之前的甜区。

Q7. 以下哪些措施能增加单 GPU 可承载的并发请求数？

多选题 · mid

  • A.对 KV Cache 做 8-bit 量化← 正确答案
  • B.降低最大序列长度限制← 正确答案
  • C.提高 MFU 利用率← 正确答案
  • D.增加模型参数量

答案：ABC。KV Cache 量化（A）直接压缩便签体积；降低序列上限（B）减少每个请求的便签厚度；提高 MFU（C）让同样火力炒更多菜。D 增加参数量会同时推高权重和计算开销，反而降低可承载并发。

Q8. 容量规划中，需求评估阶段需要采集哪些输入数据？

多选题 · mid

  • A.峰值 QPS← 正确答案
  • B.平均提示长度与平均生成长度← 正确答案
  • C.模型参数量
  • D.GPU 的 FP16 算力

答案：AB。需求评估关注“客人带来多少需求”——QPS 决定客流量，提示与生成长度决定每桌的 Token 消耗量。模型参数量（C）和 GPU 算力（D）属于硬件侧输入，在“单实例估算”阶段使用，不属于需求采集。

Q9. 关于过度订阅（Over-subscription）的说法，正确的有？

多选题 · hard

  • A.并发请求数超过系统实际承载能力← 正确答案
  • B.短期提升吞吐但延迟会雪崩← 正确答案
  • C.是提升吞吐量的推荐长期策略
  • D.超发请求会导致 KV Cache 显存耗尽← 正确答案

答案：ABD。过度订阅是超出算力与 KV Cache 承载上限地接收并发请求（A），短期看似吞吐上升，但一旦流量毛刺到来，延迟同步恶化引发雪崩（B），并可能撑爆显存（D）。C 明显错误：它不是可推荐的长期策略，正确做法是限制批大小并预留余量。

Q10. 某服务峰值 QPS=50，平均响应时间=2s，安全系数 1.5，单 GPU 可承载并发为 25，所需 GPU 数为？

单选题 · hard

  • A.4 台
  • B.6 台← 正确答案
  • C.8 台
  • D.10 台

答案：B。并发度 = QPS × 响应时间 = 50 × 2 = 100；考虑 1.5 安全系数后需求为 150；150 ÷ 25 = 6 台，向上取整仍为 6。A 未乘安全系数，C 和 D 是把并发度或安全系数计算颠倒。这题综合了 Little's Law 与实例数公式。