最近好几个团队都在问我同一个问题大模型应用跑通了功能也上线了可为什么流量一起来GPU账单和延迟同时失控我每次都会反问一句你是不是所有请求都丢给同一个最大最强的模型了十有八九回答是肯定的。这种做法效果最稳但也是成本爆炸的根源。把不同难度、不同延迟要求的请求分流到不同规格的模型、不同精度的副本、不同位置的算力上这就是混合推理Hybrid Inference的思路。这篇文章我会把我做资源优化与性能调优过程中总结的架构设计、关键路径和排查链路完整写下来适合正在搭AI原生应用推理服务、或者觉得当前推理链路太贵的读者参考。混合推理看起来像“大模型小模型”的简单拼装但真正落地会发现它牵扯请求分级、路由策略、缓存设计、批处理调度、弹性扩缩等一系列问题。任何一个环节拍脑袋决定都会让系统在观测指标上表现得一团糟。下面我从底层逻辑讲到具体操作最后把实测中踩过的三个大坑完整复盘一遍。1. 为什么AI应用开始“混着跑”单一架构撑不住的三个现实信号1.1 信号一请求难度方差太大一刀切等于浪费算力大多数AI原生应用的线上请求呈典型的“2-8分布”约80%的请求是轻量任务比如摘要、分类、改写、简短问答和意图识别只有20%是长上下文推理、复杂工具调用、多步规划这类重任务。但很多团队从一开始就不做区分所有请求统一走同一个超大参数模型。这么做的代价非常直白成本维度高算力卡的单位时间成本是普通算力卡的十几倍大模型生成100个token的成本可能是小模型的百倍以上。延迟维度简单任务在超大模型里也要经历全量注意力计算首token延迟轻松飙到好几百毫秒用户体验毫无必要地变差。容量维度简单请求占用了昂贵算力的并发额度真正需要大模型的复杂请求反而排队等待导致整体吞吐上不去。我在一个负载测试项目里看过这样的数据简单摘要请求占线上流量72%却消耗了约50%的昂贵算力时长。如果把这些请求中的60%迁移到小模型上高算力池的负载可以直接下降三成复杂请求的排队时间也会显著缩短。这不是靠增加机器解决的而是靠分流。1.2 信号二能力峰值冗余与常态过载并存单一模型架构还有一个很拧巴的现象日常流量下昂贵算力大量闲置而一旦遇到热点事件、大促、集中刷新这类峰值流量复杂请求暴增整个模型池又来不及快速扩容延迟直接崩掉。这背后的本质是“能力的峰度”和“资源的弹性”错配。大模型的巅峰能力是为了极少数的复杂请求准备的但如果把它放在所有请求的必经之路上就相当于让全城所有车辆都走一条八车道高速而普通小路全部废弃。混合推理把轻量请求挡在小模型和低成本算力上相当于把高速路让给真正的重型车辆轻车上普通道路整个路网效率自然就上来了。1.3 信号三上下文复用让“相似请求”占比越来越高AI原生应用和传统API调用有一个明显差别大量请求共享相同的上下文片段。典型场景包括同一个用户多轮会话中的历史消息每次重新全量编码系统级提示词system prompt在所有请求中完全一致RAG场景下同一段知识库文本被大量用户反复提问时来回传入。如果所有请求都从零开始对完整上下文做注意力计算等于每次把同样的内容算了一遍又一遍。混合推理体系通常会配合分层缓存和前缀复用机制把这些重复计算直接截掉。这也是单一模型单链路结构很难做好的优化点——因为它缺少“数据面拆分”的抓手。2. 混合推理的决策层设计从请求进来到模型响应中间发生了什么2.1 请求分级先把流量分出层次才知道该往哪条路走混合推理的第一个关键动作不是在模型层而是在网关层做请求分级。分级不是简单地按关键词匹配而是结合业务规则和模型判断。比较通用的分级特征包括分级维度典型判断方式示例任务类型意图识别模型或规则分类任务、摘要任务、代码修复、长文创作输入长度tokenizer 后长度短上下文1K、中上下文1K-4K、长上下文4K延迟SLA请求头或用户等级在线交互要求 500ms后台任务可容忍 5s能力要求是否需要工具调用、外部知识、长链推理需要工具调用则直接路由大模型语义复杂度小模型置信度简单问答置信度0.95 直接返回否则升级分级可以用硬规则比如“无工具调用的短文本分类请求直接进小模型”也可以用软规则小模型先算一遍输出置信度低再升级。我更推荐“规则为主、模型为辅”的混合路由规则保证可解释性模型兜底处理规则覆盖不到的长尾情况。提示路由层最怕“死路由”。如果一条请求被判定进小模型后永远没有升级通道那么误判带来的幻觉或答非所问就会直接砸在用户体验上。一定要在路由设计里留一条“动态升级”的路小模型置信度低、超时或触发了安全校验都要有明确的重定向机制。2.2 多级模型池的规格划分与运行时隔离我把混合推理的模型池分成三级这三级不是拍脑袋分的而是按“参数量级 × 量化精度 × 部署位置”三个维度组合出来的模型层级参数量级参考量化方式典型场景吞吐特征成本特征L0 端侧/轻量1B-4BINT8/INT4打招呼、短文本分类、简单问答极高支持高并发几乎可以忽略L1 线上小模型7B-14BINT8/FP16摘要、改写、实体抽取、简单QA高单卡可承载大流量数十倍低于大模型L2 大模型70B以上FP16/INT8量化复杂推理、工具调用、长文生成低需要多卡或高算力卡成本与延迟都最高特别强调一下隔离问题三个层级的模型不要共用同一个服务实例否则小模型会被大模型的显存占用和调度抢资源。比较稳妥的做法是每个层级的模型池独立部署队列独立、批处理独立、缓存独立。它们之间只通过路由网关通信。2.3 级联队列与超时逃逸延迟链路上的暗雷多级模型带来一个单模型架构没有的麻烦——级联队列。一个请求可能先在小模型排队处理超时后又升级到大模型又排一次队。如果不做控制用户感受到的延迟不是“小模型的延迟大模型的延迟”而是“两个队列的排队时间叠加”。因此网关必须具备三个能力延迟预算从入口就给每个请求分配一个总延迟预算比如简单请求300ms、复杂请求3s。预算内允许一次升级超过预算则直接降级返回或超时终止。逃逸条件小模型在什么情况下升级我建议同时满足“置信度低于阈值”和“剩余预算充足”才升级避免每个超时请求都无脑往大模型甩把大模型变成重试垃圾桶。队列状态感知网关在路由时应该参考下游队列长度而不是只看模型种类。如果L1队列积压严重可以在流量入口就直接分流到L2或者触发扩容。这三个能力缺失任何一个混合推理在低峰期看不出问题高峰一冲就散架。3. 资源优化的四条关键路径模型规格、缓存裁剪、批处理与弹性扩缩容3.1 模型规格选择用“够用”的模型代替“最强”的模型模型选型是资源优化里性价比最高的一步也最容易被跳过。很多团队直接选最大模型理由是“省事、效果有保障”。但推理成本是持续性的只要模型不下线每一笔流量都在为当初的省事买单。我的建议是建立一个任务维度的评测集把线上请求按任务类型拆成若干子集然后逐个测试候选模型的评测分数。判断标准很简单在评测分数下降不超过2-3个点的前提下尽可能选择最小的模型。实际项目里我把摘要任务从L2级别降到L1级别评测分只掉了2分单次请求成本下降62%P95延迟下降约35%。这个收益不需要改任何架构只需要换一条路由规则。选型时还要注意一个细节小模型对提示词的敏感度通常高于大模型。同样一个任务换一个措辞大模型可能无所谓小模型的表现可能波动很大。所以降级后务必做提示词的适配测试必要时把提示词模板也调整一遍。3.2 KV Cache的裁剪与量化从显存里挤出可用容量推理过程中Transformer每一层都要保存历史token的Key和Value矩阵这部分显存占用和序列长度线性相关。在线服务里KV Cache往往会占掉整个显存的一半以上大模型尤其明显。混合推理体系里不同模型规格差异大KV Cache的管理也要分开做。这里有几个立竿见影的手段启用分页显存管理机制让KV Cache按块分配减少碎片和浪费避免显存利用率忽高忽低。对KV Cache做量化从FP16降到INT8显存占用直接减半精度损失在多数任务上可控。但建议先在评测集上验证不要直接上生产。配置合理的最大序列长度和回收策略很多服务把max_seq_len调得过大结果大量显存被预留却根本用不上。按业务实际输入分布设置上限超长请求单独走特殊通道。我见过一个项目把max_seq_len从32K降到8K配合KV Cache量化单实例承载的并发数直接翻了1.6倍而实际业务里超过8K上下文的请求占比不到0.3%。这类“保守配置”反而释放了大量可用容量。3.3 连续批处理与同质合流吞吐提升的引擎静态批处理的做法是等请求攒够一批再一起推理吞吐上去了但延迟很容易不可控。连续批处理continuous batching允许新请求插入到正在执行的批次里边生成边入队能显著提高GPU利用率同时保持单请求延迟稳定。但在混合推理里我对批处理有一个额外的建议做“同质合流”。把同一规格模型、相近输入长度范围、相近生成长度预期的请求合到一个batch里。为什么因为一个batch的生成速度取决于最慢的那条序列。一个短问题和一个长文章生成请求混在同一个batch里生成长度长的那条会拖住整批短请求白白陪跑。把长度差异过大的请求分开整体吞吐反而更高。同质合流会让批处理策略更复杂但收益很可观。我在模拟项目X里做过对比同样流量下启用同质合流后P95延迟下降了28%GPU算力的单位时间产出增加了接近40%。3.4 弹性扩缩容与温冷算力分离混合推理的算力池不能一视同仁。轻量任务所在的服务实例应该具备秒级扩缩容能力见流量高峰就快速拉起重任务所在的高算力池则要保持相对稳定避免频繁扩缩带来的调度开销和模型加载时间。扩缩容触发条件建议同时看两个指标队列堆积网关层各队列的平均等待时间超过阈值GPU利用率连续几分钟利用率高于80%同时存在排队则扩容。还要注意缩容方向不能太激进。推理服务扩一个实例需要重新加载模型权重冷启动可能花几十秒甚至几分钟。如果你用“利用率低了就立刻缩容”下一个高峰来临时扩容跟不上服务直接被压垮。我的经验是至少保留20%-30%的冗余容量宁可利用率低一点也要保证缓冲空间。4. 性能调优的度量体系延迟、吞吐与成本三元组的取舍实战4.1 先建指标再谈优化没有度量就没有收敛混合推理的调优比单模型复杂因为它牵涉路由、多级队列、缓存、批处理多个环节。我建指标时一定拆到最细至少包含以下维度指标类型具体指标用途延迟首token延迟TTFT端到端延迟P50/P95/P99判断用户体验与排队情况吞吐每秒请求数RPS每秒生成token数缓存命中率判断系统承载能力与冗余计算成本单次请求成本每百万token成本高算力池利用率判断资源花费是否合理路由各层模型流量占比升级率超时逃逸率判断分级策略是否在正常工作我调试时有一个固定的排查顺序先看P95延迟延迟异常则看队列平均等待时间队列没问题就看缓存命中率缓存没问题就看路由升级率。换句话说先定位“慢在哪一层”再决定“调什么参数”。如果一上来就乱调批处理参数往往治标不治本。4.2 参数调节顺序不要一上来就动batch size很多资料喜欢把max_batch_size和max_wait_tokens放在调优第一步但我踩过几次坑后总结了更适合混合推理的调节顺序先放宽客户端超时和重试策略把超时重试风暴排除掉这部分我后面会展开再调批处理窗口每次只动max_batch_size或max_wait_tokens中的一个观察P95和吞吐的变化确认批处理稳定后再调KV Cache预留与显存分配把OOM率压到0最后才动路由策略比如升级阈值、逃逸条件和各层流量占比。为什么要这个顺序因为批处理和缓存的问题会放大路由问题的表象。如果路由升级率正常、但批处理窗口过大导致延迟飙升你可能会误判成“小模型能力不行”然后错误地把流量切到大模型成本瞬间翻倍却没能解决问题。4.3 延迟预算拆解把看不见的排队摊在明面上一次请求的总延迟由这些部分构成网络往返RTT网关排队时间tokenizer编码时间模型首token延迟包含预填充阶段逐个token的生成时间输出解析与反序列化时间。其中网络、tokenizer、反序列化通常是百毫秒内的固定开销变化最大的是网关排队和模型延迟。实际调优中最重要的判断是模型计算延迟占比高说明算力吃紧排队延迟占比高说明并发调度有问题不一定是模型慢。混合推理里我会给每个路由通道设一个延迟预算。以简单请求为例总预算500ms网络100ms、排队50ms、模型计算250ms、生成与解析100ms。当监控显示排队超过100ms就说明该通道的并发或批处理设置需要调整。预算拆解的意义在于把“慢”这个笼统的感受变成可操作的定位结论。5. 实测中踩过的坑从路由命中率暴跌到超时重试风暴的完整排查链路5.1 坑一路由置信度阈值设太高升级率暴涨小模型形同虚设现象是某系统上线一周后成本没降反升P95延迟也在涨。我第一反应是查升级率——结果从预设的5%涨到了30%。也就是说大量请求在小模型跑了一遍后又被升级到L2小模型形同虚设还白白多付了一次推理开销。完整排查链路如下看路由层指标升级率从5%涨到30%命中率却正常直接锁定路由策略异常看小模型单独延迟单独压测P95正常排除小模型本身性能问题追日志看升级原因发现大量升级请求的路由judgment逻辑命中了“置信度低”条件但置信度低的原因是用户问的是情绪类、讽刺类问题小模型输出时置信度天然偏低找到根因路由规则把所有置信度0.95的请求都升级而这类请求恰好占比高解决给简单任务开一条“中档模型通道”置信度在0.8-0.95之间的请求先走中档模型置信度0.8才走L2同时把小模型的提示词增加了一个“情感判断”前缀帮助置信度稳定。修复后升级率从30%回落到7%成本恢复预期P95延迟还下降了约12%。这个坑给我们的教训是置信度阈值不是越高越安全它需要和线上请求的真实分布对齐否则就是拿大模型给分类器兜底。5.2 坑二动态字段击穿前缀缓存缓存命中率只有3%另一个项目的现象很典型显存持续上涨服务频繁OOM观测面板上缓存命中率只有3%。当时我怀疑是缓存逻辑没有生效追查后发现问题出在缓存key的构造方式上。完整排查链路如下看缓存命中率3%基本等于没缓存看缓存key的拼接逻辑发现prompt构造时把session_id、用户ID这类动态字段拼在了系统提示词之前验证根因同一个知识库问题两个不同用户请求的prompt前缀完全不同token级前缀缓存永远无法命中解决对prompt做规范化系统提示词固定在首段动态字段session_id、用户信息统一放入显性分隔符之后并在送入缓存key计算前先剥离额外优化在提示词级缓存之外叠加一层语义缓存完全相同的业务意图直接返回历史结果。修复后缓存命中率从3%涨到了47%显存占用降了一半OOM消失。这个坑提醒了我一个通用原则前缀缓存的命中和prompt的结构化程度强相关而AI原生应用的prompt经常是字符串拼接拼出来的不规范化上层优化全是空谈。5.3 坑三客户端超时设置比P99还短重试风暴把服务打挂这个事故印象特别深刻。某系统某天下午请求成功率突然掉到50%GPU利用率冲到100%但新的有效推理请求其实并不多。看面板第一眼像算力不够实际是客户端调度出了问题。完整排查链路如下看服务端监控P99延迟约280ms看起来不算差看客户端配置超时时间300ms比P99还短等于服务端每100个请求里有1个会超时看重试策略超时后客户端会重试2次每次重试都会把请求重新塞进队列而重试请求又会遇到同样的问题验证风暴机制GPU利用率接近100%但有效产出很低说明大量算力在处理超时重试的重复请求正常请求反而排不上队解决客户端超时从300ms放宽到1200ms重试策略改为指数退避加随机抖动同时在网关层加了熔断逻辑当某个通道错误率超过阈值时自动暂停转发后续验证一周内无同类事故P95延迟反而稳定在250ms附近。这个坑本质上不是模型慢而是调用方和服务方的时间假设不一致。混合推理里多级路由本来就会引入额外排队客户端超时参数必须基于实测P99而不是想当然的“越快越好”。6. 我现在用的推荐配置与后续可扩展方向6.1 三级模型体系配置参考结合前面这些经验我现在给新项目做混合推理时通常直接采用这套配置L0/端侧或轻量通道处理打招呼、简单分类、短文本匹配等请求量化到INT8走CPU或低端算力即可不设重试L1/线上小模型通道承载约70%的流量包括摘要、改写、结构化抽取、简单QA量化到INT8独立队列和批处理缓存优先L2/大模型通道承载能力最强也最贵的那部分流量包括长文推理、工具调用、代码生成、多步规划保持FP16或INT8高质量运行并设置严格的逃逸保护。网关层统一负责请求分级、延迟预算、动态升级和重试熔断。每个通道的监控面板分开路由升级率、各层占比、缓存命中率必须单独成图。6.2 性价比极高的几个优化动作如果团队时间有限按性价比排序我建议先做这几件事prompt规范化加前缀缓存把动态字段彻底从公共前缀里拆出来缓存命中率通常能提升30个百分点以上这是投入产出比最高的一步简单任务改走轻量通道先按任务类型和输入长度各切10%流量验证效果确认质量不降再逐步放量批处理做同质合流把长短请求分开合批照顾P95延迟和吞吐的平衡客户端重试改成指数退避加抖动这一步既不花钱又不改动模型却能在尖峰流量下保住可用性。6.3 后续可以继续扩展的方向这套体系稳定后可以继续加一层更细的能力全链路可观测性给每个请求打上“路由标签”记录它走了哪个通道、是否升级、升级原因是什么、实际生成了多少token。没有这些标签你永远只能猜测流量分布而不是看到流量分布。语义缓存从token级缓存升级到“同一业务含义直接返回历史结果”对重复性业务比如客服问题、报表查询特别有效但需要加一层相似度判断和结果新鲜度控制。Agent场景下的分层推理复杂Agent任务里简单工具调用和中途步骤不一定要实时调用大模型可以用规则模板或轻量模型替代只保留最终聚合和关键决策走大模型。最后再分享一点个人体会。混合推理本质上不是“用谁替代谁”而是在所有请求进来之前先想清楚这个请求到底需要多强的模型才能让用户满意。我们团队初期把大量精力花在调大模型效果上后来调整方向先做请求分级和模型瘦身整体用户体验反而变好了成本还降了一大截。建议你从两件事开始把线上日志按请求难度分一下类给重复前缀加一层缓存跑一周看指标变化收益会比想象中直观很多。
报错到音视频方案)
