1. 大模型服务新格局背后的真实逻辑1.1 从两条产品动态说起最近圈子里讨论最多的两件事一个是某头部对话产品把最新一代通用模型推给了全体用户不再区分付费层级另一个是某轻量级模型直接把价格砍到了原来的十分之一。这两件事单独看都是常规的产品迭代但放在一起看信号就非常明确了——大模型服务的竞争重心正在从“谁的模型更聪明”转向“谁能把足够聪明的模型用足够低的成本铺给足够多的人”。我自己从早期就开始跟踪各类模型API的调用成本和实际输出质量经历过按token计费心疼到不敢多跑测试的阶段也经历过为了省钱用轻量模型结果输出质量拉胯、返工成本更高的阶段。所以这次看到这两个动态第一反应不是“哇又更新了”而是“终于走到这一步了”。这篇文章我想把这两件事拆开揉碎聊聊背后的技术逻辑、对开发者的实际影响以及在这个趋势下我们该怎么调整自己的技术选型和成本模型。1.2 谁该关注这些变化如果你是把大模型能力集成到产品里的开发者这次的变化直接影响你的API账单和用户体验设计如果你是做AI应用层创业的成本结构的改变可能让你原本跑不通的商业模式重新变得可行如果你只是日常使用对话产品的普通用户你也能感知到免费用户能拿到的能力上限在快速抬升。不管你是哪一类理解这背后的逻辑比单纯知道“降价了”“更新了”要有价值得多。2. 旗舰模型全量推送意味着什么2.1 从分层服务到全量覆盖的转变过去两年大模型产品的典型做法是分层免费用户用上一代或轻量模型付费用户才能用到旗舰模型。这个策略的逻辑很直白——旗舰模型的推理成本高需要通过订阅费来覆盖。但这次把最新旗舰模型直接推给全体用户说明两件事一是推理成本已经降到了可以承受全量免费用户的程度二是竞争压力迫使产品方必须用最强能力来留住用户而不是靠功能阉割来区分付费层级。我实测过几个不同层级的模型在相同任务上的表现差异。拿代码生成来说轻量模型在简单函数补全上还行但一旦涉及多文件重构、复杂状态管理错误率会明显上升。旗舰模型全量推送后免费用户也能直接处理这类复杂任务这对整个开发者生态的影响是深远的——以前很多个人开发者因为成本原因只能用轻量模型做原型现在可以直接用旗舰能力来验证想法。2.2 推理成本下降的技术支撑旗舰模型能全量推送核心支撑是推理成本的下降。这里面有几个关键技术方向在起作用。模型架构层面的优化。混合专家架构的成熟让模型在推理时只激活部分参数而不是全量计算。打个比方以前是一个全能团队每个人都要参与每个项目现在是按项目需求只叫相关的人来干活。这样在保持总参数量不变的情况下单次推理的计算量大幅下降。量化与蒸馏技术的进步。把模型从高精度浮点数量化到低精度整数能在几乎不损失输出质量的前提下把显存占用和计算量降下来。我试过对同一个模型做不同精度的量化对比在4bit量化下大部分对话和代码任务的输出质量差异在可接受范围内但推理速度能提升两到三倍。推理引擎的调度优化。连续批处理、分页注意力这些技术让GPU利用率大幅提升。以前一个请求占一块显存现在是多个请求动态共享空闲显存能被充分利用。这部分的优化对成本的影响非常直接——同样的硬件能服务更多用户单位成本自然下降。2.3 对开发者的实际影响旗舰模型全量推送后最直接的变化是原型验证和产品上线的模型选择可以统一了。以前常见的情况是开发阶段用旗舰模型调效果上线时为了省钱换成轻量模型结果发现输出质量下降又得重新调prompt、重新做测试。现在如果旗舰模型本身就对所有用户开放那至少在对话产品这个场景里你可以直接用旗舰能力来做产品不用在模型切换上折腾。另一个影响是用户预期的抬升。当免费用户都能用到旗舰模型你的产品如果还在用上一代模型用户会明显感知到差距。这对做AI应用的人来说是个压力但也是机会——如果你能快速接入最新能力在产品体验上就能拉开身位。注意全量推送不等于无限量使用。大部分产品仍然会有频率限制或并发限制只是不再按模型层级来区分。做产品设计时要把限流策略考虑进去。3. 轻量模型降价九成的连锁反应3.1 价格变化的量级意味着什么一个轻量模型降价九成这不是常规促销而是战略级的定价调整。我算过一笔账假设原来处理一百万token的成本是X降价后变成0.1X。对于日均调用量在千万token级别的应用来说这意味着月度成本从数万元级别直接降到数千元级别。这个量级的变化足以让很多原本因为成本原因被否决的方案重新进入可行性评估。举个具体的场景。做内容审核的团队以前因为成本原因只能用规则引擎加少量模型调用现在可以把所有待审核内容都过一遍模型准确率和覆盖率都会有质的提升。做批量文档处理的场景以前要精打细算哪些文档值得用模型处理现在可以全量处理人工只需要复核模型标记出的可疑项。3.2 轻量模型的能力边界降价归降价轻量模型的能力边界还是要清楚。我自己的测试经验是轻量模型在以下几类任务上表现和旗舰模型差距不大文本分类、意图识别、简单信息抽取、格式转换、短文本摘要。这些任务的共同特点是输出空间有限、不需要复杂推理。但在需要多步推理、长上下文理解、复杂代码生成的任务上轻量模型和旗舰模型的差距仍然明显。我试过让轻量模型做多轮对话中的指代消解在对话轮次超过五轮后错误率会显著上升。所以降价九成不等于可以无脑替换关键是要做任务分层——把适合轻量模型的任务分流过去把复杂任务留给旗舰模型。3.3 成本结构重构的实操思路基于这两个变化我建议重新审视自己的模型调用成本结构。具体可以分三步走。第一步盘点当前所有模型调用场景按任务复杂度分类。简单分类、抽取、转换类任务标记为“轻量候选”复杂推理、生成、多轮对话标记为“旗舰必需”。第二步对“轻量候选”任务做AB测试。用同样的输入分别跑轻量模型和当前使用的模型对比输出质量。这里要注意不能只看单次输出的好坏要看在真实数据分布下的稳定性和错误模式。我一般会跑至少五百条真实样本统计准确率、召回率和人工复核率。第三步设计动态路由策略。不是简单地把任务分配给某个模型而是根据输入特征动态选择。比如同样是文本摘要短文本走轻量模型长文本走旗舰模型同样是代码生成简单函数走轻量模型涉及多文件依赖的走旗舰模型。这个路由逻辑可以先用规则实现后续再考虑用模型来做路由决策。任务类型推荐模型层级理由文本分类/意图识别轻量模型输出空间有限轻量模型足够简单信息抽取轻量模型模式匹配为主不需要复杂推理短文本摘要轻量模型输入输出都短成本敏感多轮对话旗舰模型需要长上下文和指代消解复杂代码生成旗舰模型需要多步推理和依赖理解长文档分析旗舰模型上下文窗口和推理深度要求高4. 模型选型与成本控制的实战方法4.1 建立自己的模型评估流水线不要依赖别人的评测榜单来做选型决策。榜单上的任务和你的实际场景往往差距很大。我自己的做法是建一个轻量级的评估流水线包含三个部分真实样本集、自动化指标、人工抽检。真实样本集从生产环境的日志里采样覆盖各种边界情况。自动化指标根据任务类型来定分类任务看准确率和召回率生成任务看BLEU或ROUGE代码任务看编译通过率和测试通过率。人工抽检每周做一次每次抽五十到一百条重点看自动化指标覆盖不到的维度比如语气是否合适、是否有事实性错误。这个流水线建起来之后每次有新模型发布或者价格调整你都能快速评估是否值得切换而不是靠感觉做决策。4.2 缓存与批处理的降本效果除了换模型缓存和批处理是两个被低估的降本手段。缓存针对的是重复或相似请求——很多应用场景里用户问的问题是高度重复的把常见问题的回答缓存起来能省掉大量模型调用。我做过一个统计在一个客服场景里前一百个高频问题覆盖了约六成的用户咨询量这部分全部走缓存成本直接砍半。批处理针对的是离线任务。很多场景不需要实时返回结果比如夜间批量处理文档、定时生成报表。把这些任务攒起来批量调用一方面可以利用批处理接口的折扣另一方面可以更充分地利用GPU资源。我实测下来批处理的单位成本能比实时调用低百分之三十到五十。4.3 监控与告警机制成本控制不是一次性的工作需要持续监控。我建议至少监控三个指标每日token消耗量、单位请求平均成本、缓存命中率。这三个指标能帮你快速发现异常——比如某天token消耗突然翻倍可能是某个功能出了bug导致重复调用缓存命中率下降可能是用户问题分布发生了变化需要更新缓存策略。告警阈值根据业务特点来定。我一般设两级日消耗超过预算的百分之一百二十触发警告超过百分之一百五十触发严重告警并自动降级到轻量模型。自动降级这个策略要谨慎使用最好先在小流量上验证确保降级后的用户体验在可接受范围内。5. 常见问题与排查技巧实录5.1 模型切换后输出质量下降怎么排查这是最常见的问题。排查思路是按以下顺序逐项检查。先确认prompt是否针对新模型做了适配。不同模型对prompt的敏感度不同原来在旗舰模型上调好的prompt换到轻量模型上可能效果差很多。我一般会准备一个prompt模板库针对不同模型层级分别调优。再检查输入长度是否超出轻量模型的最佳处理范围。轻量模型的上下文窗口通常比旗舰模型小如果输入接近或超出窗口限制输出质量会明显下降。这时候要么截断输入要么把任务拆分成多次调用。最后看任务本身是否适合轻量模型。如果排查完前两项还是不行那大概率是这个任务本身就需要旗舰模型的能力不要硬撑该用旗舰就用旗舰。5.2 成本下降后反而总支出增加的情况这个听起来反直觉但确实会发生。原因通常是降价后团队放松了调用限制导致调用量暴增总支出反而上升。我见过一个团队模型降价后把频率限制从每分钟十次放宽到一百次结果当月账单是上个月的三倍。解决办法是降价的同时保持甚至加强用量监控。降价省下来的预算应该用在刀刃上比如把省下的钱用于处理更多有价值的任务而不是无差别地放宽所有限制。我自己的做法是降价后先保持原有调用策略不变观察一周然后逐步放宽限制同时密切监控成本变化。5.3 多模型混用的工程复杂度控制多模型混用能降本但工程复杂度会上升。我踩过的坑是一开始把路由逻辑写得太复杂结果维护成本比省下来的模型调用费还高。后来我总结的原则是路由规则不超过三条路由决策不依赖模型输出。也就是说用简单的规则比如输入长度、任务类型标记来决定走哪个模型而不是先用一个模型判断该用哪个模型。后者听起来很智能但实际上增加了延迟和成本而且判断本身也可能出错。常见问题排查方向解决思路切换后质量下降prompt适配、输入长度、任务匹配度逐项排查必要时回退总支出反增调用量监控、频率限制保持监控逐步放宽混用复杂度高路由规则数量、决策依赖规则不超过三条不依赖模型输出缓存命中率低用户问题分布变化定期更新缓存策略批处理延迟高批处理窗口设置根据业务容忍度调整窗口5.4 一个容易被忽略的细节输出长度控制模型调用成本里输出token的单价通常比输入token高。很多团队只关注输入优化忽略了输出长度控制。我见过一个场景模型在回答问题时习惯性地加一段总结和免责声明每次多输出一百多token乘以每天的调用量一个月下来多花不少钱。控制输出长度的方法很简单在prompt里明确指定输出格式和长度上限。比如“用不超过三句话回答”“只输出JSON不要额外解释”。我实测下来加上这类约束后输出token量能减少百分之二十到四十而且输出质量往往更好因为模型被强制聚焦在核心信息上。6. 个人实操体会与后续演进方向这两个变化给我的最大感受是大模型服务的竞争已经进入了“能力普惠”的阶段。旗舰能力不再是少数人的特权轻量模型的成本也降到了可以大规模铺开的水平。对开发者来说这既是机会也是挑战——机会在于可以用更低的成本做更多的事挑战在于当所有人都能用同样的能力时差异化就只能来自产品设计、场景理解和工程优化。我自己的策略是把省下来的模型调用成本投入到评估流水线和监控体系上。模型能力会越来越同质化但你对自身业务场景的理解、对输出质量的把控、对成本结构的精细管理这些是别人抄不走的。后续我还会继续跟踪多模型路由的实践特别是怎么用更轻量的方式做动态决策有新的经验再分享。 
长河君 · 2026/10/20 20:53:45 · 阅读 1.2k 大模型服务新格局：旗舰模型全量推送与轻量模型降价九成的技术逻辑与成本策略
1. 大模型服务新格局背后的真实逻辑1.1 从两条产品动态说起最近圈子里讨论最多的两件事一个是某头部对话产品把最新一代通用模型推给了全体用户不再区分付费层级另一个是某轻量级模型直接把价格砍到了原来的十分之一。这两件事单独看都是常规的产品迭代但放在一起看信号就非常明确了——大模型服务的竞争重心正在从“谁的模型更聪明”转向“谁能把足够聪明的模型用足够低的成本铺给足够多的人”。我自己从早期就开始跟踪各类模型API的调用成本和实际输出质量经历过按token计费心疼到不敢多跑测试的阶段也经历过为了省钱用轻量模型结果输出质量拉胯、返工成本更高的阶段。所以这次看到这两个动态第一反应不是“哇又更新了”而是“终于走到这一步了”。这篇文章我想把这两件事拆开揉碎聊聊背后的技术逻辑、对开发者的实际影响以及在这个趋势下我们该怎么调整自己的技术选型和成本模型。1.2 谁该关注这些变化如果你是把大模型能力集成到产品里的开发者这次的变化直接影响你的API账单和用户体验设计如果你是做AI应用层创业的成本结构的改变可能让你原本跑不通的商业模式重新变得可行如果你只是日常使用对话产品的普通用户你也能感知到免费用户能拿到的能力上限在快速抬升。不管你是哪一类理解这背后的逻辑比单纯知道“降价了”“更新了”要有价值得多。2. 旗舰模型全量推送意味着什么2.1 从分层服务到全量覆盖的转变过去两年大模型产品的典型做法是分层免费用户用上一代或轻量模型付费用户才能用到旗舰模型。这个策略的逻辑很直白——旗舰模型的推理成本高需要通过订阅费来覆盖。但这次把最新旗舰模型直接推给全体用户说明两件事一是推理成本已经降到了可以承受全量免费用户的程度二是竞争压力迫使产品方必须用最强能力来留住用户而不是靠功能阉割来区分付费层级。我实测过几个不同层级的模型在相同任务上的表现差异。拿代码生成来说轻量模型在简单函数补全上还行但一旦涉及多文件重构、复杂状态管理错误率会明显上升。旗舰模型全量推送后免费用户也能直接处理这类复杂任务这对整个开发者生态的影响是深远的——以前很多个人开发者因为成本原因只能用轻量模型做原型现在可以直接用旗舰能力来验证想法。2.2 推理成本下降的技术支撑旗舰模型能全量推送核心支撑是推理成本的下降。这里面有几个关键技术方向在起作用。模型架构层面的优化。混合专家架构的成熟让模型在推理时只激活部分参数而不是全量计算。打个比方以前是一个全能团队每个人都要参与每个项目现在是按项目需求只叫相关的人来干活。这样在保持总参数量不变的情况下单次推理的计算量大幅下降。量化与蒸馏技术的进步。把模型从高精度浮点数量化到低精度整数能在几乎不损失输出质量的前提下把显存占用和计算量降下来。我试过对同一个模型做不同精度的量化对比在4bit量化下大部分对话和代码任务的输出质量差异在可接受范围内但推理速度能提升两到三倍。推理引擎的调度优化。连续批处理、分页注意力这些技术让GPU利用率大幅提升。以前一个请求占一块显存现在是多个请求动态共享空闲显存能被充分利用。这部分的优化对成本的影响非常直接——同样的硬件能服务更多用户单位成本自然下降。2.3 对开发者的实际影响旗舰模型全量推送后最直接的变化是原型验证和产品上线的模型选择可以统一了。以前常见的情况是开发阶段用旗舰模型调效果上线时为了省钱换成轻量模型结果发现输出质量下降又得重新调prompt、重新做测试。现在如果旗舰模型本身就对所有用户开放那至少在对话产品这个场景里你可以直接用旗舰能力来做产品不用在模型切换上折腾。另一个影响是用户预期的抬升。当免费用户都能用到旗舰模型你的产品如果还在用上一代模型用户会明显感知到差距。这对做AI应用的人来说是个压力但也是机会——如果你能快速接入最新能力在产品体验上就能拉开身位。注意全量推送不等于无限量使用。大部分产品仍然会有频率限制或并发限制只是不再按模型层级来区分。做产品设计时要把限流策略考虑进去。3. 轻量模型降价九成的连锁反应3.1 价格变化的量级意味着什么一个轻量模型降价九成这不是常规促销而是战略级的定价调整。我算过一笔账假设原来处理一百万token的成本是X降价后变成0.1X。对于日均调用量在千万token级别的应用来说这意味着月度成本从数万元级别直接降到数千元级别。这个量级的变化足以让很多原本因为成本原因被否决的方案重新进入可行性评估。举个具体的场景。做内容审核的团队以前因为成本原因只能用规则引擎加少量模型调用现在可以把所有待审核内容都过一遍模型准确率和覆盖率都会有质的提升。做批量文档处理的场景以前要精打细算哪些文档值得用模型处理现在可以全量处理人工只需要复核模型标记出的可疑项。3.2 轻量模型的能力边界降价归降价轻量模型的能力边界还是要清楚。我自己的测试经验是轻量模型在以下几类任务上表现和旗舰模型差距不大文本分类、意图识别、简单信息抽取、格式转换、短文本摘要。这些任务的共同特点是输出空间有限、不需要复杂推理。但在需要多步推理、长上下文理解、复杂代码生成的任务上轻量模型和旗舰模型的差距仍然明显。我试过让轻量模型做多轮对话中的指代消解在对话轮次超过五轮后错误率会显著上升。所以降价九成不等于可以无脑替换关键是要做任务分层——把适合轻量模型的任务分流过去把复杂任务留给旗舰模型。3.3 成本结构重构的实操思路基于这两个变化我建议重新审视自己的模型调用成本结构。具体可以分三步走。第一步盘点当前所有模型调用场景按任务复杂度分类。简单分类、抽取、转换类任务标记为“轻量候选”复杂推理、生成、多轮对话标记为“旗舰必需”。第二步对“轻量候选”任务做AB测试。用同样的输入分别跑轻量模型和当前使用的模型对比输出质量。这里要注意不能只看单次输出的好坏要看在真实数据分布下的稳定性和错误模式。我一般会跑至少五百条真实样本统计准确率、召回率和人工复核率。第三步设计动态路由策略。不是简单地把任务分配给某个模型而是根据输入特征动态选择。比如同样是文本摘要短文本走轻量模型长文本走旗舰模型同样是代码生成简单函数走轻量模型涉及多文件依赖的走旗舰模型。这个路由逻辑可以先用规则实现后续再考虑用模型来做路由决策。任务类型推荐模型层级理由文本分类/意图识别轻量模型输出空间有限轻量模型足够简单信息抽取轻量模型模式匹配为主不需要复杂推理短文本摘要轻量模型输入输出都短成本敏感多轮对话旗舰模型需要长上下文和指代消解复杂代码生成旗舰模型需要多步推理和依赖理解长文档分析旗舰模型上下文窗口和推理深度要求高4. 模型选型与成本控制的实战方法4.1 建立自己的模型评估流水线不要依赖别人的评测榜单来做选型决策。榜单上的任务和你的实际场景往往差距很大。我自己的做法是建一个轻量级的评估流水线包含三个部分真实样本集、自动化指标、人工抽检。真实样本集从生产环境的日志里采样覆盖各种边界情况。自动化指标根据任务类型来定分类任务看准确率和召回率生成任务看BLEU或ROUGE代码任务看编译通过率和测试通过率。人工抽检每周做一次每次抽五十到一百条重点看自动化指标覆盖不到的维度比如语气是否合适、是否有事实性错误。这个流水线建起来之后每次有新模型发布或者价格调整你都能快速评估是否值得切换而不是靠感觉做决策。4.2 缓存与批处理的降本效果除了换模型缓存和批处理是两个被低估的降本手段。缓存针对的是重复或相似请求——很多应用场景里用户问的问题是高度重复的把常见问题的回答缓存起来能省掉大量模型调用。我做过一个统计在一个客服场景里前一百个高频问题覆盖了约六成的用户咨询量这部分全部走缓存成本直接砍半。批处理针对的是离线任务。很多场景不需要实时返回结果比如夜间批量处理文档、定时生成报表。把这些任务攒起来批量调用一方面可以利用批处理接口的折扣另一方面可以更充分地利用GPU资源。我实测下来批处理的单位成本能比实时调用低百分之三十到五十。4.3 监控与告警机制成本控制不是一次性的工作需要持续监控。我建议至少监控三个指标每日token消耗量、单位请求平均成本、缓存命中率。这三个指标能帮你快速发现异常——比如某天token消耗突然翻倍可能是某个功能出了bug导致重复调用缓存命中率下降可能是用户问题分布发生了变化需要更新缓存策略。告警阈值根据业务特点来定。我一般设两级日消耗超过预算的百分之一百二十触发警告超过百分之一百五十触发严重告警并自动降级到轻量模型。自动降级这个策略要谨慎使用最好先在小流量上验证确保降级后的用户体验在可接受范围内。5. 常见问题与排查技巧实录5.1 模型切换后输出质量下降怎么排查这是最常见的问题。排查思路是按以下顺序逐项检查。先确认prompt是否针对新模型做了适配。不同模型对prompt的敏感度不同原来在旗舰模型上调好的prompt换到轻量模型上可能效果差很多。我一般会准备一个prompt模板库针对不同模型层级分别调优。再检查输入长度是否超出轻量模型的最佳处理范围。轻量模型的上下文窗口通常比旗舰模型小如果输入接近或超出窗口限制输出质量会明显下降。这时候要么截断输入要么把任务拆分成多次调用。最后看任务本身是否适合轻量模型。如果排查完前两项还是不行那大概率是这个任务本身就需要旗舰模型的能力不要硬撑该用旗舰就用旗舰。5.2 成本下降后反而总支出增加的情况这个听起来反直觉但确实会发生。原因通常是降价后团队放松了调用限制导致调用量暴增总支出反而上升。我见过一个团队模型降价后把频率限制从每分钟十次放宽到一百次结果当月账单是上个月的三倍。解决办法是降价的同时保持甚至加强用量监控。降价省下来的预算应该用在刀刃上比如把省下的钱用于处理更多有价值的任务而不是无差别地放宽所有限制。我自己的做法是降价后先保持原有调用策略不变观察一周然后逐步放宽限制同时密切监控成本变化。5.3 多模型混用的工程复杂度控制多模型混用能降本但工程复杂度会上升。我踩过的坑是一开始把路由逻辑写得太复杂结果维护成本比省下来的模型调用费还高。后来我总结的原则是路由规则不超过三条路由决策不依赖模型输出。也就是说用简单的规则比如输入长度、任务类型标记来决定走哪个模型而不是先用一个模型判断该用哪个模型。后者听起来很智能但实际上增加了延迟和成本而且判断本身也可能出错。常见问题排查方向解决思路切换后质量下降prompt适配、输入长度、任务匹配度逐项排查必要时回退总支出反增调用量监控、频率限制保持监控逐步放宽混用复杂度高路由规则数量、决策依赖规则不超过三条不依赖模型输出缓存命中率低用户问题分布变化定期更新缓存策略批处理延迟高批处理窗口设置根据业务容忍度调整窗口5.4 一个容易被忽略的细节输出长度控制模型调用成本里输出token的单价通常比输入token高。很多团队只关注输入优化忽略了输出长度控制。我见过一个场景模型在回答问题时习惯性地加一段总结和免责声明每次多输出一百多token乘以每天的调用量一个月下来多花不少钱。控制输出长度的方法很简单在prompt里明确指定输出格式和长度上限。比如“用不超过三句话回答”“只输出JSON不要额外解释”。我实测下来加上这类约束后输出token量能减少百分之二十到四十而且输出质量往往更好因为模型被强制聚焦在核心信息上。6. 个人实操体会与后续演进方向这两个变化给我的最大感受是大模型服务的竞争已经进入了“能力普惠”的阶段。旗舰能力不再是少数人的特权轻量模型的成本也降到了可以大规模铺开的水平。对开发者来说这既是机会也是挑战——机会在于可以用更低的成本做更多的事挑战在于当所有人都能用同样的能力时差异化就只能来自产品设计、场景理解和工程优化。我自己的策略是把省下来的模型调用成本投入到评估流水线和监控体系上。模型能力会越来越同质化但你对自身业务场景的理解、对输出质量的把控、对成本结构的精细管理这些是别人抄不走的。后续我还会继续跟踪多模型路由的实践特别是怎么用更轻量的方式做动态决策有新的经验再分享。