从模型运行时间到完整交互时间
端侧采集输入、与用户交互；边缘是附近的工作站或服务节点；云端是远程资源池。终端可以本地执行，可以调用附近或云端服务，也可以把模型的不同阶段分给不同设备。远端能把模型算得更快，调用远端也会增加传输和等待。
12.1.1 图片精修：先算各段时间
条件：连接已建立，服务器收齐原图后才处理，生成完整成片后再发回；上下行以恒定速率传有效载荷；RTT 只算往返传播（排队和协议处理放到 12.3 节）。
上传占 12 秒、约 94%；处理只占约 2.3%。按 Amdahl 定律，处理再快，总时间最多也只能缩短这 2.3%。
图 12-1 / 12-2 · 图片精修预算
MB 与 Mbit 均为十进制图 12-2：横轴为对数坐标。上行越快，压缩省下的发送时间越少；同一种压缩的运算量没变，变的是发这些字节要多久。虚线是当前上行速率。
图 12-3 / 12-4 · 分块能重叠多少
三块各上传 4 s，到达后独立处理 0.1 s，再回传 1、2、2 MB（0.08、0.16、0.16 s）；单向传播 0.05 s。前两块的处理和回传藏进了后续上传，但第 12 秒前最后一块还在上传，这 12 秒压不掉。若处理需要全局曝光或跨块信息，就必须等整图到齐，分块发送也还是 12.8 秒。
计算量和数据量决定各步骤要多久，依赖关系决定它们能否同时进行。
12.1.2 实时语音：看首段何时响、后面是否连续
流式 ASR / TTS 一边收输入一边出结果。采集端每 20 ms 产生一块，模型逐块处理，网卡逐块发送，播放器按序播放：
第一个 max 是数据依赖（等输入就绪），第二个是资源竞争（等出口空闲），播放的 max 是“本块到了”和“上一块播完”两个条件。24 kHz、单声道、16-bit PCM，20 ms 一块 960 bytes。
图 12-5 / 12-6 · 一块晚到，后面全部推迟
绿＝处理，蓝＝发送，橙＝传播，灰＝到达后在缓冲里等，黑＝实际播放，虚线框＝原定播放时段。播放器等缺块、不丢弃。把 J 调到 45 ms，第 3 块刚好赶上，代价是首段晚 5 ms 响。处理拉到 20 ms 以上，处理跟不上采集，延迟会逐块累积。
图 12-7 · 缓冲挡得住抖动，挡不住长期速率不足
缓冲量 = 初始数据 + 累计接收 − 累计播放。缓冲加倍只抬高起点，斜率不变，耗尽时刻按比例推迟。只有提高传输速率或降低音频码率，收到的数据才够播。
12.1.3 Computer Use：每轮的等待会累积
程序像用户一样截图、点击、输入。和音频流水线不同：上一轮操作完成、界面更新后，才拿得到下一张有效截图，所以各轮很难重叠。
图 12-8 · 一轮截图 Agent
方框宽度不代表耗时。底部返回箭头要经过“执行操作”和“更新界面”，才能拿到第 v+1 版截图。
例 · 截图压缩能否抵消额外轮次
文字变糊会让 Agent 多做纠错。另一类无效轮次来自旧截图：模型读到版本 v，界面已经变了。把截图版本和动作编号绑定，界面一变就重新截图，可以避免这类白做的工作。
12.1.4 本地、附近与云端的初步比较
| 分析层次 | 计算对象 | 已得到的判断 |
|---|---|---|
| 各步骤耗时 | 计算、发送、传播各需多久 | 原图上传占 12 秒，模型占 0.3 秒 |
| 执行依赖 | 哪些工作可以重叠，哪些必须等 | 独立图片块可重叠；下一轮截图要等上一轮操作完成 |
| 实际执行 | 数据就绪后，计算和发送何时开始 | 平均速率够，一次晚到仍会让音频停顿 |
交给远端时，省下的计算时间必须超过上传、下载、传播、排队和准备增加的时间。多轮任务的准备只做一次，通信却每轮都发生。
最短传播先排除太远的服务器
光纤中约 2×10⁸ m/s12.1.5 端侧执行资源：带宽、容量、能耗
12.5 节要用到“端侧每轮模型计算 2.9 秒”。它的来源是三个下界：内存带宽决定每生成一个 token 至少要多久，内存容量决定能装下什么模型、留多长上下文，能耗与电池决定能持续多久。
图 12-9 · 读一遍 decode 载荷要多久
Qwen3-8B · 单请求 8K · 权重 15.14 GB + KV 1.21 GBSnapdragon 8 Elite 支持 LPDDR5X 5,300 MHz（每引脚 10.6 Gbit/s），未给总线宽度，书中按四条 x16 计。q4_0 每 32 个 BF16 值从 64 bytes 变为 18 bytes。MELTing Point 在 iPhone 14 Pro 上实测 Zephyr-3B q4_k 14.8 token/s、Llama-2 7B q3_k 6.0 token/s，量级一致。M3 Ultra（819 GB/s）与 RTX PRO 6000（1,792 GB/s）取自第 4.8.2 节。
容量：装下权重后，剩多少给上下文
系统与工作区预留 4 GB · KV 每 token 147,456 bytesBF16 权重常驻 16.38 GB，比每步读取的 15.14 GB 多出约 1.24 GB 词嵌入表：decode 每步只查一行，整张表却要留在内存里。6 GB 一档装不下 8B，3B 级 q4 模型约 1.7 GB 可以装下。
能耗：持续功率与电池
MELTing Point 实测每 token 0.16–0.21 mWh，即 0.576–0.756 J（含整机功耗）；H100 上只算数据搬移与矩阵计算约 0.534 J/token。14.8 token/s × 0.576 J ≈ 8.5 W，在 13.8 W 之内。一次充电约 490–590 个提示。
翻转条件：期限反推每轮 token 预算
运行时只决定离下界多远
llama.cpp：GGUF 分组量化布局决定容量与每步读取量。Ollama：分发与本地服务封装，省的是部署准备时间。MLX：Apple 统一内存，CPU/GPU 不拷贝，容量上限即整机内存。Unsloth：把微调状态压进一张卡。四者都不改变带宽与容量下界。RTX PRO 6000 上一步 decode 实测是读取下界的 2.83 倍，多出的主要是每步固定开销。
LoRA 省的是训练状态，不是带宽
| 显存 | 全参 Adam 16 B/参数 | BF16 基座 + rank-16 Q/V LoRA |
|---|---|---|
| 24 GB（RTX 4090） | 约 1.5B | 约 12B；Qwen3-8B 需约 16.5 GB |
| 96 GB（RTX PRO 6000） | 约 6B | 约 48B |
Qwen3-8B 全参训练状态 131.1 GB；LoRA adapter 14.6 MiB、约 765 万参数，加状态约 0.12 GB。
跨设备分工
同一张截图，可以先发给服务器再编码成特征，也可以在终端编码后再发特征。两条路径跨网络的对象不同。图片压缩用较少字节表示纹理和重复区域，是为了紧凑存储；视觉编码器把图片展开成每个视觉 token 的通道值，是为了后续计算。
端侧先做了计算，并不保证上传量减少。后续语言模型计算两边相同，只需比较两边的编码时间和图片 / 特征的发送时间。
图 12-10 / 12-11 · 编码器放在哪一边
Qwen3-VL-4B 固定配置：预处理到 640×640，合并后 400 个视觉 token，每个 token 4 × 2560 个 BF16 数。编码一张图 1.31 TFLOPs：RTX 4090（165.2 TFLOP/s）约 7.9 ms，H100 SXM（989.4 TFLOP/s）约 1.3 ms。慢链路上先比传输量；同机房 400 Gbit/s 链路上两者发送时间只差约 0.15 ms，这时要比编码和排队。
图 12-13 · 缓存越靠后，省的计算越多，要传的也可能越大
该配置每个语言模型输入 token 需 144 KiB 逻辑 KV，400 个视觉 token 约 56.3 MiB。KV 只在模型权重、前缀和 token 位置索引都匹配时可用。多轮任务里相同图片再出现时命中 EC 省一次编码，界面变了就要重编；编码总时间 = 单次编码 × 未命中次数。
12.2.3 会话迁移：一次准备，多轮回本
图 12-14 · 至少还要几轮，迁移才划算
迁移要传的是编码缓存、语言 KV、任务记录和恢复信息（目的设备已有兼容权重）。“恢复”还包括确定任务执行到了哪一步：一次点击已经改变了界面，即使应答丢了，也应恢复到点击之后。连接预热、图编译、模型加载都能用 NΔt − M 分析。
12.2.4 模型内部切分：每层都同步，启动延迟会累加
迁移只在换设备时传一次。按阶段切分（流水线并行）通信集中在相邻阶段之间；张量并行每层都要通信。36 层 Qwen3-8B 做 TP=2，每层注意力输出和 FFN 输出各一次两卡归约，两阶段环算法每次归约有两次启动：
图 12-15 / 12-16 · 一层里的两次归约
下一层要本层的归约结果，下一个 token 又要当前 token 的输出，这些启动只能依次发生，载荷再小也省不掉。单个请求只能靠减少通信次数缩短等待；多个独立请求可以让流水线各段同时处理不同请求，提高总吞吐。时间线中计算段长度为示意。
广域网传输中的额外开销与等待
12.1 节假设连接已建立、链路恒速。实际请求先要建连接和安全上下文，再取得发送额度，最后等接收方把数据交给应用。HTTP/1.1 和 HTTP/2 跑在 TCP + TLS 上；HTTP/3 用 QUIC，把传输握手和 TLS 1.3 合在一起，会话恢复时还能发 0-RTT 早期数据（被拒就重发，服务端按操作编号识别重试）。
12.3.1 连接复用
30 轮 · RTT 200 ms空闲连接仍占内存等资源；关掉能释放，下次就得重建。这和会话迁移一样，是一次准备与多次使用的比较。
12.3.2 窗口限制有效吞吐
图 12-17 · 窗口满了，链路空着也得等
为单独显示停等：接收方收齐一批才统一确认，从这批发完到收到确认再需 100 ms。蓝色时段在发送，灰色时段链路空闲，发送方却因窗口已满不能继续。物理带宽提高只能缩短蓝色部分。窗口和 RTT 跟随上方滑块。
慢启动：短请求可能还没等窗口长大就结束了
初始 10 段 × 1460 bytes · 每轮翻倍包头与 ACK 也占链路
每包 1,168 bytes 载荷 + 60 bytes 头，每包一个 92-byte ACK。约三万个包多出 ≈ 4.6 MB，35 MB 变成约 39.6 MB。逐包推算发送与确认时刻，完整请求约 14.4 s，比 12.8 s 多约 1.6 s。
少发 ACK 不一定更快
NewReno 下立即 ACK 改为每两包确认或最多等 10 ms：传输量 39.6 → 38.2 MB，完整请求却 14.52 → 14.56 s，晚约 43 ms。ACK 一面占链路，一面释放发送额度。
CUBIC 也一直在慢启动
同一路径大图比较，NewReno 与 CUBIC 都约 14.5 s。窗口轨迹显示 CUBIC 始终在慢启动，请求在进入拥塞避免之前就结束了，看到的只是启动阶段的行为。
12.3.3 丢包是不是拥塞
传统 TCP 不直接测带宽，而是把丢包当拥塞信号反推速率。Mathis 模型给出上界 B ≤ (MSS/R)·C/√p。它的前提是“丢包意味着拥塞”；无线误码和跨地域随机丢包都不满足。
Queqiao 的路径记录：Irvine → 贵阳下载方向，发送速率从 1 提到 300 Mbit/s，丢包率始终约 14%、前后独立；反方向 41,663 个报文一个未丢；RTT 最小与最大只差几毫秒，没有排队。提到 600 Mbit/s 丢包才升至 44%，越过了约 333 Mbit/s 的容量膝点，只有这里的丢包来自拥塞。
在丢包不含拥塞信息的路径上，从丢包反推的上限比实际可用速率低三个数量级。要改的是模型假设，不是传输实现。
图 12-18 · 354,640 bytes 跨地域请求的四种完成时间
RTT 0.2 s · 膝点 333 Mbit/s · MSS 1,448 · 模型 30 msBBR 不看丢包，持续测瓶颈带宽 max_bw（近期交付速率的窗口最大值）和 min_rtt（RTT 窗口最小值），按 BDP = max_bw × min_rtt 设在途量，cwnd 取 2 × BDP；Startup 的 pacing 增益 4 ln 2 ≈ 2.77，ProbeBW_UP 为 1.25。但 BBR 只回答“发多快”，不回答“丢了怎么办”。逐轮重传按理想选择性重传、不计窗口收缩与超时，是有利于 TCP 的下界：n 轮内全部送达的概率 (1 − pⁿ)245。FEC 在 245 个数据符号外多发 r 个修复符号，一块中丢失不超过 r 个就能直接恢复；r 取 99.9% 成功率所需的最小值（二项分布精确计算）。
12.3.4 多流传输：何时发送，何时交付
图片、音频和控制消息共用出口时，有两个顺序可以改：发送调度决定先给谁发，接收方的顺序要求决定已到达的字节何时交给应用（交付）。
发送调度
音频优先：音频早 3 秒，图片晚 1 秒，因为音频提前占用了原本发图片的时段。
图 12-19 / 12-20 · 队头阻塞
发送、到达与恢复时刻都不变，音频第 3 秒已收齐。HTTP/2 把多个流放进一个有序 TCP 字节流，前方缺口挡住后续字节；QUIC 按流保持有序，音频第 3 秒就能交付。接收段起点为示意。
12.3.5 案例：Queqiao 加速跨地域语音
把请求汇聚到少数数据中心，能共享模型副本、更容易集满 batch、提高利用率，代价是远方用户要走更长的网络路径。Queqiao 开源、可自托管，在可控客户端与可信网关之间承载 TCP 和 UDP 流量；应用仍调用原有 ASR、TTS 接口。
多条应用流共享客户端—网关路径的测量结果与传输状态，复用连接，按路径情况安排发送和恢复；前向纠错多发冗余，让接收方不必等重传。固定音频 354,640 bytes，理想下界 = RTT 200 + 模型 30 + 发送 8.5 ≈ 238.5 ms。
图 12-21 / 12-22 · 调优基线之后，差距去哪了
两种解释给出不同预测：若主要是连接准备与发送等待，调优直接路径后应接近下界；若协议本身有大优势，差距会保留。早期测试轮换 146–405 KB 的八个文件，改为反复发同一份文件并交替运行两条路径后，结果支持第一种：差距几乎全部来自实现开销，下界本身没错。调优后两者只差约 4 ms，小于同期 RTT 197–205 ms 的波动。
下一步该缩 RTT 还是加速模型
只要改在附近执行多出的准备和计算少于省下的 RTT，就比原来的远端路径快。
图 12-23 · 单因素实验：每次只改一个设置
| 改变的因素 | 对照的中间事件 |
|---|---|
| 连接复用 | 握手结束、首字节发送时刻 |
| 窗口设置 | 在途量、ACK 到达后的发送 |
| 发送节奏 | 两次发送之间的出口空闲、完成时刻 |
请求结束时刻只说明最后一批数据何时到达，播放器在此之前就要持续读取。另一组静音输出设备实验里，PCM 全部收到且逐位一致，播放回调却累计有 0.36–1.44 s 取不到足够样本。缓冲耗尽时：下一块还没生成，等在模型；生成了没到，等在传输；到了没被读取，等在本地缓冲与调度。
无线变化下的交互与恢复
无线接入让发送本身也有代价：上行数据和下行反馈轮流占用同一段空口时间，每次交换都要等信道空闲、等帧间间隔（SIFS），再收本跳的 MAC ACK。承载端到端 ACK 的无线帧也要做自己的 MAC 确认。
除了应用字节数，还要算交换次数。报文缩短八成，整次交换只缩短约 56%，因为 94 μs 固定开销还在。
图 12-24 · 短 ACK 帧的空口占用
OFDM 54 / 6 Mbit/s · 无聚合 · 无重传接入等待 34 μs = SIFS 16 μs + 两个 9 μs 时隙（802.11a 的 DIFS，不计随机退避）。30 MB 图片与 5 MB 成片约需数据交换、反馈交换各 30,800 次。少发 ACK 释放空口，但反馈延迟又会加长窗口停等，两者一起决定请求何时结束。TACK 把常规累积确认合并发送，需要即时反馈的事件（如丢包）立即返回。
信号波动：平均速率够，任务仍可能超期
借用 12.5 节选定的云端方案：剩余 20 轮，每轮 0.8 MB 截图走云端上行，其余工作和一次准备合计 11.6 s，期限 45 s。每轮速率 bi 可以不同：
无线上行逐轮变化 · 断连与恢复
发送时间与速率成反比：慢的几轮多出的等待，大于快的几轮省下的等待，所以要看调和平均而不是算术平均。若要 99% 的任务按时，平台要判断 P(T ≤ 45 s) ≥ 0.99，还要考虑网络持续变慢时相邻多轮一起受影响。恢复连接 1 s。
12.4.2 业务时限、过期数据与取消
按时可用才算数
八块 20 ms 音频，计划从第 0.4 秒连续播放 0.16 秒，与大图共用链路。FIFO 下八块最终全到，却都错过了各自的播放时刻；媒体优先时八块都按时到。收到的字节数一样，按时可用的声音分别是 0 s 与 0.16 s。播放器等缺块，延迟变成停顿；按固定时钟播放，晚到块直接缺失。
重试不能变成第二次点击
音频取消只丢弃尚未播放的数据；截图 Agent 的动作提交后就改变了环境。应答丢失时，重试应按原操作编号查结果；再点一次，就把通信重试变成了第二次业务操作。
图 12-25 · 一次取消，两条路径
待播队列里已有三块 20 ms 音频（60 ms）；控制消息要 100 ms 才到服务端，在此之前远端还在生成新块。本地清空决定用户何时听不到声音，远端停止决定何时不再消耗资源。远端每 20 ms 生成一块为示意。
12.4.3 双路径：分流、汇合与复制
Wi-Fi 与蜂窝是两条接入。分流把数据的不同部分交给不同路径，目标是同时用两份资源；复制把同一份数据交给两条路径，目标是更早拿到一份有效结果。
图 12-26 / 12-27 · 两路分流，再在出口汇合
复制：先看两份数据会在哪里同时失败
接入做得再可靠，共同端点那一项还在；把服务副本放到不同故障域才降得下来。复制要付额外带宽：八块 640-byte 音频一份 5,120 bytes，全量复制 10,240 bytes；接收方按块编号去重，先到的进入播放器。两路共用出口时，重复数据还会挤占别的任务。MPTCP 在一个逻辑连接里组织多条子流，接入代理可以在终端与普通服务器之间汇合路径。
从端边云分工到完整部署
回到 30 轮截图任务：前十轮已完成，剩余二十轮要在 45 秒内完成。原服务每轮 3.5 秒，还要 70 秒，必须换方案。每轮 0.8 MB 截图、0.3 秒终端工作。三处运行同一份 Qwen3-8B q4_0、8K 上下文，每轮生成 45 个 token，质量相同。每轮模型时间取 decode 读取下界：45 步 × 每步 5.47 GB ÷ 内存带宽。新服务接手前要对 8K 上下文做一次 prefill（133.6 TFLOPs ÷ BF16 峰值）；手机没有可引用的峰值，准备记为 0，这只会让端侧显得更快。
| 执行位置 | 设备 | 一次准备 | 每轮模型 | 上行 | 每轮往返传播 | 截图去向 | 20 轮能耗 |
|---|---|---|---|---|---|---|---|
| 端侧 | 手机，84.8 GB/s | 0 s | 2.90 s | 无需上传 | 0 s | 留在设备 | 518–680 J |
| 附近工作站 | RTX PRO 6000，1,792 GB/s，600 W | 0.27 s | 0.137 s | 80 Mbit/s | 0.02 s | 传到附近工作站 | ≈ 1.81 kJ |
| 云地域 | H100 SXM，3,350 GB/s，700 W | 0.14 s | 0.073 s | 6.4 Mbit/s | 0.20 s | 传到云地域 | ≈ 1.12 kJ |
成本用能耗衡量：GPU 按板卡额定功率 × 忙碌时间（一次准备 + 二十轮模型），是上限；手机按每 token 0.576–0.756 J × 900 token。网络能耗不计。比较之前先过数据驻留：截图不允许离开设备或出境时，后两行直接排除。Regionless 服务由平台为请求选择云地域，平台同样要比较传播、缓存与跨地域传输成本。
部署台 · 剩余 N 轮放在哪里
先满足期限与驻留，再比能耗图 12-31：只改云端上行 b，Tcloud(b) = 11.6 + 128/b（128 Mbit 是二十张截图的总上传量）。约 3.8 Mbit/s 起满足期限；上行再高也不低于 11.6 s，因为每轮 0.2 s 往返传播比附近工作站每轮的传播加上传（0.1 s）多出 0.1 s，超过了 H100 每轮省下的约 0.064 s 模型时间。断连只作用于远端方案，恢复连接 1 s，重做轮次再计一次模型能耗。
H100 的带宽是 RTX PRO 6000 的 1.87 倍，二十轮模型只省约 1.3 秒；上传和传播却多等 22 秒。每轮 decode 只要几十到一百多毫秒，远少于每轮的通信时间。
图 12-32 / 12-33 · 同一次断连，保存进度决定能否按时
云端每轮 1.57 s，第十轮执行完、确认未返回时断连，恢复连接 1 s。保留前九轮提交记录只重做第十轮：+2.57 s，共 34.2 s。十轮全丢：+1 + 10 × 1.57 ≈ 16.7 s，共 48.3 s，超期。附近工作站每轮约 0.54 s，就算丢十轮也只要 17.4 s：期限余量越大，对故障越宽容。此例假设操作可安全重放；已提交的外部操作先查结果。
文本 Agent：保留状态值多久
H100 SXM · 465 MB 状态逐轮重送前缀共约 66 KB，保留状态后只送约 10 KB，在 333 Mbit/s 上只省 1.3 ms。真正的收益是少算前缀：3.0×10¹⁴ → 6.0×10¹³ FLOPs，按 989.4 TFLOP/s 省约 0.239 GPU 秒。状态占 H100 80 GB 的比例折算成每秒 0.465/80 ≈ 0.0058 GPU 秒。
失败全部重试的期望成本
保存进度把整项重试变成局部重做，直接降低每次失败追加的时间和成本。
12.5.3 何时更换部署方案
| 条件变化 | 结果 | 决策 | |
|---|---|---|---|
| 云端上行 6.4 Mbit/s | 云 31.6 s、约 1.12 kJ；附近 11.0 s、约 1.81 kJ | 两者都按时，用能耗更低的云端 | |
| 云端上行降至 3.5 Mbit/s | 云约 48.2 s | 云端超期，改用附近工作站 | |
| 云端上行无论多高 | 云不少于 11.6 s | 始终慢于附近；更紧的期限只能由附近满足 | |
| 断连，保留前九轮、重做第十轮 | 34.2 s | 仍在期限内 | |
| 同次断连丢失十轮进度 | 48.3 s | 超期；改进进度保存，或改用附近 |
本例结论：剩余二十轮放到云端，31.6 秒完成，比继续用原服务（70 秒）省约 38.4 秒。终端继续采集和执行操作，H100 负责模型判断，每轮只传截图和控制结果。中途换设备还要迁移会话：12.2 节的 64 MiB 状态约 7.7 秒准备，20 轮只净省约 0.3 秒；若带宽改善只持续十轮，反而净亏约 3.7 秒。预计节省足以抵消迁移并留有余量时才迁移，临界带宽附近别来回切。
12.5.4 只加速模型，收益同样有限
图 12-34 · 固定轨迹里的加速上限
模型 8 s + 其他串行阶段 2 s剩下的 2 秒要靠改系统组织：执行移到本地减少往返，保留环境减少创建等待，新增的本地设备与驻留空间进入新的成本预算。DeepSeek V4 → V4.1 是模型侧的同类调整：跨层共享减少全局 KV 重复保存，CED 减少输入阶段反复经过解码器的工作，缓存恢复缩短多轮会话重新开始的路径。
容易算错的地方
图片精修处理快十倍只省 0.27 s；云端 H100 每轮省 0.064 s 模型时间，却多等 1.1 s 通信。先看模型在总时间里占多少。
0.8 MB 截图编码成 [400, 10240] BF16 特征是 8.192 MB，约十倍，6.4 Mbit/s 上从 1 s 变成 10.24 s。
Irvine → 贵阳 1–300 Mbit/s 丢包都约 14%，RTT 不变。按丢包反推只有 0.155 Mbit/s，实际可用约 286 Mbit/s。
十轮 6 + 十轮 10 平均也是 8 Mbit/s，任务却比恒定 8 慢 1.1 s；音频平均速率够，一块晚到仍会停顿。
20 + 10 Mbit/s 分流各 8 s 发完，但汇入 24 Mbit/s 共同出口后，30 MB 至少要 10 s。瓶颈转到了汇合点。
聚合 ACK 少传 1.38 MB，请求却晚 43 ms：确认晚到，发送额度也晚释放。
三层分析，再比成本
一、先算时间，再看依赖
数据量、计算量和传播距离给出各步骤耗时；执行依赖决定哪些相加、哪些重叠；连接、窗口、竞争和恢复解释实际等待。图片的 12.8 秒、语音的逐块递推、Agent 的逐轮累积分别对应这三层。端侧同样适用：带宽给出 token/s 上限，容量决定模型与上下文，能耗与电池决定能持续多久。
二、分工改变传什么
把计算移到端侧，可能把紧凑图片换成更大的特征；把模型拆到多台设备，可能把一次传输换成逐层同步。先扣除两边相同的耗时，再比较省下的计算与增加的通信。迁移、预热、编译、保存状态都用 NΔt − M 求回本次数，并为波动和恢复留余量。
三、先期限，后成本
Queqiao 的基线修正说明：调优消除额外等待后，再要提速只能缩短传播。随机丢包路径上要直接测带宽，再按丢包率配冗余。最终选择先满足质量和期限，再比成本；慢速轮次和丢失进度都会让“平均够用”的方案超期。
回到第 1 章：开发者通过上下文表达任务，执行系统据此安排计算、保存状态、传输数据。保留一段历史、增加一个候选分支、提前准备工具环境、迁移一次会话，现在都有了可以追踪的资源代价。
动手验证
12-2、12-3、12-7 为核心练习。未另说明的数值沿用正文条件。多数题可以直接用上面的计算器复算。
12-1 · 图片精修的传输与计算预算
(a) 上行取 10、20、100 Mbit/s，算原方案、处理快十倍、输入减半（+0.15 s）三种完成时间。(b) 求压缩收益恰为零的上行速率；20 Mbit/s 下若 0.3 s 中只有 0.2 s 可加速十倍，总耗时是多少。(c) 三块独立处理时画出重叠，标出限制继续缩短的步骤。
12-2〔核心〕· 截图压缩能否抵消额外交互
(a) 0.8 → 0.2 MB、每轮多 30 ms 编码，30 轮共省多少。(b) 压缩后需要 38 轮还快吗？最多允许几轮。(c) RTT 加 100 ms，分别算原图 30 轮和压缩图 38 轮，解释为什么增量不同。(d) 为截图版本与操作编号设计记录字段，区分压缩导致的纠错轮次与旧状态导致的无效轮次。
12-3〔核心〕· 视觉编码位置与状态迁移
(a) 0.8 MB 图片、[400, 10240] BF16 特征、6.4 Mbit/s；1.31 TFLOPs 分别在 RTX 4090 与 H100 SXM 上编码，比较两种方案总耗时。(b) 换成 ConnectX-7 400 Gbit/s，特征多花多少传输时间，与编码时间差比较，谁决定编码器位置。(c) 80 Mbit/s 传 64 MiB、恢复 1 s、每轮快 0.4 s，剩 10、20、40 轮的净节省；恢复再加 1 s，至少几轮回本。(d) 保存图片、视觉特征、语言 KV 分别从哪里重算；已提交操作怎样进入恢复。
12-4 · 连接复用与多流传输
(a) RTT 200 ms、30 轮、建链两次往返，每轮新建与全程复用差多少。(b) 立即确认与聚合 ACK 的总传输字节，为什么字节更少、完成反而可能更晚。(c) 比较发送优先级与逐流交付分别改变了什么。(d) 设计只改变连接复用方式的对照实验，列出起止事件和中间事件。
12-5 · ACK 频率与空口效率
(a) 302 μs 数据交换、134 μs 确认交换、30,800 次，ACK 减半释放多少空口时间。(b) 画出等待聚合 ACK 而暂停发送的时间线。(c) 256 kbit/s 播放、130 kbit/s 接收、60 ms 缓冲的耗尽时刻；采样率改为 24 kHz、60 ms 不变时的新耗尽时刻。
12-6 · 双路径的分流与备份
(a) 30 MB 经 20 与 10 Mbit/s 分流，推导同时完成的比例与时间。(b) 加 24 Mbit/s 共同出口，新的下界是多少，提高哪段带宽有用。(c) p₁ = 0.1、p₂ = 0.05、q = 0.02 时复制后的失败概率；两条接入完全可靠时呢。(d) 八块 640-byte 音频各复制一份，新增多少字节，接收方怎样避免重复播放。
12-7〔核心〕· 单因素实验区分连接准备、窗口与传输延迟
(a) 两组实验中直接路径与 Queqiao 中位数之比，“主要差距来自连接准备与发送等待”给出什么预测。(b) 355 KB、333 Mbit/s、RTT 200 ms、处理 30 ms 的理想完成时间，与约一秒的实测比还有多少等待要解释。(c) 设计窗口大小的单因素实验，应看到怎样的在途量、ACK 与发送时序。(d) 用音频记录画出一块从生成到播放的时刻，区分生成不及时、传输延迟与本地调度等待。
12-8 · 上行带宽与故障恢复如何改变部署
(a) 复算三种方案的时间与能耗，求云端按期所需上行，说明为什么云端追不上附近工作站。(b) 剩余十轮、期限 23 s 选方案；期限收紧到 15 s 再选（部署台 ⑦ ⑧）。(c) 十轮 6 + 十轮 10 Mbit/s 与恒定 8 Mbit/s 比较。(d) 十轮任务、期限 23 s，第八轮刚完成就断连、恢复 2 s：保留前七轮只重做第八轮，或前八轮全部重做，分别算剩余时间和总耗时，重做轮次再计模型能耗，重新选方案。
12-9 · 端侧设备的带宽、容量与能耗
(a) 四条 x16、每引脚 10.6 Gbit/s 的合计带宽，BF16 单请求 8K decode 每步下界与 token/s 上限。(b) q4_0 后重算；12 GB 内存、预留 4 GB 时剩余空间、可容纳 8K 请求数、单条最大上下文。(c) 0.576–0.756 J/token、13.8 W 给出的 token/s 上限范围，与 BF16、q4_0 带宽上限比较，谁先起作用。
12-10 · 丢包、重传与编码冗余
(a) MSS 1,448、RTT 0.2 s，p = 14% 与 3.6% 的 Mathis 上界与 354,640 bytes 的仅发送时间。(b) 245 个报文、p = 14%，期望丢失数；理想逐轮选择性重传下完成时间的期望与 p99。(c) 99.9% 成功率下两种丢包率各需多少修复包、冗余比例、完成时间，与重传 p99 比较。(d) 为什么冗余比例应随测得的丢包率调整，而不是固定 25.7%。