01
论文预印本
arXiv
·
SmartGen 面向网络带宽有限的 prefill/decode 分离部署,把 KV 迁移拆成三条路径:prefill 阶段根据 profile 主动推送关键条目,decode 阶段并行获取本地与远端 KV,后台 speculative path 最终补齐完整缓存。作者在阿里云 L20/A100 实例、25 Gbps RDMA、Llama 与 Qwen 长上下文测试中指出,48K prompt 的完整 KV 传输可显著长于 prefill;相对完整传输基线,SmartGen 自报 time-to-second-token 最高降低 4.3 倍,并保持后续 decode 性能与精度相当。
为什么值得读:P/D 分离并不自动意味着更好的首 token 之后延迟;租用型云实例的网络可能先成为瓶颈。该工作把“哪些 KV 先搬、缺失 KV 如何补取、何时补齐完整状态”做成同一传输引擎,但收益依赖选择器准确度、prompt 长度、带宽和模型结构,且论文未附公开实现。
02
编译器基础设施
PyTorch Blog / Meta
·
Meta 介绍其 Triton 下游分支 fbtriton 的持续同步机制:Agent 根据文件、符号与既有复杂变更的依赖,把上游提交分进大批低风险 bundle 或需保序的 risky chain,并分别跟踪落后上游天数与未摄取 backlog。验证按成本分层:L1 在每个 diff 运行 LIT、Triton 单测和 kernel 正确性;L2 在 trunk 周期运行 tritonbench shape sweep、分布式训练等可二分测试;L3 由生产团队按需执行耗费大量 GPU 小时的 workload 并签字确认指标。
为什么值得读:编译器 fork 的风险不是只会编译失败,还可能表现为训练/服务效率、编译时延或模型指标的静默漂移。分层验证让低成本信号挡住常见错误、昂贵集群测试留给高风险变更;文章也明确指出 Agent 可处理冲突和归因,但必须置于确定性安全护栏之内。
03
论文与开源实现
arXiv / 清华大学与腾讯
·
CoMem 利用下层和中层更偏语义理解、上层更偏预测的分工:写入时只把每个 context chunk 计算到中间层并缓存 residual tensor,读取时检索固定数量的相关状态,再仅重算 query-conditioned 上层,因此在固定检索预算下,读侧模型计算和显存不随已存上下文总长增长。作者在 Qwen3-8B 上报告 RULER 97.05、LoCoMo 38.27;单查询、bf16/SDPA、NVIDIA H20、128K 的 adapter-free 控制中,自报显存由 89.36 GB 降至 18.26 GB、prefill 加速 7.83 倍。
为什么值得读:它把长上下文压缩从 token/slot 轴推进到 layer 轴,为“缓存到多深”提供质量—成本旋钮。论文已开放代码,但效率数据来自单查询 harness,尚未测量自然多跳 workload 的 retrieval latency、批处理、并发 serving、存储和网络开销。
04
论文预印本
arXiv
·
MemTxn 是位于 answer model 外部的 memory governance layer:Ordered PatchTest 判断拟写入值是否得到原始来源支持,Temporal Resolver 在冲突事实间决定应用可见版本,持久化 snapshot journal 则在故障后恢复完整 application-visible preimage。作者报告,在 item-disjoint 审计中接受 60 个受支持原值并拒绝 179 个 hard negatives;面对 LongMemEval-S 与 LoCoMo 的持久多键故障,可在不知道实际物理写集合时恢复声明的完整 active map。
为什么值得读:持久化 Agent memory 一旦写错,错误会跨会话传播;数据库原子性只能保证物理写入,不能保证事实受来源支持或冲突版本正确可见。MemTxn 提供了接近数据库事务的应用层契约,不过结果来自合成审计和现有 memory benchmark,真实多租户系统还要处理权限、并发写、删除与隐私政策。
05
论文预印本
arXiv / Red Hat
·
论文把多租户 GPU admission 建模为多类、多资源排队网络,并将 pending queue 拆成 quotable workload 与 unfeasible workload:前者在稳定条件下有界,后者若不重配集群就不存在有限等待承诺。对可报价作业,effective server count 由 CPU、内存、GPU 等向量装箱约化决定;作者证明多维资源下的最优 admission ordering 为 NP-hard,并在 Kubernetes Kueue 与 DRA 资源上验证瓶颈维度识别、Little's Law 及 Erlang-C 的保守估计方向。
为什么值得读:用户真正关心的不只是“排队中”,而是能否获得可信的开始时间或明确的不可行原因。该方法为 Kueue/Slurm 类控制面提供可解释的等待报价框架,但依赖 Poisson arrival、建模假设与中等利用率实验,preemption feedback、fair sharing 和拓扑约束仍需更广生产验证。
06
论文预印本
arXiv
·
FeatFix 关注 diffusion feature caching 中一个浪费点:系统为检查 draft drift 已在少量 layer—timestep 位置算出 exact block output,却常只用它测误差后丢弃。该方法把同一 incoming state 下的完整精确 block 输出直接转发,重置局部 residual,又避免只替换 token/channel 或重算整个 timestep。作者在 FLUX、Qwen-Image、HunyuanVideo-1.5 与 DiT-XL/2 四类 image/video backbone 上自报,相对 Vanilla 最高 6.70 倍加速并保持有竞争力的输出质量。
为什么值得读:这是一种典型的系统复用原则:既然 verification 已经支付完整 block FLOPs,就应让精确结果同时承担 correction。它不需要重训 checkpoint,但整体收益仍由上游 draft/cache policy、验证点密度、质量指标和不同 GPU kernel 实现共同决定。
07
论文预印本
arXiv
·
论文在原生 DeepSeek-V4-Flash 中冻结局部 MoE 状态,只改变数学等价的专家聚合语义,以区分 operand representation、accumulator precision 与 reduction order。作者报告一个 layer-5 分叉中,720 种 A-mode 顺序形成 10 个 continuation basins,B-mode 的 720 顺序形成 360 个精确结构类与 11 个 basins;控制实验还表明,即便当前输出 token 相同,差异也可写入持久 attention state,在后续 decode step 才改变 router、预测与文本。
为什么值得读:跨 GPU、kernel 或 serving backend 做一致性验证时,只比较最终 token 可能漏掉潜伏状态分叉。该工作建议把 operand conversion、累加精度和规约拓扑纳入 MoE runtime 的数值兼容合同;作者也强调这是受控因果可能性,不代表生产环境中的普遍发生率。
08
候选版本
FlashInfer
·
FlashInfer 0.6.16rc4 是 0.6.16 的候选版本,修复输出 scale 不兼容 cubin 的拒绝与过滤、MoE JIT 的 SM107 映射、SM103 FP4 autotuner cache 检查、XQA 的 PDL load ordering 与 SM90 FP8 draft-mask dispatch,并限制 TensorRT-LLM routed-MoE backend 只在支持的架构上启用;同时让 CuTe-DSL 架构守卫可感知环境,并约束 normalization 的 DSL dispatch。
为什么值得读:这些改动都位于架构分派、预编译 artifact 与新精度路径的边缘,错误可能表现为错误 cubin、构建失败或静默选择不兼容 backend。它仍是 RC,不宜因 GitHub 标记为 latest 就直接替换稳定 pin;应与 vLLM、SGLang 或 TensorRT-LLM 的依赖矩阵一起测试。
09
开源补丁发布
DeepSpeed
·
DeepSpeed 0.19.3 汇集多项训练稳定性修复:ZeRO-3 coalesced all-gather 的输出和量化 scale buffer 改为按参数 dtype,异步 I/O wait 关闭文件描述符以避免泄漏,ZeRO 1/2 在 average_tensor 中等待所有 IPG bucket producer streams;版本还校验动态 loss scaling 参数、默认启用 bf16 overflow 检查、支持 AutoEP 与 ZeRO-3 zero.Init source modules,并修正 AutoTP 层级模块路径。
为什么值得读:这类补丁不提供醒目的吞吐数字,却直接影响长期训练中的 dtype 正确性、文件描述符耗尽和 stream 生命周期。使用 ZeRO-3、CPU/NVMe offload、AutoTP 或 AutoEP 的团队应优先审阅相关 PR,并在 checkpoint 恢复、混合精度和长时间运行上做回归。