当你的AI原生应用从demo走向生产第一个让你睡不着的往往不是模型能力不够而是账单和延迟。我们团队在做一个面向企业内部知识问答的AI助手时就是被这个问题逼着重新设计了整套推理链路——所有请求无论难易都打到同一个大模型API上高峰期响应时间直接飙到十几秒月底看到成本报表的时候整个人是懵的。后来我们围绕“混合推理”重构了整个架构让简单问题走轻量模型让复杂问题走重型模型中间用路由、缓存、降级把这几条策略串起来最终在延迟和成本上取得了明显的收益。这篇文章就把我们在资源优化与性能调优这条路上踩过的坑、验证过的方法、以及可以直接抄走的配置参数完整复盘一遍。适合正在做AI原生应用的开发者、技术负责人以及那些被推理成本压得喘不过气、又不想牺牲用户体验的团队。1. 混合推理为什么成了AI原生应用的刚需1.1 成本压力用重型模型处理简单问题是最大的浪费先算一笔账。一个典型的AI原生应用比如客服助手、文档问答、代码补全用户请求的复杂度是极端不均匀的。大约80%的请求属于“查个文档”“问个名词解释”“做个简单分类”这类轻量任务真正需要复杂推理、多步骤思考的只有20%。在没有混合推理的架构里所有请求都打到同一个重型模型API上。重型模型的特点是参数规模大、推理需要更多算力、单次调用价格高但它在处理“今天天气怎么样”和“帮我分析这份财报的现金流风险”时消耗的资源是同一个量级。这就像不管寄一张明信片还是一整个集装箱都叫一架货机来送——运力是足够的但成本完全失控。在实际生产环境中这个浪费会被放大。我曾见过一个应用每天调用重型模型API超过300万次其中将近250万次是简单分类和抽取任务。如果把这部分流量切到一个轻量模型上按当时的单价估算每个月光推理费用就能降掉一大半。这不是模型选型的偏好问题是纯数学问题。1.2 延迟红线重型模型撑不住交互场景的响应要求除了成本延迟是第二个卡点。重型模型因为参数规模大首字延迟TTFTTime To First Token本来就比轻量模型高。当请求量上来之后GPU算力被占满排队时间会进一步拉长用户感知到的就是“转圈圈”。我们内部对AI助手有一个硬性要求p95响应时间必须小于2秒。这个指标来自产品团队的调研超过2秒用户就会明显感觉卡顿退出率显著上升。而实际压测中简单问题走重型模型在低峰期勉强能跑到1.5秒高峰期直接变成8到12秒完全不可用。混合推理解决的思路很简单也很反直觉不是让所有请求都变得更稳定而是让大部分请求“根本不需要进入重型模型”。简单请求走轻量模型首字延迟通常在300毫秒以内高峰期也能稳定在1秒内。重型模型只服务少数复杂请求并发压力小了延迟自然也就回到正常水平。1.3 稳定性隐患同质化流量放大了集群波动很多人忽略的一点是稳定性。当所有流量都是同一种请求时它们会互相挤占资源。一个长文档分析请求可能占用几十秒的GPU计算期间其他简单请求只能在队列里排队。一旦出现几个这种大任务整个集群的资源水位立刻抬高形成“小请求给大请求陪跑”的局面。更糟的是这种波动会形成连锁反应。大请求占满显存后新进入的请求可能直接触发OOM或排队超时客户端开始重试重试又加剧了资源竞争最终雪崩。我们线上就遇到过两次这样的情况问题排查到最后根因都不是模型本身而是资源被结构性挤占。混合推理本质上是在架构层面做流量分层把不同特征的请求隔离到不同的执行通道里这样重型任务再夸张也不会拖垮轻量任务的SLA。这是它除了省成本、降延迟之外最容易被忽视但在生产环境中价值极高的一个收益。2. 混合推理系统的整体架构与决策链路2.1 四个核心环节路由、缓存、分级、降级我设计的混合推理网关包含四个核心环节这四个环节的协作关系可以理解为一条完整的决策链路。环节职责核心目标路由判断请求复杂度决定走轻量还是重型模型分类准确率、路由耗时缓存复用已有推理结果避免重复计算命中率、缓存读写延迟分级为不同渠道、不同业务设置不同模型等级成本上限控制降级在异常情况下自动切换或放弃部分请求系统稳定性、成功率网关收到请求后第一步是查缓存如果命中就直接返回第二步是路由判断根据请求内容选择模型通道第三步是在执行过程中动态监控耗时和错误率触发降级策略。这四步环环相扣前一步的决策质量直接决定后一步的执行效果。2.2 路由策略怎么选规则、向量相似度还是可学习分类器路由是整个混合推理的中枢路由策略的设计直接决定了混合推理的收益上限。我在实际项目中试过三种方案各有适用场景。第一种是规则路由。比如通过关键词、文档类型、问题长度、是否有代码块等特征来做判断。这种方式最直接延迟几乎为零而且完全可解释出问题了一看规则就知道原因。缺点是覆盖面有限容易被绕过。比如“这个接口怎么调用”和“这个接口的鉴权原理是什么”长度差不多关键词也重叠但一个是简单查询一个是需要深度解释的复杂问题规则很难区分。第二种是向量相似度路由。预先准备一批“简单问题”和“复杂问题”的代表样本把用户请求转成向量算它跟两类样本的相似度哪个高就往哪边走。这种方式比规则灵活能捕捉语义层面的差异。但有个坑向量模型的稳定性直接决定路由的稳定性。如果前后两个版本的向量模型不一致相似度分数会漂移路由结果就变得不可靠。另外样本库需要持续维护否则新出现的业务场景很容易被误判。第三种是训练一个轻量分类器。比如用几万条标注数据训练一个文本分类模型输出“简单/复杂”的概率分布。这种方式准确率最高但需要标注数据和训练资源对于小团队来说上手成本不低。我们在线上采用的是“规则前置剪枝 轻量分类器兜底”的组合先用规则把那些非常明显的简单请求比如短文本、命中白名单关键词直接放行剩下的模糊请求再交给分类器判断。实测下来这个组合比单用规则误判率降低了约60%。2.3 准确率、延迟、成本的三方权衡混合推理不是一味追求省钱它本质上是准确率、延迟、成本三者的平衡。我见过一些团队把成本压得太狠结果复杂请求也走了轻量模型回答质量下降明显用户流失造成的损失远大于省下的推理费用。我的经验是先把SLA写死再在SLA约束下做优化。比如规定简单请求准确率不低于95%p95延迟小于1秒复杂请求准确率不低于98%p95延迟小于5秒整体推理成本相比纯重型模型方案下降40%以上有了这组约束路由策略的选择就不是凭感觉而是有明确的目标函数。比如当轻量模型在某个类目上的准确率达不到95%时不管它有多便宜这类请求都必须走重型模型。成本优化是在质量红线之内做的事情而不是牺牲质量换成本。3. 资源优化核心细节动态批处理、量化与显存预算3.1 动态批处理让GPU满负荷工作的关键推理服务的吞吐能力很大程度上取决于批处理策略。早期我用的方案是静态批处理攒够N个请求才统一推理或者每隔固定时间推理一次。这种方式实现简单但明显有缺陷——请求量不均匀时要么批量太小造成浪费要么攒批时间过长拖垮延迟。后来换成了连续批处理continuous batching。它的核心思路是当一个请求的推理结束并生成完输出后不等整个批次结束立刻把这个空出来的位置分配给新到的请求。这样一来GPU资源始终在被利用就不会出现“一个慢请求占着茅坑整个批次的其他请求都等着”的情况。在工程实现上要注意两个参数max_batch_size单次推理的最大批大小。并不是越大越好因为注意力机制的计算复杂度会随批大小快速上升太大会导致单个请求的推理延迟明显增加。我在部署中通常设置为16到32之间具体需要结合模型显存占用压测。max_wait_ms攒批的等待时间上限。设置太大会增加队列延迟太小又会降低批大小。我习惯从5毫秒起步压测时观察p50和p99延迟的差值如果差值过大说明攒批等待已经对延迟造成了明显影响需要适当降低。3.2 量化与显存预算分配小模型也要精打细算如果轻量模型是自托管在GPU上的那显存预算就是一门必修课。我们当初在部署轻量模型时第一版直接用了FP16精度一个6B级别的开源模型加载后权重占掉约12GB显存再加上激活值和KV Cache单实例直接吃满一张24GB的卡。后来做了两个调整权重量化到INT8/INT4把模型权重从FP16压缩到INT8显存占用直接减半。推理质量在简单任务上没有出现明显下降因为简单任务的准确率上限本来就不高量化的精度损失完全在可接受范围内。为KV Cache预留固定显存池KV Cache是推理过程中缓存的中间结果大小跟“批大小x序列长度”成正比。如果不做限制长序列请求会把显存全部吃掉导致后续请求直接OOM。我在部署脚本里专门设置了一个max_cache_size参数分配给KV Cache的显存上限超出部分走队列等待而不是抢占。这里有一个计算显存占用的小公式方便各位估算自己的场景单请求显存需求约等于权重显存 KV Cache单请求显存 x 并发数。如果你用的是6B模型FP16权重12GBINT8权重6GBKV Cache按每几KB估算那30并发同时推理时总显存需求大约是6GB 500MB x 30。这个数字如果超出显卡显存基本可以断定需要降并发数或换更大的卡。3.3 模型常驻与连接复用被低估的冷启动开销很多团队的推理服务性能问题不是出在模型推理本身而是出在进程生命周期管理上。我第一次部署时用的是“按需拉起”方案即收到请求再从容器镜像里启动一个推理进程。结果压测出来单次请求延迟高得离谱一查才发现模型冷加载要花几十秒比推理本身还慢。后来改成“常驻Worker进程”方案模型提前加载到显存进程启动后一直监听队列请求。冷启动开销只在扩容时出现平时请求进来直接进入推理循环。在这个基础上还要做连接复用。如果每次请求都新建HTTP连接三次握手的开销在p99统计里非常明显。我们在网关和推理服务之间使用连接池始终保持一定数量的空闲连接实测下来p95延迟减少了大约200到300毫秒这个优化几乎零成本。4. 实操实现从零搭建一个混合推理网关4.1 需求定义与关键决策参数这里用一个模拟项目X来说明我们为某企业搭建的内部AI问答助手上线前定义的需求如下。需求项目标值简单请求占比80%简单请求p95延迟 1秒复杂请求p95延迟 5秒推理成本下降 40%缓存命中率 30%系统可用性 99.5%这组参数决定了系统的容量规划和资源分配。比如简单请求占比80%这个数字告诉我们网关必须能把大量简单请求快速分流到轻量模型而且轻量模型需要部署足够的副本来承载这部分流量。4.2 路由层实现与参数选择路由层是整个系统的决策大脑我给出一个简化版本的核心逻辑作为参考。真实生产环境会在这个基础上增加监控、熔断和各种可配置策略但骨架是通用的。import time import hashlib import numpy as np class HybridRouter: def __init__(self, config): self.simple_model config[simple_model] # 轻量模型通道 self.complex_model config[complex_model] # 重型模型通道 self.rule_keywords config[rule_keywords] # 简单请求白名单关键词 self.classifier config[classifier] # 轻量分类器 self.threshold config[complex_threshold] # 分类器判复杂度阈值 def route(self, query): # 第一步规则剪枝命中白名单直接走轻量模型 for kw in self.rule_keywords: if kw in query: return simple # 第二步用分类器输出复杂概率低于阈值走轻量模型 prob_complex self.classifier.predict_complex_prob(query) if prob_complex self.threshold: return simple # 第三步兜底走重型模型 return complex关键参数有三个rule_keywords典型的有“怎么调用”“怎么安装”“在哪里设置”这类操作性问题通常被认为是简单请求。这个名单需要根据线上日志持续补充每两周复盘一次把误判案例逐步加进去。complex_threshold分类器判断复杂度的阈值默认0.5。调低这个值会让更多请求走重型模型准确率更高但成本也更高调高则相反。我建议用线上采样数据画一个“阈值-成本-准确率”的曲线然后选在成本拐点的位置。4.3 缓存层与降级层实现缓存的核心目标是让重复请求不进入推理链路。第一版我直接用了文本完全匹配同一个问题重复问就能命中。但实际场景里用户问法千变万化“怎么重置密码”“如何重置密码”“密码怎么改”是同一个意图文本完全匹配根本兜不住。所以缓存改成了语义缓存流程是先把请求文本转成向量用向量相似度把历史请求和当前请求做比对相似度超过阈值的视为同一个问题直接返回历史结果。这样做的代价是引入了向量计算延迟和误召回风险阈值设置很关键阈值太高如0.98只有几乎一模一样的问题才会命中缓存命中率上不去。阈值太低如0.80不同语义的问题被当成同一个容易出现答非所问。我实测下来在中文业务场景里0.92到0.95是比较合适的区间具体要根据样本分布调。降级层的逻辑则要简单直白一些。只有在异常情况下才触发不参与正常路径。核心策略有三个超时降级重型模型请求如果超过预定时间阈值自动切换到轻量模型快速生成一个兜底回答然后再异步补充高质量结果。重试退避模型通道返回错误时不立即重试而是按“200毫秒、500毫秒、1秒”的退避间隔逐次拉长避免瞬时故障引发的重试风暴。熔断如果某个模型通道连续错误率达到20%直接打开熔断开关该通道的所有流量在30秒内自动切换到备用通道不再消耗无效的等待时间。5. 性能调优实测与压测结果解读5.1 压测方法与监控指标压测不是拿一个脚本随机打请求就行我总结了一个相对规范的方法准备线上采样流量从真实日志中随机抽取一段时间的请求保证请求类型分布、长度分布、复杂度分布跟线上一致。分三个阶梯测试分别是低并发20并发、中并发50并发、高并发100并发每个阶段持续15分钟记录稳定后的指标。核心监控指标QPS每秒查询数、p50/p95/p99延迟、成功率、显存占用率、推理成本/千请求。我看指标的习惯是p50反映体感p99反映最差情况下的体验两者的差值则揭示排队情况。如果p50很低但p99很高说明系统存在明显的长短请求混跑问题可以通过调整路由策略把长请求隔离开。5.2 三种策略的实测数据对比以下数据来自模拟项目X上线前的一次对比压测数值做了脱敏处理保留参考意义。方案p50延迟p95延迟成功率成本/千次相对成本单一大模型不做混合推理1.8秒8.5秒98.2%2.20元100%混合路由无缓存无降级0.6秒3.1秒97.8%1.30元59%混合路由 缓存 降级0.4秒1.8秒99.1%0.86元39%单一大模型方案的问题印证了开头的判断p95达到8.5秒完全超出可用范围。引入混合路由后p95降到3秒出头成本下降了约40%。这里有个有意思的现象成功率反而微微下降了从98.2%降到97.8%。原因是路由误判的那部分请求进了轻量模型某些原本应该走重型模型的复杂推理在轻量模型上跑不出好结果用户那边表现为“回答质量差”而不是“系统报错”但我们在压测脚本里把它计成了失败。加上缓存和降级之后三个指标同时变好p95降到1.8秒因为大量重复问题直接从缓存返回完全绕开了推理链路成功率回升到99.1%因为降级机制兜住了模型通道偶发错误成本进一步降到纯大模型方案的39%缓存命中贡献了很大一部分。5.3 瓶颈定位与参数迭代的方法压测中发现性能瓶颈时不要盲目调参按照下面的顺序排查先看网关层。如果网关的CPU和内存先到瓶颈说明路由、缓存这些环节消耗了太多资源优先优化这部分代码或增加网关节点数。再看模型通道。如果网关延时不高但整体请求延迟高就要看是模型服务的排队时间还是推理时间。排队时间高说明后端容量不够加副本推理时间高说明批大小、量化级别、显存预算需要重新调整。我们压测中发现过一个有意思的问题随着并发数从50升到100简单请求的p99延迟没有变化复杂请求的p99却从4秒跳到了9秒。排查下来发现是连续批处理策略导致的——当批中混入大量长序列请求时长序列的注意力计算会拖慢整批的所有请求。解决方法是把简单请求和复杂请求拆成两个独立的推理队列各跑各的批处理互不干扰。这个改动上线后复杂请求的p99降回5秒以内线下存量功能稳定运行。6. 常见问题与排查技巧实录6.1 缓存命中率上不去的真实原因缓存命中率是混合推理系统最容易虚标的指标。有段时间我们看到的命中率只有10%远低于设定的30%目标。排查后发现三个问题第一是阈值设得太保守相似度阈值定在0.98导致只有完全相同的问题才会命中稍微改几个字就算不上了。第二是向量模型不稳定缓存写入用的向量和新请求用的向量来自不同版本的模型相似度计算天然有偏差。第三是缓存键设计不合理把用户ID、时间戳这些跟语义无关的字段也拼进相似度计算里导致同一个问题在不同用户下被当成不同问题。这三个问题修正后缓存命中率从10%稳定到了35%。如果你们命中率也上不去优先检查这三项。6.2 路由误判导致用户体验滑坡路由误判是最隐蔽的问题因为它不会报错只会让用户觉得“这个AI变笨了”。症状是简单请求被分到重型模型成本浪费复杂请求被分到轻量模型回答质量下降。我在生产环境里维护了一条误判反馈闭环用户对回答点“踩”之后系统自动记录请求文本和实际路由结果每周做一次聚类分析把高频误判类型补充到规则白名单里或者微调分类器阈值。运营这个闭环半年后路由准确率从86%提升到了93%效果明显。6.3 高峰期雪崩的防护策略即使做了混合推理高峰期仍然有可能打满资源。我们的防护策略是三层而不仅仅依赖模型通道。第一层是全局限流按照业务方申请的资源配额来限制每秒钟进入网关的请求数。第二层是信号量控制并发防止排队的请求过多导致内存爆炸。第三层是熔断降级当整体错误率飙升时弹性地把部分非核心渠道的请求直接引导到缓存结果缓存没有命中就返回一个带可选项的兜底文案。我见过一个团队不设这层保护双重尖峰流量到来时网关直接OOM全站服务不可用恢复了半小时。加了信号量和熔断之后同样的尖峰流量进来最坏情况只是部分请求返回慢系统主体始终保持可用。6.4 成本核算的一个容易被忽略的坑最后提醒一个成本核算的细节。混合推理看起来只是省了API调用费但如果你自托管轻量模型GPU折旧、电费、运维人力都不能漏算。我们算过一笔账轻量模型自托管后单次推理的边际成本确实比商业API便宜但GPU的固定成本摆在那里需要足够的调用量才能摊薄。如果每天的简单请求量低于某个阈值直接调用商业API反而更划算。所以做技术选型时建议把“自托管混合推理”和“全走商业API”分别算一个总成本曲线找到两条曲线的交点这就是切换自托管的盈亏平衡点。低于这个量级的项目老老实实用全API方案可能更合适。我个人在实际操作中的体会是混合推理不是一个可以一次性搭好就丢在那里不管的系统它更像一个需要持续运营和优化配置的持续调优机制。最关键的并不是路由算法多智能、模型多强而是你是否能建立一套可以持续观测、持续调参的闭环——每次压测数据出来每次线上问题复盘都在帮你修正阈值、补充规则、调整资源预算。这套能力跑通后最大的收益其实不是账单减半而是你终于敢把AI能力放到更多真实的业务流程里因为你知道系统在成本、延迟、质量之间依然可控。 
长河君 · 2026/10/20 19:53:56 · 阅读 1.2k 混合推理架构实战：AI原生应用成本与延迟优化指南
当你的AI原生应用从demo走向生产第一个让你睡不着的往往不是模型能力不够而是账单和延迟。我们团队在做一个面向企业内部知识问答的AI助手时就是被这个问题逼着重新设计了整套推理链路——所有请求无论难易都打到同一个大模型API上高峰期响应时间直接飙到十几秒月底看到成本报表的时候整个人是懵的。后来我们围绕“混合推理”重构了整个架构让简单问题走轻量模型让复杂问题走重型模型中间用路由、缓存、降级把这几条策略串起来最终在延迟和成本上取得了明显的收益。这篇文章就把我们在资源优化与性能调优这条路上踩过的坑、验证过的方法、以及可以直接抄走的配置参数完整复盘一遍。适合正在做AI原生应用的开发者、技术负责人以及那些被推理成本压得喘不过气、又不想牺牲用户体验的团队。1. 混合推理为什么成了AI原生应用的刚需1.1 成本压力用重型模型处理简单问题是最大的浪费先算一笔账。一个典型的AI原生应用比如客服助手、文档问答、代码补全用户请求的复杂度是极端不均匀的。大约80%的请求属于“查个文档”“问个名词解释”“做个简单分类”这类轻量任务真正需要复杂推理、多步骤思考的只有20%。在没有混合推理的架构里所有请求都打到同一个重型模型API上。重型模型的特点是参数规模大、推理需要更多算力、单次调用价格高但它在处理“今天天气怎么样”和“帮我分析这份财报的现金流风险”时消耗的资源是同一个量级。这就像不管寄一张明信片还是一整个集装箱都叫一架货机来送——运力是足够的但成本完全失控。在实际生产环境中这个浪费会被放大。我曾见过一个应用每天调用重型模型API超过300万次其中将近250万次是简单分类和抽取任务。如果把这部分流量切到一个轻量模型上按当时的单价估算每个月光推理费用就能降掉一大半。这不是模型选型的偏好问题是纯数学问题。1.2 延迟红线重型模型撑不住交互场景的响应要求除了成本延迟是第二个卡点。重型模型因为参数规模大首字延迟TTFTTime To First Token本来就比轻量模型高。当请求量上来之后GPU算力被占满排队时间会进一步拉长用户感知到的就是“转圈圈”。我们内部对AI助手有一个硬性要求p95响应时间必须小于2秒。这个指标来自产品团队的调研超过2秒用户就会明显感觉卡顿退出率显著上升。而实际压测中简单问题走重型模型在低峰期勉强能跑到1.5秒高峰期直接变成8到12秒完全不可用。混合推理解决的思路很简单也很反直觉不是让所有请求都变得更稳定而是让大部分请求“根本不需要进入重型模型”。简单请求走轻量模型首字延迟通常在300毫秒以内高峰期也能稳定在1秒内。重型模型只服务少数复杂请求并发压力小了延迟自然也就回到正常水平。1.3 稳定性隐患同质化流量放大了集群波动很多人忽略的一点是稳定性。当所有流量都是同一种请求时它们会互相挤占资源。一个长文档分析请求可能占用几十秒的GPU计算期间其他简单请求只能在队列里排队。一旦出现几个这种大任务整个集群的资源水位立刻抬高形成“小请求给大请求陪跑”的局面。更糟的是这种波动会形成连锁反应。大请求占满显存后新进入的请求可能直接触发OOM或排队超时客户端开始重试重试又加剧了资源竞争最终雪崩。我们线上就遇到过两次这样的情况问题排查到最后根因都不是模型本身而是资源被结构性挤占。混合推理本质上是在架构层面做流量分层把不同特征的请求隔离到不同的执行通道里这样重型任务再夸张也不会拖垮轻量任务的SLA。这是它除了省成本、降延迟之外最容易被忽视但在生产环境中价值极高的一个收益。2. 混合推理系统的整体架构与决策链路2.1 四个核心环节路由、缓存、分级、降级我设计的混合推理网关包含四个核心环节这四个环节的协作关系可以理解为一条完整的决策链路。环节职责核心目标路由判断请求复杂度决定走轻量还是重型模型分类准确率、路由耗时缓存复用已有推理结果避免重复计算命中率、缓存读写延迟分级为不同渠道、不同业务设置不同模型等级成本上限控制降级在异常情况下自动切换或放弃部分请求系统稳定性、成功率网关收到请求后第一步是查缓存如果命中就直接返回第二步是路由判断根据请求内容选择模型通道第三步是在执行过程中动态监控耗时和错误率触发降级策略。这四步环环相扣前一步的决策质量直接决定后一步的执行效果。2.2 路由策略怎么选规则、向量相似度还是可学习分类器路由是整个混合推理的中枢路由策略的设计直接决定了混合推理的收益上限。我在实际项目中试过三种方案各有适用场景。第一种是规则路由。比如通过关键词、文档类型、问题长度、是否有代码块等特征来做判断。这种方式最直接延迟几乎为零而且完全可解释出问题了一看规则就知道原因。缺点是覆盖面有限容易被绕过。比如“这个接口怎么调用”和“这个接口的鉴权原理是什么”长度差不多关键词也重叠但一个是简单查询一个是需要深度解释的复杂问题规则很难区分。第二种是向量相似度路由。预先准备一批“简单问题”和“复杂问题”的代表样本把用户请求转成向量算它跟两类样本的相似度哪个高就往哪边走。这种方式比规则灵活能捕捉语义层面的差异。但有个坑向量模型的稳定性直接决定路由的稳定性。如果前后两个版本的向量模型不一致相似度分数会漂移路由结果就变得不可靠。另外样本库需要持续维护否则新出现的业务场景很容易被误判。第三种是训练一个轻量分类器。比如用几万条标注数据训练一个文本分类模型输出“简单/复杂”的概率分布。这种方式准确率最高但需要标注数据和训练资源对于小团队来说上手成本不低。我们在线上采用的是“规则前置剪枝 轻量分类器兜底”的组合先用规则把那些非常明显的简单请求比如短文本、命中白名单关键词直接放行剩下的模糊请求再交给分类器判断。实测下来这个组合比单用规则误判率降低了约60%。2.3 准确率、延迟、成本的三方权衡混合推理不是一味追求省钱它本质上是准确率、延迟、成本三者的平衡。我见过一些团队把成本压得太狠结果复杂请求也走了轻量模型回答质量下降明显用户流失造成的损失远大于省下的推理费用。我的经验是先把SLA写死再在SLA约束下做优化。比如规定简单请求准确率不低于95%p95延迟小于1秒复杂请求准确率不低于98%p95延迟小于5秒整体推理成本相比纯重型模型方案下降40%以上有了这组约束路由策略的选择就不是凭感觉而是有明确的目标函数。比如当轻量模型在某个类目上的准确率达不到95%时不管它有多便宜这类请求都必须走重型模型。成本优化是在质量红线之内做的事情而不是牺牲质量换成本。3. 资源优化核心细节动态批处理、量化与显存预算3.1 动态批处理让GPU满负荷工作的关键推理服务的吞吐能力很大程度上取决于批处理策略。早期我用的方案是静态批处理攒够N个请求才统一推理或者每隔固定时间推理一次。这种方式实现简单但明显有缺陷——请求量不均匀时要么批量太小造成浪费要么攒批时间过长拖垮延迟。后来换成了连续批处理continuous batching。它的核心思路是当一个请求的推理结束并生成完输出后不等整个批次结束立刻把这个空出来的位置分配给新到的请求。这样一来GPU资源始终在被利用就不会出现“一个慢请求占着茅坑整个批次的其他请求都等着”的情况。在工程实现上要注意两个参数max_batch_size单次推理的最大批大小。并不是越大越好因为注意力机制的计算复杂度会随批大小快速上升太大会导致单个请求的推理延迟明显增加。我在部署中通常设置为16到32之间具体需要结合模型显存占用压测。max_wait_ms攒批的等待时间上限。设置太大会增加队列延迟太小又会降低批大小。我习惯从5毫秒起步压测时观察p50和p99延迟的差值如果差值过大说明攒批等待已经对延迟造成了明显影响需要适当降低。3.2 量化与显存预算分配小模型也要精打细算如果轻量模型是自托管在GPU上的那显存预算就是一门必修课。我们当初在部署轻量模型时第一版直接用了FP16精度一个6B级别的开源模型加载后权重占掉约12GB显存再加上激活值和KV Cache单实例直接吃满一张24GB的卡。后来做了两个调整权重量化到INT8/INT4把模型权重从FP16压缩到INT8显存占用直接减半。推理质量在简单任务上没有出现明显下降因为简单任务的准确率上限本来就不高量化的精度损失完全在可接受范围内。为KV Cache预留固定显存池KV Cache是推理过程中缓存的中间结果大小跟“批大小x序列长度”成正比。如果不做限制长序列请求会把显存全部吃掉导致后续请求直接OOM。我在部署脚本里专门设置了一个max_cache_size参数分配给KV Cache的显存上限超出部分走队列等待而不是抢占。这里有一个计算显存占用的小公式方便各位估算自己的场景单请求显存需求约等于权重显存 KV Cache单请求显存 x 并发数。如果你用的是6B模型FP16权重12GBINT8权重6GBKV Cache按每几KB估算那30并发同时推理时总显存需求大约是6GB 500MB x 30。这个数字如果超出显卡显存基本可以断定需要降并发数或换更大的卡。3.3 模型常驻与连接复用被低估的冷启动开销很多团队的推理服务性能问题不是出在模型推理本身而是出在进程生命周期管理上。我第一次部署时用的是“按需拉起”方案即收到请求再从容器镜像里启动一个推理进程。结果压测出来单次请求延迟高得离谱一查才发现模型冷加载要花几十秒比推理本身还慢。后来改成“常驻Worker进程”方案模型提前加载到显存进程启动后一直监听队列请求。冷启动开销只在扩容时出现平时请求进来直接进入推理循环。在这个基础上还要做连接复用。如果每次请求都新建HTTP连接三次握手的开销在p99统计里非常明显。我们在网关和推理服务之间使用连接池始终保持一定数量的空闲连接实测下来p95延迟减少了大约200到300毫秒这个优化几乎零成本。4. 实操实现从零搭建一个混合推理网关4.1 需求定义与关键决策参数这里用一个模拟项目X来说明我们为某企业搭建的内部AI问答助手上线前定义的需求如下。需求项目标值简单请求占比80%简单请求p95延迟 1秒复杂请求p95延迟 5秒推理成本下降 40%缓存命中率 30%系统可用性 99.5%这组参数决定了系统的容量规划和资源分配。比如简单请求占比80%这个数字告诉我们网关必须能把大量简单请求快速分流到轻量模型而且轻量模型需要部署足够的副本来承载这部分流量。4.2 路由层实现与参数选择路由层是整个系统的决策大脑我给出一个简化版本的核心逻辑作为参考。真实生产环境会在这个基础上增加监控、熔断和各种可配置策略但骨架是通用的。import time import hashlib import numpy as np class HybridRouter: def __init__(self, config): self.simple_model config[simple_model] # 轻量模型通道 self.complex_model config[complex_model] # 重型模型通道 self.rule_keywords config[rule_keywords] # 简单请求白名单关键词 self.classifier config[classifier] # 轻量分类器 self.threshold config[complex_threshold] # 分类器判复杂度阈值 def route(self, query): # 第一步规则剪枝命中白名单直接走轻量模型 for kw in self.rule_keywords: if kw in query: return simple # 第二步用分类器输出复杂概率低于阈值走轻量模型 prob_complex self.classifier.predict_complex_prob(query) if prob_complex self.threshold: return simple # 第三步兜底走重型模型 return complex关键参数有三个rule_keywords典型的有“怎么调用”“怎么安装”“在哪里设置”这类操作性问题通常被认为是简单请求。这个名单需要根据线上日志持续补充每两周复盘一次把误判案例逐步加进去。complex_threshold分类器判断复杂度的阈值默认0.5。调低这个值会让更多请求走重型模型准确率更高但成本也更高调高则相反。我建议用线上采样数据画一个“阈值-成本-准确率”的曲线然后选在成本拐点的位置。4.3 缓存层与降级层实现缓存的核心目标是让重复请求不进入推理链路。第一版我直接用了文本完全匹配同一个问题重复问就能命中。但实际场景里用户问法千变万化“怎么重置密码”“如何重置密码”“密码怎么改”是同一个意图文本完全匹配根本兜不住。所以缓存改成了语义缓存流程是先把请求文本转成向量用向量相似度把历史请求和当前请求做比对相似度超过阈值的视为同一个问题直接返回历史结果。这样做的代价是引入了向量计算延迟和误召回风险阈值设置很关键阈值太高如0.98只有几乎一模一样的问题才会命中缓存命中率上不去。阈值太低如0.80不同语义的问题被当成同一个容易出现答非所问。我实测下来在中文业务场景里0.92到0.95是比较合适的区间具体要根据样本分布调。降级层的逻辑则要简单直白一些。只有在异常情况下才触发不参与正常路径。核心策略有三个超时降级重型模型请求如果超过预定时间阈值自动切换到轻量模型快速生成一个兜底回答然后再异步补充高质量结果。重试退避模型通道返回错误时不立即重试而是按“200毫秒、500毫秒、1秒”的退避间隔逐次拉长避免瞬时故障引发的重试风暴。熔断如果某个模型通道连续错误率达到20%直接打开熔断开关该通道的所有流量在30秒内自动切换到备用通道不再消耗无效的等待时间。5. 性能调优实测与压测结果解读5.1 压测方法与监控指标压测不是拿一个脚本随机打请求就行我总结了一个相对规范的方法准备线上采样流量从真实日志中随机抽取一段时间的请求保证请求类型分布、长度分布、复杂度分布跟线上一致。分三个阶梯测试分别是低并发20并发、中并发50并发、高并发100并发每个阶段持续15分钟记录稳定后的指标。核心监控指标QPS每秒查询数、p50/p95/p99延迟、成功率、显存占用率、推理成本/千请求。我看指标的习惯是p50反映体感p99反映最差情况下的体验两者的差值则揭示排队情况。如果p50很低但p99很高说明系统存在明显的长短请求混跑问题可以通过调整路由策略把长请求隔离开。5.2 三种策略的实测数据对比以下数据来自模拟项目X上线前的一次对比压测数值做了脱敏处理保留参考意义。方案p50延迟p95延迟成功率成本/千次相对成本单一大模型不做混合推理1.8秒8.5秒98.2%2.20元100%混合路由无缓存无降级0.6秒3.1秒97.8%1.30元59%混合路由 缓存 降级0.4秒1.8秒99.1%0.86元39%单一大模型方案的问题印证了开头的判断p95达到8.5秒完全超出可用范围。引入混合路由后p95降到3秒出头成本下降了约40%。这里有个有意思的现象成功率反而微微下降了从98.2%降到97.8%。原因是路由误判的那部分请求进了轻量模型某些原本应该走重型模型的复杂推理在轻量模型上跑不出好结果用户那边表现为“回答质量差”而不是“系统报错”但我们在压测脚本里把它计成了失败。加上缓存和降级之后三个指标同时变好p95降到1.8秒因为大量重复问题直接从缓存返回完全绕开了推理链路成功率回升到99.1%因为降级机制兜住了模型通道偶发错误成本进一步降到纯大模型方案的39%缓存命中贡献了很大一部分。5.3 瓶颈定位与参数迭代的方法压测中发现性能瓶颈时不要盲目调参按照下面的顺序排查先看网关层。如果网关的CPU和内存先到瓶颈说明路由、缓存这些环节消耗了太多资源优先优化这部分代码或增加网关节点数。再看模型通道。如果网关延时不高但整体请求延迟高就要看是模型服务的排队时间还是推理时间。排队时间高说明后端容量不够加副本推理时间高说明批大小、量化级别、显存预算需要重新调整。我们压测中发现过一个有意思的问题随着并发数从50升到100简单请求的p99延迟没有变化复杂请求的p99却从4秒跳到了9秒。排查下来发现是连续批处理策略导致的——当批中混入大量长序列请求时长序列的注意力计算会拖慢整批的所有请求。解决方法是把简单请求和复杂请求拆成两个独立的推理队列各跑各的批处理互不干扰。这个改动上线后复杂请求的p99降回5秒以内线下存量功能稳定运行。6. 常见问题与排查技巧实录6.1 缓存命中率上不去的真实原因缓存命中率是混合推理系统最容易虚标的指标。有段时间我们看到的命中率只有10%远低于设定的30%目标。排查后发现三个问题第一是阈值设得太保守相似度阈值定在0.98导致只有完全相同的问题才会命中稍微改几个字就算不上了。第二是向量模型不稳定缓存写入用的向量和新请求用的向量来自不同版本的模型相似度计算天然有偏差。第三是缓存键设计不合理把用户ID、时间戳这些跟语义无关的字段也拼进相似度计算里导致同一个问题在不同用户下被当成不同问题。这三个问题修正后缓存命中率从10%稳定到了35%。如果你们命中率也上不去优先检查这三项。6.2 路由误判导致用户体验滑坡路由误判是最隐蔽的问题因为它不会报错只会让用户觉得“这个AI变笨了”。症状是简单请求被分到重型模型成本浪费复杂请求被分到轻量模型回答质量下降。我在生产环境里维护了一条误判反馈闭环用户对回答点“踩”之后系统自动记录请求文本和实际路由结果每周做一次聚类分析把高频误判类型补充到规则白名单里或者微调分类器阈值。运营这个闭环半年后路由准确率从86%提升到了93%效果明显。6.3 高峰期雪崩的防护策略即使做了混合推理高峰期仍然有可能打满资源。我们的防护策略是三层而不仅仅依赖模型通道。第一层是全局限流按照业务方申请的资源配额来限制每秒钟进入网关的请求数。第二层是信号量控制并发防止排队的请求过多导致内存爆炸。第三层是熔断降级当整体错误率飙升时弹性地把部分非核心渠道的请求直接引导到缓存结果缓存没有命中就返回一个带可选项的兜底文案。我见过一个团队不设这层保护双重尖峰流量到来时网关直接OOM全站服务不可用恢复了半小时。加了信号量和熔断之后同样的尖峰流量进来最坏情况只是部分请求返回慢系统主体始终保持可用。6.4 成本核算的一个容易被忽略的坑最后提醒一个成本核算的细节。混合推理看起来只是省了API调用费但如果你自托管轻量模型GPU折旧、电费、运维人力都不能漏算。我们算过一笔账轻量模型自托管后单次推理的边际成本确实比商业API便宜但GPU的固定成本摆在那里需要足够的调用量才能摊薄。如果每天的简单请求量低于某个阈值直接调用商业API反而更划算。所以做技术选型时建议把“自托管混合推理”和“全走商业API”分别算一个总成本曲线找到两条曲线的交点这就是切换自托管的盈亏平衡点。低于这个量级的项目老老实实用全API方案可能更合适。我个人在实际操作中的体会是混合推理不是一个可以一次性搭好就丢在那里不管的系统它更像一个需要持续运营和优化配置的持续调优机制。最关键的并不是路由算法多智能、模型多强而是你是否能建立一套可以持续观测、持续调参的闭环——每次压测数据出来每次线上问题复盘都在帮你修正阈值、补充规则、调整资源预算。这套能力跑通后最大的收益其实不是账单减半而是你终于敢把AI能力放到更多真实的业务流程里因为你知道系统在成本、延迟、质量之间依然可控。