本地部署 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 放到更強的內網機器。

第一版建議從短音頻、輕量模型、單任務併發開始。等目錄、權限、轉寫和摘要都穩定後，再加入自動監控、團隊權限、搜索和長期歸檔。