QNAP 日前公布了 QuTS hero h6.1.0.3640 build 20261007 Public Beta 開放公開測試。這一版的官方發行說明篇幅不短，重點落在三個方向，重新設計的桌面與儀表板、以 AI Service Center（AISC）為核心的地端 AI 架構，以及快照與傳輸安全的強化。
CyberQ 將機房內的相關 QNAP NAS 逐步測試，並全數升級到這個版本，並以一台 TVS-h877AX 為主測機，逐條對照發行說明實測。本文整理實際看到的改善、可以量化的資料，以及升級過程中遇到、值得其他使用者先知道的問題。
測試環境
| 項目 | 規格 |
|---|---|
| 主測機 | TVS-h877AX，AMD Ryzen 5 7645，16 GB 記憶體，4 顆 10 TB RAIDZ1 |
| 顯示卡 | 12 GB 的 NVIDIA 顯示卡（Container Station 模式） |
| 對照與傳輸目的端 | 另一台同樣升級到 h6.1 的 QuTS hero NAS，雙方皆以 10GbE 連線 |
| 韌體 | QuTS hero h6.1.0.3640 build 20261007 Public Beta |
| 相關套件 | AI Service Center 1.0.0.842、LLM Core 2.0.0.67、Nvidia AI Runtime 1.0.0.53、Qsirch 8.0.0.2、Container Station 3.1.4.2673 |
升級後以 SSH 確認版本，/etc/os-release 顯示 6.1.0 (20261007)，核心為 6.6.129-qnap，建置日期 10 月 7 日，與 build 號碼一致。
一、介面改版：第一眼最有感的部分
登入頁
登入頁改為兩段式，先輸入帳號再輸入密碼，右上角可直接切換語系，底部集中放置 myQNAPcloud、說明與工具的入口。整體視覺比 h6.0 更簡潔。
桌面與工作列
發行說明提到「精簡化桌面預設介面」只適用於全新安裝。實測也是如此，由舊版升級的機器保留原本的桌面圖示，但工作列圖示改為線條風格，視覺一致性明顯提升。
儀表板改為右側滑出面板
儀表板改成從右側滑出的面板，視覺上比較好看，UI 設計留的空間比較適中，舊版的稍為太擠。這次的面板，預設有系統健康、CPU 與記憶體、儲存空間、溫度與散熱、線上使用者等小工具，底部可「新增 Widget」，這些小工具也能拖曳排序。發行說明也提醒，舊版放在桌面上的小工具升級後不會保留，需要重新加入。
通知整合為單一圖示
原本分開的「最近的通知」與「通知面板」合併為工作列上的單一圖示，面板內分為「警戒」、「通知」、「開始使用」三個分頁，警戒還能再依錯誤與警告篩選。實際使用時比舊版清楚許多。
小瑕疵是 AISC 下載完成的通知直接顯示未翻譯的字串鍵「_AISC_NOTICE_PULL_DONE」，屬於 Beta 版常見的多國語系翻譯遺漏。
二、AI Service Center 可說是這一版真正的主角
架構改變：LLM Core 變成「模型包」
AISC 是新的 AI 模型管理中樞。實際拆開來看，h6.1 的地端 AI 分成三層：
AI Service Center：管理介面與排程，負責決定模型放在哪個裝置、提供給哪個應用程式。
Nvidia AI Runtime：真正的推論引擎套件（約 7.1 GB），內含 Ollama 0.30.7（GPU 與 CPU 各一個容器）、ONNX 嵌入服務與 Whisper 語音辨識服務。
LLM Core 2.0：不再是推論引擎，而是一包預先下載的模型，包括 Gemma 4 12B（QAT 量化，約 7 GB）、Harrier-OSS 270M 文字嵌入、FG-CLIP2 影像嵌入與 Whisper large-v3-turbo。
這個分工比 h6.0 時期的 LLM Core 1.x 清楚，但也代表安裝順序與相依關係變得更重要（詳如本文下方的第七節）。
12 GB 顯示卡的實際表現
Runtime 裝好後，AISC 自動把三個預載模型（FG-CLIP2、Harrier、Whisper）放上 GPU，顯示記憶體用量 43%。這三個模型是 Qsirch 新版 AI 搜尋需要的。
模型庫目前提供 Gemma4 12B、26B、31B，以及 Qwen3.5 9B、Qwen3.6 27B、35B。但 LLM Core 內附的 Gemma4 12B 並沒有被自動載入，AISC 記錄寫的原因是 GPU 記憶體不足（pool_shortfall），AISC 估計 Gemma4 12B 需要 12.1 GB，而三個預載模型已經佔去約 4.4 GB。
透過這個節目，手動載入 Gemma4 12B 後，儘管系統 UI 會提示這樣做可能超過顯示卡 VRAM 記憶體用量，但還是載入成功了，GPU 記憶體用量升到 91%。進一步查看 Runtime 內部的 Ollama，模型以 65,536 的上下文長度載入，實際被拆成 42% 在 CPU、58% 在 GPU，這也直接反映在後面 RAG 測試的速度上。
通常，習慣地端推論的我們，直覺的改善方式是把官方預載模型卸載，讓 Gemma 獨佔 GPU。但是實測呢，AISC 不允許這麼做，預載模型按下卸載會出現「必須至少保留一份在運行中，若要改跑在其他裝置，請使用『更多』選單的『更換裝置』」的訊息。然而在這台機器上，「更多」選單裡只有「AI 功能使用條款」與「關於」，找不到「更換裝置」。CyberQ 檢查前端程式後確認，這個功能目前只存在於語系字串中，模型頁面並未實作，由於目前是 Beta 版，正式版是否會實作，到時候要再看。
結論是，以 12 GB 顯示卡執行 h6.1 的地端 AI，嵌入與語音模型可以順利常駐，但 12B 級的對話模型會有一部分落到 CPU。 若主要需求是地端對話與 RAG，16 GB 以上的顯示卡會從容許多。
雲端供應商與「OpenAI 相容」
發行說明提到 AISC 可串接 OpenAI、Gemini、Azure 等雲端服務。實際的供應商清單是 OpenAI、Azure OpenAI、Gemini、Claude，以及最實用的「OpenAI 相容」。後者可以填入自訂端點，就可以指定到機房環境中的地端 AI 推論伺服器、有 NVIDIA 顯示卡的桌機啦， CyberQ 將它接到機房內另一台 GPU 伺服器的 OpenAI 相容閘道，測試連線一次通過，並能列出遠端提供的模型。
精靈的第三步可以為每個模型填入單價、設定每月預算與告警門檻，並選擇超過預算時「停止服務」或「僅通知」。對於擔心雲端費用失控的企業，這是很實際的設計。
「應用程式串接」頁則以應用程式為單位，列出每種能力（語音辨識、對話、文字嵌入、圖片嵌入）目前由哪個地端或雲端模型提供。
三個預載模型都是 Qsirch AI 語意搜尋背後的「建索引」模型，不負責對話。三個合計常駐約 4.4 GB VRAM，這也是 12 GB 卡放不下整個 Gemma 4 12B 的原因。
FG-CLIP2：以文字找圖片
- 它是 CLIP 類模型，有圖片和文字兩個編碼器，會把兩者對應到同一個向量空間。
- 建索引時把每張圖片轉成向量，查詢時把使用者輸入的句子也轉成向量，再比對相近程度。所以輸入「草地上奔跑的狗」這種描述就能找到照片，不需要檔名或標籤。
- 這也是 AISC 同時標示它有「文字嵌入」的原因，文字端是用來把查詢句轉成能和圖片比對的向量。
- 前面那次查詢結果裡的「相關的圖片」，就是這個模型的作用。
Harrier OSS v1 270M：文件的語意索引
- 來源是 Microsoft 的 microsoft/harrier-oss-v1-270m，約 2.7 億參數的文字嵌入模型，QNAP 轉成 ONNX 格式在 GPU 上執行。
- 把 PDF、Word 等文件的內容切段後轉成向量，查詢時依「意思」而不是關鍵字比對。
- 「快照保留天數有什麼建議」能把 DOC_5448.pdf 排在第一筆，靠的主要是它。
Whisper large-v3-turbo：語音辨識
- 來源是 OpenAI Whisper large-v3 的加速版，把解碼器從 32 層減到 4 層，速度快很多，準確度略降。
- 在 Qsirch 裡，AI 模式索引頁把它標示為「用於影音逐字稿」，把錄音和影片中的語音轉成文字，再納入索引，讓影音檔也能用語意搜尋找到。查詢結果出現 REC_9188.m4a 這個錄音檔。
三、Qsirch 8.0：AI 模式的門檻與 RAG 實測
AI 語意搜尋：真正的門檻是授權，不是顯示卡
發行說明寫明 Qsirch 新的 AI 語意搜尋需要「至少 16 GB VRAM GPU 的 QNAP NAS」與 LLM Core 1.1.0 以上。實測 12 GB 顯示卡的結果有點出乎意料：
在 Qsirch 設定的「AI 模式索引」頁，系統需求列出五項，AISC 就緒、三個預設模型已載入，以及 CAYIN Media Viewer 的基本授權或 Value Pack。前四項在這台 12 GB 顯示卡的機器上全部打勾，唯一未通過的是 CAYIN Media Viewer 授權。介面上沒有任何 16 GB 的要求。換句話說，在這條由 AISC 提供模型的路徑上，真正的門檻是 CMV 授權，而不是發行說明寫的 16 GB VRAM，兩者並不一致，正式版是否會調整值得觀察。
取得 CAYIN Media Viewer 的授權後，還有一個 Beta 的小插曲，裝好授權的當下，AI 模式的前置檢查並沒有立刻更新，仍顯示授權未通過。重啟 CMV 與 Qsirch 都沒有解決，直到完整重開機一次，開機時的授權與註冊交握重新跑過，AI 模式才真正解鎖。重開後進 AI 模式，先前的「服務無法使用」遮罩消失，語意搜尋、相關概念、智慧分類、摘要四項能力都就緒。
實際以自然語言下一句「快照保留天數有什麼建議」，AI 語意搜尋正確運作，相關文件第一筆就是語料中談快照保留策略的那份 PDF，而且結果同時涵蓋文件、圖片、影片與音訊四種類型，這正是背後三個嵌入模型加上 Whisper 語音辨識在跨媒體建索引的效果。
整體來說，12 GB 顯示卡能跑 AI 語意搜尋，真正的前提是 CMV 授權，而授權裝好後需要一次完整重開機才會生效，這個刷新時機屬於 Beta 階段的小瑕疵。CyberQ 這次測試呢，全程以正規授權與重開機讓檢查通過，沒有去修改或繞過任何授權驗證。
RAG 搜尋：地端 Gemma4 12B 與遠端模型對照
Qsirch 的 AI 知識搜尋（RAG）在 8.0 改由 AISC 統一提供模型，舊版的雲端 LLM 設定變成唯讀，可以匯出參考。這次測試，有沿用 CyberQ 先前測試 Qsirch 7.x 時建立的工作空間（15 份自製文件：繁中 10、英文 3、日文 2）與同一套 14 題測試題，比較兩種模型：
| 項目 | Gemma4 12B（本機 12 GB 顯示卡） | DeepSeek V4.1 Flash（經 AISC 串接遠端 GPU 伺服器） |
|---|---|---|
| 總分（14 題） | 11 | 11 |
| 同語言題（9 題） | 9／9 | 9／9 |
| 跨語言題（4 題） | 1／4 | 1／4 |
| 負向題（文件中沒有答案） | 正確回答「沒有相關資訊」 | 正確回答「沒有相關資訊」 |
| 首字時間中位數 | 33.6 秒 | 1.5 秒 |
| 完整回答時間中位數 | 96.2 秒（38 至 187 秒） | 7.6 秒 |
兩個模型的分數相同，而且檢索到的來源文件完全一致，答錯的都是「用中文問英文或日文文件」的跨語言題。這說明瓶頸在檢索階段（工作空間使用的嵌入模型），而不是生成模型本身。兩者答不出來時都誠實表示找不到資料，沒有捏造答案。
差別在速度與文字品質。Gemma4 12B 因為有 42% 在 CPU 上執行，完整回答的中位數超過一分半，回答中偶爾夾雜英文單字或其他語言的字詞。接上遠端模型後，同樣的題目不到 8 秒就完成。如果換用 16GB VRAM 的顯示卡，這速度應該會在幾十秒內就完成，理論上會接近 10 秒。
實測：用 Whisper 把錄音轉成文字，再交給 AI 整理會議紀錄
AISC 預載的 Whisper large-v3-turbo，除了替 Qsirch 的影音檔建立索引，也能透過 AISC 提供的 OpenAI 相容 API（/v1/audio/transcriptions）直接使用，呼叫時需要帶入已在 AISC 註冊的應用程式 ID。拿兩段錄音實測，一段約 40 秒、多人在場的會議現場錄音，以及一段約 22 秒、兩人對話的清楚錄音。
| 錄音 | 長度 | 轉錄時間 |
|---|---|---|
| 多人會議現場 | 39.7 秒 | 1.5 至 3.9 秒 |
| 兩人對話 | 22.1 秒 | 1.5 至 5.1 秒 |
以上時間包含上傳，且當時 GPU 上同時載著 Gemma 4 12B。換算約為即時速度的 4 至 26 倍，第一次呼叫較慢，之後多在 2 秒內完成。輸出除了純文字，也支援 SRT 字幕與逐字時間戳記。
實測有三個重點：
- 格式：直接上傳 m4a 會被拒絕（引擎回應 400），需要先轉成 16 kHz 單聲道的 WAV。Qsirch 建立索引時會自行處理，但自己呼叫 API 時要注意。
- 準確度取決於錄音品質：清楚的兩人對話幾乎全對，兩次轉錄結果逐字相同。
- 繁簡體不固定：會議那段輸出繁體，兩人對話那段卻輸出簡體。在請求中加入一句提示詞「繁體中文。」即可統一為繁體，「高爾夫」也一併轉對。
從逐字稿到會議紀錄
Whisper 只負責轉文字，不會分辨發言者，也不會整理重點。因此接著把會議逐字稿交給兩個對話模型整理成會議紀錄：
| 模型 | 耗時 | 表現 |
|---|---|---|
| Gemma 4 12B（本機 12 GB 顯示卡） | 約 49 秒 | 結構完整，但會把語意不明的發言推論成「決議通過」 |
| DeepSeek V4.1 Flash（經 AISC 串接遠端 GPU 伺服器） | 約 11 秒 | 較謹慎，會標出無法從逐字稿確認的部分 |
兩個模型都能把疑似辨識錯誤的字詞列為待確認事項，但都沒能還原出正確用字。自動產生的會議紀錄仍需要人工核對，比較適合當作初稿。
使用 Gemma 4 的一個陷阱：Gemma 4 預設會先「思考」再回答。透過 API 直接呼叫時，輸出額度可能全部耗在思考上，回應正文是空的，甚至超過閘道約 300 秒的上限而失敗。在請求中加上 "reasoning_effort": "none" 關閉思考後才恢復正常。Qsirch 的 RAG 不受影響，但自行串接時要特別注意。
12 GB 顯示卡的取捨：三個預載模型加上 Whisper 轉錄時的工作記憶體，會讓 Gemma 4 12B 有四成以上落在 CPU。AISC 介面不允許卸載預載模型，測試時改在容器層停用 FG-CLIP2 與 Harrier 所在的 ONNX 服務，釋出約 3.3 GB 後，Gemma 在 GPU 上的比例由 56% 提高到 85%。不過生成速度仍約每秒 6 至 7 個 token，提升有限，Qsirch 的 AI 語意搜尋也會隨之失效。因此不建議一般使用者這樣做，若需要即時整理會議紀錄，把對話模型交給更大的 GPU 或雲端服務會比較實際。因此 QNAP 官方才推薦至少要 16GB VRAM 顯示卡才能夠使用這些功能，這算是最低消的建議值。
四、QuAgent 只能在部分新款機型安裝
發行說明介紹的對話式助理 QuAgent 1.0.0.1893 已上架 App Center，但套件目錄中的支援平台只有 QAI-X300、QAI-X700、QAI-X90 與 TS-X74 系列。在 TVS-h877AX 上以 App Center 安裝，系統回報「找不到應用程式」。TS-855x 同樣不在名單內。想體驗 QuAgent 的使用者，安裝前請先確認機型。
CyberQ 直接從 QNAP 網站上下載下載了該套件檔案 QuAgent_1.0.0.1893_x86_64.zip，直接使用指令安裝，確實也是可以用的，但它的功能較多，需要的顯示卡記憶體要夠大才能跑，這個測試只是證實具備 GPU 的 NAS 也能夠安裝和開啟，但要有良好的使用體驗和功能完整性，需要更強大的顯示卡才行。或者是讓它接上雲端模型、其他地端模型均可，同樣也能夠執行好 QuAgent AI 代理人的任務。
設定可以限定那些模型可以讓 QuAgent 使用，和 Qsirch 共用一個設定介面，安裝好 QuAgent 就會自動長出來這個可設定區域。
五、安全性：後量子密碼學 PQC 已經預設啟用
發行說明寫的是「控制台 TLS 設定為 1.3 時，自動啟用 PQC（後量子密碼學）」。CyberQ 以 OpenSSL 3.5 對兩台 NAS 的管理介面做握手測試：
| 測試 | 主測機（只允許 TLS 1.3） | 對照機（允許 TLS 1.2 以上） |
|---|---|---|
| TLS 1.3 預設協商群組 | X25519MLKEM768 | X25519MLKEM768 |
| 強制 X25519MLKEM768 | 成功 | 成功 |
| 僅提供 X25519 | 成功（傳統金鑰交換） | 成功（傳統金鑰交換） |
| TLS 1.2 | 拒絕 | 成功 |
結果顯示，只要用戶端以 TLS 1.3 連線，即使最低版本仍是 TLS 1.2，也會優先協商混合式的 X25519MLKEM768，不支援的舊用戶端則退回傳統的 X25519，相容性沒有問題。
發行說明另提醒憑證的有效期間欄位必須符合 ITU-T X.690 並包含秒數。兩台機器使用的預設自簽憑證都採 13 位元組、含秒數的 UTCTime，不受影響。使用內部 CA 憑證的環境，建議在升級前先檢查。
六、快照：SnapSync token 驗證與傳輸實測
Token 驗證在背景完成
發行說明新增「SnapSync 任務的 token 驗證」，並提醒兩端 NAS 都必須支援。實測時介面上看不到任何 token 相關的設定；建立工作時一樣是輸入遠端 NAS 的帳號密碼，連線成功後，兩端都各自產生了記錄 token 的設定檔。也就是說，token 是在第一次以帳密驗證後自動交換，後續工作改用 token 溝通，對使用者是透明的。
10GbE 傳輸數據
測試資料為 20 GiB 不可壓縮的隨機資料加上 2,000 個 64 KiB 小檔，傳輸設定採預設值（傳輸中加密、不壓縮、不去重複），兩端皆為 10GbE。
| 項目 | 結果 |
|---|---|
| 首次完整同步 | 109 秒送出 22.4 GB，平均 206 MB/s，5 秒峰值 406 MB/s |
| 資料正確性 | 抽查 5 GiB 檔案與小檔，兩端 MD5 一致；目的端 ZFS 快照 20.1 GB |
| 增量同步（新增 5 GiB） | 傳輸中將目的端 SnapSync 服務停用 60 秒 |
| 中斷後行為 | 工作轉為「斷線」，服務恢復後 8 分鐘內未自動續傳 |
| 手動重新執行 | 43 秒完成，只再送出 2.07 GB，確認可從中斷處續傳，檔案 MD5 一致 |
續傳機制本身可靠，但需要留意的是中斷後不會自動重試，必須手動或等下一次排程。
Snapshot Replica 的「重試間隔」
發行說明提到 Snapshot Replica 的「逾時時間」改為「重試間隔」。這個設定位於快照管理員的全域設定「遠端快照備份的連線重試」，預設重試間隔 300 秒、重試 3 次，範圍 1 至 3600 秒，與說明一致。需要釐清的是，這個重試設定屬於快照備份（Snapshot Replica），並不套用在 SnapSync 上，這也解釋了上面 SnapSync 中斷後沒有自動續傳的現象。
七、升級時兩個值得先知道的問題
問題一：LLM Core 1.1 升級到 2.0 後，整個網頁管理介面掛住
升級 LLM Core 到 2.0.0.67 之後，在 AISC 操作的過程中，NAS 的網頁介面完全無法連線，SSH 卻正常。重開機也沒有改善。
追查發現，8080 埠上累積了四千多條連線，全部來自 NAS 自己。原因是：
- 舊版 LLM Core 1.1.0 在套件設定中宣告了「使用反向代理」（
Use_Proxy = 1）。 - LLM Core 2.0 不再提供網頁介面，安裝腳本把網址與連接埠欄位清空，但沒有清掉反向代理旗標。
- 系統依此產生的代理規則變成「把所有請求轉給 8080 的
/apps/llmcore/」，而 8080 正是管理介面自己，形成無限迴圈，把網頁伺服器的執行緒耗盡。
由於規則在每次開機時重新產生，重開機無法解決。處理方式是把 LLM Core 的反向代理旗標改為 0，移除那條代理規則後重啟網頁服務。之後將 LLM Core 與 AISC 移除重裝，全新安裝的 LLM Core 2.0 不會帶有這個旗標，問題也沒有再發生。曾經安裝過 LLM Core 1.x 的使用者，建議升級前先移除舊版 LLM Core，再安裝 2.0。
問題二：Qsirch 7.0 升級到 8.0 後，搜尋介面回應 503
Qsirch 升到 8.0.0.2 後，網頁回應 503。日誌顯示 Qsirch 的 API 服務在讀取舊版留下的使用者偏好設定時解碼失敗，反覆重啟後被監控程式放棄。把舊的偏好設定檔改名備份後重啟 Qsirch，服務立刻恢復，既有的工作空間與索引都完整保留，只是各使用者的搜尋工具偏好回到預設值。
八、本次未能驗證的項目
以下發行說明項目，受限於機型或環境，本次沒有實測：
- QAI 系列專屬的「AI 模式」初始化與 AI 儲存配置引導（需要全新初始化）。
- Intel Arc B70 獨立顯示卡資訊（僅限特定機型）。
- 以 USB 金鑰刪除 WORM 共用資料夾與不可變快照（有不可逆風險，只確認介面已有「安全刪除」精靈）。
- 不符合 X.690 的憑證被拒絕載入的情境。
結論
CyberQ 實測這次的 QuTS hero h6.1.0 Public Beta 的介面改版確實有感，兩段式登入、右側儀表板與合併後的通知面板，讓日常管理更直覺。PQC 預設啟用、SnapSync 改用 token 驗證，則是在使用者幾乎無感的情況下補強了安全性。10GbE 環境下 SnapSync 首次同步平均 206 MB/s，續傳機制也能正常運作。
AI Service Center 是這一版最大的架構變化。它把推論引擎、模型與應用程式串接拆開管理，「OpenAI 相容」供應商讓企業可以把地端 GPU 伺服器或任何相容的服務接進 NAS 的應用程式，並附帶預算控管，方向正確。但以 12 GB 顯示卡實測，嵌入與語音模型可以常駐，12B 級的對話模型就會有一部分落到 CPU，RAG 回答時間如果改用 16GB VRAM 以上顯示卡，效果和速度會更好，若是其他預載模型如果可以設定卸載可能會更好，但使用者就無法獲得完整體驗了，這應該是進階用戶會自己考量的點。
至於 Qsirch 的 AI 語意搜尋，在這張 12 GB 卡上同樣跑得起來，真正的前提是 CAYIN Media Viewer 授權，取得授權並完整重開機後，跨文件與多媒體的語意搜尋可正確運作。
身為 Public Beta，這一版也有不少需要留意的地方，LLM Core 與 Qsirch 的升級路徑各有一個會讓服務停擺的問題，部分訊息尚未翻譯，QuAgent 僅支援少數機型，發行說明的 Qsirch 16 GB 門檻也與實際行為不同。建議生產環境等待正式版，若要先行測試，請先備份設定，並依照本文第七節的順序處理 LLM Core 與 Qsirch 的升級。
