01
生产推理实践
Cloudflare Blog / Workers AI
·
Cloudflare 公开其 Workers AI 上 Kimi K2.6 与 GLM 5.2 的 SGLang 生产路径：decode 侧把 KV cache 从 BF16 改为 FP8 e4m3，使可驻留上下文约由 68.6 万增至 137 万 tokens；在分离式 H200 测试中，FP8 单一并发略慢，但可把并发从 BF16 的 32 扩至 64，并达到 2,192 tok/s。GLM 5.2 权重由 FP8 压到 INT4 后，checkpoint 从 705 GB 降至 421 GB；decode 在并发 1 时由 60 提至 92 tok/s，而 compute-bound prefill 则由 10,160 降至 8,660 tok/s，因此平台只在 decode 使用 INT4。团队还为共享 paged KV cache 加入代际 tag 检查，在其 2-prefill / 2-decode、8K 输入与 1K 输出测试中，吞吐和 p95 代价均低于 1%。
为什么值得读：低精度不是一个全局开关：它改变的是显存容量、并发上限、带宽和安全边界，不同 phase 的最优格式可以相反。文中数字来自 Cloudflare 自有 H200/SGLang 部署与评测套件；INT4/FP8 的质量、kernel、分页器和完整性检查都应在目标模型及流量上独立验证。
02
大规模训练系统
Meta Engineering
·
Meta 介绍广告推荐基础模型 GEM 在数千张最新一代 GPU 上的训练协同设计：模型包含万亿级稀疏 embedding 与十亿级 dense 参数，jagged 输入若按最大长度 padding 会浪费至多 50% 计算。团队以 JFA、GDPA 与 BlockAttention 适配不规则和非对称 attention，引入 MXFP8 attention/MLP；分布式侧把 dense 参数的 2D FSDP + EP 与 sparse 参数的 Fully Sharded 2D Model Parallelism 映射到 NVLink、区内 RoCE 和跨区过订阅 RoCE，并用 SM-free collectives、自动 activation checkpoint/量化及 sequence-length-aware batching 减少暴露通信、重算与 straggler。Meta 自报 12 个月内训练 FLOPs 扩大 4 倍，同时端到端效率翻倍至 20—25% MFU。
为什么值得读：为 LLM 设计的 kernel、精度 recipe 与并行策略不会自动适配推荐模型；数据形状、数值敏感度、稀疏参数和网络层级必须一起优化。所有收益来自 Meta 内部模型、功耗限制与集群，外部团队更应复用其 MFU 分解和拓扑映射方法，而不是照搬百分比。
03
论文与开源系统
arXiv / McGill、Nutanix 等
·
DeltaServe 把低于峰值流量时闲置的推理算力转成 LoRA fine-tuning throughput，只要求宿主引擎支持 multi-LoRA batching，并通过紧凑 hook 接入 vLLM、SGLang 与 S-LoRA。它利用 fine-tuning forward 与 inference prefill 的共同执行结构，以感知 CUDA Graph 的离线校准、在线修正延迟模型做 SLO budgeting，在新推理请求到达时还可中断纯微调 forward batch。作者在 RTX 5090 与 4×A100 上评测；对 20 分钟 Nutanix 生产 trace，DeltaServe-vLLM 自报在全部请求满足 SLO 时达到 1,418 fine-tuning tok/s，为 LLMStation 的 2.9 倍，并比独占一张 GPU 做微调的 split-pool 基线高 39%。
为什么值得读：它给 GPU 空闲回收提供了比简单 workload colocation 更细的接口：调度器理解 prefill、backward 与 CUDA Graph 边界，同时不把实现锁死在一个 engine。当前结果基于 Llama 3-8B、LoRA r=16 和特定 trace；长模型、不同 SLO、显存压力与多租户公平性仍需验证。
04
论文与开源评测框架
arXiv / Microsoft Research 等
·
Aries 将 task semantics 与执行配置分离，用跨 LLM、harness 和 sandbox 的统一事件标识重建 agent trajectory，并把不同沙箱 substrate 映射到一致的状态与遥测接口。作者结合开放 harness/benchmark 和匿名商业平台生产 trace 报告：harness 与工具执行可占端到端时延至多 48%；增加 context budget 可把一组受 overflow 影响任务的成功率由 55% 提至 95%，但收益在 workload-specific threshold 后趋平，而长期状态持续压缩 resident capacity。论文还观察到工具沙箱大多长时间空闲、短时突发，现有 snapshot-based suspension 成本过高，并将代码、工具链和匿名 trace 开源。
为什么值得读：只优化 tok/s 可能让 GPU 更快，却不能解释任务为什么卡住、失败或占满资源。轨迹级 provenance 能把 context、工具、sandbox 生命周期和模型调用放进同一 critical path；但论文的阈值与占比来自有限 benchmark 和单个平台，不能直接视为通用容量模型。
05
Agent 运行时预览
Cloudflare Blog
·
Cloudflare 发布开源 early preview @cloudflare/computer，把 agent workspace 设计为由 SQLite 支撑的持久虚拟文件系统，并为其挂接多种执行 backend：轻量文件、Git 和数据处理可在基于 just-bash 的 isolate 中运行，需要 Linux、npm 或原生二进制时再调用 Container，通过 FUSE 与同一文件系统同步。统一的 exec 接口让模型选择 backend，文件操作和执行均可 gated、audited、observed；官方目标是让容器只承担少于 10% 的工作。
为什么值得读：Agent 基础设施正在从“每个任务一座容器”转向状态与执行资源解耦：durable workspace 保留连续性，低成本 isolate 承担水平扩展，容器成为按需工具。它仍是 early preview，尚无公开规模/延迟 benchmark；生产采用前需审计 FUSE 一致性、隔离边界、持久状态恢复和 backend 选择失败模式。
06
硬件—Kernel 研究
arXiv / Northeastern University 与 AMD
·
论文针对 MI300X、B200 一类多分区 GPU，分析 vLLM/SGLang 中 weight projection、MoE 与 attention kernel 的真实 memory trace，并用扩展的 cycle-level simulator 估计跨 partition 访问的 latency 影响。作者按 workgroup 间共享关系把 operand 分为 global、partial 与 private 三类：私有数据可通过 per-workgroup pinning 获益，部分共享数据则需要识别共享 subgroup 并协同调度；统一虚拟地址空间隐藏了 compute 与 HBM 的物理归属，使共享权重、activation 或 KV 访问可能静默变成跨 die 流量。
为什么值得读：随着 GPU 从单 die 走向 chiplet/partition，kernel locality 不再只是 cache hit 问题，还会消耗片上互联并制造 NUMA contention。工作提供了可用于编译器、runtime 和硬件的分类框架，但性能结论来自 trace 加模拟，而不是公开真机 end-to-end serving benchmark。
07
厂商硬件 Benchmark
NVIDIA Technical Blog
·
NVIDIA 测试 BlueField-4 STX 中 88 核 Armv9.2 Vera CPU 的内存驻留存储 primitives，并与一款 x86 CPU 比较。厂商自报 AES-128 加/解密最高 1.43/1.29 倍、Reed-Solomon recovery 3.26 倍、CRC32C 3.67 倍、压缩/解压 3.29/1.72 倍，压缩后加密的两阶段 pipeline 最高 3.21 倍。测试使用单进程内存数据与 OpenSSL、Zstandard、LZ4 等库，控制 buffer、线程与 CPU placement，但明确排除了文件 I/O、磁盘、网络、命令启动和外部设备瓶颈。
为什么值得读：Agent 的 context、persistent memory、KV、日志和制品让校验、加密、纠删码与压缩进入关键数据路径，CPU 可能在 SSD/网络之前成为瓶颈。数字属于 NVIDIA 对未具名 x86 对手的微基准；文章也要求 end-to-end storage/GPU 测试，采购或容量规划不能直接套用峰值倍数。
08
GPU 集群教程
NVIDIA Technical Blog
·
NVIDIA 给出一套不拆分物理 GPU 池的多团队 Kubernetes 模式：每个团队通过 vCluster 获得独立 API server、RBAC、CRD 与 cluster-admin 体验，底层 Pod 仍落到同一 host cluster；KAI Scheduler 用层级 Queue CRD 管理 GPU quota、limit 与 surplus 权重，并与 GPU Operator 的 sharing 能力配合。可复现示例在单张 L40S 上建立三个 team queue，每队保证 0.33 GPU、空闲时可 burst 到整卡，并逐一验证租户只看到自己的 workload。
为什么值得读：GPU 平台常在“共享一个大集群的效率”和“每队独立集群的自治”之间二选一；虚拟控制面加底层统一调度提供了中间层。不过 shared-nodes 只适合可信内部团队，文章明确指出不可信租户还需要 private nodes 以及网络、存储级隔离。
09
正式 Workshop 论文与 Benchmark
arXiv / EuroMLSys 2026
·
LayoutBench 比较三类 S3 多媒体数据布局：每样本一个 object、顺序打包进 tar、以及按列组织为 Parquet。论文用 ImageNet、11 种不同结果规模的查询和 6 套 AWS EC2 网络/内存配置，同时测 retrieval time、传输量与成本。作者发现 tar 依靠连接复用在中小 retrieval 上延迟更低，超大结果集时 Parquet 最快；但 Parquet 因 row-group granularity 在各查询规模都搬运更多数据、占用更多内存，总成本可达另外两种布局的一个数量级。
为什么值得读：数据 loader 的物理布局会决定 GPU 等数据的时间，也会把云 egress、内存与请求开销变成训练成本。该 benchmark 已关联 EuroMLSys 2026 DOI，但结果来自 ImageNet 与 AWS S3/EC2；实际视频、音频、小文件分布、缓存和区域定价仍需重跑。