当所有人都在讨论下一个更强的模型时，真正的竞争已经转移到了幕后：如何把模型的每一次”思考”变成一门划算的生意。
引言：一场没有发布会大战的竞赛
过去几年，AI 行业的聚光灯几乎都打在”训练”上：更大的参数量、更长的上下文窗口、更惊艳的跑分。但 2026 年的行业现实是——训练是一次性投入，推理才是持续发生的成本中心。每一次你向大模型提问、每一个智能体在后台自动执行任务，都在消耗真实的 GPU 小时。
10 月 20 日，一个不那么”性感”但分量十足的项目迎来了里程碑：由 Red Hat、IBM、Google Cloud、CoreWeave 和 NVIDIA 在 2025 年共同发起、现已进入 CNCF（云原生计算基金会）治理的开源推理基础设施项目 llm-d 发布 1.0 版本[1]。Mistral、Roblox 等公司同时公开了生产环境的使用反馈。这不是一次模型能力的跃升，而是一次信号：大模型竞争的下半场，正在从”造出模型”转向”把模型运营好”。
图：全球推理流量昼夜不息。图源 Unsplash。
一、推理为什么烧钱：利用率是决定性变量
推理成本的本质是一道简单的除法：每 token 成本 ≈ GPU 每小时价格 ÷ 每小时实际产出的 token 数。分母才是关键——而行业现状并不乐观。
几组公开数据可以说明问题的严重程度：
- 据 Cast AI 发布的《2026 Kubernetes 优化状态报告》，生产 Kubernetes 集群中 GPU 的平均利用率仅约 5%，其数据集中表现最好的集群（136 节点 H200）也只达到 49%[2]；
- 2026 年 4 月，公有云上 NVIDIA B200 的按需价格跨度高达 3.49 到 14.24 美元/卡/小时，同样的芯片，运营能力的差距直接写进了价签[3]；
- 解码（decode）阶段是典型的内存带宽受限负载，”朴素地”串行生成 token 会让大部分算力空转——你为整张卡付费，却只用到它的一小部分[3]。
换句话说，大多数推理开支买的是”闲置”。这就是为什么基础设施层的优化——缓存、调度、拆分、量化——能撬动数倍于算法微调的经济学收益。
二、两种性格的工作负载：预填充与解码
要理解 2026 年推理系统的设计哲学，得先看清楚大模型推理的内在分裂。一次请求的生命周期分为两段，它们的计算特征截然相反：
| 阶段 | 计算特征 | 瓶颈 | 敏感的指标 |
|---|---|---|---|
| 预填充（prefill） | 一次性并行处理整个输入 | 算力密集 | 首字延迟（TTFT） |
| 解码（decode） | 逐 token 自回归生成 | 内存带宽密集 | 每 token 延迟（TPOT） |
更麻烦的是 KV 缓存。它是自回归生成得以实用的前提，却也是成本随上下文长度暴涨的元凶：Llama 3 70B 在 128K 上下文下，单个请求的 KV 缓存约 42.9 GB（FP16），超过模型权重本身[4]。这意味着长上下文时代，”内存墙”比”算力墙”先到。
工程界的应对也已成体系：vLLM 团队 2026 年 4 月的基准测试显示，FP8 KV 缓存可将每 token 缓存内存降到 BF16 基线的约 54%，长上下文检索任务精度从 91% 仅回落到 89%；配合 FP8 权重，Llama 3.1 70B 的按需价格从约 1.19 美元/百万 token 降到 0.71 美元，同硬件直接省下 40%[4]。
图：内存带宽，而非峰值算力，正在成为推理硬件的主战场。图源 Unsplash。
不同业务的预填充/解码资源比例也差异巨大：聊天类约 1:8，智能体任务约 1:3，RAG 检索增强约 1:4[5]。一种负载的最优配置，往往就是另一种负载的浪费。这个”性格不合”，正是下一节所有架构创新的出发点。
三、llm-d 1.0：让推理长在 Kubernetes 上
llm-d 的定位不是又一个推理引擎，而是引擎之上的”运营层”——把 vLLM、SGLang 这类模型服务引擎与 Kubernetes 的分布式调度能力缝合起来。Red Hat 杰出工程师 Stephen Watt 在发布演示中说，这个项目要弥合的鸿沟是”在一台机器上跑推理”与”把它作为一项共享服务来运营”之间的距离，它必须满足”IT 和 SRE 团队运营生产服务的日常预期”[6]。
1.0 版本的能力清单相当务实[1][7]：
- 前缀缓存感知路由：调度器追踪每个解码节点的 KV 缓存状态，把请求路由到已持有相同前缀缓存的节点，避免重复计算；
- 预填充/解码分离（disaggregated serving）：两类负载落到独立的 GPU 池，各自独立扩缩容；
- KV 缓存分层卸载：显存装不下的缓存下沉到内存/SSD，换取更大的有效上下文承载；
- 宽专家并行：把 MoE 模型的专家分布到多节点，支撑超大模型服务；
- 多租户流量控制与高可用路由：1.0 新增的稳定配置 API，让”抢容量”变成可声明的策略。
值得注意的是它的治理路径：项目于 2026 年 3 月 24 日捐赠给 CNCF，使用标准 Kubernetes CRD（InferencePool、InferenceObjective）和 Gateway API Inference Extension 扩展[7]。推理基础设施正在走 Kubernetes 当年走过的路——从厂商私有方案走向开放中立的社区标准。这对中国企业尤其重要：中立的开源栈意味着不被单一云厂商绑定，自有 GPU 集群也能获得与头部云商对等的服务能力。
四、拆开来服务：分离式架构的经济学
预填充/解码分离带来的收益有多具体？行业测算给出过一组对比。以 1000 QPS 的 Llama-3-70B 聊天负载为例[5]：
| 服务配置 | 所需 H100 数量 | 每小时成本 |
|---|---|---|
| 朴素共置服务（基线） | ~4400 | $132K |
| 共置 + 完全优化（FA3/FP8/前缀缓存） | ~2200 | $66K |
| 分离式（同节点） | ~1500 | $45K |
| 分离式（跨节点，Mooncake 风格） | ~1200 | $36K |
| 分离式 + 投机解码（EAGLE-2） | ~800 | $24K |
即使与”完全优化过的共置部署”相比，分离式架构仍有约 30%–50% 的成本优势[5]；而 100 QPS 规模的另一个测算显示资本开支节省约 25%[5]。逻辑并不神秘：把算力密集的预填充交给少数卡，把带宽敏感的解码交给大批卡，两种硬件都可以按自己的节奏扩缩，互不牵制。跨节点传输 KV 缓存需要高速网络（NVLink、RDMA/InfiniBand）与专用传输层（如 NVIDIA 的 NIXL、月之暗面开源的 Mooncake），这正是它晚于 PagedAttention 等单机优化落地的原因。
图：分离式服务的代价与前提，是节点间足够快的缓存传输。图源 Unsplash。
2026 年的引擎生态也在快速跟进：SGLang 目前是分离式部署落地最广的开源引擎（DeepSeek-V3 的生产参考实现），vLLM 的分离支持正从原型走向生产级，NVIDIA 则以 Dynamo + TensorRT-LLM 提供自有体系的方案[5]。多条路线并存，说明这个方向已经从论文变成了共识。
五、缓存感知路由与流量控制：智能体时代的新命题
如果说分离式架构解决的是”怎么切蛋糕”，那么 1.0 版本着重补上的流量控制，解决的是”蛋糕给谁先吃”。
智能体工作负载改变了流量的形状。 人类用户的请求是相对平滑的对话流，而成百上千个并行 agent 会制造不可预测的突发压力；更要命的是，agent 需要反复读取和复用大量上下文——llm-d 社区在发布材料中直言，管理这些上下文消耗的资源常常超过生成最终输出本身[1]。上下文即成本，这解释了为什么”前缀缓存命中率”成了推理平台的核心 KPI：命中的前缀不需要重新预填充，而缓存预填充的成本远低于重算。流量越集中、复用越高，单位成本越低——规模效应在推理侧同样成立[3]。
Mistral 的推理工程师团队公开分享的场景很典型：面向交互应用与高并发 API 时，借助 llm-d 的前缀缓存感知路由、流量控制与分离式服务，他们能在不同商业套餐间划定严格的优先级带宽，容量饱和时自动挂起或丢弃低优先级请求，保住付费用户的延迟 SLO[1][8]。Roblox 则强调在混合云与自建 GPU 的异构硬件上获得统一调度能力，且不绑定单一推理引擎[1]。
图：当”优先级”成为调度器的输入，SLO 才真正可控。图源 Unsplash。
这实际上宣告了一个新范式的成熟：负载均衡器从”轮询分发”进化为”理解推理内部状态的调度器”。路由决策第一次深入到了 KV 缓存的分布、请求的优先级与业务套餐——网络工程与机器学习系统工程的边界，在这里正式融合。
六、冷静的一面：繁荣之下的三个隐忧
方向正确不等于一片坦途，至少有三件事值得从业者保持清醒：
第一，利用率鸿沟依旧巨大。 即便所有开源组件触手可及，5% 的行业平均利用率说明：把组件拼成一个能扛住生产流量的系统，仍然是少数团队的技能。分离度越高、组件越多，对 SRE 能力的要求也越高——排障面从”一个进程”扩大到”两条流水线加一张传输网”。
第二，基准与报价之间仍有迷雾。 厂商宣讲的吞吐数字常基于理想化负载，而真实业务混杂着长短不一的上下文与突发流量。行业越来越强调以 goodput（满足 SLO 的有效吞吐）为核心的可复现基准[9]，采购决策应当坚持以自己的流量回放测试，而不是相信 PPT。
第三，碎片化的老问题在重演。 llm-d、NVIDIA Dynamo、各云厂商的推理网关、GKE Inference Gateway 等托管层都在争夺同一层生态位。Kubernetes 时代”上游标准 + 厂商发行版”的格局大概率会重现，但标准收敛前的多轨适配成本，会真实地落在每一个平台团队头上。
图：再精巧的调度器，也要靠工程团队在真实流量中打磨。图源 Unsplash。
对个人开发者与中小团队，务实路径依然清晰：优先用托管推理或成熟 API，把精力放在产品上；只有当规模、数据合规或成本结构触及临界点时，再考虑自建——而自建的第一课，不是调模型，是读文档学调度。
结语：幕后英雄的加冕
AI 行业有个耐人寻味的规律：每当某个环节被公认为”脏活累活”，它往往就是下一个价值高地。训练如此，推理基础设施正在如此。llm-d 1.0 的意义不在于它自己多了不起，而在于它证明了一件事——推理服务的调度、缓存与隔离，已经从各家的内部秘籍，沉淀为开放社区的标准组件。
对行业而言，这是把大模型从”演示品”变成”公共事业”的必经之路：电一旦标准化，创新才会转移到电器上。当模型能力的差距逐渐缩小，谁能把每一个 GPU 小时榨出更多有效 token、把每一次流量洪峰稳稳接住，谁就握住了 AI 商业化的底牌。
就像那位在咖啡馆里随手调用着一个庞大推理网络的开发者——他看不到集群，但他享受的一切，都建立在幕后那场安静的战争之上。
图：最好的基础设施，是让人感觉不到它的存在。图源 Unsplash。
“它必须满足 IT 和 SRE 团队运营生产服务的日常预期。” —— Stephen Watt, Red Hat 杰出工程师[6]
参考资料
- PR Newswire / IBM Newsroom：《llm-d 1.0 Advances Open, Cost-Efficient AI Inference for Production Scale》，2026-10-20
- Cast AI：《2026 State of Kubernetes Optimization Report》
- Inworld AI：《LLM Inference Cost at Scale》，2026-06
- GPUaaS.com：《KV Cache Explained: Cut LLM Inference Costs》，2026-05（含 vLLM 团队 2026-04 FP8 KV 基准）
- Prompt20：《How LLM Inference Works: Prefill, Decode & Disaggregation》，2026
- Techstrong.ai：《llm-d 1.0 Takes Open-Source Kubernetes AI Inference Into Production》，2026-10
- Spheron：《llm-d on Kubernetes: Disaggregated LLM Inference Deployment Guide》，2026
- Google Cloud Blog：《Announcing llm-d 1.0: Open distributed inference for agents on Google Cloud TPUs and GPUs》，2026-10
- IntuitionLabs：《GPU Inference Performance: Prefill, Decode & Batching Explained》，2026