Daily Edition · 2026-07-30
本期从运行时一路看到机房入口：Agent 工作流需要跨工具调用保住 KV Cache，MoE 通信要避免尾段 incast，GPU 节点则在进入生产池前完成硅片、互联、RDMA 与 collective 验收。
ThunderAgent 在 Agent 客户端与推理后端之间加入程序级调度层，用 program_id 把多次 LLM 调用归并为同一工作流，并跟踪执行阶段、KV 占用和节点位置。内存压力升高时，它暂停低优先级程序以减少活跃工作集，再通过全局等待队列把恢复请求送往容量更充足的节点。Together AI 在 8×H100、SGLang 与 HiCache 的单节点合成数据流水线上自报，batch size 192 时吞吐由 390 提升到 803 token/s、平均延迟由 65 秒降到 10.6 秒；扩展到 8 节点时，相比 SGLang Gateway 自报 2.39 倍加速。
为什么值得读：Agent 推理的调度单位不再是一条独立请求，而是会在推理与工具执行之间反复暂停、恢复的有状态程序。这个抽象能同时处理 KV 局部性、跨节点负载与分层卸载，但数据来自 Together 的特定编码 Agent 流水线，生产收益仍取决于工具时延、上下文增长、优先级策略和缓存层容量。
论文分析 MoE dispatch 中各 NIC 独立轮转不对称流的行为：轻流先完成后，剩余发送方会逐渐集中到热门专家，接收端聚合速率在 epoch 尾部急剧上升，形成作者所称的 exponential incast。作者提出面向 MoE 的主动公平速率调度，以每个接收端的容量约束分配发送速率，并讨论在 NIC 中实现；在真实与合成流量的仿真中，作者报告该方案可消除 fabric oversubscription、维持接近 100% 链路利用率并降低 collective completion time。
为什么值得读：MoE 通信优化常盯着平均 All-to-All 带宽，但真正拖慢 collective 的可能是 skew 在尾段如何集中。该工作把问题推进到 NIC 调速与接收端容量分配，不过目前证据主要来自仿真，仍需要在真实交换网络、拥塞控制、背景流量和故障条件下验证。
AMD 介绍 GPU Operator 生态中的 Cluster Validation Framework：在与生产控制面隔离的临时 k3s 集群里，依次做节点筛选、GPU 硬件验收、节点内 XGMI mesh 带宽、NIC/固件/SR-IOV 健康、逐 rail RDMA 带宽和多节点 RCCL scale-out。每阶段把结果写成 Kubernetes node label，失败节点不会进入后续阶段，生产调度也可要求 cluster-validation-status=passed。阈值由 ConfigMap 配置，文中示例包括 MI300X 节点内 AllReduce 的 100 GB/s 门槛与 400G rail 的 380 Gbps 门槛。
为什么值得读：大规模训练的可靠性不能只靠作业运行后的 straggler 检测；节点进入资源池前就应验证硅片、互联、VF、RDMA 和 collective 的组合路径。CVF 提供了可复用的验收骨架，但文中的典型带宽和门槛是 AMD 平台边界，运营方必须按分区模式、拓扑、固件与业务容忍度重新标定。
Meta 的 Memory Layer 把原本只存在于 serving 侧的 item embedding cache 变成模型内、可共同训练和持续流式更新的键值层：item tower 在训练时写入，线上模型直接读取，同一份表示贯穿训练与服务；尚未写入缓存的 item 由 always-on embedding 兜底。论文报告其已部署到 Instagram Reels，预测覆盖率从 96% 提到 100%，embedding 新鲜度从约 5 分钟缩短到约 20 秒，训练与发布计算成本下降 30%，同时保持 serving 计算成本基本不变。
为什么值得读：这是典型的系统—模型协同：不是用更多校验去弥补 training-serving skew，而是消除两套 item representation 和多条发布链路。数字来自 Meta 生产环境，外部团队更应关注内存容量、写入一致性、冷启动兜底与 checkpoint/恢复语义，而不是直接外推业务增益。
论文研究同时包含本地 fast path 与远端高精度 slow path 的推理流水线：router 选择是否调用慢路径，merger 只在截止时间前接纳返回结果。作者表明，攻击者可用 Yo-Yo 式突发请求挤压慢路径共享资源，使正确结果在 deadline 之后到达并被丢弃，而 fast path 仍按时响应，形成表面可用但精度下降的 accuracy collapse。在自动驾驶边云目标跟踪仿真中，约 4,000 个突发请求把 benign slow-path P99 从 92 ms 推到 2 s，平均降低 7.0 个 HOTA 点。
为什么值得读：多模型路由、边云协同和级联推理的 SLO 不只是延迟指标，晚到结果会直接改变输出质量。防护需要把 admission control、隔离、autoscaling、router 与 merger 策略一起建模；论文目前基于仿真和特定视觉流水线，数字不能直接外推到通用 LLM 服务。
Together 将专用推理拆为稳定 endpoint、绑定模型与硬件配置的 deployment，以及不可变的 config revision。路由器按 weight × ready_replicas 计算每个 deployment 的有效容量，因此副本扩缩、冷启动或降为零个 ready replica 时，流量会随可服务容量自动变化；A/B cohort、shadow 和 rollout 则作为不同层次的机制叠加。官方在两个单 H100 deployment 上各发送 599 个请求，自报副本从 1:1 变为 2:1 后，实测流量从 47.6/52.4 变为 69.4/30.6，接近期望的 66.7/33.3。
为什么值得读：固定百分比分流很容易与 autoscaling 脱节，按 ready replica 加权能让路由与容量成为同一控制回路。这里的实验规模很小且来自厂商自身平台，但 endpoint 身份、不可变配置、可丢弃 deployment 与分层发布语义，对自建推理控制面同样有参考价值。
该教程分支版本在 gfx950-tutorial-v1.1 上加入 Gluon FlashAttention 需要的两项编译器改动：gl.warp_predicate 可把每个 wave 的 masked-skip 区域降到 s_and_saveexec 与 s_cbranch_execz，从而在本 wave 没有行更新 running max 时跳过 accumulator rescale；AMD warp-pipeline barrier 则固定发出 local cluster barrier，并在循环回绕处强制 LDS drain。Release 说明称，两套 attention kernel 与四套 inter_wave GEMM kernel 均编译出与开发分支逐字节一致的汇编并通过正确性检查。
为什么值得读：高性能 Attention 常依赖看似细小的执行掩码、barrier 放置与 LDS 排空语义，DSL 能否表达并稳定 lower 这些细节决定它能否替代手写 kernel。该标签面向 gfx950 教程与特定 Gluon 路径，不是通用 Triton 正式版本，采用前应锁定分支、LLVM pin 和目标架构。
这个主题下今天没有条目。