Apple 把雲端 AI 拆成本機 AI

Apple 正把 Gemini 蒸餾成本機模型，並用 Nvidia 的 confidential compute 扛雲端備援。

我盯 Apple Intelligence 很久了，越看越覺得怪。表面上它一直講 on-device、講隱私、講個人化，聽起來像是 Siri 終於要長大了；但我實際看這些系統怎麼落地，常常只看到一堆補丁。這邊先本機跑一點，那邊再丟雲端補一點，模型太大就縮一縮，隱私說明則寫得像法務半夜沒睡。這次我看到 9to5Mac 的整理，才算把那股不對勁講清楚：Apple 不是在做單一路線，它是在把雲端 AI 拆成可在地端活下去的版本。

這篇內容的觸發點，是 9to5Mac 轉述 The Information 的 Aaron Tilley 報導，外加 Apple 自己的 Apple Intelligence 公開說法。重點不是功能清單，而是方法論：先把大模型壓縮成小模型，再用雲端和安全計算補上本機做不到的部分。這種做法很不浪漫，但很實際。

Apple 不是在做一個 AI，而是在做三層路由

Apple is using a version of Google’s large Gemini model to train a smaller version of the model that can run locally on Apple devices, a process known as distillation.

翻譯一下就是：Apple 不是只買一個 API 來接 Siri，它是在把 Gemini 當老師，訓練出一個能在 iPhone、iPad、Mac 上跑得動的學生模型。這不是「合作」兩個字能講完的事，這是模型轉移策略。老師很強沒錯，但真正要上線的是那個縮小版。

我自己看這種架構，第一個反應永遠不是「哇好強」，而是「終於承認單一模型根本扛不住」。因為只要你要低延遲、要便宜、還要能跟使用者說你很重視隱私，最後幾乎一定會走向分層：能在裝置上做的就留在本機，太重的才丟雲端，訓練階段再把大模型的行為蒸餾進小模型。

實操上，我會把這件事拆成三個問題：哪些任務可以本機完成？哪些任務必須雲端補算力？哪些任務根本不該做？如果你現在還在問「local 還是 cloud」，我會直接說，你問錯了。真正該問的是「這個任務能不能被壓縮成一個小而穩的本機能力」。

• 本機：短指令、重複任務、低延遲需求。
• 雲端：長上下文、複雜推理、高成本輸出。
• 蒸餾：把大模型的行為壓成可部署版本，不是把它整個搬過來。

Apple 這招厲害的地方，不是它多會做 AI，而是它把架構複雜度藏進產品敘事裡。對外還是能說「on-device first」，對內其實早就不是單一路徑了。這才是現實世界的 AI 產品，不是簡報上的 AI 產品。

蒸餾不是優雅，是在買時間

蒸餾聽起來像一個很漂亮的詞，像是工程師終於把雜訊去掉、留下精華。但我做過幾輪模型縮小之後，對這個詞的感受只有一個：它通常代表原模型太大，目標裝置太小，大家只好硬把行為擠進去。

報導裡還提到 Apple 有考慮像 Liquid AI 這種專門做模型壓縮和本機推論的公司。這點很關鍵。因為這不是周邊能力，這是核心能力。你要 Siri 在裝置上變得像樣，就不能只靠一個大語言模型團隊，你還得有一群人專門在處理量化、記憶體、延遲、裝置差異。

我之前做過一個把雲端模型往消費級硬體搬的案子，最慘的地方不是跑不動，而是跑得動卻不好用。團隊一直想保留太多原本的能力，結果本機模型越做越胖，最後既不快，也不穩，還不夠像原本那個模型。後來我們才醒過來：本機模型不是雲端模型的縮小版，它是另一個產品。

所以實操上，我會建議你先定義「最小可用任務」，再做蒸餾。不要把所有能力都想塞進去。你要的是一個小而可靠的本機助手，不是一個縮水後還是很笨重的遠端影子。

• 先切一個最窄的使用情境，不要先做萬用助手。
• 先量 latency 和 memory，再談品質分數。
• 本機模型的 UX 可以跟雲端版不同，不必硬裝成同一個樣子。

Apple 可以把這些複雜度包裝成產品策略，但一般團隊不行。所以如果你也在做 AI 功能，別急著說自己是 local-first，先把你到底要蒸餾什麼講清楚。講不清楚，後面只會一直加 patch。

雲端沒有消失，它只是被藏起來了

這篇報導最有意思的地方，是它直接把幻想戳破：很多查詢還是得靠雲端，因為完整的 Gemini 模型太大，Apple 自己的 Private Cloud Compute 也吃不下。這句話很現實，也很不討喜，但它是真的。

也就是說，裝置端只負責能負責的部分；真正重的推理、長上下文、昂貴運算，還是得送出去。報導提到這些工作會走 Google Cloud，這就更說明一件事：Apple 想要的是「本機優先」，不是「本機唯一」。

我一直覺得很多團隊在談隱私時，最愛把雲端講成暫時性的壞東西，好像只要再努力一點就能完全消失。實務上根本不是這樣。你只要產品有複雜推理、有大上下文、有多輪互動，雲端就很難真的消失。比較誠實的做法，是把它設計成一條明確的 fallback path。

Apple 這邊還會繼續掛著 Private Cloud Compute 這個名詞，意思不是它真的只有 Apple 自己的機器，而是它要把使用者的感受維持在「這條路徑是受控的」。從產品角度看，這比講伺服器在哪裡更有用；從工程角度看，這也更危險，因為一旦標籤跟實際拓撲脫節，就很容易出事。

實操上，如果你的 AI 功能有 cloud fallback，我會要求團隊把這幾件事寫死：

• 什麼條件會觸發雲端。
• 哪些資料會離開裝置。
• 雲端資料保留多久。
• 失敗時使用者會看到什麼。

不要把雲端當臨時補洞。大多數產品最後都會把它留著，只是你要不要老實設計而已。

Nvidia 的 confidential compute 是 Apple 的安全補丁

報導還提到 Apple 已經核准 Nvidia 的 confidential compute 技術，讓它能配合 Google Cloud 做部分處理。這個細節很有味道，因為它直接告訴你：Apple 不是不知道雲端有風險，它是知道，而且正在補。

confidential compute 的核心概念很直白：資料在雲端處理時，盡量讓運算過程維持在受保護的環境裡。不是假裝雲端不存在，而是承認雲端一定會碰到敏感資料，所以要把風險壓低。這種做法比空講隱私實際多了。

我其實滿喜歡這種路線，因為它不裝。它承認一件事：只要資料離開裝置，信任成本就會上升。你不能只靠 slogan 解決，得靠技術控制。當你把 AI 工作負載丟到第三方雲端時，至少要回答：雲端營運者能不能看到資料？hypervisor 能不能碰到？硬體層能不能隔離？如果答案是會，那 confidential compute 就不是加分題，是及格線。

當然，這也有代價。報導提到這類技術會讓處理稍微慢一點。正常，安全不是免費的。Apple 願意吞這個成本，因為它知道另一個選項更糟：一個看起來很快、但隱私故事站不住腳的 Siri，這種東西才真的難收拾。

實操上，我會這樣設計：

• 敏感 prompt 或模型權重碰到第三方雲端時，優先用隔離運算。
• 接受一點延遲，換取可說明的信任邊界。
• 不要只測 happy path，要測 fallback 和 failure mode。

Apple 做的不是「雲端 vs 隱私」，而是「有控制的雲端 vs 靠祈禱的雲端」。這兩者差很多。

Private Cloud Compute 可能變成標籤，不再是地點

報導說 Apple 可能還會沿用 Private Cloud Compute 這個品牌，但下一波 Apple Intelligence 功能不會只跑在 Apple 自己的伺服器上。這件事看起來小，實際上很大。

翻譯一下就是：這個詞正在從「硬體在哪裡」變成「資料怎麼被保護」。Apple 不太想讓使用者去想什麼 Google Cloud、什麼 Apple server、什麼 region。它想讓使用者只記得一件事：這條路徑是 Apple 定義過的隱私路徑。

我懂這個操作，因為大多數使用者真的不在乎拓撲。他們在乎的是資料有沒有被亂看、亂存、亂傳。但對開發者來說，這種品牌化很容易偷渡架構漂移。今天你說 Private Cloud Compute，明天後端換成多個供應商，後天又多一層代理，結果名字還在，契約已經鬆了。

我做過最痛的事之一，就是看一個很漂亮的產品名，最後在事故排查時變成一團亂。每個人都以為自己講的是同一件事，結果實際上各自指向不同的 backend。Apple 如果要讓這個名詞繼續站得住，就得把技術約束寫得很死。

實操上，如果你也有一個 privacy-forward 的功能名，請先回答這些問題：

• 它是不是只代表沒有人工審閱？
• 它是不是也代表不長期保存？
• 它是不是包含傳輸與靜態加密？
• 它是不是包含隔離運算？

名稱可以沿用，但技術契約不能偷換。Apple 做得到，不代表你也可以偷懶。

這件事最後其實是在救 Siri

這份報導真正有意思的地方，不是 Siri 會講什麼新話，而是 Apple 終於承認：要讓 Siri 可用，不能只靠一個大模型，也不能只靠一個雲端端點。你得有多層模型、多層算力、還有多層供應商。

我覺得這才是開發者最該學的地方。真正能活下來的 AI 架構，通常不是最漂亮的那個，而是最會分流的那個。哪些東西留在本機，哪些東西上雲，哪些東西根本不做，這些決策比你 prompt 寫得多漂亮更重要。

所以如果你現在也在做 AI 助手，我會很直接地建議你：先畫 request flow，再寫 prompt。把本機路徑、雲端路徑、失敗路徑、隱私控制全部畫出來。畫不出來，就代表你還沒真的搞懂系統。

Apple 這套做法不乾淨，老實說一點都不乾淨。但乾淨不一定能出貨，能活下來才是重點。這就是我看完這篇報導後最確定的一件事。

可抄的模板

# local-first AI with cloud fallback template

## 目標
把 AI 功能設計成「本機優先、雲端備援」，讓常見任務在裝置上完成，重任務再升級到雲端。

## 模型分層
- Local model：由大模型蒸餾而來，負責低延遲、重複性高的任務
- Cloud model：負責長上下文、複雜推理、重成本輸出
- Teacher model：只用在訓練與蒸餾階段

## 路由規則
1. 預設先走本機模型
2. 如果信心分數不足、上下文太長、或輸出成本過高，轉雲端
3. 能不做的任務就不要做，不要硬塞進 assistant

## 隱私控制
- 裝置到雲端全程加密
- 敏感工作負載使用 confidential compute 或等效隔離機制
- 不做不必要的長期留存
- 明確列出哪些資料會離開裝置

## 產品說法
- 只有當每條 backend path 都符合相同技術契約，才可以用 privacy-forward 的命名
- 不要只說「private」，要寫清楚 private 的定義
- 品牌可以簡化，但技術契約不能模糊

## 工程檢查清單
- [ ] 測本機 latency
- [ ] 測本機 memory footprint
- [ ] 測雲端 fallback 條件
- [ ] 測 confidential compute 或等效隔離
- [ ] 寫 failure mode 文件
- [ ] 定義雲端保留策略
- [ ] 定義使用者在切換路徑時會看到什麼

## Request flow 範例
1. 使用者送出 prompt
2. 本機模型先處理
3. 若信心不足或上下文過大，轉雲端
4. 雲端在受控環境下處理
5. 結果回到裝置
6. 只記錄必要的 debug 資訊

## 蒸餾內部指令
你現在要把一個大型 teacher model 的能力縮成可在裝置上跑的 assistant。
優先順序：
- 低延遲
- 低記憶體
- 行為穩定
- 可接受的隱私邊界

降優先順序：
- 冗長輸出
- 過度泛化
- 需要 always-on cloud 的能力
- 為了炫技而保留的邊角功能

## 決策規則
如果任務能在本機達到可接受品質，就留在本機。
如果不能，就送雲端，並附上明確的隱私控制。
如果兩邊都不行，就先別上線。

原始素材來自 9to5Mac 轉述的 Aaron Tilley／The Information 報導，以及 Apple 的官方頁面；上面的架構拆解和模板是我根據這些來源整理出的實戰版本，不是逐字轉寫。