Rubin 及后续产品的 HBM 层数调整：从证据可信度到长上下文 Agent 部署与 TCO#
核心判断#
已有报告支持 NVIDIA 正在评估或增加采用较低层数 HBM，但不能据此认定标准 Rubin、Rubin Ultra 及所有后续产品均已固定改为 8 层。 标准 Rubin 已公布资料仍提供 288 GB HBM4、12-Hi 的基准；供应链线索涉及不同型号、配置方案和时间，必须分别解释。
HBM 减配首先收紧容量边界，生产影响取决于模型加载后的缓存余量。 软件兼容、模型能启动、满足上下文与并发要求，是三个不同门槛。在本文的 72 卡、4 卡模型组、64K 请求情景中，单卡 HBM 从 288 GB 降至 192 GB，理论缓存驻留容量从 666 降至 378，下降约 43.2%；这是容量模型结果，不能视为实测吞吐损失。
GPU 分组和缓存分层能缓解部分影响，补偿程度取决于实际布局和访问模式。 扩大模型组可减少重复权重，但会减少独立副本并增加通信；部分 MLA 部署还存在 KV 复制。长上下文 Agent 的关键风险是热缓存不足、下一轮恢复变慢，以及重算、排队和重试增加。容量下降本身不必然改变回答质量，适配所采用的截断、摘要或量化才可能改变任务效果。
对 Agent，核心经济指标是每次有效完成任务的成本。 假设完整系统每小时成本下降 5%，而同等质量与时限下的有效任务吞吐下降 20%，单位任务成本上升约 18.8%。当前缺少 Rubin 高低容量配置的同条件公开对照，以及客户真实价格、轨迹和功耗，不能给出行业通用的 TCO 涨幅。
下文依次回答：变化是否成立、改变了哪些资源、如何传导到 GPU 组和 Agent 服务、最终如何衡量经济性。
一、产品变化的证据：确认的是配置线索，尚未确认全线定案#
1.1 已公布规格与供应链证据#
| 研究模块 | 证据充分度 | 能支持的结论与边界 |
|---|---|---|
| 标准 Rubin 已公布规格 | G3，限公开规格核验 | NVIDIA 文档列出最高 288GB HBM4、12-Hi、22TB/s；不等于所有未来 SKU 都相同 |
| 8 层方案的采用与调整方向 | G2 | 有具名机构研究、记者供应链采访和本地券商原文；最终型号、占比、带宽与售价尚不完整 |
| 实际客户吞吐与单位成本 | G1 | 有成熟机制和框架文档，但缺少同模型、同负载、同服务标准的产品对照实测 |
| 报告中的数量示例 | 假设情景，计算已复核 | 可复算公式后果；不能用计算通过代替实际产品证据 |
模型配置与容量计算属于 G2：配置和权重索引可核验，但运行时开销与分片效率采用假设，未执行 GPU 实机测试。
G0–G3 表示证据对特定问题的充分程度。G3 公开规格核验不意味着客户 TCO、性能或预测准确性已经验证。
原报告保留的主要信息如下。可信度是定性判断，没有采用未经校准的概率。
| 来源 | 实际支持的主张 | 评价与限制 |
|---|---|---|
| NVIDIA，2026 年 7 月 21 日 Rubin 架构文档 | 标准 Rubin 最高 288GB HBM4、12-Hi、22TB/s | 官方公开规格，作为已公布配置的基准。[原文][nv-rubin] |
| TrendForce，2026 年 8 月 4 日 | Rubin Ultra 扩展评估 8-Hi HBM4e、12-Hi HBM4、8-Hi HBM4，最终规格未定 | 对“评估降层数”可信度中高；不能据此宣称全线已定案。 |
| Morgan Stanley，2026 年 8 月 10 日，第 1 页 | 预测 Rubin Ultra 分多个 SKU：高端 HBM4e 8Hi，较低配置 HBM4 12Hi 或 8Hi | 使用供应链调查和预测措辞；对方向可信度中高，对最终配置仍保留条件。 |
| J.P. Morgan，2026 年 8 月 9 日，第 18 页 | 讨论 Ultra 轻量版采用 8-Hi HBM4E；图 32 列出 Rubin 的 192GB 8-Hi 与 288GB 12-Hi 两种情景 | 图表注明分析师估计；正文与图表有一处层数不一致，具体数值可信度应下调。 |
| ZDNet Korea，2026 年 8 月 26 日 | 援引业内人士，报道三星与 SK 海力士计划提高对 NVIDIA 的 8 层 HBM4 供货占比，并讨论 8 层 HBM4E | 是进一步的供货线索，可信度中高；消息源匿名，具体 SKU 和实际出货占比未披露。 |
摩根大通第 18 页正文将 Rubin 较低配置写为“192GB 12-Hi HBM4”，同页图 32 则写为“8-Hi 24GB HBM4 × 8”。9 月 6 日原报告已核对 PDF 页面，记录了这一内部不一致；可能是笔误，不能当成 NVIDIA 确认。报告对 Ultra 所假设的堆栈数量也不应与其他来源的方案静默拼接。
国金证券 2026 年 8 月 9 日《第三次谈 Vera Rubin》第 6 页转引 SemiAnalysis，讨论 12-Hi、288GB 向 8-Hi、192GB 调整。这属于转引证据，不能额外计为一次独立供应链验证。本研究未取得 SemiAnalysis 对应付费模型全文。
多篇报道可能共享供应链消息，方向一致不能自动视为多次独立验证。应将“存在较低层数方案”的判断与“最终型号、比例和参数已确定”的判断分开。
对 Feynman 及更后续产品，原报告检索未找到足以确认固定采用 8 层的证据。NVIDIA GTC 2026 路线图中的 Die Stacking、Custom HBM 不能直接转换成 DRAM 层数结论。
1.2 层数、堆栈数量、容量和带宽分别决定什么#
8-Hi／8-high 指单个 HBM 堆栈内的 8 层 DRAM，通常不把底部逻辑 die 算作第九层 DRAM；“8 个 HBM 堆栈”则指 GPU 封装内有 8 个这样的内存堆栈。两者不能混用。
为解释容量关系，可写为：
$$ H=S\times L\times D/8 $$其中，\(H\) 是十进制 GB 容量，\(S\) 是堆栈数量，\(L\) 是每堆栈 DRAM 层数，\(D\) 是每层容量，单位 Gb。Gb 为 gigabit，GB 为 gigabyte，8 bit 等于 1 byte。
假设保持 8 个堆栈、每层 24Gb 不变：
- 12 层：\(8\times12\times24/8=288\text{GB}\)。
- 8 层：\(8\times8\times24/8=192\text{GB}\)。
**12 层变 8 层并不单独决定带宽变化。**外部峰值带宽可近似拆为堆栈数量、每堆栈接口宽度和引脚传输速率的乘积；层数没有以简单比例直接出现在该式中。减少层数后能否保持速率、功耗和实效带宽，仍需要供应商及系统验证。美光 HBM4 产品资料将 2048 位接口、引脚速率和每堆栈带宽分别列出，也体现了这些指标的区别。
本报告的主体采用 288GB → 192GB、容量减少三分之一 的控制变量情景：算力、HBM 带宽、互联和软件支持暂时不变。若实际方案同时改变 HBM4E/HBM4 代际、引脚速率、堆栈数量或计算 die 数，则必须重新测算。384GB → 192GB 或早期路线图中的其他容量变化，属于不同基准，不与本情景混算。
二、从物理容量到客户适配：先区分三道门槛#
2.1 软件兼容、容量可行、生产可行是三个门槛#
**同一个模型在两种 GPU 上都能启动，不代表两种配置同样适合生产。**客户需要同时确认三个层次：
| 层次 | 需要回答的问题 | HBM 容量减少的主要影响 |
|---|---|---|
| 软件兼容 | 框架支持模型结构、算子、权重格式和数值精度吗？ | 单纯改变 HBM 层数通常不改变这些能力；运行时仍需匹配实际 GPU 和内核 |
| 容量可行 | 权重、临时空间及至少一个有效请求能否装下？ | 可能需要更多 GPU、量化或数据卸载 |
| 生产可行 | 指定上下文、并发、延迟及任务质量能否同时满足？ | 模型即使能加载，也可能降低服务容量、增加排队或提高成本 |
这里的“适配”主要是重新选择部署参数和资源配置，一般不要求仅因 HBM 层数下降就重新训练模型。但如果不得不换模型、改变精度或削减上下文，验收标准就会涉及任务效果。
2.2 沿着一次真实请求看内存的作用#
一个简化的推理请求会依次经历：
用户提交输入
↓
排队与调度
↓
Prefill：处理输入，建立缓存和中间状态
↓
Decode：逐步生成输出，并更新缓存
↓
完成并释放活跃状态，或保留可复用前缀
HBM 主要承担模型权重、活跃请求的 KV cache、激活与工作空间等。权重通常在一个模型副本内部由请求共享；不同请求通常需要各自的状态，公共前缀共享可以减少部分重复占用。
因此，增加用户数量通常不会为每位用户完整复制一份模型，却会增加需要同时保存的请求状态。更长输入、更长输出、多轮任务和更高并发，都可能扩大活跃状态需求。
**模型标称的最大上下文是模型能力的一项上限，硬件容量决定客户能在什么并发下使用这一上限。**某个模型支持 128K 上下文，不意味着一套设备能同时为大量用户提供 128K 服务。生产调度还应为输出继续增长留空间，不能只检查请求刚进入系统时是否装得下。
2.3 层数更多，收益会不会非线性增加#
在堆栈数量和单层密度不变时，容量随 DRAM 层数线性增加。即使暂不考虑成本、良率、散热和技术障碍，也不能进一步推出服务价值的边际收益一直递增。
当增加的容量使模型从“装不下”变成“装得下”，或让原本需要跨节点的工作集留在本地时，收益可能出现跳跃。继续增加后，如果系统已经受算力、带宽、延迟或需求量约束，额外容量的收益则可能很小。因此，更准确的理解是：容量的物理增量近似线性，业务收益具有门槛，并随当前瓶颈变化。
三、GPU 组的容量模型：以 72 卡、长上下文部署为主案例#
3.1 统一容量口径#
设集群有 N 个 GPU，每个模型副本使用 g 个 GPU；单卡容量为 H，纳入部署的比例为 u，每卡非权重、非 KV 运行空间为 O，每组共享的模型权重总量为 W。在权重和 KV 均匀分片、没有额外复制时：
$$ K(g,H)=g(uH-O)-W, \qquad B_{\mathrm{cap}}=\max\left(0,\left\lfloor\frac{K(g,H)}{k(T)}\right\rfloor\right). $$K 是每组可用于 KV 的容量，k(T) 是一个总驻留长度为 T 的请求所需 KV，B_cap 是给定预算下的驻留数量上限。如果权重和运行时自身已超出预算，模型副本便不可按此布局驻留。组内最紧张 GPU 仍需单独检查；汇总容量充足只是必要条件。
对常规 GQA，单请求 KV 可近似为：
$$ k(T)=2\times L_a\times n_{KV}\times d_h\times b\times T. $$L_a 是注意力层数，n_KV 是 KV 头数，d_h 是每头维度，b 是每元素字节数；前面的 2 对应 K 与 V，结果为 byte。这里的模型层数与 HBM 物理层数无关，也不能用查询头数代替 KV 头数。不同长度请求应逐个累加，再扣除可共享前缀；MLA、滑动窗口和其他状态结构需要另用相应公式。
3.2 用公开模型结构计算，而非假定所有大模型占用相同#
用 Qwen2.5-72B-Instruct 作为 GQA 架构的计算案例，目的在于展示容量机制，并非推荐客户改用这一模型。其官方配置为 80 层、8 个 KV heads、每头维度 128；BF16 KV 按每元素 2 字节计算，每个驻留 token 的 KV 为：
$$ b_{KV}=2\times80\times8\times128\times2=327,680\ \text{bytes}. $$64K 即 65,536 个驻留 token，对应约 21.47 GB KV。权重索引给出的张量字节数约 145.41 GB；实际 GPU 加载占用还受框架、复制和分配方式影响。这里 GB 统一为十进制，避免与 GiB 混用。官方配置、官方权重索引
特别注意：该配置原生长度为 32,768，64K/128K 情景需要采用模型官方说明的 YaRN 扩展，两种容量使用相同配置并检验长上下文质量。下表中的长度是输入加已生成内容的总驻留长度；若输入已达 64K，还需另计随后输出。官方长上下文说明
计算假设：72 张卡，每组加载一份 BF16 模型；将显存的 90% 纳入部署预算，再为每张卡扣除 20 GB 非权重、非 KV 运行空间；在 2/4/8 卡组内均匀切分权重和 KV；不计跨会话前缀共享、缓存卸载或 KV 量化。10% 预留与 20 GB 用于不同用途，均为情景参数，真实部署应以框架实测替换。
代入本节模型与预算参数，可得下表。表中采用完整字节数计算，正文展示值经过四舍五入。
| 每模型 GPU 组 | 72 卡中的组数 | 288 GB：每组 64K 会话 | 192 GB：每组 64K 会话 | 72 卡驻留容量变化 |
|---|---|---|---|---|
| 2 卡 | 36 | 15 | 7 | 540→252，下降 53.3% |
| 4 卡 | 18 | 37 | 21 | 666→378，下降 43.2% |
| 8 卡 | 9 | 82 | 50 | 738→450，下降 39.0% |
这些是给定预算下的理论驻留上限，尚未施加算力、带宽及延迟约束，实际可服务并发可能更低。因此不能将下降 43.2% 直接写成请求吞吐下降 43.2%，也不能将倒数直接当作 TCO。
4 卡组中，KV 池由约 811.39 GB 降至 465.79 GB。原系统在高峰时若需常驻的 KV 超过旧池的 57.4%，减配后便无法原样全部驻留。这个门槛比“显存下降三分之一”更能提示迁移风险。
这里应观察的是活跃请求及需要保留的高价值缓存，而非简单的显存占用百分比。缓存框架可能用闲置空间保存可淘汰数据，显示接近满载并不等于已经无法接收新请求。反之，即使日均低于门槛，长请求扎堆和任务同时恢复仍可能触发高峰不足。均匀分片假设也可能被单卡热点、碎片和额外缓冲打破。
3.3 扩大 GPU 组能缓解多少#
在上述模型中，低容量系统由 4 卡组改成 8 卡组，72 卡驻留容量从 378 增至 450，提升约 19%。原因是模型副本数量减少，释放了一部分权重空间；并未增加物理 HBM。
但高容量系统也能使用 8 卡组，其容量为 738。公平比较同为 8 卡组，减配损失仍约 39%。只比较“旧系统未优化”和“新系统优化后”，会高估软件对减配的补偿。
更大的组还涉及单次请求的通信和同步开销，以及模型副本变少的调度影响。应以整个集群在相同服务要求下完成多少任务评估；单组更快，未必代表整柜吞吐更高。72 张变成 144 张，在相同布局及负载比例下只是两边规模一起扩大，不会让容量缺口比例自行消失。
跨柜扩大资源池同样需要明确拓扑。NVLink 扩展域及机柜间网络不是无成本的共享显存；需要数据放置、分片和调度支持，还可能付出恢复流量及同步延迟。不能把多柜总 HBM 当成每个 GPU 都能按本地 HBM 速度访问的空间。
从驻留容量进一步走到服务能力，还需加入每组的有效吞吐。若各组独立、配置相同且 N 可被 g 整除，则：
$$ Q_{\mathrm{cluster}}(g)=\frac{N}{g}\,q(g), $$q(g) 是该组在指定质量与时限下每小时完成的任务数。如果组规模翻倍，副本数减半，单组吞吐就需要翻倍才能保持集群吞吐不变。这个关系解释了为什么“一个更大的组容纳更多会话”仍不足以证明整柜经济性改善。
四、模型架构和局部热点：为什么总 HBM 不能直接相加#
4.1 MLA 的缓存复制与序列分片#
上面的 GQA 例子利用了 8 个 KV heads 的可分片性。对于 MLA，不能机械沿用同一公式。vLLM 的纯张量并行实现中，压缩后的 latent KV 可能在各卡复制；Decode Context Parallelism（DCP）则按序列位置切分缓存。框架和后端不同，实际布局需要确认。vLLM 开发者说明与基准
仅按 DeepSeek-R1 配置估算，BF16 压缩 KV 每 token 为 61×(512+64)×2＝70,272 字节。64K 请求的唯一 KV 约 4.61 GB；若在 8 个 TP ranks 完整复制，组内物理占用约 36.84 GB，理想 DCP8 分片后约 4.61 GB。这里没有再乘常规 K/V 的系数 2，因为 latent 与 rope 的结构已经体现在公式里；也未计块、量化尺度和额外缓冲。官方配置
这说明模型架构和缓存布局可能比简单增加组内卡数更重要。它不意味着 DCP 可以免费提速 8 倍，也不意味着所有部署都有如此大的可消除冗余。
有相关公开测量：vLLM 在 8×B200、Kimi K2.6 NVFP4 的 Agent 轨迹基准中，报告纯 TP 在并发 64 时 KV 满载、吞吐平台约 1,863 tok/s/GPU；DCP 在并发 512 时达到 6,091 tok/s/GPU，KV 使用率约 82%。这是开发者报告的特定基准，说明缓存布局能够实质改变规模上限；两组数字并发不同，不能称为同一生产 SLO 下的 3.27 倍有效吞吐或 TCO 改善，也不是 Rubin 容量减配对照。基准原文
4.2 MoE 与多模型平台还存在局部容量约束#
MoE 每个 token 只调用部分专家，可以减少活跃计算；全部专家权重仍需存放在某处。常规低延迟部署通常让它们分布在 GPU 内存中，选择按需加载则会引入另一组缓存命中和传输条件。活跃参数量不能直接替代驻留权重总量。[Hugging Face MoE 说明][moe]
在多 GPU 部署中，应逐颗核对容量和路由负载。整柜 HBM 的总和不能证明热点专家所在的 GPU 仍有足够缓存，也不能证明专家通信不会成为瓶颈。
对托管多个模型或多个副本的平台，HBM 减少还可能降低常驻密度，引入模型装载和切换等待。即使某个单模型 benchmark 不变，平台层的资源碎片、可售服务组合和冗余能力也可能改变。这些属于客户业务结构的影响，需要实际请求与模型组合验证。
五、长上下文、多轮 Agent：从会话驻留到恢复与重算#
5.1 一个任务会跨越多次模型调用#
一个 Agent 任务可能多次调用模型，中间等待搜索、代码执行或其他工具。每轮除了少量新增信息，还可能重新使用较长历史。HBM 因此同时承载正在生成的请求和具有未来复用价值的缓存。
容量缩小后，系统可能减少驻留会话、移出暂停任务的缓存、增加重算，或者改变 GPU 分组。不同选择会将压力传导到恢复时间、排队或成本。
必须分清三种数量：在线会话数、正在进行模型调用的请求数、其 KV cache 驻留于 HBM 的会话数。Agent 等工具时可以不占用计算，但继续占用缓存；也可以释放 HBM，并在下一轮恢复。因而“可驻留会话容量”不能直接叫“每秒可处理请求数”。
5.2 缓存不足如何转化成任务成本#
Agent 等待工具时，将 KV 移到 CPU 或其他缓存层可能是合理选择。决定影响的条件包括：等待时长、下一轮恢复概率、恢复带宽、同时恢复任务数，以及恢复能否与工具执行重叠。因此，生产上不一定需要把所有会话历史永久留在 HBM。
但是，HBM 减少会压缩可以快速复用的热缓存集合。当工作集超出该集合，成本可能沿三条路径上升：从低层存储恢复缓存产生传输；所有层都未命中时重新做 prefill；排队、超时和重试增加完成一个任务所需的资源。是否发生以及发生多大，取决于实际复用距离和分层策略。
一个明确标为假设的例子：每轮复用 64K 历史、新增 1K 内容。如果所有缓存层合计可复用的历史 token 比例从 90% 降到 70%，则未缓存输入 token 的工作量代理由：
$$ 1K+10\%\times64K=7.4K \quad\longrightarrow\quad 1K+30\%\times64K=20.2K, $$增至约 2.73 倍。这只表示需要重新处理的输入 token 数，不代表 prefill FLOPs、耗时、整任务成本也恰好增长 2.73 倍。如果仅从 HBM 未命中变成 CPU 命中，额外工作主要是恢复传输，不能按全部重算计。
上述传输和重算讨论以完整保留上下文为前提；如果改用截断或压缩适配，还需按第六节重新验收任务质量。
即使正在生成的请求保持相近的逐 token 速度，尚未获得执行位置的请求也可能排队更久。减少可驻留请求数还可能缩小有效批量，使权重读取和计算开销更难摊薄；如果减配后批量仍足够使系统饱和，吞吐损失则可能较小。缓存紧张时的抢占和重算是另一条性能损失路径。[vLLM 调优文档][vllm-opt]
5.3 CPU 内存、远端缓存和更快互联的补偿条件#
NVIDIA Dynamo 提供将 KV 迁往 CPU 内存和其他存储层的工程路径。低频复用、暂不活跃的数据适合分层管理；每步生成都需要访问的数据，对迁移和预取的要求更高。
一次传输的简单下界为：
$$ t_{\mathrm{transfer}}\geq V/B_{\mathrm{effective}}, $$V 为移动字节数，B_effective 为端到端有效单向带宽。实际还包含启动、排队、协议和同步开销；能被工具等待或其他计算覆盖的部分，对任务关键路径影响可以较小。HBM 带宽和网络标称双向汇总带宽不能直接比较。
更快的 scale-up 网络可以降低分片和专家路由代价；scale-out 网络可以改善跨节点通信和部分缓存迁移。收益取决于请求是否真正使用该路径。CPO、NPO 或可插拔光模块影响传输距离、带宽密度、功耗和维护，但不直接增加本地 HBM，也不能将“地址可访问”视为“访问代价等同本地”。
如果 CPU 内存也减少，缓解 HBM 压力的第二级缓存可能同时收缩。这只能作为独立联合压力情景验证，不能把不同产品或时间的消息拼成一个已确认配置。本报告也未把未经确认的光学升级计为确定成本收益。
六、客户的适配选择：保留哪些服务条件，付出什么代价#
**应先判断必须保住的是任务质量、上下文、响应速度还是服务容量，再选择适配方式。**这些要求可能无法在同一设备预算内全部保留。
| 适配方式 | 主要保留的能力 | 需要重新验证的代价 |
|---|---|---|
| 减少同时执行的请求 | 原模型、精度及单请求长度 | 排队、峰值接待能力、尾部延迟 |
| 缩短输入或输出上限 | 原模型、部分服务容量 | 长文档、代码库和多轮任务效果 |
| 增加 GPU 并重新分片 | 原模型和精度、更多合计容量 | 设备数、互联、同步、每 GPU 占用及副本吞吐 |
| 量化权重或 KV | 更低驻留占用 | 下游任务质量、数值误差、内核支持和性能 |
| 优化缓存分页和前缀复用 | 减少碎片和重复状态 | 实际命中率、可节省空间、调度开销 |
| 将数据迁往 CPU 内存或存储 | 更大逻辑数据容量 | 搬运与预取是否足够快，是否触发重算和超时 |
**容量减少本身不会让同样的模型权重失去知识。**如果保持输入、权重、精度及等价计算，模型能力不会仅因 HBM 层数变化而系统性下降；硬件和并行顺序变化仍可能造成微小数值差异。真正可能改变效果的是随后采取的量化、截断、模型替换等措施。NVIDIA 精度文档明确说明量化存在舍入和截断误差，因此不能默认所有任务质量不变。
更节省状态的模型架构能够缓解容量问题，但客户通常不能把现有全注意力模型通过一个部署开关变成 MLA 或线性注意力模型。更换架构往往涉及不同权重和训练过程，必须重新验证任务能力。
训练及微调还包含梯度、优化器状态、保存的激活等额外占用，受到 batch、梯度累积、重计算和分片策略共同影响。上述推理缓存算例不能直接用于估算训练速度或成本。
七、生产指标与 TCO：以有效完成任务衡量产出#
7.1 从设备指标连接到业务指标#
| 指标 | 生产口径 | 主要回答的问题 |
|---|---|---|
| 有效任务吞吐 Goodput | 单位时间内，质量合格且在任务时限内完成的独立任务数；重试不另算成功任务 | 集群实际交付能力是否下降 |
| 每成功任务成本 | 观察窗口完整成本÷该窗口内有效完成任务数，处理跨窗口任务归属 | 成本是否真的下降 |
| 每任务 GPU 秒、kWh | 包含失败、重试、重算和空转分摊 | 设备看似忙碌是否创造有效产出 |
| p95/p99 任务耗时 | 包含排队、工具等待和各轮推理，同时分解各项 | 多轮体验与超时风险 |
| 首 token / 恢复首 token 延迟 | 从请求到达服务端开始计，包含排队；冷启动、热缓存、恢复分别统计 | 减配是否拖慢新请求或下一轮恢复 |
| 平均输出 token 耗时 TPOT、逐 token 间隔 ITL | 分别记录请求平均值与逐 token 间隔分布，并按上下文长度、并发分档 | 流式响应速度能否满足要求 |
| 峰值活跃 KV 与热缓存字节 | 按最紧张 GPU 和组分布，区分可淘汰缓存 | 是否接近容量门槛 |
| 分层缓存命中与恢复 | token/字节加权命中率、HBM/CPU/其他层来源、恢复时间与流量 | 容量缺口由传输还是重算承担 |
| 重算、抢占、超时、重试率 | 每千次模型调用及每成功任务两种口径 | 缓存压力是否转化成浪费 |
| 任务成功率与质量 | 固定任务集、工具、模型和评价标准；上下文长度分别统计 | “适配”是否牺牲业务能力 |
推理框架可提供 TTFT、排队时间和抢占等基础观测，但 Agent 任务级成功、工具等待及重试归因需要应用层补充。对长尾负载，除总体均值外，应按 32K、64K、128K 等长度档和冷/热缓存分别统计。vLLM 指标文档
原始输出 tokens/s 和每百万输出 token 成本仍适合诊断模型服务效率，但比较时要固定模型、tokenizer、质量、输入输出长度及延迟要求，并包含输入处理的成本。Agent 跨多轮调用、工具和重试，因而以有效完成任务为主口径；不能用输出更多 token 代替完成更多有用任务。
7.2 固定集群规模：成本节省必须覆盖有效吞吐损失#
令 C 为相同规模集群每小时完整成本，Q 为该集群每小时在固定质量与时限内完成的任务数：
$$ \text{单位有效任务成本}=C/Q. $$完整成本口径包括硬件折旧或租赁、CPU/网络/缓存存储、软件与维护、电力和制冷等。自有硬件可用年化资本成本或折旧口径，但不要将购买额和完整折旧重复计入；云租赁也不应再加上已经包含在租金中的项目。失败、重试等资源消耗留在成本内，有效任务分母只计一次。
若完整每小时成本降低 s，有效任务吞吐降低 d，则：
$$ \frac{\text{减配后单位成本}}{\text{原单位成本}}=\frac{1-s}{1-d}. $$这里 d 已包含质量不合格和超时造成的有效产出损失，不能再重复乘一个成功率惩罚。如果使用的是原始调用吞吐，则必须另外校正任务成功、轮数和重试。
下表假设完整集群每小时成本下降 5%。这不是 Rubin 报价，也不是对吞吐损失的预测：
| 有效任务吞吐下降 | 单位有效任务成本变化 | 恢复原产出所需的设备规模增幅* |
|---|---|---|
| 0% | −5.0% | 0% |
| 5% | 0% | +5.3% |
| 10% | +5.6% | +11.1% |
| 15% | +11.8% | +17.6% |
| 20% | +18.8% | +25.0% |
| 30% | +35.7% | +42.9% |
| 40% | +58.3% | +66.7% |
*设备规模增幅使用 1/(1−d)−1，假设可线性扩容且负载可分发。真实系统需要按整组、整节点或整柜购买，还受电力和网络约束，不能将连续估算当作可购买数量。
因此，完整成本只降 5%，就只能容忍有效任务吞吐下降不超过 5%，才能保持单位经济性不变或改善。 在上述情景中，吞吐下降 20% 时，单位任务成本上升 18.8%，即使系统价格确实下降也无法抵消。
硬件采购价降 5% 也不等于完整成本降 5%。例如年化硬件仅占完整成本 70%，其他项目不变，则完整成本只下降 3.5%。新增外部缓存或网络开销可能进一步抵消收益；HBM 制造成本下降是否传递给买方，还取决于最终合同价格。
能耗同理：每有效任务能耗比率＝平均设施功率比率÷有效任务吞吐比率。若功率下降 3%、吞吐下降 20%，每有效任务能耗反而上升约 21.3%。这里两项都是演示假设，应以包括 CPU、网络及制冷分摊的实测功率替换。
7.3 固定业务量：重新计算副本数与设备成本#
如果必须维持目标有效任务吞吐 Q_target，每个合格部署组的吞吐为 q(g)，独立副本可近似线性扩展时，需要：
$$ R=\left\lceil Q_{\mathrm{target}}/q(g)\right\rceil, \qquad N_{\mathrm{needed}}=gR. $$再加入冗余、共享网络、缓存、运维和扩容成本。此时不能一面增加 GPU 数，一面继续把“固定设备数量下成本下降 5%”直接当成扩容后的总成本变化。
假设某工作集为 220 GB，部署预算为 HBM 的 90%，单个 288 GB GPU 容量上可行，单个 192 GB GPU 不可行；若框架支持，可能改成双卡分片。假设每张新卡期间成本为旧卡的 90%，新组的 GPU 成本为原来的 1.8 倍。仅就这一成本项，新组有效吞吐需达到原来的 1.8 倍才能保持单位成本；新增算力和带宽是否做到这一点，需要测量。这个例子为教学假设，未计其他费用，不是完整 TCO。
八、什么情况下影响更严重，以及如何验收#
8.1 按实际运行状态判断影响#
| 实际运行状态 | 预期影响及判断 |
|---|---|
| 高峰活跃 KV 加高价值缓存仍能放入减配预算，且算力或带宽先饱和 | 减配可能主要减少闲置余量；任务吞吐不一定明显下降，价格折扣可能改善 TCO |
| 热缓存不足，但 CPU 层恢复能被工具等待掩盖 | 有机会维持任务体验；必须计入额外恢复流量、缓存设备和功耗 |
| 长上下文同时活跃、下一轮频繁恢复，KV 池长期紧张 | 驻留上限、抢占和排队更容易成为瓶颈，单位任务成本存在实质上升风险 |
| 为适配被迫截断历史或改变模型精度 | 性能与质量比较条件改变；需重新测任务成功，不能只宣称成本下降 |
| 组数、机柜或电力边界被突破 | 扩容存在离散跳跃，成本可能明显超过线性敏感性结果 |
对于长上下文、多轮 Agent，合理的事前判断是：在缺乏充分余量或有效缓存分层时，它属于减配更容易伤及单位经济性的负载；采用高效缓存布局、具有较长工具等待时间且能提前恢复的部署，可能明显缓解损失。 当前证据不足以将这种条件判断收敛成全行业统一的 TCO 涨幅。
8.2 两类基准、两种优化状态#
- 固定真实任务及成功标准。保留各轮输入/输出长度、前缀复用、工具等待、到达时间和重试；只把单次 prompt 重放，无法重现多轮缓存压力。
- 对照两种优化状态：首先以相同软件布局隔离容量影响，其次让高低容量配置分别优化，再比较两者在同质量、同服务要求下的最优完整成本。记录 TP、DCP、KV 精度、缓存层级、路由和副本数。
- 按真实到达率和突发性压测，并做容量扫描。单纯固定并发的闭环压测可能因响应变慢而自动降低发压，掩盖排队风险；需要包含工具等待后的集中恢复。
- 同时报冷/热缓存，并控制预热状态；覆盖高峰、低峰和必要冗余。不以显存满载或原始 tokens/s 单独验收。
- 在尚无不同容量硬件时，可限制高容量卡的 KV 预算测试调度与缓存敏感性。这只能模拟可用容量压力，无法验证实际 8Hi 产品的带宽、功耗、价格或硬件行为。
- 采购判定使用合同价格及实测 Goodput：只有质量和延迟达标，且 C_low/Q_low 低于 C_high/Q_high，才有依据称减配方案对该业务改善 TCO。
验收需同时覆盖固定 GPU 数量的能力对比，以及固定业务量的完整成本对比；每类比较都区分原配置直接迁移与高低容量分别调优后的结果。保留模型版本、框架和内核、精度、分片、节点边界及冗余口径，压测需足够长以暴露缓存饱和和热稳态。[TensorRT-LLM 基准说明][benchmark]
九、对 NVIDIA 与存储产业链的研究含义#
从供给约束出发，较低层数有可能降低每颗 GPU 的 HBM bit 消耗，使相同可交付 bit 支持更多 GPU；这首先是供给与产品组合层面的可能性。若只是 288GB → 192GB，在其他条件相同的理想算术下，等量 bit 可支持 1.5 倍 GPU，但实际还受逻辑 die、封装、良率、带宽分档和整机部件约束。
对客户而言，多交付 GPU 是否改善业务经济性，取决于完整系统成本和有效任务产出。对 NVIDIA 而言，收益可能来自更多出货、不同 SKU 定价或成本节省；对 HBM 厂商而言，结果还涉及总 GPU 量、各 SKU 占比、每层密度、价格与产品毛利。单一层数变化不足以推出 HBM 总需求下降、NVIDIA 利润上升或某家供应商必然受益。
最有价值的后续证据是：NVIDIA 最终 SKU 的容量与带宽、供应商 8H/12H 的实际出货结构、客户同负载的部署规模与价格。若较低容量配置在保持质量和服务标准后仍降低完整系统成本，说明优化对该类负载成立；若需显著扩容、削减上下文或牺牲 goodput，则该类客户的经济性应下调。两类结果可能同时存在。
附录：算例差异、证据缺口与复核材料#
A. 为什么单卡教学算例比主案例的降幅大#
另一个仅为解释固定占用效应的单卡算例，设权重 140 GB、运行空间 20 GB、部署预算 90%、每请求 KV 为 10 GB：
| 项目 | 288 GB | 192 GB |
|---|---|---|
| 预算容量 | 259.2 GB | 172.8 GB |
| 权重及运行固定占用 | 160 GB | 160 GB |
| 剩余 KV 空间 | 99.2 GB | 12.8 GB |
| 理论驻留请求数 | 9 | 1 |
剩余 KV 空间下降 87.1%。它与主文 Qwen 多卡案例使用不同权重、每请求缓存占用和部署布局，所以不能把它们解释成同一模型从单卡扩到多卡的实测结果。主文采用官方模型结构作主要分析，本附录仅说明接近容量边界时的放大效应；两者都不直接预测吞吐。
B. 尚未解决的证据缺口#
关键缺口包括最终低容量 SKU 的型号、带宽与价格，同模型同负载同服务要求的硬件对照，实际峰值 KV、任务轨迹、缓存恢复及完整功耗。公开 B200/DCP 测试证明了布局的重要性，但不能替代 Rubin 减配及客户任务的对照。
DeepSeek 权重索引完整解析未成功，已读取前缀的 total_size 与直接按配置推定的 FP8 占用存在待解释差异。本文只使用其配置计算压缩 KV，不据此发布完整模型的实际 GPU 组容量。公开轨迹基准也不能视为用户真实生产任务。[公开轨迹测试方法][agent-trace]
文中没有将美元/GB 报价、假定采购折扣、其他 Kimi 型号的吞吐损失区间，或混合 DDR/HBM 减配设为事实。所有成本折扣与损失幅度均为标注后的敏感性假设。
本文所载观点与意见仅代表作者个人立场，仅供一般性的信息与教育参考之用，不构成任何形式的投资建议、理财建议、交易建议或买卖证券的推荐。读者不应将本文的任何内容视为购买或出售任何金融工具的邀请或要约。
本文仅用于研究交流，不构成投资建议。市场观点具有时点性，请结合原始资料与自身风险约束独立判断。