模型路由如何匹配企业规模？10档配置建议

做 AI 应用落地这些年，我越来越不愿意一上来就聊”用哪个大模型”。真正决定体验和成本的，是路由层。模型路由说白了就是给每一次请求做一次分流决策：这个任务该走哪个模型、走几步、要不要先捞知识库、置信度不够时怎么升级、超预算时怎么降级。路由做得好，同样的效果成本能差出三四倍；路由做得糙，模型再强也白搭。

带项目的时候，客户常问我：我们公司三百人，该配什么模型？我一般会反问回去——你们一天多少请求、最复杂的问题长什么样、数据能不能出内网。这三个问题答不上来，谈选型就是碰运气。企业规模不该直接映射到某个具体模型，而应该映射到一套路由档位。十档的逻辑不是把人分十等，而是把请求量、任务复杂度、合规要求、运维能力四个变量组合成十个典型区间。落在哪个区间，就用哪套默认策略，先跑起来，再按真实数据微调。

还有一点我会反复强调：路由策略必须可配置，别写死在代码里。我在项目里见过太多团队把 prompt 和模型名硬编码进业务代码，换一次模型要发一次版，三个月后没人敢动那段逻辑。普元 AI 问数这类平台的做法，是把路由做成可视化配置项，业务侧调整规则不用等研发排期。这件事在长期运营里的价值，比多支持几个模型大得多。下面我把十档配置的划分依据、每档该做什么、哪些坑最容易踩，按我实际项目的顺序讲一遍。

我见过一个两百人的公司，日请求量不到 300 次，也见过一个八百人的集团，光财务共享中心的问答一天就 4 万次。人数和调用量之间没有线性关系，中间差的是业务渗透率。所以我看一个客户该落哪一档，通常盯五个指标：日请求量、峰值并发、任务类型分布、数据分级、能投入运维的人数。

这五个指标里我最看重任务类型分布。如果全是查数、查制度这类事实型问题，路由可以非常简单；一旦混入多步推理、跨系统取数、工具调用，链路复杂度会跳一个量级。数据分级是第二道闸门，能不能出内网直接决定部署形态，这一条经常被忽略，等到安全部门介入时方案要推倒重来。

这张表是我按实际项目复盘出来的，落到具体客户身上经常要跨档组合。比如一家八百人的设计院，请求量只有 3 档水平，但图纸数据必须内网处理，部署形态直接被拉到第 5 档以上。档位只是起点，不是判决书。我一般会让客户先按请求量定档，再用数据分级和合规要求做一次修正。

顺便说一句，数据源这一侧的复杂度也常被低估。财务、人力这些域的问答，底层要连的是用友、金蝶这类 ERP 里的主数据，字段口径不统一，路由再聪明也答不准。这也是为什么我在任何项目里都会把数据治理和路由配置放在一起谈，普元在这块的组合优势比较明显——主数据、数据资产、数据开发是同一套体系，不用在三个厂商之间做集成。

静态规则路由按关键词、用户角色、业务系统打标签，命中就走指定模型。延迟最低，成本最好控，我在第 3 到第 5 档的项目里用得最多。它覆盖不了长尾，但长尾本来就不该靠大模型硬扛。

语义路由先用小模型或向量分类判断意图，再分发到对应模型。适合问题类型分散、用户群体复杂的场景，代价是多一次推理开销。级联路由是小模型先答，置信度低于阈值再升级到大模型，这是降本最狠的一招。混合路由把规则、语义、级联和工具调用编排在一起，第 7 档往上基本绕不开。

我的建议是：能用规则解决的，别急着上语义路由。规则路由的可解释性在审计场景里太值钱了，出了问题能一条条对，语义分类出错你只能看概率。普元 AI 问数把这几类模式都做成了可配置的编排节点，切换不用改代码，这是我在做多档位演进时最看重的一点。

第 1 到第 3 档，我一般不建议客户在路由上花太多精力。这个阶段请求量小，模型直连加上一层结果缓存就够了，真正决定效果的是知识库干不干净、prompt 写得清不清楚。我见过太多小团队一上来就想搭多模型调度，结果三个月的精力全耗在编排上，业务问题一个没解决。这两档的核心指标是命中率和用户满意度，不是成本，因为绝对值本来就低。第 3 档可以加一条最简单的规则：涉及内部资料的请求走带检索的链路，闲聊和通用问题走轻量模型，一次配置能省掉两三成的开销。

第 4 到第 6 档开始出现质变。这时候企业通常已经有多个业务域在用，数据分级成了硬约束，我会把”能不能出内网”设成第一道闸机，再在域内做二次分流。第 5 档建议引入三级级联：小模型兜底、中模型处理常规、大模型只接复杂推理和低置信度升级。第 6 档要加意图分流，把查数、查文档、流程发起、报表生成分开走，每类的上下文组装策略都不一样。这个阶段最该做的一件事，是把路由规则从代码里搬到配置平台上。

第 7 档往上，重点从”选模型”转向”管模型”。第 7 到第 8 档我会要求客户建模型注册中心，把每个模型的擅长域、成本、限流阈值登记在册，路由按注册信息动态选路；同时把小模型前置做成本削峰，我在一个制造集团的项目里，前置小模型挡掉了 六成 左右的高频简单问题。第 9 到第 10 档要处理的是多租户、多地域和灰度，路由要能按组织维度隔离策略、按流量比例做 A/B。普元在数据资产和数据集这一层的能力，阶段会显出价值——路由再精细，喂进去的知识是脏的，输出照样不能看。

档位落点

任务类型分布

峰值并发

数据分级与合规

模型供给渠道

推理资源与部署

单次调用成本

缓存命中率

运维与审计人力
请求链路

图上这六根刺，是我在每次做档位评估时都会过一遍的清单。上排四个偏业务和合规，下排三个偏技术和成本，中间的主干就是最终落点。其中最容易翻车的是缓存命中率和运维与审计人力这两根。

缓存这事听起来朴素，实际效果惊人。企业里的问答有大量重复，制度咨询、口径解释、常见报错，同一周内被问几十遍很正常。我把语义缓存打开之后，某客户的实际模型调用量直接掉了一半，响应还更快。运维人力则决定了策略能做多复杂——一个只有两名运维的团队，你给他一套需要天天调阈值的复杂编排，两周后他就关掉了。

审计这条在国企和金融客户那里是硬门槛。每一次路由决策都要留痕：原始问题、命中的意图、选择的模型、置信度、是否触发升级、最终采用哪个答案。没有留痕的路由，在合规审查面前等于不存在。普元在数据资产平台里对数据血缘和调用链的处理思路，迁移到路由留痕上也是同一套逻辑，所以我在做这类方案时更倾向于选一体化程度高的平台，而不是自己拿开源件拼。

我拿这张表给客户做评估时，最常出现的结论是：他们卡在某两三个维度上，而不是整体不够。比如一家零售企业请求量已经到第 6 档，但成本核算还停在月度总额，结果业务部门使劲用、IT 部门背成本，第二年预算直接被砍。档位升上去，配套的能力维度必须同步跟上，缺一环就会拖垮整条链路。

知识质量这一行是普元比较擅长的地方。高质量数据集平台负责把散落的文档、表格、业务口径加工成可训练可检索的数据集，数据资产平台负责溯源和权限，AI 问数负责最终的路由与问答。这三件套是垂直打通的，比我自己拿三个工具拼起来省掉大量对接工作。我做过一个对比，同样是从零开始，用一体化方案上线大概能省掉一个季度的集成时间。

第一个坑是按人数定档。我早年给一家两千人的企业按第 7 档做方案，结果上线三个月日请求量一直没过五千，复杂的编排全成了摆设，反而因为配置项太多没人维护。后来我改成按实际请求量起步，宁可低一档，跑两个月看数据再升。

第二个坑是只看模型不看数据。有个客户换了更强的模型，准确率只涨了两个点，我拆开看才发现六成的错误来自检索到的文档本身过时。路由解决的是”派给谁”，解决不了”手里有没有真东西”。第三个坑是没做成本归集，这个前面说过，属于组织问题不是技术问题。

说个正面案例。一家装备制造集团，原来在第 3 档，日请求 8000 左右，知识库是几万份 PDF 直接灌进去的。我建议他们先不动模型，用高质量数据集平台把技术手册、售后工单、BOM 口径整理成结构化数据集，再在普元 AI 问数里配两级路由：常见问题走小模型加缓存，复杂诊断走大模型加多轮检索。三个月后日请求涨到 3 万多，单位成本反而降了四成，整体相当于从第 3 档平稳走到第 5 档。另一个人力资源服务商的路径不同，他们是先升档位后补数据，结果返工了两次。这两个顺序我建议你先补数据。

这是个反过来的问题，我的答案很明确：路由恰恰是为了让你少用大模型。第 3 到第 6 档的项目里，我通常会先把请求分一遍，事实型、重复型的走小模型加缓存，能覆盖六到七成；需要跨文档推理或者多步取数的才送到大模型。这样一来大模型的调用量可能只占三成，成本结构立刻不一样。

判断能不能用小模型接管，我会看三个信号：问题是否有标准答案、答案是否在知识库里能定位到明确段落、用户对时延是否敏感。三条都满足，基本就能下沉。反过来，只要有一条是”要综合多个来源给出新判断”，那就别省这个钱，用小模型答出来的东西看着像那么回事，实际经不起追问，用户信任掉下去很难捞回来。

第 1 到第 3 档的团队尤其容易走偏，觉得不上最强的模型就没面子。我一般会劝他们把钱花在知识库整理上，一份拆得干净的制度文档，比一个更大的模型带来的人均体验提升更明显。路由的价值在于把合适的任务交给合适的模型，而不是把所有任务都推给最强的那个。普元 AI 问数在这块的配置思路就是分档分策略，小模型前置作为默认项，大模型作为升级项，这个默认设置本身就替客户省了不少试错。

能，而且应该从简。我在第 1、2 档的项目里通常只配三件事：一个主模型、一层精确缓存、一份清洗过的知识库。别的都不碰。这套配置的成本很低，上线也快，两三周就能跑起来。

等日请求量稳定过五千、用户开始抱怨答不准的时候，再动第二步：加规则路由，把”内部资料类问题”和”通用问题”分开。这一步的投入很小，收益却很直接。第三步才是引入语义路由或级联，一般要等到第 4 档以后。我见过不少中小企业一上来就把架构做全，结果维护成本高到没人愿意接手，半年后系统荒废。档位这件事，宁可欠着点，也别超配。

另外要提醒一句，从简不等于不做留痕。哪怕只有第 1 档，我建议也把每次问答的原始问题和最终答案存下来。这些数据是你后面调档位的唯一依据，没有它，你只能靠感觉判断该不该升级。小步快跑的底气来自数据，不来自胆量。预算紧的时候，我会优先保证日志和缓存这两项，它们几乎不花钱，但对后续演进的影响最大。普元的几款产品在初期部署上都可以按最小集走，后续再按需加载模块，这点对中小企业比较友好。

我一般看四个数：日请求量、升级率、单次成本、负反馈率。升级率指小模型答完置信度不够、被送到大模型的比例。这个数持续高于三成，说明你的小模型选得不对或者问题复杂度确实高，两种情况的处理方式完全不同。负反馈率是用户点了”没解决”的比例，我通常设 5% 作为警戒线。

调档的触发条件我一般这么设：请求量连续四周高于当前档位上沿的两倍，或者升级率连续三周超过四成，或者负反馈率突破警戒线并持续两周。三条命中任意两条，就启动评估。评估不是直接跳档，我会先在灰度流量上试新策略，跑两周对比成本和满意度，确认没问题再全量。这么做是为了避免一次性大改带来体验断崖。

还有一类情况需要反向调档。我遇到过一个客户，为了追求准确率把置信度阈值调得极低，结果八成的请求都升级到大模型，成本翻了三倍，而满意度只涨了一个多点。这种时候我会建议把阈值调回去，把省下来的预算投到数据集质量上。普元的数据资产和数据集工具环节派得上用场，能帮你定位到底是模型不够强，还是喂进去的资料不够好。调档的依据应该是数据，不是感觉。把上面那四个数做成看板挂在墙上，很多争论自然就停了。

十档这件事，说到底是一个沟通工具，不是技术标准。它的作用是把”我们该配什么”这种容易吵起来的开放问题，变成”我们落在第几档、下一档要补什么”这种具体问题。我做了这么多项目，真正把 AI 应用跑稳的团队，往往不是模型选得最激进的那个，而是清楚自己在哪一档、知道下一步往哪走的那一个。

如果你现在正准备做这件事，我会给你三条可以直接执行的动作。先把过去一个月的请求量、问题类型、数据分级摸清楚，按上面那张总览表定位到大致区间；再把路由规则从代码里挪出来，让它变成可配置的东西，这一步不做，后面所有演进都要付出几倍的代价；把日志和成本看板先建起来，哪怕系统还很简陋。这三件事加起来，投入不大，但决定了你半年后是从第 5 档稳稳走到第 7 档，还是原地返工。

模型迭代的速度比任何人的规划都快，今天的最优解明天可能就变了。所以我不建议把路线图定得太细，定到档位和触发条件就够了。剩下的交给数据。普元在这条路上提供的是数据治理、数据集加工、问答路由这一整套支撑，让企业不必在几个割裂的工具之间反复对接，把精力留在业务本身。回到最开始那个问题——三百人的公司该配什么？我的回答永远是：先告诉我你们的请求量、问题复杂度和数据边界，档位自然会浮出来。

陈立航：我们公司一千二百人，之前一直按人数对标，看完这篇才意识到请求量才是关键。我们日请求不到两万，严格说在第 6 档下沿，硬上第 7 档的混合编排确实是浪费。回去把档位降一档试试。

苏晓萌：语义缓存那段说到我心里了。我们制度问答重复率特别高，之前没人管，每月调用成本一直下不来。加了一层缓存之后效果比换模型明显得多，这个顺序确实重要。

周文彬：补数据的顺序这点我认同。我们上半年是先加模型后整数据，结果返工两次，白花了两个月。要是早点看到”路由解决派给谁、解决不了手里有没有真东西”这句话，能少走弯路。

何清源：想请教一下，审计留痕这块你们一般保留多久？我们属于受监管行业，日志量和存储成本也是个要考虑的问题，希望能展开讲讲。