大模型推理降本：不是裁人，是排队

不少人降本第一反应是裁员，模型团队的第一反应是砍算力账单。这两件事里有 80% 重叠。今天说下推理侧最实用的三个开关，都是我们这类小团队真正用过、能写进月度报表的。

开关一：KV Cache，把重复计算变成查表

生成下一个 token 时，模型要看前面所有 token 的 Key 和 Value。朴素实现是每步重算，成本随序列长度平方涨。KV Cache 把这些算好的结果存下来，后续步骤直接查表，单步开销从 O(n²) 降到 O(n)。

实操上要注意两点。第一，显存不是加多少就行，70B 模型开 8K 上下文，单卡 80G 可能装不下 KV Cache，这时优先砍并发而不是砍上下文。第二，多轮对话的 cache 命中率取决于会话管理策略，把会话 key 设成 session_id 比设成 request_id，命中率能从 30% 提到 80% 以上，账单直接砍掉一截。

开关二：量化，精度换字节的明码标价

INT8 比 FP16 省一半显存和带宽，INT4 再省一半。听起来简单，实际部署有个坑：量化损失不均匀。权重层影响小，注意力里的 softmax 附近影响大，低比特下长尾任务（数学、代码）掉点比平均指标凶。

我们的做法是分层决策：主干权重 INT4，输出层和注意力投影保留 INT8。70B 模型全 INT4 能跑在 48G 卡上，这套混合方案掉点在 0.5 个百分点内，业务方无感。省下的不是几张卡，是能多塞 2 倍并发。

开关三：批处理，把碎请求拼成整块

推理 GPU 利用率低，十有八九是请求太碎。单条请求占 GPU 时间片短，启动和切换开销占比高。连续批处理（continuous batching）让新请求随时插入正在跑的批次，把 GPU 占满。

判断值不值有个简单标准：你的请求 P95 延迟要求。如果业务能接受 2 秒内返回，批处理是纯赚；如果要求 200 毫秒内，批处理可能把 P95 推上去，这时不如加卡。我们客服场景 P95 要求 1.5 秒，开批处理后 GPU 利用率从 34% 拉到 71%，单 token 成本降了 40%。

怎么组合这三个开关

顺序很重要：先开 KV Cache（零损失、纯赚），再上量化（有损失、需要评测），最后调批处理（有延迟代价、看业务容忍度）。三个都做完，小团队的推理账单通常能砍到原来的三成。剩下的钱别急着投硬件，先看看有没有请求可以用小模型或规则兜底，那才是更大的头。