Back to blog
    為什麼你的 AI 應用程式感覺很慢:網路延遲是瓶頸
    latencyUXmobile AIperformanceon-device AIsegment:mobile-builder

    為什麼你的 AI 應用程式感覺很慢:網路延遲是瓶頸

    AI API 呼叫為每次互動增加 500-3,000 毫秒的延遲。在行動裝置上,這就是使用者喜愛的功能和被棄用功能之間的差別。以下是時間耗費的位置以及如何解決。

    EErtas Team·

    你的 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,000ms50-200ms
    完整回應(100 token)2-5 秒1-3 秒
    離線失敗正常運作
    弱連線下的延遲3-10+ 秒與強連線相同
    一致性不穩定穩定

    差異在首個 token 上最為明顯。使用者感覺 50ms 是即時的。回應在點擊發送後「立即」開始出現。

    Token 生成速度

    現代行動硬體生成 token 的速度足以提供流暢的聊天體驗:

    裝置1B 模型3B 模型
    iPhone 15 Pro35-45 tok/s18-25 tok/s
    Galaxy S2435-45 tok/s18-25 tok/s
    iPhone 1320-30 tok/s10-15 tok/s
    中階 Android18-25 tok/s8-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 在本地運行。

    路徑如下:

    1. 衡量你目前的雲端 API 延遲(P50 和 P95)
    2. 識別哪些 AI 功能對延遲敏感(任何使用者需要等待回應的功能)
    3. 從你現有的 API 日誌中收集訓練資料
    4. 使用像 Ertas 這樣的平台微調領域特定模型
    5. 部署到裝置端並衡量延遲改善
    6. 在雲端和裝置端之間進行 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