# 可行性调研与落地实现路线报告

> 项目：多专业小模型 + 路由模型系统（MVP）
> 报告日期：2026-08-12
> 依据：项目内《可行性分析报告》《实现方案》/ 13 篇 arXiv 论文 / 2026 最新业界动态 / 当前代码库实测

---

## 一、TL;DR（先看结论）

1. **可行性：★★★★☆（强烈建议实施）**。技术、成本、生态三个维度证据充分：
   - 路由已成为独立学科与独立服务类别，低成本路由器在 RouterArena 排行榜上以 $0.04/1K 查询成本全面超越 GPT-5（$10.02/1K）；
   - 小模型 + 路由替代大模型已有多篇顶会实证（The Avengers/AAAI 2025、R2R/NeurIPS 2025、StR/EMNLP 2025）；
   - 本项目当前 MVP 已跑通全链路（20 项测试通过、demo 正常、分类 100%/15 条样例）。
2. **核心问题答案：不需要全新架构（推倒重来），但需要"分层演进"**。
   - 现有架构骨架（缓存 → 分类 → 专家池 → Judge → 回退）与 2026 最新综述归纳的六种路由范式、与 Not Diamond / OrcaRouter / vLLM-SR 等生产路由产品完全同构；
   - 代码抽象（`Base*` 接口 + 配置驱动）已经为演进预留了接口，**换实现不换架构**；
   - 需要变化的是**每一层"内部实现"**（规则 → 训练模型、Mock → 真实模型、启发式 → LLM-as-Judge）和**部署形态**（单体进程 → 推理服务 + 网关），这两者属于"升级"而非"重写"。
3. **什么情况下才需要全新架构**（见第四章）：多租户高并发（QPS≥100）、流式输出、分布式多机推理、模型热加载、多模态/长上下文。若这些成为硬需求，给出三套备选方案与迁移路径（第五章）。
4. **推荐落地路线**（见第六章）：5 个阶段、约 14–20 周，从"完全本地真实链路"起步（不依赖任何 API key），到"本地小模型推理 + 训练分类器 + embedding 缓存 + RouterArena 评测 + 生产化"。

---

## 二、项目现状盘点（2026-08-12 实测）

### 2.1 已完成（对应实现方案第一阶段 MVP）

| 能力 | 状态 | 实测结果 |
|------|------|---------|
| 全链路路由（缓存→分类→专家→Judge→回退） | ✅ 可运行 | `scripts/demo.py` exit 0，平均延迟 ~14ms |
| 5 领域意图分类（code/math/legal/medical/general） | ✅ 规则分类器 | 15 条评测样例准确率 100% |
| 两阶段缓存（L1 精确 + L2 n-gram 语义） | ✅ 零依赖 | eval 缓存命中率 40% |
| Judge 质量控制器 + 升级机制 | ✅ 启发式 | 升级率 20%（达标 ≤20%） |
| FastAPI 网关（/chat /health /metrics） | ✅ | 20 项单元测试全部通过 |
| 论文调研（13 篇 PDF + 2026 survey） | ✅ | `research/2026_papers_survey.md` |

### 2.2 当前短板（决定路线图的输入）

| 短板 | 现状 | 与目标的差距 |
|------|------|-------------|
| 分类器 | 关键词规则，仅 15 条样例验证 | 目标 ≥95% 且可扩展；规则在更大数据上会掉点 |
| 专家池 | 全部 Mock 模板输出 | 无真实推理，成本/延迟/质量均未验证 |
| Judge | 启发式打分（覆盖度/长度/格式） | 无法评估事实性与逻辑正确性 |
| 缓存 | 字符 n-gram 相似度 | 语义质量弱，应升级为 embedding 检索 |
| 回退层 | Mock | 升级为本地 7B 量化模型（DeepSeek-R1-Distill-Qwen-7B）兜底，完全本地 |
| 评测 | 自建 15 条迷你基准 | 未接入 RouterArena 标准化评测 |
| 路由决策 | 仅"领域+置信度" | 无预算感知（R2-Router）、无级联深度控制 |
| 工程小问题 | eval.py 控制台 GBK 崩溃、test_cache.py 中文损坏 | 见第七章修复清单 |

---

## 三、可行性调研结论

### 3.1 技术可行性：证据充分（2025–2026 最新）

**（1）"小模型集合 + 路由"已被顶会反复验证**

- **The Avengers（AAAI 2025）**：轻量框架聚合小模型集体智能，路由+评分+投票在数学/代码/逻辑任务超越专有大模型——本项目最直接的理论支撑（论文已在仓库：`2505.19797v3.pdf`）。
- **R2R（NeurIPS 2025）**：token 级路由，DeepSeek R1-1.5B + R1-32B 平均激活仅 5.6B 即超越 R1-14B，速度 2.8×。
- **Select-then-Route / StR（EMNLP 2025 Industry）**：先按语义类目选模型子池再级联路由——**与本项目"分类器 + 专家池"结构完全一致**，直接验证了当前架构。
- **Doing More with Less 综述（arXiv 2502.00409）**：query 级路由 64.3% vs 领域式 52.2%，支持"逐查询路由"而非"按领域分区"。

**（2）2026 年路由已从"方法"变成"独立服务类别"**

- 最新综述 [Dynamic Model Routing and Cascading（2603.04445）](https://huggingface.co/papers/2603.04445) 将路由研究归纳为六种范式（难度感知、级联、预算约束、多轮、多模态、token 级），本项目覆盖了其中四类（难度感知、级联、缓存、回退）。
- [LLM Routers Have Become a Service Category of Their Own](https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/)（2026）：Not Diamond、Martian、OpenRouter 等已将路由产品化；[vLLM Semantic Router](https://vllm-sr.ai/blog/vllm-sr-fusion-api/) 将语义路由内置进主流推理框架——说明**路由不是实验性玩具，而是生产级基础设施**。
- [OrcaRouter（2605.30736）](https://arxiv-org.ezproxy.obspm.fr/html/2605.30736v1)：生产导向的混合离线-在线学习路由器，验证了"规则 + 数据驱动 + 在线反馈"的渐进式升级路线（与本报告路线一致）。

**（3）必须正视的新风险（2026 年新增）**

- [When Routing Collapses（2602.03478）](https://huggingface.co/papers/2602.03478)：训练路由器时可能出现**退化收敛**——路由器坍缩到"总选同一个模型"，丧失区分度。影响：**本项目第一阶段用"可解释的规则/阈值路由"起步是正确选择**；当引入学习型路由器时（路线图阶段 4+），需监控路由选择熵，避免过早用数据训练路由器。
- [Mixture of Parrots（ICLR 2025）](https://arxiv.org/abs/2410.19034)：任意数量的小专家有表征容量天花板，**必须保留大模型回退层**——本项目回退设计是必要的，不是可选项。

### 3.2 经济可行性：成本降低 80–96% 有实测支撑

| 方案 | 平均激活参数 | 相对成本 | 来源 |
|------|-------------|---------|------|
| 单一稠密大模型（70B） | 70B | 1.0× | 基线 |
| MoE（激活 20B） | 20B | 0.29× | — |
| **本项目路由系统（80% 小模型 + 20% 升级）** | **~3B** | **0.04–0.15×** | 可行性分析 §6.1 |
| [RouteLLM 基准实测](https://klymentiev.com/blog/llm-router) | — | 0.15–0.70×（**成本降 30–85%**） | 2026 业界实测 |
| [RouterArena 排行（2026-07）](https://huggingface.co/blog/JerryPotter/who-routes-the-routers) | — | Hybrid Router $0.04/1K vs GPT-5 $10.02/1K | 榜单实测 |

按实现方案 §4.2 估算（日均 10 万请求）：全量大模型 ¥50,000–80,000/月 vs 路由系统 ¥5,000–12,000/月，**节省 80–90%**。量越大优势越明显。

### 3.3 理论边界（必须承认的"墙"）

| 边界 | 说明 | 本项目应对 |
|------|------|-----------|
| 复杂推理 | 数学证明、逻辑链、多步规划仍需大模型 | 级联升级：仅 10–20% 请求升级（已实现，升级率 20%） |
| 表征容量 | 专家宽度有下限（建议 ≥1B） | 配置已用 0.5B–7B 专家，符合下限 |
| 能力密度 3.5 月翻倍 | 模型会快速过时 | 模型注册表 + 定期替换（实现方案 §4.2） |

### 3.4 综合评级（更新 2026 视角）

| 维度 | 评级 | 说明 |
|------|------|------|
| 技术可行性 | ★★★★★ | 顶会 + 商业产品双验证 |
| 成本效益 | ★★★★★ | 30–85%（保守）~ 85–96%（乐观） |
| 部署复杂度 | ★★★☆☆ | 真实模型接入是主要工程量 |
| 推理天花板 | ★★★★☆ | 回退层兜底，可控 |
| 生态成熟度 | ★★★★☆ | vLLM/RouterArena/评测框架已就绪 |
| **综合** | **★★★★☆** | **强烈建议实施** |

---

## 四、核心问题：需不需要全新架构？

### 4.1 结论：不需要推倒重来，需要"分层演进"

**判断依据（为什么现有骨架是对的）：**

1. **结构与业界同构**：2026 综述（2603.04445）的六范式、StR 的两阶段结构、Not Diamond / OrcaRouter / vLLM-SR 的组件划分，与当前代码的 `Router → (Cache / Classifier / Experts / Judge / Fallback / Stats)` 完全对应。重写等于把已经验证正确的骨架再写一遍。
2. **接口抽象已为演进预留**：`BaseClassifier` / `Expert` / `BaseJudge` / `FallbackProvider` 四个抽象接口 + `build_*` 工厂 + `config.yaml` 驱动。替换任何一层实现都不需要改 Router 主流程（20 项测试保证回归安全）。
3. **成本不对称**：推倒重来 = 丢掉已验证的 20 项测试、评测基线（缓存 40%、升级率 20%、分类 100%）、以及 5 个领域的规则语料；而演进每步都可验证、可回滚。
4. **现有代码量小且整洁**：核心 `router_system/` 仅 ~50KB，无历史包袱、无耦合陷阱，不值得"重构"（重构解决的是"坏味道"，这里没有）。

**需要变化的两件事（注意这不是"新架构"，是"换零件"）：**

| 层 | 现在 | 演进为 | 方式 |
|----|------|--------|------|
| 分类器 | 规则关键词 | 训练的小模型分类器（BERT / Qwen3-0.6B） | 换 `build_classifier` 实现，接口不变 |
| 专家池 | Mock 模板 | 真实 LoRA 微调专家（vLLM 推理） | 换 `build_expert` 实现，接口不变 |
| Judge | 启发式 | LLM-as-Judge / 规则+模型混合 | 换 `build_judge` 实现，接口不变 |
| 缓存 L2 | n-gram 相似度 | embedding 向量检索（BGE / text-embedding） | 换 `RouterCache` 内部实现 |
| 回退层 | Mock | 本地 7B 量化模型（DeepSeek-R1-Distill-Qwen-7B Q4，按需加载） | 新加 `build_fallback` 本地后端；`type: api` 保留为可选（默认关闭） |
| 部署形态 | 单体进程 | 网关进程 + vLLM/llama.cpp 推理服务 + 向量库 | 新增部署层，不改核心代码 |

> **一句话：换的是"层内实现"和"部署拓扑"，不是"分层架构"本身。**

### 4.2 什么情况下才需要"全新架构"（触发条件）

出现以下任一**硬需求**时，单体演进方案不够用，需要系统形态升级（注意：即便如此，核心路由逻辑仍可复用，不是"从头写"）：

| # | 触发条件 | 具体信号 | 需要的架构形态 |
|---|---------|---------|---------------|
| 1 | 多租户 / 高并发生产服务 | 目标 QPS ≥ 100，需要 SLA、限流、租户隔离 | 无状态网关集群 + 独立推理服务 |
| 2 | 流式输出（SSE/WebSocket） | 用户要求"打字机"效果，长文档生成 | 网关 → 推理服务全链路流式透传 |
| 3 | 分布式多机推理 | 专家池超过单卡容量（>24GB），或需要并发多专家 | vLLM 推理集群 + 模型分发 |
| 4 | 模型热加载 / 热替换 | 灰度发布、模型更新不停服 | 推理服务与路由解耦 + 版本路由 |
| 5 | 多模态 / 长上下文 | 输入含图像/音频，或 128K+ 上下文 | 新增模态处理层、上下文工程 |
| 6 | 大规模语义缓存共享 | 多实例缓存一致性 | 外部向量数据库（Redis/FAISS/Qdrant） |

> 判断方法：**先问"是不是必须"，再问"现在能不能不做"**。当前阶段（内部工具 / 限定领域 / 单机）以上 6 条都不是硬需求，因此**不触发**全新架构。建议在阶段 5 复查此表。

---

## 五、如果要用全新架构：三种方案详解

> 本节回答"怎么用"。三套方案按"改动量从小到大"排列，都基于同一原则：**保留 Router 核心逻辑（它是对的），重构外围与部署形态**。推荐方案 A。

### 方案 A：演进式分层架构（推荐 —— 当前形态的自然升级）

**形态**：单体代码库 + 进程拆分（网关与推理分离），仍是一个应用，但推理交给独立服务。

```
┌─────────────┐     ┌─────────────────────────────┐
│  客户端/调用方 │────▶│  Router Gateway (FastAPI)   │
└─────────────┘     │  · 缓存(L1精确 + L2向量检索)   │
                    │  · 分类器(训练模型, 已替换规则) │
                    │  · 路由决策 + 预算感知          │
                    │  · Judge(规则+LLM混合)         │
                    │  · 升级/回退决策                │
                    └──────┬──────────┬──────────┬──┘
                           ▼          ▼          ▼
                    ┌──────────┐ ┌──────────┐ ┌──────────────┐
                    │ vLLM 服务 │ │ vLLM 服务 │ │ 本地 7B 兜底    │
                    │ 专家池    │ │ Judge模型 │ │ (Q4量化, 按需加载)│
                    │(多模型并发)│ │(1-3B)    │ └──────────────┘
                    └──────────┘ └──────────┘
```

**落地步骤（每步可独立上线）：**
1. 保持 `router_system/` 原样，新增 `serving/` 目录：`vllm_engine.py`（封装 OpenAI 兼容推理服务调用）。
2. `experts.py` 的 `APIExpert` 指向本地 `http://localhost:8001/v1`（vLLM 启动多个 LoRA 专家的 OpenAI 兼容端点），**一行配置切换**：`experts.code.type: api`。
3. 缓存 L2 升级：`RouterCache` 增加 embedding 后端抽象（`SemanticStore` 接口），默认 n-gram 实现保留，可选 `BGE` 向量实现（用 `sentence-transformers` 或调用本地 embedding 服务）。
4. 分类器替换：训练后输出模型文件，`build_classifier` 增加 `type: trained`，加载本地 ONNX/transformers 模型。
5. 网关增加流式透传（若需要）：`/chat/stream` 走 SSE。

**优点**：改动可控（每步 1–3 天）、逐步验证、可回滚；代码与测试资产全部保留。
**缺点**：仍是"一个仓库一个应用"，多实例共享缓存需要外部存储（阶段 5 处理）。

---

### 方案 B：事件驱动微服务（生产 SaaS / 多租户时采用）

**形态**：路由决策与模型推理完全解耦为独立服务，通过消息队列异步编排。

```
                      ┌────────────┐    ┌─────────────┐
  Client ──▶ API Gateway ──▶ Kafka/RabbitMQ ──▶ Router Worker (决策)
   (限流/鉴权)   │                      ▲           │
                 ▼                      │           ▼
            Redis Cache ◀───────────────┘      Expert Workers (vLLM池)
              (共享语义缓存)                     Judge Workers
                                                    │
                                                    ▼
                                               Fallback (外部API)
```

**关键设计决策：**
| 决策点 | 选择 | 理由 |
|--------|------|------|
| 通信 | 同步（短任务）/ 异步队列（长任务）混合 | 80% 查询 <2s 走同步；升级/复杂任务走异步 |
| 路由状态 | 无状态 Worker + Redis 缓存 | 水平扩展、故障恢复 |
| 模型 | 每个专家一个 vLLM 实例（或单实例多 LoRA） | LoRA 切换成本低，GPU 利用率高 |
| 观测 | OpenTelemetry 全链路 trace | 路由决策可审计（生产刚需） |
| 评测 | RouterArena 离线流水线 + 在线采样评估 | 防路由退化（见 3.1 风险 3） |

**优点**：水平扩展、租户隔离、故障域隔离、可审计。
**缺点**：工程量 4–8 周；引入 MQ/Redis 运维成本；对当前单机阶段是过度设计。

---

### 方案 C：拥抱推理框架生态（"不自己造轮子"路线）

**形态**：放弃自研路由决策的某些部分，用生态组件拼装：

| 组件 | 可选生态 | 说明 |
|------|---------|------|
| 推理 | vLLM / SGLang / llama.cpp / Ollama | 全支持 OpenAI 兼容 API |
| 语义路由 | [vLLM Semantic Router](https://vllm-sr.ai/blog/vllm-sr-fusion-api/) | 把路由内置到推理框架 |
| 路由器 | [RouteLLM](https://klymentiev.com/blog/llm-router)（开源） / Not Diamond（商业） | 数据驱动路由，含阈值校准 |
| 评测 | [RouterArena](https://github.com/RouteWorks/RouterArena) | 标准 5 维评测 |
| 缓存 | Redis + embedding（BGE / text-embedding-3） | 共享语义缓存 |

**适用场景**：团队规模小、不想维护推理细节；或希望直接使用成熟路由器的校准阈值。
**注意**：vLLM-SR / RouteLLM 主要做"模型选择路由"，不解决本项目"领域专家 + Judge + 回退"的业务编排——**生态组件应作为"层内实现"嵌入方案 A，而不是替代 A**。

---

### 三方案对比

| 维度 | A 演进式（推荐） | B 微服务 | C 生态拼装 |
|------|-----------------|---------|-----------|
| 触发条件 | 现在即可（无硬需求） | QPS≥100 / 多租户 / 流式 | 团队小 / 想用现成 |
| 改动量 | 每步 1–3 天 | 4–8 周 | 2–4 周 |
| 保留现有代码 | 全部 | 路由核心逻辑 | 大部分（接口适配） |
| 可扩展性 | 中（单机→双机） | 高 | 中高 |
| 运维复杂度 | 低 | 高 | 中 |
| 风险 | 低 | 中（分布式一致性问题） | 中（依赖第三方演进） |
| 与路线图关系 | 是路线图的实现方式 | 路线图阶段 5 的选项 | 可嵌入 A |

**结论：先走 A；若业务爆发（触发条件 1/2），在 A 基础上平滑升级到 B 的部署形态；C 的选择性组件（vLLM、RouterArena）始终可用。**

---

## 六、推荐落地实现路线（5 个阶段，14–20 周）

> 每阶段都有独立验收标准，可单独交付。里程碑用 ✅ 标注。

### 阶段 1：真实链路打通（第 1–2 周）—— 完全本地化起步

**目标**：修复工程问题、下载本地模型、把 mock 换成真实本地推理，验证全链路真实成本/延迟/质量。**本阶段起即完全本地，不需要任何 API key。**

| 任务 | 产出 | 验收 |
|------|------|------|
| 修复工程问题（见 §7） | eval.py 可在 GBK 控制台运行；test_cache.py 中文修复 | 全部测试通过 |
| 下载本地模型权重 | Qwen3-0.6B（分类）、BGE-small-zh（embedding）、Qwen2.5-Coder-7B / Qwen3-4B（专家）、DeepSeek-R1-Distill-Qwen-7B（回退，Q4 量化） | 离线可加载，无需联网 |
| 回退层接入本地 7B | `build_fallback` 新本地后端（llama.cpp / vLLM 量化加载） | 低置信查询走本地 7B 返回真实回答 |
| 专家池接入本地推理 | `experts.*.type: hf` 指向本地模型（或本地 OpenAI 兼容服务） | 5 领域各 2 条查询真实回答 |
| 建立成本/延迟基线 | `scripts/eval.py` 记录真实 cost_est 与延迟 | 输出报告：升级率 / 平均成本 / 延迟 |

**验收标准（对齐实现方案 5.1，完全本地口径）**：端到端延迟 < 大模型 1.5×；升级率 ≤20%；全链路离线运行，无任何外部 API 依赖。

### 阶段 2：本地小模型推理（第 3–6 周）—— 真正降本的主体

**目标**：本地 vLLM/llama.cpp 跑 0.6B–7B 开源模型池（专家 + 回退），全链路离线，无任何 API 依赖。

| 任务 | 产出 | 验收 |
|------|------|------|
| 安装推理栈 | `pip install -r requirements-ml.txt` + vLLM（或 llama.cpp 量化） | RTX 4060 8GB 可跑 Qwen3-0.6B / Qwen2.5-Coder-7B 量化 |
| 单实例多模型 | vLLM 启动多模型（`--served-model-name` 区分）或单实例多 LoRA | 5 领域专家并发可用 |
| 配置切换 | `experts.*.type: hf` / 本地服务 `base_url: http://127.0.0.1:8001/v1` | 全链路本地推理跑通 |
| 延迟/吞吐基线 | 压测脚本（10–50 并发） | P50 < 500ms，P99 < 2s（对齐实现方案 5.2） |
| 分类器试跑真实模型 | `HuggingFaceClassifier` 加载 Qwen3-0.6B 或 BERT | 与规则分类器准确率对比（≥90% 则保留，否则回退规则） |

**验收**：全链路离线可跑（拔网线也能工作）；分类准确率 ≥90%；延迟 P50 < 500ms。

### 阶段 3：训练分类器 + 升级 Judge（第 5–10 周，与阶段 2 并行）

**目标**：分类器从规则升级为训练模型（94–97% 目标），Judge 从启发式升级为"规则+LLM 混合"。

| 任务 | 产出 | 验收 |
|------|------|------|
| 构建训练数据 | 每领域 500–2000 条（人工标注 + 合成 + 公开数据集） | `data/train.jsonl` / `data/dev.jsonl` 格式齐备 |
| 训练分类器 | 跑通 `scripts/train_classifier.py`（BERT 或 Qwen3-0.6B LoRA） | 开发集准确率 ≥94%，推理 <50ms |
| 分类器 A/B | 规则 vs 训练模型同评测集对比 | 训练模型胜出才切换（否则保留规则，成本更低） |
| Judge 升级 | `RuleJudge` 保留快速过滤 + 增加本地 `LLMJudge`（本地 1–3B） | Judge 与人工评估一致性 ≥90%（实现方案 5.2） |
| 阈值校准 | 参考 Conformal Cascade 校准 `judge_fallback_threshold` | 升级率 ≤20% 且有分布无关保证 |

**验收**：分类准确率 ≥95%（正式目标）；升级率 ≤20%；缓存命中率 ≥30%（对齐实现方案 5.2）。

### 阶段 4：语义缓存升级 + 标准化评测（第 9–14 周）

**目标**：L2 缓存从 n-gram 升级为 embedding 检索；接入 RouterArena 标准评测。

| 任务 | 产出 | 验收 |
|------|------|------|
| embedding 语义缓存 | `SemanticStore` 抽象 + BGE 实现（`BAAI/bge-small-zh-v1.5`） | 同义改写查询命中率提升 ≥15%（vs n-gram） |
| 缓存评估 | 真实流量采样回放 | 缓存命中率 ≥30%（目标 40%+） |
| RouterArena 接入 | 按 RouterArena 格式生成预测文件并评测 | 获得 Arena Score 与成本对比基线 |
| 引入预算感知（可选进阶） | 参考 R2-Router：根据难度/置信度限制输出 token 预算 | 成本再降 20–30% 且质量 Δ≥0 |

**验收**：RouterArena 5 维指标全部可量化；成本/质量曲线优于"单一大模型"基线。

### 阶段 5：生产化（第 12–20 周，部分与阶段 4 并行）

**目标**：把系统从"能跑"变成"可运维、可监控、可替换"。

| 任务 | 产出 | 验收 |
|------|------|------|
| 监控 | Prometheus + Grafana：延迟/升级率/成本/路由分布/选择熵 | 面板上线，路由决策可审计 |
| 模型注册表 + 热替换 | 配置文件驱动模型版本；新模型评测通过后灰度切换 | 不停服替换专家（对齐实现方案 5.3） |
| 灰度/A-B | 网关按流量比例分流新旧路由器 | 可回滚 |
| 复查 §4.2 触发条件 | 若 QPS≥100/多租户 → 按方案 B 升级部署形态 | 架构决策记录 |

**验收**：整体成本降低 ≥80%（对比"全部请求走云端大模型"基线）；系统可灰度发布；模型可热替换。

### 时间线总览

```
第1-2周     第3-6周       第5-10周       第9-14周       第12-20周
┌────────┐  ┌────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│阶段1    │→ │阶段2    │→ │阶段3      │→ │阶段4      │→ │阶段5      │
│真实链路  │  │本地推理  │   │分类器+Judge│  │缓存+评测   │  │生产化     │
└────────┘  └────────┘   └──────────┘   └──────────┘   └──────────┘
  修问题      本地推理     训练/微调       embedding     监控/热替换
  接本地模型   压测          A/B切换        RouterArena    复查触发条件
```

---

## 七、已知工程问题修复清单（建议阶段 1 一并处理）

| # | 问题 | 位置 | 修复 |
|---|------|------|------|
| 1 | `eval.py` 打印 `✅` 在 GBK 控制台抛 `UnicodeEncodeError`（已实测复现） | `scripts/eval.py:76` | 脚本开头 `sys.stdout.reconfigure(encoding="utf-8")`，或 emoji 改 ASCII |
| 2 | `tests/test_cache.py` 中文被 `?` 替换（文件损坏，已确认字节级） | `tests/test_cache.py:16,17,20,27` | 重写为正确中文查询/注释 |
| 3 | `scripts/serve.py --stop` 用 `os.kill(SIGTERM)`，Windows detached 进程可能杀不掉 | `scripts/serve.py:45` | 改用 `taskkill /PID <pid> /T /F` |
| 4 | `conftest.py` 注释同样有 `?` 损坏 | `tests/conftest.py` | 同上修复 |

---

## 八、风险清单（2026 更新版）

| 风险 | 概率 | 影响 | 应对 | 阶段 |
|------|------|------|------|------|
| 路由误分类导致质量下降 | 中 | 高 | 置信度阈值 + 低置信走大模型（已实现）；阶段 3 训练分类器 | 1–3 |
| 小模型推理天花板 | 高 | 中 | 级联升级兜底（已实现）；Judge 阈值校准 | 持续 |
| **学习型路由器退化收敛（新）** | 低 | 高 | 规则/阈值起步；引入学习路由后监控选择熵（2602.03478） | 4–5 |
| 多模型管理复杂度 | 中 | 中 | vLLM 多 LoRA 统一管理 + 模型注册表 | 2,5 |
| 本地 GPU 资源不足 | 中 | 高 | 量化（4bit）+ 按需加载；回退降级为 4B 模型 | 2 |
| 领域数据不足微调效果差 | 中 | 中 | 合成数据 + few-shot 先验证；规则分类器作为保底 | 3 |
| 缓存击穿大模型负载飙升 | 低 | 高 | 限流 + 降级 + 预缓存热门查询 | 5 |
| 能力密度变化导致选型过时 | 低 | 低 | 接口抽象化（已具备），模型替换不动路由层 | 持续 |

---

## 九、参考文献与资源（2026 更新）

**项目内已有**：
- 《可行性分析报告_多专业小模型+路由模型路径.md》（15 篇论文）
- 《实现方案_多专业小模型+路由模型.md》（三阶段 681 行）
- `research/2026_papers_survey.md` + `references/` 13 篇 PDF

**2026 新增引用**：
- [Dynamic Model Routing and Cascading: A Survey（2603.04445）](https://huggingface.co/papers/2603.04445) —— 路由六范式综述
- [When Routing Collapses（2602.03478）](https://huggingface.co/papers/2602.03478) —— 路由器退化收敛风险
- [OrcaRouter: Production-Oriented LLM Router（2605.30736）](https://arxiv-org.ezproxy.obspm.fr/html/2605.30736v1) —— 生产路由器设计
- [RouteLLM 基准实测：成本降 30–85%](https://klymentiev.com/blog/llm-router)
- [LLM Routers 已成为独立服务类别（Techstrong）](https://techstrong.ai/articles/llm-routers-have-become-a-service-category-of-their-own/)
- [vLLM Semantic Router](https://vllm-sr.ai/blog/vllm-sr-fusion-api/)
- [RouterArena 代码仓库](https://github.com/RouteWorks/RouterArena) 与 [博客](https://huggingface.co/blog/JerryPotter/who-routes-the-routers)

---

*报告完成。核心结论：可行性 ★★★★☆，架构沿用（分层演进），推荐方案 A 路线，5 阶段 14–20 周落地。*