开源模型+三层缓存替代商业 API，企业 AI 成本直降50万

1. 项目背景从一份刺眼的 API 账单说起1.1 先算清楚一年 50 万的 API 费用到底花在哪年初公司定年度预算研发这边压力最大。我们内部 AI 系统已经上线两年多覆盖客服工单分类、文档问答、代码辅助、合同关键信息抽取这些场景。业务方用习惯了量一直在涨可我打开云厂商的账单一看月均 API 费用已经到四万五左右年化下来就是五十五万上下再算上偶尔的突发流量逼近六十万。老板看到这个数字第一反应是问能不能把量砍一截。但业务都在靠这些能力砍功能等于砍生产力这条路走不通。我就把账单拉出来按场景做了个拆解。数据很直白客服工单分类调用量最大占了总 token 的 35% 以上但绝大多数是短文本问题模式高度重复很多用户问的几乎是一模一样的句子。文档问答和合同抽取占了大约 40% 的 token单次调用长度大但不少是同一份文档被反复提问答案早就生成过了还要再付费生成一遍。代码辅助场景调用量不大可平均输出 token 很长单价高费用占比居然超过 20%。换句话说一半以上的费用都花在了重复计算和低价值计算上。这里要说明一个关键认知商业 API 是线性计费模型调用量翻倍成本直接翻倍。系统的价值越高用得越多账单就越失控。这不是某家云厂商定价贵的问题而是按 token 计费的逻辑天然不适合高频内部应用。把账单拆到场景粒度之后我基本确定了一个方向换一套成本曲线更平的技术底座同时把重复计算拦在模型调用之前。1.2 换思路为什么开源重构能把成本曲线压平当时团队里有人提议换个更便宜的商业模型算下来确实能降一部分但幅度有限而且质量要打折。我坚持走开源方案理由有三层开源模型是本地部署推理成本主要是硬件折旧和电费跟调用量基本解耦。一套几万元的 GPU 服务器哪怕一年只跑 20% 的利用率也比按 token 计费便宜得多。这是成本曲线变平的根本原因。而且数据不出内网对合同、客服记录这种敏感内容来说合规压力小很多。第三个理由是可以定制内部术语、业务规则可以通过微调和检索增强写进模型这是闭源 API 很难做到的。方案确定之后我给自己定了几条设计原则。第一先隔离再替换新老链路并行跑业务方无感切换。第二利润守恒不能为了省钱把响应质量打到不可用哪怕保留少量商业 API 做兜底。第三所有改造都要有数据记录每一分钱省在哪都要能说清楚。这套原则在后面几个月的推进中反复帮我做决策尤其是业务方质疑输出质量的时候灰度数据和兜底机制就是最好的说服工具。技术栈上我用开源模型做主力推理开源推理框架做高性能部署开源模型网关做统一接入和路由再配合向量数据库做语义缓存整体替换掉原来直接调用商业 API 的架构。业务代码改动很小因为本地推理服务兼容 OpenAI 接口格式。如果你想复现这套方案下面每个环节我都会把选型逻辑和实操细节展开讲。2. 开源方案选型五个构件组成一套可用系统2.1 模型层按任务难度分档小模型扛 80% 请求很多人一上来就想部署一个超大模型觉得效果最好。但内部系统大部分请求并不需要顶配模型的智商硬上大模型就是浪费算力。我的做法是把任务分档每档配一个合适的模型。我把内部场景分成四档。第一档是极简任务比如安全过滤、意图识别、工单粗分类这类任务用 1.5B 到 3B 的小模型就能很好完成延迟低内存占用小。第二档是常规问答客服帮答、常见文档问答7B 到 14B 的模型足够配合检索增强效果明显。第三档是文档级任务长合同抽取、多页资料总结需要 14B 到 32B 的模型上下文窗口和指令遵循能力要够强。第四档是复杂推理和代码生成32B 以上的模型才能保证产出质量偶尔还需要更高级别的推理能力。分档之后实际调用分布很理想前三档模型扛住了大约 80% 的请求量只有极少数复杂问题会走到大模型。而商业 API 只保留一道兜底留给那些本地模型回答质量不达标或者逻辑链特别长的请求。这个兜底比例被控制在 5% 以内费用几乎可以忽略。选型时还要注意开源模型的许可证和中文能力。我优先选中文语料占比高、社区活跃、迭代频繁的系列踩坑概率低。具体型号我不展开推荐但你可以按这个原则去社区看评测、跑自己的测试集别只看榜单分数一定要拿自己业务里的真实问题去测。2.2 部署层量化与显存规划的避坑指南部署环节最核心的是显存规划。公式很简单模型权重大小约等于参数量乘以精度字节数。一个 14B 模型FP16 精度下权重约 28GB8bit 量化约 14GB4bit 量化约 7GB还要额外留出 KV Cache 和推理框架自身的开销通常再乘 1.2 到 1.3 的安全系数。我的经验是优先做 8bit 量化跑主力模型质量损失很小显存占用可控。追求极致吞吐的场景才用 4bit但要注意输出质量可能不稳定尤其涉及合同条款和代码生成。量化格式上优先选社区支持度高的格式方便推理框架直接加载省去转换的麻烦。部署顺序上先把模型放在一台测试机上跑通推理接口压测到目标 QPS确认延迟在可接受范围再考虑扩容。我一开始低估了 KV Cache 的开销14B 模型开着 8192 上下文跑 32 并发显存直接爆掉。后来把最大上下文长度下调到 4096加上限制并发数才稳定下来。所以显存计算不要只算权重KV Cache 才是隐藏的显存放纵犯。推理框架的选择我认准两条硬性要求一是支持 OpenAI 兼容接口业务侧能零改造接入二是自带连续批处理和 KV Cache 管理能把 GPU 利用率拉满。开源的成熟推理框架普遍具备这两个能力社区文档也完善。部署方式上建议容器化镜像直接固定环境切换版本时一键起新服务避免污染宿主机环境。2.3 接入层用网关把商业 API 换成开源模型直接让业务代码去连本地推理服务不现实风险太大了。模型一升级、服务一重启调用方全都感知这不能接受。我在中间加了一层开源模型网关所有业务请求先到网关由网关决定转发给本地模型还是商业 API。这样切流量就是在网关上改一条路由规则业务代码完全无感。网关做四件事统一鉴权所有调用方用一套 Key 管理模型路由按规则把请求分发到不同档位模型失败重试和降级本地服务挂了自动切到商业 API保证可用性成本审计每一笔调用记录模型、token 数、响应耗时月底直接导出成本报表。接入层的配置文件长这样我用简化的 YAML 示例说明思路实际字段以你选的网关文档为准routes: - name: faq_answer model: local-14b match: - category: faq - name: code_review model: local-32b match: - category: code - name: hard_reasoning match: - category: complex fallback: cloud-api-strong fallback_policy: cloud-api-strong: max_retries: 2 timeout_seconds: 30路由规则上线前我先在网关上把请求复制一份做影子流量也就是真实流量照常走商业 API同时复制一份打到本地模型对比两边的输出质量和耗时。影子跑了一周确认本地模型在 95% 的样例上达到可接受水准才正式切量。这个环节千万别省直接全量切换一旦出质量问题整个项目的信任就没了。2.4 本地向量库与检索增强开源方案的第三根支柱光有模型还不够。内部系统的强项应该是企业内部知识而不是通用知识。通用问答用开源模型没问题但涉及内部规章制度、产品逻辑、历史工单的答案模型根本没见过这些内容硬答很容易产生幻觉。所以我在模型前面加了一层检索增强架构也就是把内部文档切片、用 embedding 模型转成向量、存进向量库每次提问先检索最相关的几段内容塞进上下文再让模型基于这些内容回答。这个设计同时解决了两个问题一是准确率明显提升答案有据可依二是减少幻觉模型不再凭空编造内部名词的解释。选向量库和 embedding 模型时我只看开源方案优先选社区活跃、支持中文效果好、能本地化部署的。切片策略上我踩过一个坑一开始按固定 500 字切片结果把合同条款从中间切断检索出来的片段缺胳膊少腿。后来改成按段落和语义边界切片重叠 50 字效果才稳下来。检索不是装完就能用的。embedding 模型选型要用你自己的文档测试相似度召回别用公开榜单直接拍板。文档切片大小、检索返回条数、上下文拼装顺序都会影响最终答案质量必须当成一个持续调优的子系统来对待。我把检索增强和语义缓存放在同一个向量库里一套基础设施支撑两个核心功能后续省了不少运维成本。3. 三层缓存与模型路由省钱的真正主力3.1 第一层精确缓存拦截重复请求换开源模型只是把单价降下来了但如果调用次数不控制省钱效果还是有限。真正的大头收入来自缓存。我做的第一层是精确缓存请求参数完全一致时直接返回上一次的结果不再调用任何模型。实现很简单把请求的关键字段做哈希作为 key 存进 Redisvalue 就是完整响应。设置合理的过期时间比如工单分类结果缓存一天文档问答缓存一小时。上线后我发现客服工单分类这个场景的精确缓存命中率超过了 20%因为业务系统里很多重复工单用的问候语和问题描述一模一样。仅这一层缓存每个月就省掉了五分之一的模型调用量。精确缓存的成本很低几乎可以无脑铺开。但要注意两点业务上要求实时性的数据比如库存查询、价格计算不能套缓存否则会出事故缓存 key 必须包含全量影响输出的参数比如模型版本号模型升级后旧缓存要主动失效。我一开始忽略模型版本号升级模型后还在返回旧结果被业务方投诉了好几次才补上这个细节。3.2 第二层语义缓存解决换个说法再问一次精确缓存只能处理完全相同的请求但用户天然会用不同措辞问同一个问题。比如“发票怎么开”和“如何申请开票”字面上不一样语义上是一回事。第二层语义缓存就是干这个的。核心思路是把用户问题用 embedding 模型转成向量在向量库里做相似度检索如果找到相似度超过阈值的历史问题直接返回那次回答。伪代码大概是def semantic_cache(query: str, threshold: float 0.93) - str | None: q_vec embed(query) hit vector_db.search(q_vec, top_k1) if hit and hit.score threshold: return hit.answer return None这个功能上线后才算把重复计算真正拦住。精确缓存加上语义缓存整体命中率可以做到 30% 到 40%意味着将近四成的请求根本不会进入模型推理。但语义缓存的坑也比较隐蔽阈值设低一点比如 0.8确实能命中更多但会把不相关的问题误判成同一问题答非所问设高一点比如 0.98又只剩下同义改写才能命中收益缩水。我实测下来阈值在 0.92 到 0.95 之间比较平衡具体数值要拿自己的业务数据标定。再提醒一句语义缓存必须加业务隔离。不同场景的问题向量混在一起缓存很容易串答案。我在缓存记录里加了场景标签检索时先按场景过滤基本杜绝了串台问题。缓存冷启动阶段也别急投用两到三周后样本足够命中率才会稳定下来。3.3 第三层模型路由动态分流模型路由本质上是一种按需分配把高价值的复杂请求留给大模型把简单请求交给小模型。我用网关的规则引擎把请求按意图分类再动态分配模型。具体判断依据有两类规则匹配和模型打分。规则匹配跑得快能覆盖大部分场景模型打分给规则覆盖不到的模糊请求兜底。两部分结合起来路由准确率能做到很高。路由规则持续迭代比如代码生成走 32B 模型复杂多跳推理临时申请走最强模型简单的翻译、摘要走 14B。这样每一档模型都在做最擅长的事不会出现用小模型硬扛复杂任务导致质量下滑也不会用大模型处理“请把这段话翻译成英文”这种浪费算力的情况。缓存和路由是配合关系不是替代关系。先查缓存缓存未命中再做路由分流。执行顺序上精确缓存和语义缓存前置因为它们最快路由放到缓存后面只对真正需要推理的请求做分配。整体架构从业务到模型之间是串成一条链的每一层都在过滤请求减轻下一层的压力。3.4 改造前后的成本核算对比省钱效果必须用数字说话。把改造前后的月度成本放在一起看一目了然成本项改造前月度费用改造后月度费用商业 API 调用约 4.2 万元约 0.2 万元仅兜底GPU 服务器折旧0 元约 0.3 万元电费与机房0 元约 0.1 万元运维人力和工具0.1 万元约 0.2 万元合计约 4.3 万元约 0.8 万元月度费用从四万多降到八千附近年化节省接近 42 万。这还没算缓存命中带来的节省如果把缓存减少的模型调用折算进去年化节省超过 50 万。实际执行中我还做了一道附加的节约把最低频的长尾场景暂时降级到更小模型让渡一部分极端情况下的回答质量换取更稳定的成本控制。这套账算完发到管理层后面的资源审批就顺了很多。4. 重构实操全过程与踩坑实录4.1 阶段一先切最高频场景拿到第一批收益重构最忌讳一步到位。我按调用量排序先切了工单分类和合同关键信息抽取这两个场景它们合起来占了 40% 以上的 token 消耗。第一步部署 14B 模型到测试环境导入一批脱敏的真实工单人工跑评测集。评测标准按三类打分完全可用、勉强可用、不可用。14B 模型在主流的工单分类任务上表现超出预期完全可用比例接近 90%但合同抽取的专业术语偶尔不准。于是我把合同抽取暂时保留在商业 API先只切工单分类。切流量用网关注入的方式逐步放大先切 5% 的线上请求观察错误率和延迟半天再放到 20%、50%稳了就全量。这个灰度过程持续了大约一周。业务方只会在模型回答明显不对劲的时候来问所以每次切换前我都准备好了对照样例和兜底方案。第一周跑完工单分类场景成本下降了六成多第一次拿到了明显的收益也让团队对整套方案有了信心。这一阶段的教训是不要同时切换两个高风险场景。合同抽取的专业术语问题如果一开始就暴露很可能影响整体节奏。一次只动一个场景出问题能快速定位也不要让业务方一次性适应太多变化。4.2 阶段二缓存与路由全量铺开第一阶段验证了开源模型能顶住主场景第二阶段开始铺缓存和路由。精确缓存上线最快当天就有效果。语义缓存部署稍慢需要先跑向量化管道把历史问答对灌进向量库再调优检索参数。路由规则的迭代主要靠线上日志看到某个分类频繁被路由到 32B 模型就去分析是不是可以用 7B 模型解决是则调低档位。这个阶段我踩了一个延迟的坑。网关统一接入后逻辑变复杂了一些请求在网关层多了几次序列化和网络往返端到端延迟比直连商业 API 高了 200 多毫秒。我在网关层加了连接复用又去掉不必要的中间态记录才把延迟压回去。优化过程中也要保持监控延迟数据必须明细到每个环节才能定位瓶颈。4.3 阶段三质量兜底、数据回流与灰度省钱之后最重要的事是守住质量底线。我建了一套兜底机制对每个输出做规则校验比如 JSON 格式是否合法、关键字段是否存在不合法就自动重试一次再失败就降级到商业 API。这套兜底机制在合同抽取场景尤其重要一个 JSON 字段缺失可能导致下游流程中断。数据回流是持续优化的关键。每周把线上调用的输入输出日志采样下来挑出回答不达标的样本分析原因。大部分问题集中在知识过时、检索没召回正确内容、指令理解偏差。知识过时靠更新文档库解决检索不到要靠调切片和 embedding 模型指令偏差则整理成数据集做轻量微调。大概跑了两个月模型在内部业务上的表现已经稳定超过最初的商业 API 组合。灰度要一直保留。哪怕模型升级到新版本也必须走灰度流程因为新版可能在某些场景上倒退。我给团队立了规矩没有灰度数据不允许全量切换没有兜底预案不允许上线新模型。4.4 常见问题排查速查表把实际操作中遇到的典型问题整理成一张排查表方便后面接手的人快速上手现象可能原因处理建议启动后显存不足 OOM权重和 KV Cache 超出显存下调最大上下文长度或并发数换更高精度量化增加显卡本地模型回答质量飘模型档位太低或量化过度换高一档模型8bit 量化补检索上下文收集 badcase 微调语义缓存答非所问相似度阈值过低或未按场景隔离调高阈值到 0.92 以上缓存记录增加场景标签定期清理脏数据请求超时或延迟抖动并发突增或推理框架未预热服务启动后预热加队列削峰给网关设置超时和重试降级模型升级后缓存命中旧结果缓存 key 未包含模型版本缓存 key 增加模型版本字段升级时主动清理缓存网关调用商业 API 失败网络波动或 Key 过期配置失败重试和多 Key 轮换设置备用通道这些坑不是一次性踩完的很多是上线运行数周后才暴露。所以定期看日志、看监控还是不能省省下来的钱最终要靠稳定运行来兑现。5. 一点亲身经验与后续扩展5.1 这套方案真正值钱的地方整套重构做完我最大的体会不是省了多少钱而是把内部 AI 系统的成本结构从“按量付费”改成了“固定成本”。一旦推理服务稳定调用量增长带来的边际成本极低预算压力几乎消失。开源方案还带来了一个副产品模型和数据都在自己手里产品迭代的自由度大了很多。以前改提示词要反复调试 API现在可以直接改系统提示、调本地模型测试和上线流程完全自主。再者这套成本数据在汇报中起到了意想不到的作用。当管理层看到月度 API 账单从四万变成八千他们不仅认可了这次重构还主动问能不能把能力推广给更多业务线。技术项目在公司里的价值兑现永远需要可量化的结果作为支点。5.2 后续可以继续扩展的方向这套方案离终点还远我已经在规划几个扩展方向。一个是把成本审计做成自动化报表每周自动生成每个业务线的 token 消耗和费用异常波动直接告警。另一个是把模型路由升级成自动伸缩根据请求实时负载自动增加或回收推理节点进一步降低闲时成本。再有是沉淀一套内部微调流水线把每周积累的 badcase 自动转成训练集持续提升开源模型在垂直业务上的效果。如果你也在折腾类似的项目建议先别急着铺大模型认真盘一盘调用日志找出重复和低效的请求往往省钱的突破口就在那堆不起眼的日志里。