小明想开一家“云端甜品工厂”。开业前，他必须回答几个问题：高峰期同时有多少顾客排队点单？该请十个全能厨师，还是买一台只会做珍珠的专用机器？冷藏仓库要租多大？总共要准备多少预算？——这不是开店的烦恼，而是大语言模型服务上线前，你作为工程师必须做的“算力容量规划”。 模型就像工厂里的“配方”，用户的提问就像一张张“订单”，而 GPU 和 TPU 是两类截然不同的“生产力设备”。GPU 是那种什么甜点都会做的全能厨师，灵活但单价不菲；TPU 是那种只做珍珠但速度快到惊人的专用流水线，极致高效却十分挑剔——它只能跑“珍珠”这一道工序。要让工厂既接得住高峰期的订单，又不养闲人浪费预算，就得先算需求、再比设备、算清仓库、规划规模和账本。 这篇文章就用甜品工厂的故事，带你走完 GPU 与 TPU 容量规划的全流程：从需求测算、性能画像、显存约束，到选型对比、集群规模、成本估算与上线验证，帮你形成一张随时可用的“开店清单”。

岗位关联

学会本知识，你就能在 LLM 服务上线前回答“该买多少卡、买什么卡、花多少钱”，为企业节省几十万到几百万的算力成本，这是 AI 基础设施工程师的核心竞争力。

目录
  1. 可视化演示
  2. 推理需求测算
  3. GPU性能特征
  4. TPU性能特征
  5. 显存容量约束
  6. 硬件选型对比
  7. 集群规模规划
  8. 成本估算实践
  9. 容量规划流程
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态展示LLM推理容量规划四阶段流程、GPU与TPU加速器对比、HBM显存约束分析与利用率提升效果。

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

推理需求测算

甜品工厂开业前，店长第一件事不是急着买烤箱，而是站在门口数人流量：早高峰有多少人同时排队？每人大概点几杯？如果一小时只来十个客人，买十台机器就是浪费；如果高峰期涌进三百人，两台机器就会让队伍排到马路对面。容量规划的第一步，从来不是选设备，而是算需求。

在 LLM 服务里，“客人”就是调用推理接口的用户，“订单”就是一条条文本生成请求。我们需要两个核心数字：一是“并发会话数”——同一时刻有多少条请求正在模型里运行；二是“吞吐需求”——服务每秒要吐出多少个 token（可以理解为“字词碎片”）。前者决定了系统要同时“供着”多少人，后者决定了算力要转多快。

并发会话数通常由总用户数和高峰活跃率推算。一个日活 100 万的聊天应用，高峰时段可能只有 5% 的用户同时在对话，这 5 万条会话也不可能同时打进模型，因为中间还隔着用户打字的“思考时间”。工程上常用活跃率折减得到并发数，再乘以单会话的生成速度（每秒 token 数），就得到服务必须支撑的吞吐目标。

需求算错了，后面所有设备采购、预算估算都会跟着错。回到甜品工厂——先数清“高峰期同时排队的人数”和“每人每秒能喝掉几口”，才能决定后厨要多快。这就是容量规划里“需求是锚”的道理。

Cconcurrent=Nusers×Uactive,Rtokens/s=Cconcurrent×Vgen\displaystyle C_{concurrent} = N_{users} \times U_{active}, \qquad R_{tokens/s} = C_{concurrent} \times V_{gen}
通俗地说：并发会话数 = 总用户数 × 高峰活跃率；总吞吐 = 并发会话数 × 每条会话的生成速度。前者算“同时有多少人站着点单”，后者算“后厨每秒要出多少口吃的”。
  1. 总用户数 \(N_{users}\)注册或日活用户规模，是所有“潜在客人”的上限，通常直接来自产品指标。
    NusersN_{users}
  2. 活跃率 \(U_{active}\)高峰时段真正同时发起请求的用户比例，取值在 0 到 1 之间。它排除了发呆、打字间隙、已离开的用户。
    UactiveU_{active}
  3. 并发会话数 \(C_{concurrent}\)两者相乘得到的同时运行的推理会话数。注意它不是“每秒请求数”，而是“同一时刻在跑的条数”。
    Cconcurrent=Nusers×Uactive\displaystyle C_{concurrent} = N_{users} \times U_{active}
  4. 单会话生成速度 \(V_{gen}\)每条会话每秒生成的 token 数，受模型大小和硬件共同影响，通常取实测值而非理论值。
    VgenV_{gen}
  5. 吞吐目标 \(R_{tokens/s}\)两者相乘得到每秒总 token 产出需求，它是后面所有设备计算的起点。
    Rtokens/s=Cconcurrent×Vgen\displaystyle R_{tokens/s} = C_{concurrent} \times V_{gen}

GPU性能特征

甜品工厂的首选设备是“全能厨师”。他既会烤蛋糕、做马卡龙，也会调奶茶，菜单随便换他都能上手。但全能厨师有个毛病：一旦被同时安排十条订单，手忙脚乱，效率直线下降。GPU 就是 AI 世界的全能厨师——什么算子都能跑，但实际效率要打折扣。

GPU 最初为图形渲染设计，天然擅长大规模并行计算。在 LLM 推理中，它既能跑权重矩阵乘法，也能灵活处理注意力、采样、并行切分等各类操作，配套生态（CUDA 编程框架、PyTorch、vLLM 推理引擎）也最成熟。刻画它的能力需要三个指标：峰值算力（每秒浮点运算次数）、显存带宽（HBM 高速显存的读写速度）、以及实际利用率。

峰值算力只是“纸面速度”，真实推理远达不到。研究者用 MFU（模型浮点利用率）衡量实际算力发挥比例，LLM 推理场景的 MFU 通常只有 10%~30%。瓶颈往往不在算力而在显存带宽——每生成一个 token 都要把全部权重从显存里读一遍，属于“访存密集”型任务。NVIDIA 的 A100、H100、H20 等型号正是通过不同的算力、带宽、显存组合来适配不同场景。

全能厨师的能力不是铭牌上写的“一小时做一百道菜”，而是实际高峰中被催促、被切换、被等原料时能做到的二十道。买 GPU 也一样——用 MFU 打个折，才不会被峰值参数忽悠。

Ceff=Cpeak×ηMFU\displaystyle C_{eff} = C_{peak} \times \eta_{MFU}
有效算力 = 峰值算力 × 利用率。就像厨师的“真实速度”是“纸面速度”乘以高峰期的发挥系数，买卡要按这个打折后的数字来算账。
  1. 峰值算力 \(C_{peak}\)GPU 标称的每秒浮点运算次数（FLOPs），是出厂铭牌上的最高速度。
    CpeakC_{peak}
  2. 模型利用率 \(\eta_{MFU}\)真实运行中算力被有效利用的比例，取值 0~1。推理常受带宽限制，只有 0.1~0.3。
    ηMFU\eta_{MFU}
  3. 有效算力 \(C_{eff}\)两者相乘才是这台 GPU 实际能贡献的“真实速度”，选型应比较有效算力而非峰值。
    Ceff=Cpeak×ηMFU\displaystyle C_{eff} = C_{peak} \times \eta_{MFU}

TPU性能特征

隔壁工厂老板买来一台“珍珠机”：按钮一按，每小时能搓出十万颗完美珍珠，把全能厨师秒成渣。但珍珠机只会做珍珠，客人若要点芒果布丁，它只能干瞪眼。TPU 就是这台珍珠机——为矩阵运算而生的专用芯片。

TPU 是 Google 为神经网络矩阵运算量身定制的专用芯片，内部采用脉动阵列（Systolic Array），让数据像流水线一样流过一排排计算单元，在矩阵乘法上效率极高。它还配备了高带宽的定制内存（HBM），单位能耗和单位成本下的矩阵吞吐常常优于同代 GPU。在规整的大矩阵运算上，TPU 的优势是结构性的。

但专用性是一把双刃剑。TPU 的强项集中在规整的大矩阵乘，遇到注意力计算中的小算子、动态形状、稀疏逻辑时优势会迅速缩小；编译链路（XLA 编译器）对算子的支持也远不如 CUDA 生态丰富。TPU 的加速比随模型结构变化：矩阵占比高的稠密大模型（如标准 GPT 结构）加速明显，含大量自定义算子的模型则可能跑不出优势。

珍珠机值不值得买，取决于你的菜单是不是以珍珠为主。产品是标准 GPT 结构、批量大、算子规整，TPU 的性价比惊人；若模型天天改结构、加自定义算子，全能厨师（GPU）的灵活性反而更省钱。

S=TGPUTTPU\displaystyle S = \frac{T_{GPU}}{T_{TPU}}
加速比 = GPU 耗时 ÷ TPU 耗时。大于 1 表示 TPU 更快，小于 1 表示 GPU 更快。它不是固定值，而是随模型结构变化的“实测面试成绩”。
  1. GPU 耗时 \(T_{GPU}\)同一模型、同一批请求在 GPU 上完成推理所需的时间。
    TGPUT_{GPU}
  2. TPU 耗时 \(T_{TPU}\)完全相同的任务在 TPU 上的耗时。
    TTPUT_{TPU}
  3. 加速比 \(S\)两者相除。S 大于 1 说明 TPU 更快，小于 1 说明 GPU 更快。
    S=TGPUTTPU\displaystyle S = \frac{T_{GPU}}{T_{TPU}}

显存容量约束

设备买好了，还得租冷藏仓库。原材料（模型权重）要一直占着地方，半成品（KV 缓存）还会随订单越堆越多。仓库爆了，厨师再快也得停工。LLM 推理的“仓库”就是显存（HBM）。

显存里住着三户房客：模型权重（参数本身）、KV 缓存（注意力机制缓存的键值对）、以及激活值（中间计算结果）。权重是固定大小的“长期住户”，KV 缓存是随并发会话数增长的“流动人口”，每到高峰就暴涨。三者加起来不能超过显存容量，否则服务直接崩溃（Out of Memory）。

KV 缓存有经典估算公式：以 7B 模型、FP16 精度为例，32 层、隐藏维度 4096、序列长度 2048 时，单条请求的 KV 缓存约 1GB，16 条并发就吃掉 16GB——比 14GB 的权重还大！这就是为什么“显存够装模型”绝不等于“显存够跑服务”。

仓库规划的核心是给“流动人口”留够空间。设计容量时先算清 KV 缓存峰值，再决定批次大小和序列长度上限，否则旺季一到仓库爆仓，再贵的生产线也得停摆。

MKV=2×L×dmodel×sseq×bbatch×pbytes\displaystyle M_{KV} = 2 \times L \times d_{model} \times s_{seq} \times b_{batch} \times p_{bytes}
KV 缓存 = 2 × 层数 × 隐藏维度 × 序列长度 × 批次大小 × 每数占字节。它是显存里最会“膨胀”的住户，容量规划时必须先给它留够位置。
  1. 系数 2注意力机制要为每个 token 分别保存键 K 和值 V 两份张量。
    22
  2. 层数 \(L\)Transformer 有多少层，每层都要一份独立的 KV 缓存。
    LL
  3. 隐藏维度 \(d_{model}\)每层注意力头的隐藏尺寸，决定每个 token 缓存的宽度。
    dmodeld_{model}
  4. 序列长度 \(s_{seq}\)当前请求的序列长度，序列越长缓存越大。
    sseqs_{seq}
  5. 批次大小 \(b_{batch}\)同一批并发处理的请求数，批次越大缓存线性增长。
    bbatchb_{batch}
  6. 字节数 \(p_{bytes}\)每个数值占的字节数，FP16 为 2，INT8 为 1。
    pbytesp_{bytes}

硬件选型对比

请全能厨师还是买珍珠机？老板不比“谁更快”，而比“做一杯珍珠奶茶，谁的单位成本更低”。厨师时薪 500 元、一小时做 50 杯，每杯人工 10 元；珍珠机折旧加电费每小时 1000 元、一小时做 5000 杯，每杯只要 0.2 元。选型的本质是算单位产出的成本。

硬件选型挂在嘴边的“性价比”，落到 LLM 推理上应统一成“每产出 100 万 token 的成本”。公式很简单：用设备每小时总成本除以它每小时实际吐出的 token 数。每小时总成本要包含采购折旧（或云租赁）、电力、机房等；每小时 token 数则来自压测得到的真实吞吐，而不是理论峰值。

同代硬件里，A100/H100 更像“通用型”选手，H20 这类卡通过削弱算力、加大显存来压低价格；TPU 因为专注矩阵运算，在标准模型上每 token 成本往往更低。但选型不能只看单价：采购周期（GPU 全球缺货，TPU 通常绑定 Google 云）、生态成熟度（vLLM 等推理框架对 GPU 的优化远早于 TPU）、模型是否频繁定制，都会影响真实总成本。

老板最终会在菜单（模型结构）、客流量（吞吐需求）和账本（成本）之间找平衡。最贵的设备不一定最划算，单位产出的成本才是那本算得清的账。

Cper_token=ChourTtokens/hour\displaystyle C_{per\_token} = \frac{C_{hour}}{T_{tokens/hour}}
单位 token 成本 = 每小时设备成本 ÷ 每小时产出 token 数。把分母换成压测实测值，才能公平地对比 GPU 和 TPU 谁更划算。
  1. 每小时设备成本 \(C_{hour}\)把购机款按折旧年限分摊到每小时，加上电费、运维；云上直接取实例时价。
    ChourC_{hour}
  2. 每小时产出 token 数 \(T_{tokens/hour}\)实测吞吐乘以 3600 秒，只信压测数字，不信纸面算力。
    Ttokens/hour=Ttokens/s×3600\displaystyle T_{tokens/hour} = T_{tokens/s} \times 3600
  3. 单位 token 成本 \(C_{per\_token}\)两者相除。横向对比时再乘 100 万，得到业界通用的“每百万 token 成本”。
    Cper_token=ChourTtokens/hour\displaystyle C_{per\_token} = \frac{C_{hour}}{T_{tokens/hour}}

集群规模规划

设备选型定了，接下来是“开几条流水线”。甜品工厂算过：一条全自动产线每小时能出 1000 杯，高峰期要 5000 杯，那就得开 5 条；但万一某条线检修呢？留 20% 的备用产能更稳妥。集群规模规划就是一道除法题。

需求侧的吞吐目标（每秒 token 数）除以单卡实测吞吐，向上取整，再乘上冗余系数，就是所需的 GPU/TPU 数量。这个数字直接决定采购预算、机房面积和电力规划。真实项目里还要考虑多卡并行带来的效率损耗——8 卡分布式跑模型，实际吞吐通常不是单卡的 8 倍，而只有 7 倍左右。

扩缩容策略也在这一环节确定：是预留高峰期所需的全部设备（确定性容量），还是自建小集群做底座、高峰时向云端弹性扩容（混合容量）？前者简单但闲时浪费，后者省钱但依赖云厂商资源。SLA 要求越高、业务波动越大，越需要精细的冗余设计和自动伸缩机制。

流水线数量 = 高峰杯数 ÷ 单线产能，向上取整，再乘备用系数。少算一条，周年庆那天客人就在门口排两小时队；多算太多，闲置产线每个月光折旧就吃掉利润。

Ndevices=⌈Rtokens/sTper_device⌉×(1+Rspare)\displaystyle N_{devices} = \left\lceil \frac{R_{tokens/s}}{T_{per\_device}} \right\rceil \times (1 + R_{spare})
设备数 = 向上取整（吞吐需求 ÷ 单设备吞吐）×（1 + 冗余率）。就像“流水线数量 = 高峰杯数 ÷ 单线产能”，最后还要留出检修备用线。
  1. 吞吐需求 \(R_{tokens/s}\)第一节算出的服务总吞吐目标，代表高峰期的“峰值订单量”。
    Rtokens/sR_{tokens/s}
  2. 单设备吞吐 \(T_{per\_device}\)单张 GPU/TPU 在真实负载下实测的每秒 token 数，注意是“单卡”而非“单机”。
    Tper_deviceT_{per\_device}
  3. 向上取整 \(\lceil \cdot \rceil\)设备必须买整数台，13.4 台也要按 14 台算，这是硬件采购的物理约束。
    ⌈⋅⌉\left\lceil \cdot \right\rceil
  4. 冗余率 \(R_{spare}\)为故障、滚动更新、流量毛刺预留的额外比例，通常取 10%~30%。
    RspareR_{spare}
  5. 设备总数 \(N_{devices}\)最终下采购单的数量，这个数字直接决定后面成本估算的规模。
    Ndevices=⌈Rtokens/sTper_device⌉×(1+Rspare)\displaystyle N_{devices} = \left\lceil \frac{R_{tokens/s}}{T_{per\_device}} \right\rceil \times (1 + R_{spare})

成本估算实践

开店前最后算总账：装修费（买设备）是一次性砸下去的钱，房租水电人工（电费运维）是每个月都要流的血。甜品工厂老板把两年的账摊开，发现“买得便宜”不如“用得省”。云上算力成本也分这两本账——CAPEX 和 OPEX。

自建算力集群要付 CAPEX（资本支出）：买服务器、建机房；还要持续付 OPEX（运营支出）：电费、制冷、运维人力、维修折旧。云上则几乎是纯 OPEX，按小时租用。业界用 TCO（总拥有成本）统一衡量：把一次性投入分摊到生命周期内，再加上每月的运营费用，得到“三年一共花多少钱”。

云厂商还提供三种计费姿势：按量付费（随开随停，最贵）、预留实例（承诺使用 1~3 年，便宜 30%~60%）、Spot 抢占型（极便宜但随时可能被回收）。容量规划要结合业务确定性来组合：常驻流量用预留实例，突发流量用按量实例，离线批处理用 Spot。实践中，一个 8 卡 GPU 节点三年 TCO 通常达数百万元，选错计费模式可能多花 40% 以上。

把账本摊开，老板才明白“珍珠机虽然贵，但省下的电费和人工两年就回本”。TCO 是容量规划交出的最终答卷——买多少设备不重要，重要的是这笔钱花得值。

CTCO=CCAPEX+COPEX×Tmonths\displaystyle C_{TCO} = C_{CAPEX} + C_{OPEX} \times T_{months}
总拥有成本 = 一次性资本支出 + 每月运营支出 × 生命周期月数。它把“装修费”和“每月房租”统一到一张表上，是向老板汇报的最终数字。
  1. 资本支出 \(C_{CAPEX}\)购置硬件、机房改造等一次性投入，用自有算力才需要。
    CCAPEXC_{CAPEX}
  2. 每月运营支出 \(C_{OPEX}\)电费、制冷、带宽、运维人力或云租赁月账单，每月固定发生。
    COPEXC_{OPEX}
  3. 生命周期月数 \(T_{months}\)设备折旧周期或服务运营周期，常取 24~36 个月。
    TmonthsT_{months}
  4. 总拥有成本 \(C_{TCO}\)三者组合得到生命周期内的全部花销，是不同方案横向对比的最终指标。
    CTCO=CCAPEX+COPEX×Tmonths\displaystyle C_{TCO} = C_{CAPEX} + C_{OPEX} \times T_{months}

容量规划流程

图纸、设备、账本都齐了，还不能直接营业。懂行的老板会先搞三天“试营业”：免费发券请真实顾客来排队，观察产线会不会堵、仓库够不够放、服务员忙不忙得过来。容量规划的最后一步，就是用“试营业”验证之前的每一道算术题。

试营业在 AI 工程里叫负载测试。先用脚本模拟真实用户的请求模式（并发数、序列长度、token 速率）打向推理服务，观察延迟和吞吐的拐点。压测工具会记录 P99 延迟（99% 请求都在它以下的延迟值）、每卡吞吐、显存水位，然后与规划时的假设逐一比对：发现“实际吞吐只有预估的 70%”，就回去调模型或加设备。

完整流程是一个闭环：需求建模 → 硬件选型 → 容量计算 → 压测验证 → 上线监控 → 定期复盘。上线后监控系统持续追踪显存使用率、GPU 利用率、排队长度，水位逼近阈值就触发扩缩容；每月复盘把真实流量数据回填到需求模型，重新校准下一季度容量计划。容量规划不是一次性交付，而是持续迭代的工程惯例。

试营业那几天，老板不关心“理论产能”，只关心“真实顾客体验”。容量规划的价值不在图纸上，而在每一次真实请求的延迟数字里——用数据说话，持续修正，这才是容量规划的终局。

Pok=NwithinNtotal×100%\displaystyle P_{ok} = \frac{N_{within}}{N_{total}} \times 100\%
达标率 = 延迟达标的请求数 ÷ 总请求数 × 100%。业务 SLA 通常要求 P99 达标率在 99% 以上，这是容量是否够用的“验收标准”。
  1. 达标请求数 \(N_{within}\)压测或生产中延迟低于 SLA 阈值的请求数量。
    NwithinN_{within}
  2. 总请求数 \(N_{total}\)压测期间发出的全部请求数量。
    NtotalN_{total}
  3. 达标率 \(P_{ok}\)两者相除再乘 100%，是容量规划的“定期体检报告”。
    Pok=NwithinNtotal×100%\displaystyle P_{ok} = \frac{N_{within}}{N_{total}} \times 100\%

AI 应用场景

场景 1：创业公司上线企业客服问答 API

阶段：硬件选型与容量计算（推理服务部署前）

解决的问题：传统做法靠“感觉”买卡——先买 4 张 A100 跑起来再说，结果流量一来延迟超标，加卡又怕浪费。用本文方法先做需求测算：日活 20 万、活跃率 5%、单会话生成速度 30 token/s，算出并发与吞吐目标，再用“每百万 token 成本”对比 A10/A100/H20，最终选定 8 卡 A100 集群保底 + 云上按量扩容。

具体案例：某 SaaS 团队给 7B 客服模型做容量规划，按公式算出峰值需要 5 卡，压测却发现单卡吞吐只有预期的 80%，于是按 6 卡采购并预留 1 卡冗余。上线后 P99 延迟稳定在 SLA 内，月成本比“拍脑袋买 10 卡”省了约 40 万元。

场景 2：电商大促的弹性扩缩容

阶段：集群规模规划与扩缩容策略

解决的问题：大促流量是平时的十倍，静态集群要么扛不住、要么平时大量闲置。容量规划把集群拆成“保底容量 + 弹性容量”：常驻流量用预留实例（便宜），峰值突发用按量/Spo​​t 实例（弹性），并设置显存水位与排队长度阈值自动扩容。

具体案例：某电商智能导购在大促前用负载测试确定 60% 流量走自建 GPU 集群、40% 走云端弹性资源。大促当天监控到排队长度超阈值自动扩容 20 台实例，活动结束自动缩容，SLA 达标率 99.5%，算力成本比全量自建节省约 30%。

场景 3：FinOps 成本复盘与计费组合优化

阶段：成本估算实践

解决的问题：账单超预算时，传统做法是一刀切降配，结果服务变慢用户投诉。用 TCO 模型把集群账单拆成 CAPEX/OPEX，区分常驻与突发负载，重新组合预留实例、按量、Spot 三种计费方式，在不降 SLA 的前提下把成本压下来。

具体案例：某大模型团队月度账单超预算 40%，复盘发现 70% 的实例都在按最贵的按量付费跑。用 TCO 公式重新测算后，把 70% 常驻实例转为 1 年预留实例、离线批处理切到 Spot，三个月后账单下降 32%。

Python 演示

python44 行
"""GPU/TPU capacity planner: estimate devices and TCO for LLM serving.""" import math  def kv_cache_gb(layers, hidden_dim, seq_len, batch, bytes_per=2):    """Estimate KV cache memory in GB."""    raw = 2 * layers * hidden_dim * seq_len * batch * bytes_per    return raw / (1024 ** 3)  def weights_gb(params_b, bytes_per=2):    """Estimate model weights memory in GB."""    return params_b * bytes_per / (1024 ** 3)  def device_count(tokens_per_s, per_device, spare=0.2):    """Compute how many devices needed with spare ratio."""    base = math.ceil(tokens_per_s / per_device)    return math.ceil(base * (1 + spare))  def tco_total(capex, opex_monthly, months):    """Total cost of ownership over life cycle."""    return capex + opex_monthly * months  def main():    tokens_per_s = 5000          # business throughput target    per_device = 800             # measured tokens/s per GPU    n = device_count(tokens_per_s, per_device, spare=0.25)    print("device count:", n)     kv = kv_cache_gb(layers=32, hidden_dim=4096, seq_len=2048, batch=16)    w = weights_gb(params_b=7e9)    print("weights GB: %.1f, kv cache GB: %.1f" % (w, kv))     capex = n * 160000           # CNY per A100    tco = tco_total(capex, n * 9000, 36)    print("36-month TCO (10k CNY): %.0f" % (tco / 10000))  if __name__ == "__main__":    main()
目的：一个可直接运行的容量规划计算器，输入吞吐需求、单卡实测吞吐与模型结构，输出所需设备数、KV 缓存占用与三年总拥有成本。
  1. raw = 2 * layers * hidden_dim * seq_len * batch * bytes_per复现 KV Cache 显存公式，算出“流动人口”占多大仓库。
  2. return raw / (1024 ** 3)把字节数换算成直观的 GB。
  3. base = math.ceil(tokens_per_s / per_device)设备必须买整数台，向上取整。
  4. return math.ceil(base * (1 + spare))在基础数量上追加冗余比例，对应“备用产线”。
  5. n = device_count(tokens_per_s, per_device, spare=0.25)5000 token/s 需求、单卡 800、冗余 25%，算出 9 卡。
  6. tco = tco_total(capex, n * 9000, 36)用 36 个月生命周期汇总总拥有成本，方便对比方案。

常见误区

误区我的 7B 模型 FP16 只要 14GB，买一张 16GB 显存的卡不就行了吗？结果一上线就内存溢出（OOM），很疑惑。

正解显存里住着三户房客：权重、KV 缓存、激活值。14GB 权重只是“长期住户”，并发一高，KV 缓存这个“流动人口”瞬间挤爆仓库。正确做法是用 \(M_{KV} = 2Ldsbp\) 公式把三部分都算进去，再决定批次和序列长度上限。

为何常见：训练场景显存占用以权重为主，新手把训练经验直接搬到推理，忽略了推理特有的 KV 缓存会随并发线性增长。

误区网上都说 TPU 算得快，那就全上 TPU。结果模型跑起来延迟比 GPU 还高，而且很多算子根本编译不过去。

正解TPU 只在规整的大矩阵运算上有结构性优势。模型含自定义算子、动态形状时，编译开销和算子不兼容会吃掉优势。加速比必须用同一模型、同一批请求实测，不能靠“听说”。

为何常见：厂商宣传和评测都在最理想模型下进行，且 TPU 生态门槛高，非 Google 系团队容易在算子适配阶段踩坑。

误区预算充足，直接上最贵的 H100，性能最强肯定不会错，省得以后后悔。

正解最贵不等于性价比最高。如果瓶颈在显存带宽或小批次延迟，便宜但显存更大的 H20 可能更合适。选型应该比“每百万 token 成本”，而不是比单卡标价；还要把采购周期和生态成熟度算进去。

为何常见：把“性能”简单等同于“单价”，忽略了推理场景的真实瓶颈是显存带宽和容量，而非单纯峰值算力。

误区日活 100 万，那每秒请求就是 100 万？按这个量买卡，预算直接爆表。

正解并发会话数（同一时刻在跑的请求数）与每秒请求数是两个概念，中间隔着活跃率、思考时间、生成时长三重折减。100 万日活经活跃率折减后可能只剩几千并发，两者相差两个数量级。

为何常见：混淆了“注册用户/日活”与“系统并发”两种视角，忽略了概率和时间这两个天然的“减速带”。

误区上线前算好买多少张卡，以后就不用管了。结果三个月后流量涨了一倍，系统天天报警，只能临时加急采购。

正解容量规划是持续迭代的闭环：上线后监控真实水位，每月复盘把流量数据回填需求模型，按业务增长节奏滚动调整。流量、模型、硬件都在变，规划就必须跟着变。

为何常见：把容量规划当成一次性工程项目，没意识到它是和业务一起演化的长期运营活动。

面试题

Q1. KV Cache 容量公式中的系数"2"代表什么？

单选题 · easy

  • A.需要分别缓存键 K 与值 V 两份← 正确答案
  • B.每个浮点数在 FP16 下占两个字节
  • C.Transformer 的注意力机制包含两层
  • D.模型权重需要保留主副本与备份

答案：A。公式 \(2Ldsbp\) 中的 2 表示每个 token 都要同时缓存注意力计算所需的键 K 和值 V 两份张量；L 代表层数，d 代表隐藏维度，p 是精度字节数。选 B 的同学把"2"和张量字节数搞混了——那是 p 的职责。

Q2. 进行显存总量估算时，必须计入哪三个部分？

单选题 · easy

  • A.模型权重、KV 缓存、激活内存← 正确答案
  • B.模型权重、训练日志、网络缓存
  • C.KV 缓存、操作系统、磁盘空间
  • D.激活内存、浏览器缓存、驱动程序

答案：A。显存里住着三户房客：权重（长期住户）、KV 缓存（随并发增长的流动人口）、激活值（中间结果）。训练日志、磁盘空间、浏览器缓存都不属于推理显存，选错说明没分清“仓库”里到底放了什么。

Q3. 一份完整的 LLM 推理容量规划，需求侧需要哪些输入？

多选题 · mid

  • A.高峰期的并发会话数量← 正确答案
  • B.平均和最大生成长度← 正确答案
  • C.模型的层数与隐藏维度← 正确答案
  • D.办公区工位的大小尺寸

答案：ABC。并发会话数决定“同时供着多少人”，生成长度影响 KV 缓存与单请求耗时，模型的层数与隐藏维度直接代入 KV 公式。工位尺寸与算力容量无关，属于干扰项。

Q4. 哪种负载形态最适合发挥 TPU 的优势？

单选题 · mid

  • A.规整大矩阵乘的批量推理← 正确答案
  • B.频繁动态分支的自定义算子
  • C.稀疏且形状不规则的图算法
  • D.依赖大量 CUDA 扩展的模型

答案：A。TPU 的脉动阵列专为规整的大矩阵乘设计，稠密 Transformer 的批量推理是它的主场。动态分支、稀疏不规则形状、CUDA 专属扩展恰恰是 TPU 的短板。加速比要用实测说话，不能想当然。

Q5. 某服务需求 5000 tokens/s，单卡实测 800 tokens/s，冗余率 25%，需要几张卡？

单选题 · mid

  • A.需求量较大，约需要 7 张
  • B.需求量较大，约需要 8 张
  • C.需求量较大，约需要 9 张← 正确答案
  • D.需求量较大，约需要 10 张

答案：C。先算 5000 ÷ 800 = 6.25，向上取整得 7；再乘冗余系数 1.25 得 8.75，再次向上取整得 9 张。这道题考察两个取整动作，少做一步都会选错。

Q6. 关于 MFU（模型浮点利用率），下列说法正确的是？

单选题 · hard

  • A.反映实际算力占峰值算力的比例← 正确答案
  • B.反映显存带宽的实际占用比例
  • C.反映网络传输中的拥塞比例
  • D.反映服务请求的失败比例

答案：A。MFU 衡量真实运行中算力被有效利用的比例，LLM 推理的 MFU 通常只有 10%~30%，因为瓶颈常在显存带宽而非算力。它不直接衡量带宽、网络或失败率，选 B 的同学可能把“带宽瓶颈”和“带宽占用率”混为一谈了。

Q7. 推理时 KV Cache 过大导致显存溢出，可以采取哪些措施？

多选题 · hard

  • A.减小推理的批次大小← 正确答案
  • B.对 KV 缓存做量化压缩← 正确答案
  • C.限制最大序列长度← 正确答案
  • D.增加模型的层数参数

答案：ABC。KV 缓存与批次、序列长度、精度字节数线性相关，减小批次、限制序列长度、量化压缩都能直接释放显存。增加层数只会让权重和 KV 双双变大，是反向操作。

Q8. 以下哪一项属于容量规划中的运营支出（OPEX）？

单选题 · mid

  • A.按月支付的云服务器租用费用← 正确答案
  • B.一次性购置自建服务器的费用
  • C.机房建设的一次性改造费用
  • D.采购团队的差旅和招待费用

答案：A。OPEX 是按月发生的持续性支出，云租用费最典型；一次性购置和机房改造属于 CAPEX。采购差旅虽然也是花销，但不属于算力容量规划的运营成本科目。

Q9. FP16 精度下，一个模型参数在显存中约占几个字节？

单选题 · easy

  • A.约占 1 个字节
  • B.约占 2 个字节← 正确答案
  • C.约占 4 个字节
  • D.约占 8 个字节

答案：B。FP16 即半精度浮点数，每个数值占 2 字节；1 字节是 INT8，4 字节是 FP32，8 字节是 FP64。这一数字直接代入 KV 公式的 \(p_{bytes}\)，也用于权重显存估算。

Q10. 容量规划的正确工作流程包含哪些环节？

多选题 · mid

  • A.需求建模与负载压测← 正确答案
  • B.成本估算与选型决策← 正确答案
  • C.上线监控与定期调优← 正确答案
  • D.仅在故障后被动扩容

答案：ABC。容量规划是“需求建模→选型计算→压测验证→上线监控→复盘调优”的闭环，讲究提前布局与持续迭代。故障后被动扩容是典型的“消防式运维”，既容易超预算又损害 SLA。