[Docs] audit DSV4-Pro TP16 TTFT benchmark semantics
This commit is contained in:
Zhiyi Hong
parent
d5d96bd7e4
commit
595bdde5d7
@ -1,5 +1,9 @@
|
||||
# sskj — 多平台大模型推理性能基准测试项目
|
||||
|
||||
> **更新（2026-07-30 16:38:41 CST）**
|
||||
>
|
||||
> 完成 DeepSeek-V4-Pro 双机 TP16 新旧脚本 TTFT 口径审计。确认旧产物受到 16 条 Warm-up、跨 Case 固定 Seed 递增长度、未清 Prefix Cache 及前一轮残留服务状态影响；同配置冷请求稳定复现约 16 秒/1K。新增 Phase 1 结果、脚本审计和 Phase 2 设计 HTML 档案，后续 Cold/Warm Prefix 指标分开报告。
|
||||
>
|
||||
> **更新（2026-07-30 14:33:52 CST）**
|
||||
>
|
||||
> 新增独立的 `dsv4pro_pro6000d_2node_sglang_tp16_quick_map` 快速性能地图与混合干扰 A/B。实验只保留一个 Shell 入口；旧 TP16 全量脚本保持不变。首轮真机验证已确认双机 TP16 服务可用，并据实测耗时将快速矩阵缩为一波请求，同时修正 Warm-up 污染 Prefix Cache 和混合负载注入时序。
|
||||
|
||||
@ -0,0 +1,721 @@
|
||||
<!doctype html>
|
||||
<html lang="zh-CN">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<meta name="color-scheme" content="light">
|
||||
<title>Phase 1：DeepSeek-V4-Pro 双机 Pro6000D SGLang 快速性能地图</title>
|
||||
<style>
|
||||
:root {
|
||||
--canvas: #f3f6f7;
|
||||
--paper: #ffffff;
|
||||
--ink: #172126;
|
||||
--muted: #5d6b71;
|
||||
--line: #d8e0e3;
|
||||
--teal: #087e75;
|
||||
--teal-soft: #e8f5f3;
|
||||
--orange: #b65318;
|
||||
--orange-soft: #fff1e8;
|
||||
--code-bg: #18262b;
|
||||
--code-ink: #eaf2f3;
|
||||
}
|
||||
|
||||
* {
|
||||
box-sizing: border-box;
|
||||
letter-spacing: 0;
|
||||
}
|
||||
|
||||
html {
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
color: var(--ink);
|
||||
background: var(--canvas);
|
||||
font-family: "PingFang SC", "Microsoft YaHei", "Noto Sans CJK SC",
|
||||
Arial, sans-serif;
|
||||
font-size: 16px;
|
||||
line-height: 1.72;
|
||||
}
|
||||
|
||||
a {
|
||||
color: var(--teal);
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
|
||||
header {
|
||||
color: #f7fbfb;
|
||||
background: #17343a;
|
||||
border-bottom: 5px solid #d76a2a;
|
||||
}
|
||||
|
||||
.header-inner,
|
||||
main {
|
||||
width: min(100% - 40px, 1020px);
|
||||
margin: 0 auto;
|
||||
}
|
||||
|
||||
.header-inner {
|
||||
padding: 34px 0 30px;
|
||||
}
|
||||
|
||||
.eyebrow {
|
||||
margin: 0 0 6px;
|
||||
color: #9edbd5;
|
||||
font-size: 13px;
|
||||
font-weight: 700;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
h1 {
|
||||
max-width: 900px;
|
||||
margin: 0;
|
||||
font-size: clamp(28px, 4vw, 42px);
|
||||
line-height: 1.25;
|
||||
}
|
||||
|
||||
.meta {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 8px 20px;
|
||||
margin-top: 16px;
|
||||
color: #d4e4e6;
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
main {
|
||||
margin-top: 32px;
|
||||
margin-bottom: 72px;
|
||||
padding: 40px 50px 60px;
|
||||
background: var(--paper);
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 6px;
|
||||
box-shadow: 0 12px 34px rgba(28, 43, 49, 0.07);
|
||||
}
|
||||
|
||||
.back {
|
||||
display: inline-block;
|
||||
margin-bottom: 20px;
|
||||
font-weight: 700;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.status {
|
||||
margin: 0 0 28px;
|
||||
padding: 14px 18px;
|
||||
background: var(--teal-soft);
|
||||
border-left: 4px solid var(--teal);
|
||||
}
|
||||
|
||||
.status strong {
|
||||
color: #075e58;
|
||||
}
|
||||
|
||||
h2 {
|
||||
margin: 48px 0 16px;
|
||||
padding-bottom: 9px;
|
||||
font-size: 25px;
|
||||
line-height: 1.35;
|
||||
border-bottom: 2px solid #afbcc1;
|
||||
}
|
||||
|
||||
h2:first-of-type {
|
||||
margin-top: 14px;
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin: 30px 0 10px;
|
||||
color: #21434a;
|
||||
font-size: 19px;
|
||||
}
|
||||
|
||||
p,
|
||||
ul,
|
||||
ol {
|
||||
margin-top: 0;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
|
||||
li + li {
|
||||
margin-top: 5px;
|
||||
}
|
||||
|
||||
table {
|
||||
width: 100%;
|
||||
margin: 18px 0 28px;
|
||||
border-collapse: collapse;
|
||||
font-size: 14px;
|
||||
}
|
||||
|
||||
th,
|
||||
td {
|
||||
padding: 10px 12px;
|
||||
vertical-align: top;
|
||||
text-align: left;
|
||||
border: 1px solid var(--line);
|
||||
overflow-wrap: anywhere;
|
||||
}
|
||||
|
||||
th {
|
||||
color: #15393e;
|
||||
background: #eaf2f2;
|
||||
}
|
||||
|
||||
tbody tr:nth-child(even) {
|
||||
background: #fafcfc;
|
||||
}
|
||||
|
||||
code {
|
||||
padding: 2px 5px;
|
||||
color: #85380d;
|
||||
background: var(--orange-soft);
|
||||
border-radius: 3px;
|
||||
font-family: "SFMono-Regular", Consolas, monospace;
|
||||
font-size: 0.9em;
|
||||
overflow-wrap: anywhere;
|
||||
}
|
||||
|
||||
pre {
|
||||
margin: 18px 0 24px;
|
||||
padding: 16px 18px;
|
||||
overflow: auto;
|
||||
color: var(--code-ink);
|
||||
background: var(--code-bg);
|
||||
border-radius: 6px;
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
pre code {
|
||||
padding: 0;
|
||||
color: inherit;
|
||||
background: transparent;
|
||||
white-space: pre;
|
||||
}
|
||||
|
||||
.pending {
|
||||
color: var(--orange);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.pass {
|
||||
color: var(--teal);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
@media (max-width: 680px) {
|
||||
.header-inner,
|
||||
main {
|
||||
width: min(100% - 24px, 1020px);
|
||||
}
|
||||
|
||||
main {
|
||||
padding: 28px 18px 44px;
|
||||
}
|
||||
|
||||
table {
|
||||
display: block;
|
||||
overflow-x: auto;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<div class="header-inner">
|
||||
<p class="eyebrow">Implementation & Result Record</p>
|
||||
<h1>Phase 1：DeepSeek-V4-Pro 双机 Pro6000D SGLang 快速性能地图</h1>
|
||||
<div class="meta">
|
||||
<span>节点：174.1.51.5 + 174.1.51.7</span>
|
||||
<span>拓扑：SGLang TP16 / EP2</span>
|
||||
<span>更新：2026-07-30 15:46 CST</span>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<a class="back" href="./推理优化计划.html">返回推理优化主计划</a>
|
||||
|
||||
<p class="status">
|
||||
<strong>阶段状态：提前结束，已进入硬件归因。</strong>
|
||||
第一次真机 Run
|
||||
<code>dsv4pro-pro6000d-2node-sglang-quick-20260730-140026</code>
|
||||
已验证双机服务可用，但因发现请求量和 Prefix Cache 口径问题而主动停止。
|
||||
精简后的第二次 Run
|
||||
<code>dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625</code>
|
||||
完成 3 个 Prefill 固定点后，发现输入吞吐稳定锁定在约
|
||||
<code>65 token/s</code>。继续扫描 Decode 和混合流量不能解释该异常，
|
||||
因此用户决定中止第 4 个 Case，直接进入 Phase 2。
|
||||
Manifest 终态为 <code>ABORTED_EARLY_FOR_PHASE2</code>；
|
||||
两节点容器和 16 张 GPU 已清理。
|
||||
</p>
|
||||
|
||||
<h2>1. 目标与边界</h2>
|
||||
<p>
|
||||
用数小时以内、可重复的小矩阵替代约一天以上的全量扫描，先回答
|
||||
Prefill、Decode、长上下文和混合干扰各自是否存在明显异常，再决定后续
|
||||
Timeline 和 Kernel Profiling 的捕获对象。该阶段不要求为了“跑满表格”
|
||||
而浪费算力；一旦出现稳定、可复现且足以改变调查方向的异常，就可以提前结束。
|
||||
</p>
|
||||
<ul>
|
||||
<li>只测试 SGLang，不测试 vLLM。</li>
|
||||
<li>使用双机 16 卡完整实例，不做 PD 分离。</li>
|
||||
<li>不启用 MTP、EAGLE、DSpark 或其他投机解码。</li>
|
||||
<li>本轮不启用 Profiler；三个已完成 Case 可作为对应 Shape 的端到端基线。</li>
|
||||
<li>不修改或调用旧的全天全量 Benchmark 脚本。</li>
|
||||
</ul>
|
||||
|
||||
<h2>2. 精简实现</h2>
|
||||
<p>实验代码位于：</p>
|
||||
<pre><code>/data/hzy/sskj/experiments/pro6000/
|
||||
dsv4pro_pro6000d_2node_sglang_tp16_quick_map/</code></pre>
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>文件</th>
|
||||
<th>职责</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>run_quick_map.sh</code></td>
|
||||
<td>唯一 Shell 入口：双机服务启停、固定矩阵、混合 A/B、错误处理与清理</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>config.env</code></td>
|
||||
<td>节点、模型、镜像、并行与容量参数</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>quick_map_scenarios.tsv</code></td>
|
||||
<td>九个固定工作负载点</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>quick_map_results.py</code></td>
|
||||
<td>验证 Bench JSON，生成 CSV、JSONL 和 Markdown 汇总</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>tests/test_quick_map_results.py</code></td>
|
||||
<td>结果解析回归测试</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<p>单入口的操作面：</p>
|
||||
<pre><code class="language-bash">bash run_quick_map.sh all
|
||||
|
||||
# 仅排障时使用同一个入口
|
||||
bash run_quick_map.sh start
|
||||
bash run_quick_map.sh fixed
|
||||
bash run_quick_map.sh mixed
|
||||
bash run_quick_map.sh stop</code></pre>
|
||||
|
||||
<h2>3. 服务配置</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>配置项</th>
|
||||
<th>当前值</th>
|
||||
<th>说明</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>镜像</td>
|
||||
<td><code>lmsysorg/sglang:nightly-dev-cu13-20260720-b3570a45</code></td>
|
||||
<td>沿用已验证可加载 DSV4-Pro 的版本</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>模型</td>
|
||||
<td><code>/data/hf_models/DeepSeek-V4-Pro</code></td>
|
||||
<td>两台节点均有本地权重</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>并行</td>
|
||||
<td><code>TP=16, EP=2, nnodes=2</code></td>
|
||||
<td>每台 8 卡，共 16 Rank</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>显存比例</td>
|
||||
<td><code>0.9</code></td>
|
||||
<td>保持已知基线，不在本阶段调参</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>活跃请求上限</td>
|
||||
<td><code>256</code></td>
|
||||
<td>覆盖本轮最大并发 64</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>CUDA Graph Decode BS</td>
|
||||
<td><code>64</code></td>
|
||||
<td>覆盖固定矩阵中的 Decode C64</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>NCCL bootstrap</td>
|
||||
<td><code>eth1</code></td>
|
||||
<td>普通 TCP 建连接口</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>RoCE HCA</td>
|
||||
<td><code>mlx5_0,mlx5_3</code></td>
|
||||
<td>双 Rail 数据面，<code>NCCL_CROSS_NIC=1</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>代码分支</td>
|
||||
<td><code>hzy</code></td>
|
||||
<td>从该维护分支向中央仓库 <code>main</code> 提交合并请求</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>4. 固定快速矩阵</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Case ID</th>
|
||||
<th>ISL</th>
|
||||
<th>OSL</th>
|
||||
<th>C</th>
|
||||
<th>目的</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><code>short_prefill_latency_1k_c1</code></td><td>1K</td><td>1</td><td>1</td><td>最小 TTFT</td></tr>
|
||||
<tr><td><code>mid_prefill_latency_32k_c1</code></td><td>32K</td><td>1</td><td>1</td><td>中长 Prefill</td></tr>
|
||||
<tr><td><code>long_prefill_latency_128k_c1</code></td><td>128K</td><td>1</td><td>1</td><td>长上下文 Prefill</td></tr>
|
||||
<tr><td><code>mid_prefill_throughput_32k_c16</code></td><td>32K</td><td>1</td><td>16</td><td>Prefill 输入吞吐</td></tr>
|
||||
<tr><td><code>decode_latency_1k_to_1k_c1</code></td><td>1K</td><td>1K</td><td>1</td><td>单请求 TPOT</td></tr>
|
||||
<tr><td><code>decode_throughput_1k_to_1k_c16</code></td><td>1K</td><td>1K</td><td>16</td><td>Decode 吞吐</td></tr>
|
||||
<tr><td><code>decode_throughput_1k_to_1k_c32</code></td><td>1K</td><td>1K</td><td>32</td><td>Decode 吞吐</td></tr>
|
||||
<tr><td><code>decode_throughput_1k_to_1k_c64</code></td><td>1K</td><td>1K</td><td>64</td><td>Decode 高并发</td></tr>
|
||||
<tr><td><code>balanced_32k_to_1k_c8</code></td><td>32K</td><td>1K</td><td>8</td><td>综合压力</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>
|
||||
快速 Run 使用一次重复和一波测量请求，即 <code>num_prompts=C</code>。
|
||||
32K/128K Prefill 不做昂贵的同形状 Warm-up；短 Prefill 与 Decode 使用一个
|
||||
Warm-up，并在正式计时前清空 Prefix Cache。固定矩阵不做 SLO 截断或自适应并发搜索。
|
||||
</p>
|
||||
|
||||
<h2>5. SGLang Benchmark 与 Prefix Cache</h2>
|
||||
<h3>5.1 <code>random</code> 如何生成 ISL</h3>
|
||||
<p>
|
||||
当前镜像的实现位于
|
||||
<code>/sgl-workspace/sglang/python/sglang/benchmark/datasets/random.py</code>。
|
||||
<code>dataset-name=random</code> 会读取 ShareGPT，打乱样本后取每条会话的首轮用户文本：
|
||||
文本过长就截断，过短就重复其 token，直到达到目标 ISL。
|
||||
<code>random-range-ratio=1.0</code> 使每条请求都使用精确的目标长度。
|
||||
本机数据集共有 94,145 行，其中 92,886 行可用、71,904 个不同首轮文本，
|
||||
因此不存在此前“两条数据只能形成两个并发请求”的问题。
|
||||
</p>
|
||||
<p>
|
||||
<code>random-ids</code> 则直接构造随机整数 token id，不读取 ShareGPT。
|
||||
当前源码同时警告这种方式可能触发 NaN，因此本阶段继续使用
|
||||
<code>random + 大规模 ShareGPT</code>，并通过清缓存隔离不同测试点。
|
||||
</p>
|
||||
|
||||
<h3>5.2 OSL 为什么能达到指定长度</h3>
|
||||
<p>
|
||||
SGLang 原生请求函数位于
|
||||
<code>/sgl-workspace/sglang/python/sglang/benchmark/serving.py</code>。
|
||||
它将目标 OSL 写入 <code>max_new_tokens</code>，并默认设置
|
||||
<code>ignore_eos=True</code>。因此模型即使提前生成 EOS，也会继续生成到指定 OSL；
|
||||
只有请求失败、超时或触及上下文限制时，实际输出才可能不足。
|
||||
</p>
|
||||
<pre><code class="language-python">sampling_params = {
|
||||
"max_new_tokens": request_func_input.output_len,
|
||||
"ignore_eos": not args.disable_ignore_eos,
|
||||
}</code></pre>
|
||||
|
||||
<h3>5.3 为什么 Warm-up 会污染 Prefix Cache</h3>
|
||||
<p>
|
||||
SGLang benchmark 的 Warm-up 直接复用 <code>input_requests[0]</code>，
|
||||
而正式测量随后仍会遍历包含该请求的完整列表。因此，只要服务启用了 Prefix Cache，
|
||||
第一条正式请求就可能命中刚刚 Warm-up 的前缀。第一次 Run 的服务日志实际出现
|
||||
<code>#cached-token: 768</code>，证明该污染在当前环境真实发生。
|
||||
</p>
|
||||
<p>
|
||||
修复方式是在每个隔离测试点传入 <code>--flush-cache</code>。benchmark 会先完成
|
||||
Warm-up，再调用服务端 <code>/flush_cache</code>，最后才启动计时。这样保留 Kernel
|
||||
和执行路径预热，同时不把 Warm-up 的 KV 前缀带入测量。混合干扰中的长 Prefill
|
||||
注入不会清缓存，避免在 Decode 背景运行时改变其服务状态；背景与注入使用不同随机种子。
|
||||
</p>
|
||||
|
||||
<h3>5.4 如何单独测试 Prefix Caching</h3>
|
||||
<ol>
|
||||
<li>调用 <code>/flush_cache</code>，发送固定长 Prompt P，记录 Cold TTFT 和 <code>#cached-token</code>。</li>
|
||||
<li>不清缓存，原样重发 P，记录 Warm TTFT；预期 cached token 明显增加、TTFT 降低。</li>
|
||||
<li>再次清缓存，发送同长度但内容不同的 Prompt Q，排除长度、JIT 和偶然波动造成的假提升。</li>
|
||||
</ol>
|
||||
<p>
|
||||
三组请求保持 OSL、采样参数和并发一致，各重复至少 3 次。Prefix Cache 是生产优化能力，
|
||||
不是“坏东西”；这里只是在无缓存性能基线中隔离它，后续会把缓存命中场景作为单独 A/B。
|
||||
</p>
|
||||
|
||||
<h2>6. 混合干扰实现</h2>
|
||||
<p>
|
||||
这里的“背景”不是 SGLang 后台线程，而是<strong>先启动并持续运行的一批
|
||||
Decode 基准流量</strong>。它既在实验期间占用 GPU，也是我们希望观察是否
|
||||
变慢的对象。混合 A/B 的问题非常具体：同样一批 Decode 请求，在没有长
|
||||
Prefill 干扰和有长 Prefill 干扰时，性能会相差多少？
|
||||
</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>组别</th><th>运行内容</th><th>作用</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>A：Control</td><td>仅运行 64 条 <code>1K → 1K, C=32</code> Decode</td><td>建立无干扰基线</td></tr>
|
||||
<tr><td>B：Treatment</td><td>运行相同 Decode，并在正式测量开始 10 秒后注入一条 <code>128K → 1</code> Prefill</td><td>测量 Prefill 对 Decode 的干扰</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<ol>
|
||||
<li>先完成 A 组，仅运行 Decode，保存对照指标。</li>
|
||||
<li>启动 B 组的 Decode 基准流量，并从日志确认它已进入正式测量，而不只是完成客户端初始化。</li>
|
||||
<li>正式测量开始 10 秒后，并行提交一个 <code>128K → 1</code> 长 Prefill。</li>
|
||||
<li>等待两类请求都结束，分别保存 Decode 流量和长 Prefill 请求的结果。</li>
|
||||
<li>用 A、B 两组 Decode 的 Output TPS、TTFT P95、TPOT P95 与 E2E P95 计算变化率；长 Prefill 自身的 TTFT 单独报告。</li>
|
||||
</ol>
|
||||
<pre><code>A：Decode ───────────────────────────────→ 结束
|
||||
|
||||
B：Decode ───────────────────────────────→ 结束
|
||||
正式测量 + 10 秒
|
||||
└─ 128K Prefill ─→ 结束
|
||||
共同占用同一服务</code></pre>
|
||||
<pre><code class="language-bash">(
|
||||
run_bench_case ... 1024 1024 32 64
|
||||
) &
|
||||
background_pid=$!
|
||||
|
||||
# 实际代码先从 bench.log 确认正式测量已经开始。
|
||||
sleep 10
|
||||
run_bench_case ... 131072 1 1 1
|
||||
wait "${background_pid}"</code></pre>
|
||||
<p>
|
||||
<code>&</code> 让 Decode benchmark 与后续 Prefill 并行；
|
||||
<code>$!</code> 取得该 Decode benchmark 的进程号；
|
||||
<code>wait</code> 等待它完成。总请求数 64、并发 32，表示最多同时有
|
||||
32 条请求在途，通常形成约两波请求。如果 Decode 流量在注入前已经结束，
|
||||
两类请求没有发生重叠，结果会被明确改写为
|
||||
<code>BACKGROUND_FINISHED_BEFORE_INJECTION</code>，避免生成虚假的“混合成功”。
|
||||
</p>
|
||||
|
||||
<h2>7. 结果与可追溯性</h2>
|
||||
<pre><code>results/<RUN_ID>/
|
||||
run_manifest.json
|
||||
run.log
|
||||
summary.csv
|
||||
summary.jsonl
|
||||
aggregate.csv
|
||||
report.md
|
||||
cases/<case_id>/rep1/
|
||||
bench_cmd.txt
|
||||
bench.jsonl
|
||||
bench.log
|
||||
meta.json
|
||||
server/
|
||||
head_server_cmd.txt
|
||||
worker_server_cmd.txt
|
||||
head_server.log
|
||||
worker_server.log</code></pre>
|
||||
<p>
|
||||
汇总保留 Request/Input/Output/Total TPS，以及 E2E、TTFT、TPOT、ITL 的
|
||||
Mean、P50、P95、P99。断点续跑前会重新解析原始 Bench JSON，不能只凭文件存在就跳过。
|
||||
</p>
|
||||
|
||||
<h2>8. 已完成验证</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>检查</th><th>结果</th><th>证据</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>Shell 语法</td><td class="pass">通过</td><td><code>bash -n run_quick_map.sh</code></td></tr>
|
||||
<tr><td>Python 单测</td><td class="pass">3/3 通过</td><td>场景唯一性、百分位回退、失败结果汇总</td></tr>
|
||||
<tr><td>完整 Dry-run</td><td class="pass">通过</td><td>服务、九个固定点、混合 A/B、清理均展开成功</td></tr>
|
||||
<tr><td>真实旧 Bench JSON 解析</td><td class="pass">通过</td><td>成功解析 P50/P95/P99 与吞吐字段</td></tr>
|
||||
<tr><td>项目精简</td><td class="pass">通过</td><td>实验目录顶层仅保留一个 Shell 入口</td></tr>
|
||||
<tr><td>双机容器启动</td><td class="pass">通过</td><td>第二次 Run 于 14:42:04 通过 Health Check，启动约 5 分 30 秒</td></tr>
|
||||
<tr><td>Prefix Cache 隔离</td><td class="pass">通过</td><td>Warm-up 后 <code>POST /flush_cache</code> 返回 200，正式请求仍为 <code>#cached-token: 0</code></td></tr>
|
||||
<tr><td>中止清理</td><td class="pass">通过</td><td>头、Worker 节点均无相关容器和 Bench 进程，16 张 GPU 显存回到 0 MiB</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>9. 真机结果</h2>
|
||||
<p>
|
||||
最终采用 Run
|
||||
<code>dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625</code>。
|
||||
以下三条均为一条请求、<code>C=1</code>、<code>OSL=1</code>，且正式测量前
|
||||
Prefix Cache 已清空。
|
||||
</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Case</th>
|
||||
<th>ISL</th>
|
||||
<th>输入 TPS</th>
|
||||
<th>TTFT</th>
|
||||
<th>E2E</th>
|
||||
<th>状态</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><code>short_prefill_latency_1k_c1</code></td><td>1K</td><td>64.44 tok/s</td><td>15.88 s</td><td>15.88 s</td><td class="pass">COMPLETED</td></tr>
|
||||
<tr><td><code>mid_prefill_latency_32k_c1</code></td><td>32K</td><td>64.96 tok/s</td><td>504.44 s</td><td>504.44 s</td><td class="pass">COMPLETED</td></tr>
|
||||
<tr><td><code>long_prefill_latency_128k_c1</code></td><td>128K</td><td>65.20 tok/s</td><td>2010.38 s</td><td>2010.38 s</td><td class="pass">COMPLETED</td></tr>
|
||||
<tr><td><code>mid_prefill_throughput_32k_c16</code></td><td>32K × 16</td><td>未形成最终结果</td><td>未形成最终结果</td><td>未形成最终结果</td><td class="pending">ABORTED</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3>9.1 可以下的结论</h3>
|
||||
<ul>
|
||||
<li>三个长度的输入吞吐只相差约 1.2%，稳定在 <code>64.44–65.20 token/s</code>。</li>
|
||||
<li>32K TTFT 约为 1K 的 31.76 倍；128K TTFT 约为 32K 的 3.99 倍，几乎按 token 数线性增长。</li>
|
||||
<li>这不是偶发卡顿：服务端每约 125 秒完成一个 8192-token Chunk，GPU 在该期间持续忙碌。</li>
|
||||
<li><code>32K, C=16</code> 的观察窗口内，日志持续显示 <code>#new-seq: 1</code>，队列从 15 降到 14；至少当前路径没有立即把 16 条 Prefill 合成大批次。</li>
|
||||
<li>没有出现 OOM、NCCL、CUDA、EngineDead 或请求失败，所以“服务崩溃”不能解释低吞吐。</li>
|
||||
</ul>
|
||||
|
||||
<h3>9.2 现在还不能下的结论</h3>
|
||||
<ul>
|
||||
<li>仅凭 GPU Utilization=100% 不能判断是算力、显存带宽还是通信瓶颈。</li>
|
||||
<li>尚不能断言是 SGLang Bug、DSV4/NSA Kernel、TP16 NCCL、MoE Backend 或 Scheduler 中的哪一项。</li>
|
||||
<li>Decode、Balanced 和混合 A/B 未执行，Phase 1 不提供这些场景的基线。</li>
|
||||
<li>每个 Shape 只有一次重复，不能用于稳定性或 CV 结论。</li>
|
||||
</ul>
|
||||
|
||||
<h3>9.3 为什么提前结束</h3>
|
||||
<p>
|
||||
Phase 1 的目标是发现值得归因的关键异常，而不是机械完成九个格子。
|
||||
三个独立长度已经给出同一个稳定信号；第 4 个并发 Prefill 在 922 秒后仍表现为
|
||||
单序列 Chunk 推进。继续执行剩余矩阵预计还需数小时，却不能回答
|
||||
“这 65 token/s 到底卡在哪里”。因此第 4 个 Case 被写入
|
||||
<code>EARLY_STOP_FOR_PHASE2</code>，其余固定点和混合 A/B 保留为未执行。
|
||||
</p>
|
||||
|
||||
<h3>9.4 为什么旧脚本的 TTFT 短很多</h3>
|
||||
<p>
|
||||
2026-07-30 对旧目录
|
||||
<code>/data/qqt/sskj/experiments/pro6000/dsv4_pro6000_sglang_tp16</code>
|
||||
做了逐项审计。结论是：<strong>旧结果与本轮冷 Prefill 不是同一缓存口径</strong>，
|
||||
不是 quick-map 把相同请求跑慢了。
|
||||
</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>审计项</th><th>旧脚本</th><th>quick-map</th><th>判断</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>服务端配置</td>
|
||||
<td>同一镜像，TP16 / EP2，8K Chunk，FlashInfer MXFP4 MoE</td>
|
||||
<td>相同</td>
|
||||
<td class="pass">排除明显的启动参数回归</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>正式请求数</td>
|
||||
<td><code>C=1</code> 仍强制至少 10 条</td>
|
||||
<td>延迟点只发 1 条</td>
|
||||
<td>旧均值混合了多条请求的缓存状态</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Warm-up</td>
|
||||
<td>每个 Shape 固定 16 条同 Prompt Warm-up</td>
|
||||
<td>Warm-up 后清 Prefix Cache；32K/128K 延迟点不做额外 Warm-up</td>
|
||||
<td>旧正式测量会继承 Warm-up 的 Prompt 前缀</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Cache 清理</td>
|
||||
<td>从不传 <code>--flush-cache</code></td>
|
||||
<td>正式测量前传 <code>--flush-cache</code></td>
|
||||
<td>旧脚本跨 Case、跨长度保留 Radix/Prefix Cache</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Shape 顺序</td>
|
||||
<td>固定 Seed=42，按 1K→4K→8K→16K→32K→64K→128K 递增</td>
|
||||
<td>每个延迟点按冷缓存解释</td>
|
||||
<td>旧请求会复用上一档相同 Prompt 的短前缀</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>
|
||||
旧时间线还有一条直接证据：17:40 的失败 Run 已完整执行过
|
||||
<code>1K / 128 / C=1</code>，18:01 的正式 Run 没有重启服务便再次执行同一批
|
||||
Seed=42 请求。因此旧文件中的 1K TTFT 约 0.455 秒，本身就是热缓存结果。
|
||||
</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>最小复现</th><th>Mean TTFT</th><th>P95 TTFT</th><th>解释</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>1K→1，首次冷缓存</td><td>16.04 s</td><td>16.04 s</td><td>清 Prefix Cache，1 条正式请求</td></tr>
|
||||
<tr><td>1K→1，原样再次冷缓存</td><td>15.90 s</td><td>15.90 s</td><td>再次清 Cache，排除一次性 JIT 主导</td></tr>
|
||||
<tr><td>1K→128，冷缓存</td><td>15.79 s</td><td>15.79 s</td><td>排除 OSL=1 特殊慢路径</td></tr>
|
||||
<tr><td>旧命令语义重新复现</td><td>14.60 s</td><td>15.97 s</td><td>10 条正式请求、16 条 Warm-up、不清 Cache</td></tr>
|
||||
<tr><td>2026-07-28 旧产物</td><td>0.455 s</td><td>0.513 s</td><td>服务已被前一次 Run 和后续递增长度预热</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>
|
||||
旧 32K 文件的第一条请求约 0.67 秒，其余 9 条平均约 35.51 秒；
|
||||
旧 128K 文件的第一条约 0.96 秒，其余 9 条平均约 144.83 秒。
|
||||
后 9 条也已经分别继承上一档 16K、64K 前缀。旧报告仍按完整 ISL 统计
|
||||
Input TPS，因此会把只计算新增后缀的耗时除进完整 token 数，进一步放大吞吐。
|
||||
</p>
|
||||
<p>
|
||||
审计结论：Phase 1 的约 65 token/s 是<strong>冷 Prefix Cache 的完整 Prompt 路径</strong>，
|
||||
旧结果是热缓存/递增前缀路径。两者都可以测，但必须分成 Cold 与 Warm 两套实验，
|
||||
不能放在同一列直接比较。审计原始产物保存在：
|
||||
</p>
|
||||
<pre><code>/data/hzy/dsv4_script_audit_20260730/</code></pre>
|
||||
<p>
|
||||
本地归档：
|
||||
<a href="./results/script-audit-20260730/report.md">TTFT 脚本口径审计报告</a>
|
||||
及同目录原始 JSON/log。
|
||||
</p>
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>检查点</th>
|
||||
<th>状态</th>
|
||||
<th>结果或结论</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>服务健康</td><td class="pass">通过</td><td>端口 <code>30002</code> 已就绪，无 OOM、NCCL 或 Engine 异常</td></tr>
|
||||
<tr><td>第一次固定点 Run</td><td class="pending">主动停止</td><td>发现 32K 单请求约需十余分钟；原协议的 4 次同形状请求会使整轮再次接近半天</td></tr>
|
||||
<tr><td>精简后九个固定点</td><td class="pending">3 完成 / 1 中止 / 5 未执行</td><td>Prefill 异常信号已足够清晰，停止继续消耗算力</td></tr>
|
||||
<tr><td>混合干扰 A/B</td><td class="pending">未执行</td><td>待 Prefill 根因明确后再决定是否重放</td></tr>
|
||||
<tr><td>阶段耗时</td><td class="pass">约 65 分钟</td><td>14:36:26 启动，15:41:52 完成进程与容器清理</td></tr>
|
||||
<tr><td>是否进入下一阶段</td><td class="pass">是</td><td>用户决定立即进入 Phase 2 硬件指标归因</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>10. 结果位置</h2>
|
||||
<p>服务器原始结果：</p>
|
||||
<pre><code>/data/hzy/sskj/experiments/pro6000/
|
||||
dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/
|
||||
dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/</code></pre>
|
||||
<p>
|
||||
本地已归档
|
||||
<a href="./results/phase1-dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/report.md">report.md</a>、
|
||||
<a href="./results/phase1-dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/aggregate.csv">aggregate.csv</a>
|
||||
和同目录下的 Manifest、Summary、主日志。
|
||||
</p>
|
||||
|
||||
<h2>11. 运行命令</h2>
|
||||
<pre><code class="language-bash">cd /data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map
|
||||
|
||||
tmux new-session -d -s dsv4pro-pro6000d-2node-sglang-quick-map -c "$PWD"
|
||||
tmux send-keys -t dsv4pro-pro6000d-2node-sglang-quick-map \
|
||||
'RUN_ID=dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625 bash run_quick_map.sh all' Enter
|
||||
|
||||
tmux attach -t dsv4pro-pro6000d-2node-sglang-quick-map</code></pre>
|
||||
|
||||
<p>
|
||||
下一阶段：
|
||||
<a class="back" href="./phase2_dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution.html">
|
||||
Phase 2：Prefill 硬件指标归因
|
||||
</a>
|
||||
</p>
|
||||
<p><a class="back" href="./推理优化计划.html">返回推理优化主计划</a></p>
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
@ -0,0 +1,327 @@
|
||||
<!doctype html>
|
||||
<html lang="zh-CN">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
<title>Phase 2：DeepSeek-V4-Pro 双机 Pro6000D SGLang Prefill 硬件归因</title>
|
||||
<style>
|
||||
:root {
|
||||
color-scheme: light;
|
||||
--ink: #18202a;
|
||||
--muted: #5b6570;
|
||||
--line: #d8dde3;
|
||||
--paper: #ffffff;
|
||||
--page: #f3f5f7;
|
||||
--blue: #1769aa;
|
||||
--green: #16734a;
|
||||
--amber: #9a5a00;
|
||||
--red: #a13232;
|
||||
--code: #f0f3f6;
|
||||
}
|
||||
* { box-sizing: border-box; }
|
||||
body {
|
||||
margin: 0;
|
||||
background: var(--page);
|
||||
color: var(--ink);
|
||||
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
|
||||
font-size: 16px;
|
||||
line-height: 1.65;
|
||||
}
|
||||
header {
|
||||
background: #202a34;
|
||||
color: #fff;
|
||||
border-bottom: 5px solid #34a17a;
|
||||
}
|
||||
.header-inner, main {
|
||||
width: min(1120px, calc(100% - 32px));
|
||||
margin: 0 auto;
|
||||
}
|
||||
.header-inner { padding: 38px 0 32px; }
|
||||
h1, h2, h3 { letter-spacing: 0; }
|
||||
h1 {
|
||||
margin: 4px 0 12px;
|
||||
font-size: clamp(26px, 4vw, 42px);
|
||||
line-height: 1.2;
|
||||
}
|
||||
h2 {
|
||||
margin: 38px 0 12px;
|
||||
padding-bottom: 7px;
|
||||
border-bottom: 2px solid var(--line);
|
||||
font-size: 24px;
|
||||
}
|
||||
h3 { margin: 26px 0 8px; font-size: 19px; }
|
||||
.eyebrow {
|
||||
margin: 0;
|
||||
color: #8fd8bd;
|
||||
font-size: 13px;
|
||||
font-weight: 700;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
.meta {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 8px 22px;
|
||||
color: #d7dee5;
|
||||
font-size: 14px;
|
||||
}
|
||||
main {
|
||||
margin-top: 24px;
|
||||
margin-bottom: 48px;
|
||||
padding: 30px 38px 42px;
|
||||
background: var(--paper);
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 6px;
|
||||
}
|
||||
.status {
|
||||
padding: 14px 16px;
|
||||
border-left: 4px solid var(--amber);
|
||||
background: #fff7e7;
|
||||
}
|
||||
.decision {
|
||||
padding: 14px 16px;
|
||||
border-left: 4px solid var(--green);
|
||||
background: #eef8f3;
|
||||
}
|
||||
a { color: var(--blue); }
|
||||
.back {
|
||||
display: inline-block;
|
||||
margin-bottom: 10px;
|
||||
font-weight: 650;
|
||||
}
|
||||
code {
|
||||
padding: 1px 5px;
|
||||
background: var(--code);
|
||||
border-radius: 3px;
|
||||
font-family: "SFMono-Regular", Consolas, monospace;
|
||||
font-size: 0.92em;
|
||||
}
|
||||
pre {
|
||||
overflow-x: auto;
|
||||
padding: 14px 16px;
|
||||
background: #202a34;
|
||||
color: #f4f7fa;
|
||||
border-radius: 5px;
|
||||
line-height: 1.5;
|
||||
}
|
||||
pre code { padding: 0; background: transparent; color: inherit; }
|
||||
table {
|
||||
width: 100%;
|
||||
margin: 14px 0 22px;
|
||||
border-collapse: collapse;
|
||||
font-size: 14px;
|
||||
}
|
||||
th, td {
|
||||
padding: 10px 11px;
|
||||
border: 1px solid var(--line);
|
||||
text-align: left;
|
||||
vertical-align: top;
|
||||
}
|
||||
th { background: #edf1f4; }
|
||||
.pass { color: var(--green); font-weight: 700; }
|
||||
.pending { color: var(--amber); font-weight: 700; }
|
||||
.fail { color: var(--red); font-weight: 700; }
|
||||
li + li { margin-top: 5px; }
|
||||
@media (max-width: 720px) {
|
||||
main { padding: 22px 18px 30px; }
|
||||
table { display: block; overflow-x: auto; white-space: nowrap; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<div class="header-inner">
|
||||
<p class="eyebrow">Design, Implementation & Result Record</p>
|
||||
<h1>Phase 2：DeepSeek-V4-Pro 双机 Pro6000D SGLang Prefill 硬件归因</h1>
|
||||
<div class="meta">
|
||||
<span>节点：174.1.51.5 + 174.1.51.7</span>
|
||||
<span>拓扑：SGLang TP16 / EP2</span>
|
||||
<span>更新：2026-07-30 16:35 CST</span>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<a class="back" href="./推理优化计划.html">返回推理优化主计划</a>
|
||||
|
||||
<p class="status">
|
||||
<strong>当前状态：旧脚本口径审计完成，Phase 2 代码尚未开始。</strong>
|
||||
本页从第一行 Phase 2 代码开始同步维护。每次代码改动、静态验证、真机运行和
|
||||
结果判断都会在对应小节留下文件路径、命令和证据，不在阶段结束后凭记忆补写。
|
||||
</p>
|
||||
|
||||
<h2>1. 为什么立即进入 Phase 2</h2>
|
||||
<p>
|
||||
Phase 1 在没有 Profiler、没有 Prefix Cache 命中的条件下得到以下结果：
|
||||
</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>ISL / OSL / C</th><th>输入 TPS</th><th>TTFT</th><th>结果</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>1K / 1 / 1</td><td>64.44 tok/s</td><td>15.88 s</td><td>完成</td></tr>
|
||||
<tr><td>32K / 1 / 1</td><td>64.96 tok/s</td><td>504.44 s</td><td>完成</td></tr>
|
||||
<tr><td>128K / 1 / 1</td><td>65.20 tok/s</td><td>2010.38 s</td><td>完成</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>
|
||||
三个长度的输入吞吐几乎相同，TTFT 近似按 token 数线性增加。
|
||||
这已经不是“继续扩充 Shape”能回答的问题。Phase 2 要回答：
|
||||
<strong>稳定的约 65 token/s 到底受 GPU 计算、显存、CPU 调度还是双机通信中的哪一项限制。</strong>
|
||||
</p>
|
||||
|
||||
<h3>1.1 Phase 2 前置审计</h3>
|
||||
<p>
|
||||
旧脚本较短的 TTFT 已确认不是同口径反例。旧脚本固定执行 16 条同 Prompt
|
||||
Warm-up，从不清 Prefix Cache，并按固定 Seed 递增长度；17:40 的失败 Run
|
||||
还在 18:01 正式 Run 前预热了同一批 1K 请求。全字段比较显示新旧
|
||||
<code>server_info</code> 的关键运行参数相同。
|
||||
</p>
|
||||
<p>
|
||||
同一服务上的最小复现得到：两次独立清 Cache 的 1K→1 TTFT 分别为
|
||||
16.04 秒和 15.90 秒；把 OSL 改为 128 后是 15.79 秒；按旧命令语义重新执行
|
||||
仍为 14.60 秒，而不是旧产物的 0.455 秒。因此 Phase 2 将继续 profile
|
||||
<strong>清 Prefix Cache 后的完整冷 Prefill</strong>。Warm Prefix/Prefix Cache
|
||||
收益另立 A/B，不与本阶段混算。
|
||||
</p>
|
||||
|
||||
<h2>2. 本阶段的边界</h2>
|
||||
<ul>
|
||||
<li>只测试 SGLang，不测试 vLLM。</li>
|
||||
<li>保留 Phase 1 的模型、镜像、TP16、EP2、显存比例和 NCCL 参数。</li>
|
||||
<li>不启用 Nsight Systems、PyTorch Profiler、NCCL DEBUG 或投机解码。</li>
|
||||
<li>不调参，不尝试优化；先获得足以区分瓶颈类别的硬件证据。</li>
|
||||
<li>第一轮只重放 <code>32K → 1, C=1</code>，与 Phase 1 结果直接对齐。</li>
|
||||
<li>采集器从请求开始前启动，到请求结束后停止，不能中途补采后声称完整。</li>
|
||||
</ul>
|
||||
|
||||
<h2>3. 待验证假设</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>假设</th><th>预期硬件表现</th><th>后续方向</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>DSV4/NSA Prefill Kernel 计算受限</td><td>GPU 持续忙、高功耗和稳定频率；双 Rail 流量不高</td><td>Phase 3 捕获 Kernel 与 Attention/Indexer 时间线</td></tr>
|
||||
<tr><td>权重或激活显存带宽受限</td><td>GPU Memory Utilization 高，SM 指标未必饱和；功耗可能低于纯计算</td><td>补 DCGM/Profiler 的 DRAM Active，再看 Kernel</td></tr>
|
||||
<tr><td>TP16 跨机通信受限</td><td>RoCE 吞吐高或两条 Rail 明显失衡，GPU 出现等待</td><td>NCCL_CROSS_NIC 0/1/2 快速 A/B，随后看 NCCL Timeline</td></tr>
|
||||
<tr><td>CPU Scheduler 或 Kernel Launch 受限</td><td>GPU 利用率锯齿或有空洞，单 CPU 核持续满载</td><td>定位 Scheduler/Tokenizer 线程与 launch gap</td></tr>
|
||||
<tr><td>频率、功耗或温度限制</td><td>P-state、SM Clock 或 Power 持续异常，可能出现节流原因</td><td>修正电源、散热或 Clock Policy 后复测</td></tr>
|
||||
<tr><td>节点或 Rank 不均衡</td><td>两节点或不同 GPU 的利用率、功耗、网络流量存在固定偏差</td><td>检查 NUMA、GPU-NIC 亲和与慢 Rank</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>4. 诊断 Run</h2>
|
||||
<ol>
|
||||
<li>保存两节点静态快照：GPU/NIC/NUMA 拓扑、驱动、CUDA、镜像与服务命令。</li>
|
||||
<li>复用 Phase 1 已验证的 <code>run_quick_map.sh start</code> 启动同配置双机服务。</li>
|
||||
<li>在 Head 和 Worker 同时启动 GPU、CPU、网卡与 RDMA 采样，先记录 15 秒空闲基线。</li>
|
||||
<li>清空 Prefix Cache，发送一条 <code>32K → 1, C=1</code> 请求，Seed 与 Phase 1 一致。</li>
|
||||
<li>请求结束后继续采样 15 秒，再停止采集器和服务。</li>
|
||||
<li>按时间戳将请求、8K Chunk、GPU、CPU 和 Rail 指标对齐，生成摘要与判定。</li>
|
||||
</ol>
|
||||
<pre><code>idle 15s │──────── 32K Prefill：4 × 8K Chunk ────────│ cooldown 15s
|
||||
↑ request_start ↑ request_end
|
||||
Head 与 Worker 的所有采集器覆盖完整时间窗</code></pre>
|
||||
<p>
|
||||
预计服务加载约 6 分钟、请求约 8.5 分钟，连同快照和清理应在 20 分钟左右完成。
|
||||
</p>
|
||||
|
||||
<h2>5. 采集指标</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>层级</th><th>连续采样</th><th>静态或前后快照</th><th>局限</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>GPU</td><td>利用率、Memory Utilization、显存、功耗、SM/Memory Clock、温度、P-state</td><td><code>nvidia-smi topo -m</code>、Compute Process</td><td><code>nvidia-smi</code> 的 Memory Utilization 不是实际 HBM GB/s</td></tr>
|
||||
<tr><td>CPU</td><td>每核利用率、上下文切换、服务进程 CPU/内存</td><td>NUMA 拓扑、容器 PID 与 CPU Affinity</td><td>需要时间戳与 GPU Chunk 日志对齐</td></tr>
|
||||
<tr><td>Network</td><td><code>eth0/eth3</code> RX/TX</td><td><code>ethtool -S</code> 错误计数前后差</td><td>普通 netdev 统计不一定覆盖所有 RDMA 细节</td></tr>
|
||||
<tr><td>RDMA</td><td><code>mlx5_0/mlx5_3</code> port_xmit/recv_data 差分</td><td>Port State、GID 与错误计数</td><td>计数单位需要按设备定义换算</td></tr>
|
||||
<tr><td>DCGM</td><td>若可用则记录 SM Active、DRAM Active、Tensor Active、PCIe</td><td>工具版本与可用 Field</td><td>不可用时明确记录，不能用粗粒度指标冒充</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>6. 精简代码设计</h2>
|
||||
<p>计划新增目录：</p>
|
||||
<pre><code>/data/hzy/sskj/experiments/pro6000/
|
||||
dsv4pro_pro6000d_2node_sglang_prefill_hardware_attribution/</code></pre>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>文件</th><th>计划职责</th><th>当前状态</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><code>run_prefill_hardware_attribution.sh</code></td><td>唯一 Shell 入口；服务启停、双节点采集器、单 Case、Trap 清理</td><td class="pending">待实现</td></tr>
|
||||
<tr><td><code>config.env</code></td><td>Phase 1 入口路径、32K Case、采样间隔、结果路径</td><td class="pending">待实现</td></tr>
|
||||
<tr><td><code>hardware_attribution.py</code></td><td>结构化解析、时间对齐、统计摘要与报告生成</td><td class="pending">待实现</td></tr>
|
||||
<tr><td><code>tests/test_hardware_attribution.py</code></td><td>计数器差分、单位换算、统计与缺失工具回退测试</td><td class="pending">待实现</td></tr>
|
||||
<tr><td><code>README.md</code></td><td>入口命令、环境变量和结果目录说明</td><td class="pending">待实现</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p class="decision">
|
||||
Phase 2 不复制双机 Docker 启停实现。唯一入口通过环境变量调用 Phase 1 的
|
||||
<code>run_quick_map.sh start/stop</code>，只新增硬件采集和 32K 请求编排。
|
||||
顶层仍只保留一个 Shell 文件，不创建额外 tmux、launch、start 或 stop 脚本。
|
||||
</p>
|
||||
|
||||
<h2>7. 预期结果结构</h2>
|
||||
<pre><code>results/<RUN_ID>/
|
||||
manifest.json
|
||||
run.log
|
||||
bench/
|
||||
bench_cmd.txt
|
||||
bench.log
|
||||
bench.jsonl
|
||||
service/
|
||||
head_server_cmd.txt
|
||||
worker_server_cmd.txt
|
||||
head_server.log
|
||||
worker_server.log
|
||||
head/
|
||||
gpu.csv
|
||||
cpu_mpstat.log
|
||||
cpu_pidstat.log
|
||||
net_sar.log
|
||||
rdma.csv
|
||||
static/
|
||||
worker/
|
||||
gpu.csv
|
||||
cpu_mpstat.log
|
||||
cpu_pidstat.log
|
||||
net_sar.log
|
||||
rdma.csv
|
||||
static/
|
||||
summary.json
|
||||
summary.csv
|
||||
report.md</code></pre>
|
||||
|
||||
<h2>8. 验收条件</h2>
|
||||
<ul>
|
||||
<li>Bench 的 ISL、OSL、并发、Seed、缓存状态与 Phase 1 的 32K Case 一致。</li>
|
||||
<li>两节点采集器均覆盖请求开始前 15 秒到结束后 15 秒。</li>
|
||||
<li>每份时间序列有节点名、墙钟时间和单调时钟，能与服务 Chunk 日志对齐。</li>
|
||||
<li>采集器不可用时记录 <code>UNAVAILABLE</code> 和原因，不静默跳过。</li>
|
||||
<li>异常退出仍会停止采集器、Head/Worker 容器并确认 GPU 释放。</li>
|
||||
<li>报告至少能缩小到“计算/显存、CPU 调度、网络通信、频率节流、节点不均衡”中的一个或两个方向。</li>
|
||||
<li>若粗粒度指标仍无法区分，明确指出需要 Phase 3 的哪一段 Timeline，而不是强行给根因。</li>
|
||||
</ul>
|
||||
|
||||
<h2>9. 实施记录</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>时间</th><th>代码或运行</th><th>结果</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>2026-07-30 15:46 CST</td><td>创建 Phase 2 设计与档案</td><td>代码尚未开始，等待按本页设计实现</td></tr>
|
||||
<tr><td>2026-07-30 16:35 CST</td><td>完成旧脚本与 quick-map 同口径审计</td><td>排除服务参数、OSL=1 和一次性 JIT；确认旧产物被 Warm-up、跨 Case 与前一轮 Prefix Cache 污染</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>10. 真机结果</h2>
|
||||
<p class="pending">
|
||||
尚未运行。代码实现、静态验证和 Dry-run 完成后，将先向用户说明具体代码改动，
|
||||
再启动真机诊断。
|
||||
</p>
|
||||
|
||||
<p><a class="back" href="./phase1_dsv4pro_pro6000d_2node_sglang_quick_map.html">返回 Phase 1 实施记录</a></p>
|
||||
<p><a class="back" href="./推理优化计划.html">返回推理优化主计划</a></p>
|
||||
</main>
|
||||
</body>
|
||||
</html>
|
||||
@ -0,0 +1,20 @@
|
||||
# DeepSeek-V4-Pro Pro6000D Two-Node SGLang Quick Map
|
||||
|
||||
Profiler: disabled. Speculative decoding: disabled.
|
||||
|
||||
## Aggregate results
|
||||
|
||||
| Case | Suite / role | Stage | ISL | OSL | C | Reps | Total TPS | CV | Output TPS | TTFT P95 | TPOT P95 | E2E P95 | Status |
|
||||
|---|---|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---|
|
||||
| long_prefill_latency_128k_c1 | fixed / - | prefill_latency | 131072 | 1 | 1 | 1/1 | 65.20 | -% | 0.00 | 2010382.63 ms | 0.00 ms | 2010382.70 ms | COMPLETED |
|
||||
| mid_prefill_latency_32k_c1 | fixed / - | prefill_latency | 32768 | 1 | 1 | 1/1 | 64.96 | -% | 0.00 | 504435.18 ms | 0.00 ms | 504435.25 ms | COMPLETED |
|
||||
| mid_prefill_throughput_32k_c16 | fixed / - | prefill_throughput | 32768 | 1 | 16 | 0/1 | - | -% | - | - ms | - ms | - ms | ABORTED |
|
||||
| short_prefill_latency_1k_c1 | fixed / - | prefill_latency | 1024 | 1 | 1 | 1/1 | 64.44 | -% | 0.06 | 15882.76 ms | 0.00 ms | 15882.82 ms | COMPLETED |
|
||||
|
||||
## Failed or incomplete cases
|
||||
|
||||
| Case | Repetition | Status | Error | Exit code |
|
||||
|---|---:|---|---|---:|
|
||||
| mid_prefill_throughput_32k_c16 | 1 | ABORTED | EARLY_STOP_FOR_PHASE2 | 143 |
|
||||
|
||||
The fixed map is descriptive and never stops on SLO. With one repetition, CV is intentionally unavailable.
|
||||
@ -0,0 +1,40 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"workflow_stage": "quick_performance_map",
|
||||
"run_id": "dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625",
|
||||
"status": "ABORTED_EARLY_FOR_PHASE2",
|
||||
"started_at": "2026-07-30T14:36:26+08:00",
|
||||
"updated_at": "2026-07-30T15:44:11+08:00",
|
||||
"suites": [
|
||||
"fixed",
|
||||
"mixed"
|
||||
],
|
||||
"engine": "sglang",
|
||||
"model_name": "DeepSeek-V4-Pro",
|
||||
"model_path": "/data/hf_models/DeepSeek-V4-Pro",
|
||||
"docker_image": "lmsysorg/sglang:nightly-dev-cu13-20260720-b3570a45",
|
||||
"head_node": "10.101.0.11",
|
||||
"worker_node": "10.101.0.13",
|
||||
"head_ip": "10.101.0.11",
|
||||
"sglang_port": 30002,
|
||||
"dist_init_port": 20002,
|
||||
"tp_size": 16,
|
||||
"ep_size": 2,
|
||||
"nnodes": 2,
|
||||
"mem_fraction_static": 0.9,
|
||||
"cuda_graph_max_bs_decode": 64,
|
||||
"max_running_requests": 256,
|
||||
"nccl_socket_ifname": "eth1",
|
||||
"nccl_ib_hca": "mlx5_0,mlx5_3",
|
||||
"nccl_cross_nic": "1",
|
||||
"git_commit": "d5d96bd6f60f7fcdf0e118070ace468698949428",
|
||||
"git_dirty": false,
|
||||
"scenario_file": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/quick_map_scenarios.tsv",
|
||||
"notes": [
|
||||
"The fixed quick map does not stop on SLO.",
|
||||
"Profiler is disabled; these results are eligible for performance comparison.",
|
||||
"Speculative decoding is not enabled.",
|
||||
"Source tree was committed unchanged during model initialization."
|
||||
],
|
||||
"ended_at": "2026-07-30T15:44:11+08:00"
|
||||
}
|
||||
@ -0,0 +1,4 @@
|
||||
{"run_id": "dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625", "suite": "fixed", "case_id": "long_prefill_latency_128k_c1", "role": "", "stage": "prefill_latency", "repetition": 1, "isl": 131072, "osl": 1, "concurrency": 1, "num_prompts": 1, "warmup_requests": 0, "status": "COMPLETED", "error_type": "", "exit_code": 0, "started_at": "2026-07-30T14:52:19+0800", "ended_at": "2026-07-30T15:26:24+0800", "elapsed_s": 2045.0, "completed": 1, "failed": 0, "duration_s": 2010.4037326959951, "actual_concurrency": 0.999989539343442, "peak_concurrent_requests": null, "total_input_tokens": 131072, "total_output_tokens": 1, "request_throughput": 0.0004974125265172375, "input_token_throughput": 65.19685467566735, "output_token_throughput": 0.0004974125265172375, "total_token_throughput": 65.19735208819388, "peak_output_token_throughput": null, "e2e_mean_ms": 2010382.7025530045, "e2e_p50_ms": 2010382.7025530045, "e2e_p95_ms": 2010382.7025530045, "e2e_p99_ms": 2010382.7025530045, "ttft_mean_ms": 2010382.6258230256, "ttft_p50_ms": 2010382.6258230256, "ttft_p95_ms": 2010382.6258230256, "ttft_p99_ms": 2010382.6258230256, "tpot_mean_ms": 0.0, "tpot_p50_ms": 0.0, "tpot_p95_ms": 0.0, "tpot_p99_ms": 0.0, "itl_mean_ms": 0.0, "itl_p50_ms": 0.0, "itl_p95_ms": 0.0, "itl_p99_ms": 0.0, "bench_file": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/long_prefill_latency_128k_c1/rep1/bench.jsonl", "bench_log": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/long_prefill_latency_128k_c1/rep1/bench.log"}
|
||||
{"run_id": "dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625", "suite": "fixed", "case_id": "mid_prefill_latency_32k_c1", "role": "", "stage": "prefill_latency", "repetition": 1, "isl": 32768, "osl": 1, "concurrency": 1, "num_prompts": 1, "warmup_requests": 0, "status": "COMPLETED", "error_type": "", "exit_code": 0, "started_at": "2026-07-30T14:43:15+0800", "ended_at": "2026-07-30T14:52:13+0800", "elapsed_s": 538.0, "completed": 1, "failed": 0, "duration_s": 504.4536426469858, "actual_concurrency": 0.9999635371827135, "peak_concurrent_requests": null, "total_input_tokens": 32768, "total_output_tokens": 1, "request_throughput": 0.001982342707949866, "input_token_throughput": 64.95740585410121, "output_token_throughput": 0.001982342707949866, "total_token_throughput": 64.95938819680917, "peak_output_token_throughput": null, "e2e_mean_ms": 504435.24884598446, "e2e_p50_ms": 504435.24884598446, "e2e_p95_ms": 504435.24884598446, "e2e_p99_ms": 504435.24884598446, "ttft_mean_ms": 504435.1755149837, "ttft_p50_ms": 504435.1755149837, "ttft_p95_ms": 504435.1755149837, "ttft_p99_ms": 504435.1755149837, "tpot_mean_ms": 0.0, "tpot_p50_ms": 0.0, "tpot_p95_ms": 0.0, "tpot_p99_ms": 0.0, "itl_mean_ms": 0.0, "itl_p50_ms": 0.0, "itl_p95_ms": 0.0, "itl_p99_ms": 0.0, "bench_file": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/mid_prefill_latency_32k_c1/rep1/bench.jsonl", "bench_log": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/mid_prefill_latency_32k_c1/rep1/bench.log"}
|
||||
{"run_id": "dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625", "suite": "fixed", "case_id": "mid_prefill_throughput_32k_c16", "role": "", "stage": "prefill_throughput", "repetition": 1, "isl": 32768, "osl": 1, "concurrency": 16, "num_prompts": 16, "warmup_requests": 0, "status": "ABORTED", "error_type": "EARLY_STOP_FOR_PHASE2", "exit_code": 143, "started_at": "2026-07-30T15:26:30+0800", "ended_at": "2026-07-30T15:41:52+0800", "elapsed_s": 922.0, "completed": null, "failed": null, "duration_s": null, "actual_concurrency": null, "peak_concurrent_requests": null, "total_input_tokens": null, "total_output_tokens": null, "request_throughput": null, "input_token_throughput": null, "output_token_throughput": null, "total_token_throughput": null, "peak_output_token_throughput": null, "e2e_mean_ms": null, "e2e_p50_ms": null, "e2e_p95_ms": null, "e2e_p99_ms": null, "ttft_mean_ms": null, "ttft_p50_ms": null, "ttft_p95_ms": null, "ttft_p99_ms": null, "tpot_mean_ms": null, "tpot_p50_ms": null, "tpot_p95_ms": null, "tpot_p99_ms": null, "itl_mean_ms": null, "itl_p50_ms": null, "itl_p95_ms": null, "itl_p99_ms": null, "bench_file": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/mid_prefill_throughput_32k_c16/rep1/bench.jsonl", "bench_log": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/mid_prefill_throughput_32k_c16/rep1/bench.log"}
|
||||
{"run_id": "dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625", "suite": "fixed", "case_id": "short_prefill_latency_1k_c1", "role": "", "stage": "prefill_latency", "repetition": 1, "isl": 1024, "osl": 1, "concurrency": 1, "num_prompts": 1, "warmup_requests": 1, "status": "COMPLETED", "error_type": "", "exit_code": 0, "started_at": "2026-07-30T14:42:04+0800", "ended_at": "2026-07-30T14:43:10+0800", "elapsed_s": 66.0, "completed": 1, "failed": 0, "duration_s": 15.905719314003363, "actual_concurrency": 0.9985603391737933, "peak_concurrent_requests": null, "total_input_tokens": 1024, "total_output_tokens": 1, "request_throughput": 0.06287046692189532, "input_token_throughput": 64.37935812802081, "output_token_throughput": 0.06287046692189532, "total_token_throughput": 64.4422285949427, "peak_output_token_throughput": null, "e2e_mean_ms": 15882.820472994354, "e2e_p50_ms": 15882.820472994354, "e2e_p95_ms": 15882.820472994354, "e2e_p99_ms": 15882.820472994354, "ttft_mean_ms": 15882.760226988466, "ttft_p50_ms": 15882.760226988466, "ttft_p95_ms": 15882.760226988466, "ttft_p99_ms": 15882.760226988466, "tpot_mean_ms": 0.0, "tpot_p50_ms": 0.0, "tpot_p95_ms": 0.0, "tpot_p99_ms": 0.0, "itl_mean_ms": 0.0, "itl_p50_ms": 0.0, "itl_p95_ms": 0.0, "itl_p99_ms": 0.0, "bench_file": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/short_prefill_latency_1k_c1/rep1/bench.jsonl", "bench_log": "/data/hzy/sskj/experiments/pro6000/dsv4pro_pro6000d_2node_sglang_tp16_quick_map/results/dsv4pro-pro6000d-2node-sglang-quick-v2-20260730-143625/cases/short_prefill_latency_1k_c1/rep1/bench.log"}
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@ -0,0 +1,54 @@
|
||||
# DSV4-Pro TP16 TTFT 脚本口径审计
|
||||
|
||||
时间：2026-07-30
|
||||
机器：174.1.51.5 + 174.1.51.7
|
||||
引擎：SGLang TP16 / EP2
|
||||
|
||||
## 结论
|
||||
|
||||
旧脚本的短 TTFT 不是同口径下的更高冷 Prefill 性能。旧结果同时受到以下状态影响：
|
||||
|
||||
- 每个 Shape 固定执行 16 条同 Prompt Warm-up。
|
||||
- Benchmark 不传 `--flush-cache`。
|
||||
- Seed 固定为 42，并按递增 ISL 重复选取同一批 Prompt。
|
||||
- 17:40 的失败 Run 已执行 1K Case，18:01 的正式 Run 未重启服务。
|
||||
- `C=1` 仍至少执行 10 条正式请求，聚合均值混合了不同缓存状态。
|
||||
|
||||
新旧 `server_info` 的关键运行参数一致：同一镜像、TP16、EP2、8K Chunk、FlashInfer
|
||||
MXFP4 MoE、相同的调度和 CUDA Graph 配置。明显的服务启动参数回归已排除。
|
||||
|
||||
## 最小复现
|
||||
|
||||
| Case | Mean TTFT | P95 TTFT | 说明 |
|
||||
|---|---:|---:|---|
|
||||
| 1K→1，首次冷 Cache | 16.04 s | 16.04 s | `warmup=0`，测量前 flush |
|
||||
| 1K→1，原样再次冷 Cache | 15.90 s | 15.90 s | 再次 flush，排除一次性 JIT 主导 |
|
||||
| 1K→128，冷 Cache | 15.79 s | 15.79 s | 排除 OSL=1 特殊慢路径 |
|
||||
| 旧命令语义复现 | 14.60 s | 15.97 s | 10 prompts、16 warmup、不 flush |
|
||||
| 2026-07-28 旧产物 | 0.455 s | 0.513 s | 服务和 Prompt 已被前一轮预热 |
|
||||
|
||||
旧命令语义复现的逐请求 TTFT 为：
|
||||
|
||||
```text
|
||||
4.13, 15.81, 15.70, 15.82, 15.81,
|
||||
15.82, 16.07, 15.42, 15.63, 15.84 seconds
|
||||
```
|
||||
|
||||
它无法复现旧产物约 0.45 秒的结果。
|
||||
|
||||
## 递增长度污染
|
||||
|
||||
旧 32K 产物中，第一条 TTFT 约 0.67 秒，其余 9 条平均约 35.51 秒。旧 128K
|
||||
产物中，第一条约 0.96 秒，其余 9 条平均约 144.83 秒。由于脚本此前已经以相同
|
||||
Seed 跑过 16K、64K，这些请求会继承上一档 Prompt 前缀。
|
||||
|
||||
旧报告仍使用完整 ISL 计算 Input TPS，即使服务实际只需计算新增后缀，所以旧
|
||||
Input TPS 也会被高估。
|
||||
|
||||
## 后续口径
|
||||
|
||||
- Phase 2 继续归因清 Prefix Cache 后的完整冷 Prefill。
|
||||
- Warm Prefix / Prefix Cache 收益单独设计 A/B。
|
||||
- Cold 与 Warm 数据必须分列，不再直接比较。
|
||||
|
||||
原始 JSON 和日志就在本目录。
|
||||
1238
docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html
Normal file
1238
docs/dsv4pro_pro6000d_2node_sglang/推理优化计划.html
Normal file
File diff suppressed because it is too large
Load Diff
Loading…
x
Reference in New Issue
Block a user