游戏AI为什么越来越需要模型路由，而不是让一个大模型处理所有事情？

玩家推开一扇门，守卫需要在几十毫秒内决定是转身还是拔剑，接着在一两秒内说出一句得体的话，而整个章节的剧情要不要重排，几分钟以后再决定也来得及。这三件事的时间尺度相差三个数量级，如果都交给同一个云端大模型，要么守卫永远慢半拍，要么每句台词都在为最大的模型付费。游戏AI越来越需要“模型路由”（Model Routing），也就是一个专门决定“这件事由谁来做”的调度层。

路由并不是新发明。行业里已有厂商公开过类似思路：英伟达的ACE自主游戏角色方案（2025年）使用8B、4B、2B级的小语言模型做角色决策；据英伟达技术博客介绍，KRAFTON在PUBG Ally中把2B模型部署在玩家本机以压低延迟，并让行为树负责战斗动作、语言模型负责推理与说话。下面沿着PA真人游戏大模型研究组的思路，把这个调度层拆开来看。

先看任务，而不是先看模型

游戏里的AI任务可以粗分成五档，每一档对延迟、成本和质量的要求都不同。

表中所有延迟数字都是示例参数，用来说明量级，并非任何产品的实测结果。重要的是这张表反映的判断：越靠近玩家的操作，越需要确定性；越靠近内容创作，越需要大模型的语言能力。而“一致性校验”这一行提醒我们，最需要可靠的地方，往往一个语言模型都不该出现。

路由器看哪些信号

路由器每次拿到请求，会综合几类信息。任务类型是第一位的；其次是上下文长度，示例参数：超过4000个词元的上下文不适合端侧小模型；再次是玩家设备，比如显存和电量；最后是网络状况，网络往返超过示例阈值时，本来该上云的对话会退回端侧。还有一类容易被忽略的信号是“重要程度”：主线关键剧情节点值得多花一点成本，路边行人的一句问候则不值得。

路由规则早期用手写条件就足够，比如“对话且上下文小于2000词元且端侧可用，选小模型”。规则变多以后，可以再用一个很小的分类器学习路由，但它必须被规则兜底：分类器的置信度低于示例阈值时，走更保守的路径。

一次NPC对话的路由决策（示例）

玩家走到铁匠铺，问铁匠“昨天那批剑修好了吗”。路由器的处理大致是这样的：

1. 识别任务：这是一句带世界状态依赖的短对话。先向世界状态查询“昨天那批剑”的任务状态，这一步是检索，不调用任何模型。
2. 检查缓存：相似问题在最近对话中出现过吗？如果玩家上次问过同样的问题且状态未变，直接复用上次的要点。
3. 选择执行者：状态查询显示剑已修好、并有一条关于报酬的关系记录，属于低风险短对话，交给端侧小模型，示例目标是首字延迟不超过500毫秒。
4. 校验输出：规则检查器核对台词里是否出现了状态里没有的物品或数字，不通过则重试一次。
5. 降级兜底：如果端侧模型超时，返回一条预写的模板台词并在后台异步补生成更丰富的版本。
6. 记录日志：任务类型、所选执行者、延迟、是否重试都写入路由日志。

如果玩家换一种问法，比如“你觉得我该去帮北边的村子还是留在城里”，任务性质就变了，涉及剧情倾向与多个任务分支，路由器会把它判定为规划类，转给云端大模型，并允许玩家看到一个短暂的“铁匠正在思考”的表现，以此掩盖秒级的等待。

识别任务→检查缓存→选择执行者→校验输出→降级兜底→记录路由日志

缓存、预生成与降级

许多请求可以提前处理。玩家进入新区域前，云端可以预先生成一批可能用到的NPC对话要点与区域描述，放入本地缓存；夜间或后台空闲时，还可以预生成下一段主线的候选走向。缓存的关键是失效条件：世界状态里相关实体的版本一旦改变，对应缓存立即作废，否则守卫会对已经不存在的事情侃侃而谈。这一点与世界状态管理里的版本号机制是同一套逻辑。

降级则要预先设计成多档：云端不可用退到端侧，端侧模型过载退到模板，模板也不适用就退到沉默或简短动作。玩家不应该看到错误提示，只会觉得角色少说了几句。

没有观测，就没有路由

分流是否合理，最终要靠数据回答。路由日志需要记录每次请求的任务类型、执行者、延迟、成本、校验是否通过，以及玩家是否在这一轮之后有明显的负面反馈，比如连续跳过对话。把这些日志汇总，才能发现“本应端侧处理的短句被频繁送上云”这类浪费，也能发现小模型在某类任务上的失败率偏高。非确定性系统的评测很困难，路由策略需要结合自动评测与线上小流量实验反复调整。

路由也带来新的风险：不同模型的口吻略有差异，玩家可能感到同一个角色时而聪明时而迟钝。缓解办法是把人设与语气约束放在共享的角色档案里，而不是分别写进各个模型的提示词。更大的图景可以对照游戏世界模型一文，栏目里的其他内容则可以从PA真人AI大模型栏目继续阅读。