6000D 双机 DeepSeek-V4-Pro 推理优化计划

适用环境：174.1.51.5 + 174.1.51.7，每台 8 张 RTX PRO 6000 Blackwell Server Edition
当前部署：DeepSeek-V4-Pro，16 张 GPU 组成一个完整实例
当前约束：模型暂时只能使用全部 16 张 GPU，无法额外复制一套模型进行 PD 分离
计划版本：2026-07-31 15:25:00 CST

当前执行状态与阶段档案

阶段档案规范：正文只保留最终成功实验、有效结果和结论； 失败尝试压缩到末尾的经验教训。阶段完成时删除“暂不能下结论”等过渡内容。

0. 先看懂双机通信

在分析 TP16 性能前，先区分设备、传输后端与 NCCL 参数。 完整解释和本次网络误配置复盘见 《6000D 双机通信与 NCCL 术语入门》。

400G 是每条物理 Ethernet 链路的标称线速，不是“TCP 速度”或“RDMA 速度”。同一条链路可以承载 TCP，也可以承载 RoCE/RDMA； 400 Gbit/s ≈ 50 GB/s 只是单向理论上限，NCCL 的 algbw/busbw 与端到端模型吞吐都不能直接等同于该数字。

当前 6000D 机内没有 NVLink。单机 8 卡由 PCIe 连接： GPU0–3 与 GPU4–7 各自在本地 PCIe Switch 内通信，两组之间还要经过 Host Bridge 和 CPU/NUMA 互联。NCCL 机内日志中的 P2P/IPC 是 CUDA P2P over PCIe； 两机之间则使用 mlx5_0/mlx5_3 双 Rail NET/IB + GDRDMA。Phase 2 最终代码已加入机内 PCIe P2P 全矩阵、 单机 8-rank 和双机 16-rank NCCL 微基准；正式数值在最终复跑后写入阶段档案。

1. 目标与原则

1.1 最终目标

在不做 PD 分离的前提下，定位 DeepSeek-V4-Pro 在双机 6000D 上的端到端瓶颈，并提高：

• 满足 TTFT、TPOT 等 SLO 时的最大吞吐。
• 长上下文 Prefill 性能。
• Decode 输出吞吐和单请求 TPOT。
• 混合流量下的稳定性与 P95/P99 时延。
• 16 张 GPU、PCIe 和双 Rail 计算网的有效利用率。

1.2 核心原则

1. 先找关键路径，再调参数。
2. 先用端到端指标确认问题，再用 Timeline 找到阶段，最后才用 Kernel Profiler。
3. Prefill、Decode 和混合干扰必须分别测试。
4. 一次只改变一个变量，每项优化都要保留可复现的 A/B 结果。
5. 单算子更快不代表服务吞吐更高，最终结论必须回到真实请求和 SLO。
6. Profiling Run 只用于定位，不能与无 Profiler 的正式性能结果直接比较。

2. 当前最值得验证的瓶颈假设

3. Profiling 总体流程

端到端性能地图
    ↓
服务内部指标与硬件计数器
    ↓
Nsight Systems 时间线
    ↓
确定 1-3 个主要瓶颈
    ↓
Nsight Compute 或专项 Microbenchmark
    ↓
提出优化并做单变量 A/B
    ↓
回到完整 Benchmark 和 SLO 验证

不要直接对完整服务运行长时间 Nsight Compute。它的开销很高，也会生成巨大的报告。应先用 Nsight Systems 找到占关键路径的 Kernel，再构造小型复现。

4. Phase 0：冻结可复现环境

正式测试前，每个 Run 必须保存以下信息：

• 两台机器的 GPU、Driver、CUDA、NCCL 版本。
• vLLM 或 SGLang 的镜像名、镜像 ID、Git Commit 和 Python 包版本。
• 模型目录、权重文件校验信息和模型配置。
• 完整 Docker Run 与服务启动命令。
• 完整 Benchmark 命令。
• TP、DP、PP、EP 拓扑。
• Attention、NSA、Indexer、MoE、GEMM 和通信 Backend。
• NCCL_SOCKET_IFNAME、NCCL_IB_HCA、NCCL_CROSS_NIC 等通信变量。
• GPU Memory Fraction、Context Limit、Active Request Limit、KV Cache Dtype。
• CUDA Graph、Chunked Prefill、Prefix Cache 和投机解码状态。
• 运行前后的 nvidia-smi、容器列表和网络状态。

建议每次运行生成：

results/<RUN_ID>/
  run_manifest.json
  run.log
  summary.csv
  summary.jsonl
  aggregate.csv
  report.md
  cases/
  server/

基线约束

• 初始基线不启用 MTP、EAGLE、DSpark 等投机解码。
• 初始基线使用唯一随机 Prompt，避免 Prefix Cache 影响。
• 短 Prefill 与 Decode 点执行一个 Warm-up；昂贵的 32K/128K Prefill 不做同形状 Warm-up。
• 隔离测试点在 Warm-up 后、正式计时前清空 Prefix Cache，避免首条测量请求复用 Warm-up 前缀。
• 快速定位 Run 先执行 1 次；只有进入里程碑基线后才执行 3 次并计算变异系数。
• 正式结果使用无 Profiler 运行。
• Profiling 只捕获预热后的少量 Engine Step。

5. Phase 1：建立阶段化性能地图

本阶段当前实现与结果维护在 Phase 1：双机 SGLang TP16 快速性能地图实施记录。 代码采用单一 Shell 入口 run_quick_map.sh，不修改或调用旧的全天全量脚本。

最终 Run dsv4pro-phase1-full-20260730-220916 已完成： Head 与 Worker 均通过双 Rail NET/IB + GDRDMA 门禁， 9 个固定点和 3 个混合 A/B 结果共 12/12 成功，总用时 28 分 36 秒。 单请求 32K/128K Prefill 输入吞吐为 2,652.76/2,710.16 token/s； 1K → 1K Decode 的 Output TPS 从 C=1 的 31.41 提升到 C=64 的 647.42。

最值得继续归因的现象有两个：32K Prefill 从 C=1 增至 C=16 时， 聚合输入吞吐只提高 17.3%，TTFT P95 却从 12.335 秒增至 162.087 秒； 在 C=32 Decode 中注入一个 128K Prefill 后，Output TPS 下降 24.08%， TPOT P95 增加 66.55%。Phase 2 将围绕这两个现象采集硬件时间序列。

5.1 当前固定快速矩阵

长度应以当前已验证的服务容量为上限。如果 128K 不可用，先降到 64K，但必须在 Manifest 中记录原因。

5.2 混合干扰 A/B

1. 先运行有限的 1K → 1K, C=32 Decode 对照流量。
2. 再次运行相同 Decode 基准流量，并等待 Benchmark 确认进入正式测量。
3. 正式测量开始 10 秒后注入一个 128K → 1, C=1 长 Prefill；不额外执行 128K Warm-up。
4. 比较 Output TPS、P95 TTFT、P95 TPOT 与 P95 E2E 的变化。

该 A/B 已完成：注入 128K Prefill 后，Decode Output TPS 从 455.68 降至 345.95 token/s，TPOT P95 从 65.88 ms 增至 109.73 ms。它证明存在聚合级干扰， 但逐请求调度时间线仍由后续阶段补齐。

5.3 本轮运行与停止策略

• 固定矩阵不做 Add-16 搜索，也不按 SLO 提前终止。
• 快速 Run 每个 Case 只执行一波请求，即 num_prompts=C，默认重复 1 次。
• 单个 Case 失败会记录错误并继续；服务失去健康状态则中止，避免连锁无效结果。
• 断点续跑只有在 meta.json 为成功且原始 Benchmark JSON 可重新解析时才跳过。
• 进入里程碑基线后使用 3 次重复；自适应并发搜索仍由后续完整容量实验负责。
• 如果少量 Case 已稳定暴露足以改变调查方向的异常，可由用户决定提前结束并进入归因阶段；必须在 Manifest 和报告中记录未执行项。

不能把“最大成功并发”“最高 TPS 并发”和“满足 SLO 的最大并发”混为同一个值。

5.4 当前采集范围

本轮已实现的请求层指标

• 实际成功、失败和超时请求数。
• 实际输入、输出和总 token 数。
• Request Throughput。
• Input、Output 和 Total TPS。
• P50/P95/P99 TTFT。
• P50/P95/P99 TPOT。
• P50/P95/P99 ITL。
• P50/P95/P99 E2E。

本轮明确不采集

Scheduler Step、逐请求 Queue Time、显存分解、GPU/CPU/网络时间序列和 Kernel Timeline 不伪装成当前已有能力；它们分别由后续硬件指标与 Profiling 阶段补齐。

6. Phase 2：同步采集轻量硬件指标

本阶段的设计、代码改动与结果同步维护在 Phase 2：硬件与资源竞争归因档案。本阶段重放长 Prefill、并发 Prefill、 普通 Decode、长输出 Decode、长上下文 Decode，以及 1K → 1K, C=32 的混合 A/B。首轮 Run dsv4pro-phase2-20260731-130125 在 26 分 26 秒内完成 8/8 个结果； 最终采集代码固定到提交 30664faa41f8，完成最终复跑和汇报后才进入 Phase 3。

6.1 首轮归因结果

• 混合负载再次稳定复现：Decode Output TPS 下降 24.03%，TPOT P95 增加 66.79%，E2E P95 增加 63.30%。
• 128K Prefill 注入窗口两节点 GPU 平均利用率约 99%，功耗约 274 W，频率稳定；显存每卡约 83.2–83.4 GiB，只剩约 2.3 GiB 余量。
• 整机 CPU 平均约 8%–11%，没有全机 CPU 或 I/O Wait 饱和，但少量 CPU 核持续高负载，Scheduler/Affinity/NUMA 热点仍需关注。
• 双 Rail 流量对称且错误增量为 0；最高平均总发送约 140 Gbit/s，即每条 400G Rail 约 70 Gbit/s，原始 RoCE 带宽未饱和。

最终代码已经把首轮的采集限制变成强制门禁：两节点 dcgmi discovery -l 必须成功；每个 Case 使用 Starting main benchmark run 加 SGLang duration 形成正式测量窗口； 必需采集器提前退出会让 Run 失败。

6.2 最终采集范围

• nvidia-smi：GPU/显存利用率、显存、功耗、温度、SM/Memory Clock 和 P-state，每秒一次。
• DCGM：SM Active/Occupancy、Tensor Active、设备显存接口 Active、PCIe TX/RX，每秒一次。
• mpstat/pidstat/perf/numastat：整机、热点核、服务进程、CPU 计数器和 NUMA 内存，每 5 秒一次。
• sar 与 HCA Counter：eth0/eth3 和 mlx5_0/mlx5_3 的吞吐、均衡、错误与重试。
• 通信基线：两节点 CUDA P2P 全矩阵、两组 8-rank AllReduce、三组 16-rank NCCL_CROSS_NIC=0/1/2。

6.3 数据与报告规则

每种指标都生成独立的 case_*_summary.csv。最终 report.md 必须逐项列出原始文件、有效样本数、Head/Worker 数值、 Mean/P95/Max、Case 间变化和解释，不能只写抽象结论。缺失数据写 - 并报告采集器状态，不能当成 0。

6.4 与 Phase 3 的边界

Phase 2 回答“哪个硬件/Host/通信资源在什么 Case 中升高，以及硬件基线是多少”。 Phase 3 只捕获短 TP16 Timeline，回答具体 Kernel、Scheduler gap、Collective、 Rank 同步及计算/通信重叠，不重复 Phase 2 的长时间轻量采样。

7. Phase 3：时间线 Profiling（Nsight Systems 为主）

Nsight Systems、PyTorch Profiler 和 NVTX 是三件不同的东西：Nsight Systems 记录系统级 CUDA/NCCL/CPU 时间线；PyTorch Profiler 由框架接口触发； NVTX 只是在时间线上添加可读标记。启用 NVTX 不等于已经启动 Nsight。

7.1 与 Phase 2 的分工

因此 Phase 3 可以分析卡间通信，但分析的是真实请求里的时间与依赖关系， 不是再次统计平均网络带宽。通信微基准负责给出硬件上限，Phase 3 负责解释 SGLang 距离该上限有多远，以及通信是否落在关键路径上。

7.2 捕获策略

• 只捕获预热后的 5 到 10 个 Engine Step。
• Prefill、Decode 和混合干扰分别生成报告。
• 两台机器分别保存原始报告。
• 优先保留所有 Rank；文件过大时至少保留代表 Rank 和跨机通信相关 Rank。
• 报告必须和对应 Benchmark Case ID 绑定。
• 不重复运行 Phase 2 的五点硬件采集矩阵，不同时开启高频 pidstat、mpstat、sar 或 DCGM 全量采样。

7.3 vLLM

当前版本支持时，使用 CUDA Profiler 动态 Capture：

export VLLM_WORKER_MULTIPROC_METHOD=spawn

nsys profile \
  --trace=cuda,nvtx,nccl \
  --trace-fork-before-exec=true \
  --cuda-graph-trace=node \
  --capture-range=cudaProfilerApi \
  --capture-range-end=repeat \
  -o /data/profile/dsv4_tp16 \
  vllm serve ... \
  --profiler-config.profiler cuda

压测端使用支持 Profile Trigger 的 Bench：

vllm bench serve ... --profile

7.4 SGLang

以下 SGLANG_TORCH_PROFILER_DIR 与 /start_profile 属于 SGLang 的 PyTorch Profiler 路径，可用于框架级时间线，但不能把生成物 称为 Nsight Systems 报告。

服务启动前设置：

export SGLANG_TORCH_PROFILER_DIR=/data/profile/sglang

Profiling 专用 Run 可增加：

--enable-layerwise-nvtx-marker

捕获预热后的 10 个 Step：

curl -X POST http://127.0.0.1:30000/start_profile \
  -H 'Content-Type: application/json' \
  -d '{
    "output_dir": "/data/profile/sglang",
    "start_step": 5,
    "num_steps": 10,
    "activities": ["CPU", "GPU"]
  }'

多机 Trace 自动合并要求两台机器能访问同一个共享输出目录。没有共享目录时分别保存，再在本地汇总。

真正的 Nsight Systems Run 需要在两台节点分别由 nsys 捕获对应 SGLang 进程，并绑定相同 Case ID 和时间窗口。正式执行前先验证容器内外的 nsys 版本、子进程跟踪方式及动态 Capture 机制，再固化命令； 不直接对整轮 Benchmark 做长时间全量捕获。

7.4 时间线必须回答的问题

1. Prefill 和 Decode 各自的 Top Kernel 是什么？
2. NCCL 在关键路径上的暴露时间是多少？
3. 通信与计算重叠了多少？
4. 每层之间是否存在 CPU 或同步空洞？
5. CUDA Graph 是否覆盖常见 Decode Batch？
6. 16 个 Rank 是否同时结束？
7. 是否存在固定慢 Rank？
8. MoE Expert Token 是否严重不均衡？
9. NSA Indexer 的成本占 Sparse Attention 总成本多少？
10. 长 Prefill 到来时，Decode Kernel 为什么被延迟？

7.5 报告分析

nsys stats <REPORT>.nsys-rep

重点查看：

• CUDA GPU Kernel Summary。
• NCCL Summary。
• NCCL GPU Time Utilization。
• Communication/Compute Overlap。
• NCCL Straggler。
• CUDA API Summary。
• OS Runtime 和 CPU Thread Timeline。

8. 证据到优化方向的映射

9. Phase 4：优先级最高的拓扑实验

9.1 A：TP16 基线

当前方案用于建立所有后续实验的对照。

风险是每层 TP Collective 都可能跨越两台机器，Decode 小消息通信尤其容易被延迟支配。

9.2 B：TP8 + PP2

逻辑上：

Node 5: Pipeline Stage 0, TP8
Node 7: Pipeline Stage 1, TP8

理想情况下，每卡权重占用与 TP16 接近：

TP16:
  每卡权重约为 W / 16

TP8 + PP2:
  每个 Stage 保存 W / 2
  Stage 内由 8 卡切分
  每卡权重约为 (W / 2) / 8 = W / 16

潜在收益：

• 每层 TP Collective 留在单机。
• 跨机主要传输 Pipeline Stage 边界激活。
• 避免每层都进行跨机 AllReduce。

潜在代价：

• Pipeline Bubble。
• 低并发延迟可能变差。
• KV Cache、Hybrid Cache 和 DSV4-Pro 模型实现可能暂不支持 PP。
• 两个 Stage 的计算量可能不均衡。

测试顺序：

1. 先做加载与单请求 Smoke Test。
2. 对比 C=1 Decode 延迟。
3. 对比 C=16/32/64 吞吐。
4. 观察跨机网络流量是否显著下降。
5. 观察两个 Pipeline Stage 是否负载均衡。

9.3 C：Attention TP8/DP2 + MoE EP16

目标是：

• Attention 在节点内使用 TP8。
• 两个 Attention DP Group 并行处理请求。
• MoE Expert 在 16 张卡上分布。

这接近“Attention DP + MoE EP”的思路。Expert 权重通常占模型大头，因此即使 Attention 权重复制两份，也有机会放入显存。

必须先验证：

• 当前 vLLM/SGLang 版本是否支持 DSV4-Pro 的该拓扑。
• Expert 权重、非 Expert 权重和 KV Cache 的实际显存占用。
• All-to-All 是否比当前 TP16 AllReduce 更划算。
• Expert 负载是否均衡。

10. Phase 5：通信专项

10.1 不只测 1 GiB 大消息

之前的 1 GiB all_reduce_perf 主要说明大消息带宽。Decode 中的 Collective 往往更小，可能由延迟主导。

需要覆盖真实消息尺度：

all_reduce_perf -b 8K -e 64M -f 2 -g 8
all_gather_perf -b 8K -e 64M -f 2 -g 8
reduce_scatter_perf -b 8K -e 64M -f 2 -g 8

若启用 EP，还要测试 All-to-All。

10.2 通信优化顺序

1. 确认两条 Rail 都在工作。
2. 确认 Rank、GPU、NIC 和 NUMA Affinity。
3. 对照实际模型消息大小。
4. 查看 NCCL 自动选择的 Algorithm、Protocol 和 Channel。
5. 只有自动选择明显不合理时，才 A/B Ring/Tree、Simple/LL128 等设置。
6. 观察模型端到端结果，而不只看 nccl-tests 峰值。

11. Phase 6：Kernel 专项

从 Nsight Systems 中选累计占关键路径最高的 1 到 3 个 Kernel，再使用 Nsight Compute。

DSV4-Pro 的优先怀疑对象：

• NSA Indexer/Top-K。
• Sparse MLA/Attention Prefill。
• Sparse MLA/Attention Decode。
• MoE Gate、Dispatch、Grouped GEMM、Combine。
• FP8 Quant/Dequant 与 Scale Packing。
• RMSNorm、Rope、KV Cache Store 等碎片化小算子。
• NCCL Collective Kernel。

需要分析：

• SM 和 Tensor Core 利用率。
• DRAM 吞吐与 L2 Hit Rate。
• Occupancy。
• Register 与 Shared Memory 压力。
• Warp Stall 原因。
• Kernel Shape 与 Batch/Token 数。
• 小 Kernel Launch 次数。

优化优先顺序：

1. 切换已有高性能 Backend。
2. 调整 Backend 的 Shape/Workspace/Tile 配置。
3. 消除无用 Copy、Cast 和临时 Tensor。
4. 融合相邻的 Memory-bound 小算子。
5. 现有 Backend 不覆盖关键 Shape 时，再开发新 Kernel 或提交 PR。

12. Phase 7：Scheduler 与统一实例干扰

12.1 混合干扰实验

先建立稳定 Decode 背景流量：

ISL=1K
OSL=1K
C=32

运行稳定后，周期性注入一个长 Prefill：

ISL=128K
OSL=1
C=1

比较注入前后：

• Decode P50/P95/P99 TPOT。
• Decode Output TPS。
• 长请求 TTFT。
• 每轮 Prefill Chunk。
• Scheduler Queue。
• GPU Timeline。

12.2 可调方向

• Chunked Prefill Size。
• Max Prefill Tokens。
• Max Batched Tokens。
• Max Running Requests/Max Num Seqs。
• Prefill 与 Decode 调度优先级。
• CUDA Graph Batch Coverage。
• 双 Batch Overlap 或框架已有的通算重叠能力。

调优目标不是单独最大化 Prefill TPS，而是减少长 Prefill 对 Decode SLO 的破坏。

13. Phase 8：显存与缓存

当前初始值应保持固定，只在发现明确证据后调整：

• GPU Memory Fraction。
• Max Context Length。
• Active Request Limit。
• KV Cache Dtype。
• Page/Block Size。
• CUDA Graph Capture Size。

若 KV Cache 是瓶颈，优先顺序：

1. 确认权重和 Workspace 的真实占用。
2. 检查 Allocated/Reserved 差值与碎片。
3. 使用 FP8 KV Cache，前提是当前 Kernel 支持且精度可接受。
4. 根据业务上限设置 Context Length，不为不会出现的极端长度预留容量。
5. 设置合理的 Active Request Limit，避免运行时 OOM。
6. 再考虑 CPU/L3 KV Offload。

Prefix Cache 单独做第二阶段测试：

Mooncake 或三级缓存只有在 Prefix 可复用时才有明显价值。随机独立 Prompt 不适合评价它。

14. Phase 9：MTP 与模型级优化

当 TP16 Baseline、并行拓扑、通信、Backend 和 Scheduler 已稳定后，再测试：

• 原生 MTP。
• DSpark。
• EAGLE。
• KV Cache 量化。
• 更低比特权重量化。
• Sparse Attention 算法或 Indexer 优化。

投机解码至少记录：

• Accept Rate。
• Mean Accept Length。
• Target Forward TPS。
• Draft/MTP 开销。
• CPU 调度气泡。
• 不同并发下的净收益。

不能只看 Accept Length，也不能只看 C=1。

15. 里程碑与交付物

M1：可信 Baseline

完成条件：

• 九个固定快速地图点与混合干扰 A/B 均完成；里程碑版本各有 3 次重复。
• 同一 Case 的关键 TPS 变异系数尽量不超过 3%。
• 所有环境、命令和日志可追溯。

交付：

• Baseline Summary。
• SLO Frontier。
• GPU/CPU/Network Timeline。

M2：瓶颈报告

完成条件：

• Prefill、Decode、混合三类 Profile 完成。
• 找出累计贡献最高的 1 到 3 个瓶颈。
• 每个判断都有 Trace、计数器或日志证据。

交付：

• .nsys-rep 或 Torch Trace。
• Kernel/NCCL Summary。
• Bottleneck Evidence Table。

M3：并行拓扑 A/B

完成条件：

• TP16 保留基线。
• TP8+PP2 完成可行性与性能验证。
• Attention DP + MoE EP 完成支持性和显存评估。

交付：

• 每种拓扑的显存、通信、TTFT、TPOT 和 TPS 对比。
• 推荐拓扑与不推荐拓扑的证据。

M4：首轮优化闭环

完成条件：

• 至少一项优化通过完整 Benchmark。
• 结果在无 Profiler 环境下可复现。
• 正确性无回归。
• 满足 SLO 的吞吐有明确改善。

期望目标：

• 首轮争取获得至少 10% 的 SLO 内吞吐提升，或显著降低 P95/P99 长尾。
• 若无法提升，也必须形成排除结论，说明瓶颈为什么不在该方向。

16. 实验纪律

每次实验都必须回答：

1. 改了什么？
2. 为什么认为它会影响当前瓶颈？
3. 除该变量外，还有什么发生了变化？
4. 端到端指标如何变化？
5. Profile 证据如何变化？
6. 是否引入精度、稳定性或显存风险？
7. 是否值得保留？

禁止以下做法：

• 同时修改多个参数后只报告最终 TPS。
• 用 Profiling Run 和普通 Run 直接比较性能。
• 只看平均值，不看 P95/P99。
• 用配置 ISL/OSL 估算 TPS，而不核对实际 token 数。
• 用 1 GiB NCCL 带宽代表 Decode 小消息性能。
• 因单个 Kernel 更快就宣称端到端优化成功。
• OOM 后不重启服务继续测试。

17. 首轮执行建议

建议直接按以下顺序推进：

1. 固化当前 TP16 服务命令和 Manifest。
2. 先跑九个固定快速地图点，再跑 Decode 背景中注入 128K Prefill 的混合干扰 A/B。
3. 同步采集 GPU、CPU 和双 Rail 数据。
4. 对 P3、D2、M1 各捕获 5 到 10 个 Engine Step。
5. 输出 NCCL、NSA/Attention、MoE、CPU Gap 四项时间占比。
6. 根据最大暴露时间选择第一个优化方向。
7. 优先做 TP16 与 TP8+PP2 的可行性和性能对比。
8. 回到完整 Benchmark 验证 SLO 内吞吐。

最重要的判定标准是：

优化暴露在关键路径上的时间，而不是只优化看起来最慢的单个算子。

18. 参考资料

• vLLM Profiling
• SGLang Benchmark and Profiling
• SGLang Server Arguments
• NVIDIA Nsight Systems User Guide
• NVIDIA Nsight Systems Analysis Guide
• 腾讯混元 Hy3 Preview AI Infra 精读笔记