本地部署开源大模型：用Ollama搭建AI写作辅助系统实战指南

乔治·R·R·马丁因为《冰与火之歌》系列迟迟没有完结，每隔一段时间就会被读者推到热搜上。最近他又公开谈到了写作拖延带来的抑郁情绪，这其实不是一个娱乐话题，而是一个真实的创作压力问题。这篇文章不谈文学，只谈工程：内容创作卡住的时候，AI 辅助写作能不能真正帮上忙？

答案是能，而且不需要等云端平台开放接口。现在市面上的开源文本生成模型已经可以本地部署，普通 CPU 也能跑小模型，有 NVIDIA 显卡可以跑更大的模型，部署完之后还能提供 REST API，接进自己的写作工作流里做批量草稿、大纲生成和文字润色。下面我会沿着一条通用部署路线讲清楚：怎么选模型、怎么启动服务、怎么做功能验证、怎么用 API 跑批量任务，以及最容易踩到哪些坑。

如果你是一个写作者、自媒体运营者，或者负责公司内容产出，这篇文章可以帮你把“本地 AI 写作助手”从零跑起来。如果你只是想确认本地部署是不是值得折腾，前三章就能给你判断依据。

1. 核心能力速览

下面这张表以“本地部署开源文本生成模型 + Ollama 或 llama.cpp”为例，整理出最值得关注的能力项。实际项目里模型版本和启动方式会有差异，但整体框架是一致的。

核心思路是：把模型跑在本地，数据不出本机，调用逻辑非常简单。

2. 适用场景与使用边界

2.1 适合谁用

本地部署文本生成模型，不是要替代作者，而是把重复劳动减掉。

• 小说和剧本写作者：生成角色对话草稿、场景描写、情节走向的候选方案。
• 自媒体运营：批量生成标题选项、文章开头、金句和内容提纲。
• 产品和技术团队：把需求描述写成初版文档，或者把会议纪要整理成结构化的说明。
• 学生和研究者：辅助梳理文献综述的结构，生成摘要草稿。
• 工具链开发者：把模型封装成内部 API，接入文章管理后台或知识库系统。

从这个角度看，本地 AI 写作助手更适合作为“第一个草稿机器”而不是“最终作者”。

2.2 不适合什么场景

它不适合做事实核查，因为生成模型会一本正经地输出错误信息。也不适合完全替代人工创作，尤其是涉及个人观点、深度分析和核心品牌表达的内容。如果你需要输出高精度数据、法律条文、医疗建议，千万不要用通用对话模型直接生成。

2.3 使用边界和合规提醒

本地部署不等于可以随意使用数据。如果拿到的素材来源不明，尤其是人像照片、真实人物隐私、未授权书稿、商业机密，不要直接喂给模型。用 AI 辅助写作时，需要确认输入素材的版权，输出内容也要做人工复核。涉及真实人物、真实事件的创作，必须获得合法授权。

心理健康同样是边界问题。如果感受到持续的写作焦虑和情绪低落，建议尽快寻求专业心理帮助。AI 工具只能缓解工作流程上的压力，不能替代专业支持。

3. 环境准备与前置条件

在开始部署前，先确认你的机器满足基本条件。

可以先打开命令行确认基础信息：

# 查看操作系统 uname -a # 查看内存和磁盘 free -h df -h # 查看 NVIDIA 显卡驱动 nvidia-smi

如果没有 NVIDIA 显卡，也可以继续，选一个 1B 到 3B 的小模型，在 CPU 上跑通流程。

磁盘空间尤其重要，很多启动失败不是代码问题，而是模型文件没下载完整。模型文件放在哪里，也需要提前规划好，建议单独建一个models目录，不要把模型文件散落在各个项目里。

4. 安装部署与启动方式

4.1 方案一：Ollama 一键部署

Ollama 是目前把本地大模型部署成本压得最低的方案之一。它帮你处理了模型下载、backend 启动和 API 服务，用户只需要敲命令。

先安装 Ollama。Linux 和 macOS 可以用下面的命令：

curl -fsSL https://ollama.com/install.sh | sh

Windows 用户直接去官网下载安装包，安装完会在系统里注册一个命令行工具。

安装完成后，拉取一个通用文本生成模型。以 Qwen2.5 系列为例：

ollama pull qwen2.5:7b

如果你机器配置不高，可以选更小的版本：

ollama pull qwen2.5:3b

拉取完成后，直接运行：

ollama run qwen2.5:7b

进入交互模式后，你可以输入一句话，模型会继续生成内容。这个模式适合做快速测试。

启动后台服务模式：

ollama serve

默认服务地址是http://127.0.0.1:11434。服务启动后，模型会在收到第一个请求时加载到内存，因此第一次请求会比较慢，这是正常现象。

4.2 方案二：llama.cpp 编译运行

如果你更想控制底层参数，或者在 CPU 上追求更好的性能，可以用 llama.cpp。

git clone https://github.com/ggml-org/llama.cpp cd llama.cpp mkdir build && cd build cmake .. -DGGML_CUDA=ON cmake --build . --config Release

如果没有 NVIDIA 显卡，编译时把-DGGML_CUDA=ON去掉，走 CPU 版。

编译完成后，你需要准备 GGUF 格式的模型文件，然后把模型路径传给命令行：

./llama-cli -m /path/to/model.gguf -p "写一段关于程序员加班的故事" -n 256

这里的-n表示生成的最大 token 数，-p是输入提示词。由于模型文件名和路径需要按你实际下载的文件调整，这里给的是通用模板。

4.3 首次启动时的检查顺序

启动服务后，建议按下面顺序检查：

1. 服务进程是否在运行。
2. 默认端口是否被占用。
3. 模型文件是否下载完整。
4. 内存或显存是否足够。

端口占用很常见。如果 Ollama 默认的 11434 被占用，可以设置环境变量换端口：

export OLLAMA_HOST=127.0.0.1:11435 ollama serve

5. 功能测试与效果验证

服务跑起来之后，先用最简单的对话测试判断整体链路是否正常。

5.1 基础文本生成测试

用命令行直接测试：

ollama run qwen2.5:7b "写三句关于秋天的小学作文开头"

预期结果是模型输出三句不同写法。如果模型返回了完整句子，说明拉取模型和服务调用都正常。

如果用的是 API，则用curl测试：

curl http://127.0.0.1:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "写一个关于城市夜景的短段落", "stream": false }'

返回结果会是一个 JSON，其中包含response字段，这就是生成文本。

5.2 大纲生成测试

写作场景里最常用的功能是生成大纲。输入：

ollama run qwen2.5:7b "给我一个关于本地部署AI写作助手的文章大纲，要求三个一级章节和六个二级章节"

判断标准：模型是否输出了逻辑清楚、层级分明的标题结构。如果结构混乱，可以调整提示词，明确章节数量。

5.3 文本润色测试

把一段比较啰嗦的文字丢给模型：

ollama run qwen2.5:7b "润色下面这段文字：我们觉得这个工具很好用，因为它非常方便，而且速度很快，虽然有时候会卡，但总体是好的。"

判断标准：输出是否比原文更紧凑、有没有保留原意。如果模型只是把句子顺序换了一下，说明提示词还需要再具体一些，比如要求“控制在100字内”“语气正式”。

5.4 多轮对话测试

写作不只是单次生成，更多时候是不断追问和修改。Ollama 提供了api/chat接口支持多轮对话，但对于命令行交互模式，直接连续输入即可。

如果发现自己跑的是旧版本模型，背景理解能力弱，很可能是因为模型上下文窗口较短。可以通过设置num_ctx参数来调整上下文长度，比如：

ollama run qwen2.5:7b --num-ctx 8192

5.5 判断成功和失败的标准

成功标准很明确：生成内容没有乱码、没有中断、输出长度合理、结构清晰。

常见失败包括：输出非常短、反复重复同一句话、回答英文但提示词是中文、模型加载时直接退出。遇到这些情况，优先检查模型是否选对了，以及提示词是否足够清晰。

6. 接口 API 与批量任务

本地部署的价值不只是自己聊天，更重要的是把模型能力接进自己的脚本或工具。Ollama 默认提供 REST API，所以批量任务实现成本很低。

6.1 文本生成接口调用示例

使用 Python 调用api/generate：

import requests import json url = "http://127.0.0.1:11434/api/generate" payload = { "model": "qwen2.5:7b", "prompt": "写一个自媒体文章标题，主题是程序员如何避免职业倦怠", "stream": False } response = requests.post(url, json=payload, timeout=120) data = response.json() print(data["response"])

这个接口和 OpenAI 的聊天接口格式不完全一样，但很多开源工具会兼容 OpenAI 风格。Ollama 从某个版本开始也提供了/v1/chat/completions路径，你可以在本地把它当成一个简化版 OpenAI 服务来联调。

6.2 批量生成任务设计

批量任务的核心是：读取一批输入文件，循环调用接口，把结果写入输出目录，并记录每一条任务的日志。

import requests import json from pathlib import Path url = "http://127.0.0.1:11434/api/generate" input_dir = Path("./inputs") output_dir = Path("./outputs") output_dir.mkdir(exist_ok=True) for file in input_dir.glob("*.txt"): prompt = file.read_text(encoding="utf-8").strip() payload = { "model": "qwen2.5:7b", "prompt": prompt, "stream": False } try: resp = requests.post(url, json=payload, timeout=180) resp.raise_for_status() result = resp.json()["response"] output_file = output_dir / f"{file.stem}_result.txt" output_file.write_text(result, encoding="utf-8") print(f"OK: {file.name}") except Exception as e: print(f"ERROR: {file.name}: {e}")

批量任务建议加上失败重试逻辑。比如遇到超时或连接失败，等待 10 秒再重试一次。不要一次性并发太多请求，因为本地模型的显存和内存是共享的，并发过高会导致 OOM 或响应时间急剧拉长。

6.3 任务日志和中间结果

写批量任务时，最好把中间结果先写入临时文件，任务全部完成后再汇总。这样即使某个任务中断，已经生成的内容也不会丢失。

一个简单的目录结构建议：

writing-assistant/ ├── inputs/ │ ├── 01_topic.txt │ └── 02_outline.txt ├── outputs/ │ └── 01_topic_result.txt ├── logs/ │ └── batch.log └── script.py

7. 资源占用与性能观察

本地模型最容易忽视的问题是资源占用。不要只盯着生成结果，要观察显存、内存和磁盘占用。

7.1 查看模型资源占用

如果你使用 Ollama，可以开启另一个终端：

ollama ps

这个命令会显示当前加载了哪些模型、模型的参数大小、以及显存和内存占用。如果是自己用 llama.cpp 跑的服务，可以用nvidia-smi查看 GPU 显存占用。

nvidia-smi

重点看进程列表里是否有 llama 相关进程，以及显存占用是否接近显卡上限。如果接近上限，说明模型太大或者并发请求太多，需要缩小模型或减少并发。

7.2 影响性能的主要因素

• 模型参数量：7B 模型明显比 3B 模型占用更多显存，生成速度通常也更慢。
• 量化方式：GGUF 量化模型可以明显降低显存占用，代价是输出质量略有下降。
• 上下文长度：输入越长的历史对话，显存消耗越高。
• 批量并发：同一个服务同时处理多个请求时，资源占用线性上升。
• 生成 token 数：输出越长，生成耗时越长。

7.3 降低显存占用的方法

如果没有大显存显卡，建议优先选择 1B 到 3B 参数的量化模型。另外可以减少上下文窗口长度，把num_ctx从默认值降到 2048，或者限制单次生成的最大 token 数。

GGUF 模型文件通常会在文件名里标注q4_k_m或q5_k_m之类的量化等级。q4系列体积小适合低显存，q8系列质量更好但占用也更大。

7.4 如何避免端口冲突和进程残留

服务停止后，偶尔会有残留进程继续占用端口。用下面的命令检查：

lsof -i :11434

找到进程号后，确认没有正在运行的生成任务，再执行：

kill <PID>

如果是 Ollama 启动的服务，最干净的方式是从系统托盘退出 Ollama，或者执行：

ollama stop qwen2.5:7b

8. 常见问题与排查方法

这些问题是本地部署最常见的几类。绝大多数情况不是代码写错，而是模型版本、资源限制和提示词之间的匹配问题。

9. 最佳实践与使用建议

9.1 先小后大

第一次尝试时，不要直接追求 70B 级别的大模型。先跑一个 3B 或 7B 的小模型，把整个调用链路跑通，再决定是否换更大模型。

9.2 保留一套最小可运行配置

把拉取模型、启动服务、调用 API 这三步整理成一个脚本，保存到项目根目录。以后换机器或者重装环境，只需要跑一遍脚本就能恢复。

示例脚本：

#!/bin/bash ollama pull qwen2.5:3b ollama serve

9.3 输入、输出、日志分开管理

写作辅助工具不是一次性脚本，平时会反复使用。建议在项目里固定目录结构：

• inputs/：存放待处理的文本文件。
• outputs/：存放生成结果。
• logs/：存放批量任务的日志。
• prompts/：存放常用的提示词模板。

提示词模板非常重要。同一个模型，提示词写得好不好直接影响结果。比如把“润色这段话”改成“将下列文字改写成适合公众号发布的中文版本，语气简洁，不超过 300 字”，效果会明显不同。

9.4 增加人工复核环节

AI 生成内容不能直接发布。批量任务跑完后，至少需要一个人快速检查逻辑是否通顺、事实是否准确、是否包含敏感信息。如果生成内容涉及真实人物、品牌或者版权素材，一定要确认授权情况。

9.5 接口服务访问范围控制

如果 API 服务跑在云服务器上，不要默认监听 0.0.0.0。可以让服务只监听本机地址，或者通过防火墙限制访问 IP。轻量场景下，直接把服务跑在本地反而更安全。

10. 总结与下一步

乔治·R·R·马丁的事情让我意识到，内容创作的压力是真实存在的，而技术能提供的帮助不是“一键写完”，而是把重复劳动和启动成本降下来。本地部署 AI 写作辅助这件事，最大的门槛其实是迈出第一步：装好 Ollama，拉一个模型，跑通一次 API 调用。之后你会发现，批量出标题、生成大纲、润色章节，都只是循环脚本的问题。

这篇文章里，建议你先验证三件事：本地模型能不能正常生成文本、API 能不能被脚本调用、批量结果能不能稳定写入文件。最容易踩的坑是模型文件没下载完就启动服务，以及第一次请求时资源占用过高导致超时。只要你把这套流程跑通，后续可以继续扩展的方向很多：接一个前端网页、接入知识库做更精准的创作辅助、或者把多个模型封装成自己的写作工作台。

建议收藏备用，下次遇到创作瓶颈的时候，至少可以先用本地模型生一个草稿出来。