
我的 AIOps 平台每天处理 5000+ 次 AI 调用,全部走 Qwen2.5-72B,每月 API 费用 1.2 万元。检查日志发现:60% 的调用用小模型就能胜任,却全部消耗大模型 token。就像用货车送快递,能效比极低。
我负责的 AIOps 平台每天处理 5000+ 次 AI 调用,全部走 Qwen2.5-72B,每月 API 费用约 1.2 万元。
分析调用日志后,发现惊人的浪费:
调用类型 | 占比 | 实际所需模型 | 浪费程度 |
|---|---|---|---|
告警摘要 | 40% | 小模型即可 | 🔴 高 |
日志格式化 | 20% | 小模型即可 | 🔴 高 |
配置审查 | 15% | 中等模型 | 🟡 中 |
根因分析 | 15% | 大模型 | 🟢 低 |
架构建议 | 10% | 大模型 | 🟢 低 |
核心发现:60% 的调用用小模型就能胜任,却全部消耗大模型的 token。


图:智能路由监控看板,实时展示各模型调用分布
整个路由系统分为三层:请求接入 → 智能路由引擎 → 多模型服务池。

维度 | Qwen2.5-7B (本地) | Qwen2.5-32B (云端) | Qwen2.5-72B (云端) |
|---|---|---|---|
推理能力 | 基础 | 中等 | 强 |
上下文长度 | 32K | 32K | 128K |
单次调用成本 | 0 元 | 0.008 元 | 0.04 元 |
平均延迟 | 800ms | 1.2s | 2.5s |
适用场景 | 摘要/格式化/分类 | 配置审查/告警聚类 | 根因分析/架构设计 |
可用性 | 99.5% (依赖本地 GPU) | 99.9% | 99.9% |
你可能会问:为什么不用 Embedding 做分类?因为 Embedding 每次请求都要调 API,路由延迟和成本都很高。后面踩坑 3 会详细对比。
为什么用规则 + 轻量模型双层分类?纯规则无法覆盖所有场景,纯模型又有延迟和成本开销。双层结构兼顾准确性和效率。
#!/usr/bin/env python3
"""
多模型智能路由引擎
根据任务复杂度自动选择合适的模型
"""
import re
from dataclasses import dataclass
from enum import Enum
class Complexity(Enum):
"""任务复杂度"""
SIMPLE = "simple" # 简单:摘要、格式化、分类
MODERATE = "moderate" # 中等:配置审查、告警聚类
COMPLEX = "complex" # 复杂:根因分析、架构设计
class Model(Enum):
"""可用模型"""
QWEN_7B_LOCAL = "qwen2.5:7b" # 本地 Ollama
QWEN_32B_CLOUD = "qwen2.5:32b" # 云端
QWEN_72B_CLOUD = "qwen2.5:72b" # 云端
@dataclass
class RoutingResult:
"""路由结果"""
complexity: Complexity
model: Model
reason: str
estimated_tokens: int
estimated_cost: float
# 关键词 -> 复杂度映射规则
COMPLEXITY_RULES = {
Complexity.SIMPLE: [
r"摘要|总结|概括",
r"格式化|整理|清洗",
r"分类|归类|打标签",
r"翻译|转换",
r"提取.*?关键字",
],
Complexity.MODERATE: [
r"审查|检查|校验",
r"对比|比较|差异",
r"聚类|聚合|关联",
r"优化建议|改进",
],
Complexity.COMPLEX: [
r"根因|根本原因|为什么",
r"架构|设计|方案",
r"排查|诊断|定位",
r"生成.*?策略|制定.*?计划",
r"分析.*?链路|完整.*?流程",
],
}
# 复杂度 -> 模型映射
COMPLEXITY_MODEL_MAP = {
Complexity.SIMPLE: Model.QWEN_7B_LOCAL,
Complexity.MODERATE: Model.QWEN_32B_CLOUD,
Complexity.COMPLEX: Model.QWEN_72B_CLOUD,
}
# 模型单 token 成本(元/千 token)
MODEL_COST = {
Model.QWEN_7B_LOCAL: 0.0,
Model.QWEN_32B_CLOUD: 0.002,
Model.QWEN_72B_CLOUD: 0.01,
}
def classify_complexity(prompt: str) -> Complexity:
"""根据 Prompt 内容判断任务复杂度"""
for complexity in [Complexity.COMPLEX,
Complexity.MODERATE,
Complexity.SIMPLE]:
patterns = COMPLEXITY_RULES[complexity]
for pattern in patterns:
if re.search(pattern, prompt):
return complexity
return Complexity.MODERATE
def route(prompt: str, input_length: int = 0) -> RoutingResult:
"""智能路由:选择合适的模型"""
complexity = classify_complexity(prompt)
# 长上下文自动升级模型
if input_length > 30000 and complexity != Complexity.COMPLEX:
complexity = Complexity.COMPLEX
reason = "输入超 30K token,升级至大模型"
else:
reason = f"任务匹配 {complexity.value} 级别"
model = COMPLEXITY_MODEL_MAP[complexity]
estimated_tokens = max(input_length, 500) + 300
estimated_cost = (estimated_tokens / 1000) * MODEL_COST[model]
return RoutingResult(
complexity=complexity,
model=model,
reason=reason,
estimated_tokens=estimated_tokens,
estimated_cost=estimated_cost
)
# 使用示例
test_prompts = [
"帮我总结这条告警的核心信息",
"审查这个 Nginx 配置有没有安全隐患",
"分析这次故障的根因,给出完整的推理链路",
]
for p in test_prompts:
result = route(p)
print(f"Prompt: {p}")
print(f" → 复杂度: {result.complexity.value}")
print(f" → 模型: {result.model.value}")
print(f" → 预估成本: {result.estimated_cost:.4f} 元\n")
Prompt: 帮我总结这条告警的核心信息
→ 复杂度: simple
→ 模型: qwen2.5:7b
→ 预估成本: 0.0000 元
Prompt: 审查这个 Nginx 配置有没有安全隐患
→ 复杂度: moderate
→ 模型: qwen2.5:32b
→ 预估成本: 0.0016 元
Prompt: 分析这次故障的根因,给出完整的推理链路
→ 复杂度: complex
→ 模型: qwen2.5:72b
→ 预估成本: 0.0080 元
简单任务 0 成本,中等任务 0.0016 元,复杂任务 0.008 元——这就是路由的价值。
场景 | 大模型调用量 | 中模型调用量 | 小模型调用量 | 月度成本 |
|---|---|---|---|---|
全部走 72B | 15 万次 | 0 | 0 | 1.2 万元 |
智能路由 | 2.25 万次 | 2.25 万次 | 10.5 万次 | 0.32 万元 |

指标 | 全大模型 | 智能路由 | 节省 |
|---|---|---|---|
月度 API 成本 | 1.2 万 | 0.32 万 | ⬇️ 73% |
平均响应延迟 | 2.5s | 1.1s | ⬇️ 56% |
本地 GPU 利用率 | 0% | 65% | ⬆️ — |
云端调用量 | 15 万 | 4.5 万 | ⬇️ 70% |

图:调用成本对比,智能路由显著降低每月 API 支出
💡 思考题:你的团队每月 AI 调用成本是多少?如果按 70% 小模型、15% 中模型、15% 大模型分配,能省多少?欢迎评论区算一算~
现象:告警摘要用 7B 模型生成,但多条关联告警合并时逻辑混乱,丢失关键信息。
原因:路由规则只按关键词匹配,"告警摘要"被分到简单任务,但"多条关联告警合并摘要"实际需要中等推理能力。
解决:增加输入复杂度评估——输入超过 2000 token 或涉及多个数据源时,自动升级模型:
def refine_routing(prompt: str, context: dict) -> RoutingResult:
"""精细化路由:结合输入特征调整"""
base_result = route(prompt, context.get("input_length", 0))
# 输入过长,升级模型
if context.get("input_length", 0) > 2000:
if base_result.complexity == Complexity.SIMPLE:
base_result.complexity = Complexity.MODERATE
base_result.model = Model.QWEN_32B_CLOUD
base_result.reason += " + 输入较长自动升级"
# 多数据源关联,升级模型
if context.get("multi_source", False):
base_result.complexity = Complexity.MODERATE
base_result.model = Model.QWEN_32B_CLOUD
base_result.reason += " + 多源数据自动升级"
return base_result
提醒:路由不能只看 Prompt 表面,输入规模和数据源数量也是关键信号。
现象:GPU 温度过高导致 Ollama 推理超时,大量简单任务路由到本地后 50% 失败。
原因:路由策略没有考虑模型服务的实时可用性,本地 GPU 故障时仍继续路由。
解决:增加模型健康检查机制,不可用时自动降级到云端小模型:
import time
class ModelHealthChecker:
"""模型健康检查器"""
def __init__(self):
self.health_status = {}
def check(self, model: Model) -> bool:
"""检查模型是否可用"""
status = self.health_status.get(model.value)
if status and time.time() - status["last_check"] < 30:
return status["healthy"]
try:
if model == Model.QWEN_7B_LOCAL:
resp = requests.post(
"http://localhost:11434/api/generate",
json={"model": "qwen2.5:7b",
"prompt": "ping", "stream": False},
timeout=5
)
healthy = resp.status_code == 200
else:
healthy = True
except requests.RequestException:
healthy = False
self.health_status[model.value] = {
"healthy": healthy,
"last_check": time.time(),
"fail_count": 0 if healthy
else self.health_status.get(model.value, {}).get("fail_count", 0) + 1
}
return healthy
def get_fallback(self, model: Model) -> Model:
"""获取降级模型"""
fallback_map = {
Model.QWEN_7B_LOCAL: Model.QWEN_32B_CLOUD,
Model.QWEN_32B_CLOUD: Model.QWEN_72B_CLOUD,
Model.QWEN_72B_CLOUD: None,
}
return fallback_map.get(model)
提醒:本地模型是"锦上添花",必须有云端降级兜底方案。
现象:路由分类器对每个请求做 Embedding 计算相似度,单次路由耗时 500ms,7B 模型推理才 800ms,路由开销占比过高。
原因:初期用 Embedding 相似度做任务分类,每次请求都要调 Embedding API,延迟和成本都很高。
解决:从 Embedding 方案改为关键词正则 + 缓存方案,路由决策降到 < 5ms:
from functools import lru_cache
@lru_cache(maxsize=1000)
def cached_classify(prompt_prefix: str) -> Complexity:
"""缓存分类结果,相同前缀不重复计算"""
return classify_complexity(prompt_prefix)
def fast_route(prompt: str) -> RoutingResult:
"""快速路由:用前 50 字符做缓存 key"""
prefix = prompt[:50].strip()
complexity = cached_classify(prefix)
model = COMPLEXITY_MODEL_MAP[complexity]
return RoutingResult(
complexity=complexity,
model=model,
reason="cached routing",
estimated_tokens=500,
estimated_cost=0
)
提醒:路由决策本身的开销必须远小于模型推理时间,否则就是"为了省钱花了更多钱"。
路由系统上线后,需要持续监控各模型调用量、延迟和成本的变化:
监控项 | 采集方式 | 更新间隔 | 告警阈值 | 严重级别 |
|---|---|---|---|---|
模型调用失败率 | 日志统计 | 60s | > 5% | P1 |
分类器准确率 | 用户反馈 | 3600s | < 85% | P1 |
各模型 Token 消耗趋势 | 统计 | 3600s | 突增 > 50%/天 | P2 |
大模型调用占比 | 统计 | 3600s | > 40% | P2 |
路由决策延迟 | API 监控 | 60s | P99 > 200ms | P2 |
模型降级触发 | 日志 | 60s | 任何降级事件 | P1 |
# Crontab 配置:路由优化定时任务
0 4 * * * /opt/scripts/routing_optimizer.sh # 每天凌晨优化路由策略
0 */6 * * * /opt/scripts/model_cost_review.sh # 每6小时成本回顾
*/5 * * * * /opt/scripts/routing_health_check.sh # 每5分钟路由健康检查
0 8 * * 1 /opt/scripts/classifier_retrain.sh # 每周一重训练分类器
多模型智能路由的核心价值:
适用场景:AI 调用量大(1000+ 次/天)、任务类型多样、有本地 GPU 资源的团队
不适用场景:调用量小(< 100 次/天)、任务类型单一、无本地 GPU 资源
💬 你的团队用几个模型?有没有做过路由优化?欢迎评论区聊聊你的方案~ 💡 下期预告:AIOps 可观测性——构建全栈监控与智能诊断体系,从日志、指标、Trace 三维度实现智能排障。