北京
同一个70B模型，跑在同一块GPU上，每次请求的成本可以相差八倍。差距不在模型本身，而在你如何配置底层的推理服务。这个差距不是四舍五入能忽略的小数点，它决定了一个项目是停留在业余爱好层面，还是能进入生产环境成为正式成本项。
大多数团队在评估开源模型时，只看基准测试分数，几乎没人关注真正决定能否负担得起的因素——推理服务栈。今天这篇拆解，把影响推理成本的四个关键杠杆讲清楚，并给出一个判断框架：什么时候自建推理服务真的比调用API划算。
先分清两个阶段，再谈优化
推理过程分为两个瓶颈完全不同的阶段。Prefill阶段——读取提示词——是并行的，受计算能力限制。Decode阶段——逐个生成token——是串行的，受内存带宽限制，因为每一步都要把模型权重和不断增长的KV缓存从GPU内存中流式读出。
在动手优化之前，先把首token延迟和token间延迟分开测量。如果GPU利用率低但token间延迟正常，说明是批处理（batching）问题。如果首token延迟占主导，则是prefill或前缀缓存（prefix caching）问题。不先做这个区分就盲目猜测该动哪个杠杆，是团队在投机解码（speculative decoding）上浪费一个月、而真正问题只是批处理大小的常见原因。
四个杠杆，各自能带来什么
量化（Quantization）压缩权重和KV缓存——这两样东西在每一步解码时都要流式读取。从FP16降到FP8，权重内存大约减半，在Hopper级及更新的GPU上几乎无损；通过AWQ或GPTQ用INT4量化，内存降到四分之一，质量损失真实存在但通常很小。
关键点在于：KV缓存量化是大多数团队跳过的杠杆。把键和值从FP16存成INT8，缓存内存大约减半，再配合PagedAttention式的内存管理，有效KV占用能降到原来的4到8倍差距。连续批处理和前缀缓存是免费的杠杆——它们不影响模型质量，只是避免浪费GPU内存和重复计算。投机解码介于两者之间：设计上不影响质量，但增加工程复杂度。
四个杠杆全部叠加，多个来源的报告结果一致：相比H100级GPU上朴素的FP16加静态批处理基线，成本效率提升约5到8倍。更激进的INT4加前缀缓存组合，相比同一基线可削减成本60%到80%。
一个具体案例：AWQ量化的实际效果
Tensoria的一份生产部署文档把AWQ的收益讲得很具体：4比特权重量化相比BF16，显存占用下降60%到70%，在通用基准上质量退化控制在2%以内。在抽取、分类这类窄任务上，退化幅度更小。
这个案例说明，量化不是"牺牲质量换成本"的零和游戏——在多数任务上，质量损失小到可以接受，而成本节省是数量级的。
自建还是调API？一个判断框架
回到最初的问题：什么时候自建推理服务真的比调用API划算？答案取决于你的流量特征和工程能力。
如果请求量稳定且可预测，四个杠杆能叠加出5到8倍的成本优势，自建值得认真考虑。如果流量波动大、峰值难以预估，API的弹性伸缩可能更省心。如果团队没有专门的推理优化经验，贸然自建可能把一个月时间耗在调参上——而那个时间成本，往往比API账单更贵。
核心判断依据是：先测量，再优化。把首token延迟和token间延迟分开看，确认瓶颈在哪个阶段，再决定动哪个杠杆。跳过这一步直接上投机解码，是成本最高的"优化"方式。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
