我想给企业的大模型做一个调度员
企业部署了好几个大模型，可算力总是有限的。我想做一套算力分配机制：先判断这次请求是什么、要多少能力，再结合业务规则、模型能力和实时负载，把有限的算力自动、合理地分给每一次请求，并且说清楚为什么这么分。
最近在做大模型性能测试的时候，我一直在琢磨一个问题。
企业部署了好几个大模型，可手里的算力总是有限的。这些算力该怎么分，是个绕不开的事。
现在很多 AI 平台都提供模型选择：用户可以在通用模型、推理模型、代码模型、长文本模型之间手动切换。对熟悉大模型的人来说，这样切换很自由。放到企业内部，情况就不一样了：这一次请求该花掉多少算力，被推到了用户手上。
一次通知润色，占用的算力很小；一次几十页材料的分析，需要更多、更强的算力。如果每个人都凭感觉挑模型，轻任务容易挤占贵模型，需要它的人反而要排队。
我希望这个判断由系统来完成。
一、模型越来越多，算力怎么分反而成了一个问题
企业建设 AI 能力，通常不会只有一个模型。
不同模型有自己的优势。有的擅长复杂推理，有的在代码任务上表现不错，有的支持更长的上下文，还有一些小模型响应快、资源消耗低。
但这些模型背后，是同一批有限的算力。
私有化部署尤其如此。大模型的成本不只是 API 调用费用，还包括 GPU 或其他加速设备、推理服务部署、显存占用、资源调度和运维成本。
我在性能测试中遇到过一种情况：模型在低并发下表现正常，并发一上来，首 Token 响应时间明显增长。请求继续增加，系统还能把任务处理完，但用户已经要等很久。
把所有办公请求都压到同一个高能力模型上，资源竞争就出现了：需要它的复杂任务，只能排在后面。为了省算力改用小模型，复杂任务的效果又会打折。
图 1 · 任务不一样、模型不一样、算力又有限，企业需要一套能把算力分明白的路由机制
所以我想做的，是一套算力分配机制。
用户只负责提出需求，这一次用多少算力、交给哪个模型，由系统判断。
二、Laya 给了我一个切入点
前段时间关注到一个开源项目：Laya。
它采用非自回归的判别式推理方式，可以针对输入内容执行 choice、score、noul 等结构化判断任务，不用像生成式大模型那样逐 Token 输出一段解释。
例如，可以让它判断：
- 当前任务属于文档分析、知识问答、代码生成还是其他类型？
- 任务的复杂程度如何？
- 是否需要复杂推理、长上下文或者工具调用？
- 当前分类结果是否足够可靠？
把这些判断放在调用链路最前面，算力分配就有了依据：先弄清这次请求要什么，再决定给它多少算力、由谁来接。
不过，Laya 离开箱即用还有距离。
它在中文办公场景里的准确率、复杂任务识别能力、置信度是否可靠，都要用专门的数据集验证，必要时还要做领域适配和微调。
这里最关键的一点：判断本身不能太慢，也不能因为误判，把一次重任务分到不够用的算力上。
三、光能判断任务类型，还远远不够
假设用户提出一个请求：
帮我分析这份财务报告中的主要经营风险。
Laya 大概能识别出这是一个文档分析任务，也知道它对推理能力和输出质量要求较高。
但知道这些，还决定不了这一次该分给它什么算力。
后面还有几个现实问题要回答。
模型有没有这个能力？
支持长上下文，不等于长文档分析做得好。它可能收得下全部材料，却提不出准确的信息。这要靠真实的模型能力评测数据来判断。
这个模型允许处理当前业务吗？
企业内部不同业务的数据敏感程度、模型使用范围、合规要求都不一样。模型能力再强，也不代表它能处理所有请求。
这块算力现在还有余量吗？
某个模型可能最适合当前任务，但推理队列已经排得很长。如果另一个模型能达到同样的质量要求、响应还更快，把请求分给它更合理。
值不值得动用高成本的那部分算力？
简单的文字润色，小模型就能做好，没必要每次都占用高成本的算力。
这几个问题，靠一套明确的企业规则和调度机制来回答。
图 2 · 一次分配是怎样做出来的：任务画像 → 硬约束筛选 → 候选模型评估 → 最终路由
四、我准备把算力分配拆成几个环节
初步设想是做一个独立的模型路由决策服务，放在企业 AI 应用和实际模型服务之间。
处理过程分成四个部分。
第一部分是 任务识别。用 Laya 拿到请求的任务类型、复杂度，以及需要哪些模型能力。
第二部分是 业务规则判断。结合数据权限、业务场景、模型使用范围和质量要求，划出这次请求能动用的算力范围。
第三部分是 资源和效果判断。用模型评测数据、性能测试结果和实时服务状态，在合格模型里挑一个更合适的。
第四部分是 运行反馈。把每次分配的原因、实际响应时间、失败情况和任务完成效果记下来，供后续优化。
图 3 · 系统分层：Laya 做识别，规则做约束，决策引擎做选型，网关负责执行
我希望做到的效果是：不同用户提交不同任务，系统自己决定这一次算力花在哪、花多少，并且能说清为什么这样分。
五、性能测试数据可能会发挥更大的作用
过去做大模型性能测试，重点通常是评估模型在不同资源配置、上下文长度和并发条件下的处理能力。
测试做完，数据主要用于容量评估、资源规划和上线前的性能判断。
这些数据还能继续用。
同一个模型，输入长度不同，首 Token 响应时间可能差很多；硬件配置、推理参数一变，能稳定扛住的并发量也不一样。
把这些结果沉淀成模型的性能画像，再叠上运行时的负载状态，就能回答一个很实际的问题：此刻这块算力还能不能接，接了大概要等多久。算力分配最需要的就是这个。
不过，离线压测结果能不能反映生产负载，还得实验验证。
混合任务场景里，请求长度、输出规模、到达方式、服务端排队都会影响性能。一次压测得到的并发上限，不能直接拿来当作所有业务请求的分配依据。
这部分是我接下来准备重点研究的。
六、这套东西有没有实际价值，得靠数据证明
模型路由不是新概念。
RouteLLM 等研究已经探索过根据请求选择不同能力的模型，用来平衡质量和成本。LiteLLM 这类开源网关，也提供了多模型负载均衡、延迟感知路由和故障回退。
我没打算重做一套完整的模型调用基础设施。
我关心的是：能不能把任务识别、企业业务规则、模型能力评测和真实资源状态串起来，形成一套能把算力分明白的机制。
接下来准备做几组对照实验：
- 一组用固定模型，所有请求都走同一档算力；
- 一组做简单任务分类，把不同任务映射到预设模型；
- 再一组加上业务约束、模型能力评价和实时资源判断。
比较它们在相同任务集下的质量通过率、响应时间、吞吐量、资源消耗，以及分配决策本身的开销。
还要专门测几类异常：分类错了怎么办，模型突然不可用怎么办，候选模型都不符合要求怎么办，系统会不会为了快，把任务分到算力不够的模型上。
图 4 · 四组方案对比：从固定模型到动态决策，看质量、响应和资源成本，也看异常场景下的边界
这些问题测清楚了，才好判断这套机制到底有没有用。
七、下一步，先把决策引擎做出来
计划是先做一个最小版本。
前端做一个路由决策实验室：输入任务、看分类结果、配业务规则、检查候选模型，并展示最终为什么这样分。
后端接入 Laya、模型能力库和统一模型调用接口。资源数据先用模拟的，再逐步换成真实的评测结果和性能监测数据。
之后再研究容量预测、分配策略优化，以及异常情况下的模型切换。
理想情况下，用户只需要描述自己要做什么。背后用哪一档算力、消耗多少资源、要不要排队，都由系统按明确的规则处理。
前提是它分得准、用得稳，带来的收益能盖过自身的复杂度。
这是我接下来想做的一次技术实践。
