Featured Teardown · Strategy Signature № 02 · STEADY-PULSE

Apple Intelligence 結合 Gemini:端側與雲端混合路由的實作啟示Apple Intelligence Meets Gemini: Practical Lessons from Hybrid On-Device and Cloud Routing

蘋果在 WWDC 2026 宣布 Apple Intelligence,並選擇整合 Google Gemini 來處理複雜任務。這標誌著「端側小模型 + 雲端大模型」的混合路由 (Hybrid Routing) 架構正式成為業界標準。沒有一間公司能全靠端側模型解決所有問題,也沒有人想把所有請求都送上雲端燒錢。

At WWDC 2026, Apple announced Apple Intelligence and opted to integrate Google Gemini for complex tasks. This marks the "on-device small model + cloud large model" hybrid routing architecture as the official industry standard. No company can solve everything exclusively with on-device models, and nobody wants to burn money sending every request to the cloud.


混合路由為什麼是必然趨勢?

混合路由架構圖

在個人或企業的 Self-host 方案中,我們常面臨兩難:本地模型(如 Llama 3 8B 或 Gemma)便宜且保密,但遇到長文本推理或程式碼重構時能力不足;雲端大模型(如 Claude Sonnet)能力極強,但將所有日常對話、日誌分析都送上雲端,成本與延遲又難以承受。因此,一個聰明的「路由器」就成了關鍵。

Why Hybrid Routing is Inevitable

Hybrid routing architecture diagram

In personal or enterprise self-hosted solutions, we often face a dilemma: local models (like Llama 3 8B or Gemma) are cheap and private but lack capability for long-context reasoning or code refactoring; cloud large models (like Claude Sonnet) are extremely capable, but sending all daily chats and log analyses to the cloud incurs unbearable costs and latency. Therefore, a smart "router" becomes the key.


實驗設計:實作一個本地意圖路由器

實驗程式碼片段

為了驗證混合架構的效益,我們寫了一個簡單的 Python Router。這個 Router 會先攔截使用者的請求,透過極輕量的方式判斷意圖: 如果是「文字整理、總結、格式轉換」,就交由本地的 gemma4:e2b 處理;如果是「資料爬蟲、複雜數學、程式碼除錯」,則 mock 呼叫外部 API (例如 Gemini 或 Claude)。我們記錄了兩種策略的延遲與成本差異。

Experiment Design: Implementing a Local Intent Router

Experiment code snippet

To verify the benefits of a hybrid architecture, we wrote a simple Python Router. This Router intercepts user requests and uses a lightweight method to determine intent: If it's "text formatting, summarization, or translation," it hands it to the local gemma4:e2b; if it's "web scraping, complex math, or code debugging," it mocks an external API call (like Gemini or Claude). We recorded the latency and cost differences between the two strategies.


實驗結果:成本與延遲的最佳平衡

效能與成本對比表格

結果非常明顯。藉由第一層的意圖過濾,我們成功將 70% 的日常瑣碎請求留在本地端處理,這讓整體 API 呼叫成本急遽下降。雖然本地處理的延遲比直接呼叫雲端稍微高一點點(受限於個人 Mac 的算力),但考量到完全的隱私與零訂閱費,這個交易非常划算。

Experiment Results: The Perfect Balance of Cost and Latency

Performance and cost comparison table

The results are striking. By using a first-layer intent filter, we successfully kept 70% of mundane daily requests on the local machine, causing overall API call costs to plummet. While local processing latency is slightly higher than direct cloud calls (limited by a personal Mac's compute power), considering total privacy and zero subscription fees, the trade-off is incredibly worthwhile.


決策框架

選用混合路由 (Hybrid Routing) 當:

  • 你有穩定的本地算力(例如 Mac M 系列或具備中等顯卡的 PC)
  • 你的任務有明確區分:一部分高度涉及機密隱私,另一部分需要強大推理
  • 你希望控制 API 支出,並願意承擔少量系統維護成本

選用純本地端 (Local Only) 當:

  • 處理極度敏感資料(如病歷、內部商業機密)
  • 運作於離線或高安全性的隔離網段

選用純雲端 (Cloud Only) 當:

  • 終端設備算力極弱(如輕薄筆電或手機)且沒有本地伺服器
  • 任務 100% 需要頂尖的邏輯推理能力,無關緊要的請求極少

Decision Framework

Choose Hybrid Routing when:

  • You have stable local compute (e.g., Mac M-series or a PC with a decent GPU).
  • Your tasks are clearly segregated: some highly confidential, others requiring powerful reasoning.
  • You want to control API expenses and are willing to bear minor system maintenance costs.

Choose Local Only when:

  • Processing highly sensitive data (e.g., medical records, trade secrets).
  • Operating in offline or highly secure isolated networks.

Choose Cloud Only when:

  • Endpoint devices have very weak compute (e.g., thin laptops or phones) with no local server.
  • Tasks are 100% reliant on top-tier logical reasoning, with very few trivial requests.