刚接触 LoRA 和 MoE 路由的人往往先被一个问题卡住手头已经有好几个训练好的 LoRA 专家系统不知道当前请求该交给谁。于是大家会想到让路由器看不确定性也就是“哪个模型更犹豫就避开哪个”。但这个思路往往只能帮你排除错误答案并不能告诉你换了专家以后结果能提升多少。所以这里想展开的核心观点是在做混合 LoRA 专家的路由时不确定性也就是 entropy、置信度、多采样不一致性这些信号只是一个参考维度真正做决定时应该尽量去估计信息价值也就是“把请求切换到另一个 LoRA 专家之后比当前决策多出来的收益”。这套思路特别适合已经在做 LoRA 微调、并且手上攒了不止一个领域 LoRA 的团队。如果你只是在单模型上做一次性微调路由问题离你很远但一旦你想让代码 LoRA、SQL LoRA、客服 LoRA 同时服务于同一个入口路由就变成模型之外最核心的系统问题。1. LoRA 专家一多路由很容易成为系统瓶颈1.1 你迟早会碰到“几个 LoRA 同时在线”的场景在 LoRA 微调落地得很顺的团队里模型的扩散方式非常快有人训练了面向代码补全的 LoRA有人训练了面向数据库 SQL 优化的 LoRA还有人训练了面向客服话术的 LoRA。单独部署每个 LoRA或者按用户手动选择都能跑但一旦你希望多个 LoRA 支撑同一个入口就不得不面对路由问题。所谓路由就是在用户请求进来后判断到底应该由哪个专家处理或者哪些专家并行处理后再选出一个最终结果。很多人在这个阶段会误以为路由问题等价于分类问题给每个请求打一个标签然后调用对应的 LoRA。但实际场景往往没有干净标签也没有唯一正确答案。同一个输入放在“生活常识” LoRA 下也能答放在“医疗健康” LoRA 下也能答只是质量、风格、风险程度不同。这时候需要的不再是一个硬分类器而是一个能够权衡质量的决策器。1.2 只看不确定性最典型的问题是什么如果你使用不确定性路由通常会计算当前模型或候选专家在输出上的置信度例如softmax 概率最大的那个值logits 之间的差值或置信区间宽度多次随机采样后答案的语义一致性多个 LoRA 输出之间的分歧程度。这些指标都能反映“当前模型拿不准”但它们都缺少一个关键维度候选专家本身是否真的更好。一个很现实的情况是当前 LoRA 很犹豫说明它不适合这条输入但另一个 LoRA 可能同样差甚至更差。不确定性只能告诉你“这里有问题”但不能告诉你“换谁来解决这个问题”。在决策论里这条额外的判断就是信息价值。我见过不少把 top k 个不确定样本交给所有专家并行生成、最后再用一个打分模型挑选的工程方案。它能解决问题但成本容易被忽略。尤其是候选 LoRA 数量达到十几个时每个请求都要跑十几遍生成延迟、显存、token 消耗都会快速上涨。更稳的做法是先用一个轻量路由器计算每个候选专家的预期收益只调动收益增量最大的一个或两个专家。1.3 路由需要回答的其实是两个问题第一当前默认方案在这个输入上有多好第二换成候选专家之后又会变好多少。第一个问题可以用历史平均分、当前基础模型的置信度、甚至是规则默认值来估计第二个问题是路由的核心它不能只看不确定性的绝对值而要结合该专家在这个输入类别上的历史表现以及当前输入和该专家训练分布的接近程度。所以标题里说的“不确定性不够”本质上是在提醒你路由指标应该和最终业务指标挂钩。如果你的业务指标是答案采纳率、任务完成率、回答正确率那路由器的打分就应该逼近这个指标而不是只逼近“模型自己觉得有多自信”。2. 信息价值路由从“我慌不慌”到“换了值不值”2.1 先把路由当成一个决策问题把决策拆成三步会很清楚你有一个当前策略它可能是“默认模型直接回答”也可能是“按关键词调度到某个 LoRA”。你有一组候选策略也就是切换到的 LoRA 专家 k。你有一个收益函数用来衡量某个专家在当前输入 x 上的输出质量这个函数可以是评分模型、人工标注、任务成功率等。路由问题就变成了在当前已知信息下哪个候选策略的期望收益最高并且它的期望收益显著高于当前策略。信息价值这个概念在这里的含义是如果你获取更多信息后再做选择选择质量能提升多少。放到混合 LoRA 专家的场景里多获取的信息可能是某个专家头部的 logits、某个隐藏层向量、或者干脆是把请求先让默认模型生成一小段草稿再打分。2.2 不确定性和信息价值在计算上的差异不确定性通常是一个标量描述分布本身的弥散程度。比如熵越高表示模型输出概率越平均这时模型没有明显偏好。信息价值则不一样它描述的是“采取某个行动之后收益的期望提升”。举一个简化版的数值例子。现在有两个候选专家 A 和 BA 在编程类问题上的历史评分是 0.9但它在当前输入上的不确定性很高。B 在编程类问题上的历史评分是 0.6但它在当前输入上的不确定性很低。如果只看不确定性你可能会觉得 B 更稳定所以选 B。但如果你估算的是“选择某个专家后期望能拿到的收益”A 可能仍然是 0.9 附近B 只有 0.6最终应该选 A。当然现实比这个例子复杂因为历史评分不一定能迁移到当前输入还需要结合相似度、最近一次任务表现等特征但核心区别已经清楚了不确定性告诉你的东西不直接等于收益。路由方式核心判断依据优点容易出现的问题规则路由关键词、来源、用户标签可控、可解释泛化差新输入没法覆盖向量检索路由输入 embedding 和专家描述相似度简单适合冷启动相似不等于任务效果更好不确定性路由熵、置信度、多采样不一致性能识别“边界输入”只提示有问题不提示谁更好信息价值路由预期收益提升、切换代价、确定性收益与业务指标对齐需要构造收益数据训练成本高这四种方式不是互斥的。工程里往往先用规则兜底再用向量检索做粗筛最后用一个小模型输出每个候选 LoRA 的预期质量分。信息价值路由更像是对最后一层决策的升级。2.3 不搞完整贝叶斯框架也能近似计算信息价值完整的信息价值计算非常重因为你需要模拟“获取所有可能信息后的所有可能决策”这对在线推理不现实。实践中可以用更简单的代理训练一个打分网络输入是当前请求的特征和某个候选专家的描述输出是该专家在这个请求上的预期质量分然后把当前默认方案的质量分也估计出来。当某个候选专家的预期质量分明显高于默认方案且高于当前不确定性的惩罚项时才触发切换。你也可以把“切换成本”设计成一个参数例如额外增加的延迟、token 消耗、失败率最终路由分数就是收益减去成本。我在实际项目里会更倾向于做一个回归任务而不是分类任务。分类任务通常问“这个请求属于哪个 LoRA”但一个请求可能同时属于多个 LoRA也可能哪个都不属于。回归任务则问“如果让第 k 个 LoRA 处理质量大概能到多少”这样更容易支持 top_k 选择和多专家投票。3. 落地实现路由器的输入、训练数据和推理流程3.1 先解决“什么是好输出”再谈训练路由器很多人在训练路由器之前没有准备专家质量分这是一个容易踩的坑。路由器要预测的是“这个专家在这个输入上能不能拿高分”所以手里必须有一批已经标好分数的数据。构造这套数据的大致流程准备 2000 到 10000 条有代表性的输入尽量覆盖上线后可能遇到的任务类型、语言、长度和格式。每一个输入都喂给所有候选 LoRA生成答案或者至少喂给候选 LoRA 的一个子集。用一个统一评分器给答案打分。评分器可以是一个更强的模型、一个奖励模型也可以是程序化规则加人工抽检。把输入特征、候选 LoRA 标识、评分结果整理成训练集。这一步特别要注意两件事。第一所有候选 LoRA 都要用同一套评分标准不然路由会偏向评分更宽松的专家。第二不要只用“那条输入最终选了谁”来作为标签因为最终的硬选择会丢掉大量信息更好的形式是保留每个专家在这个输入上的完整得分向量。3.2 输入特征别只拿 logits我建议把特征分成三组输入侧特征提示文本 embedding、输入长度、语言、是否多轮、是否包含代码块或公式等。模型侧特征基础模型最后一层隐藏状态的 pooling 结果、默认模型在该输入上的置信度或熵。专家侧特征候选 LoRA 的描述 embedding、历史平均表现、最近 N 条任务的成功率、当前输入与该专家训练分布的相似度。很多实现只用了输入 embedding 和专家 embedding 做相似度匹配效果往往不够好因为相似度高不代表该专家的生成能力强。把模型侧特征和专家侧的历史统计加进去之后路由会更接近“哪个专家更有可能成功”而不是“哪个专家看起来相关”。如果你担心特征太多导致延迟增加可以让特征计算走一个小模型或者缓存专家侧特征。每个请求真正需要动态计算的通常只有输入侧的 embedding 和一个轻量分类器。3.3 推理链路可以参考这个顺序在线推理时我一般按下面这个顺序接用户请求进来先走规则路由。如果命中强规则比如请求明确带有“翻译为英文”就直接走对应 LoRA。规则没有命中时计算输入 embedding做一次候选专家粗筛过滤掉明显无关的 LoRA把候选集缩小到 3 到 5 个。对留下来的候选专家让路由打分网络逐个输出预期质量分。把当前默认方案的质量分也估算出来或者用一个兜底策略。如果最高预期质量分超过兜底分数并且差额大于阈值就切换到对应专家。把所有路由日志写入存储供后续离线评估和重新训练。这里每一步都不是必须的。如果候选 LoRA 只有 3 个第 2 步可以省略。如果打分网络的计算量已经很小第 3 步和第 4 步可以合并。关键是形成一条从“规则到模型再到回退”的链路而不是让路由器成为新的单点。3.4 一个小型路由模块的示意结构下面这个代码块只是用来说明流程不是某个具体框架的完整实现。真实落地时你需要根据自己的推理后端调整。# 示意候选专家质量分路由 def route_request(request, cand_adapters, router, default_score, threshold0.05): feats extract_features(request) scores router.predict(feats, cand_adapters) base_score default_score(feats) best_name None best_score base_score for name, score in scores.items(): if score best_score and score - base_score threshold: best_name name best_score score if best_name is None: return generate_with_default(request) return generate_with_adapter(request, best_name)这个逻辑的核心是“只有当候选专家预期收益明显高于默认方案时才切换”。threshold 控制路由的保守程度。调小 threshold路由器会变得激进也可能把请求切给一个表面分高但实际不稳定的专家。调大 threshold路由更稳但会错过一些收益较高的切换。4. 影响稳定性和成本的几个关键参数4.1 top_k 和阈值决定成本和质量的平衡top_k 表示最终并行激活多少个候选专家。top_k1 最省资源但一旦路由分错误就没有回旋余地。top_k2 到 3 可以让多个专家并行生成再让后端统一打分选优代价是 token 消耗和显存占用明显上升。如果你刚上线我建议先跑 top_k1只做“切换专家”不要同时跑多个专家。等日志积累足够多证明路由本身准确率不错后再尝试 top_k2。阈值没有通用推荐值因为它取决于你用的评分器范围。如果评分器范围是 0 到 10.05 到 0.1 是一个可以接受的起点如果评分器是 1 到 5 分阈值可能要放到 0.3 到 0.5。更稳的做法是先用一批离线数据画出“阈值-准确率-成本”曲线再选一个业务上可接受的平衡点。4.2 每个请求路由一次还是每个 token 路由一次LoRA 专家路由有两种常见频率请求级路由一个对话或一个请求只路由一次所有生成过程都使用同一个 LoRA。这种方式更稳定适合客服、问答、代码生成等场景。token 级路由生成过程中每一步都可能切换到不同 LoRA。这种方式需要更复杂的实现而且切换上下文很可能引入不稳定输出。如果你在做细粒度 MoE或者希望在一个 LoRA 里同时容纳多种能力token 级路由是值得研究的方向。但对大多数生产系统我建议先做请求级路由。主要原因不是 token 级做不到而是排查复杂一旦输出质量波动你很难判断是路由评错了还是中途切换导致上下文破坏。请求级路由至少能让问题边界清晰。4.3 显存和延迟的真实边界LoRA 微调时大家常问“需要多少显存”到了推理路由阶段反而容易忽略多个 LoRA 同时挂载的代价。单个 LoRA 权重文件通常不大可能只有几十 MB也可能到几百 MB但要让多个 LoRA 处于可用状态不只是权重加载还会影响前向计算路径、缓存空间和显存碎片。低配置机器也能把混合 LoRA 专家系统跑起来但需要把候选数、上下文长度、batch size 一起调小。我见过有人在 8GB 显存的环境里挂 5 个 7B 模型的 LoRA单请求还能跑并发一上来就频繁 OOM。原因是路由本身需要一次额外的模型前向提取特征候选 LoRA 在切换时又要重新加载峰值显存比预想的更高。更合理的做法是单请求测试时观察切换专家时的峰值显存和第一次生成延迟。批量压力测试时观察 p99 延迟和 OOM 出现次数。如果延迟超标优先减少候选专家数量而不是单独优化某个专家。5. 我实测中经常遇到的问题和排查顺序5.1 看起来像路由问题实际是特征对齐问题路由结果的波动很多时候不是因为打分网络不够强而是因为特征没有对齐。最典型的是输入长度不一致问题训练时用 512 token 的截断长度上线时请求长度涨到 2000 token模型侧的 embedding 语义已经发生变化。另一个问题是多轮对话没有把历史消息拼进去导致路由只看到了最后一句话自然很难判断领域。遇到路由结果不理想时不要急着换模型先检查输入是否走了和训练时相同的前处理流程是否所有候选专家都使用了同一套 tokenizer特征抓的是哪一层的 hidden state层数变了分布也会有差异路由服务器和推理服务器是否版本一致。5.2 评分器不一致训练数据再干净也没用如果你用 A 模型的输出作为 B 模型的评分器而 A 模型明显偏好长答案那么所有长答案都会被推到高分路由器就会学出一个“谁生成更长就选谁”的偏差。这未必是你想要的业务目标。解决方法是先在小样本上做一次人工校验确认评分器给出的分数和人工判断方向一致然后固定评分器版本不要频繁更换。对于业务指标比较明确的场景完全可以不用模型评分器。比如代码补全任务可以直接用测试用例是否通过翻译任务可以用双语评测指标客服场景可以用用户是否点击、是否继续追问、工单是否关闭等行为数据。越接近真实业务标签路由器的预测就越有用。5.3 我建议的排查顺序如果上线后路由表现不好按这个顺序排查先看路由日志确认每条请求到底被分给了哪个专家以及分数是多少。再看输入确认特征提取、tokenizer、上下文长度都没有偏离训练配置。再看训练数据确认每个专家在训练集里的样本数量不要太悬殊。某个专家样本占 80% 时路由器很容易变成“万事不决选 A”。再看阈值确认不是切换太频繁导致输出抖动。最后看评分器确认训练时的评分标准和线上评估标准一致。这个顺序能帮你把问题归因到数据、特征、参数还是评分器避免一上来就重新训练一个大模型。5.4 一张简单的排查对照表现象优先排查位置常见原因路由器永远选同一个 LoRA训练数据分布、评分器偏差某个专家样本过多或评分被抬高在线结果不如离线评测特征一致性、阈值特征没对齐或者阈值选得不合适切换后答案更差评分器、专家本身评分器和真实业务不一致或该专家只是历史平均分高但当前输入不匹配显存峰值异常候选数、batch、路由前向额外前向和多个 LoRA 同时挂载导致峰值上涨延迟大幅上升候选数、top_k、并行生成触发了过多专家并行生成6. 先跑通再优化的建议路线6.1 从一个最小的硬路由开始不要一上来就构建完整的信息价值路由系统。最稳妥的路线是选 3 到 5 个差异明显的 LoRA比如代码、SQL、客服或者你业务中真正高频的三个领域。先用规则或向量检索做一个硬路由记录每条请求被分配给了谁同时让所有候选专家都生成答案做离线对比。累积几千条带评分的数据后再训练一个简单的打分网络替换掉硬路由。上线时保留所有日志持续对比路由策略和兜底策略的表现。这样做的原因很简单信息价值路由需要的数据、特征、评分器都不是一次能建好的先跑通一个可解释的硬路由你会更容易看清问题出在哪个环节。而且硬路由可以在失败时回退不会让系统陷入“完全依赖一个黑盒路由器”的状态。6.2 给新手的预期管理信息价值路由不是银弹。它适合的场景是你确实有多个质量不错的 LoRA并且投入了时间和资源去准备质量分数据。如果只是学习或者只有两个 LoRA用固定规则甚至手动选择反而更省事。默认配置下先用一个轻量分类器粗筛再用阈值控制切换比强行套一个复杂的决策框架要靠谱得多。值得再强调的是路由器的上限不会超过候选专家的上限。如果所有 LoRA 在该输入上都表现不好再精确的路由也只能选出一个“最不差”的答案。所以我更建议把注意力同时放在两个方向底座的通用能力、候选 LoRA 的场景覆盖度。两者都做实了路由才会成为锦上添花的一环。6.3 真正落地时该盯住的三个长期事项一是日志。每一条请求的路由分数、候选专家分数、最终选择、线上反馈都要尽量留存。没有日志你就没法评估路由器的改进效果。二是定期重新训练。用户输入分布会变化LoRA 本身也可能被更新路由器如果一直用旧数据会慢慢失真。三是保留兜底策略。无论路由表现得多么好都要有一个不经过候选专家直接回答的默认路径。这个兜底不仅能处理评分器失效的异常也能在路由器的分数差异不显著时避免无谓切换。踩过几次之后我的感受是混合 LoRA 专家的重心往往不是专家模型训练而是路由系统的数据闭环。你能不能让路由器知道自己选得好不好比选一个更复杂的模型更关键。先把日志和评分标准做好再把信息价值路由的路一步一步走出来。