4 推理成业

4.1 独立成业

模型训练完成，只说明一组参数被求出来了；它没有自动变成用户随时可调用、延迟可预期、故障可恢复、用量可结算的服务。训练解决怎样得到模型，推理解决怎样让模型在真实请求下持续工作。两者可以用同类 GPU，却面对完全不同的输入、状态、瓶颈和失败方式，这是推理独立成产业的根本原因。

训练围绕一个有边界的任务组织：给定数据、目标函数、集群和训练计划，反复更新参数，直到达到停止条件。即使训练持续数月，它仍可以被看作一个大型作业。推理没有明确终点：请求随时到来，长度不同、并发变化、模型版本并存，还要在客户能感知的时间内返回结果。系统目标随之改变：训练在意单位时间处理多少数据、检查点能否恢复；在线推理在意首个 token 何时出现、后续出字是否稳定、突发流量是否排队、错误能否隔离、月末账单能否和请求日志对上。vLLM、Splitwise、DistServe 这些系统工作之所以存在，正是因为固定模型在真实请求下仍有缓存管理、批处理、阶段资源差异和约束内有效吞吐这些新问题。核

推理是一套长期在线的生产系统，远不止训练结束后调用一次模型。这个定位差异贯穿全书：后面所有的技术章节讲这套系统怎么运转，所有的商业章节讲这套系统怎么收钱。

4.2 工程六问

看任何一套推理系统，用六个工程问题拆。这六问也是全书技术部分的阅读框架。

4.3 持续交付

在实验机上成功生成 token，只证明模型、驱动和运行时在某个时刻兼容。要成为产品，还要依次回答：设备是否验收，集群是否联网，镜像和模型能否重复部署，性能基线是否可复现，监控是否覆盖端到端链路，故障能不能转移流量，用户能不能鉴权和限流，用量能不能计费。这条链在第 8 章会正式化为七道闸门。

链上的失败会传导。一个节点显存泄漏，第一步是该副本容量下降；第二步是请求转移到其他副本，队列变长，尾延迟上升，更多请求超出服务目标，继而触发服务信用和客户流失。技术故障经过流量、合同和人的行为，最终变成经济结果，这是技术章节和商业章节必须放在同一本册子里的原因。

收入形态也从这里分化。训练围绕项目、集群时长或模型资产核算；推理收入可以来自按 token 的 API、专用端点、保留吞吐、卡时或运维服务，计量方式不同，风险归属就不同。成本也不止模型计算：设备、机房电力、网络存储、软件许可、运维值守、备件、失败重试、服务信用和资金成本共同构成服务成本。即使一个请求的边际 GPU 成本很低，固定容量也要由当月可计费的 token 分摊。只算售价减卡时，会把局部贡献误写成净利润，第 26 章专门算这笔账。

4.4 两岸会合

技术人员关心调度、缓存和服务目标，BD 关心客户、价格和合同。两边需要对账的是可承诺产能：在指定模型、硬件、负载和延迟约束下，系统能够持续交付多少成功请求，异常时怎样恢复，账单怎样复核。

BD 跳过这一步，会把峰值性能当成可售库存；技术跳过这一步，会把吞吐改善当成商业结果。更高吞吐的直接效果是单位固定成本下降，间接效果则可能是销售报出更低价格、客户把更多业务迁入、负载结构改变，原来的性能基线随之失效。系统必须持续测量，而不是上线前测一次。