首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >API 成本降低 73%!多模型智能路由,简单问题走小模型、复杂问题走大模型

API 成本降低 73%!多模型智能路由,简单问题走小模型、复杂问题走大模型

作者头像
行者全栈架构师
发布2026-07-21 12:20:35
发布2026-07-21 12:20:35
930
举报

我的 AIOps 平台每天处理 5000+ 次 AI 调用,全部走 Qwen2.5-72B,每月 API 费用 1.2 万元。检查日志发现:60% 的调用用小模型就能胜任,却全部消耗大模型 token。就像用货车送快递,能效比极低。

01 全部走大模型的成本困局

我负责的 AIOps 平台每天处理 5000+ 次 AI 调用,全部走 Qwen2.5-72B,每月 API 费用约 1.2 万元。

分析调用日志后,发现惊人的浪费:

调用类型

占比

实际所需模型

浪费程度

告警摘要

40%

小模型即可

🔴 高

日志格式化

20%

小模型即可

🔴 高

配置审查

15%

中等模型

🟡 中

根因分析

15%

大模型

🟢 低

架构建议

10%

大模型

🟢 低

核心发现:60% 的调用用小模型就能胜任,却全部消耗大模型的 token。

图:智能路由监控看板,实时展示各模型调用分布

02 智能路由架构设计

整个路由系统分为三层:请求接入 → 智能路由引擎 → 多模型服务池

模型能力与成本对比

维度

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 会详细对比。

03 任务分类器:规则 + 轻量模型双层分类

为什么用规则 + 轻量模型双层分类?纯规则无法覆盖所有场景,纯模型又有延迟和成本开销。双层结构兼顾准确性和效率。

分类器核心代码

代码语言:javascript
复制
#!/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")

路由输出效果

代码语言:javascript
复制
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 元——这就是路由的价值。

04 成本对比:从 1.2 万降到 0.32 万

月度成本模拟

场景

大模型调用量

中模型调用量

小模型调用量

月度成本

全部走 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% 大模型分配,能省多少?欢迎评论区算一算~

05 三个踩坑实录,每一个都是真金白银的教训

坑 1:小模型处理复杂任务结果质量差

现象:告警摘要用 7B 模型生成,但多条关联告警合并时逻辑混乱,丢失关键信息。

原因:路由规则只按关键词匹配,"告警摘要"被分到简单任务,但"多条关联告警合并摘要"实际需要中等推理能力。

解决:增加输入复杂度评估——输入超过 2000 token 或涉及多个数据源时,自动升级模型:

代码语言:javascript
复制
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 表面,输入规模和数据源数量也是关键信号。

坑 2:本地 Ollama 服务不稳定导致批量失败

现象:GPU 温度过高导致 Ollama 推理超时,大量简单任务路由到本地后 50% 失败。

原因:路由策略没有考虑模型服务的实时可用性,本地 GPU 故障时仍继续路由。

解决:增加模型健康检查机制,不可用时自动降级到云端小模型:

代码语言:javascript
复制
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)

提醒:本地模型是"锦上添花",必须有云端降级兜底方案。

坑 3:路由决策过慢抵消了成本节省

现象:路由分类器对每个请求做 Embedding 计算相似度,单次路由耗时 500ms,7B 模型推理才 800ms,路由开销占比过高。

原因:初期用 Embedding 相似度做任务分类,每次请求都要调 Embedding API,延迟和成本都很高。

解决:从 Embedding 方案改为关键词正则 + 缓存方案,路由决策降到 < 5ms:

代码语言:javascript
复制
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

代码语言:javascript
复制
# 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       # 每周一重训练分类器

06 总结

多模型智能路由的核心价值:

  • API 成本:从 1.2 万/月 → 0.32 万/月(⬇️ 73%)
  • 平均延迟:从 2.5s → 1.1s(⬇️ 56%)
  • 本地资源利用:GPU 利用率从 0% → 65%

适用场景:AI 调用量大(1000+ 次/天)、任务类型多样、有本地 GPU 资源的团队

不适用场景:调用量小(< 100 次/天)、任务类型单一、无本地 GPU 资源

💬 你的团队用几个模型?有没有做过路由优化?欢迎评论区聊聊你的方案~ 💡 下期预告:AIOps 可观测性——构建全栈监控与智能诊断体系,从日志、指标、Trace 三维度实现智能排障。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-07-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 行者架构谈 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 01 全部走大模型的成本困局
  • 02 智能路由架构设计
    • 模型能力与成本对比
  • 03 任务分类器:规则 + 轻量模型双层分类
    • 分类器核心代码
    • 路由输出效果
  • 04 成本对比:从 1.2 万降到 0.32 万
    • 月度成本模拟
    • 路由分发比例
    • 成本节省明细
  • 05 三个踩坑实录,每一个都是真金白银的教训
    • 坑 1:小模型处理复杂任务结果质量差
    • 坑 2:本地 Ollama 服务不稳定导致批量失败
    • 坑 3:路由决策过慢抵消了成本节省
    • 路由监控体系
  • 06 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档