一个模型打天下：多模型路由前端的策略层与降级兜底
一、一个模型打天下：AI 应用的成本与延迟死结
去年给一个 AI 客服产品做成本审计，发现一个反常识的事实：80% 的请求只是查订单、问地址、要退款流程，却全部走了旗舰大模型。单次推理成本 0.04 元，月账单 38 万。这事我见过太多团队栽进去------一个模型从立项用到上线，没人想过该分流。
旗舰模型推理强，但慢且贵。简单分类任务用旗舰，等于用大炮打蚊子。更隐蔽的是延迟问题：旗舰模型首 Token 延迟普遍 1.5 秒以上，而客服场景用户对响应敏感，超过 2 秒就开始怀疑是不是断了。成本与延迟，是同一个死结的两端。
正确的做法是在前端之上加一层「模型路由」。根据任务类型、上下文长度、用户分级，把请求分发到不同的模型。推理复杂的走旗舰，简单分类走小模型，代码生成走专用模型。让每个任务匹配性价比最高的模型，而不是所有任务共用一个最贵的。
但路由不是简单 if-else。它要处理规则匹配、成本预算、延迟兜底、失败回退、A/B 灰度。前端这一层做不好，用户体验会剧烈波动------同样一个问题，今天秒回明天转圈。本篇要解决的，就是如何在多模型并存下，让前端路由既省成本又稳体验。
二、任务画像与降级链：多模型路由的底层机制
多模型路由的核心是「任务画像---模型匹配---降级链」三段式。
任务画像从请求中提取特征。维度包括：任务类型（推理、分类、代码、摘要）、输入长度（短文本、长上下文）、用户分级（免费、付费、企业）、延迟敏感度（实时对话、后台批处理）。这些特征组成一个画像向量，作为路由决策的输入。
模型匹配按规则与成本双约束。规则层把任务类型映射到候选模型池，比如「代码任务」候选池是 代码专用模型, 旗舰模型；成本层在候选池里挑当前单价最低的。若用户是付费分级，可解锁更贵的候选；免费用户只能在小模型池里选。
降级链是兜底关键。首选模型超时或报错，自动切到次选；次选也失败，切到兜底小模型；全链失败才返回错误。每一级降级都带超时阈值，避免单模型卡死整个请求。某 AI 助手曾因首选模型雪崩无降级，整站不可用 12 分钟；加降级链后，类似故障用户几乎无感。
A/B 灰度让路由策略可演进。新模型上线先放 5% 流量，对比延迟与质量，达标再放量。预算控制是最后一道闸门：当月成本超阈值，自动把免费用户全量切到小模型，保付费体验。让路由既灵活又不失控。
综上，多模型路由靠三层兜底：首选超时或报错自动切次选、次选失败再切兜底小模型、全链失败才报错，每级带超时阈值；新模型先 5% 灰度验证再放量；成本超阈值自动把免费用户切小模型。把路由层做厚，多模型并存才从「风险」变「冗余」。
三、生产级多模型路由器实现
下面给出一个可复用的模型路由器。它支持任务画像、规则匹配、降级链、预算兜底与 A/B 灰度。
ts
type TaskType = 'reasoning' | 'classification' | 'code' | 'summary';
type Tier = 'free' | 'paid' | 'enterprise';
interface RouteRequest {
task: TaskType;
text: string;
tier: Tier;
abKey?: string; // 用于 A/B 灰度的用户标识
}
interface ModelClient {
name: string;
costPerCall: number; // 单次调用成本，用于预算控制
invoke: (text: string, signal: AbortSignal) => Promise<string>;
}
// 候选链：按优先级排序，前面的失败才切后面的
const candidateChain: Record<TaskType, string[]> = {
reasoning: ['flagship', 'mid', 'small'],
classification: ['small', 'mid'],
code: ['code-pro', 'flagship'],
summary: ['mid', 'small'],
};
export class ModelRouter {
private models = new Map<string, ModelClient>();
private monthlySpent = 0;
private readonly BUDGET_CAP = 100_000; // 月度成本上限，超阈值触发降级
register(name: string, client: ModelClient) {
this.models.set(name, client);
}
async route(req: RouteRequest): Promise<string> {
const chain = this.pickChain(req);
let lastError: unknown = null;
for (const modelName of chain) {
const client = this.models.get(modelName);
if (!client) continue;
// 预算超限且非付费用户，跳过昂贵模型，保住成本底线
if (this.monthlySpent > this.BUDGET_CAP && req.tier === 'free' && client.costPerCall > 0.005) {
continue;
}
try {
const result = await this.invokeWithTimeout(client, req.text, 3000);
this.monthlySpent += client.costPerCall;
this.logRoute(req, modelName, 'ok');
return result;
} catch (err) {
// 记录失败原因，继续尝试下一个候选，不让单模型故障拖垮整条链
lastError = err;
this.logRoute(req, modelName, 'fail');
}
}
throw new Error(`所有候选模型均失败: ${String(lastError)}`);
}
// 按任务类型与 A/B 灰度共同决定候选链
private pickChain(req: RouteRequest): string[] {
const base = candidateChain[req.task];
// A/B 灰度：5% 流量试用新模型，插入候选链首位
if (req.abKey && this.hashToBucket(req.abKey) < 5) {
return ['new-model', ...base];
}
return base;
}
private hashToBucket(key: string): number {
let h = 0;
for (const ch of key) h = (h * 31 + ch.charCodeAt(0)) % 100;
return h;
}
// 单模型调用带超时，超时即 abort，让降级链继续推进
private async invokeWithTimeout(client: ModelClient, text: string, ms: number) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), ms);
try {
return await client.invoke(text, controller.signal);
} finally {
clearTimeout(timer);
}
}
private logRoute(req: RouteRequest, model: string, status: 'ok' | 'fail') {
// 路由日志单独采集，用于事后分析降级率与成本分布
try {
navigator.sendBeacon('/api/route-log', JSON.stringify({ task: req.task, model, status }));
} catch { /* 日志失败不影响主流程 */ }
}
}关键点在于三处。其一，候选链按任务类型预定义，每个任务都有明确的降级路径。其二，预算超限时自动跳过昂贵模型，保付费体验的同时压住免费成本。其三，单模型调用带 3 秒超时，不让慢模型拖垮整条链。某客服产品接入后，月度推理成本从 38 万降到 11 万，P95 延迟从 2.4 秒降到 0.9 秒。
四、路由复杂度与体验波动的代价：适用边界
多模型路由不是没有代价。
第一道代价是体验波动。同一类任务，用户 A 走小模型秒回，用户 B 因灰度走到新模型等了 3 秒，对比之下会觉着「被区别对待」。灰度比例需谨慎控制，新模型未达稳定性门槛前不超过 10%。同时需做请求级一致性，同一用户同一会话内尽量走同一模型，避免中途切换让回答风格跳变。
第二道代价是路由复杂度。任务画像、候选链、预算阈值、灰度比例，参数越多越难调。一个配置错误可能让所有请求都走最贵的模型，成本瞬间爆表。需配套路由策略的可视化面板，实时观察各模型流量分布与降级率，异常自动告警。
第三是质量不一致。不同模型对同一问题的回答风格、准确度、长度都不同。用户连续提问时，如果前一条走旗舰后一条走小模型，体验割裂。需在会话维度固定模型，或对会话内任务类型做一致性约束。
适用边界：高并发、多任务类型、成本敏感的 AI 应用收益最高------客服、搜索摘要、内容审核。单一任务类型、低并发的内部工具，引入路由器徒增复杂度，直接锁定一个模型更省心。
五、总结
多模型路由的工程核心，是按任务画像把请求分发到性价比最高的模型，并用降级链兜底稳定性。落地建议：第一，按任务类型预定义候选链，每条链都有明确降级出口。第二，单模型调用带超时，不让慢模型拖垮整条链。第三，预算超限时自动降级免费用户，保付费体验。第四，A/B 灰度比例严格控制，会话内尽量固定模型避免体验割裂。最终在成本控制与体验稳定之间取得平衡。这条路在千万级调用量下能跑通，回报是值得的。