北京
“尾延迟在 1.0 microVM/vCPU 之前保持平稳，超过后 p99 在接下来 15% 的密度增幅里陡升，而中位数几乎不动。”这是 AWS 在 EC2 Metal 裸金属上做大模型强化学习沙箱实践后，给出的一个相当反直觉的结论。
换句话说，你以为多塞一点任务进去只是让机器忙一点，实际上中位数感受不到，但最慢的那一批请求已经开始失控。而 RLVR 训练里，最慢的那一批恰恰是决定成败的那一批。
黄金比例是怎么测出来的
AWS 的这套架构建立在 Firecracker microVM 之上，用来承载大模型强化学习的 Rollout 沙箱。为了找到 microVM 与物理 vCPU 之间的合理配比，他们用开源工具 labsweep 做了拓扑探测和矩阵延迟测试。
测试结果指向一个明确的拐点：1.0x。密度低于 1.0 时，尾延迟极度平稳；一旦越过这条线，P99 开始急剧恶化。这个分水岭被描述为跨机型通用，不是某一款硬件的特例。
更值得警惕的是恶化的速度。密度仅仅增加 15%，P99 就已经陡升，而中位数几乎不动。这意味着常规的均值监控根本发现不了问题，等到报警响起，训练效率可能已经塌了。
为什么 GRPO 对尾延迟如此敏感
问题出在 GRPO 这类算法的同步机制上。每个梯度步都要等待最慢的那个 rollout 结果，木桶效应被放大到了极致。
在 G=64 的规模下，一次 P99 事件会影响约 47% 的训练步。也就是说，单次尾延迟抖动，就能拖累近半数训练步的整体速度。这不是性能打折，是吞吐遭遇毁灭性打击。
所以盲目超配 microVM 密度，省下的那点资源成本，很可能被训练时间的暴涨全部吃掉，还倒贴。
两个可以立刻上手的调优动作
除了守住 1.0x 这条线，AWS 的实践里还有两个具体手段：
- CPU 绑定：可将 P99/P50 压缩至 1.1x，尾延迟分布明显收窄。
- 关闭 SMT：计算密集型场景应果断关掉超线程，避免争抢带来的抖动。
这两项调优针对的都是同一个目标——把最慢的那一批请求拉回来。对于需要等待最慢 rollout 的 GRPO 来说，这比提升中位数性能更有价值。
整套实践的核心逻辑其实很朴素：RL 训练沙箱的密度不是越高越好，1.0x 就是那条不能踩的线。踩过去，中位数骗你没事，P99 会替你付出代价。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
