MODEL_ROUTING_ARCHITECTURE_DIFF.md - 路由计划 vs 现实对照 — ppt

幻灯片 1：路由计划与现实对照：结论摘要

• 现行系统未实现单一入口，而是维持 Backend 与 Web 分离的“双栈路由”架构 [1]。
• 基础路由规则已被抽取并统一至共享内核 model-router-core 中 [1]。
• 计划中作为兜底的 Zenmux 在后端路由链中未出现，在 Web 端也仅有部分模型族使用 [1]。
• Web 端引入了旧文档未覆盖的“任务路由（Task Router）”与“服务级 fallback” [1]。

幻灯片 2：核心路由架构对比

• 计划架构：原计划采用单一的 SmartRouter 作为全局统一入口 [1]。
• 现实架构：实际代码分为 Backend（src/llm/*）和 Web（apps/web/lib/llm/*）两套平行的体系 [1]。
• 架构影响：这种双栈架构导致同名模型在不同调用路径下的 fallback 机制不一致 [1]。
• 内核状态：尽管链路分离，但基础的 family、transform 和 env 规则已经通过 model-router-core.ts 实现了统一 [1]。

幻灯片 3：服务提供商（Provider）调用差异

• Zenmux 使用现状：旧文档计划其承担多数模型的 fallback，但现实是“配置中有≠实际会走”，Backend 完全未接入 Zenmux [1]。
• SiliconFlow 的引入：作为聚合和加速分支被引入系统，支持 DeepSeek、GLM、Kimi 等国内模型 [1]。
• 加速生效范围：国内加速目前存在非对称性，SiliconFlow 仅在 Web 路由侧生效，Backend 未引入 [1]。

幻灯片 4：关键大模型的 Fallback 链路实况

• Gemini 链路：Backend 与 Web 保持一致，均严格按照 Google → Poe → OpenRouter 顺序回退 [1]。
• GPT 链路：Web 链路按预期包含 Zenmux（Poe → OpenRouter → Zenmux → OpenAI），但 Backend 直接跳过了 Zenmux [1, 2]。
• DeepSeek 链路：由于 Web 端特有加速，其回退链路包含了 SiliconFlow，而后端则直接通过 Poe 和 OpenRouter 调用 DeepSeek [2, 3]。

幻灯片 5：Web 端特有的高级路由机制

• 任务路由的引入：Web 端独有 task-model-router 和 SmartChat，实际调用动态依赖于 TaskType 的选择 [2, 3]。
• 服务级回退（Fallback）：Web 端不再完全依赖底层的统一路由回退，而是存在多个 API 显式通过 try/catch 实现的服务级 fallback [2]。
• 质量档位执行：原定的 Premium/Balanced/Fast 三档质量未被统一执行，Web 采用场景配置，而 Backend 仅依赖环境变量默认值 [2]。

幻灯片 6：PPT 图像生成链路的高度收敛

• 链路精简：相比起复杂的多模型 fallback 链，PPT 文生图链路变得更短、更具确定性 [2]。
• Google 专用模型：在 PPT 图像场景下，Google 节点仅使用特定的 gemini-3-pro-image-preview 模型 [1, 3]。
• Poe 专用模型：在同场景下，Poe 节点收敛为仅调用 nano-banana-pro [1, 3]。

幻灯片 7：代码证据索引与核对清单

• 后端逻辑溯源：核心链路可在 src/llm/model-router.ts 和 model-router-core.ts 中查证 [3]。
• Web 端逻辑溯源：任务路由及服务级代码分布在 apps/web/lib/llm/ 及具体的 AI API 路由中 [3, 4]。
• PPT 场景溯源：图像生成的专有链路逻辑可在 apps/web/lib/services/image-generation.ts 和生成 PPT 相关 API 中获取具体证据 [3]。

MODEL_ROUTING_ARCHITECTURE_DIFF.md - 路由计划 vs 现实对照 — summary

SEO 友好博客摘要

本文深入对比了大模型路由架构的计划与现实实现 [1]。通过梳理代码发现，系统依然维持 Backend 与 Web 的双栈路由模式，并成功抽离了基础共享内核 [1]。文章详细剖析了 Zenmux、SiliconFlow 等平台在双端的 fallback 链路差异 [1, 2]，并揭示了 Web 端引入的任务路由机制及 PPT 文生图链路的精简收敛策略 [1, 3]。这为开发者优化 API 调用、排查模型容灾逻辑提供了真实的代码级对照指南。

核心看点

1. 双栈路由与共享内核并存：维持 Backend 与 Web 分离的双栈路由，基础规则抽离至共享内核 [1]。
2. 两端 Fallback 链路差异显著：Backend 链中未出现 Zenmux，而 Web 端引入 SiliconFlow 加速分支 [1, 2]。
3. 新增任务路由与链路收敛：Web 端引入任务路由，且 PPT 绘图链路收敛至单一确定模型 [1, 3]。

MODEL_ROUTING_ARCHITECTURE_DIFF.md - 路由计划 vs 现实对照 — video

这是一段为您定制的60秒短视频脚本，严格按照字数和结构要求编写：

【钩子开场】（12字）
路由计划与实际代码一样吗？[1]

【核心解说】

1. 架构现状（29字）：系统暂未统一，仍是后端与Web双栈路由，但基础规则已共享。[1]
2. 链路差异（30字）：模型链路差异大，后端缺Zenmux，国内加速仅Web侧生效。[1, 2]
3. 功能收敛（28字）：PPT图片链路收敛，仅保留谷歌与Poe特定模型，路径更短。[1-3]

【一句收束】
规划很理想，现实需打磨，系统架构的彻底统一仍在路上！