Prhub

#23622 Again update DeepSeek V4 cookbook

原始 PR 作者 fzyzcjy 合并时间 2026-04-24 15:12 文件变更 2 提交数 11 评论 2 代码增减 +32 / -9

执行摘要

再次更新 DeepSeek V4 部署指南,新增配方案例和 Docker 示例

继续完善DeepSeek V4部署文档,确保文档中的命令行参数真实可用。基于实际端到端测试,将更多硬件与配方的组合标记为已验证,并根据人类反馈纠正cp配方的标志逻辑,消除歧义和重复设置。

建议部署DeepSeek V4的用户阅读此PR以获取最新的命令行参考。开发者和文档维护者可关注cp配方中参数单一来源的处理方式,以及如何通过VERIFIED_RECIPES集合优雅地管理验证状态。此PR体现了sglang项目对文档易用性和准确性的持续投入。

讨论亮点

本PR没有来自人类审核者的评论。仅有的两个评论来自gemini-code-assist[bot],内容为每日配额已达上限的通知,不涉及技术讨论。

实现拆解

  1. 简化配方选择器UIdeepseek-v4-deployment.jsx):移除recipe选项集合中每个条目的subtitle字段,使界面只显示配方名称,更加清爽。
  2. 扩展已验证配方集合:在VERIFIED_RECIPES Set中添加了B200 Flash/Pro的balancedmax-throughputcp组合,以及H200 Flash的low-latencybalancedmax-throughput组合。这些组合经过端到端验证,生成的命令不再被注释掉,用户可直接复制使用。
  3. 修复cp配方标志生成:调整buildCommand函数中cp分支:根据人类最新指示,不再设置--mem-fraction-static 0.70(移除覆盖),并将--max-running-requests改为条件设置——Blackwell Pro为256,其他情况(含H200)为1024。确保每个参数只出现一次,避免混淆。
  4. 补充Docker使用文档DeepSeek-V4.mdx):在Docker镜像表格下方添加指向安装指南的链接,并提供一个包含GPU挂载、共享内存、端口映射和模型缓存挂载的最小docker run示例,方便用户快速启动容器。
文件 模块 状态 重要度
docs_new/src/snippets/autoregressive/deepseek-v4-deployment.jsx 命令生成器 modified 5.68
docs_new/cookbook/autoregressive/DeepSeek/DeepSeek-V4.mdx 用户指南 modified 2.68

关键符号

DeepSeekV4Deployment buildCommand buildPDDisaggCommand getInitialState

关键源码片段

docs_new/src/snippets/autoregressive/deepseek-v4-deployment.jsx core-logic

核心变更文件:更新了已验证配方集合、简化了 UI、调整了 cp 配方的参数生成逻辑。直接影响用户复制的命令。

// cp 配方标志生成部分(简化抽取)
if (recipe === 'cp') {
  // ... 之前已加入 --tp、--moe-a2a-backend deepep 等通用标志
  flags.push('--mem-fraction-static 0.78');
  // 人类指示(2026-04-24):不再设置 --mem-fraction-static 0.70 覆盖
  // 只设置 --max-running-requests 一次:Blackwell big 用 256,其余用 1024
  if (isBig && hardware !== 'h200') {
    flags.push('--cuda-graph-max-bs 256');
    flags.push('--max-running-requests 256');
  } else {
    flags.push('--max-running-requests 1024');
  }
  // H200 cp 在非多节点时加上 DeepEP 大 SMS 标志
  if (!multinode) flags.push(DEEPEP_LARGE_SMS_FLAG);
}

评论区精华

没有提炼出高价值讨论线程

当前评论区没有形成足够清晰的争议点或结论,后续有更多讨论时会体现在这里。

风险与影响

本PR本质上是文档和命令模板的更新,不涉及运行时逻辑,风险较低。主要风险在于:

  • 命令参数正确性:cp配方中--max-running-requests的取值调整需要与sglang serve的实际支持能力一致。已根据人类指示和所有涉及的硬件配置核对,确保取值合理。
  • 版本同步:随着未来模型权重更新或SGLang版本变化,已验证的配方可能需要重新验证,但此PR本身不会引入兼容性问题。
  • 用户侧:获得更全面、已验证的部署命令,减少试错成本;新增的Docker示例使首次使用容器部署的用户更容易上手。
  • 系统侧:不影响任何运行时逻辑或API行为。
  • 团队侧:文档维护者可通过修改VERIFIED_RECIPES集合轻松管理已验证状态,但需注意保持与实际测试同步。
文档变更 已验证状态更新

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。

完整报告

参与讨论