sgl-project/sglang

删除 Common KV 连接层 3 处死桩，恢复 ABC 强制

值得快速精读，尤其是 PR body 的验证方法论：作者用 AST 遍历证明死代码不可达、用 abstractmethod 集合对比证明 ABC 语义变化、用镜像类实测构造行为，是"删除代码"类 PR 的高质量范本。核心设计决策是"删除而非修正"——通过恢复 ABC 强制，把未来后端的实现遗漏从运行时无声失败提前到构造期显式报错，这类"用类型/抽象约束消灭一类 bug"的思路可直接借鉴。

STAGING_REQ 处理去重为共享 mixin，覆盖 Mooncake/NIXL

值得快速精读。关注三点：① 用 AST 等价性验证「move 而非 rewrite」的方法论——先证明两份旧拷贝完全相同，再证明新 mixin 与旧实现归一化后等价；② mixin 与基类方法的选择理由（`MoriKVManager` 无 staging 支持，放基类会埋雷）；③ 把「子类需提供哪些属性」写进 docstring 的隐式契约文档化实践。对 disagg 维护者，`staging_handler.py` 从此是 staging 消息处理的唯一入口，值得收藏。

支持 Transformers 序列化 BnB4 组件加载，统一准入契约

值得精读。该 PR 展示了如何为“允许 Transformers 接管某类检查点”设计清晰的准入边界（`uses_native_transformers_bnb4` + `NativeComponentLoaderRequired` 双闸门），以及如何通过基类钩子（`resolve_native_transformers_model_class`）将架构相关逻辑从通用加载路径中隔离。阅读重点：`component_loader.py` 的 `load_native` 泛化逻辑与 `text_encoder_loader.py` 的 encoder-only 类解析迁移，可为后续新增量化检查点格式提供参考模板。

修复 Pixtral 多图请求在 CUDA IPC 下切片代理导致的 HTTP 500

值得精读。核心设计是“把 CUDA IPC 包裹固定为 pipeline 最后一步”的生命周期保证，而不是给代理加切片能力；`_finalize_mm_items` 的 hook 顺序、`copy.copy` 后重置派生字段、以及 fail-loud 基数校验都是可迁移到其他多模态处理器的模式。建议重点关注 `_postprocess_mm_items_before_transport` 的可重写约定，以及测试中用 `object.__new__` 构造被测对象的技巧。合并后建议观察一段时间多模态请求与 CI 稳定性，确认无周边 processor 回归。

草稿注意力后端白名单迁移到共享注册表并开放扩展

适合快速阅读，作为理解 SGLang server_args 注册表扩展模式的小样例。若你正在维护外部注意力后端集成，建议关注 add_draft_attention_backend_choices 的调用时机（必须在 ServerArgs 构造前）。若你关心配置系统重构，本 PR 与近期大量 config 相关 PR 展示的注册表模式一致。

完整集成 dots.note.omni 多模态模型与 MTP 推测解码

值得精读，尤其对维护多模态与推测解码框架的工程师。重点阅读 `dots_hybrid_backend.py` 的 DP padding 元数据 normalize 逻辑、`pool_configurator.py` 的 SWA 草稿层记账，以及 `nextn.py` 的全共享 MTP 实现。同时需要关注作者在评论中提到的 follow-up PR（#36195）对 DSA 默认后端兼容性的修复，当前合并状态下该配置存在已知缺陷。

SWA 池 loc 翻译钳制墓碑负值，防 cuda-graph 非法访问

值得快速精读（约 15 分钟）。这是一个典型的 KV 池边界防御 bugfix，展示了 tombstone sentinel 的标准处理模式：收敛到保留的 padding sink 槽位而非让负值逃逸。值得关注三个点：① 为什么 `slot 0` 是安全的“垃圾场”；② 为什么负 loc 在已捕获的 cuda-graph 重放下是非法访问而非普通越界；③ 缺少单测的后续补强方向（可为 `translate_loc_from_full_to_swa` 的墓碑输入构造最小回归测试）。

Qwen3.8-27B 三卡部署配方统一到 1cf2b8c 重测

值得精读，虽然是纯文档 PR，但包含三类可迁移知识：1）mem-fraction 扫描方法论——如何区分“状态池饥饿 / graph capture OOM / 请求期 OOM”三种失败模式并据此决定 pin 与置灰边界；2）统一内存计价与宿主内存冲突——DGX Spark 上 mem-fraction 直接撞 earlyoom 阈值的排障链（exit -15 → journalctl -u earlyoom）；3）docs-as-config 的声明式组织——jsx 中 stripPrefixes / flags / disabled 的组合方式让“剥离旧 pin、重发新 pin”可组合，对维护多卡多量化矩阵的团队有借鉴意义。阅读时建议关注第 4、5 个 commit（镜像统一）与最后 commit（清理陈旧说明），它们才是整个方案完整落地所必需的部分。