适用读者：要评估"加个模型要多久"、要拆 TTFT 之外的网络与设备时间、要做端云分工的人。
前置：S23-J22（TTFT）、J14（传输时间）、J21（重叠）。
覆盖旧文：A-4345 §12.1–§12.2（完整交互时间 + 跨设备分工，364 点）→ 364 点。
扩展点：E-S23-114（串行公式：12.8 s，压缩交叉点 800 Mbit/s）、E-S23-115（分块重叠只省 0.4 s：12.8 → 12.4）、E-S23-116（语音流水线递推：一块迟到 5 ms 就全推后）、E-S23-117（端/边/云分工判据）。
上一篇：S23-J30 · 调度、服务成本与扩容
下一篇：S23-J32 · 广域网、无线与端边云部署。
1. 一句话结论
用户感知的时间不是模型时间，是"传输 + 处理 + 传输"。 30 MB 原图、上行 20 Mbit/s：上传 12 s，处理 0.3 s——模型再快 10 倍也没用。压缩省 15 MB 在 20 Mbit/s 下省 6 s，在 800 Mbit/s 下省 0——同一种优化，收益由链路决定。
出处：AI Infra 教材 §12.1–§12.2（
id 4345）。
T_serial = S_u/B_u + R + T_c + S_d/B_d
2. 串行公式与各段（E-S23-114）
图片精修：输入 30 MB、输出 5 MB、上行 20 Mbit/s、下行 100 Mbit/s、RTT 0.1 s、处理 0.3 s。
| 段 | 计算 | 时间 |
|---|---|---|
| 上传 | 30 MB × 8 / 20 Mbit/s |
12.0 s |
| 传播（往返） | RTT | 0.1 s |
| 处理 | — | 0.3 s |
| 下行 | 5 MB × 8 / 100 Mbit/s |
0.4 s |
| 合计 | — | 12.8 s |
判据："缩小文件"只缩短发送时间，不影响传播与处理。 而发送时间在慢上行上是绝对主导——这就是端侧预压缩的价值来源。
2.1 压缩的收益边界
ΔT = (S_u − S'_u)/B_u − T_e
压缩把输入减半（省 15 MB）、额外编解码 0.15 s：
| 上行速率 | 省下的发送时间 | 净收益 |
|---|---|---|
| 20 Mbit/s | 6.0 s | +5.85 s |
| 100 Mbit/s | 1.2 s | +1.05 s |
| 800 Mbit/s | 0.15 s | 0（交叉点） |
交叉点：B_u = 15 MB×8 / 0.15 s = 800 Mbit/s
判据：同一个压缩算法，在慢网上是刚需、在快网上是浪费。 是否上压缩要按目标用户的实际上行带宽定。
2.2 分块重叠能省多少（E-S23-115）
三块、每块上传 4 s、处理 0.1 s、回传 0.08/0.16/0.16 s：
| 方案 | 完成时刻 |
|---|---|
| 整图串行 | 12.8 s |
| 分块流水 | 12.4 s |
前两块的处理与回传藏在后续上传里；但最后一块仍要等第 12 s 才发完
→ 节省只来自"处理+回传"那 0.4 s，上传的 12 s 无法压缩
判据：重叠只能省"可重叠的那部分"。 上传是串行瓶颈时，分块只是把尾巴削掉。
3. 实时语音：流水线递推（E-S23-116）
c_i = max(a_i, c_{i−1}) + m_i 处理完成
u_i = max(c_i, u_{i−1}) + s_i 发送完成
r_i = u_i + d_i 到达
参数：24 kHz、单声道、16-bit PCM → 20 ms 块 = 960 B；处理 12 ms、发送 1 ms、传播 5 ms。
| 块 | 就绪 | 处理完 | 发完 | 到达 | 播放 |
|---|---|---|---|---|---|
| 1 | 20 | 32 | 33 | 38 | 78（+40 ms 缓冲） |
| 2 | 40 | 52 | 53 | 58 | 98 |
每块处理 12 ms < 采集间隔 20 ms → 处理跟得上
故障：第 3 块传播变成 50 ms → 到达 123 ms，而原定播放 118 ms → 晚 5 ms，之后所有块顺延。
| 资源 | 跟不上时的现象 |
|---|---|
| 采集 | 丢块/降采样 |
处理（m>20 ms） |
队列增长，延迟累积 |
发送（s 变大） |
出口排队 |
| 传播（抖动） | 晚到一块，全体顺延 |
判据：流式交互的指标是"首段时刻 + 连续性"，不是"总时长"。 一次抖动就破坏连续性，缓冲就是为它付的保险费。
4. Computer Use 与端侧执行（§12.1.3–12.1.5）
| 环节 | 延迟构成 | 优化点 |
|---|---|---|
| 截图上传 | 图像大小 / 上行 | 降分辨率、只传变化区域 |
| 模型决策 | TTFT + decode | 小模型先行、批处理 |
| 动作下发 | 小消息 + 传播 | 连接复用 |
| 页面等待 | 外部系统（不受控） | 超时、重试、并行 |
判据：Computer Use 的瓶颈常在"等别人"——页面加载、应用响应不在你的优化范围内，只能靠超时与并发绕开。
端侧 vs 云（§12.1.4–12.1.5）：
| 维度 | 端侧 | 云 |
|---|---|---|
| 首 token | 无网络往返 | 加 RTT |
| 算力/显存 | 受限（手机几 GB） | 可扩 |
| 隐私 | 数据不出设备 | 需合规 |
| 成本 | 用户设备 | 按量 |
5. 跨设备分工（§12.2）
| 方案 | 传输量 | 适用 |
|---|---|---|
| 完整调用 | 输入 + 输出 | 简单、端侧太弱 |
| 端侧编码 | 只传 embedding/特征 | 带宽紧、隐私敏感 |
| 会话迁移 | 状态（KV） | 换设备续聊 |
| 模型内部切分 | 每层激活 | 端云协同推理（通信边界同 J25） |
端侧编码的账（§12.2.2）：把原始输入换成小得多的中间表示，省上行；代价是端侧要跑编码器（算力、功耗）。判据同压缩：省下的传输时间 > 端侧编码时间才划算。
6. 可复算（实测）
$ cd /root/博客运营官/blog-v2 && python3 tools/s23_book_calc.py | tail -10
图片: 12.0 上传 + 0.1 RTT + 0.3 处理 + 0.4 下行 = 12.8 s
压缩省 15 MB: 20 Mbit/s → 6.0 s；100 → 1.2 s；800 → 0.15 s（= T_e，交叉点 800 Mbit/s）
分块流水: 12 + 0.1 + 0.16 + 2×0.05 = 12.36 ≈ 12.4 s（只省 0.4）
语音: 960 B/块；块 1 就绪 20 / 处理 32 / 发 33 / 到 38 / 播 78
第 3 块传播 50 ms → 到达 123 ms > 118 ms（晚 5 ms，全体顺延）
窗口: W=64 KB, R=0.1 s → 5.1 Mbit/s（路径 20）；30 MB 需 47 s
填满需 250 KB 在途；整批确认 25.6 ms + 100 ms = 125.6 ms/批
慢启动: 10×1460 B，4 轮 219,000 B；5 轮 452,600 B（355 KB 需 5 轮）
跨地域语音: 8.5 + 200 + 30 = 238.5 ms（理想）；直接 >1000 ms；优化后约 300 ms
7. 前提与边界
| 结论 | 成立条件 | 不成立时 |
|---|---|---|
T_serial |
各段串行、连接已建 | 重叠/流水 → 用 max |
| 压缩交叉点 800 Mbit/s | 编解码 0.15 s、省 15 MB | 参数变 → 重算 |
| 分块省 0.4 s | 上传是瓶颈 | 处理是瓶颈 → 省更多 |
| 语音 78 ms 起播 | 缓冲 40 ms | 缓冲更小 → 更易断续 |
8. 常见误区
| 误区 | 纠正 |
|---|---|
| "模型快了，体验就好了" | 上传 12 s 占 94% |
| "压缩一定省时间" | 800 Mbit/s 以上省 0 |
| "分块上传能大幅加速" | 只省 0.4 s（3%） |
| "延迟高就加缓冲" | 缓冲换连续性、加起播时间 |
| "端侧一定更快" | 端侧算力弱，可能更慢 |
9. 自测
- 30 MB 上行 20 Mbit/s、5 MB 下行 100 Mbit/s、RTT 0.1、处理 0.3，总时间？
- 压缩省 15 MB、编解码 0.15 s，上行多快时收益归零？
- 语音 20 ms 块、处理 12 ms、发送 1 ms、传播 5 ms、缓冲 40 ms，第一块何时播放？
- 第 3 块传播变 50 ms，会怎样？
答案
12 + 0.1 + 0.3 + 0.4 = 12.8 s。15 MB×8/0.15 s = 800 Mbit/s。- 就绪 20 → 处理完 32 → 发完 33 → 到达 38 → 78 ms 播放。
- 到达 123 ms > 原定 118 ms，晚 5 ms 且之后全部顺延。
10. 下一篇
S23-J32 · 广域网、无线与端边云部署 —— 连接建立与复用、窗口与有效吞吐、丢包不等于拥塞、多流与优先级，以及共享空口、过期数据与双路径切换。