7.4 多模型支持与私有化部署
7.4.1 支持多种大模型：GPT、Claude、DeepSeek、通义千问
Spring AI 的价值不是要求所有模型都暴露同一种协议，而是用 ChatModel 抽象屏蔽 Provider 差异，再由 ChatClient 提供统一调用方式。OpenAI、Anthropic、Ollama 等实现可以各自使用对应的 ChatModel；业务层仍通过 prompt()、call()、stream() 和 Tool Calling 处理对话。
IoT DC3 当前实现与这个抽象一致。dc3_model_provider 保存 Provider 类型、base_url、api_key、默认标记、启用状态和租户信息，Provider 类型目前包括 OPENAI_COMPATIBLE 与 ANTHROPIC；具体模型及其能力配置由 dc3_model_config 关联到 Provider，ChatClientFactory 按 7.2.1 节所述方式构建并缓存对应客户端，此处不再重复。
因此，切换模型的准确描述是：先配置 Provider 与 Model，再由请求选择模型或回退到默认模型。只要上层继续使用 ChatClient，Tool 实现通常无需随 Provider 改写；但不同 Provider 的认证、请求选项、Tool Calling 能力和返回行为仍需单独验证，不能把适配器说成“只改配置且完全无差异”。当前项目也没有按任务复杂度或敏感度自动路由模型的策略引擎，这类路由需要后续显式实现。
| 模型或接入方式 | 当前接入路径 | 适合场景 | 需验证 |
|---|---|---|---|
| GPT、DeepSeek、Qwen 等 OpenAI-compatible 服务 | OPENAI_COMPATIBLE → OpenAiChatModel | 通用对话、中文运维、工具调用 | 端点兼容性、模型能力、成本与数据合规 |
| Claude | ANTHROPIC → AnthropicChatModel | 长上下文、日志与报告分析 | Tool Calling、参数差异与区域合规 |
| Ollama、vLLM 等本地推理端点 | 按实际兼容协议配置对应 Provider | 数据不出域、私有化验证 | 模型格式、吞吐、显存、上下文长度与函数调用稳定性 |
模型选型不应依赖宣传参数。更可靠的做法是用同一批设备查询、历史值分析和 Tool Calling 用例，对候选模型测量延迟、成功率、参数正确率、成本和资源占用，再决定默认模型。多模型配置提供的是可替换能力，不等于已经实现自动路由。
7.4.2 私有化部署方案：安全与隐私考量
某位工程师在配置文件中只改了端点地址就完成了模型切换——这个操作背后隐含了一个重要的前提：本地必须有一个运行中的模型服务。私有化部署不是简单的“下载一个模型文件”，它涉及模型获取、推理引擎选型（Inference Engine）、硬件适配和运维管理四个维度。物联网场景中走私有化路线的驱动力，通常来自两条清晰的需求：数据主权和延迟可控。
谁在要求私有化
一家工厂的运维负责人说得直白：“设备位号数据就是我的工艺参数，出了厂区我睡不着觉。”在工业、能源和医疗领域，设备配置参数、运行曲线、故障模式是企业的核心资产。公有云大模型服务虽然承诺传输层加密，但模型推理发生在云上——每次请求的文本都会发送到模型提供商的数据中心。对于内部网络不与外网直连的生产环境，这条路根本走不通。
另一个驱动力是推理延迟。云端的模型调用包含网络传输时间。操作员说“关闭三号反应釜的进料阀”，如果模型需要先走外网再到云端推理，再返回指令，多出的数百毫秒在网络抖动时可能变成数秒。本地部署可以把推理延迟稳定控制在百毫秒以内，不受运营商网络状况影响。
主流方案：Ollama、vLLM 与 LocalAI
当前本地部署大模型的工具链已比较成熟。三个方案在物联网场景中最常用，各有侧重。
Ollama 的封装程度最高，一条 ollama pull qwen2.5:7b 命令就能拉起服务。它的模型库丰富，主流大小的模型都有现成镜像。适合快速验证、单实例、低并发的场景——比如一个工厂只需要同时服务几个运维操作员。
vLLM 需要用户手动从 HuggingFace 拉取模型并指定路径，封装程度中等。它的优势是生产级的高吞吐和多实例高可用。当你要同时服务几十个操作员，或者把推理能力开放给外部 Agent 调用时，vLLM 的连续批处理（Continuous Batching）和 PagedAttention 机制能把 GPU 的利用率压榨到极限。
LocalAI 提供与 OpenAI API 完全兼容的接口，在容器化部署上更灵活。它对模型格式的宽容度更高——同一个部署可以同时加载不同厂商的模型。适合需要在同一台机器上运行多个异构模型的场景。
三个方案都提供 OpenAI 兼容端点，这正是 Spring AI 依赖的协议标准。对 Agentic Center 来说，换推理引擎只需改 base-url，与切换云端模型没有架构差异。配置示例：
# application.properties（示意）
spring.ai.ollama.base-url=http://localhost:11434
spring.ai.ollama.chat.model=deepseek-r1:7b
# 替换为 vLLM 或 LocalAI 时，改这一行即可：
# spring.ai.openai.base-url=http://localhost:8000/v1硬件是现实约束
GPU 资源是大多数团队面对的门槛。不同参数规模的模型对显存需求差异明显。以典型7B参数规模的模型为例，在消费级GPU上可以正常运行，但实际能跑多快、能支持多长的上下文序列，取决于量化精度和序列长度。更大参数规模的模型（例如达到百亿参数级别），对显存和内存的要求会显著提高。当模型参数量超过单卡容量时，需要多卡并行或 CPU Offloading——把部分层放到 CPU 内存中，牺牲推理速度换取可用性。Ollama 和 vLLM 都支持这种技术。在 IoT 数据查询场景中，一次推理 3～5 秒的延迟通常可以接受，远好于完全无法部署。
混合模式：分层决策，不二选一
不是所有请求都需要私有化。更稳妥的混合路由先按数据分级、工具权限、成本和已测任务质量做决策：敏感数据或低风险查询可走经过验收的本地模型，允许出域且需要更强能力的任务才进入获批的云模型。具体模型名称和能力会变化，本书不把某个品牌与“简单”或“复杂”永久绑定。Agentic Center 的 dc3_model_provider 表支持配置多个提供商并可按会话选择模型；若要自动路由，还需另行实现策略、降级、审计与评测闭环，而不只是补一个 if：
// 代码：按请求特征选择模型后端
public ChatClient selectModel(ChatRequest request) {
if (request.containsSensitiveTags()) {
return ollamaChatClient; // 敏感数据，走本地
}
if (request.isSimpleQuery()) {
return ollamaChatClient; // 低延迟优先
}
return openAiChatClient; // 复杂任务，走云端
}这套做法把一个看似二选一的问题，变成了可分层调控的决策。
工程检查清单：开始私有化部署前
- 确认模型参数规模和所需显存估算，核对服务器 GPU 配置（参考模型发布页的推荐要求）。
- 选择推理引擎：Ollama 适合快速验证，vLLM 适合生产高吞吐，LocalAI 适合异构模型共存。
- 拉取模型镜像并验证 OpenAI 兼容端点可用。
- 修改 Agentic Center 配置文件的
base-url指向本地推理服务。 - 验证工具调用链是否完整：发一条“查询所有离线设备”的测试消息。
- （可选）部署混合路由逻辑，按查询类型和敏感度分级分流。
私有化不是全有或全无的选择。用对方法，可以在数据主权、响应速度和模型能力之间找到自己的平衡点。
7.4.3 MLOps 与 LLMOps：从版本登记到生产回归
把模型部署成一个 HTTP 服务，只解决了“能够调用”的问题。生产系统还必须回答：当前请求用了哪个模型、哪版 Prompt、哪份知识索引、哪些 Tool、什么权限策略；升级后效果是否退化；出问题时能否只回退一个组件。传统 MLOps 主要治理数据、特征、训练代码、模型和部署，LLMOps 则把 Prompt、上下文、RAG 索引、Tool schema、评测集和安全策略一起纳入发布单元。
AI 应用不是一个模型，而是一组有依赖关系的资产
建议为每次发布生成不可变 manifest，至少记录：
- 模型 Provider、模型 ID 和服务版本；
- 系统 Prompt、业务模板及其哈希；
- Tool 名称、描述、输入 schema、风险等级和后端 API 版本；
- RAG 语料快照、切分器、Embedding、reranker、索引和过滤策略；
- 安全策略、租户范围、审批规则和输出过滤版本；
- 离线评测集、攻击集和通过阈值；
- 发布人、审批人、时间、变更原因和回退目标。
只有模型版本而没有 Tool schema 版本，可能让新模型按旧参数调用新接口；只有索引版本而没有语料快照，无法解释知识回归；只保存 Prompt 文本而不记录策略，无法复现为什么同一请求在两个租户下得到不同工具目录。
MLOps 与 LLMOps 的边界
| 维度 | MLOps 重点 | LLMOps 新增重点 |
|---|---|---|
| 数据 | 训练/验证数据、特征、标签 | Prompt、会话、RAG 语料、工具返回、人工反馈 |
| 资产 | 模型、训练代码、特征流水线 | 模型、Prompt、索引、Tool schema、策略、评测集 |
| 评测 | 精度、召回、漂移、服务指标 | 忠实性、拒答、轨迹、越权、成本、非确定性波动 |
| 发布 | 模型注册、灰度、回滚 | 组件独立版本、只读先行、自主度分级、策略回退 |
| 监控 | 数据/概念漂移、预测质量 | 无证据回答、工具失败、注入、人工拒绝、上下文污染 |
两者不是替代关系。预测性维护模型仍需要数据切分、模型注册和漂移监控；调用它的 Agent 还要治理 Prompt、Tool 和审批策略。
发布门：先证明没有破坏，再逐步放权
一个稳妥的发布流程可分为五道门：
- 离线回归：在版本化 golden set、不可回答集和安全攻击集上运行；
- 影子流量：新版本读取真实请求但不产生外部副作用，与旧版本比较；
- 灰度租户：只对限定租户、设备和用户开放；
- 只读先行：先开放查询 Tool，再开放需要确认的写操作；
- 扩大范围：指标稳定且事故预案演练通过后，才增加设备和场景。
任何阶段都不应让模型自己决定是否通过发布门。评测执行、策略判断和审批必须位于模型之外。
在线 traces：从结果追到版本和副作用
每个请求应生成可关联的 trace，记录模型和 Prompt 版本、检索文档及版本、Tool 目录、工具参数摘要、权限决策、Action 确认、后端回执、最终回答、token、时延和成本。敏感参数可脱敏或存哈希，但不能完全失去关联性。
监控至少包含：请求成功率与 P95 时延、token 和单任务成本、RAG 无证据回答率、Tool 成功/超时/重试率、人工拒绝率、Action 过期率、跨租户拦截和安全测试命中。业务结果延迟出现时，还应将设备告警、工单和最终状态回连到原 trace。
漂移不只发生在模型
- 数据漂移：设备分布、季节或工况变化；
- 概念漂移：同一特征与故障之间的关系变化；
- 知识漂移：手册、固件和 SOP 更新；
- 接口漂移：Tool schema 或后端 API 变化；
- 策略漂移：权限、审批和风险阈值变化；
- 行为漂移：Provider 在模型 ID 不变时更新服务实现。
因此持续评测不能只在模型升级时触发。语料、Tool、策略和关键依赖发生变化时，都应运行对应回归集。
回退必须按组件设计
全量回退往往过慢。工程上应分别准备模型、Prompt、检索配置、Tool schema 和策略回退，并支持将系统从受约束 Agent 降级为 Copilot、只读问答或确定性规则。回退后仍要保持 trace 可读，避免旧模型配到新 Tool。
资产登记
→ 离线评测
→ 影子流量
→ 灰度租户/只读工具
→ 在线 traces 与持续评测
→ 扩大范围或按组件回退发布记录的价值不在于增加流程，而在于把“感觉新版本更好”变成可审计判断：哪个组件变化、哪些指标改善、哪些风险增加、谁批准，以及如何恢复到最后一个已知安全组合。