一、先分清三维各指什么

三个词常被混用，先把口径说清。吞吐指单位时间内系统完成的请求量或产出的字元数，衡量的是整体产能，与延迟、成本都不在一个维度上，不能相互替代。延迟指单个请求从发出到收到结果的时间，衡量的是单个用户的体感。成本指支撑这套服务所付出的资源开销，通常折算成单次请求或单位产出的花费。三者描述的不是同一件事：吞吐是系统视角，延迟是用户视角，成本是经营视角。选型时先问自己哪一项是硬约束。在线客服这类场景，延迟是硬约束，用户等不了几秒；离线批量处理，吞吐是硬约束，晚几分钟无人在意；而成本在多数项目里是软约束，但它的弹性有限，超了预算项目就做不下去。先定硬约束，后面所有的取舍都有依据，否则三项指标互相打架，永远得不出结论。

二、延迟要看分位值与两个分段

延迟的测法有讲究。均值会把少数糟糕体验盖住，十个请求里九个快、一个慢，均值看着正常，那个慢的用户体验却很差。所以要看分位值：一半请求在多少毫秒内返回、九成请求在多少、九成九请求在多少。分位值越靠后，越能暴露系统在拥堵时的表现。另外，生成式推理的延迟要拆成两段看：首字延迟与后续生成速度。首字延迟决定用户等多久见到第一个字，感受上颇为敏感；后续速度决定整段回答多久出完。两段的影响因素不同，前者与排队、调度、输入处理有关，后者与解码效率、显存带宽有关。测的时候两段分开记录，优化时也分开处理。另一个实用做法是做延迟预算分解：把端到端延迟拆成排队、输入处理、首字生成、正文生成、网络传输几段，逐段记录占比。有了这份分解，超时的原因一眼可见，也防止把所有问题都归到模型头上。还要留意波动：同样用量下延迟忽高忽低，比稳定偏慢更难受，因为用户无法形成预期。波动大的原因常在调度与批处理策略上，选型时值得多问一句系统怎么排队、怎么凑批。

三、吞吐要看有效吞吐

吞吐数字容易掺水分。标称吞吐是理想状态下的值：请求长度均匀、并发打满、没有排队。真实业务里请求长短不一、有高峰有低谷，有效吞吐往往只有标称的几成。衡量有效吞吐，要在接近真实流量的形态下测：请求长度按实际分布来，并发按实际峰值来，连续跑一段足够长的时间，看单位时间真正处理完的请求量。批处理策略对吞吐影响很大：把多个请求凑成一批同时算，吞吐能翻倍，但批内的每个请求都要等整批算完，延迟随之上升。凑批的窗口越大，吞吐越高、延迟越差，这是三维牵制里很典型的一对。还有一点常被忽略：不同长度请求的吞吐不可直接比较。按字元数算与按请求数算，结论可能相反，对比时务必统一口径，否则两家服务的数据根本不在一张表上。

四、成本要算到单请求

每小时单价是误导性颇大的口径。真正的成本口径是单次请求成本：总开销除以同期处理的请求数。用这个口径衡量，很多便宜的方案会现出原形——单价低但并发上不去，为了扛住峰值要开很多实例，闲置时段大量空转，折算到每个请求上反而不便宜。算成本要包含四块：算力本身、存储与网络、闲置损耗、以及失败重试。推理服务的特殊性在于请求量波动大，资源按峰值预留则低谷浪费严重，按低谷配置则高峰排队，两头都有代价。能弹性伸缩的形态在这一项上占优，但弹性有前提：实例启动要时间，扩容跟不上流量的尖峰。另外，量化压缩对成本的影响值得单独算一笔：把模型压到低精度，显存占用与算力开销同步下降，单卡能服务的并发上升，单位成本可能降一半以上，代价是输出质量略有变化，这笔账要在质量可接受的范围内算。长上下文业务还要单独看：输入越长，处理开销越大，长文本场景的单请求成本可能是短文本的数倍，按典型长度分层核算，比笼统按次数计更贴近真实开销。

五、三维怎么互相牵制

三者的关系可以用两条线描述。第一条线在吞吐与延迟之间：资源固定时，吞吐往上推，队列变长，延迟跟着涨；想压延迟，就要减少排队与凑批，吞吐立刻回落。第二条线在延迟与成本之间：同样的延迟目标，用更充足的硬件、更多的副本能轻松达成，成本随之上升；压缩成本，延迟的分位值就会恶化。吞吐与成本之间倒是方向一致：有效吞吐越高，单请求成本越低，所以真正被夹在中间的是延迟。还有一个常被忽视的现象：延迟的恶化不是线性的，资源用到七八成之前大体稳定，逼近上限后陡然上升。容量规划因此不能按打满设计，留出两成余量，延迟才有缓冲。这也解释了为什么选型要先定延迟底线：底线一定，剩下的问题就变成在吞吐与成本之间权衡，而这两者可以一起优化。常见的优化手段按收益排序：量化压缩、凑批参数调优、缓存复用、更高效的解码实现、硬件换挡。每一项都先在测试环境验证质量与收益，再决定是否上，别在现网上直接改。

六、实测怎么做才可信

宣传数字只能做初筛，决策依据要自己测。实测要注意五点。第一，用真实流量回放：把线上日志脱敏后按原始时序回放，比人造均匀流量可信得多。第二，跑够时长：十分钟的数据容易受缓存与偶然因素影响，至少覆盖一个完整的业务高峰。第三，固定对照条件：两次测试用同一批请求、同一套口径、同一时段的资源保障，否则差异说不清来源。第四，记录资源占用：同样的延迟表现，一个方案占用三成资源、另一个占用八成，扩展潜力完全不同。第五，测失败路径：限流、超时、实例故障时的表现，比正常路径更能区分成熟度。测试结果整理成一张三维对照表：每个候选一行，列延迟分位值、有效吞吐、单请求成本、资源占用与异常表现。有这张表，选型会从凭印象变成看数据；没有它，三家的宣传页根本没法直接比。

七、按场景取舍的核对次序

不同场景的三维权重差别很大，给一份按场景的核对次序。在线对话类：先定延迟底线，重点看首字延迟的分位值与波动，吞吐只要能扛住峰值即可，成本取可行区间。离线批处理类：先看有效吞吐与单请求成本，延迟不设硬约束，但要确认任务能断点续跑。混合形态：把在线与离线拆成两套部署，在线的保延迟，离线的吃剩余算力，比一套部署兼顾两头更实际。增长快的业务：重点测弹性能力，扩容要多久、缩容是否及时，别按当前峰值选死配置。无论哪类场景，都建议先按轻量规模试运行两周，用真实数据填满那张三维对照表，再决定签约规模。试运行的观察点提前列好：高峰期延迟曲线、扩容触发频率、单请求成本走势，三项有了数据，决策就不纠结，也便于向管理层交代取舍理由。选定之后也别一次签太长：推理技术迭代快，半年后同类配置的单位成本可能明显下降，保留一年以内的灵活期，通常比锁定多年更划算。

结语

推理服务的选型，实质是在吞吐、延迟、成本三维之间找业务底线内的可行解。延迟看分位值与首字、生成两段，不看均值；吞吐看真实流量下的有效值，警惕批处理把延迟换走；成本算到单请求，把闲置与量化收益一起算。三维互相牵制，延迟是那根定住不动的轴，先定底线，再在吞吐与成本之间权衡。决策依据靠实测：真实流量回放、跑够时长、固定口径、记录资源占用、测失败路径，末了落成一张三维对照表。有底线、有口径、有数据，选型就有了次序，而不是在三份宣传页之间来回犹豫。