
為什麼你的 AI 應用程式感覺很慢:網路延遲是瓶頸
AI API 呼叫為每次互動增加 500-3,000 毫秒的延遲。在行動裝置上,這就是使用者喜愛的功能和被棄用功能之間的差別。以下是時間耗費的位置以及如何解決。
你的 AI 功能運作正常。模型很好。提示詞已經調校過。但使用者形容它「很卡」。他們盯著載入動畫等待 2-3 秒才看到任何回應。在行動裝置上,這是一段漫長的等待。
問題不在模型。而是使用者手機和執行推理的雲端伺服器之間的網路往返時間。
時間花在哪裡
從行動裝置進行典型的雲端 AI API 呼叫包含以下步驟:
| 步驟 | 時間 | 備註 |
|---|---|---|
| DNS 解析 | 10-50ms | 首次呼叫後快取 |
| TCP + TLS 交握 | 50-150ms | 每次連線(連線重用有幫助) |
| 請求上傳 | 20-100ms | 取決於負載大小和頻寬 |
| 伺服器佇列等待 | 50-500ms | 因供應商負載而異 |
| 模型推理(TTFT) | 200-1,500ms | 首個 token 時間,取決於模型 |
| 回應下載(首個 token) | 20-50ms | 網路傳輸 |
| 首個 token 的總時間 | 350-2,350ms |
在良好的連線下,你可能看到 500ms。在行動網路上,1-2 秒。在弱連線下(電梯、地鐵、偏遠地區),3 秒以上或逾時。
複合效應
這些延遲在每一次互動中都會出現。與雲端 API 的 5 輪對話意味著使用者等待 5 次。每次等待都強化了「這個功能很慢」的感受。在 3-4 次互動後,許多使用者就會完全停止使用該功能。
Google 的研究發現,53% 的行動使用者會放棄載入時間超過 3 秒的頁面。AI 功能面臨相同的門檻,但標準更高,因為使用者會將 AI 回應時間與應用程式中其他所有 UI 元素的即時回饋進行比較。
為什麼行動裝置比桌面更糟
呼叫 AI API 的桌面應用程式有結構性優勢:它們通常在穩定的 WiFi 或乙太網路連線上運行。行動裝置增加了多層延遲:
行動網路的變動性: 4G 延遲平均 50-100ms,但在擁塞時飆升到 300-500ms。5G 在理想條件下表現更好,但實際上並不穩定。
連線切換: 在 WiFi 和行動網路之間切換(進出建築物)可能導致 1-2 秒的中斷,等待連線重新建立。
前景/背景轉換: iOS 和 Android 在應用程式進入背景時會暫停網路連線。當使用者返回時,連線可能需要重新建立。
地理距離: API 伺服器通常位於美國東部或美國西部。東南亞、非洲或南美洲的使用者會增加 100-300ms 的純網路傳輸時間。
UX 影響
載入動畫扼殺參與度
每個載入動畫都是使用者可能決定做其他事情的瞬間。在行動裝置上,「其他事情」只需一個滑動就能到達。應用程式切換器始終可用。
多個行動團隊的 A/B 測試顯示,延遲超過 1 秒的 AI 功能與亞秒級功能相比,完成率低了 30-40%。功能運作完全相同。唯一的差別是感知速度。
串流有幫助,但有限制
逐 token 串流(Server-Sent Events)透過在生成時顯示輸出來降低感知延遲。使用者很快就能看到前幾個字,這給人回應靈敏的印象。
串流改善了體驗但沒有消除問題:
- 首個 token 時間仍然是 500-2,000ms
- 在弱連線下,SSE 串流會緩衝,產生明顯的卡頓
- 每個串流區塊都增加了自身的網路開銷
離線落差
最糟糕的延遲是無限大。當使用者沒有連線時,雲端 API 什麼也不回傳。功能完全中斷。
這在行動裝置上不是邊緣案例。使用者經常在地鐵、電梯、飛機、地下室、偏遠地區和沒有數據連線的國際地點。在這些時刻功能失效會訓練使用者不去依賴它。
裝置端替代方案
裝置端推理完全消除了網路延遲。模型在使用者的手機上運行。從輸入到輸出的路徑永遠不會接觸網路。
| 指標 | 雲端 API | 裝置端 |
|---|---|---|
| 首個 token 時間 | 500-2,000ms | 50-200ms |
| 完整回應(100 token) | 2-5 秒 | 1-3 秒 |
| 離線 | 失敗 | 正常運作 |
| 弱連線下的延遲 | 3-10+ 秒 | 與強連線相同 |
| 一致性 | 不穩定 | 穩定 |
差異在首個 token 上最為明顯。使用者感覺 50ms 是即時的。回應在點擊發送後「立即」開始出現。
Token 生成速度
現代行動硬體生成 token 的速度足以提供流暢的聊天體驗:
| 裝置 | 1B 模型 | 3B 模型 |
|---|---|---|
| iPhone 15 Pro | 35-45 tok/s | 18-25 tok/s |
| Galaxy S24 | 35-45 tok/s | 18-25 tok/s |
| iPhone 13 | 20-30 tok/s | 10-15 tok/s |
| 中階 Android | 18-25 tok/s | 8-12 tok/s |
在每秒 20 個以上的 token 下,文字看起來流暢地串流。在每秒 10 個以上的 token 下,文字可讀且可用。兩者都超過了舒適聊天體驗的門檻。
衡量影響
追蹤這些指標來量化你應用程式中的延遲問題:
P50/P95 首個 token 時間: 中位數告訴你典型的體驗。P95 告訴你最差 5% 使用者在每次互動中的體驗。如果 P95 超過 3 秒,5% 的使用者在每次互動中都有糟糕的體驗。
功能完成率: 有多少百分比的使用者開始 AI 互動後會完成它(等待並閱讀回應)?將此與你應用程式中的非 AI 功能進行比較。
重試率: 使用者多常再次點擊「發送」,因為他們認為第一次請求失敗了?高重試率表示感知逾時。
AI 功能留存率(D7/D30): 嘗試過 AI 功能的使用者是否會回來再次使用?高初次嘗試率但低留存率暗示 UX 問題,而延遲是最常見的原因。
解決方案
架構層面的解決方案是將推理移到裝置端。微調一個小型模型(1-3B 參數)以適應你的特定任務,匯出為 GGUF,並透過 llama.cpp 在本地運行。
路徑如下:
- 衡量你目前的雲端 API 延遲(P50 和 P95)
- 識別哪些 AI 功能對延遲敏感(任何使用者需要等待回應的功能)
- 從你現有的 API 日誌中收集訓練資料
- 使用像 Ertas 這樣的平台微調領域特定模型
- 部署到裝置端並衡量延遲改善
- 在雲端和裝置端之間進行 A/B 測試使用者參與度
僅延遲的改善往往就能帶來可衡量的功能參與度提升。當你加上離線支援和成本消除,這個論點就變得毫無疑問。
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

Fine-Tuning vs RAG for Mobile: Why RAG Still Needs a Server
RAG is the go-to solution for giving AI domain knowledge. But on mobile, RAG reintroduces the server dependency you are trying to eliminate. Fine-tuning bakes the knowledge into the model itself.

On-Device AI Unit Economics: The Math That Makes Mobile AI Profitable
The complete unit economics breakdown for on-device AI vs cloud APIs. Fixed costs, variable costs, break-even analysis, and the financial model for scaling mobile AI features profitably.

AI Features Mobile Users Actually Want (2026)
Research-backed list of AI features that drive retention and engagement in mobile apps. What users want, what they ignore, and how to prioritize AI features based on actual behavior data.