推理引擎、显存、并发，这些指标怎么影响真实成本

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-04 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多人在算大模型私有化或自托管成本时，最容易先盯住的是两件事：

• 一张卡多少钱
• 模型需要多少显存

这两个数字当然重要，但如果只看到这里，最后经常会算出一张很“理论正确、线上失真”的成本表。
因为真实成本不是由单一硬件价格决定的，而是由推理引擎、显存占用、并发效率和服务稳定性一起决定的有效产能。

也就是说，真正该问的问题不是“这张卡贵不贵”，而是“这套栈每小时到底能稳定完成多少个有效请求”。

先把真实成本写成一个更像工程的公式

我现在更喜欢这么理解：

单位真实成本
= 基础设施总成本 / 稳定完成的有效请求数

这意味着：

• 同样一台机器
• 同样一个模型
• 不同推理引擎、不同并发配置、不同 KV cache 策略

最后打出来的单位成本可能差很多。

推理引擎影响的，不只是速度，还有“能不能吃满机器”

很多人把推理引擎理解成一个技术实现细节，其实它直接决定：

• 动态 batching 做得怎么样
• KV cache 利用率怎么样
• 长上下文时吞吐掉得多不多
• 多请求并发时队列延迟高不高

也就是说，引擎不同，机器的“有效产能”可能就不同。
同一张卡，如果有的栈只能稳定接 8 个并发，有的能接 20 个并发，后面的单位请求成本当然不会一样。

显存不是越够用越好，而是越接近“可运营边界”越关键

显存问题也常常被理解得太静态。
很多人只算“模型能不能放进去”，但线上真正要看的是：

• 模型权重占多少
• KV cache 占多少
• batch 上来后会不会挤爆
• 留给系统波动和升级的余量有多少

如果显存刚刚够装下模型，但一上长上下文或并发就开始抖，那这套配置在线上就并不便宜，因为它会带来：

• 更高超时率
• 更多排队
• 更频繁的回退或扩容

这些最后都会折回成本。

并发不是越高越省，过了拐点反而更贵

很多团队会天然觉得：并发越高，吞吐越高，单位成本越低。
这在一定范围内通常成立，但过了拐点就会反过来。

因为一旦并发压得太高：

• 排队时延会上升
• p95 和 p99 会变难看
• 超时和取消会增多
• 上层重试会把请求量再放大

于是你本来想省成本，最后可能得到的是：

• GPU 利用率看起来很高
• 但有效成功请求并没有同比增加
• 反而把失败重试成本也抬起来了

这就是典型的“吞吐看着高，真实成本更差”。

一个更现实的看法：成本和时延是一起算的

我后来做这类系统时，几乎不会单独看某一个指标，而会一起盯：

• 每小时机器成本
• tokens/s 吞吐
• 稳定并发上限
• p95 时延
• 超时率
• 单位成功请求成本

因为只有这些指标放在一起，你才能看到真实的运行区间。

一个很常见的误判

举个典型例子：

方案 A

• 单实例成本较低
• 并发压得很高
• 平均吞吐不错
• p95 已经明显偏高

方案 B

• 单实例成本高一点
• 并发更保守
• 吞吐略低
• 时延更稳，失败更少

很多人会直觉选 A，因为看起来“机器利用率更满”。
但如果 A 导致上层更多重试、更多 fallback、更多用户等待，它的真实业务成本可能反而更高。

我现在更愿意做“稳定工作点”测试

现在如果要选推理配置，我不太看单点 benchmark，而更喜欢找每套方案的稳定工作点：

在可接受的 p95 内
最大稳定并发是多少
单位成功请求成本是多少

这比单纯比：

• 峰值吞吐
• 理论显存利用率
• 实验室跑分

更接近线上现实。

真正会影响成本的，还包括上层系统反应

这件事也很重要：推理层的性能变化会传导到整条链。

例如推理层稍微慢一点，上层可能就会：

• 触发超时重试
• 提前 fallback 到更贵模型
• 积压队列，拉高整体等待

于是成本并不是只在推理层多花一点，而是整个系统都开始为这个慢付费。

总结

推理引擎、显存、并发，这些指标怎么影响真实成本？核心答案是：它们共同决定了系统的有效产能，而有效产能才决定单位真实成本。

所以别只看卡价，也别只看模型能不能塞进显存。更该看的，是在可接受时延和稳定性约束下，这套栈到底能持续产出多少“真正完成的请求”。只有这样算出来的成本，才不是纸面成本，而是可以拿去做架构决策的真实成本。