sgl-project/sglang

一、项目定位

SGLang 是由 LMSYS 维护的开源高性能推理/服务框架，面向大语言模型（LLM）、视觉语言模型（VLM），并已扩展到扩散模型（图像/视频生成）、音频 Omni 等模态。它把 RadixAttention 这类早期学术工作工程化为一个生产级 serving stack，核心卖点是：结构化生成（guided decoding / grammar-based generation）、高吞吐低延迟的连续批处理调度、与 vLLM 类似的 PagedAttention KV cache、以及对 NVIDIA / AMD / Intel GPU / TPU / NPU / CPU / Apple Silicon 等多后端的统一抽象。项目已经走过早期研究原型阶段，进入多硬件、多模态、大规模 RL rollout 支撑的成熟期——从 README 中列出的 v0.5.x 系列发布节奏、大量第三方生态（SMG、RBG、NVIDIA Dynamo、Ray Serve、verl、slime 等）以及“Trusted by Industry and Research”的生产背书可以看出，它已不是实验性玩具，而是 LMSYS 的旗舰基础设施项目之一。仓库结构上，python/sglang/ 是主服务 runtime（Python），rust/ 包含高性能组件，proto/ 定义 gRPC/内部协议，experimental/sgl-router/ 是实验性路由层，docs/ 用 Mintlify 承载文档站，docker/ 覆盖几乎所有硬件后端的镜像，benchmark/ 下积累了大量硬件/模型/调度器的性能回归套件。整体定位：在 vLLM 主导的 LLM serving 赛道里，SGLang 走“更广的硬件面 + 更强的结构化生成 + 多模态原生支持”的差异化路线。

解决什么问题、给谁用

解决的核心问题是：在单框架内同时做到（1）高吞吐、低延迟的 LLM/VLM 在线推理服务；（2）对结构化输出（JSON / 正则 / 上下文无关文法）的高效约束解码；（3）跨 NVIDIA、AMD、Intel、TPU、NPU、CPU、Apple Silicon 的统一部署接口；（4）原生支持扩散模型的图像/视频生成推理；（5）为 RL post-training 的大规模 rollout 提供稳定、可并发的推理后端。典型使用场景：AI 实验室/企业在云上或本地用 Docker 拉起 SGLang 服务跑 DeepSeek、Qwen、Llama 等模型；用 SGLang Diffusion 跑 FLUX/视频扩散模型；在 verl / slime 等 RL pipeline 里把 SGLang 当 rollout engine；通过 SMG / RBG / Ray Serve / NVIDIA Dynamo 做大规模集群调度；在 Apple Silicon Mac 上通过 Metal/MLX 做本地开发和小规模验证。

目标用户包括：（1）需要生产级 LLM/VLM serving 的 ML 工程师和 MLE，他们通过 Cookbook 拿一行命令在自己的硬件上起服务；（2）RL 训练框架开发者，把 SGLang 当 rollout 后端；（3）框架/硬件适配工程师，为 AMD、Intel、NPU、TPU 等后端贡献 kernel 和调度优化；（4）研究者和学生，通过 Mini-SGLang / zero-to-sglang 学习推理引擎设计；（5）企业部署团队，通过 SMG / RBG / Dynamo / Ray Serve 做集群级运维。对这位 GPU kernel / 训练性能工程师而言，最相关的用户画像就是（3）：需要在 SGLang 的 attention 后端、扩散 kernel、跨硬件抽象层里做性能极致优化。

同类项目与差别

• vLLM：vLLM 是 LLM serving 的事实标准，以 PagedAttention 和成熟的 NVIDIA 生态见长。SGLang 在 vLLM 基础上更强调结构化生成的原生支持、更宽的多硬件后端面（AMD、Intel、NPU、TPU、Apple Silicon），并把扩散模型推理内建为第一类公民，同时在 RL rollout 生态里更活跃。
• TensorRT-LLM：NVIDIA 官方栈，深度绑定 TensorRT，在 NVIDIA 硬件上极致优化但硬件锁定严重。SGLang 走开源、多厂商、Python-first 路线，硬件覆盖面远大于 TensorRT-LLM，但单卡极致性能调优深度可能不如前者。
• Triton Inference Server：通用模型 serving，支持多框架多后端，但非 LLM 专用，缺少 PagedAttention、continuous batching、guided decoding 等 LLM 时代的核心优化。SGLang 是 LLM-native 的，在 LLM 场景下吞吐和延迟更有针对性。
• LMDeploy：以 TurboMind 推理引擎和量化/并行优化著称，国内生态强。SGLang 更国际化、多硬件、多模态（扩散/音频）覆盖更广，而 LMDeploy 在量化工程和国内模型适配上有深度积累。
• llama.cpp / MLX：端侧/个人设备推理代表，轻量、CPU/Apple Silicon 友好。SGLang 通过 Apple Silicon 后端与之有部分重叠，但 SGLang 主攻数据中心级多卡多节点服务，llama.cpp/MLX 主攻本地单机场景。

核心能力

阶段：成熟生产阶段（v0.5.x 系列，月级发布节奏，生产级用户背书，但仍在快速迭代——README 中列出的 AWS Trainium、Cambricon MLU、Qualcomm QAIC 等集成明确标注为 in progress，experimental/sgl-router 也显示部分组件仍在孵化）。

技术栈：Python（主 runtime，python/sglang/，pyproject.toml）；Rust（高性能组件，rust/）；gRPC / Protocol Buffers（proto/）；Mintlify（文档站，docs/，docs.json + .mdx）；Docker（多硬件镜像，docker/）；PyTorch（模型执行）；FlashInfer（attention kernel 后端）；NVIDIA CUDA / AMD ROCm / Intel XPU / TPU / NPU / Metal 等多后端；CI: GitHub Actions（.github/workflows）；pre-commit + codespell + isort + linters（.pre-commit-config.yaml, .isort.cfg, .codespellrc）

规模：最近 Release v0.5.21（2026-10-02）、v0.5.20（2026-09-18）、v0.5.19（2026-09-05），约两周一个 release；commit 热点集中在 python/sglang/（19 次/近期）、test/registered、docs/docs、docker/ 等；docs/ 下 610 个条目（文档规模大）；docker/ 下 25 个条目覆盖几乎所有硬件；benchmark/ 下 147 条 benchmark；python/ 下 3715 个条目（主代码体量大）；star 数未在证据中直接给出，需验证；pushed_at 2026-10-12 显示活跃开发中。

二、架构与代码地图

SGLang 仓库在物理上分为四个大区：入口层、调度层、执行层 / kernel 层、工具与实验层。入口层由 python/sglang/srt/entrypoints/ 与 experimental/sgl-router/ 构成，负责 HTTP/gRPC 接入、OpenAI 兼容 API 暴露与 KV-aware 路由。调度层位于 python/sglang/srt/managers/，是 Scheduler、TPCoordinator、IO 调度、Chunked Prefill、HiCache 调度的大脑，决定 batch 组成与 KV cache 分配。执行层覆盖 python/sglang/srt/models/、python/sglang/srt/layers/、python/sglang/srt/mem_cache/、python/sglang/srt/weight_sync/，是模型前向、张量并行、KV cache 管理、权重同步的主战场。kernel 层由 python/sgl-kernel/ 与 python/sglang/srt/cutedsl_kernels/ 等构成，封装 Triton / CuTe / CUTLASS / DeepGemm / DeepEP / FlashInfer 等后端。工具与实验层包括 experimental/sgl-router/（Rust 重写的高性能 router）、benchmark/、docs/、docker/、test/。这种分层让同一套 Scheduler 可以同时驱动 NVIDIA、AMD、Intel GPU、TPU、NPU、CPU、Apple Silicon 等多硬件后端。

一次调用怎么流过这些模块

一次典型在线推理请求路径：1) 客户端通过 OpenAI 兼容 HTTP API 到达 entrypoints/openai/serving_chat.py，被转换为 SamplingParams + tokenized 请求；2) 请求进入 managers/scheduler.py 的 Scheduler，由 continuous batching 逻辑与 chunked prefill 策略决定 batch 组成，同时 mem_cache/radix_cache.py 通过 RadixAttention 做 KV cache 前缀匹配与分配；3) Scheduler 构造 ScheduleBatch 并派发给 TpModelWorker（位于 managers/tp_worker.py 附近），后者调用 models/ 中注册的模型做前向；4) 前向过程中 layers/ 调用 sgl-kernel 的 Triton/CuTe/DeepGemm kernel 做 attention、MoE、quant、TP 通信；5) 采样阶段进入 guided_decoding/ 或 sampling/ 做约束解码，产出 token；6) 结果经 Scheduler 回到 entrypoints 返回流式响应。对于 RL rollout 场景，weight_sync/ 会在 rollout 间隙把更新后的权重同步到推理 worker；对于 disaggregation 部署，prefill 与 decode 调度由 Scheduler 分离，通过 mem_cache/ 的跨节点 KV 传输完成。关键数据结构包括 SamplingParams、ScheduleBatch、RadixCache 节点、TokenPool、LoadStat（发布到 sgl-router）等。

关键类型与函数

扩展点

• 新模型：在 python/sglang/srt/models/ 下新增模型文件，实现 torch.nn.Module 并按 registry 模式注册；VLM/DiT/音频/RM 分别在对应子目录；docs/cookbook/ 加 config 即可生成部署配方
• 新后端（硬件）：在 python/sgl-kernel/ 下新增后端实现（如 ROCm hipify、Metal、XPU），并在 python/sglang/srt/layers/ 与 docker/ 中适配；pyproject_other.toml / pyproject_xpu.toml 等已表明多后端构建机制
• 新 kernel：在 python/sgl-kernel/src/ 或 python/sgl-kernel/csrc/ 新增 Triton/CuTe/CUTLASS kernel，通过 benchmark/kernels/ 下的 benchmark 脚本调优；benchmark/lean_kernel_sweep.py 是自动化 sweep 入口
• 新调度策略：在 python/sglang/srt/managers/scheduler.py 或 scheduler_components/ 中修改 batch 组装逻辑；或在 experimental/sgl-router/src/policies/ 下新增 Rust 路由策略
• 新路由策略（sgl-router）：在 experimental/sgl-router/src/policies/ 或 policies_reorg/ 中实现新的 Policy 接口，并在 factory.rs 注册
• 新前端 API：在 python/sglang/srt/entrypoints/openai/ 下扩展，参考现有 Anthropic/Gemini 适配
• 新 diffusion 模型：在 python/sglang/srt/models/ 下新增 DiT/视频模型，并在 python/sglang/srt/diffusion/ 中集成调度逻辑
• 新 RL 集成：通过 weight_sync/ 与 entrypoints/engine.py 暴露 rollout 接口，参考 verl/slime 集成

最近在动的地方

• python/sglang/srt/managers/scheduler.py：commit #41872 修复 batch_is_full 锁存、#43758 RL weight update 失败处理，调度器是性能与正确性核心
• python/sglang/srt/layers/ 与 python/sgl-kernel/：benchmark/kernels/ 下有大量 fused_moe、allreduce、attention、quant 基准；FlashInfer 版本 bump 到 0.7.1（#43494）
• experimental/sgl-router/：最近提交最密集区域，含 KV indexer gRPC、K8s 发现、load monitor、circuit breaker、多路由策略重构
• python/sglang/srt/mem_cache/：benchmark/hicache/ 与 benchmark/disaggregation/ 表明 HiCache 多级缓存与 disaggregation 是性能热点
• python/sglang/srt/models/：DSV4.1 相关提交 #42159 减少 eager Engram extend 准备，DeepSeek/VLM/视频扩散模型持续适配
• python/sglang/srt/weight_sync/：RL rollout 生态（verl/slime/Miles）依赖权重同步，#43758 修复 cache flush 拒绝时的失败处理
• python/sglang/srt/diffusion/ 或 models 内 DiT：#41940 XPU FLUX.2 Triton SwiGLU bit-exact 支持，扩散模型是新硬件适配重点
• test/ 与 docs/：#43762 VLM throughput floor 重锚、#43688 transformers 5.18/5.19 适配，文档同步活跃

建议阅读顺序

1. README.md 与 docs/INDEX
2. python/sglang/srt/entrypoints/engine.py 与 openai/serving_chat.py
3. python/sglang/srt/managers/scheduler.py
4. python/sglang/srt/mem_cache/radix_cache.py 与 token_pool.py
5. python/sglang/srt/models/ 下任一模型（如 deepseek_v3 或 llama）
6. python/sglang/srt/layers/ 下 moe 与 attention 目录
7. python/sgl-kernel/ 下任一 Triton/CuTe kernel 与 benchmark/kernels/
8. experimental/sgl-router/src/main.rs 与 policies/mod.rs
9. benchmark/deepseek_v3/ 与 benchmark/hicache/ 了解性能回归
10. docker/Dockerfile 与 pyproject.toml 了解多硬件构建

三、本地跑起来（没有 GPU 的 Mac）

安装

1. # 1. 克隆仓库 git clone https://github.com/sgl-project/sglang.git cd sglang
2. # 2. 创建并激活 Python 虚拟环境（推荐 Python 3.10+） python3 -m venv .venv source .venv/bin/activate
3. # 3. 安装 CPU-only 依赖（跳过 CUDA kernel 编译） # 仓库提供了 pyproject_cpu.toml 用于无 GPU 环境 pip install -e "python[cpu]" --extra-index-url https://download.pytorch.org/whl/cpu # 或使用 uv（推荐，更快）： # uv pip install --prerelease=allow -e "python[cpu]"
4. # 4. 验证基础 import python -c "import sglang; print(sglang.__version__)"
5. # 5. 安装开发工具（可选，用于跑测试） pip install pre-commit pytest pytest-asyncio

哪些路径能真跑

['可执行（CPU/MPS/Metal）：\n- python/sglang/srt/managers/ — Scheduler、IO 调度逻辑（部分可 CPU 运行）\n- python/sglang/srt/layers/ — 部分 attention/MoE 实现有 CPU fallback\n- python/sglang/srt/models/ — 模型定义可 import，但推理需 GPU\n- experimental/sgl-router/ — Rust 路由层，完全 CPU 无关，可在 Mac 上编译运行\n- benchmark/simulator/ — 调度器仿真，纯 Python 可跑\n- test/ 下标记为 cpu 的测试用例\n\n仅可读代码（需 Colab T4 验证）：\n- python/sgl-kernel/ — Triton/CuTe/CUTLASS kernel，必须有 NVIDIA GPU\n- python/sglang/srt/cutedsl_kernels/ — CuTe DSL kernel\n- python/sglang/srt/mem_cache/ — PagedAttention 实际执行依赖 CUDA\n- python/sglang/srt/weight_sync/ — 权重同步涉及 NCCL\n- 所有 benchmark/kernels/ 下的 benchmark 脚本\n- Docker 镜像中 Dockerfile.cu134、sgl-deep-ep.Dockerfile、sgl-deep-gemm.Dockerfile 相关路径']

最小可运行

1. # 1. 验证 sglang 包可导入 python -c "from sglang.srt.entrypoints.engine import Engine; print('Engine import OK')"
2. # 2. 验证 sgl-router 编译（Rust 组件，CPU 无关） cd experimental/sgl-router cargo build --release cd ../..
3. # 3. 运行 scheduler 仿真（纯 Python，无 GPU 依赖） python benchmark/simulator/bench_runner.py --help # 或跑一个简单仿真： python benchmark/simulator/bench_serving.py --model dummy --num-requests 10
4. # 4. 验证模型定义可加载（仅 import，不跑推理） python -c "from sglang.srt.models.llama import LlamaForCausalMLM; print('Model class import OK')"
5. # 5. 跑 CPU 标记的测试子集 python -m pytest test/ -k "cpu" -x --timeout=60 # 或跑 sgl-router 单元测试： cd experimental/sgl-router && cargo test

测试

['测试框架： pytest + pytest-asyncio，部分用 unittest\n目录结构：\n- test/ — 主测试目录\n- test/registered/ — 注册的功能测试\n- test/manual/ — 手动测试脚本\n- experimental/sgl-router/tests/ — Rust 路由层测试（cargo test）\n\nCPU 子集运行：\n``bash\n# 只跑标记为 cpu 的测试\npython -m pytest test/ -k "cpu" -x --timeout=120 -v\n\n# 跑 sgl-router 测试（纯 Rust，Mac 原生）\ncd experimental/sgl-router && cargo test --all-targets\n\n# 跑特定模块测试\npython -m pytest test/test_sheduler.py -x --timeout=60 # 需验证文件名\n``\n\n预估耗时：\n- CPU 子集：5-15 分钟（取决于用例数量）\n- sgl-router cargo test：2-5 分钟\n- 完整 test/ 套件（含 GPU 测试）：不可在 Mac 上跑']

调试

• 日志开关： - SGLANG_LOG_LEVEL=DEBUG — 全局日志级别 - SGLANG_LOG_TO_FILE=1 — 日志输出到文件 - RUST_LOG=debug — sgl-router Rust 日志 环境变量： - SGLANG_FORCE_CPU=1 — 强制 CPU 模式（需验证是否生效） - SGLANG_DISABLE_CUDA=1 — 禁用 CUDA 初始化 - CUDA_VISIBLE_DEVICES="" — 隐藏 GPU（Mac 上无实际 GPU） Profiling 入口： - examples/profiler/ — 包含 nsys 分析工具 - .agents/skills/llm-torch-profiler-analysis/ — torch-profiler 分析脚本 - sgl-router 内置 metrics 端点（启动后访问 /metrics） 断点建议： - python/sglang/srt/entrypoints/engine.py — Engine 初始化入口 - python/sglang/srt/managers/scheduler.py — 调度器主循环 - experimental/sgl-router/src/server/routes/chat.rs — 路由请求处理

CI

['CI 系统： GitHub Actions（.github/workflows/）\n\nPR 会被卡住的检查：\n1. pre-commit — 代码格式化（black、isort、codespell）\n2. Lint — .github/linters/ 下的自定义 lint 规则\n3. 单元测试 — 标记为 required 的 test/ 子集\n4. sgl-router 编译 — experimental/sgl-router 的 cargo build/test\n5. 文档构建 — docs/ 的 mint 构建（仅修改 docs 时触发）\n\n注意：\n- 完整 GPU 测试不会在 PR CI 上跑（需要自托管 runner）\n- 部分硬件特定测试（XPU、NPU、TPU）有独立 workflow\n- .github/CI_PERMISSIONS.json 控制哪些检查是 required']

坑

• 1. sgl-kernel 编译失败：python/sgl-kernel/ 依赖 CUDA 编译，Mac 上会报错。解决方案：使用 pyproject_cpu.toml 或设置 SGLANG_DISABLE_CUDA=1（需验证） 2. FlashInfer/DeepGemm 不可用：这些库仅支持 NVIDIA GPU，import 时会 fallback 到慢路径或直接报错。阅读代码时注意 has_flashinfer() 等条件检查。 3. sgl-router 需要 Rust 工具链：Mac 上需先 brew install rust 或 curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh。 4. 测试用例 GPU 依赖：test/ 下大部分测试假设 CUDA 可用。Mac 上只跑 pytest -k "cpu" 或 sgl-router 测试。 5. 模型权重下载：即使只读代码，某些测试会尝试下载 HF 模型。设置 HF_HUB_OFFLINE=1 或 TRANSFORMERS_OFFLINE=1 避免网络依赖。 6. Python 版本兼容性：仓库要求 Python 3.10+，Mac 自带 Python 3.9 可能不够。推荐 brew install python@3.12 或使用 pyenv。 7. PyTorch CPU 版本功能缺失：torch.cuda 相关 API 在 CPU 版本不可用。阅读代码时注意 torch.cuda.is_available() 分支。 8. Docker 镜像不适用于 Mac：docker/ 目录下的镜像多为 CUDA/ROCm 专用。Apple Silicon 上如需容器化，参考 docker/arm64.Dockerfile（需验证是否可用）。

四、维护者与社区

Release 节奏稳定且频繁：最近三个版本 v0.5.19（2026-09-05）、v0.5.20（2026-09-18）、v0.5.21（2026-10-02）间隔约两周，说明已进入成熟的双周发布周期。Commit 热度高度集中在 python/sglang/（热点值 19），表明核心 runtime 仍在快速迭代；test/registered、.github/workflows、docker/Dockerfile、docker/Dockerfile.cu134、docs/、scripts/release 等也有频繁更新，说明 CI、多硬件镜像、文档、发布流程是并行的活跃面。单日可见多条提交（如 2026-10-12 就有 10+ 条跨 kernel、diffusion、scheduler、CI、doc 的提交），整体处于高并发维护阶段。

流程与 Review 风格

流程清晰且偏轻量，不强制 CLA/DCO： 1. README 明确写：'Fork the repository and create a branch. For larger changes, discuss your proposal in a GitHub issue or on Slack.' 说明大改动需先 Issue/RFC，小修可直接 PR。 2. README 要求：'Run pre-commit run --all-files before submitting.' 仓库根目录存在 .pre-commit-config.yaml，启用 pre-commit 钩子。 3. README 要求：'Open a PR describing the change and how you tested it. Include benchmarks or accuracy evaluations when relevant.' 说明测试证据与 benchmark 是重要提交材料。 4. .github/CODEOWNERS、.github/workflows、.github/labeler.yml 等表明存在自动化标签与目录级 owner 审查路由；.github/pull_request_template.md 提供 PR 模板。 5. docs 子目录 docs/CONTRIBUTING.md 与 docs/README.md 给出文档贡献的本地 mint dev 流程，说明 docs 与代码是同一仓库、同一 PR 流程。 6. 未在 README / CONTRIBUTING 中看到 CLA/DCO 强制声明，推断为 Apache-2.0 项目标准签署-off（需验证是否要求 DCO sign-off）。

从近期 Issue/PR 看，Review 风格偏具体、重证据、快响应： - Issue #43557、#43765、#43743 等都在同一天内被复现、定位到具体函数（compact_attention_hip、mhc_fused_post_pre、forward_absorb_rocm_core），说明维护者会精确到 API 行号级别。 - PR 标题高度规范化，如 [FlashInfer] Add startup autotuning for MegaMoE、[AMD] Fuse AITER DSA decode RoPE and KV-cache preparation、[NPU] Fix W4A8 MoE scale_bias sharding for tensor parallelism、[Perf][mem_cache] Persistent lazy eviction heap for the UnifiedRadixCache Full component (bit-identical order)——这种标签化标题本身就是 Review 文化的体现：期望 PR 一句话说清模块+动作+影响。 - CI 相关 PR（如 #42048、#43468、#43784）频繁出现，说明对 per-file timeout、GB300 资源调度、hanging test 快速失败等工程细节非常敏感，Review 会关注 CI 成本。 - Issue #40877（SM120 生产报告）下有 9 条讨论，#39499（dLLM Serving Roadmap）有 19 条评论，#40843（GLM-5.3 DFLASH 重复退化）有 13 条评论，说明复杂问题会深度讨论，不回避 hard case。 - 多个 good first issue / help wanted Issue 仍长期未关闭（如 #2271、#2272、#3365、#8072、#9889），说明人手紧张，对新人友好但响应可能滞后。

渠道

• https://slack.sglang.io/
• https://github.com/sgl-project/sglang/issues
• https://github.com/sgl-project/sglang/releases
• https://docs.sglang.io/docs/developer_guide/contribution_guide
• https://roadmap.sglang.io/
• https://lmsys.org/blog/
• https://www.sglang.io/events
• mailto:sglang@lmsys.org
• https://x.com/lmsysorg
• https://www.linkedin.com/company/sgl-project/

这里的规矩

• 得体的做法： - PR 标题使用 [模块] 动作 + 对象 标签化格式（如 [AMD]、[NPU]、[Perf][mem_cache]、[diffusion][xpu]），与现有提交风格一致。 - 提交前跑 pre-commit run --all-files，并附上测试命令与结果（README 明确要求）。 - 涉及性能改动时附上 benchmark 或 accuracy 评估（README 明确要求）。 - 大改动先在 Issue 或 Slack 讨论（README 明确要求 'For larger changes, discuss your proposal in a GitHub issue or on Slack'）。 - 对 bug 报告给出最小复现步骤 + 环境（从 Issue #43557、#43743、#43765 等高质量 bug 报告推断，社区期望精确到函数/API 层面）。 - 文档改动可直接在 GitHub 在线编辑或用 mint dev 本地预览（docs/README.md 明确鼓励）。 不得体的做法： - 不发 Issue 直接提大型重构 PR（README 明确要求先讨论）。 - 跳过 pre-commit / CI 检查提交（README 明确要求跑 pre-commit）。 - 性能 PR 不带任何 benchmark 或对比数据（README 明确要求 'Include benchmarks or accuracy evaluations when relevant'）。 - 在 Issue 里只说 'it crashes' 不给 trace / 复现脚本（从维护者反复要求 trace 推断）。 - 向 sglang@lmsys.org 发无上下文的企业合作邮件（README 明确该邮箱用于 'enterprise adoption, technical consulting, sponsorship, or partnership inquiries'，且有专门格式）。

维护者现在最想要的帮助

• 多硬件后端 kernel 适配与修复：从活跃 Issue 与提交看，AMD（ROCm）方向急需帮助——#43765（DSV4 compact_attention_hip 依赖 aiter 已删除的 pa_decode_sparse）、#38709（dcp-size > 1 在 ROCm 上 forward_absorb_rocm_core 解包错误）、#38710（aiter_allreduce_fusion 日志与代码不一致）、#43730（ROCm NGRAM speculative decoding HSA 错误）均为未解决的痛点。NPU 方向：#43519（2026 Q4 NPU 多模态 roadmap）、#40880（W4A8 MoE scale_bias sharding）仍在推进。XPU/Intel GPU 方向：#41940（FLUX.2 bit-exact Triton SwiGLU on XPU）、#42048（XPU CI 优化）显示刚起步。这些方向人手明显不足。
• Kernel 性能优化：#2271（Triton 解码 kernel 长上下文优化，high priority）、#2272（cuDNN attention backend，high priority）、#9889（torch.nonzero 性能热点）、#3365（logits gather vs all_gather）都是长期开放的 good first issue / help wanted，说明维护者欢迎外部 kernel 级性能贡献。
• 调度器与内存管理：#38371（UnifiedRadixCache lazy eviction heap）、#41076（SparsePrefillWorkspace OOM）、#43204（mamba cache 分配失败）、#33713（unified_cache MAMBA 组件 pruning 错误）表明 mem_cache / scheduler 层仍在演进，需要既懂调度又懂内存布局的贡献者。
• Diffusion / 多模态推理：#43731（Diffusion 并发实例端口冲突）、#43708（音频时长无界）、#43710（Qwen-VL 视频全分辨率解码）、#43705（GLM-V 视频预算绕过）、#41126（diffusion warmup 可配置化）显示 SGLang Diffusion 刚进入生产，bug 密度高，是切入的好机会。
• 文档与 Cookbook：docs/README.md 明确鼓励 'add a recipe for a new model, improve existing docs, or fix a typo'，cookbook 是 config-driven（src/snippets/_deployment.jsx + per-model config），门槛低、产出可见度高，适合无 GPU 时以纯文档方式贡献。
• CI / 测试基础设施：#42048、#43468、#43784 等 PR 显示维护者在持续优化 per-file timeout、GB300 资源调度、hanging test 快速失败——这类贡献不需要 GPU，但极受重视。
• Auto-tuner / 自动化调优：Roadmap #13363 'sglang auto tuner' 标签 good first issue，16 条评论仍开放，说明是维护者想要但没人做的方向。

五、切入方案

它现在缺什么（你无 GPU 也能补）

第一批 PR

怎么知道自己站住了

• 30 天内：sgl-router 顶层 README 与架构文档 PR 被合并，获得至少 1 位核心 reviewer approve。
• 60 天内：LoadStat 合约测试 + router benchmark PR 被合并，在 Slack 被 @ 参与 router 相关 Issue 讨论。
• 90 天内：成为 experimental/sgl-router/ CODEOWNERS 或 reviewer 列表中出现的名字，或独立 review 他人 PR 并被采纳。
• 持续信号：在 Issue #43557（PD runtime）、#16565（MUSA）等活跃 Issue 中出现 router 视角的评论，显示跨模块理解。
• 量化信号：router benchmark 被后续 PR 引用为回归基线；文档页被 docs/ 内部链接引用。