
为什么你的 AI 应用感觉很慢: 网络延迟是瓶颈
AI API 调用为每次交互增加 500-3,000ms 的延迟。在移动端,这是用户喜爱和放弃一个功能之间的差距。时间花在哪里,以及如何解决。
你的 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 的纯网络传输时间。
用户体验影响
加载动画扼杀参与度
每个 加载动画都是用户可能决定去做其他事情的时刻。在移动端,"其他事情"只需一次滑动。应用切换器随时可用。
多个移动团队的 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.