Tuhin Srivastava：推理——构建推理云

一项请求进入平台后，并不会直接落到“某块 GPU”。它通常先经过鉴权、限流和路由，再进入队列，由模型服务器和运行时组织计算，最后持续返回 token。

Prefill 一次处理整段输入，通常具有更高并行度；Decode 必须逐 token 前进，受权重读取和内存带宽约束。长上下文 Agent 会让 Prefill 更重，实时对话又要求 Decode 足够稳定。

当两类工作负载差异扩大时，平台可以把它们放到不同机器甚至不同芯片上，再通过高速网络传递中间状态。分离不是免费的：状态传输、调度和故障处理会增加复杂度。只有节省的计算成本和容量收益超过通信开销，它才值得采用。

推理服务的核心经济来自共享。模型权重已经加载在 GPU 中，平台希望让更多请求共同使用这份固定资产。

连续批处理不是等一批请求全部结束再换下一批，而是在旧请求完成后立即把新请求插入空位。它提高利用率，也更适合输出长度不一致的生成任务。

这项优化并不由单一主体完成。vLLM、SGLang、TensorRT-LLM 等模型服务框架负责具体批处理与内核执行；推理平台再根据不同客户、模型和集群决定队列、优先级与扩缩容；应用还可以通过稳定提示前缀提高缓存复用。竞争因此分布在运行时、平台调度和应用结构三层。⁴

KV Cache保存一次请求已经计算过的注意力状态，避免每生成一个 token 都重算全部上下文。它主要在同一请求内复用。

前缀缓存进一步复用不同请求之间相同的开头。例如代码 Agent 反复携带同一仓库说明、工具定义和系统规则，稳定前缀可以只计算一次。

总推理成本
= 新增计算
+ 无法复用的上下文
+ 缓存占用
+ 排队与空闲损失
+ 网络和故障成本

缓存并非越多越好。显存有限，保留一个低复用前缀可能挤掉更高价值请求。平台需要预测未来复用概率，并决定何时保留、迁移或淘汰缓存。

每 token 更快不一定意味着 Agent 更好。一个模型可能输出很快，却频繁选择错误工具；另一个模型使用更多推理 token，却一次完成任务。

因此，服务指标应从 token 层扩展到任务层：

单位完成任务成本 = 全部模型、工具、重试和验证成本 ÷ 成功任务数

更低首 token 时延 ──→ 更好交互
更高 token 吞吐 ────→ 更低生成成本
更高任务成功率 ────→ 更少重试与人工接管
更稳定尾部时延 ────→ 生产系统可预测

对于编码、研究和长时间 Agent，完成时间、最终测试通过率和重试次数可能比单次模型基准更重要。

Baseten 并不首先建设自己的物理数据中心。它把多个云、多个区域和不同硬件组织成一个托管推理平台，向客户提供模型部署、自动扩缩容、运行时优化、监控和服务保障。

推理平台早期收入往往接近计算成本加价：购买或承诺 GPU 容量，再以更高价格卖给客户。这个模式简单，却容易被云厂商价格、GPU 供给和大客户自建能力挤压。

Tuhin 希望平台进一步按 token 或服务结果计价。这样平台可以在后台自由选择硬件、量化、缓存和批处理方式，把优化收益保留下来。

按 GPU 小时收费：客户承担利用率和硬件选择
按 token 收费：   平台承担生产效率
按任务收费：      平台进一步承担模型效果和重试

越靠近结果，收入上限越高，平台承担的风险也越多。若模型质量波动、请求输出长度不可预测或任务失败，平台可能无法只靠基础设施优化控制毛利。

开放权重让企业可以持有、修改和自行部署模型，但“拿到权重”不等于“拥有低成本、可靠推理”。运行仍需要 GPU、内核、批处理、监控、扩缩容和运维。

开放与闭源模型很可能形成动态组合：最前沿闭源模型在一段时间内保有能力溢价，开放模型随后追赶，并以更低价格承接成熟任务。2026 年的技术评估显示两者仍有差距，但差距以数月为单位变化。⁵⁶

专用模型也不必证明自己比前沿模型“更聪明”。只要它在同一质量门槛下具有更低的每项合格任务成本、更稳定的时延或更强的数据控制，就有现实价值；但这种执行经济性不等于长期智能壁垒，下一代通用模型仍可能迅速覆盖它。

路由和调度可以使用运筹优化、启发式规则和机器学习。机器学习更适合预测请求长度、缓存命中、故障概率和到达流量；优化器再根据服务等级和容量做分配。

预测层：未来会来什么请求、需要多少资源
        ↓
优化层：在成本、时延和可靠性之间选择方案
        ↓
执行层：部署、路由、扩缩容与故障恢复
        ↓
反馈层：实际结果更新预测和策略

单个调度算法容易被复制。更强的壁垒来自跨工作负载的数据、实际执行权限和长期反馈：平台是否能看到不同模型、硬件、缓存和客户任务的完整表现，并持续把经验转成更好的控制策略。

这与第六课的经验闭环直接相连。真正稀缺的不是“有很多日志”，而是能把失败归因给模型、上下文、运行时、硬件、路由或验证器，并知道下一次该改哪一层。

Tuhin 认为 NVIDIA 硬件体系仍占据绝对主导地位。原因不仅是芯片性能，也包括供应、CUDA、框架支持、工具和团队经验。

“支持 PyTorch”不等于“CUDA 兼容”。一块新芯片可以在上层接收 PyTorch 模型，但仍需要自己的：

编译器后端
→ 算子与内核
→ 内存管理
→ 通信库
→ 运行时
→ 模型服务
→ 调试与可观测工具

新模型结构出现后，谁能最快完成这条链，谁就能先获得生产负载。专用芯片即使在稳定基准上更快，也可能因为适配速度慢而错过需求窗口。

课堂围绕 Baseten 的长期边界展开了一个更大的问题：AWS、Azure 和 Google 本身拥有 GPU、数据中心、客户和云平台，为什么还需要独立推理公司？

历史上的 Snowflake 和 Databricks 提供了一个有用但不能机械照搬的检验。独立基础设施公司能够成立，通常经历三步：

新的架构洞察
    ↓
把洞察变成客户愿意购买的产品抽象
    ↓
继续向更高价值的状态、工作流或控制层迁移

推理平台不能随意共享客户私有数据，但可以积累不含业务内容的系统方法：什么请求适合哪种硬件、怎样预测输出长度、哪些缓存策略有效、什么故障模式会导致尾部时延。

更高一层的规模经济来自生产—评价—再配置闭环：

模型上线
  ↓
真实任务与结果
  ↓
评价和失败归因
  ↓
修改模型、上下文、技能、路由或验证器
  ↓
重新部署

客户拥有最终业务效用和数据；平台可以提供评价基础设施、部署工具和跨任务方法。谁掌握这条闭环中的更多信息和执行权，谁更有机会从“GPU 加价商”升级为生产控制层。

推理是把模型变成产品的生产系统。批处理、缓存、Prefill/Decode 分离、路由和异构硬件共同决定成本与体验，最有意义的指标最终是成功完成任务的成本和时延。

独立推理平台的短期价值来自专业化、多云抽象和运维；长期能否存在，取决于它是否从轻状态的模型托管进入更难复制的优化闭环。单次性能领先和调度算法很容易衰减，持续适配新架构、隐藏底层变化，并连接生产、评价和再配置，才可能形成更稳定的平台位置。