老闆要求小安評估：能不能不靠大型雲端服務，改用開放模型自己部署一個會聽會議錄音、會呼叫內部工具的小助理，而且資料不能外洩
走進 AI 落地的現場，第一個問題往往不是「要不要用 AI」，而是「該選哪一種模型」。現在開放權重的模型（開放權重模型訓練好的「成果檔」公開讓人下載，你可以放在自己的電腦或伺服器上跑，而不是只能透過別人的網站使用）正朝兩個很不一樣的方向發展：一個是「小而專」，另一個是「大而全」。這一單元先看清楚這兩條路各自長什麼樣子。
先看「小而專」的代表：Liquid AI 的第三代小型模型 LFM3。它的文字、影像、聲音、全能（omni）與決策等模型，全都建立在同一個約 20 億參數（參數模型內部可調整的數字旋鈕，數量越多通常越有能力，但也越吃記憶體與算力）的底座上，共有六個 2B 等級的模型。重點在於：你可以依需求挑出對應的模型，用自己的資料在「單張顯卡」上微調，再部署到應用程式實際執行的地方。
為什麼它能放進裝置裡？素材給了幾個具體數字：文字模型在 4 位元精度下只要約 1 GB（量化把模型裡的數字用更少的位元來存，像把高畫質照片壓成較小的檔案，換取更小的體積和更快的速度，品質略有取捨）；而且 LFM3-1.7B 用的參數比前代 LFM2.5-2.6B 少 35%，表現卻更好。它的文字模型還支援 256K token 的上下文長度，讓代理（agent，能自己呼叫工具完成任務的 AI）有機會在裝置端運作。架構搜尋涵蓋 14 種裝置與後端組合，從手機、Raspberry Pi 5 到筆電、雲端 CPU、GPU，以及高通的 Hexagon NPU。
再看「大而全」的代表：Mistral Large 4（暱稱 Le Chonk）。它能讀文字也能看圖，總參數約 1 兆、每次實際啟動的約 490 億，採用 MoE（MoE 混合專家把模型切成許多「專家」小組，每個詞只叫其中幾組出來工作，所以雖然總規模很大，每次實際運算量卻比較小）架構，上下文視窗長達 100 萬 token。授權是 Mistral 生態系開放權重授權，類似 MIT，但對「把模型當成服務賣給別人」有限制。
它特別擅長資安與寫程式。在 Artificial Analysis Cyber Index 測試中，要求模型重現開源軟體裡的真實漏洞再修補，Mistral Large 4 得 82%；Mistral 並指出幾個封閉的前沿模型因為拒絕嘗試而接近零分。這對防守方很重要，因為修漏洞通常得先重現漏洞。開放權重讓使用政策與部署方式都掌握在使用者手中，不必擔心 API 在事故處理到一半被停用。
所以兩條路的選擇邏輯很清楚：場景需要在手機、小型設備上離線執行、或要用自己的資料量身微調，選 LFM3 這類小而專的模型；需要一次讀進超長文件、看圖、處理複雜的程式與資安任務，選 Mistral Large 4 這類大而全的模型。而「資料放在自己手上」這件事，正好帶出下一個要談的議題：當推論改在雲端做，資料會不會洩漏？
| 比較項目 | LFM3（Liquid AI） | Mistral Large 4 |
|---|---|---|
| 規模 | 約 20 億參數（2B 等級） | 總參數約 1 兆、啟動約 490 億 |
| 輸入類型 | 文字、影像、聲音、全能、決策各有對應模型 | 文字與影像 |
| 上下文長度 | 文字模型 256K token | 100 萬 token |
| 部署重點 | 量化後約 1 GB，可跑在裝置端 | 大型模型，也有 GGUF 版本可供社群使用 |
| 客製方式 | 單張顯卡即可微調 | 可用其產生的資料訓練較小的模型 |
| 擅長場景 | 裝置端代理、貼近自己資料的專用模型 | 程式、資安、多模態 |
上一單元看到，開放模型可以選「小而專」或「大而全」。這一單元要問的是：選好模型之後，一個 AI 助理怎麼從「聽見聲音」走到「做出正確的事」？這中間有兩道關卡：先把聲音變成文字，再把文字變成可靠的動作。
第一道關卡是語音轉文字。NVIDIA 釋出的 Nemotron 3.5 Transcribe 是一個開放權重模型模型訓練好的參數公開給大家下載，任何人都能拿來自己跑或自己調整。一個模型就包辦轉寫（40 種語言）、翻譯（其中 31 種可和英文互譯）、分辨誰在說話（13 種語言），還能回答關於錄音的問題。它能處理長達一小時的錄音，最多標示八位講者。
最有意思的是它「可以被指令調整」。同一段會議錄音，你說「轉寫這段錄音並標出每位講者」，它就給逐字稿；說「把這段音訊翻成英文」，它就給翻譯；問「這場會議做了哪些決定？」，它就直接回答。也就是說，你不用換模型，只要換一句話。
但光靠一句話，遇到陌生的專業詞彙（例如醫療用語）可能還是寫錯。素材建議先試「提供上下文」，不夠再訓練：在醫療案例中，針對沒聽過的講者做微調，字詞錯誤率（WER，也就是轉錯字的比例）比最好的一種提示寫法再降低 45.8%（相對值）。
第二道關卡是「做得到」。AI 要呼叫外部工具，需要兩步：先告訴模型有哪些工具，再教它用固定格式輸出呼叫。格式只要錯一點，後面的動作就接不起來。Ubicloud 用 vLLM 0.28 自架 Kimi K2.6 時，只有 92% 的工具呼叫符合預期格式，也就是每 25 次就失敗 2 次。錯誤的呼叫會讓模型在無意義的上下文上繼續累積，多輪的代理式任務尤其容易越做越歪。
修法是受限解碼模型每次挑下一個字時，只准它從符合格式規則的字裡選，所以不可能寫出格式錯誤的內容。vLLM 0.31 把它做成伺服器端的旗標（開關），打開後，較新的 Kimi 與 DeepSeek 模型在格式正確率上達到 100%。順帶一提，Liquid AI 的 LFM3 在訓練後段刻意加入較多代理操作紀錄與工具呼叫資料，可見「穩定呼叫工具」已是小模型訓練時的明確目標。
| 手段 | 管什麼 | 素材中的成效或特點 |
|---|---|---|
| 文字指令（提示） | 決定語音模型輸出轉寫、翻譯、講者標示或問答 | 同一個模型，換一句話就換一種輸出，不必重新訓練 |
| 微調 | 讓語音模型適應專業詞彙與口音 | 醫療案例中，錯誤率比最好的提示再降低 45.8%（相對值） |
| 受限解碼 | 讓工具呼叫的格式一定正確 | 從約 92% 提升到 100%（vLLM 0.31 的伺服器旗標） |
這是 OpenCode 傳給 Kimi 的工具說明書（節錄、簡化），描述一個叫 webfetch 的網頁抓取工具。模型輸出的呼叫必須符合這份格式，受限解碼守的就是這份規則。
"name": "webfetch","type": "object","url": { "type": "string", ... },"format": { "type": "string", "enum": ["text", "markdown", "html"] },"timeout": { "type": "number", ... },"required": ["url"]上一單元我們看到，模型要「做得到」，靠的是穩定的工具呼叫。但當你把這些能力放到雲端或自己的機器上跑，另一個問題就浮現了：你的資料，會不會被別人看到？這一單元就用 Cloudflare 公布的一起真實事故來回答。
先講一個背景。AI 服務在處理你的長篇提問時，會把算過的中間結果存起來，這個暫存區叫做 KV 快取模型讀完你的文字後，把「已經算好的理解結果」暫存起來的記憶區，下次要接著用時不必重算。這樣做是為了快，而且很多使用者會同時共用同一批 GPU，所以快取必須確保「你的內容只屬於你」，這就是所謂的 租戶隔離同一套系統服務很多客戶時，保證客戶之間彼此看不到對方資料的機制。
事故經過是這樣：2026 年 8 月 27 日起，Cloudflare 上跑的 GLM-5.3 模型，讓少數客戶收到了「別人剛送出的請求內容」。總共 155 筆回應受影響，而且全部發生在提示長度超過 681,280 個 token 的情況。9 月 8 日由資安研究員 Gadi Evron 通報，Cloudflare 隔天重現問題，宣告事故後 40 分鐘內就把模型下線，當天修好並恢復服務。他們也查過，這些請求的時間與數量像是正常的長文件使用，沒有發現有人刻意利用漏洞。
原因是兩個問題疊在一起。第一，設定不一致：模型對外宣稱可以讀 1,048,576 個 token，但負責讀題的 GPU 上，快取空間只裝得下 681,280 個。Cloudflare 上線前就知道這個落差，但預期引擎遇到放不下的內容會直接報錯，而且他們的長文測試也都成功回應，所以沒當一回事。第二，是所用的開源推論引擎 SGLang 的程式錯誤：太長的請求被標記為拒絕，並換成一個只有一個 token 的佔位內容，但系統沒有中止並回報錯誤，反而照樣為佔位內容產生快取並往下傳，結果讀到的是別人留在那塊空間裡的內容。
把這件事放到「自架」的角度看，風險同樣存在，只是形式不同。第二篇素材講的是用 vLLM 自架開源模型：用 vLLM 0.28 跑 Kimi K2.6 時，工具呼叫格式只有 92% 正確，也就是每 25 次就有 2 次失敗，這是品質風險；不過這則素材談的是格式正確率，並沒有談資料外洩。所以評估時要分開看：雲端的風險是「你無法檢查別人家的設定與引擎」，自架的風險是「所有設定與修補都得自己負責」。
| 面向 | 用雲端 AI 服務 | 自架開源模型 |
|---|---|---|
| 設定與引擎誰負責 | 服務商負責，你看不到細節 | 你自己負責，包含設定與更新 |
| 素材中的實例 | GLM-5.3 因快取隔離出錯，155 筆回應含他人內容 | vLLM 0.28 跑 Kimi K2.6，工具呼叫格式僅 92% 正確（品質問題，非外洩） |
| 發現與修復 | 靠外部研究員通報，服務商下線修復 | 要自己追蹤引擎版本與修正 |
| 你能做的事 | 了解服務是否與他人共用，並留意公告 | 自己控管設定、測試並及時升級 |
上一單元我們看到，雲端推論服務可能因為快取隔離出錯，把別人的資料送到你手上。這一單元要把視野再拉大一步：從「模型」到「推論服務」再到「開發工具」，它們串成一條信任鏈，任何一環出缺口，整條鏈都不可靠。
先看 Cloudflare 的事故。他們用開源的 推論引擎負責把模型載入並真正算出回答的軟體 SGLang 跑 GLM-5.3，上線時設定的 context window模型一次能讀進去的內容長度上限 是 1,048,576 個 token，但 KV cache模型為了加速而暫存先前計算結果的記憶區 池只容得下 681,280 個 token。團隊在上線前就知道這個落差，卻以為超長的請求會被引擎直接報錯；結果引擎把超長請求換成一個佔位符，卻沒有中止，反而把別人的快取內容送了出去。受影響的是 155 筆回應，全都是超過 681,280 token 的長提示。這告訴我們：「我以為它會報錯」不是安全保證。
接著是更貼近日常的例子。資安公司 Phorion 發現，Cursor 擴充市集上的官方 Claude Code for VS Code 擴充套件 2.1.313 版被植入後門。擴充套件是以你本人的權限執行的，所以一載入就能碰到本機檔案、原始碼與開發工具。這個後門會設定 SSH 遠端登入並留下持久的存取方式，還會把主機資訊回傳給操作者。Cursor 已下架該版本，並同時從 NPM 與 VS Code 的來源撤下 2.1.313。
有趣的是，這個後門在 macOS 上有個失誤：它用 systemsetup -getremotelogin 檢查 SSH 是否關閉，但一般使用者執行時，這個指令只會印出需要管理員權限的錯誤，並且回傳狀態 0，而不是 Off，所以惡意程式沒有真的把 SSH 打開。但 SSH 金鑰和持久化機制仍被放下，所以仍然必須當成事件處理。運氣好不等於安全。
把三則素材放在一起，就能建立三個實用習慣。安裝前：確認來源與版本、留意有無異常更新。事後排查：若曾安裝受影響版本，檢查是否出現不明的 SSH 金鑰與遠端登入設定，並通知資安人員。最小權限：開發工具不要用超過需要的權限，也不要把敏感資料放在不需要的地方。開放權重模型如 Mistral Large 4 讓你自己掌控部署與使用政策，但它同樣是信任鏈的一環，自架不代表可以省略檢查。
| 環節 | 本單元事件 | 缺口原因 | 你能做的事 |
|---|---|---|---|
| 模型/推論引擎 | GLM-5.3 快取外洩 | 快取池小於宣告的長度上限，且引擎沒有正確中止請求 | 了解服務上限，不要假設超長輸入會被擋下 |
| 推論服務 | Workers AI 租戶隔離 | 多個客戶共用服務，資料隔離出錯 | 敏感內容不要隨意送上共用雲端服務 |
| 開發工具 | Claude Code 擴充套件後門 | 官方發布管道的套件被植入惡意程式碼 | 核對版本、排查 SSH 痕跡、最小權限 |