智能LLM路由系统：46个模型基准测试与14维分类器

构建一个 Smart LLM Router

2026 年 4 月 22 日 | BlockRun Engineering

当你需要在 8 个提供商的 55+ 个模型之间路由 AI 请求时，不能只选最便宜的那个，也不能只选最快的那个。我们是吃了苦头才明白这一点的。

这篇文章讲述了我们如何对平台上的每个模型进行 benchmark，发现速度和智能之间的相关性很弱，并构建了一个生产级 routing system：使用 14 个加权维度和 sigmoid confidence calibration，在 1ms 内完成请求分类。

问题：一个 Gateway，46 个模型，无穷无尽的错误选择

BlockRun 是一个 x402 micropayment gateway。每个 LLM 请求都会经过我们的 proxy，通过链上 USDC payment 完成认证，然后转发到相应的 provider。payment overhead 会给每个请求增加 50-100ms。

我们的用户会设置 model: "auto"，并期待我们替他们选出正确的模型。但“正确”对于不同请求有不同的含义：

• “什么是 Python？” 这类查询应该路由到最便宜、最快的模型
• “实现一个支持并发插入的 B-tree” 这类查询需要能力更强的模型
• “逐步证明这个 theorem” 这类查询需要 reasoning capabilities
• 带有 tool calls 的 agentic workflow 需要能够严格遵循指令的模型

我们需要一个系统，能够对任意请求进行分类，并实时路由到最优模型。

第 1 步：对 Fleet 进行 Benchmark

在构建 router 之前，我们需要 ground truth。我们通过生产环境中的 payment pipeline，对全部 55+ 个模型进行了 benchmark。

方法

Setup:     ClawRouter v0.12.47 proxy on localhost
           → BlockRun x402 gateway (Base EVM chain)
           → Provider APIs (OpenAI, Anthropic, Google, xAI, DeepSeek, Moonshot, MiniMax, Z.AI)

Prompts:   3 Python coding tasks (IPv4 validation, LCS algorithm, LRU cache)
           2 requests per model per prompt
Config:    256 max tokens, non-streaming, temperature 0.7
Measured:  End-to-end wall clock time (includes x402 payment verification)

这不是 synthetic benchmark。每次测量都包含真实用户会经历的完整 payment-verification round trip。

Latency Landscape

结果显示，最快和最慢的模型之间存在 7 倍差距：

FAST TIER (<1.5s):
  xai/grok-4-fast           1,143ms   224 tok/s   $0.20/$0.50
  xai/grok-3-mini           1,202ms   215 tok/s   $0.30/$0.50
  google/gemini-2.5-flash   1,238ms   208 tok/s   $0.30/$2.50
  google/gemini-2.5-pro     1,294ms   198 tok/s   $1.25/$10.00
  google/gemini-3-flash     1,398ms   183 tok/s   $0.50/$3.00
  deepseek/deepseek-chat    1,431ms   179 tok/s   $0.28/$0.42

MID TIER (1.5-2.5s):
  google/gemini-3.1-pro     1,609ms   167 tok/s   $2.00/$12.00
  moonshot/kimi-k2.5        1,646ms   156 tok/s   $0.60/$3.00
  anthropic/claude-sonnet   2,110ms   121 tok/s   $3.00/$15.00
  anthropic/claude-opus     2,139ms   120 tok/s   $5.00/$25.00
  openai/o3-mini            2,260ms   114 tok/s   $1.10/$4.40

SLOW TIER (>3s):
  openai/gpt-5.2-pro        3,546ms    73 tok/s   $21.00/$168.00
  openai/gpt-4o             5,378ms    48 tok/s   $2.50/$10.00
  openai/gpt-5.4            6,213ms    41 tok/s   $2.50/$15.00
  openai/gpt-5.3-codex      7,935ms    32 tok/s   $1.75/$14.00

这里有两个明显的规律：

1. Google 和 xAI 在速度上占据主导。最快的 13 个模型中，有 11 个来自 Google 或 xAI。
2. OpenAI 的旗舰模型始终偏慢。所有 GPT-5.x 模型都需要 3-8 秒。即使是它们最便宜的模型（GPT-4.1-nano，$0.10/$0.40），也比 Google 最便宜的模型慢 2 倍。

第 2 步：加入 Quality 维度

单看速度，并不能说明某个模型是否真的能处理你的请求。我们将 latency 数据与 Artificial Analysis Intelligence Index v4.0 分数进行交叉比对（该分数综合了 GPQA、MMLU、MATH、HumanEval 和其他 benchmark）：

MODEL                       LATENCY    IQ    $/M INPUT
─────────────────────────────────────────────────────
google/gemini-3.1-pro       1,609ms    57    $2.00    ← SWEET SPOT
openai/gpt-5.4              6,213ms    57    $2.50
openai/gpt-5.3-codex        7,935ms    54    $1.75
anthropic/claude-opus-4.6   2,139ms    53    $5.00
anthropic/claude-sonnet-4.6 2,110ms    52    $3.00
google/gemini-3-pro-prev    1,352ms    48    $2.00
moonshot/kimi-k2.5          1,646ms    47    $0.60
google/gemini-3-flash-prev  1,398ms    46    $0.50    ← VALUE SWEET SPOT
xai/grok-4                  1,348ms    41    $0.20
xai/grok-4.1-fast           1,244ms    41    $0.20
deepseek/deepseek-chat      1,431ms    32    $0.28
xai/grok-4-fast             1,143ms    23    $0.20
google/gemini-2.5-flash     1,238ms    20    $0.30

Efficiency Frontier

将 IQ 与 latency 画在同一张图上后，可以看到一条清晰的 efficiency frontier：

IQ
57 |  Gem3.1Pro ·························· GPT-5.4
   |
53 |                    · Opus
52 |                   · Sonnet
   |
48 |  Gem3Pro ·
47 |   · Kimi
46 |  Gem3Flash ·
   |
41 |  Grok4 ·
   |
32 | Grok3 · · DeepSeek
   |
23 | GrokFast ·
20 | GemFlash ·
   └──────────────────────────────────────────────
     1.0   1.5   2.0   2.5   3.0        6.0  8.0
                 End-to-End Latency (seconds)

这条 frontier 从 Gemini 2.5 Flash（IQ 20，1.2s）一直延伸到 Gemini 3.1 Pro（IQ 57，1.6s）。位于这条线右上方的模型都处于 dominated 状态——你可以从其他模型那里，以更低的 latency 获得同等或更好的质量。

关键洞察是：Gemini 3.1 Pro 用 1/4 的 latency 和更低的成本，达到了 GPT-5.4 相同的 IQ。Claude Sonnet 4.6 以 60% 的价格，几乎达到了 Opus 4.6 的质量。这些 dominated pairing 直接影响了我们的 routing fallback chains。

第 3 步：失败的实验（Latency-First Routing）

拿到 benchmark 数据后，我们最初优先优化速度。routing config 里优先使用快速模型：

// v0.12.47 — latency-optimized（已回滚）
COMPLEX: {
  primary: "xai/grok-4-0709",           // 1,348ms, IQ 41
  fallback: [
    "xai/grok-4-1-fast-non-reasoning",  // 1,244ms, IQ 41
    "google/gemini-2.5-flash",           // 1,238ms, IQ 20
    // ... fast models first
  ],
}

用户在 24 小时内就开始抱怨了。快速模型会拒绝处理复杂任务，并给出浅层回答。一个 IQ 41 的模型，无论速度多快，都无法可靠地处理 architecture design 或多步 code generation。

经验教训是：在一个多目标系统里，只优化单一指标会产生 failure modes。我们需要同时在速度、质量和成本上进行优化。

第 4 步：14 维评分系统

router 在选择模型之前，需要先判断当前请求属于哪一类。我们构建了一个基于规则的 classifier，对 14 个加权维度进行打分：

架构

User Prompt → Lowercase + Tokenize
                    ↓
            ┌──────────────────────────────────┐
            │   14 Dimension Scorers           │
            │   Each returns score ∈ [-1, 1]   │
            └──────┬───────────────────────────┘
                   ↓
            Weighted Sum (configurable weights)
                   ↓
            Tier Boundaries (SIMPLE < 0.0 < MEDIUM < 0.3 < COMPLEX < 0.5 < REASONING)
                   ↓
            Sigmoid Confidence Calibration
                   ↓
            confidence < 0.7 → AMBIGUOUS → default to MEDIUM
            confidence ≥ 0.7 → Classified tier
                   ↓
            Tier × Profile → Model Selection

14 个维度

weights 总和为 1.0。加权分数会映射到一条连续轴上，再由 tier boundaries 对该空间进行划分。

多语言支持

每个关键词列表都包含 9 种语言的翻译（EN、ZH、JA、RU、DE、ES、PT、KO、AR）。当中文用户输入“证明这个定理”时，会触发与 “prove this theorem” 相同的 reasoning 分类。

Confidence Calibration

当分数接近边界时，原始 tier 分配可能会比较 ambiguous。我们使用 sigmoid calibration：

confidence = 1 / (1 + exp(-steepness * distance_from_boundary))

其中，steepness = 12，distance_from_boundary 表示该分数到最近 tier boundary 的距离。它会被映射到 [0.5, 1.0] 的 confidence 区间。低于阈值 0.7 时，请求会被分类为 ambiguous，并默认归入 MEDIUM。

Agentic Detection

还有一条单独的评分路径用于检测 agentic tasks（多步骤、使用 tool、迭代式）。当 agenticScore >= 0.5 时，router 会切换到针对 agentic 优化的 tier configs，优先选择指令遵循能力强的模型（复杂任务使用 Claude Sonnet，简单 tool calls 使用 GPT-4o-mini）。

第 5 步：Tier 到 Model 的映射

一旦请求被归类到某个 tier，router 就会从 4 种 routing profiles 中进行选择：

Auto Profile（默认）

根据我们的 benchmark 数据和用户留存指标进行调优：

SIMPLE  → gemini-2.5-flash (1,238ms, IQ 20, 60% retention)
MEDIUM  → kimi-k2.5 (1,646ms, IQ 47, strong tool use)
COMPLEX → gemini-3.1-pro (1,609ms, IQ 57, fastest flagship)
REASON  → grok-4-1-fast-reasoning (1,454ms, $0.20/$0.50)

Eco Profile

极致成本优化，使用免费或近乎免费的模型：

SIMPLE  → nvidia/gpt-oss-120b (FREE)
MEDIUM  → gemini-2.5-flash-lite ($0.10/$0.40, 1M context)
COMPLEX → gemini-2.5-flash-lite ($0.10/$0.40)
REASON  → grok-4-1-fast-reasoning ($0.20/$0.50)

Premium Profile

不计成本，追求最佳质量：

SIMPLE  → kimi-k2.5 ($0.60/$3.00)
MEDIUM  → gpt-5.3-codex ($1.75/$14.00, 400K context)
COMPLEX → claude-opus-4.6 ($5.00/$25.00)
REASON  → claude-sonnet-4.6 ($3.00/$15.00)

Fallback Chains

每个 tier config 都包含一个有序的 fallback list。当 primary 模型返回 402（payment failed）、429（rate limited）或 5xx 时，proxy 会沿着 fallback chain 依次尝试。fallback 的排序是基于 benchmark 得出的：

// COMPLEX tier — quality-first fallback order
fallback: [
  "google/gemini-3-pro-preview", // IQ 48, 1,352ms
  "google/gemini-3-flash-preview", // IQ 46, 1,398ms
  "xai/grok-4-0709", // IQ 41, 1,348ms
  "google/gemini-2.5-pro", // 1,294ms
  "anthropic/claude-sonnet-4.6", // IQ 52, 2,110ms
  "deepseek/deepseek-chat", // IQ 32, 1,431ms
  "google/gemini-2.5-flash", // IQ 20, 1,238ms
  "openai/gpt-5.4", // IQ 57, 6,213ms — last resort
];

这条 chain 会先按质量下降的顺序排列（IQ 48 → 46 → 41），然后再用质量换取速度。GPT-5.4 虽然 IQ 达到 57，但仍然排在最后，因为它 6.2s 的 latency 会带来最糟糕的用户体验。

第 6 步：上下文感知过滤

fallback chain 会在运行时根据请求属性进行过滤：

1. 上下文窗口过滤：如果模型的上下文窗口不足以容纳估计的总 token 数，就会被排除（保留 10% 的安全缓冲）
2. Tool calling 过滤：当请求包含 tool definitions 时，只保留支持 function calling 的模型
3. Vision 过滤：当请求包含图片时，只保留具备 vision 能力的模型

如果过滤后所有候选都被移除，就会回退到完整 chain（让 API 报错也比什么都不返回更好）。

成本计算与节省

每个 routing decision 都会给出相对于基线（Claude Opus 4.6 定价）的 cost estimate 和 savings percentage：

savings = max(0, (opusCost - routedCost) / opusCost);

对于一个典型的 SIMPLE 请求（500 个输入 token，256 个输出 token）：

• Opus cost: $0.0089（按每 1M tokens $5.00/$25.00 计算）
• Gemini Flash cost: $0.0008（按每 1M tokens $0.30/$2.50 计算）
• Savings: 91.0%

在我们的用户群中，相比把所有请求都路由到 premium model，median savings rate 为 85%。

性能

整个 classification pipeline（14 个维度 + tier mapping + model selection）的运行时间不到 1ms。没有外部 API 调用，没有 LLM inference，纯粹依靠关键词匹配和算术运算。

我们最初设计的是一个两阶段系统：当基于规则的分类置信度较低时，会回退到一个 LLM classifier（Gemini 2.5 Flash）。但在实际中，这套规则已经能以高置信度处理 70-80% 的请求，剩余的模糊情况则默认归入 MEDIUM——这是一个正确且保守的选择。

我们学到了什么

1. Speed 和 intelligence 的相关性很弱。最快的模型（Grok 4 Fast，IQ 23）位于质量榜单底部。低 latency 下最聪明的模型（Gemini 3.1 Pro，IQ 57，1.6s）来自 Google，而不是 OpenAI。
2. 优化单一指标会失败。latency-first routing 会破坏质量，quality-first routing 会破坏 latency 预算。你需要 multi-objective optimization。
3. User retention 才是真正的指标。我们在 SIMPLE 任务上表现最好的模型，不是最便宜也不是最快的，而是 Gemini 2.5 Flash（60% retention rate），因为它在速度、成本和足够好的质量之间取得了平衡。
4. Fallback 的排序比 primary 的选择更重要。primary 模型处理的是 happy path，fallback chain 处理的是现实——rate limits、outages、payment failures。一个排序良好的 fallback chain，比挑选出一个完美的 primary 更重要。
5. 基于规则的分类被低估了。14 个关键词维度加上 sigmoid confidence calibration，能在 <1ms 内正确处理 70-80% 的请求。剩下的 20-30% 则默认进入一个安全的中间 tier。对于一个 routing system 来说，在 classification 步骤中避免 LLM inference 所节省的每一毫秒 overhead 都很有价值，即使这会牺牲一部分准确率。

附录：完整 Benchmark 数据

• 原文链接： x.com/cheetah_x0/status/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～