自己搭一个 AI 站点，用着用着一定会遇到一个问题：这个模型回答不好，换个试试。但如果代码里到处硬编码了某一个模型的调用方式，换模型就要改一遍全局。
这篇聊一下多模型接入的技术设计——怎么让应用和具体模型解耦。
一、先看清不同模型的技术差异在哪
选模型不只是看"回答得好不好"，几个工程维度决定了接入难度：
| 维度 | 影响什么 | 接入时要处理 |
|---|---|---|
| API 协议 | 请求结构、鉴权方式 | 不同厂商的字段名、参数格式不一致 |
| 上下文长度 | 能带多长的历史 | 超长历史需要截断或摘要 |
| 流式返回格式 | SSE 数据块结构 | 解析逻辑要按厂商适配 |
| 工具调用 | 能否调用外部函数 | 能力有无、格式差异大 |
| 部署方式 | 云端 API 还是本地权重 | 本地部署要管推理框架和显存 |
DeepSeek 是云端 API 为主，接口形态接近通用的 chat completions 风格，接入成本低，适合做默认模型。
Qwen 系列 同样有云端 API，同时开源权重可本地部署，上下文长度版本差异较大，接入时要注意不同版本的参数上限。
Llama 更多是在开源生态里，本地部署常见，需要自己处理推理框架（vLLM、Ollama 等）和量化配置，接入工作量比 API 大得多。
二、抽象层该怎么设计
核心思路：在应用层定义一个统一的模型接口，不同厂商的适配写在下面。
应用代码
↓ 调用统一接口 chat(messages, options)
ModelRouter（路由层）
↓ 按配置分发
┌────────────┬────────────┬────────────┐
DeepSeek Qwen Llama
适配器 适配器 适配器
路由层要做三件事：
1. 统一请求结构。 应用层只传标准化的 messages 数组和参数（temperature、max_tokens），适配器负责翻译成各厂商的字段格式。
2. 统一返回结构。 不管上游返回什么，适配器都要归一成同样的形状：文本内容、token 用量、结束原因。这样上层渲染逻辑只写一次。
3. 统一流式接口。 各家的流式返回数据块格式不同，适配器要把它们都转成统一的增量事件，前端不用关心是哪家模型。
三、配置化比代码分支更重要
一个常见的反模式是在代码里写 if-else 判断模型名。更好的做法是配置驱动：
{
"models": [
{
"name": "deepseek-chat",
"provider": "deepseek",
"endpoint": "https://api.example.com/v1/chat/completions",
"context_limit": 64000,
"supports_stream": true
},
{
"name": "qwen-max",
"provider": "qwen",
"endpoint": "https://api.example.com/v1/chat/completions",
"context_limit": 32000,
"supports_stream": true
}
]
}
新增一个模型只需要加一段配置和（如果协议不兼容）一个适配器，不用改业务逻辑。
四、上下文长度的处理策略
不同模型上下文窗口差异大，同一段历史对话，在长窗口模型上完整带上，在短窗口模型上会超限。
处理方式有三种，按场景选：
- 滑动窗口：只保留最近 N 轮对话，最老的消息丢掉。实现简单，但会丢失早期关键信息
- 摘要压缩：把早期对话让模型自己总结成一段摘要，替代原始消息。多一次模型调用
- 检索增强：历史对话向量化存起来，按当前问题召回相关片段。适合超长会话
实际产品里通常组合使用：近期对话保留原文，早期对话做摘要。
五、本地部署模型要注意的差异
如果选择本地部署 Llama 或 Qwen 的开源权重，接入方式和调云端 API 完全不同：
推理框架的选择。 vLLM 适合高并发、支持批量推理；Ollama 上手最简单，适合个人使用；llama.cpp 适合 CPU 环境和小模型。选定之后，对外暴露的接口形态也不一样（有的兼容 OpenAI 协议，有的自定义）。
显存与量化的权衡。 7B 模型全精度大约需要十几 GB 显存，4-bit 量化能压到几 GB，但会损失一点精度。参数量、量化方式、上下文长度三者共同决定显存需求，配实例前要先估算。
冷启动时间。 模型加载到显存需要几十秒到几分钟，服务启动慢。要么常驻进程，要么接受首请求等待。
六、可观测性不能缺
多模型接入后，很容易出现"感觉某个模型变慢了但说不清"的情况。建议在路由层统一埋点：
- 每次调用的模型名、耗时、输入输出 token 数
- 失败率与失败原因分类（超时、限流、鉴权、格式错误）
- 各模型的平均首字延迟（流式场景的关键指标）
这些数据放在一起看，才能判断该换模型还是该改代码。
七、写在最后
多模型接入的价值不是"能选好几个模型"，而是让模型变成可替换的组件。做了抽象层之后，换模型是改配置，做 A/B 对比是切流量，加新模型是写适配器——这些都不该动业务代码。
完整的部署方案可以看官方页面——查看 DeepSeek 个人站点快速部署与多模型体验方案。具体规格与权益以页面实际展示为准。
你做多模型接入时是怎么抽象的？有没有踩过协议不一致的坑？评论区聊聊。
