当你向 AI 提问并收到回复，这个看似瞬间完成的交互背后，是一套横跨计算、存储、内存与网络调度的复杂工业体系。
9 月 22 日，研究机构 SemiAnalysis 发布深度技术报告，系统拆解了大模型推理服务的底层架构。从用户发出请求到 AI 生成每一个 token，每个环节如何运作、哪里是瓶颈、什么样的硬件在什么阶段真正创造价值。
报告指出，推理服务并非一个整体，而是由预填充（Prefill）、中间填充（Midfill）、解码注意力（Decode Attention）和解码专家（Decode Experts）四个工作阶段构成的 "Token 工厂 "。
这一分析框架对于理解 AI 基础设施竞争的核心逻辑具有重要参考价值。每个阶段对算力、内存带宽和网络的需求截然不同，混同处理将损失混合专家（MoE）模型架构的结构性优势。
报告以英伟达 Blackwell 系列 GPU 为案例进行推演，其结论对硬件设计者、云服务商和模型部署方均具有直接指导意义。
" 专家工厂 " 的诞生：MoE 改变了什么
过去，我们讨论大模型，习惯用参数量说话——千亿、万亿，数字越大越震撼。但 MoE 的出现，让这种比较方式变得苍白。它真正改变的，不再是参数的总量，关键是哪些参数在哪个时刻被激活。
具体来说：每次处理一个词元 Token（可以简单理解为一个词或一个字），MoE 模型不会让全部参数都参与计算。它有一个 " 路由器 "，会为每个 Token 精准定位出少数几个最合适的 " 专家模块 "，让这些专家各司其职，处理完再把结果汇总。
这就好比一家超级医院，每个病人进门不是被所有科室的医生轮流问诊，而是智能分诊系统直接把他送到最对口的两三位专科医生面前。
这个机制带来了一系列连锁反应：
哪些数据必须 " 住 " 在离计算最近的地方，发生了根本变化；
内存、带宽、存储的价值权重，被彻底重新排列；
调度系统的复杂度，从线性增长变成了指数级跃迁。
换句话说，MoE 让整个推理系统变成了一座需要精密协调的 " 智能工厂 "。
推理服务是一座分工明确的流水线工厂
SemiAnalysis 报告指出，AI 推理服务是一个由多个专用工作节点池构成的循环系统，而非运行在单一服务器上的程序。
用户或其代理发出请求后，调度层（如英伟达 Dynamo 或 Mooncake）将其放入队列，分配给输入填充工作节点处理。该节点负责将用户输入连同历史对话状态转化为新的上下文，再交由解码工作节点反复读取已积累的状态、逐步生成回答 token。
在智能体（Agent）场景下，这一流程还会与工具调用、外部搜索等环节交织，形成每小时可达数千次的对话轮次。
（推理服务中模型阶段的概述）
每一轮对话产生的 " 记忆 "，在系统内部以一种叫做 KV 状态的形式存储。这些状态被设计成不可变的数据块（blob），像区块链账本上的记录一样，一旦生成便不再修改，只会不断追加。
为什么要这样设计？因为 AI 对话天然是因果推进的——后一句话的理解，依赖于前面所有内容的积累。不可变结构，完美契合了这种单向流动的特性。
更炫技的是这套存储的层级设计：
最高频调用的实时数据（当前正在计算的上下文）住在 GPU 的 HBM（高带宽内存）里，这里是寸土寸金的 " 黄金地段 "；
次高频的中间态数据（刚完成的对话轮次）被迅速转移到 CPU 的 DRAM，进行中转暂存；
低频沉淀的历史数据则被推入 SSD 或网络存储池，等待被召唤。
这套动态分级，让昂贵的 HBM 永远只服务于 " 正在赚钱的数据 "，而不是白白浪费在存档上。
报告引用 SemiAnalysis AgentX 数据集的真实追踪数据显示，智能体对话过程中上下文的增长速度极快，但也会因压缩等模型行为产生大幅波动。边界模型供应商的领先 AI 公司被观察到正在反复压缩上下文以维持在百万 Token 限制之内。
在成本结构上，报告明确指出，HBM 比 DDR 内存贵出数倍且供应受限，频繁复用的通用数据块（如系统提示）应保留在共享 CPU 内存或近端缓存设备中，而非占用昂贵的 HBM 资源。
四个工作阶段，对硬件的需求天差地别
SemiAnalysis 报告最核心的贡献之一，是将推理过程细分为四个截然不同的计算区间，并指出将它们作为同一工作负载处理会造成严重的效率损失。
预填充（Prefill）对应用户首次发起请求的场景，模型需要处理一整批新 token。由于大量 token 共享权重加载，矩阵运算效率高，算术强度高，通常受计算能力约束，而非内存带宽。
中间填充（Midfill）在智能体工作流中日益重要。它在已有的长缓存前缀基础上追加少量新 token ——前缀可能已达数十万 token，而新输入仅有数百至数千 token。这一阶段兼具解码阶段的大规模 KV 状态读取和预填充阶段的权重复用特性，算术强度可达单 token 解码的数百倍，但缓存状态的流量也远超同等规模的初始预填充。
解码注意力是生成回答 token 的核心环节，每次前向传播仅处理一个或少数几个 token。随着上下文长度增长，注意力读取的数据量甚至可以超过模型权重本身的大小——在长上下文场景下，注意力是现代解码过程中最重的内存操作之一，尽管大多数模型参数实际上位于专家层。
解码专家（Decode Experts）是 MoE 架构特有的环节。路由器根据当前 token 的激活值，从庞大的专家库中选取少数几个专家执行计算。专家权重不携带任何查询历史，仅依赖当前激活，这使其可以在更广泛的 GPU 范围内分布部署。
这四道工序的神奇之处在于：它们对硬件的需求截然不同。
预填充是计算密集型的，中间填充是计算与内存的双重考验，而解码则几乎完全被内存带宽所主宰。把它们混为一谈，就像让短跑运动员和马拉松选手用同一套训练方案，必然是一场浪费。
内存带宽比内存容量更值钱
报告专门辟节讨论内存带宽与内存容量的经济权衡，得出一个对硬件设计和采购决策具有反直觉意义的结论：在许多推理场景下，带宽比容量更能创造收益。
数据在被处理时创造收益，在内存中闲置时只产生成本。一块内存吞吐极高的加速器，即便容量较小，其生成 token 的速率也可能超过低带宽高容量配置。
在达到 " 够用 " 的容量门槛之前，每增加一份内存都能显著提升收益；越过这个门槛后，曲线逐渐走平，继续堆容量的边际效益越来越低，最终可能变成一种浪费。
（每台机器的收入与本地快速内存容量的关系）
报告给出了一个 2027 年的实用设计基准：以每 token 约 70KB 的 KV 状态、200 万 token 的聚合活跃上下文计算，单个流水线阶段的 KV 状态需求约为 140GB，加入双缓冲后接近 280GB；再叠加模型权重、激活值、路由表和运行余量，单阶段约需 400 至 500GB 的本地快速内存。
这一基准同时说明，加速器 HBM（高带宽内存）的最优用途是承载当前正在赚取收益的活跃批次数据。已完成处理的 KV 数据块应及时迁移至 CPU DRAM，再转入更廉价的网络附加存储。将昂贵的 HBM 用于存储闲置上下文，是对稀缺资源的低效使用。
调度稳定性决定工厂级吞吐效率
即便硬件配置完善，推理服务的实际效率在很大程度上取决于调度层的设计质量。报告特别警告了一种在大规模推理集群中容易出现的系统性风险：延迟反馈震荡（retirement-gated oscillation）
首先要承认一个现实，预填充和中间填充是可预测的，只要知道输入长度和缓存大小，处理时间就能被精确估算。但解码是随机的，没有人知道模型什么时候会输出终止符号，一个回答可能 3 句话结束，也可能写出一篇论文。
这种不对称，给调度系统带来了巨大挑战。如果解码速度变慢（比如某个超长回答还没写完），后续的 Prefill 请求就会积压，整个流水线开始拥堵。
更糟糕的是，一旦出现延迟，系统可能过度补偿，突然放入大量新任务，导致新一轮拥堵。这是经典的延迟反馈震荡，就像交通信号灯控制失当时的道路潮汐现象。
工程师们的解法充满智慧：
在各个阶段之间设置 " 就绪缓冲区 "，让预填充完成的结果先在缓冲区等待，而不是直接堵在解码入口；
平滑化入场控制，不根据单次请求的完成情况来决定下一批任务的数量，而是观察整体积压趋势；
分层控制时间尺度：微秒级的硬件调度、毫秒级的 Token 流控制、秒级的缓冲管理、分钟级的工作节点重配置。绝对不能让慢变量去追快噪声。
值得注意的是，高交互性和高利用率并不天然矛盾。只要调度系统足够聪明，完全可以在保持每个用户低延迟体验的同时，让机器整体保持高负荷运转。
关键在于，调度器要有足够的 " 视野 " 和足够快的 " 反应速度 "。
聚合还是分离：一场没有标准答案的辩论
在推理系统的架构设计上，目前存在两种主流哲学的激烈交锋。
分离式（Disaggregated）架构主张让不同类型的工作节点各司其职：专门为 Prefill 优化的机器，专门为 Decode 优化的机器，各自配置最适合自己工作模式的硬件。
Prefill 机器可以更注重计算力，Decode 机器可以更注重内存带宽。任务来了，调度器决定送到哪台机器，完成后搬走 KV 缓存，交接给下一台。
聚合式（Aggregated）架构则主张一次对话的整个处理过程，尽量在同一台机器上完成。好处是显而易见的，不需要在不同机器之间搬运动辄几十 GB 的 KV 缓存，没有网络传输的延迟和开销，专家层可以天然共享，调度器的决策也简单得多。
聚合式的软肋同样明显，一台机器需要同时擅长高强度计算（服务 Prefill）和高带宽内存访问（服务 Decode），而这两种能力在硬件设计上往往存在取舍。
如果一台机器在其中某方面有短板，它就会在对应的工作模式下 " 跑不满 "，白白浪费算力。
这场辩论的结论，取决于你能否造出那块 " 全能明星芯片 "。 如果未来某款加速器能同时拥有极高的计算密度和极高的内存带宽，聚合式架构将获得压倒性优势。否则，分离式架构仍然是在现有硬件条件下最务实的选择。
实例分析：预测 Kimi K3 在 Blackwell 系统上的性能
报告通过 SemiAnalysis 推理模拟器，对 Kimi K3 模型在 B200、B300 与 GB200 系统上采用 16 至 64 块 GPU 的不同配置进行了性能投影，覆盖交互延迟、吞吐量、能耗与内存占用四个维度。需要说明的是，这些均为工作负载与硬件的模拟预测，并非实测基准数据。
在解码阶段，GB200 在延迟 - 吞吐权衡曲线的大部分区间表现领先，B200 和 B300 亦提供具竞争力的配置点。最低延迟配置通常结合流水线与张量并行；而吞吐量导向的配置则倾向于每 GPU 单个注意力实例，不采用张量或流水线并行，同时保持尽可能宽的专家并行度。
在中间填充阶段（127k 缓存输入 Token 加 1k 新 Token 追加），GB200 凭借 NVL72 架构将扩展带宽延伸至整个机架，在低首 Token 延迟区间领先；B300 在吞吐量导向端追平差距。B200 与 B300 通常采用 PP=4 配置，将专家全对全通信限制在节点内部的 NVLink 网络。
内存占用方面，投影结果显示大多数前沿配置的每 GPU HBM 峰值驻留量维持在 80GB 以下，支持了报告的核心论点：相较于最大化每块加速器的 HBM 容量，带宽管理与存储编排往往具有更高的经济价值。
能耗分析方面，解码阶段因每个查询需约 1000 次模型前向传播而成为最大能耗来源；中间填充阶段因仅需对现有长上下文追加短序列，反而是能耗最低的模式。
