本地大模型上线后怎么维护？模型换版、灰度与回滚

本地大模型上线后，第一次升级往往比第一次安装更容易被低估。新权重可能改变回答习惯，量化方式可能影响细节，推理框架更新也可能改变并发和显存表现。若团队只记录“模型名字”，却没有记下实际文件、启动参数和运行环境，出了问题就很难确认是模型变化、配置变化还是机器状态导致的。

把能影响结果的版本记录在一起

一条可恢复的部署记录，至少包括模型权重版本或校验值、量化格式、tokenizer、推理服务和依赖版本、驱动与硬件信息、启动参数、上下文长度、提示词和工具配置。若使用外部下载的模型文件，还要保留来源与许可信息。版本清单的目标不是追求表格完整，而是让另一位工程师能复现当前服务，并知道新旧环境具体改了哪里。

模型、运行时、提示词和知识库最好分别管理变更。一次同时更新所有组件，即使结果变差，也很难定位原因。升级前先说明变更目的和预期影响，例如减少显存占用、修复某种格式兼容或改善特定任务；若没有可观察的目标，升级本身就难以评价。

用固定样本比较新旧表现

回归集应来自已经上线的真实任务，经企业规则脱敏后覆盖常见问题、边界输入、无答案情形、权限拒绝和工具失败。比较时不只看语言是否流畅，还要看任务字段、事实依据、拒绝与转交行为、工具调用和格式是否符合要求。关键样本逐条检查；对可量化的结果，再按业务场景分组看变化，避免总体平均掩盖某类任务明显退化。

性能也要在接近实际的环境观察。记录首次加载时间、常驻后的响应耗时、并发下的失败率、资源占用和任务完成情况。冷启动、长上下文和峰值请求分别测试，因为它们表现出的瓶颈不同。测试应有停止条件，尤其共享机器不能为了压测而影响生产任务。此前的本地模型安装与测试验收可以作为建立回归样本的起点。

灰度期间要能看见问题并迅速停下

较稳妥的发布方式是让新旧服务短时间并行，先在隔离环境回归，再让内部测试用户使用，之后才考虑让一小部分低风险请求进入新版本。灰度比例、观察时长和扩大条件由企业结合业务确定；观察项包括任务成功、人工接管、工具错误、耗时、资源和用户反馈。新旧两组请求的任务类型要尽量相近，否则结果差异可能来自样本而非版本。

发布路由要能明确指向旧服务，并避免同一请求在切换时重复执行。对只读问答，切回旧模型相对直接；对已经写入业务系统的流程，回滚模型不会撤销业务写入，需同时确认执行状态和业务补偿办法。配置、模型文件和提示词都应保留上一版的可用副本；回退流程应在真实演练中走过，而不是只写在文档里。

按现象判断从哪一层排查

若答案依据突然变化，先看模型、提示词和检索版本；若大量请求超时或内存告警，检查模型大小、并发、上下文和运行参数；若工具调用失败，核对接口状态与参数契约；若服务启动失败，检查依赖、驱动和模型文件。一次任务的检索、工具、权限与耗时记录有助于缩小范围，可参考Agent 运行轨迹的排障方法。日志应保留必要证据并按企业规则脱敏。

Ollama 和 vLLM 都持续维护各自的服务配置文档，但升级前应以部署所用的具体版本为准，先在复制环境里验证兼容性，再安排生产切换。可查阅Ollama API 文档与vLLM 在线服务文档。发布记录、回归结果和回滚演练一起构成本地模型的运维闭环；只完成模型下载，并不等于生产运维已经就绪。