QVAC 把消費硬體變本地 AI

我拆 Tether 的 QVAC 堆疊，整理成一套可直接套用的本地優先 AI 模板。

我最近一直盯著 AI 工具怎麼長歪。大家嘴上都說 local、private、efficient，結果你一打開文件，還是那套老把戲：雲端 API 包一層、GPU 帳單藏一層、資料照樣往別人的伺服器送。更煩的是，很多產品把「本地」講得像信仰，實際上只是把雲端依賴換個包裝。我想要的是模型真的跑在資料所在的地方，不是再多一個漂亮的轉接頭。

後來我看了 Tether 的贊助文章 Tether AI is building the Stable Intelligence layer，我在意的不是行銷詞，是它把整個堆疊拆成什麼樣子：QVAC Fabric、QVAC SDK、本地推理、delegated inference，還有真的想讓消費級硬體做事的企圖。TechCrunch 這篇有明講是 sponsored content，所以我不會把它當中立報導；但它提供的架構形狀，剛好可以拿來拆成一套我自己能抄的做法。

別再把「本地 AI」當口號

“QVAC SDK and Fabric give people and companies the ability to execute inference and fine-tune powerful models on their own terms, on their own hardware, with full control of their data.”

翻譯一下就是：重點不是「AI 變小」，重點是控制權回到自己手上。模型如果真的跑在你的筆電、手機、桌機，或團隊自己的機器上，延遲、隱私、成本就不再是簡報上的漂亮名詞，而是你能直接設計的產品限制。

我看過太多團隊被反殺。先在託管 API 上做原型，做出一個看起來很能打的功能，然後才發現使用量一上來，帳單直接把老闆的臉色改寫。或者更慘，資料不能出境，法遵直接把雲端方案打槍。再不然就是想客製模型，結果整個流程掉進雲 GPU、重訓、排程和月結單的泥巴裡。

Tether 這套說白了就是：少把每一步推理都租給別人。這不是道德口號，這是系統設計。只要工作負載能留在消費級硬體上，很多壓力會直接消失。代價也很現實：你要自己扛裝置差異、後端混雜、還有跨硬體的穩定性。沒有免費午餐，只有把麻煩換到你能掌控的位置。

實操寫法很簡單：我會先替每個 AI 功能問一個很土但很有用的問題，這個功能真的需要雲端嗎，還是只是需要一個模型？如果只是需要模型，我會先設計成 local-first，再考慮遠端 fallback。這個決定會直接改寫你的架構，不是小修小補。

QVAC Fabric 其實是在賭 runtime，不是在賭模型

文章裡說 QVAC Fabric 是一個「high-throughput inference runtime」，而且是從 llama.cpp 延伸出來的。這個細節比那些更響亮的「Stable Intelligence」更重要。做過模型工具的人都知道，真正痛的是 runtime，不是模型名單。模型負責吸睛，runtime 負責挨罵。

也就是說，Tether 不是只在包一層模型 API，而是在做一個通用的 AI 執行層。文章提到 Fabric 是 hardware-agnostic，能跑在 NVIDIA、AMD、Intel 的桌機 GPU，也能碰到 Mali、Adreno、Apple silicon 這些行動端晶片，還能依 GPU 切換 Vulkan、CUDA、ROCm。這種說法聽起來很無聊，但你只要真的要支援混合裝置，就會知道這有多重要。

我以前做內部工具就撞過這種牆。工程師手上是 NVIDIA，設計師是 MacBook，外勤同事的筆電則是那種不該拿來跑推理的等級。如果你的堆疊只認一種 GPU 廠牌，你基本上已經把半個團隊踢出局。如果你只押雲端，那離線、敏感資料、低網路環境也都別玩了。

• runtime 的可攜性，通常比模型新鮮度更重要。
• 只要硬體不是單一規格，backend 切換就不是加分題，是生存題。
• 消費級硬體支援有沒有用，關鍵看 runtime 能不能撐住裝置差異。

實操寫法是把 runtime 當成產品的一級元件。先列出你要支援的 backend，再列出最低裝置規格，最後才去挑模型。順序顛倒的話很常見：模型選得很漂亮，結果一半使用者的機器直接跑不動，那你的 AI 功能其實只是帶 UI 的實驗室 demo。

真正的麻煩是記憶體，不是聽起來很酷的演算法

文章提到一個 Dynamic Tiling Algorithm，說它可以透過切分大型矩陣運算來繞過記憶體限制。這種東西很多人會直接滑過去，因為聽起來太技術、太乾。但我不會。做本地 AI，記憶體就是地雷區。你可以有很聰明的模型，最後還是死在裝置塞不下工作集。

翻譯一下就是：軟體要負責把工作切成硬體吃得下的尺寸。這不性感，但它決定了「模型能在手機上跑」跟「模型只適合出現在簡報裡」的差別。文章還說 QVAC Fabric 會降低 mobile GPU 的運算開銷。如果這件事在實際使用上站得住腳，那差別就是產品像原生功能，還是像一個會把手機烤熱的負擔。

我看過很多團隊犯同一個錯：先在桌機上 benchmark，然後預設手機只是「慢一點」而已。不是。手機不是慢版桌機，它是完全不同的環境，有不同的記憶體上限、散熱限制、電池條件。你不照這些條件設計，功能就算 technically 能跑，也會讓人用到火大。

實操寫法是先算記憶體，再談模型大小。把目標裝置類型列出來，接著 profile 最大 context window、最重的 adapter、以及最糟的併發情境。如果你說不清楚記憶體去哪了，你根本不是在做 edge strategy，你是在賭運氣。

微調不該是有錢公司的奢侈稅

這篇文章最實際的地方，其實是成本。它一直在談 fine-tuning 的成本、多 GPU cluster 的成本，以及那種團隊已經把流程做下去，帳單才慢慢浮出來的煩躁。它也提到 PEFT 方法像 LoRA 和 QLoRA，這些東西的共同方向就是把模型適配變得沒那麼貴。

也就是說，模型客製不該只屬於 GPU 預算很鬆、還有一票 infra 人員待命的公司。如果你的任務有固定模式，你就應該能用比較輕的方式去適配，而不是為了改幾個行為去蓋一座小型資料中心。Tether 的說法是 QVAC Fabric 裡面有完整的 LoRA fine-tuning workflow，我在意的不是它時髦，而是它把「AI 訂閱制」往「可被你調整的工具」推了一步。

我看過團隊花在 prompt engineering、重試、人工覆核、以及各種補鍋工的成本，最後比直接做適配還貴。這種隱形稅最麻煩，因為它不會立刻出現在模型訓練報表上，只會出現在每個月的工時和情緒裡。如果一條較輕的 fine-tuning 路線能把這些浪費壓掉，它不只是省錢，是比較不會把人搞瘋。

• 任務模式穩定、輸出重複性高，就該考慮 adaptation。
• 用途還很廣、每週都在變，就先用 base model，不要急著訓練。
• 別只算訓練成本，人工清理成本通常更可怕。

實操寫法是替 fine-tuning 設門檻。如果你每週都在重寫 prompt 去修同一個行為，就把那段邏輯搬進可重用的適配流程。若資料敏感，本地 fine-tuning 會更有吸引力，因為原始資料不用先送進第三方服務。

delegated inference 才是我會先偷走的那一段

文章說 QVAC Workbench 支援透過 Pear 做 delegated inference，而 Pear 是建立在 Holepunch stack 上的 P2P runtime。例子很直白：你可以先在手機上開工，然後把重活交給家裡的桌機去跑。這個模式我很喜歡，因為它不是叫你接受某個雲端中繼站，而是讓裝置之間自己分工。

翻譯一下就是，裝置選擇變成工作流程的一部分，不再是硬限制。手機負責啟動任務，桌機負責收尾，可信裝置圖或本地網路負責路由。這比把所有工作都硬塞進同一台伺服器舒服多了，至少你不用為了單一架構圖去犧牲使用情境。

我以前做研究工作流時也碰過類似問題。資料不能亂跑，但我又希望出門時能繼續處理。最煩的不是模型本身，而是怎麼在裝置之間移交任務，還不能丟 state、不能洩漏資料。delegated inference 如果做得好，產品就不再像聊天機器人，而比較像一個分散式工作台。

實操寫法是先畫任務移動邊界。哪些任務可以在低功耗裝置上起手？哪些應該轉去更強的機器？哪些任務不管怎樣都必須留在本地？這些邊界先畫清楚，你才有辦法做出兼顧電池、隱私和算力的體驗，而不是讓使用者自己當調度員。

Workbench 和 Health 才讓這套東西看起來像真的要出貨

文章提到兩個已經建立在 QVAC 上的產品：QVAC Workbench 和 QVAC Health。我不太在意品牌名，我在意的是它們代表 Tether 想拿實際應用來證明這套堆疊。平台故事通常都在這裡分勝負，不是變成產品，就是變成簡報。

Workbench 被描述成一個 local-first AI assistant，能做排程、寫作、coding、研究。QVAC Health 則是偏私人的健康助理，把資料留在裝置上，還能用 OCR 掃檢驗報告、記錄 biomarker。這兩個情境差很大，但它們都靠同一個底層承諾：資料留在本地，模型也在使用者自己的裝置上跑。

也就是說，這不是單純的 library bundle，而是一種產品設計立場。如果這個堆疊能同時支撐工作助理和健康助理，那它想賣的就不是單一 app，而是一個應用層的基座。這比單點工具難賣，但如果真的能跑，實用度也高很多。

我對只存在於承諾裡的 AI 平台一向很保留，但當我看得到它想長出來的 app 長相，我就比較願意相信它。Workbench 告訴我它想碰一般生產力，Health 告訴我它想碰敏感個人資料。這兩個放在一起，本地優先架構就不再是興趣，而是產品需求。

實操寫法是，不要先講平台，先拿一兩個具體 app 把模式證明出來。底層可以做得很通用，但第一個版本一定要窄，窄到讓人一眼看懂這個架構到底值不值得信。

可抄的模板

# 本地優先 AI 產品模板，參考 QVAC 這種設計思路

## 1) 核心承諾
AI 任務先在使用者自有硬體上完成。
只有當任務無法在本地完成時，才送往雲端。

## 2) 架構
- 模型 runtime：可插拔 backend 的本地推理引擎
- 裝置目標：桌機 GPU、手機 GPU、CPU fallback
- 資料政策：預設原始使用者資料不離開裝置
- 同步政策：只同步衍生結果，不同步原始資料
- 任務移交政策：允許任務在可信裝置之間搬移

## 3) 必要模組
- inference
- adapter fine-tuning
- OCR
- transcription
- translation
- embeddings
- RAG
- text-to-speech
- delegated execution

## 4) 產品規則
- 每個 AI 功能都要寫清楚是否可離線
- 每個功能都要寫清楚最低裝置規格
- 每個功能都要寫清楚記憶體預算
- 每個功能都要寫清楚資料是否離開裝置

## 5) 實作清單
- 先選一個本地推理 runtime
- 定義支援的 GPU 和 fallback 路徑
- 先做 adapter-based customization，再考慮完整重訓
- 做一個可在裝置間移動的任務 queue
- 對任何同步的 metadata 做加密
- 先做一個窄應用，再擴成平台

## 6) 給產品規劃用的 prompt
你正在設計一個面向消費級硬體的本地優先 AI 功能。

請回傳：
1. 最小但有用的本地工作流
2. 必須支援的裝置類型
3. 記憶體與延遲預算
4. 哪些資料絕對不能離開裝置
5. 本地算力不足時的 fallback 行為
6. 哪一個 app 最能證明這個平台真的可用

## 7) 決策門檻
符合以下條件就先本地執行：
- 任務涉及隱私
- 任務重複頻繁
- 任務可接受裝置差異
- 使用者需要離線能力

以下情況才用雲端推理：
- 任務超過本地記憶體
- 任務需要共享的集中式 state
- 任務更適合伺服器級排程

如果我要把這篇文章的想法變成真的產品規劃，我會先拿這份模板開會。它逼團隊不要再含糊講什麼 edge AI，而是老實回答幾個很煩但很重要的問題：模型在哪跑、哪些裝置算數、哪些資料要留在本地、什麼時候我們真的得認輸改走別條路。

這份模板不花俏，但它的價值就是把架構講清楚，清楚到大家可以在浪費三個 sprint 之前先吵一輪。這種吵法，通常比事後救火便宜多了。

我會怎麼收尾

我把 Tether 這套 QVAC 拆下來之後，最有感的不是它有多會講 AI，而是它一直在逼你面對現實：硬體會碎、記憶體會爆、資料不想出門、使用者也不想每次都連雲。這些問題沒有一個靠口號能解。真正有用的，是把 runtime、記憶體、資料政策、任務移交都先寫死，然後再去談模型。

如果你也在做本地優先 AI，我會直接建議你先從模板開始，不要先從願景開始。願景很便宜，架構很貴。這篇我拆的是 Tether 的方法論，模板是我整理出來的可抄版本。

來源：TechCrunch sponsored article。文中的產品主張、模組與架構描述來自原始來源；模板、取捨與實作建議是我自己的整理與延伸。