Mistral 3 系列多模型路由Spring Boot 后端按请求复杂度动态选型的踩坑实录项目背景我们团队在 2026 年 6 月对核心 NLP 服务做了模型升级从原先单一接入 Mistral 7B 切换到了 Mistral 3 系列。业务场景是电商平台的商品问答与智能客服日均调用量约 12 万次。技术栈为 Spring Boot 3.2.5 JDK 17.0.12 OkHttp 4.12.0。团队 6 人其中 2 人负责 AI 服务层。升级的初衷很直接Mistral 3 系列提供了多个尺寸的模型理论上简单请求用轻量模型、复杂请求用大模型能显著降低 API 调用成本。但实际落地后第一个月我们踩了一个很大的坑——成本不降反升。选型决策接入前我们对 Mistral 3 系列的可用模型做了调研。| 模型 | 参数量 | 适用场景 | 单次调用成本相对值 | 中文表现 ||------|--------|----------|----------------------|----------|| Mistral Small 3 | 24B | 文本分类、信息抽取、简单问答 | 1x | 良好 || Mistral Medium 3 | 约 60B | 中等推理、代码理解、多轮对话 | 3x | 优秀 || Mistral Large 3 | 未公开 | 复杂推理、长文本分析、多步任务 | 8x | 顶级 || Mistral 7B旧 | 7B | 基础 NLP | 0.5x | 一般 |最初方案很简单按输入文本字符长度做路由——少于 100 字符走 Small 3100-500 走 Medium 3超过 500 走 Large 3。这个方案虽然官方推荐文档里也提到了类似思路但在我们场景下反而更糟。上线两周后我们发现客服对话中有大量「短输入高复杂度」的查询比如「这个商品和上一个有什么区别」——只有十几个字但需要模型理解上下文并做对比推理。用 Small 3 处理这类请求回答准确率从 94% 掉到了 71%。实现过程问题定位我们从日志里拉了 5 天的调用数据做分析。核心发现60% 的请求是简单的商品属性查询「多少钱」「有没有货」用 Small 3 完全够用25% 是中等复杂度对比、推荐、解释需要 Medium 315% 是复杂推理多步分析、代码相关、长文本总结必须用 Large 3但按字符长度路由时这 25% 的中等请求里有近一半被错误地路由到了 Small 3导致回答质量下降用户投诉率上升了 3 个百分点。真正的根因是输入长度和任务复杂度之间没有强相关性。一个 10 字的「为什么这个不能用」和一个 200 字的「请帮我列出这个商品的所有参数」前者反而需要更强的推理能力。解决方案两阶段路由我们改用了两阶段路由策略第一阶段所有请求先经过一个轻量级的分类器用 Small 3 本身做判断任务复杂度等级。第二阶段根据分类结果路由到对应尺寸的模型。核心实现如下javaServicepublic class MistralRouterService {Autowiredprivate MistralClient mistralClient;Value(${mistral.models.small:open-mistral-small-3})private String smallModel;Value(${mistral.models.medium:open-mistral-medium-3})private String mediumModel;Value(${mistral.models.large:open-mistral-large-3})private String largeModel;public MistralResponse routeRequest(UserQuery query) {// 第一阶段用 Small 3 做复杂度分类ComplexityLevel level classifyComplexity(query);// 第二阶段根据分类结果选择模型String targetModel resolveModel(level);return mistralClient.chat(query.getPrompt(), targetModel, buildConfig(level));}private ComplexityLevel classifyComplexity(UserQuery query) {String classifyPrompt String.format(判断以下用户查询的复杂度等级只返回 SIMPLE、MEDIUM 或 COMPLEX\n\n%s,query.getContent());try {MistralResponse response mistralClient.chat(classifyPrompt, smallModel, ClassificationConfig.builder().temperature(0.1).maxTokens(10).build());String result response.getContent().trim().toUpperCase();return ComplexityLevel.valueOf(result);} catch (Exception e) {// 分类失败时降级为 MEDIUM避免影响主流程log.warn(Complexity classification failed, fallback to MEDIUM, e);return ComplexityLevel.MEDIUM;}}private String resolveModel(ComplexityLevel level) {return switch (level) {case SIMPLE - smallModel;case MEDIUM - mediumModel;case COMPLEX - largeModel;};}}分类器的 System Prompt 我们也专门调过最初让模型输出 JSON 格式但发现约 2% 的请求会返回带 markdown 代码块的 JSON导致解析失败。后来改成只要求输出一个纯文本标签反而更稳定。路由层还加了一个兜底机制如果目标模型调用超时或返回错误自动降级到下一档模型重试一次。yamlmistral:routing:classification-timeout-ms: 3000fallback-enabled: truemax-fallback-levels: 1circuit-breaker:failure-threshold: 5recovery-timeout-seconds: 30这里有个值得注意的点熔断器的阈值我们设了 5 次失败才触发而不是常见的 3 次。原因是分类阶段本身就可能因为网络波动偶尔失败阈值设太低会导致不必要的熔断反而增加 Large 3 的调用量。效果数据两阶段路由上线后运行 3 周的数据对比API 调用总成本下降 58%从日均约 2400 元降到 1008 元用户满意度评分从 4.2 回升到 4.55 分制P99 响应时间从 4.8s 降到 3.1s因为大量简单请求走 Small 3推理更快分类器额外引入的延迟约 200-400ms但整体 P99 仍然改善因为省去了 Large 3 的排队等待从模型调用分布看路由后的实际比例是 Small 3 占 62%、Medium 3 占 28%、Large 3 占 10%和我们的预期基本吻合。感悟如果重来一次会在两个地方做得更好。第一分类器不应该和主请求串行执行。理想方案是异步预分类——用户消息到达时立即启动分类同时准备 Small 3 的默认响应。分类结果回来后如果判定为 COMPLEX 才切换到 Large 3否则直接用 Small 3 的结果。这样可以把分类开销完全隐藏掉。第二分类的准确率需要持续监控。我们上线后发现分类器对「否定句」的识别偏弱比如「这个商品有什么不好」容易被判为 SIMPLE但实际用户期望的是分析缺点属于 MEDIUM 甚至 COMPLEX。后来我们在分类 prompt 里加了一条针对否定句的显式规则准确率才回到可接受水平。大模型路由不是做一次就完事的它需要和业务数据持续对齐。#后端 #Java #SpringBoot #Mistral #大模型路由你在实际项目中有遇到类似问题吗欢迎在评论区分享你的经验和解决方案。