第034期 - 快速 Token 之争、TPU v7、Vera Rubin 与 Engrams（AI 供应链，InferenceX）
摘要
- Engrams 将模型架构与内存层级合并为一个协同设计问题。 它在哈希表中学习 2-gram 和 3-gram 的 token embedding，让模型直接取回熟悉的语义，而不是交给后续 Transformer 层重新构建；消融实验显示，Engram 与 MoE 层的混合架构优于全 MoE/无 Engram 或全 Engram/无 MoE。由于 token ID 在计算开始前就已知，从 DRAM 或 SSD 中取数可以与计算重叠，相当于获得“免费层”；但放置得越靠前，模型收益越大，能够用来隐藏取数延迟的时间也越少。
- 这一设计反映了中国模型架构面临的结构性约束：HBM 越少，就越依赖更激进的压缩、分层与异步卸载。 嘉宾将 Engrams 与 DeepSeek 早期压缩 KV cache、使用 HBM 的工作联系起来，也提到国内加速器的带宽落后于美国系统。更广泛的判断是，中国实验室会继续把 KV cache 及相关模型状态向更低的内存层级下移，而美国实验室过去受到这一约束的驱动较小。
- AgentX 说明，在真实编码 Agent 工作负载中，KV-cache 管理会成为决定性因素。 通过 SemiAnalysis 内部代理捕获并重放的会话显示，P50 请求接近 100,000 个输入 token，理论缓存命中率超过98%，因为每次工具调用都会向既有长对话追加内容。低并发交互场景下，DRAM 卸载价值有限；但当并发 Agent 达到数百个、吞吐在 40–60 tokens/s 左右，或进入离线批处理、强化学习 rollout 时，其价值就会显现。
- 在工作负载与定价假设成立的前提下，当前推理经济学可能让最新系统看起来像“印钞机”。 团队的计算器将硬件、电力、数据中心成本、吞吐、并发和 OpenRouter 定价结合起来；讨论中的情景包括 GB200 NVL72 约 40.7%的利润率，以及 GB300/Moonshot 在按牌价的 30%和60%计价时约 50%的利润率。结果仍高度依赖利用率、节点可用性、软件和流量。
- TPU V7 对外开放，构成了 NVIDIA 与 AMD 之外最清晰的潜在第三家竞争者。 团队早期测试显示，TPU V7 几乎占据 Pareto 曲线低成本一侧的全部位置，只有一个点胜过它，外部 TCO 输入约为 $1.21。软件仍不成熟；原生 Torch 支持、TPU vLLM、megakernel、V8，以及 Google 内部环境之外的 GCP 托管，都可能进一步改善其位置。
- Vera Rubin 在运营层面看起来不如 Blackwell 激进，但经济性可能强得多。 在约 100 tokens/s 的运行点上，早期讨论认为性能提升可能接近 3×；在高吞吐场景，提升幅度则可能更接近约 1.4×。HBM3 到 HBM4 约 3× 的内存带宽进步，有助于解释曲线中段的内存受限特征。一条硬件加速的查找表量化路径值得关注：8-bit 表值、3-bit key，有效位宽约 3.125 bit，但目前尚未发现重大应用。
- 关于快速 token 的争论尚未定论，因为 Agent 工作流同时包含对延迟敏感和对延迟不敏感的阶段。 Bryan、Cam 和 Alec 认为，在多个 Agent 并行运行，或 30 秒工具调用占主导时，快速解码的回报有限；尤其当价格接近每100万输出 token 300美元时更是如此，但 Alec 也提醒未来工作流可能改变。TensorRT 在 NVIDIA GPU 上实现每秒数百个 token，强化了专用推理软件的逻辑；不过 batch size=1 的 megakernel、不断变化的 prefill/decode 比例和困难的部署经济性，都让定制芯片的论点更加复杂。
精读
1. Engrams 用可寻址内存替代重复语义计算
Cam 的框架是：普通 token embedding 在穿过 Transformer 层时不断累积语义；Engrams 则为 2-token 和 3-token 序列学习 embedding，将其哈希到表中，再把取回的表示注入模型。
讨论中提到 DeepSeek 的相关工作：比较不同隐藏状态深度对 next-token prediction 的能力，以及相对于最终层的 KL divergence。Bryan 的解释是，Engram 将词义信息前置，后续层就不必再动用那么多参数去重建这些信息。
关键消融并不是“用内存替代一切”。损失曲线在 Engram 模块与传统 MoE 层结合的中间位置有所改善，而全 MoE/无 Engram 和全 Engram/无 MoE 两个端点的效果都更差。因此，团队将收益描述为获得了若干“免费层”（free layers），而不是取消 Transformer 计算。
模块放置位置带来了核心的协同设计权衡。更早进行取数，意味着更多下游层可以访问这部分内存，报告中的消融结果对模型帮助也更大；但这样一来，可用于隐藏 DRAM 或 SSD 取数的计算就更少，模块放得更靠后，则有更多机会与取数异步重叠。
2. 内存稀缺正在塑造中国模型架构
token ID 在 forward pass 开始前就已知，因此 Engram lookup 可以通过统一虚拟寻址和 CPU 上的固定页主机内存立即启动。它不像依赖中间 hidden state 的检索那样需要等待前序计算，因此可以与模型其他部分重叠执行，使 DRAM、甚至 SSD，成为实际可用的内存层级。
嘉宾将 Engrams 与 DeepSeek 早期压缩 KV cache、使用 HBM 的工作放在一起讨论。更广泛的判断是，凡是可以提前取回并与计算重叠的信息，都天然适合卸载到更低层级。
中国加速器进一步强化了这一动力。国内系统可能使用中国制造的 HBM 类技术，但带宽更低，因此中国实验室会被推向更小的 KV 表示、更强的压缩、更低层级的内存以及各种架构技巧；相比之下，美国实验室拥有更多 HBM，相对于这一约束，Cam 形容其算力几乎是无限的。
3. AgentX 让 KV-cache 问题变得可测量
Cam 描述的 Agent trace 是：用户发送任务，模型生成文本和工具调用，工具输出被追加进上下文，增长后的对话再返回给无状态模型。每一轮对话都会让 KV cache“以惊人的速度增长”。
AgentX 使用 SemiAnalysis 员工通过代理捕获的编码会话，去除不适合的请求，再将剩余 trace 重放到开源 serving stack 上。团队承认，这并不代表全部编码流量，但认为其基本形态——任务、工具循环、新增上下文、重复前缀——具有普遍性。
最突出的数字是：P50 请求约包含 100,000 个输入 token，理论缓存命中率超过98%。大多数轮次都会复用此前的大量上下文，因此，将请求路由到正确的 prefill server、在 prefill 和 decode 之间传输 KV，以及维持缓存驻留，都需要精细的系统设计。
卸载的价值取决于运行点。低并发、高交互场景下，需要溢出的 KV 不多，而更慢的二级内存价值有限；当吞吐达到 40–60 tokens/s、并发会话达到数百个，或进入离线批处理、强化学习 rollout 时，DRAM 卸载就变得重要。Bryan 另表示，他希望看到 HBM 而不是 VRAM 的缓存命中率处在 20–30%区间。
4. Serving 利润更奖励利用率，而非基准测试领先
Bryan 解释，计算器先从每小时持有成本出发，包括加速器、数据中心成本、电力和相关基础设施；随后将这些数字与模型吞吐、并发、利用率假设和 OpenRouter 定价结合起来。它的目标，是把基准测试曲线转换成特定工作负载下不同芯片能够产生的利润。
按讨论中的假设，GB200 NVL72 部署可以实现约 40.7%的利润率。团队还展示了 Kimi K2 和 DeepSeek V4.1 Flash 的其他利润率情景。Jordan 也提到，在 GB300/Moonshot 情景中，按牌价的 30%和60%计价，利润率约为 50%。
质疑本身已经嵌入模型：按60%利用率计算，除非节点停机，系统实际上就相当于接近饱和；而不同服务商可能面临较低利用率、不同软件或不同算力价格。Bryan 表示，部分服务商在 30–40%利用率下仍然可以盈利。Jordan 的意思是，服务商希望在数月内收回机架资本，而不是说每个情景都能保证这一结果。
5. TPU 对外开放使 Google 成为平台型竞争者
Alec 的早期 TPU V7 结果显示，这一公有云产品几乎占据整条价格-性能 Pareto 曲线最便宜的一侧，只有一个点胜过它。团队使用了约 $1.21 的外部 TCO 输入，并强调这是第一天的结果，尚未计入后续软件优化。
这一比较并不完全对等：TPU 的芯片、编程模型、可访问性和社区支持，都与 B200 或 B300 存在实质差异。固定尺寸的脉动阵列可能因为 padding 浪费算力，而 Google 的内部模型过去是围绕自身约束设计的，开源模型未必遵循这些约束。
软件是最明确的追赶路径。嘉宾预计，TPU vLLM、更多 megakernel 工作以及即将推出的 Torch-TPU backend，将降低编程模型摩擦；V8 属于 TPU 下一阶段的发展方向，而 V7 本身也会随着 kernel 和公有模型支持成熟而继续改善。
Bryan 更大的判断是“大规模对外开放”（large-scale externalization）：Google 仍会在内部使用大量 TPU，但也会出售其中一部分。如果 GCP 能在 Google 自有环境之外托管 TPU，生态就可能向更多客户开放；Cam 则认为，这会让 AMD 和 NVIDIA 面对一个真正的第三家竞争者。
6. Rubin、快速解码与定制芯片重新切分工作负载
从 H100/H200 HGX 系统转向 GB200 和 GB300，引入了 Arm CPU、scale-up NVLink switch、新网络和液冷；Blackwell 的 SM100 还引入了新的 FP4 数据类型。Vera Rubin 在运营层面看起来更像渐进式升级：没有重大的新 scale-up 网络或 Arm CPU，液冷也已经部署，但内存带宽大幅提升。
性能曲线取决于工作负载。在约 100 tokens/s 的位置，早期讨论认为 Rubin 的性能或相同交互水平下可服务的用户数可能接近提升 3×；在最大吞吐附近，优势则可能更接近约 1.4×。HBM3 到 HBM4 约 3× 的带宽提升，与曲线中段的内存受限特征高度吻合。
Rubin 还暴露出一条新的硬件加速查找表量化路径：使用 8-bit 表值和 3-bit key，有效位宽约为 3.125 bit。团队尚未看到这条路径的专门应用，也明确表示开源生态会在多大程度上采用它仍待观察；与 MXFP4 类似的 scaling 方式以及准确率评估，都是后续关注点。
对快速 token 的需求引发了最尖锐的分歧。Bryan 更偏好多个 Agent 并行运行；Cam 指出，一次 30 秒的工具调用就可能抵消每秒 1,000 个 token 的解码速度；Alec 则质疑投入产出比，认为价格过高。Alec 的历史性谨慎在于，1–2年前他不会预测自己今天的 AI 工作流，因此未来需求很难预测。Cam 的判断是，快速模式会对部分任务有用，而可以批处理的工作能够容忍更高延迟。
TensorRT 展示了软件优化的极端形态：将模型的大部分融合进一个巨大的 dataflow 风格 megakernel，在 NVIDIA GPU 上实现每秒数百个 token；一张图表中的点位接近 500 tokens/s，对应的是一个规模相当大、参数量接近1万亿的模型，而且只使用 NVIDIA GPU。代价则是巨大的工程投入、缓慢的模型接入速度，以及偏向交互而非高吞吐 serving 的 batch size=1 特性。
因此，Jordan 并不担心加速器初创公司找不到第一批客户，因为“需求完全领先于供给”（demand is completely ahead of supply）；但团队并不认同这就能证明经济性具有持久性。如今做出能工作的芯片已经变得可行，真正更难的商业问题仍包括取得良率、完成服务器组装、 확보分销渠道、运营数据中心、适应不断变化的 prefill/decode 比例，以及与 NVIDIA 的软件和受控 GPU 供给竞争。