本地大模型离线助手教程：用 Ollama / LM Studio 搭私有 AI 工作台

适用人群

适合三类用户：第一，处理敏感资料，不希望上传到云端；第二，经常调用模型，想降低 API 成本；第三，开发者想测试开源模型、构建本地应用。如果你追求最强推理、最稳定工具调用和最少折腾，云端模型仍然更省心。

硬件怎么选

本地模型最吃显存和内存。普通笔记本也能跑 7B 或 8B 量化模型，但速度和上下文长度有限。大致可以这样判断：16GB 内存适合跑轻量模型和短文本；32GB 内存更舒服，可以处理多数个人文档；有 12GB 以上显存的独显会显著提升速度。苹果芯片机器因为统一内存，对本地模型体验相对友好。

不要盲目追大参数。一个适合中文和你任务的小模型，往往比一个跑得很慢的大模型更有用。

第一步：安装 Ollama 或 LM Studio

Ollama 更适合开发者，命令行安装模型、启动服务、接 API 都很方便。LM Studio 更适合普通用户，有图形界面，可以搜索模型、下载、聊天，也能开启本地 API。新手可以先用 LM Studio 感受模型效果，之后再用 Ollama 接入自己的脚本或应用。

安装后先选一个通用模型，例如 Qwen、Llama、Mistral 系列的 7B / 8B / 14B 量化版本。下载时注意量化格式，通常 Q4 速度快、占用低，Q8 质量更好但更吃资源。

Ollama 命令行实操

ollama pull qwen2.5:7b
ollama run qwen2.5:7b

本地 API 测试：

curl http://localhost:11434/api/chat \
  -d '{
    "model": "qwen2.5:7b",
    "messages": [
      {"role": "user", "content": "用三句话解释 RAG 是什么"}
    ],
    "stream": false
  }'

如果你要接自己的网页应用，可以把 localhost:11434 当成本地模型服务。界面验收图要包含三张：Ollama 终端运行界面、LM Studio 模型下载页、本地 WebUI 文档问答页。

第二步：测试基础能力

不要一上来就导入几百篇文档。先用 10 个真实问题测试：中文写作、长文摘要、代码解释、表格提取、逻辑推理、翻译、本地知识问答。记录回答质量、速度、是否容易胡说。不同模型差异很大，尤其是中文、代码和长上下文能力。

如果回答太慢，换更小模型或更低量化。如果回答经常跑题，换指令微调更好的模型。如果中文很差，不要指望提示词完全补救，直接换中文能力更强的模型。

第三步：加入本地文档问答

本地助手最实用的能力是读你的文档。可以选择 AnythingLLM、Open WebUI、Dify 本地版、LlamaIndex 脚本等方案。流程和 RAG 类似：导入文档、切分、向量化、检索、让本地模型基于片段回答。

文档不要混放。个人笔记、合同、代码文档、发票资料应分不同知识库。不同知识库可以设置不同模型和提示词，例如合同问答更强调引用和“不确定就说不知道”，写作知识库更强调风格模仿。

第四步：隐私与安全

本地不等于绝对安全。你仍然要注意：下载模型来源是否可信，本地 Web UI 是否暴露到公网，插件是否会把内容发到第三方服务，浏览器扩展是否读取敏感页面。建议默认只监听本机地址，不要把本地模型 API 暴露给局域网，除非你清楚访问控制。

对于公司资料，还要看内部合规要求。有些公司禁止把资料放进任何未经批准的软件，即便软件跑在本地。

性能优化建议

本地模型慢，通常不是单一原因。先看模型大小和量化，再看上下文长度，最后看前端工具是否开启了过多插件。日常写作和摘要可以用 7B / 8B 模型，复杂代码和长文档再切到更大模型。上下文不是越长越好，塞进无关内容会让模型更慢，也更容易跑题。

如果你用的是笔记本，建议准备两套配置：轻量模式用于日常问答，质量模式用于重要任务。轻量模式用小模型、低上下文、快速响应；质量模式用更大模型、更高量化、更长上下文。这样比一直追求最高质量更符合真实使用。

团队共享怎么做

小团队可以把本地模型部署在一台内网机器上，通过 Open WebUI 或内部网页访问。但这时它已经不再是“个人本地工具”，需要考虑账号、权限、日志和备份。不同团队的知识库要隔离，不能因为模型服务在内网就默认所有人都能访问所有资料。

共享服务还要设置使用预期。它适合写草稿、查内部资料、做初步摘要，不适合替代正式审批和专业判断。管理员可以准备几个推荐入口：普通聊天、文档问答、代码解释、会议摘要，每个入口用不同提示词和模型参数，减少用户自己乱调配置的成本。

常见坑

| 现象 | 可能原因 | 修法 | |------|----------|------| | 回复慢到不可用 | 模型太大或上下文太长 | 换 7B / 8B Q4，先把上下文降到 4K | | 中文回答生硬 | 模型中文能力弱 | 换 Qwen、Yi、GLM 等中文更强的模型 | | 文档问答乱引用 | 检索片段太长或太杂 | 按标题切分，chunk 控制在 300-800 中文字 | | 电脑风扇狂转 | CPU 跑大模型 | 使用 GPU / Metal 加速，或换更小量化 | | 本地 API 被滥用 | 没有绑定本机或鉴权 | 只监听 127.0.0.1，不要暴露到公网 |

检查本地服务监听地址：

lsof -i :11434

如果看到服务监听在 0.0.0.0，说明局域网其他机器可能访问到它；个人使用应改回只监听本机。

替代方案

如果你只是偶尔处理敏感文本，可以用云端模型的企业版或不训练承诺方案。如果你需要团队知识库，可以选择私有化部署的 Dify、AnythingLLM、MaxKB、FastGPT。如果你追求最强编程和推理，云端 Claude、OpenAI、Gemini 仍然是主力，本地模型更适合做草稿和离线辅助。

小结

本地大模型离线助手的正确定位是“私有、低成本、可控的日常助手”。先从小模型和少量文档开始，确认速度和质量，再逐步扩展知识库和工具。不要为了本地而本地，能解决隐私、成本或离线问题，才值得投入维护。