LLM 推理成本优化实战把单位 Token 成本降下来的六条路径一、成本问题为什么是生产落地的头号敌人很多团队在 Demo 阶段从不担心成本一旦进入生产环境账单会教做人。大模型服务的成本结构里输入 token 常常占总消耗的 80% 以上——而这部分大部分是几乎不变的系统提示词、知识库片段和对话历史。与此同时不同请求对模型能力的需求差异极大简单问答和复杂推理用同一个模型等于为 80% 的简单请求支付了 100% 的算力。本文整理六条经过验证的成本优化路径从不换模型就能省到换架构才能省按实施难度排序你可以根据自己的阶段逐步落地。二、路径一前缀缓存Prompt Caching——性价比最高的第一刀真实在线推理请求通常长这样System Prompt800 token 多轮历史2000 token 新消息50 token。多轮对话的后续轮次、RAG 场景的文档问答、模板批处理任务都存在大量共享前缀。如果每次都从头重算这些前缀的 KV Cache浪费巨大。vLLM 的自动前缀缓存APC把 token 序列切成固定大小的块默认 16 token每个块用链式哈希唯一标识维护全局哈希表新请求到达时逐个查哈希命中的块直接引用物理块只计算未命中的部分。实测效果多轮对话同会话前缀命中率 80%-95%后轮 prefill 时间趋近于零RAG 文档问答命中率 60%-85%模板批量处理 1000 个相同模板请求只算一次前缀命中率 90%。实践要点静态内容放前面系统指令、文档放在 prompt 开头动态的用户消息放后面避免前缀里有动态元素时间戳、随机数会让整条缓存链失效放到 prompt 末尾调大 gpu-memory-utilization 让缓存池更大、LRU 淘汰更少。开启方式–enable-prefix-cachingV1 引擎默认开启、–enable-prompt-tokens-details 可在 usage 里返回 cached_tokens 字段。云厂商同样提供 prompt cachingDeepSeek 的上下文硬盘缓存、OpenAI 的自动缓存缓存命中价格约为 1/10——命中部分按缓存价计费长期稳定前缀的成本可以降到十分之一。三、路径二模型分层路由——让合适的模型干合适的活一个被严重低估的杠杆80% 的请求可能只需要小模型大模型只处理复杂子集。生产实践中按任务复杂度路由到不同模型综合成本能再降 40%。落地方式在网关层加一个路由决策器先让一个小模型或规则对请求做分类——简单查询天气、FAQ、格式转换走小模型复杂推理代码生成、长文分析、多步任务走大模型。也可以用级联模式先小模型尝试置信度低再升级到大模型。模型分层 前缀缓存组合成本可以降到原来的 1/10 以下。实测原则先统计你线上请求的分布——如果 60% 是短输入短输出的事实性问题换小模型的收益立竿见影。注意小模型选型要匹配任务中文场景 DeepSeek、Qwen 系列小模型效果已经很能打。四、路径三量化——显存和带宽双降量化把权重从 FP16/BF16 压到 INT8、INT4 等格式减少显存占用和内存带宽。以 Qwen2.5-7B 为例FP16 约 14GBINT8 约 8GB精度损失极小INT4 约 4.5GB精度损失可接受。70B 级别模型 4-bit 量化把显存需求从 140GB 降至 35GB。量化不是免费午餐精度和兼容性要实际测试不要只看显存下降。vLLM 原生支持 AWQ、GPTQ、FP8社区反馈 AWQ 略快于 GPTQ差距 5% 以内。本地部署跑不动完整精度模型时量化是最直接的方案量化后同样的 GPU 能承载更多并发单位 token 成本随之下降。五、路径四KV Cache 优化——长上下文的隐形杀手KV Cache 是推理显存占用的大头大小和序列长度成正比。越长的对话、越大的并发KV Cache 越恐怖。优化方向有三个KV Cache 量化对 KV Cache 做低比特量化FP8、INT8几乎不损失精度的情况下把显存占用降低一半支持更长上下文或更高并发。KV Cache 共享多个请求共享相同前缀system prompt、few-shot 示例时可以物理共享同一块显存——这正是 vLLM PagedAttention 的核心能力配合前缀缓存大幅降低重复计算。上下文管理应用层的长上下文不一定要全量传给模型。生产经验保留 system 消息和最近几轮对话中间部分让模型生成摘要既省 token 又不丢关键信息。RAG 场景更要控制送入的片段数量和长度避免上下文窗口溢出和 token 浪费。六、路径五批处理与调度优化——把 GPU 喂饱GPU 是成本的大头喂饱 GPU 就是省钱。vLLM 的连续批处理Continuous Batching在 token 级别动态调度请求生成完立刻释放资源、新请求马上补进来GPU 几乎一直在算有效 token。实测吞吐相比 HuggingFace Transformers 提升 24 倍同样的 GPU 资源承载数倍请求量。Chunked Prefill 把长 prompt 拆成小块避免一个超长输入独占 GPU 数百毫秒卡住其他请求在线服务的延迟和吞吐同时受益。离线批处理按输入长度分组分批避免长输入让 batch 里短输入的 padding 变多max_tokens 按业务分开设置不要统一设很大。七、路径六评估驱动的成本治理成本优化最怕省了钱丢了质量。必须建立量化评估体系任务成功率、工具调用准确率、答案忠诚度、延迟P50/P95在优化前后都要对比。没有评测集就上线等于裸奔。可观测性必须埋点每条请求记录 trace_id、调用的模型、输入/输出 token 数、延迟和成本。用 LangSmith、Langfuse、Phoenix 追踪完整链路。建立 token 成本预算和告警按天/按用户/按场景统计成本异常突增时能定位到具体功能。RAG 应用里输入 token 常常占总消耗的 80% 以上其中大部分是几乎不变的系统提示词和知识库片段——前缀缓存 模型分层是优先级最高的两刀。八、计费与监控的实操细节自托管推理的计费有深坑缓存命中 token 你的实际成本是正常价的 1/10 甚至更低但用户按全量 prompt_tokens 计费——prompt_tokens 是用户计费基础cached_tokens 是你的实际成本基础中间差价就是自托管服务的利润空间。中间件应该同时记录两个字段。监控指标前缀缓存命中率用 PromQLrate(vllm_prefix_cache_hits[5m]) / rate(vllm_prefix_cache_queries[5m])、KV Cache 内存块命中率90% 为优、批处理效率有效 token 占比、单位请求成本。命中率偏低时检查前缀是否被动态内容污染、缓存池是否太小、模板是否没放在 prompt 开头。九、综合案例一个 RAG 应用的降本路径一个典型的企业 RAG 问答应用优化前每请求约消耗 4000 输入 token 200 输出 token成本大头在知识库片段和系统提示词。降本路径第一步开前缀缓存系统提示词 高频文档片段命中后输入成本降到原来的 1/10第二步模型分层简单 FAQ 走小模型复杂分析走大模型综合再降 40%第三步控制检索数量Top-K 从 8 收到 3-5减少无效片段第四步上下文压缩长片段先生成摘要再拼接。四步叠加单位请求成本通常能降到原来的 1/20 以内而评测指标答案忠诚度、相关性保持不降。十、写在最后成本优化的核心不是抠门而是让每一分算力都产生价值。优先做不换架构就能生效的优化前缀缓存、上下文压缩、检索数量控制再逐步引入架构级优化模型分层、量化、批处理调优。每一步优化都要用评估数据验证防止省了钱丢了质量。记住推理成本的可控性本身就是企业级 LLM 应用的竞争力之一。