本地大模型装好之后，先别接业务：把验收跑扎实

“已经能回答了”常被当成本地模型安装完成的信号。可一旦换成真实问题，团队才发现模型首轮加载要等很久、长对话会变慢、结构化结果不稳定，或者知识问答答得流畅却没有依据。能启动只是起点。安装和验收分开做，能减少把运行正常误当成业务可用的情况。

先让环境可复现

下载模型前先记录运行设备、操作系统、推理框架版本、模型仓库与具体版本、量化文件名和许可证信息。别只记一个模型家族名称：同名系列里的尺寸、指令版本和量化变体可能不同。正式测试应固定这些条件，否则今天和下周的结果不一定能解释差异从何而来。模型文件也要从可信来源获取，并按团队流程核对来源、完整性和使用许可。

以 Ollama 为例，官方文档提供 `ollama pull <模型名称>` 下载模型、`ollama run <模型名称>` 启动交互的本地流程；Linux 环境下服务未自动运行时还可使用 `ollama serve`。如果团队选择 llama.cpp、MLX 或 vLLM，则应依照对应框架和硬件的官方安装说明准备环境。安装命令会随操作系统和版本变化，部署记录里最好保留实际使用的命令与日志，而不是复制一份过期的教程。

第一次运行时，至少确认进程是否正常加载目标模型、实际监听地址和端口是否符合预期、接口能否返回结果。Ollama 的本地聊天接口示例使用 `http://localhost:11434/api/chat`，而 vLLM 提供 OpenAI 兼容的服务端接口；接口形式相似并不意味着参数、流式输出、结构化生成或工具调用的支持完全一样。应用测试前，先把所选版本支持的接口能力核对清楚。

用真实任务检查回答有没有用

测试集应从准备上线的任务里来。比如知识助手要回答制度、产品或操作问题，就准备几条资料中有明确答案的请求，再加入没有答案、资料冲突、表述含糊和越权请求。检查的不只是句子是否通顺，还包括事实是否能从允许使用的资料中找到依据；无法确认时能不能坦白不确定；需要补充信息时会不会追问。对关键输出，最好让业务负责人给出可以接受的结果边界。

如果应用需要输出 JSON、选择类别或调用工具，就把这些任务单独测。检查字段是否完整、取值是否符合业务枚举、异常输入时是否拒绝或请求补充。API 返回一个格式正确的工具调用，只证明结构可解析，不能证明模型选对了工具、参数适用于当前用户，或业务系统允许执行。最终授权与数据校验仍应由应用和业务服务执行。

测试问题要用同一组样本同时比较候选模型和配置。记下提示词、采样参数、上下文长度和资料版本，按任务类型复核错误：哪些是模型知识不足，哪些是检索没找到依据，哪些是格式或流程问题。把失败样本和修订结果保留下来，下一次改模型、量化方式或运行时后重跑，就能知道变化到底改善了什么，还是只让某个演示问题变得更好看。

测性能时分开看首次和持续运行

首次加载耗时与模型已经驻留内存后的回答耗时，是两种不同体验。对交互场景，应同时记录首字响应、完整任务耗时与输出速度；对多人使用的服务，还要看并发上升后延迟和失败率如何变化。长上下文任务与短问题也应分开，因为上下文缓存会改变内存占用和响应表现。用业务承诺来设定可接受区间，不要拿另一台机器上的公开跑分直接当作验收门槛。

此外，观察显存或统一内存是否逼近上限、模型是否意外退回 CPU、请求结束后模型是否按预期驻留或卸载。压力测试要从低并发逐步加量，同时准备停止条件，避免测试程序挤占共享机器上的其他工作。若目标机器在热机后表现稳定，但冷启动远超业务可忍受时间，可能需要调整常驻策略或重新评估模型和硬件。

把隐私和可恢复性也纳入验收

本地推理不代表所有数据都留在本机。还要检查应用是否把请求发到云端、运行工具是否启用遥测、日志保留了哪些原文、模型更新从哪里下载、故障排查人员能看到什么。测试样本优先使用脱敏或合成数据；确需使用真实数据时，按企业已批准的测试环境和权限进行。服务器监听地址也要核对，局部测试一般不需要把推理端口直接暴露给公网。

最终验收记录应能让另一位工程师按相同版本和配置重跑，并知道失败时如何停止服务、清理缓存或切回旧版。模型、提示词、知识库和推理框架任一变化都可能影响结果，因此每次变更要有基本的回归范围。准备进入业务集成时，可继续阅读[企业应用如何接入本地模型](/resources/solutions/local-llm-enterprise-application-integration)，先从只读、低风险的流程开始。

宜天信达在企业 Agent 项目中，可与业务、IT 和安全团队一起确定本地模型验收样本及上线条件，让安装成功、任务可用和系统可运营成为三个分别可核对的结论。

官方资料

Ollama 快速开始；Ollama Chat API；vLLM 在线服务与 API 说明。