6个AI模型服务19个行业，这套路由方案实现99.7%可用性

当我们开始构建SCALA——这个面向服务业的AI操作系统时，犯了一个所有团队都会踩的经典坑：只选一个大语言模型，然后试图让它包揽所有任务。意大利语的客户支持？同一个模型。财务报告生成？也用它。WhatsApp消息路由？还是它。结果毫不意外：什么都能干，什么都干不精，最要命的是，烧代币的速度像不要钱似的。

经过18个月反复打磨，我们终于摸出一套多模型路由体系。现在，每次推理请求会根据任务类型、延迟要求和成本约束，被实时分派到6个不同模型上。这个架构跑通了19个行业，推理路径的可用性达到99.7%，却没在任何一家供应商那里购买企业级SLA。下面就是实际在用的决策树，每一层都是拿教训换来的。

路径的第一层是面向客户的对话机器人SARA，直接走Groq上的LLaMA 3.3 70B。原因很粗暴：p95延迟只有200毫秒。对于酒店客人在WhatsApp上等回复的场景来说，这就是生与死的差别。万一Groq那侧出问题，链路会自动坠落，先切到Cerebras，再不行就降级到Mistral。这样就算基础模型供应商单点挂掉，用户那边也感知不到延迟跳变。

长篇内容和分析任务走另一条路，直接上Claude Opus。这类请求不要死盯延迟——一份季度报告生成花30秒完全可接受，但事实准确度不能打折扣。Opus在长上下文推理和结构化输出上的表现，比单纯拼响应快要有价值得多。这也是为什么我们会把准确度放在速度前面：一次分析翻车带来的信任损失，十个快速回复都补不回来。

RAG知识库涉及的嵌入层，链路则完全自控。我们用mxbai-embed-large处理57,000多个文本块的向量化，维度拉到1024。这套模型跑在我们自己的服务器上，不用经过第三方的推理API。对于外部文档注入，改用Jina v3，因为它对上万份异构文件的边栏信息提取更稳定。两个嵌入模型各走各的管线，互不串扰。

代码生成和前端任务配的是Claude Sonnet。它的速度和生成质量配比刚刚好，尤其在输出React组件或复杂SQL时不容易把结构写崩。视觉理解、文档解析这些就走多模态模型，具体用哪个会根据文档语言、表格密度以及是否包含手写内容实时判断。至于大批量内容——比如翻译、社交媒体帖子——就直接挑当前成本最低的提供商，然后加一道质量阈值过滤，结果不合格就自动重跑或塞入人工审核队列。

为什么要把模型分得这么细？因为SCALA服务的行业跨度太大了：酒店、房地产、美业、汽车、医疗，外加另外14个垂直领域。每种业务对AI的忍耐度完全不同。酒店前台聊天消息如果超过3秒还没响应，客人就开始在房间里摔手机了；而一份医疗初诊问卷，允许30秒运算，但准确度得99%以上，因为漏掉一个药物过敏史就可能是事故。意大利餐厅用WhatsApp接待客人，德国物业经理用邮件发季度结算，巴西美容院每天批量生成促销文案——它们全部跑在同一套平台上。一个每月付97欧元的夫妻美甲店，显然不可能按照企业级推理成本去铺算力。所以路由不仅要算延迟和准确性，还得实时把成本考虑进去。

架构里最核心的韧性设计，是坠落链模式。每条推理路径都不只配一个API密钥，而是塞进2到3个备选供应商。实际的异步函数长这样：针对一个给定的提示词和路由配置，按顺序尝试每个提供商；每次尝试都带上超时和最大Token数限制；如果返回结果的质量分数低于阈值，或者干脆抛了异常，就自动转下一个。计数器递增一次“fallback_triggered”指标，并且把提供商的名字打上标签，方便后续做告警和账单复盘。如果整条链条都跑不通，最后还有一个静态的兜底回复，比如“我们正在处理您的请求，请稍后”。就是这套看起来特别简单粗暴的for循环，帮我们把所有推理路径的宕机时间压到了几乎为零——比那个静态兜底值本身还要可靠。

但那些真正让人半夜惊醒的故障，往往不是大模型宕机，而是向量维度这种看起来人畜无害的细节。嵌入维度不匹配，会悄无声息地把整个RAG系统搞残。举个例子：如果你用某个模型给57,000多个知识块生成了1024维的索引，然后某一天换了一个新模型，生成的查询向量是768维，系统并不会抛出一个大红色的报错框。它只会默默地在高维空间里找不到匹配，然后吐出完全没有依据的回答。这类故障最难查——响应时间是正常的，输出格式也是正常的，只是内容开始胡说八道。我们在几个月前就吃过这个亏，所以现在所有嵌入维度变更都必须走强制校验，而且索引和查询端用的模型版本号、维度数全量记录在元数据里。

回看整个路由体系，它本质上不是要炫技，而是被现实逼出来的。五六年前大家还在喊一个通用模型解决一切，现在到了生产环境里，面对19种完全不同的业务逻辑、19套不同的容忍边界和19个级别的付费意愿，靠单一模型死扛已经不是“不够优雅”的问题，而是直接造成客户流失。把请求分拆到6个模型上，听上去运维变复杂了，但事实上供应商锁定被彻底打散，成本也更容易做精细化管。每个月支付€97的客户不会被企业级推理的账单挤走；需要四秒内给出医疗建议的场景，也不会因为共享同一个低延迟模型而把酒店消息队列堵死。

架构里的“冷血”部分也很直白：不做模型邪教。不迷信任何一个提供商，同一类任务永远有坠落选项，质量阈值随时在调。视觉模型今天用这个，明天性能倒退就切那个。批量内容哪怕省0.1个基点，经过每天上百万次调用后也是真金白银。这样的设计让团队在供应商突然涨价、突然降质、突然下线某个API版本时，都不至于手忙脚乱。

至于那些57,000多个知识块，它们还在继续涨。每接入一个新的行业，索引就需要重新对齐一次。我们在这个过程中学到的最大教训是：除非被逼到绝路，否则不要轻易改动嵌入维度。所有对准确率、召回率和延迟的优化，最后都会拐回来叩问那一个字段：它到底是多少维。一旦改动了，就得做好心理准备——不是系统崩了，而是你知道它已经坏了，但用户和监控面板还没开始叫。