SGLang Cookbook 迁移指南：Legacy 部署生成器到 Config 驱动五维矩阵的维度映射

SGLang Cookbook 迁移指南Legacy 部署生成器到 Config 驱动五维矩阵的维度映射【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang本文是仓库中 .claude/skills/cookbook-migrate-model/references/dimension-mapping.md 的系统性展开。SGLang 文档站的 cookbook 正在把「每模型一份 monolith 部署生成器」docs/src/snippets/autoregressive/model-deployment.jsx迁往「共享渲染引擎 每模型纯数据 config」docs/src/snippets/configs/vendor/model.jsx。这篇指南回答迁移中唯一的映射决策问题一个 legacy 控件该变成 5 维矩阵hw × variant × quant × strategy × nodes里的哪一维、还是 Playground 里的哪个轴生成命令允许做哪些归一化改写策略strategy分层依据什么信号。读完你可以独立完成任意模型页的迁移设计画出 5 维映射表、套用命令改写表、按 signal-driven 规则分层、按 verified 规则摆放 cells并用与 pilot 相同的代码生成 审计脚本校验等价性。1. 迁移上下文这份参考文件在整个管线中的位置dimension-mapping.md由 .claude/skills/cookbook-migrate-model/SKILL.md 在运行时按需加载用于把某个 legacy generator 的选项空间翻译成新的数据模型。它只讲映射决策字段级 schemaconfig/cells[]/playgroundFeatures的完整契约属于另一份文档——.claude/skills/cookbook-add-model/references/authoring-reference.md引擎扩展规范在 .claude/skills/cookbook-add-model/references/engine-axis.md。需要先理解的目标结构Deployment 矩阵引擎docs/src/snippets/_deployment.jsx其头部注释逐字段声明了 config 契约。默认形态是「固定五维」——硬件目录HARDWARE_CATALOG并集config.hardwarevariants/quantizations/strategies/nodesOptions四个选项列表cells[]以{hw, variant, quant, strategy, nodes}元组为键查表。Playground 引擎docs/src/snippets/_playground.jsx基于 diff 的覆盖组件。头部声明了它认识的轴attention、moe、parsers、speculative、pdDisagg、hicache、hisparse以及通用的flagSelects。legacy 源头docs/src/snippets/autoregressive/下的每个*-deployment.jsx如qwen35-deployment.jsx——迁移中它是唯一事实来源single source of truth你在转写它而不是改进它。迁移工作流的一条铁律决定了下文所有规则的性质_deployment.jsx/_playground.jsx在迁移 PR 中只读模型专属功能一律以 config 数据表达见 .claude/skills/cookbook-migrate-model/SKILL.md 硬规则 4。因此映射决策的最终输出几乎总是一个config {...}字面量。2. Legacy 控件归宿决策5 维矩阵还是 Playground 轴五维矩阵负责决定一份配方属于哪个格子Playground 轴负责在选中格子的命令之上做纯 flag 的增删覆盖。核心分水岭是引擎只能做纯 flag diff做不了「耦合修改」。把下表作为每次迁移的决策总表Legacy 控件新归宿规则hardware 单选match.hw目录 id 原样照搬。目录外的硬件 → 写config.hardware条目——例如 A100{id:a100, label:A100, vram:80GB, vendor:nvidia}并入 NVIDIA 分组行、Xeon{id:xeon, label:Xeon, vram:host RAM, vendor:intel}引擎据此渲染新的 INTEL 分组任意 vendor key 均可。合并型芯片如 MI300X/MI325X拆成两个 id、复制同样两份 cell 数据cells 刻意做反规范化model-size / model-name 单选variants每个可部署 checkpoint 族一个 variant无 variant 轴时只给一个{id:default}此时modelNames键去掉 variant 半段quantization 单选quantizations用真实精度 idbf16/fp8/fp4/int4/…。即使不同厂商 checkpoint 不同也只用一个fp4id用hw\|variant\|quant三键在modelNames里路由NVFP4 on Blackwell vs AMD MXFP4 是先例「某个硬件上变灰」自然由「该格子是否存在」决定与命令其他部分耦合的开关改 TP/mem/EP或 legacy 页用operating-point 措辞标注的单选strategiesPlayground 只能做纯 flag diff做不了耦合修改。例Qwen3.5 的 MTP 开关在三个 H100 组合上会抬 TP → 拆成low-latency(MTP on) /high-throughput(MTP off)。命名也算耦合GLM-5.1 / Kimi-K2.6 的dpattention只追加--dp N --enable-dp-attention未耦合但选项自带 Low Latency/High Throughput 副标题——页面自己命名了 operating point → 归strategies。GPU 数量单选GLM-4.7、MiniMax-M2.5/2.7→ budget-tier strategieslegacy 的 SUPPORT 矩阵由格子存在性保留。strategy 数量跟随页面 operating points1 个 → 仅balanced2 个 →low-latencyhigh-throughput3 个 → 完整三件套详见 §7只增删自己 flag 的开关Playground 轴按规则烘焙但 parser 与降低精度的 flag 除外--reasoning-parser/--tool-call-parser永不烘焙进 cells——Deployment 命令无论 legacy 默认或实测命令如何都不带它们parsers轴在其上追加DSv4 惯例cells 镜像 legacy generator 的 parsers-OFF 输出。降低精度的开关同样永不烘焙见 §4 caveat。其他纯 flag 开关legacy 默认 ON → 烘焙进 cells 并声明该轴用户可删除diff 呈红色删除线默认 OFF → cells 保持干净轴只做预设。MTP/EAGLE 预设 →speculative轴dp-attention 在「被页面当作 operating-point 划分」或「耦合」时 → strategy见上行否则 →attention.dpAttn仅对特定组合隐藏的选项如 Xeon 上隐藏 spec缺省格子不为 legacy 控件产不出组合造 cell引擎自动将它们置灰。# Error:伪命令 → 不产 cell在 tips 和/或 chip 的disable/disableReason里解释耦合的次级旋钮如 mamba cache V1/V2cells Playground 轴按 legacy 耦合关系在每个 cell 烘焙正确值Qwen3.5MTP ⇒ NVIDIA 上加--mamba-scheduler-strategy extra_bufferAMD/Xeon ⇒ V1/不加 flag在 §2 tips 写清耦合关系——同时仍要像对待每个 legacy 功能一样把它暴露成 Playground 轴。只烘焙不够mamba 旋钮与 KV Cache DType 同属「单个选择」形态因此归并到通用flagSelects轴——纯 config 声明无需引擎 PR上表落地为两条总原则每个 legacy 控件都必须活成一个交互控件某个维度或某个 Playground 轴绝不允许退化成 tips 里的一句话。而模型专属控件是config 数据而非引擎代码轴处理器直接从config.playgroundFeatures读取 options/flags/env/gatingMegaMoE 的 W4A4 完全就是 DSv4 在既有moe轴上的 config 数据无任何逐模型引擎修改。凡能套进现有轴数据 schema 的控件就是纯 config、到此为止。带标题的单选、且语义是「剥离一整个 flag 族」如 Nemotron3 的 KV Cache DType--kv-cache-dtype统一归并到通用flagSelects轴 →纯 config声明一个{ id, title, stripPrefixes, options }列表即可不需要引擎 PR真实仓库示例见 docs/src/snippets/configs/Qwen/qwen3.8.jsx 的flagSelects块。只有当控件的形态是flagSelects表达不了的才需要在迁移之前的独立引擎 PR 上新增一次性通用原语永远不做 model-named handler其向后兼容推理按 key opt-in、不在 opt-out 集内在 engine-axis.md。3. 命令改写表迁移中唯一允许的归一化迁移不得现代化——legacy 的 env、flag、TP、docker tag、版本串一律原样转写。允许的归一化只有下表在 .claude/skills/cookbook-migrate-model/SKILL.md 硬规则 1 中称之为五个别名改写LegacyNewpython(3) -m sglang.launch_server引擎负责输出sglang servecells 只存 flags--model X/--model-path X--model-path {{MODEL_NAME}}modelNameskey--tp-size N--tp N--speculative-algo X缩写--speculative-algorithm X——Playground spec 轴只按完整首 token剥离/推导缩写别名会逃过开关、导致 flag 重复叠加--speculative-algorithm NEXTN--speculative-algorithm EAGLE——NEXTN 是 EAGLE 的别名同一算法。cells 与预设统一归一化为 EAGLE绝不把 NEXTN 与 EAGLE 作为两个独立speculative预设暴露会形成重复 chip。当实测命令用到 NEXTN 时保留一行出处说明 the bench reported NEXTN, an alias of EAGLE--expert-parallel-size N--ep N——Playground EP 旋钮只识别/剥离--ep长格式会逃过开关、导致重复叠加缺省给每个cell 追加--host {{HOST_IP}}、--port {{PORT}}--nnodes N --node-rank … --dist-init-addr …字面量删除改由match.nodes: multi-NnodesOptions条目驱动——引擎在最后一个并行度锚点之后自动注入三元组与多节点头注释env-var 命令前缀原样进cell.env[]绝不丢弃、绝不归一化按 legacy 生成顺序输出的 flags重排为规范序--trust-remote-code→--model-path→ 并行度--tp/--dp/--enable-dp-attention/EP→ MoE → 调优 →--host/--portPlayground 插入锚点依赖此顺序。调优跨度内保持 legacy 相对顺序保证命令仍可肉眼 diffNEXTN → EAGLE 的别名关系可以在仓库源码里直接印证SGLang 的推测解码注册表在 python/sglang/srt/speculative/spec_registry.py 里把NEXTN列为保留别名_RESERVED_ALIASES frozenset({NEXTN})注释明确 NEXTN - EAGLEpython/sglang/srt/server_args.py 的--speculative-algorithm文档字符串把 NEXTN 与 EAGLE 并列列出。这解释了为何两套预设会形成重复 chip、为何speculative轴必须统一为单个eagle预设。3.1 改写表之外的 pilot 经验CaveatsPlayground 的moe.ep旋钮只认识--ep把 legacy 的--expert-parallel-size N归一化为--ep N别名见上表旋钮才能识别并剥离它。multiNodeHints只给「需要手工 NIC env 的互联」的硬件用gb200 级标准 IB 的 H100 多节点不需要任何 hint。Hints 在两种运行模式Python/Docker上都会显示因此docker run专属 flags 放在硬件条目的multiNodeDockerFlags里引擎会写进命令本身。dockerImages只收录 legacy 页钉死的 tag。CPU/Xeon 保持不映射回退:dev并附 install from source 提示。降低精度的 flag--kv-cache-dtype fp8_e4m3、W4A4 风格运行时量化遵循一条确定性规则迁移中不问、直接执行作为 legacy可选项/开关提供 →绝不选中它cells 镜像精度安全一侧即使 legacy 默认就是有损侧。但该选项必须活成 Playground 控件——用户的选择权不得退化成 tips 提一句。在合适轴上以 config 数据表达DSv4 把 W4A4 门控在megamoeQuant后面Nemotron3-Ultra 的 KV Cache DType None/fp8_e4m3/bf16 单选则归并通用flagSelects轴——声明一个flagSelects块纯 config无引擎 PR烘焙在配方无条件/默认命令里 →原样保留。legacy 测量就是在它上面跑的且 fp8 KV 缓存减半、剥离可能让配方 OOM。预期模式legacy AMD 配方常规追加--kv-cache-dtype fp8_e4m3for memory efficiencyGLM-5 的 NVFP4 路径也带它——全部保留。只有迁移走这个自动保留此处忠实优先。新页面遇到同类 flag 则要与维护者确认flag-and-confirm见 authoring-reference.md §2.2 与 review checklist。4. Playground 轴opt-out不是 opt-inlegacy 页面没提某功能不代表该轴要被砍掉。每个 cookbook 默认携带通用轴attentionTP/CP/DP-Attn、MoE 模型还有moebackend EP、parsers、speculative、pdDisagg、hicache——然后按需加模型专属轴且只删除该模型确实用不了的轴hisparse仅 DSA 模型MegaMoE 仅 DeepSeek-V4 Blackwell。对某个 variants/hw 子集无意义的旋钮用disabledisableReasonper-chip 约束表达而不是删掉——例如 MoE backend/EP 在 dense variant 上置灰。其他轴级细则speculative预设必须覆盖页面上真实出现过的每个算法否则被剥离格的基线无法恢复——但折叠别名NEXTN 是 EAGLE 的别名§3 改写表因此用 NEXTN 跑过 bench 的页面只发一个eagle预设。Pilot 史Qwen3.5 曾同时发过两者已改正为仅 EAGLE。MTP 的--max-running-requests提示引擎自动当某 cell 的命令开了推测解码存在--speculative-algorithm却无--max-running-requests时Deploy 面板 Playground 自动渲染琥珀色提示SGLang 否则把它封顶在 48。它是flag 驱动而非 strategy 驱动——每个页面无需额外书写不要在 §2 prose 里重复造。parsers轴是 add-only--reasoning-parser/--tool-call-parser永不出现在任何 Deployment cell见 §2——轴在基础命令之上追加因此切换 parser 渲染的是绿色追加行绝不是删除线。5. 验证Verified机制与 accuracy 数据摆放三条与映射直接相关的政策机制绿色Verified需要实测数据 flag 与实测命令逐字相等SKILL.md 硬规则 3。cells[]排序要让经验证的旗舰 cell 排第一——cells[0]是页面初始选中项。当实测命令与 generator 默认不一致时Qwen3.5bench 跑了NEXTNSGLANG_USE_CUDA_IPC_TRANSPORT1generator 输出EAGLE 融合 flags经验证的 cell 镜像测量generator 默认以未验证的兄弟 cell 存活。两者都作为speculative预设提供并在 §2 tips 解释分裂原因。config.accuracyLabels是必填项——只要 benchmarks 带 accuracy 数据就 MUST 声明引擎不带任何默认评测集缺了它 accuracy 行会静默不渲染。defaultAccuracy会给某 variant 的每个有 benchmark 条目的 cell 上色——但在严格政策下优先只给被测量的 cell 写 per-entryaccuracy。6. strategies 维度signal-driven 分层硬规则strategy 数量跟随页面 operating pointsid 永远取自 DeepSeek-V4 词汇表low-latency/balanced/high-throughput绝不用mtp/no-mtp这类模型专属 id1 个 operating point单份配方、无性能开关→ 单个balanced。绝不为了填满 chips 凭空发明第二份配方。2 个 operating point→low-latencyhigh-throughput。当 legacy 开关是 MTP/推测解码时方向是确定性默认直接执行不问MTP on →low-latencyMTP off →high-throughput。理由推测解码在低并发下压低每 token 延迟但饱和时 draftverify 开销反超收益——DSv4 的 high-throughput 配方禁用 MTP 正是同一原因。其他开关按同样的服务语义映射——两个反复出现的high-throughput 信号是dp-attention ONMLA-attention 模型与EP / DPEP ONMoE 模型都把工作跨 rank 切分以换取饱和吞吐代价是每请求延迟。方向适用于被选为 strategy 维度的那个开关§2旁边若有纯 flag 的 spec 开关则仍是 Playground 轴、按 legacy 默认烘焙。仅当 legacy 页记载了相反倾向如 enable MTP for high throughput才停下来找维护者确认。3 个 operating point→完整三件套理想情形例如 GPU 预算档 2/4/8。Signal-driven 分层硬规则某 cell 归low-latency/high-throughput只允许基于 legacy 源里出现的信号——显式性能开关MTP/推测、dp-attention、EP、gpuCount…、命名 recipe/strategy 复选框、选项副标题Low Latency/High Throughput、或点名 operating point 的 prose。读这种信号属于 SGLang 层级的服务语义MTP 在任何厂商的硅上都偏向延迟所以任何迁移者都能给任何厂商的 cell 分层无需硬件专属判断。无信号 →balanced——legacy 沉默本身就是信息页面把该命令当作该硬件的通用 operating point 提供balanced逐字转写它。绝不凭自己的硬件直觉推导倾向这组 flag 看起来像吞吐调优依据实测证据重新分层是硬件所有者的后续 PR不属于迁移范畴。映射不到任何维度的开关、或疑似未记载的倾向 → 停下来问维护者。分层按(hw × variant × quant) 组合生效、不只按页面整体operating point 少于页面的组合其 cell 停在语义诚实的档位。有信号佐证倾向的单份配方进对应档DSv4 的 RTX PRO 6000 →low-latency工作站卡、低 batch 的 Marlin 配方无延迟/吞吐倾向的通用配方进balancedQwen3.5 的 Xeon →balanced。无倾向的配方绝不因页面开关映射落点而被塞进low-latency/high-throughput——那读起来像语义谎言CPU high-throughput。页面strategies列表是实际用到的档位的并集混排[low-latency, balanced, high-throughput]页面、GPU 用两端而 CPU 用中间完全合法引擎按当前选中项自动置灰未用 chips 并 auto-snap无需额外 config。偏离惯例例如如何命名纯 GPU-budget 档位需要维护者签字。6.1 各模型族策略基线表下表来自 2026-06-10 的PAGE 级survey 草图。迁移时必须从活着的 generator 重新推导——页面会漂移先例Kimi-K2.6 的活页面有一个 survey 笔记里没有的 spec 开关且 per-combination 规则意味着被门控/隐藏的开关——通常在 Xeon、AMD 或 NVFP4 这类单配方 quant 上——会产生 page 级草图看不到的balanced组合。MDX 的 strategy 描述按 DSv4 风格讲服务语义single-user chat / typical multi-user / batch jobs至多加一行模型专属说明——绝不写成开关/迁移视角的解释。FamilystrategiesNotesGemma4low-latency(MTP on——legacy 开关自带 Lower Latency 副标题) /high-throughput(MTP off)mi300x 隐藏该开关 → 单配方 →balancedtrio 并集Qwen3.5 Xeon 模式variants e2b/e4b/12b/31b/26b-a4bcheckpoint 单选 Standard(BF16)/QAT(q4_0) → 经modelNames映射为 quant idAMD 超 widget 范围的配方由 prose 承载——cells-from-prose vs tips 由维护者裁决vision/audio 调用 prose 原样延续deployment matrix 为纯文本标准gemma4 branch 版本 → 速度下降、MMLU/GSM8K 精度保持注意 few-shot vs run_eval harness 脚注专用 multi-arch dev 镜像原样Nemotron3-Ultradpattention 带 Low latency/High throughput 副标题命名规则但三个性能控件叠加——multi-value DP-Attention(2/4/8) × MTP × EP——用 §2 表设计档位映射需维护者签字仅 NVIDIAh100→gb300带 per-quant 验证硬件 SUPPORT 矩阵 → 缺省 cellModel 单选 quant 维BF16 / NVFP4 Blackwell-onlyTP 单选 8/16——TP16 是两节点 →nodes维kvcache 单选(None/fp8_e4m3/bf16) →flagSelects轴纯 config通用原语已合并——无引擎 PRlaunch_server spec-V2 env 前缀原样专用dev-nemotron3-ultra(cu13)镜像原样not in any stable releasemain branch 版本不可复现 → 丢弃整条实测结果速度与精度除非能钉到支持 PR/commitday-0 规则GLM-4.5, GLM-4.6low-latency(TP legacy checkbox 的 MTP) /high-throughput(TPDPEP)GLM-4.7low-latency(2 GPUs) /balanced(4) /high-throughput(8)——gpus 2/4/8 SUPPORT 矩阵确认命名档位是 GPU 预算实测最佳 B200 TP2 NVFP4 → 验证 cellGLM-4.7-Flashlow-latency(tp1 legacy checkbox 的 MTP) /high-throughput(DP)由 legacy dp/mtp checkbox 推导GLM-5, GLM-5.1low-latency(dpattention off) /high-throughput(dpattention on)——dpattention 单选自带页面级 Low Latency/High Throughput 副标题命名规则§2spec 为纯 flag、默认 ON、AMD 上隐藏 → NVIDIA 两侧都烘焙 speculative轴NVFP4 隐藏全部开关 → 单个无信号配方 →balanced页面发 trio 并集Kimi-K2low-latency(tp8) /high-throughput(dp4ep4)variants instruct/thinkinginstruct 上 reasoning chiphideKimi-K2.5, K2.6low-latency(dpattention off) /high-throughput(dpattention on)——与 GLM-5.1 相同的命名副标题模式K2.5 的 spec 预设带--speculative-draft-model-path …eagle3-mlachip 门控到 h200/b300K2.6 活页面有 NVIDIA-only 的 spec 开关、默认 OFF → 仅speculative轴、不烘焙survey 漏记Qwen3.6, Qwen3-Nextlow-latency(MTP on——legacy 推测开关) /high-throughput(MTP off)Xeon 隐藏开关 → 单配方 →balanced页面发 trio与 Qwen3.5 pilot 同模式Kimi-Linear, MiniMax-M2, Qwen3, Qwen3-Coder, Qwen3-Coder-Next单个balanced——一份配方、无性能开关规则1 operating point →balanced渲染成一个 chipQwen3-Coder-Next 在活页面上无 spec 维仅 quant × toolcall × mambaCache——早前草图误并入 Qwen3.6MiniMax-M2.5, M2.7low-latency(2) /balanced(4) /high-throughput(8tp8ep8)——确认命名档位是 GPU 预算Xeon(M2.7) 是单个无倾向配方固定 TP6→balancedper-combination 规则Qwen3.5 Xeon 先例Qwen3.5 (DONE — pilot)low-latency(MTP on) /high-throughput(MTP off)Xeon 的单个无倾向配方 →balanced页面发完整 trio见 §7Qwen 系 variant 扇出variants 可部署 checkpoint按尺寸排序235b-instruct,235b-thinking,235b,30b-*,32b, …不要把 instruct/thinking 这一类塞进 strategies。Original 混合 chip 裁剪到 legacy 页实际测量过的那些。7. 完整工作示例Qwen3.5 pilotPR #27848一份决策日志按出现顺序记录。它的 legacy 源正是仓库里现存文件 docs/src/snippets/autoregressive/qwen35-deployment.jsx——该生成器内的耦合逻辑可以直接对照例如generateCommand()里 35B/27B H100 BF16 MTP 时把 TP 抬到 2 并跳过--mem-fraction-static122B H100 FP8 MTP 抬到 4397B B200 NVFP4 MTP 走 tp2ep2且 MTP on 强制 Mamba V2对应本文 §2 表格里 mamba cache 旋钮与 MTP 耦合 那一行的真实来源。策略拆分成 Playground 开关因为 MTP 在三个 H100 组合上与 TP 耦合35B/27B BF16tp2↔tp1mem0.88122B FP8tp4↔tp2。规范命名low-latency MTP onlegacy 默认high-throughput MTP off。Xeon 只有一个 operating pointlegacy widget 在那里隐藏了 MTP 开关且配方无延迟/吞吐倾向 → 其 12 个 cell 停在balancedper-combination 摆放把它们当开关映射副作用塞进 high-throughput 会读成语义谎言。结果186 cells 87 low-latency 87 high-throughput 12 balanced页面发完整 trio引擎按选中自动置灰未用 chips。验证 cell 跟随测量H200/397B/BF16/low-latency SGLANG_USE_CUDA_IPC_TRANSPORT1env --speculative-algorithm EAGLEbench 报 NEXTN即 EAGLE 别名——归一化为 EAGLE§3 实测 flag 集减去 parser flags实测同时开了两个 parsercells 永不携带——在 benchmarks 头注释说明。其余所有 cell generator 的 parsers-OFF 输出逐字照搬。speculative轴上只有一个eaglespec 预设重复的 NEXTN 预设被删。FP4 单一 quant id用hw|variant|quantmodelNames 键 →nvidia/...NVFP4b200/b300vsamd/...MXFP4mi355x。Xeon作为config.hardware条目vendor:intelcells 带--device cpu --disable-overlap-schedule无 docker 映射。Playground 轴按 §4 的完整通用集——attentionTP/CP/DP-Attn、moeDeepEP backend EP 旋钮dense variant 上disable原因、parsers、speculativeNEXTN 与 EAGLE 都出现在页面 → 两个都收录……在修正后仅保留 EAGLE、pdDisagg、hicache。剔除不适用项hisparse仅 DSA、MegaMoE仅 DSv4 Blackwell。legacy 的--expert-parallel-size 8归一化为--ep 8供 EP 旋钮使用。Benchmarks仅一条条目被测量的 cell——无条目 cell 直接渲染 pending不需要空 stub。legacy 的速度数据被丢弃它们测在漂移的 main branch 构建上没有版本锚点速度只在精确 release tag/commit hash 下迁移——硬规则 2因此条目只带 accuracyGSM8K MMMU经accuracyLabels样本数放notes无sglang_version。Codegen 审计脚本按模型适配一个 generator-port 脚本逐字输出 cells 字面量一个独立审计脚本git show出原始generator、stubuseState/useEffect、对每个组合经 indirect eval 调其generateCommand(values)、与新的 cells 做 token diff只允许预期差异。legacy 源码用git show main:path读取——不是HEAD:迁移分支的 HEAD 已删除该文件删除 commit 之后审计会坏。此后任何 cells 修订含重命名都要重跑审计。Pilot 结果185/185 完全一致 1 处有意覆盖。脚本归档在 PR #27848 描述里折叠 details 块。继承而来的不可行组合原样保留如 mi325x 上 122B BF16 tp1244GB 权重 vs 256GB VRAM 且 mem-fraction 0.8——保持黄色并列在 PR body 供再验证跟踪。浏览器 smoke probe 陷阱React 18 下在一个同步 eval 批次里连发多次程序化.click()它们之间的 DOM 读取是陈旧的看起来像 snap-logic 的 bug。一次 eval 只点一次然后等 settle。8. 从仓库源码印证引擎「轴」与flagSelects的真实形态映射规则之所以能成立是因为引擎确实以「config 声明即可用」的方式工作仓库源码可以逐条印证轴清单即引擎契约docs/src/snippets/_playground.jsx 头注释列出识别的轴attention/moe/parsers/speculative/pdDisagg/hicache/hisparse/flagSelects并说明轴级showWhen(base)可以让「Deploy 面板没开启该功能」的轴整个不渲染flagSelects被描述为config-declared LIST of single-selects, each with its own title strip-prefixes options (no per-feature code)——与 §2 的纯 config、无引擎 PR完全对应。轴的默认状态机制则落实在_deployment.jsx的matchDims/overlayDims双引擎一致注释MIRROR中该机制正是「轴是覆盖层、不参与 cell 查表」的代码基础。flagSelects的真实数据形态docs/src/snippets/configs/Qwen/qwen3.8.jsx 中实际声明了三个 flagSelects 行replaySsmstripPrefixes: [--enable-linear-replayssm-spec]选项含disabledisableReason、mambaRadixGDN Radix Cache StrategystripPrefixes: [--mamba-radix-cache-strategy]、kvCacheDtypeKV Cache PrecisionstripPrefixes: [--kv-cache-dtype]选项fp8对应flags: [--kv-cache-dtype fp8_e4m3]。这就是 §2/§3.1 里 KV Cache DType / mamba 旋钮只写 config、不碰引擎 的仓库级样板——每个 stripPrefixes 对应的正是被烘焙进 cells 的 flag 族。归一化后 flag 的规范顺序被引擎锚点依赖authoring-reference.md §2.2 与_deployment.jsx头部都要求--model-path在前紧随--trust-remote-code--host/--port收尾Playground 插入覆盖时以这些锚点定位——所以 §3 改写表的「重排到规范序」不是排版偏好而是引擎正确性的前提。审计闭环docs/scripts/check_cookbook_configs.mjs会对每个可达选中项探测 config 中的谓词型字段如verificationStatus函数、showWhen从工具层面阻止「拼写错误伪装成绿色徽章」或「谓词运行崩溃」上到页面——它与 §7 第 7 条的 token 级审计一起构成双保险。9. 迁移输出清单对照自检一次完整迁移在映射维度的收尾产物可对照检查每个 legacy 控件都已落位维度或轴无 tips-only 控件cells[]全部能解析到modelNameskeycell 内无--nnodes/--node-rank/--dist-init-addr/--host/--port字面量host/port 走{{HOST_IP}}/{{PORT}}占位符每个supportedHardwareid 至少有一个 cell实测被测量 cell 是cells[0]且 flags 与实测命令等价mod 别名改写与 parser 剥离带 accuracy 的页面声明了config.accuracyLabels策略档位全部由 legacy 源中的信号驱动最终把策略映射表按信号分组、每行一条理由与审计 PASS 数放进 PR body 供硬件所有者签字。【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考