1. 项目背景

业务场景

某公司的AI平台已经服务了三个部门：客服部用qwen2.5:7b做问答（日均5000次），研发部用qwen2.5:7b做代码审查（日均200次），运维部用qwen2.5:7b做日志分析（日均100次）。一切看似正常，但CTO看完成本报告后皱起了眉头。

客服部的小王抱怨："为什么我问’退货政策’要等3秒？这问题很简单啊！"研发部的小李也抱怨：“我问’为什么这个SQL走全表扫描’，AI给的答案不够专业。”——这两种任务性质完全不同：客服问答是3秒的快问快答，SQL分析是30秒的专业推理。但系统让他们用同一个7B模型，两头不讨好——简单任务没必要用7B（浪费GPU），复杂任务用7B不够强。

运维老李算了一笔账：如果简单问答用1.5B模型（1秒响应），复杂分析用14B模型（10秒响应），整体GPU利用率能提升40%，用户满意度也能提升。

痛点

1. 一把钥匙开所有锁：所有任务用同一个模型，简单任务浪费算力，复杂任务能力不足。
2. 模型切换全靠人工：用户需要手动选择模型，90%的人永远用默认的。
3. 无故障降级：7B模型挂了，整个AI平台瘫痪——没有备选模型自动顶上。
4. 无灰度对比：想验证14B是否比7B好，需要人工做AB测试，效率极低。

一句话总结：