当前位置：首页 > 文章列表 > 科技周边 > 人工智能 > 模型路由怎样按任务难度分配不同推理预算

模型路由怎样按任务难度分配不同推理预算

来源：17golang原创 2026-10-09 15:39:12 0浏览收藏

模型路由分配推理预算，最稳的做法不是“输入越长就用越贵的模型”，而是把决策拆成三件事：先用可观测特征判断任务难度，再分别选择模型档位和推理强度，最后设置延迟、成本、输出长度与工具调用次数等硬上限。第一次调用只拿满足要求的最低预算；结构校验失败、工具错误或证据覆盖不足时，才升级一档。

要点速览

模型能力与推理强度是两个旋钮，不能合并成一个“高低配”。
难度要综合任务类型、约束数量、上下文依赖、工具依赖、不确定性和风险。
升级依据优先采用外部校验，不能只相信模型自报的置信度。
用每次成功成本、p95 延迟、升级率和错分率评价路由，而不是只看平均 token。

这次改动：从单一路由变成二维预算

很多系统最初只有一条规则：普通请求走小模型，重要请求走大模型。问题是，大模型也可以用较低推理强度快速完成简单任务，小模型即使“多想”也未必具备处理复杂约束的能力。因此路由表至少要分开记录 model_tier 和 reasoning_effort。

不同厂商对推理控制的命名并不一致，例如 reasoning effort、effort 或 thinking level；它们通常是软控制，不等于精确分配固定数量的“思考 token”。输出 token 上限、请求超时和费用上限属于硬控制，设得太低会直接截断结果。路由层应把这两类参数分开管理，不要用缩短输出上限代替降低推理强度。

为什么统一预算会同时浪费和欠账

统一高预算的浪费最直观：分类、字段抽取、格式改写等任务被迫承担更高延迟与费用。统一低预算的问题更隐蔽：多文件代码修改、跨文档归纳、带工具调用的规划任务可能给出表面完整但遗漏约束的答案。平均成功率看起来尚可，长尾任务却持续失败。

输入长度也不是可靠的难度代理。一个很长的日志可能只是提取固定字段，而一句“设计零停机迁移方案”可能包含大量隐含约束。真正影响预算的是任务需要多少步推导、多少外部证据，以及错误后果是否可接受。

难度判断要看六类信号

信号	低难度表现	需要升级的表现
任务类型	分类、抽取、改写	规划、代码修改、冲突消解
约束数量	目标单一、格式固定	多个硬约束相互影响
上下文依赖	单段即可回答	跨文件、跨文档建立关系
工具依赖	无需工具或一次查询	多工具串联、结果相互依赖
不确定性	输入完整、边界明确	歧义多、缺少关键证据
风险	可逆、可人工快速检查	高影响、不可仅靠自动结果

任务信号、难度层、模型档位、推理强度和硬上限之间的静态映射图 — 图1：任务难度信号与执行预算的静态映射，不是运行截图。

这些信号既可以由确定性规则提取，也可以交给轻量分类器。关键是保留每次路由的特征快照和命中理由，方便发现某条规则是否把大量简单任务误判为复杂任务。高风险任务还要有独立护栏，不能因为难度分数低就绕过人工审批或业务校验。

四档策略先求清楚，再求精细

难度层	典型任务	模型档位	推理强度	硬限制
T0	字段抽取、短文本分类、固定模板改写	轻量	最小或关闭	短超时、少量输出、无工具
T1	有限约束问答、摘要、局部代码解释	标准	低	中等输出、最多一次工具调用
T2	多步分析、跨文档比较、代码修改	增强	中	更长超时、限定工具次数
T3	高影响决策、复杂架构、证据冲突	最强或专用	高	外部校验、人工复核、明确费用上限

表里的具体模型名、推理参数和值域必须由当前供应商文档和实测决定。策略层只保存抽象档位，再由适配器翻译成各家 API 参数。这样更换模型时不必重写业务规则，也不会把某个厂商的参数误当成行业统一标准。

package routing

import "time"

// Features 只保存可观察的任务信号，不依赖模型自报置信度。
type Features struct {
	ConstraintCount int
	CrossDoc         bool
	NeedsTools       bool
	Ambiguous        bool
	HighRisk         bool
}

type Route struct {
	ModelTier   string
	Effort      string
	Deadline    time.Duration
	MaxToolCall int
}

// SelectRoute 返回满足任务要求的最低初始预算。
func SelectRoute(f Features) Route {
	if f.HighRisk || (f.CrossDoc && f.NeedsTools && f.Ambiguous) {
		return Route{"strong", "high", 90 * time.Second, 6}
	}
	if f.CrossDoc || f.NeedsTools || f.ConstraintCount >= 6 {
		return Route{"enhanced", "medium", 45 * time.Second, 3}
	}
	if f.Ambiguous || f.ConstraintCount >= 3 {
		return Route{"standard", "low", 20 * time.Second, 1}
	}
	return Route{"light", "minimal", 8 * time.Second, 0}
}

这段代码只是起点。生产环境还应加入租户预算、模型可用性、区域合规、并发水位与缓存命中等条件，但这些属于执行约束，不应偷偷改变任务本身的难度标签。