摘要

  • RFC 9699 是 Informational 用例文档，不是性能标准，也不是某家运营商的部署成绩单。
  • XR 需求的突发与长尾，使“平均很快”和“连续可用”成为两回事；被放弃或降级的任务不能从统计中消失。
  • 边缘采购需要把设备、无线、计算和应用的证据接起来，以约定条件下可用的会话时间核算价值。

一份验收报告可以同时写着“网络低时延”“计算响应达标”，却不回答用户看到的虚拟物体有没有及时对准现实。缺口未必是某一方造假，也可能是大家各自选择了有利的起止点与分母：网络测包，服务器测完成的任务，应用只统计返回的画面。最慢的任务若已被丢弃，平均值甚至会因此改善。

这是本文提出的分析情境，不是一次已发生的运营事故。它解释了为什么讨论 XR 边缘计算，必须先问账本记录了什么，再问机房离人多近。

2024 年 12 月发布的 RFC 9699 描述扩展现实应用使用边缘基础设施的用例。其状态是 Informational，而非 Standards Track。文中的伦敦塔游客情境帮助解释技术需求，并不是已经运营的项目；文档也没有给出命名运营商的规模化体验验收结果。把 RFC 编号写进方案，不能补上这些证据。

更近，只改变其中一笔支出

XR 要追踪运动、建立环境模型、把虚拟对象与物理空间配准，再生成时间上连贯的画面。这条链同时受设备电池、散热、无线传输与计算资源限制。卸载工作可能减轻头戴设备的计算负担，但会增加上传、远端准入、排队和回传的依赖；一项支出被移走，不代表总账自动变小。

RFC 引述的早期多用户 AR 研究提醒读者关注上行：场景中可用视觉特征较少时，可能需要上传更多信息。展示高下行速率，并不能证明识别困难场景时的更新也能赶上。这些是历史研究所揭示的机制，不是对今天某一款 5G 产品的测量。

散热也不能靠推断验收。2020 年的一项智能眼镜热模型研究用热网络模型与有限元计算对照，实际物理测量验证仍属于后续计划。它说明材料、布局和热传导路径值得认真处理，却不能提供当代商品头显卸载之后的降温或续航增益。无线活动与剩余的本地处理仍然耗能。

重尾不是拒绝平均值，而是拒绝只看平均值

RFC 讨论需求与流量的重尾特征、突发和空闲期，以及它们对资源预测的挑战。使用这一观察要克制：不能据此认定所有 XR 样本都服从同一种分布，更不能说所有重尾分布的均值或方差都不存在。实际工作负载仍需采样、检验和说明观察窗口。

工程上更直接的问题，是多少任务错过了自己的截止时间，失败是否成串出现。人群带来更多竞争，移动改变接入条件，难以识别的场景又增加处理或传输需求；若这些条件同时发生，孤立测得的各段指标就可能低估组合压力。这是需要测试的假设，不是本文的新实验结论。

RFC 引用 20 毫秒以及更优的 7–15 毫秒等设计目标，并举出显示约占 12–13 毫秒的预算。它们不是普遍医学安全线，也不是所有现售头显的实测成绩。文中另有服务器响应时间的讨论，恰恰提醒验收方：服务器返回、网络往返、运动到显示，是不同的测量对象。

本文建议用同一条任务因果链连接追踪、上传、入队、执行、返回与呈现，并公开时钟误差和拿不到的观测。各阶段的尾分位数不能直接相加成端到端尾分位数；被放弃、超时和降级的工作则应留在相应分母中，而非从成功样本里悄悄消失。

网络承诺不能替显示签字

RFC 8655 的 DetNet 架构有明确管理边界：单一管理域或封闭协作的管理域，并非任意互联网路径的确定性保证。即使传输在约定范围内按时完成，也没有替 GPU 队列、追踪误差与显示设备作出认证。方案罗列协议名，不能替代各责任面的证据。

怎样建立证据？可以用相同场景、轨迹与并发负载比较本地处理和不同卸载位置，保留失败样本。Puffer 视频研究的启发在方法：仿真中表现出色的复杂方案，需要在真实环境中与简单基线比较。那不是 XR 实验，不能移植其效果数字，只能借鉴现场验证的纪律。

因此，RFC 9699 的价值在于把问题讲清楚，而不是替采购做完决定。一个可信的商业结论应带着限定条件：哪些设备、哪些负载、什么失败分布，换来了多少可用体验。离用户更近，是待检验的手段，不是结算凭证。