本地部署 AI 会议记录助手 NAS：教程、排障和 FAQ

AI 会议记录助手最适合本地部署的场景，是团队有大量会议录音、访谈音频、课程录屏或客户沟通记录，又不希望所有音频都上传到第三方云服务。NAS 刚好适合做这件事：它长期在线、有硬盘空间、可以跑 Docker，也方便把录音文件集中存放。

这篇按“教程 + 排障 + FAQ”整理，目标是帮你在 NAS 上搭一个本地 AI 会议记录流程：音频上传到 NAS，服务转成文字，再用本地或私有 LLM 生成摘要、行动项和待办清单。

先确认你要部署哪一类助手

本地 AI 会议记录大致有三种路线：

NAS 上建议先从“转写 + 摘要”开始。完整平台功能更全，但部署复杂度、数据库、权限、备份和升级成本也更高。

NAS 部署前的硬件判断

先看 NAS 能不能扛住转写和摘要。

最低建议：

• 4GB 内存可以做轻量测试。
• 8GB 内存更适合长期运行。
• x86 NAS 比 ARM NAS 兼容性更好。
• 有核显或 GPU 会更快，但不是必须。
• 硬盘空间要预留音频、转写文本和模型缓存。

如果你的 NAS 性能较弱，可以采用“NAS 存储 + 另一台电脑推理”的方式。NAS 负责保存录音和结果，转写服务跑在迷你主机、台式机或 GPU 机器上。

推荐架构

一个实用的本地架构可以这样设计：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

会议录音
  ↓
NAS 共享目录
  ↓
Docker 服务
  ↓
Whisper / faster-whisper 转写
  ↓
Ollama / OpenAI 兼容 LLM 摘要
  ↓
Markdown / TXT / SRT / 网页结果

这个结构的好处是组件清楚。转写失败就查 STT，摘要失败就查 LLM，文件找不到就查挂载目录。

准备目录

先在 NAS 上准备几个目录：

1
2
3
4
5
6

/volume1/docker/meeting-ai/
├── config/
├── input/
├── output/
├── models/
└── logs/

用途：

• input：放待处理音频。
• output：放逐字稿、字幕、摘要。
• models：放 Whisper 或其他模型缓存。
• config：放配置文件。
• logs：放运行日志。

目录先规划好，后面排障会简单很多。

Docker Compose 示例

不同会议助手项目的镜像和参数不一样，但思路类似。下面是一个通用结构示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

services:
  meeting-ai:
    image: your-meeting-assistant-image:latest
    container_name: meeting-ai
    restart: unless-stopped
    ports:
      - "7860:7860"
    volumes:
      - /volume1/docker/meeting-ai/input:/app/input
      - /volume1/docker/meeting-ai/output:/app/output
      - /volume1/docker/meeting-ai/models:/app/models
      - /volume1/docker/meeting-ai/config:/app/config
    environment:
      - TZ=Asia/Shanghai
      - WHISPER_MODEL=small
      - LLM_BASE_URL=http://ollama:11434
      - LLM_MODEL=qwen2.5:7b

如果你的 NAS 使用群晖 Container Manager、飞牛 Docker、TrueNAS Apps 或 Portainer，核心也是一样：镜像、端口、目录挂载、环境变量。

Ollama 要不要也部署在 NAS 上

如果 NAS 性能足够，可以把 Ollama 也部署在 NAS 上；如果性能弱，建议把 Ollama 放到更强的机器。

NAS 本机部署的优点：

• 数据都在内网。
• 配置简单。
• 长期在线。

缺点：

• 大模型推理慢。
• 内存容易吃紧。
• 转写和摘要同时跑会卡。

更稳的方案是：

1
2

NAS：存储、Web UI、任务队列
迷你主机或台式机：Ollama / GPU 推理

然后在配置里把 LLM_BASE_URL 指向那台机器的内网地址。

音频格式怎么处理

会议录音常见格式有 mp3、m4a、wav、mp4。为了减少问题，建议统一转成 wav 或标准 mp3。

可以用 ffmpeg 预处理：

1

ffmpeg -i meeting.m4a -ar 16000 -ac 1 meeting.wav

含义：

• -ar 16000：采样率转 16k。
• -ac 1：转单声道。
• meeting.wav：输出给转写模型使用。

如果原文件是视频，也可以只提取音频：

1

ffmpeg -i meeting.mp4 -vn -ar 16000 -ac 1 meeting.wav

转写模型怎么选

常见选择是 Whisper 或 faster-whisper。模型越大，准确率通常越好，但速度和内存占用也更高。

中文会议建议从 small 开始。如果转写质量不够，再尝试 medium。不要一上来用最大模型，否则排障时很难判断是模型慢、CPU 慢还是服务卡住。

摘要提示词建议

转写完成后，可以让 LLM 生成结构化纪要。提示词可以固定成模板：

1
2
3
4
5
6
7
8

请根据下面的会议逐字稿生成中文会议纪要。

要求：
1. 提炼会议主题。
2. 用要点列出关键讨论。
3. 单独列出行动项，包括负责人、事项、截止时间；如果没有明确负责人或时间，写“未明确”。
4. 保留重要数字、项目名和风险。
5. 不要编造逐字稿里没有的信息。

对本地模型来说，逐字稿太长时要分段摘要，再汇总。不要一次把几个小时的会议完整塞进去。

常见报错：容器启动失败

典型表现：

1
2
3

container exited
permission denied
exec format error

常见原因：

• 镜像架构不支持你的 NAS CPU。
• 挂载目录权限不足。
• 环境变量缺失。
• 端口被占用。
• 配置文件路径写错。

排查顺序：

1. 看容器日志。
2. 确认镜像支持 amd64 或 arm64。
3. 检查目录权限。
4. 换一个未占用端口。
5. 先用最小配置启动，再逐步加模型和 LLM。

exec format error 很可能是镜像架构不匹配。

常见报错：上传音频后没有反应

可能原因：

• 上传目录没有挂载到容器内部。
• 服务只扫描特定后缀。
• 文件还没写完就被任务扫描。
• 文件名包含特殊字符。
• 后台任务队列卡住。

建议先用简单文件名测试：

1

meeting-test.mp3

不要一开始就用包含空格、中文括号、特殊符号的长文件名。跑通后再测试真实文件。

常见报错：转写很慢

NAS 上转写慢很常见，不一定是部署错了。

优化方法：

• 换小一点的 Whisper 模型。
• 先把音频转成 16k 单声道。
• 把长会议切成多个片段。
• 避免转写和 LLM 摘要同时占满 CPU。
• 把转写任务放到更强机器，NAS 只做存储。

如果一小时会议要转几十分钟，在低功耗 NAS 上并不奇怪。关键是要能稳定跑完。

常见报错：转写乱码或语言识别错

可能原因：

• 自动语言检测失败。
• 音频噪声太大。
• 采样率或声道异常。
• 模型太小。
• 中英混合场景太复杂。

处理方法：

• 显式指定语言为中文。
• 先用 ffmpeg 统一音频格式。
• 换 small 或 medium 模型。
• 对多人会议尽量提高录音质量。
• 对重要会议保留原始音频，方便复查。

常见报错：Ollama 连接失败

典型表现：

1
2
3

connection refused
failed to connect to Ollama
model not found

排查：

• Ollama 是否正在运行。
• LLM_BASE_URL 是否写对。
• 容器里访问的 localhost 是否指向自己，而不是 NAS 或主机。
• 模型是否已经 ollama pull。
• NAS 防火墙是否允许内网访问。

如果会议助手在容器里，http://localhost:11434 通常指容器自己。Ollama 在宿主机或另一台机器时，要写对应内网 IP。

常见报错：摘要质量差

摘要质量差通常不是部署问题，而是输入和模型的问题。

常见原因：

• 逐字稿错字太多。
• 会议太长，一次输入超出上下文。
• 本地模型太小。
• 提示词没有约束输出格式。
• 行动项在原文里没有明确说清楚。

改进方法：

• 先按 10 到 20 分钟分段摘要。
• 最后再做总摘要。
• 要求模型标注“不确定”。
• 对行动项使用固定字段。
• 对重要会议人工复核。

本地模型可以节省成本，但不要期待它自动补全会议里没有说过的信息。

常见问题：NAS 内存不够

如果 NAS 内存小，建议：

• 转写模型选 base 或 small。
• 不在 NAS 上跑大 LLM。
• 限制并发任务为 1。
• 关闭不必要的容器。
• 把模型缓存放到空间充足的卷。

如果经常 OOM，说明这台 NAS 更适合做存储，不适合做主要推理机器。

隐私和权限要注意什么

会议录音通常包含敏感信息，本地部署也不能忽视权限。

建议：

• 给 input/output 目录设置访问权限。
• 不要把 Web UI 直接暴露到公网。
• 外网访问走 VPN 或反向代理鉴权。
• 定期清理临时音频和中间文件。
• 重要会议结果保留人工复核流程。
• 如果接入云端 LLM，要明确哪些文本会上传。

“部署在 NAS 上”不自动等于安全，权限和网络边界仍然要自己管。

推荐落地流程

第一次部署可以按这个顺序来：

1. 在 NAS 上建好 input、output、models、config 目录。
2. 用 Docker 跑起会议助手服务。
3. 上传一个 1 分钟测试音频。
4. 用 tiny 或 base 模型确认转写链路。
5. 换成 small 模型测试中文准确率。
6. 接入 Ollama 或 OpenAI 兼容 LLM 做摘要。
7. 配置定期清理和权限控制。
8. 再处理真实会议录音。

不要一开始就拿两个小时会议录音测试。先用短音频验证链路，省时间，也方便排障。

FAQ

NAS 上能完全本地离线转写吗？

可以，但前提是转写模型、摘要模型和所有依赖都在本地。如果摘要调用云端 LLM，就不是完全离线。建议在配置里明确区分 STT 和 LLM 的来源。

群晖、飞牛、TrueNAS 都能部署吗？

只要能运行 Docker 或类似容器服务，理论上都可以。差别主要在路径、权限、端口映射和 CPU 架构。

ARM NAS 适合跑吗？

可以跑轻量转写，但镜像兼容和性能要提前确认。很多 AI 镜像默认优先支持 amd64，ARM 设备容易遇到架构不匹配。

会议记录助手一定要 GPU 吗？

不一定。CPU 也能转写，只是慢。短音频和低频使用可以接受；大量会议或长视频建议用 GPU 机器。

输出应该保存成什么格式？

建议至少保存 txt 或 md 逐字稿、srt 字幕和 md 摘要。Markdown 最适合后续搜索、归档和人工编辑。

能不能自动识别不同说话人？

这取决于你用的工具是否支持 speaker diarization。它比普通转写更复杂，也更耗资源。重要会议建议把“说话人识别”当成增强功能，不要作为第一版必需功能。

可以直接把会议录音文件夹做自动监控吗？

可以，但要注意文件写入完成再处理。否则录音还没上传完，任务就开始转写，容易失败。可以用临时目录加完成后移动的方式。

本地模型摘要可以直接当正式纪要吗？

不建议。AI 摘要适合作为初稿，尤其是行动项和责任人需要人工复核。对客户会议、法务会议和重要决策会议更要谨慎。

小结

在 NAS 上本地部署 AI 会议记录助手，关键不是一次装上最复杂的平台，而是先跑通稳定链路：音频进入 NAS、容器能读取、转写能完成、摘要能生成、结果能归档。性能不足时，不要强行让 NAS 承担所有推理，可以让它负责存储和任务管理，把转写或 LLM 放到更强的内网机器。

第一版建议从短音频、轻量模型、单任务并发开始。等目录、权限、转写和摘要都稳定后，再加入自动监控、团队权限、搜索和长期归档。