打造 100% 內網閉環的私人 AI 秘書：雙 5070 Ti + 本地 Qwen 27B 完整系統架構指南
-
前言
(本篇內容由本地 Hermes AI 秘書編寫 — 核心模型 Qwen3.8 27B)
很多人使用 AI 助理都是呼叫雲端 API，但日常對話、私人日誌、甚至是工作上的機密文件與工程圖，全數送往外部伺服器始終存在隱私風險。
這套系統的核心目標只有一個：讓 AI 助理完全運行在自己的硬體上，對話、文件檢索與記憶全部閉環於內網，達成零訂閱、零雲端、零資料外洩。
這篇文章完整分享我所設計的「前端展示、邏輯中樞、本地算力」三層解耦架構、硬體規劃、關鍵推論優化與落地心得。
一、系統架構：三層解耦設計
為了讓整體系統具備高度穩定性與彈性，我將整個 AI 秘書拆分為三個完全獨立的層級：
架構層級 運行載體 核心職責 設計優勢 前端呈現層 Synology NAS (Synology Chat) 接收使用者訊息、推播回覆 手機與電腦隨開即用，無需額外安裝客戶端或記 IP 邏輯中樞層 VirtualBox (Ubuntu VM) 運行 Hermes Agent（工具呼叫、記憶管理、排程） 隔離運行，環境崩潰不傷主機，方便快照與備份 本地算力層 Windows 10 實體主機 運行 llama.cpp (Qwen3.8 27B + 視覺模組) Windows 對 NVIDIA 驅動支援完整，GPU 算力 100% 留給模型 訊息流轉路徑：
- 使用者在手機上的 Synology Chat 發送文字或圖片。
- 訊息轉發至實體主機，注入 VirtualBox 虛擬機中的 Hermes Agent。
- Agent 整理上下文與提示詞，跨層呼叫實體主機的 llama-server（Port 8080）進行模型推論。
- 模型生成結果後回傳給 Agent 整理，原路推播回 Synology Chat。
二、硬體配置清單
- 前端伺服器：Synology NAS（負責 Chat 服務與訊息轉發）
- 中央處理器 (CPU)：Intel i9-9900K @ 3.60 GHz（VM 分配 4 核，llama.cpp 佔用 16 執行緒）
- 系統記憶體 (RAM)：128 GB DDR4 @ 3203 MHz（提供充裕的主機與快取空間）
- 圖形處理器 (GPU)：雙 NVIDIA RTX 5070 Ti（16 GB × 2，共 32 GB VRAM）
- 匯流排 (PCIe)：PCIe 3.0（拆分 8x + 8x）
- 高速儲存：5 TB NVMe SSD（存放模型權重檔、知識庫與歷史對話記錄）
三、算力層核心：llama.cpp 部署與加速關鍵
推論引擎採用 llama.cpp，模型選用 Qwen3.8-27B-UD-Q5_K_XL 搭配視覺組件。
完整啟動腳本
@echo off chcp 65001 >nul llama-server.exe ^ -m "models\Qwen3.8-27B-UD-Q5_K_XL.gguf" ^ --mmproj "models\mmproj-Qwen3.8-27B-f16.gguf" ^ --image-min-tokens 1024 ^ --image-max-tokens 2048 ^ --split-mode tensor ^ --tensor-split 1,1 ^ --main-gpu 0 ^ -ngl 999 ^ -t 16 ^ -fa on ^ --ctx-size 131072 ^ --parallel 1 ^ -b 2048 ^ -ub 512 ^ -cb ^ --cache-type-k q8_0 ^ --cache-type-v q8_0 ^ --spec-type draft-mtp ^ --spec-draft-ngl 999 ^ --spec-draft-n-max 2 ^ --spec-draft-p-min 0 ^ --jinja ^ --reasoning-preserve ^ --chat-template-kwargs "{\"reasoning_effort\":\"medium\"}" ^ --temp 0.2 ^ --top-p 0.7 ^ --top-k 20 ^ --min-p 0.08 ^ --samplers "top_k;top_p;min_p;temperature" ^ --repeat-penalty 1.05 ^ --host 0.0.0.0 ^ --port 8080 pause系統高效運行的 3 個關鍵調優
- 雙卡對稱張量並行（Tensor Split 1,1）
27B 模型權重約 18～19 GB，單張 16G 顯卡無法全卸載。採用--split-mode tensor與1,1純對稱切分，讓兩張卡算力與矩陣乘法維度完全對齊，徹底消除非對稱切分帶來的 AllReduce 通訊等待延遲。 - 128K 超長上下文 + Q8_0 KV Cache
為了讓 AI 助理具備長記憶與長文件讀取能力，配置了原生 131,072（128K）上下文。搭配--cache-type-k/v q8_0對快取進行量化，精確將整體顯存壓在雙卡 32 GB 範圍內。 - MTP（Multi-Token Prediction）投機解碼
利用 Qwen 原生 MTP 架構開啟投機預測推論（--spec-type draft-mtp），讓生成速度在長文本下依然能穩定維持 75 tok/s 以上的高檔水準。
四、效能實測表現
透過標準 API 串流端點進行 3 輪長文本生成測速：
評測項目 實測數值 體驗感受 平均生成速度 76.33 tok/s 500 字回覆約 6～7 秒即可完成，出字如行雲流水 首字延遲 (TTFT) 0.57 秒 發送訊息後不到 1 秒內即開始串流出字 穩定度 74.64 / 75.05 / 79.30 tok/s 多輪長時間測試速率一致，無降頻與卡頓 投機命中率 Draft Acceptance 40%～97% MTP 機制大幅提升每秒字數產出
五、落地應用心得與優勢
- 多模態辨識超實用
透過--image-max-tokens 2048限制圖片上限，隨手用手機拍下設備電路圖、報表截圖或手寫筆記發進 Chat，模型都能在 2 秒內完成 OCR 與內容解析，且完全不佔用多餘顯存。 - 算力與邏輯徹底解耦
將 Hermes Agent 放進 Linux VM 是一大亮點。Agent 需要安裝各種 Python 工具庫、排程腳本或知識庫外掛，在 VM 裡隨便折騰、拍快照備份，完全不會污染負責提供 GPU 算力的 Windows 實體主機。 - 極致隱私與零成本
所有對話紀錄、個人記憶庫與機密文件完全留在自家區網內。不再需要支付任何雲端 AI 訂閱費用，斷網時依然能正常工作。
結語
消費級硬體（雙 RTX 5070 Ti）搭配適當的架構分層與量化參數，已經完全能夠在自家內網搭建出一套高速度（76 tok/s）、大容量（128K Context）、能看圖且具備長記憶的頂級私人 AI 助理。
歡迎對本地部署與私人 Agent 感興趣的朋友在下方交流討論！
-
架构很完整，三層解耦的思路尤其对——Agent 放 VM 里随便折腾、推理层留在 Windows 物理机，正好把"Agent 吃资源/烧 token"和 GPU 算力隔离开。几个补充：
-
76 tok/s 跟论坛双 5070Ti 实录对得上（TID:1268 双 5070Ti 跑 27B），1,1 对称切分也是对的。PCIe 3.0 x8+x8 跑 27B 够用，但如果以后上 72B 级，8GB/s 的链路就是瓶颈。
-
显存账其实贴线了，算一下：Q5_K_XL 权重约 19GB + 128K Q8 KV（27B MoE 大概 8~10GB）+ MTP 头 + mmproj + 计算缓冲，加起来就在 32GB 边缘。llama.cpp 显存不够会静默把 KV spill 到 CPU，速度直接腰斩但不报错——建议看启动日志里 KV buffer 那行，确认是 GPU 还是 CPU。想留余量：KV 降 q4_0（注意 K/V 精度必须对称，q8_0 K + q4_0 V 这种不对称组合会静默回退非融合 attention）；128K 不是刚需的话 -c 65536 直接省一半 KV。
-
MTP 接受率 40%~97% 波动大是正常的：MTP 只预测少量 token，长文本里重复/模板段容易冲高，对话混着生成波动就大，看均值更有意义。
-
一个小提醒：9900K 总共 16 线程，VM 4 核 + llama.cpp 16 线程是超卖的，Windows 调度器会抢。你 TTFT 0.57s 说明暂时影响不大，但以后 VM 里跑重任务，记得给 llama-server 降 -t 留余量。
-
-
前言
(本篇內容由本地 Hermes AI 秘書編寫 — 核心模型 Qwen3.8 27B)
很多人使用 AI 助理都是呼叫雲端 API，但日常對話、私人日誌、甚至是工作上的機密文件與工程圖，全數送往外部伺服器始終存在隱私風險。
這套系統的核心目標只有一個：讓 AI 助理完全運行在自己的硬體上，對話、文件檢索與記憶全部閉環於內網，達成零訂閱、零雲端、零資料外洩。
這篇文章完整分享我所設計的「前端展示、邏輯中樞、本地算力」三層解耦架構、硬體規劃、關鍵推論優化與落地心得。
一、系統架構：三層解耦設計
為了讓整體系統具備高度穩定性與彈性，我將整個 AI 秘書拆分為三個完全獨立的層級：
架構層級 運行載體 核心職責 設計優勢 前端呈現層 Synology NAS (Synology Chat) 接收使用者訊息、推播回覆 手機與電腦隨開即用，無需額外安裝客戶端或記 IP 邏輯中樞層 VirtualBox (Ubuntu VM) 運行 Hermes Agent（工具呼叫、記憶管理、排程） 隔離運行，環境崩潰不傷主機，方便快照與備份 本地算力層 Windows 10 實體主機 運行 llama.cpp (Qwen3.8 27B + 視覺模組) Windows 對 NVIDIA 驅動支援完整，GPU 算力 100% 留給模型 訊息流轉路徑：
- 使用者在手機上的 Synology Chat 發送文字或圖片。
- 訊息轉發至實體主機，注入 VirtualBox 虛擬機中的 Hermes Agent。
- Agent 整理上下文與提示詞，跨層呼叫實體主機的 llama-server（Port 8080）進行模型推論。
- 模型生成結果後回傳給 Agent 整理，原路推播回 Synology Chat。
二、硬體配置清單
- 前端伺服器：Synology NAS（負責 Chat 服務與訊息轉發）
- 中央處理器 (CPU)：Intel i9-9900K @ 3.60 GHz（VM 分配 4 核，llama.cpp 佔用 16 執行緒）
- 系統記憶體 (RAM)：128 GB DDR4 @ 3203 MHz（提供充裕的主機與快取空間）
- 圖形處理器 (GPU)：雙 NVIDIA RTX 5070 Ti（16 GB × 2，共 32 GB VRAM）
- 匯流排 (PCIe)：PCIe 3.0（拆分 8x + 8x）
- 高速儲存：5 TB NVMe SSD（存放模型權重檔、知識庫與歷史對話記錄）
三、算力層核心：llama.cpp 部署與加速關鍵
推論引擎採用 llama.cpp，模型選用 Qwen3.8-27B-UD-Q5_K_XL 搭配視覺組件。
完整啟動腳本
@echo off chcp 65001 >nul llama-server.exe ^ -m "models\Qwen3.8-27B-UD-Q5_K_XL.gguf" ^ --mmproj "models\mmproj-Qwen3.8-27B-f16.gguf" ^ --image-min-tokens 1024 ^ --image-max-tokens 2048 ^ --split-mode tensor ^ --tensor-split 1,1 ^ --main-gpu 0 ^ -ngl 999 ^ -t 16 ^ -fa on ^ --ctx-size 131072 ^ --parallel 1 ^ -b 2048 ^ -ub 512 ^ -cb ^ --cache-type-k q8_0 ^ --cache-type-v q8_0 ^ --spec-type draft-mtp ^ --spec-draft-ngl 999 ^ --spec-draft-n-max 2 ^ --spec-draft-p-min 0 ^ --jinja ^ --reasoning-preserve ^ --chat-template-kwargs "{\"reasoning_effort\":\"medium\"}" ^ --temp 0.2 ^ --top-p 0.7 ^ --top-k 20 ^ --min-p 0.08 ^ --samplers "top_k;top_p;min_p;temperature" ^ --repeat-penalty 1.05 ^ --host 0.0.0.0 ^ --port 8080 pause系統高效運行的 3 個關鍵調優
- 雙卡對稱張量並行（Tensor Split 1,1）
27B 模型權重約 18～19 GB，單張 16G 顯卡無法全卸載。採用--split-mode tensor與1,1純對稱切分，讓兩張卡算力與矩陣乘法維度完全對齊，徹底消除非對稱切分帶來的 AllReduce 通訊等待延遲。 - 128K 超長上下文 + Q8_0 KV Cache
為了讓 AI 助理具備長記憶與長文件讀取能力，配置了原生 131,072（128K）上下文。搭配--cache-type-k/v q8_0對快取進行量化，精確將整體顯存壓在雙卡 32 GB 範圍內。 - MTP（Multi-Token Prediction）投機解碼
利用 Qwen 原生 MTP 架構開啟投機預測推論（--spec-type draft-mtp），讓生成速度在長文本下依然能穩定維持 75 tok/s 以上的高檔水準。
四、效能實測表現
透過標準 API 串流端點進行 3 輪長文本生成測速：
評測項目 實測數值 體驗感受 平均生成速度 76.33 tok/s 500 字回覆約 6～7 秒即可完成，出字如行雲流水 首字延遲 (TTFT) 0.57 秒 發送訊息後不到 1 秒內即開始串流出字 穩定度 74.64 / 75.05 / 79.30 tok/s 多輪長時間測試速率一致，無降頻與卡頓 投機命中率 Draft Acceptance 40%～97% MTP 機制大幅提升每秒字數產出
五、落地應用心得與優勢
- 多模態辨識超實用
透過--image-max-tokens 2048限制圖片上限，隨手用手機拍下設備電路圖、報表截圖或手寫筆記發進 Chat，模型都能在 2 秒內完成 OCR 與內容解析，且完全不佔用多餘顯存。 - 算力與邏輯徹底解耦
將 Hermes Agent 放進 Linux VM 是一大亮點。Agent 需要安裝各種 Python 工具庫、排程腳本或知識庫外掛，在 VM 裡隨便折騰、拍快照備份，完全不會污染負責提供 GPU 算力的 Windows 實體主機。 - 極致隱私與零成本
所有對話紀錄、個人記憶庫與機密文件完全留在自家區網內。不再需要支付任何雲端 AI 訂閱費用，斷網時依然能正常工作。
結語
消費級硬體（雙 RTX 5070 Ti）搭配適當的架構分層與量化參數，已經完全能夠在自家內網搭建出一套高速度（76 tok/s）、大容量（128K Context）、能看圖且具備長記憶的頂級私人 AI 助理。
歡迎對本地部署與私人 Agent 感興趣的朋友在下方交流討論！
-
Synology NAS (Synology Chat)
請問這比Hermes 內建的 Telegram 使用上有什麼優勢嗎？減少多層的Latency延遲 ？
誠實拆解，不吹不黑：我從來沒想過延遲的問題，哈~~~
1. 延遲：內網下 Synology Chat 是「手機➔LAN➔NAS」，我實測從 NAS 推送到 Agent 的端到端處理在 20ms 以內，省去跨國路由。回應時間取決於複雜度：純對話幾秒內就回，要查證/跑工具的則 8~80 秒——但無論哪種，平台那 20ms 都體感不到。延遲優勢真正有感的是高頻告警場景，不是對話速度。
2. 隱私（我換過來的最大理由）：所有資料留在自家 NAS，不經第三方雲端。補充：Synology Chat 有 E2E 加密頻道（連管理員都只有密文），但官方明定加密頻道會停用 Webhook/機器人，所以 AI 通道只能走一般頻道（管理員可查閱明文）——管理員是我自己所以沒問題，共用 NAS 的人要留意。
3. 穩定性：Telegram 限流嚴（約 1 msg/s），高頻通知容易撞 429；Synology Chat 走本地 Webhook，吞吐量由自家硬體決定。
結論：資料不出門、高頻告警、零訂閱選 Synology Chat；在外隨開即用、成熟生態選 Telegram。我選前者，因為我的資料只該在我的硬碟上。
以上資料請我的 AI 秘書幫我整理：延遲數據是它從系統日誌實測抓的，加密與限流部分對照過 Synology 官方 KB 與 Telegram 官方文件。
-llama.cpp 底層又默默變強了。雙卡玩家記得一定要對稱等分（1:1）、注意 PCIe 頻寬，所以我的變快是llama.cpp底層變強了
-
，
T terry 固定了此主题
-
，系统 取消固定了此主题
[
65.1k (
99.5%) 
️4 
0.6s 
️48.9s 
56.8 t/s]