sgl-project/sglang

新增 RTX 5090 的 DeepSeek-V4 部署配置

值得快速浏览，用于理解 cookbook 配置数据如何组织（硬件登记与部署 cell 分离、verified 状态语义、flags 的注入约定）。设计上可借鉴的是把硬件元数据作为配置而非引擎代码，以及用 Not Verified 状态透明区分未经基准验证的命令。无需深入精读，因为不涉及运行时逻辑。

M3 注意力 GEMM 全面 fp8 化，prefill 最高提速 66%

值得精读。三个 commit 相互独立、各有用处：升序 topk 契约、page128 支持、fp8 模式。重点关注：`m3_fp8_attn_gemm_enabled` 的推导式开关与 kill switch 设计、per-tensor scale 以 `Optional[float] = None` 端到端传递并归一化到 `unit_scale()` 的边界约定、`q_scale` 折入 `sm_scale`（同时作用 QK dot 与 sink logit）而 `k_scale` 不能碰 sink 项的数学约束，以及 warp-wise 升序排序与 fmha_sm100 early-exit 机制的契约互动。测试方法论（fp8 vs 反量化 bf16 参考的 parity 策略 + CUDA graph 位精确断言）也值得直接复用。

禁用隐式 PyTorch 头，KV VMM stub 构建从 12.2s 降至 0.2s

值得作为 `load_inline` 隐式头文件开销的典型案例快速了解，也可作为后续批量 `load_inline` 调用的优化模板；无需精读深究。

Inkling 短卷积状态收敛到单 metadata，移除池级缓存

值得精读，尤其适合关注 attention backend metadata 生命周期与 CUDA graph buffer 管理的工程师。三个设计决策值得借鉴：(1) cache ownership 应该由调用方而非池来承担，且用 AST 扫描与微基准论证移除缓存的 blast radius；(2) per-step metadata 采用可变 `msgspec.Struct`、由 prep 就地填充，与 `FlashAttentionMetadata` 对齐；(3) 用构造性等价（`at_layer_idx(L).conv[s]` 与 `conv[s][L]` 等价）配合 bit-identical 模型校验，而不是用 mock 计数测试去钉死 wiring。

调度器侧扁平化 prompt top logprobs 数组，两跳 IPC 省约 30ms

值得精读。三个设计点尤其值得借鉴：(1) 把数据面“组装前移 + 可选字段 + 默认 None”的兼容策略——新字段只对 opt-in 请求非 None，未使用方 wire 不变；(2) 共享校验原语 `build_flat_input_top_logprobs_arrays` 在 scheduler 与 tokenizer 两个进程复用，保证 fallback 语义一致；(3) 提交了 env-gated 的可复现序列化 microbench。需要留意的是 ch-wan 提出的缓存遮蔽与 idx 校验两个未解决的健壮性问题，未来若把 flat 格式扩展到 MIS 或其他请求路径，应先补齐这些防御。

修复 FULL_MASK verify mask 超 max_bs 越界复用，防调度器挂死

值得精读：这是一个把“为什么 `bs <= max_bs` 对 FULL_MASK 也是充分边界”论证清楚的修复，frozen struct 防止 `max_bs` 与 `buffer` 失配的设计模式可借鉴；同时其 commit 历史展示了“动态计算 vs 分配期固化”两种方案的取舍，对理解预分配 buffer 的容量管理有帮助。

移植 Kimi Linear 的 DCP + DSPARK 支持并修复验证后状态漂移

值得精读，尤其关注三点：verify 后状态提交的时机与后端能力门控设计、DCP 下 workspace 尺寸推导（head count × dcp_size 与真实 draft 宽度）、以及 allocator page_size 对齐的 KV 释放修复。对实现 speculative decoding、混合注意力模型或数据并行 + 推测解码组合的工程师有直接借鉴意义。

为 Inkling-Small 增加 DGX Spark 多节点部署指南与配置

值得快速浏览：它展示了“部署文档如何产品化”的设计取舍，尤其是 multiNodeDockerFlags 与 multiNodeHints 的职责划分、以及 Mintlify 限制下双引擎重复实现的应对方式。若你在维护 cookbook 或文档站点的部署命令生成器，建议精读 _deployment.jsx 的 fabricFlagsOf 与 _playground.jsx 的 HW_MULTINODE_DOCKER_FLAGS，并留意两处同步的维护约定。