状态：草稿（2026-10-16），实测合集。 服务器端的阶段是本系列中使用 Lab 实验室的 8GB 级笔记本 GPU 测得的值，而运营操作员（服务器 GPU，与其他任务共享显卡）和浏览器端的值引用了仓库
docs/tt/PERFORMANCE.md的实测结果（2026-10-11–15）。手机内部的时间和互联网传输区间属于 未测量。 系列“阅读视觉模型 3”第 8 篇（完结）。模型本身位于 TT Score 模型剖析。
TT Score 实时路径的实际预算表
目录
1. 追踪单次路径
在相机记分牌（/tt/play/cam) 中开启“自动计分”时，流程如下。
- 手机（浏览器）: 以最高 30fps 捕获相机画面，将其居中缩放到 512×288，制成 JPEG（质量 0.7），在头部附加 8 字节的“编号 + 拍摄时间”，通过 WebSocket 发送。如果连续 3 帧未收到回复，则暂停发送。
- Web 服务器: 查看登录状态、座位和每日限额，将帧原样转发给 GPU 工作线程。大小和速度上限（每秒 36 帧）在这里再次进行限制。
- GPU 工作线程: 解码 JPEG 并进行归一化，为每个会话使用最后 3 张图像构建窗口。将等待中的会话的最新窗口合并为一个批次输入球体模型，积压的窗口将被新窗口覆盖。
- 后处理: 从最后一帧的热力图中寻找球体团块，通过追踪器将其连接起来，通过规则找出反弹、网球网和拉力赛结束，并由训练过的小型 CNN 再次筛选出反弹。裁判规则决定得分。
- 答复: 球的位置逐帧返回，反弹和判定在生成时以 JSON 格式返回并由手机绘制。
2. 预算表
| 阶段 | 位置 | 测量值 | 来源与条件 | 缩减方法（篇） |
|---|---|---|---|---|
| 捕获相机画面 | 手机 | 未测量 | — | — |
| 缩放到 512×288 + JPEG | 手机 | 未测量（模拟服务器 CPU 为 0.27 + 0.30ms） | 本系列第 1 篇 | 第 7 篇（设备内） |
| 上传（JPEG 12–18KB） | 互联网 | 未测量 | 大小基于运营设计实测 | 第 5、7 篇（减小发送体积） |
| Web 服务器转发 | 服务器 | 未测量（未单独测量） | — | — |
| JPEG 解码 | 工作线程 CPU | 0.31ms | 本系列第 1 篇 | — |
| 归一化 | 工作线程 CPU | 1.35ms | 本系列第 1 篇 | 在 GPU 上执行（第 1 篇，未测量） |
| 构建窗口 + 传至 GPU | CPU → GPU | 1.76ms | 本系列第 1 篇 | 转换为 uint8（第 1 篇，未测量） |
| 球体模型推理 | GPU | 15.2ms(FP32) · 10.0ms(FP16) · 4.3ms(FP16 + 编译) | 实验 GPU，第 2、3 篇 | 第 2、3 篇 |
| 相同推理，运营服务器 GPU | GPU | 单窗口 10.5ms（空闲显卡）· 34ms（与其他 2–3 个任务共享） | 性能文档 2.9.8 | 第 6 篇（显卡划分） |
| 将热力图传回 CPU + 寻找团块 | GPU → CPU | 0.18 + 0.07ms | 本系列第 1 篇 | — |
| 球桌追踪（光流·切片判定） | 工作线程 CPU | p50 1.72 · p95 1.77ms | 性能文档 2.12（静默节点） | 第 5 篇（仅偶尔重新查找） |
| 反弹规则的前向查看 | 引擎 | 3 帧（60fps 时 50ms，30fps 时 100ms） | 引擎设置 | — |
| 拉力赛结束判定 | 引擎 | 球在一段时间内不可见即为结束 | 引擎设置 | 第 1 篇（迟到的正确答案对错误的答案） |
| 接收答复 + 绘制 | 互联网·手机 | 未测量 | — | — |
仅将会话侧 GPU 相加约为 19ms，在 30fps 的单帧（33.3ms）之内。这与实时工作线程的一个会话接收 30fps 的情况相符。
3. 端到端测量值
将各阶段相加得到的值与实际测量的端到端值有所不同。这是因为加上了队列等待时间、线程之间的切换以及同一显卡上其他任务的开销。
| 项目 | 测量值 | 条件（运营性能文档） |
|---|---|---|
| 工作线程往返，会话 1 | p50 24–28ms · p99 31–32ms, 29.4fps | 同节点的客户端，TTS 与显卡共享（4.2） |
| 工作线程往返，3 个会话并发 | 每个会话 16–20fps，p50 70–95ms，p99 约 127ms | 同上，发送的帧中有 21–30% 被覆盖丢弃（4.2） |
| 浏览器端到端 | p50 65 · p90 84 · p99 146ms, 24.6fps | 无头浏览器虚拟相机 → 实际转发 → 工作线程，显卡资源竞争中（4.1） |
| 拉力赛结束 → 判定送达浏览器 | 中间值 0.67–0.90 秒 | 以时间单位运行运营引擎代码的重现器，公开视频的多种条件，将捕获抖动、60ms 往返和 15ms 工作线程设为接近运营环境的值（2.14）。目标 1.5 秒 |
最后一行是用户实际感受到的延迟。它比单帧往返（几十毫秒）长十倍以上。判定必须在确认“球落在地上或出界”之后才能做出，但要区分球被短暂遮挡和拉力赛结束，必须等待球在一段时间内不可见。研究记录表明，缩短这种等待会大幅减少判定延迟的 p90，但胜者准确率会略有下降，因此目前尚未更改（正在进行的研究）。
这与第 1 篇中的 Streaming Perception 结构相同。 迟到的正确答案与早到的错误答案之间的权衡，仅通过将模型加快几毫秒几乎无法改变这个数字。
4. 那么应该首先缩减什么
| 目标 | 最大杠杆 | 依据 |
|---|---|---|
| 加速判定 | 拉力赛结束判定（等待与准确率） | 第 3 节 |
| 在单个显卡上增加会话数 | 推理：FP16 + 编译（15.2 → 4.3ms，实验 GPU） | 第 2、3 篇。开启前需确认球位置的一致性 |
| 减少延迟尾巴 | 切勿与其他任务共享显卡 | 第 6 篇（10.5 → 34ms） |
| 在慢速网络下 | 保持 512×288 和 JPEG 质量，上传带宽约 3Mbit/s | 第 7 篇 |
| 无需服务器 | 从球桌查找开始就在手机上进行 | 第 4、7 篇 |
在第 2 篇中，FP16 的球位置与 FP32 在判定上完全相同，但该测量是在实验 GPU 上对单场比赛的 388 帧进行的。若要在运营环境中开启，必须在运营 GPU 以及多种比赛和劣化条件下重新确认。
5. 尚未测量的部分
- 手机内部时间：捕获相机、缩放、JPEG 编码、绘制。不同机型会有所不同。
- 互联网区间与 Web 服务器转发分离的延迟。目前的端到端值仅将两者合并测量。
- 运营 GPU 上的 FP16 和编译效果及准确率。
- 在手机端运行球体模型时的速度（第 7 篇）。
6. 系列结语
本系列中最常出现的一句话是“测量后发现与预期不同”。将乘法运算减少 8 倍后速度只快了 1.6 倍（第 4 篇）；原本以为合并会加速的批处理在此 GPU 上反而变慢了（第 6 篇）；与将精度降低一半相比，JPEG 压缩对球位置的晃动影响更大（第 2 篇）。而且，用户感受到的延迟是由判定规则的等待时间决定的，而不是由模型决定的（本文）。论文和文档指明了方向，但具体数字必须在自己的模型、自己的设备以及自己的使用方式中测量才能得出。
Tt 语录。 我找到球只需要 15ms，但记分牌更新大约需要 0.8 秒。因为要稍微观察一下球是不是真的落地了。总比急急忙忙出错要好，对吧！
参考文献
- 我们的测量：本系列第 1–7 篇的实测结果（原始数据来自仓库外的研究记录），仓库的
docs/tt/PERFORMANCE.md2.9.8·2.12·2.14·4.1·4.2 - TT Score 模型剖析系列： README
- Li, M., Wang, Y.-X., Ramanan, D. (2020). Towards Streaming Perception. ECCV 2020. https://arxiv.org/abs/2005.10420