347 lines
22 KiB
Markdown
347 lines
22 KiB
Markdown
# EXP-CODE-TRACE：从 chat 1h trace 扩展到 code 与 phase-separated replay
|
||
|
||
> **状态：RUNNING（Phase A code P+D）。** A0 数据/profile、A1
|
||
> max-length smoke、A2 paired canary 与 A3 sim calibration 已完成；
|
||
> A4 第一批 61min real jobs 正在 `dash1`--`dash4` 运行。禁止使用 `dash0`。
|
||
|
||
## 目标与成功定义
|
||
|
||
当前 1h+ 证据只覆盖 Qwen3-30B-A3B 的生产 chat trace、prefill+decode（P+D）和亚临界负载。本 campaign 分两步扩展：
|
||
|
||
1. **主任务：** 使用 `~/ali-trace/trace-glm5.1-formatted/` 中的 1h+ code trace，先完成 P+D real-vs-Frontier 回放；
|
||
2. **后续 phase matrix：** 对 chat/code 都补 prefill-only 和严格 decode-only。
|
||
|
||
本轮不是只看“能否跑完”。每个正式 cell 必须满足：同一 request vector、同一 arrival、同一 token shape、同一 prefix/initial-KV 合约、real 零失败、无持续 backlog，并同时报告 TTFT/TPOT/E2E、queue/batch、KV/prefix state 与 5min 分窗漂移。
|
||
|
||
## 当前决策快照
|
||
|
||
| 项目 | 当前结论 | 下一 gate |
|
||
|---|---|---|
|
||
| code P+D 数据 | 61min development window、long-context profile-v6、四个 paired full 输入已冻结 | 第一批 1h real 运行中 |
|
||
| TP4 负载 | low/mid/near-knee=`rho 0.0002/0.0008/0.0016`；paired canary 的 TTFT/E2E、KV、batch 通过 | 三个 load 的 trial 1 运行中 |
|
||
| TP2 负载 | `rho 0.0004` canary 暴露 TTFT p90 `-32.1%` bad case | 只跑 `rho 0.0002` 1h diagnostic，暂不铺满 |
|
||
| code prefill-only | TP2 已冻结 `rho 0.0004/0.0008/0.0016`，`0.0032` 过载；TP4 到 `0.0032` 仍亚临界 | TP4 追加更高 rho 边界 |
|
||
| strict decode-only | vLLM 0.20.0 有 `DecodeBenchConnector`；Frontier trace generator 尚不能注入 initial computed tokens | C0 contract canary，未进入正式结果 |
|
||
|
||
## 三种 workload mode 的冻结定义
|
||
|
||
| Mode | 保留 | 改写 | 主指标 | 明确不声称 |
|
||
|---|---|---|---|---|
|
||
| P+D | 原 ISL/OSL、arrival、session/prefix | 仅做 source block→16-token runtime block 映射 | TTFT、TPOT、E2E、hit ratio、batch/queue | 不代表 PD 分离 |
|
||
| prefill-only | 原 ISL、arrival、session/prefix | OSL 固定为 1，real `min_tokens=max_tokens=1`，sim decode tokens=1 | TTFT、prefill service/tokens/s、prefix hit、queue | TPOT 不定义；1-token decode 只用于完成请求 |
|
||
| strict decode-only | 原 OSL、context length、arrival burst | arrival 定义为 **KV-ready time**；请求进入 decode 时已有 ISL 长度的 initial KV | TPOT、decode tokens/s、batch/queue、preemption | 不包含 prefill 与 KV transfer latency，不把短 prompt proxy 称为 decode-only |
|
||
|
||
strict decode-only 必须同时具备：
|
||
|
||
- real：vLLM `DecodeBenchConnector`（或等价、经验证的 initial-KV 注入）；
|
||
- sim：Frontier request 在 admission 时已拥有相同长度/块布局的 computed KV；
|
||
- 两侧都不在 decode critical path 重做 prefill；
|
||
- arrival 以 KV-ready time 对齐。若只保留原 trace 的相对到达形状，结论限定为 decode engine compute/scheduling fidelity。
|
||
|
||
在该合约完成前，只允许跑并标注为 **decode-dominant proxy**，不能进入 strict decode-only 结果表。
|
||
|
||
## 为什么 code P+D 不能直接复用 chat 配置
|
||
|
||
已知历史探查显示 code trace ISL p90 约 81.9k，约 32.6% 请求超过旧 `40960` 上限；真实数值必须由本 campaign 重新审计。至少有四个独立适配面：
|
||
|
||
1. **Serving cap：** `max_model_len` 必须覆盖 `ISL+OSL`，不能只看 ISL，也不能静默丢掉超长请求；
|
||
2. **KV capacity：** Qwen3-30B 模型 position limit 为 262144，但 TP1/2/4 在 H20 上是否有足够 KV blocks 是 runtime gate，不由 config.json 自动保证；
|
||
3. **Prefix block：** code source hash 预计为 512-token block，chat harness 原先固定 64→16；
|
||
4. **Profile support：** 当前修复后的 attention profile 只覆盖到约 32k KV context。即使 vLLM 能跑 128k，Frontier 对 32k–128k 仍会出 profile 支撑域；在补 long-context 网格前只能做诊断 replay，不能做 fidelity claim。
|
||
|
||
## Hypotheses
|
||
|
||
- **H-code-generalizes：** 在补齐 long-context profile 支撑域后，code P+D 的 TTFT/TPOT/E2E 分布统计偏差仍处于当前 chat 量级，且 1h 残差不发散。
|
||
- **H-longctx-gap：** code 的主要新增 gap 来自 32k 以上 KV-context 外推；补到 trace p99/max 对应的网格后，TTFT bias 随 ISL 的二次项显著收敛。
|
||
- **H-phase-specific：** prefill-only 主要暴露 long-context/profile gap；strict decode-only 主要暴露 batch-conditioned whole-layer service 与 scheduler fixed-point gap。二者不能用 P+D 的误差抵消来互相证明准确。
|
||
|
||
## Preflight gates（按顺序，任一失败即停止后续真机矩阵）
|
||
|
||
### G0：数据位置与 provenance
|
||
|
||
- 只读列举 `trace-glm5.1-formatted/*.jsonl`，记录文件大小与 SHA256；
|
||
- 确认至少两个独立日期段：一个作为 development，一个 held-out；
|
||
- 本机当前没有该目录；仓库历史记录的远端位置为
|
||
`/home/admin/cpfs/wjh/ali-trace/trace-glm5.1-formatted/`。恢复机器后先确认 `~/ali-trace/...` 是否为同一路径/软链，不能假设。
|
||
|
||
### G1：1h window、schema 与 block contract
|
||
|
||
运行 `audit_code_trace.py`，要求：
|
||
|
||
- timestamp 单调，存在 60–75min 连续稳定窗口；
|
||
- `timestamp/input_length/output_length` 全行存在；
|
||
- `input_length<=0` 或 `output_length<=0` 的行不进入 replay，但必须计数并保留样例。已抽查的两条 0→0 行在 raw trace 中同时满足 `usage.total_tokens=0`、`response_message={}`，属于未发生模型执行的 source request，不是 full-cache decode；
|
||
- `hash_ids` 数量与某个 source block size 在全行严格满足
|
||
`ceil(ISL/source_block_size)`；预计值 512，但以审计结果为准；
|
||
- 记录 ISL/OSL/ISL+OSL 的 p50/p90/p95/p99/max、gap、request rate、prompt/sampling 字段覆盖。
|
||
|
||
选择窗口后用 `prepare_code_window.py` 物化只读派生文件，并按 session root 生成确定性的 `sampling_u`。另一日期段不参与 rho 与 profile 选择。
|
||
|
||
### G2：`max_model_len` data gate
|
||
|
||
source-window audit 先用 `40960/65536/98304/131072/262144` 给出完整
|
||
窗口上界；真实 server 则使用能 **100% 覆盖该 rho 实际 paired requests
|
||
的 `ISL+OSL`** 的最小 16-token 对齐值。规则：
|
||
|
||
- sampling 只按 session-coherent `sampling_u`，不得按 token length 过滤；
|
||
- full source window 的 cap 用于记录 workload envelope，不强迫低 rho cell
|
||
为未被抽中的 outlier 预留 KV capacity；
|
||
- 若某 paired cell max≤131072，使用 131072 或更小的对齐值；超过
|
||
131072 时按该 cell 实际 max 向上对齐，而不是直接跳到 262144；
|
||
- Frontier 的 trace max tokens、predictor max tokens/request、vLLM `--max-model-len` 三处使用同一个 manifest 值。
|
||
|
||
### G3：prompt 与 prefix fidelity
|
||
|
||
优先级：
|
||
|
||
1. 有对齐 prompt text sidecar：用 Qwen tokenizer 重分词，要求 token length 与 trace ISL 全行一致；
|
||
2. trace 内已有 prompt text/token IDs：同样做长度与 hash relation 检查；
|
||
3. 两者都没有：允许用 source hash 确定性展开为 synthetic Qwen token IDs，但结果降级为 **length/arrival/prefix-shape faithful**，不声称 prompt-content 或 MoE routing faithful。
|
||
|
||
不论走哪条路径，source→16 映射冲突、runtime identity collision、parent prefix violation 都必须为 0。P+D/prefill-only 两侧 prefix caching 同开；先用 5–10min TP4/MNS16 做 hit-ratio audit。
|
||
|
||
### G4：long-context profile support
|
||
|
||
现有 profile-v5 的 KV context 上界约 32k，对 code 不足。根据 development window 的 uncached-ISL 分布生成 profile-v6-code-longctx：
|
||
|
||
- full chunk：`q8k`，context 至少覆盖 40k/56k/72k/88k/104k/120k/128k；
|
||
- tail chunk：从真实 `ISL mod 8192` 的 p50/p90 选择 2–4k/4–6k 代表点；
|
||
- TP1/2/4 分开采集，复测 `q1ks8k/q8ks32k` anchor；
|
||
- 每点至少两次 fresh-process repeat；CV≤5%，anchor drift≤10%；
|
||
- profile max context 必须 ≥ development window p99；正式 max claim 要求 ≥ max。若只覆盖 p99，max 以上请求单独列为 out-of-support，不进入总体准确度数字。
|
||
|
||
这是 code P+D 正式 fidelity 的硬 gate。可以先用旧 profile 跑 diagnostic sim 来估 load，但不得与真机组成最终 gap。
|
||
|
||
### G5：vLLM max-length/KV runtime gate
|
||
|
||
对每个候选 topology（先 TP4，再 TP2，TP1 后置）：
|
||
|
||
1. fresh server，以 manifest cap 启动；
|
||
2. 记录 vLLM 版本、model config、GPU KV blocks、maximum concurrency、启动日志；
|
||
3. 发 3 个单请求：ISL p50、p99、max（OSL=1），usage 必须逐 token 对齐；
|
||
4. 发 5min sampled P+D canary，零 OOM/timeout/preemption storm；
|
||
5. 只有 maximum concurrency>1 且 canary drain tail≤窗口时长 10% 才进入 rho calibration。
|
||
|
||
`max_model_len` 变大不等于每个请求都预占最大 KV，但会改变启动合法性与可表达的单请求上界；实际 KV 压力仍由并发 token state 决定。
|
||
|
||
对本模型，`VLLM_ALLOW_LONG_MAX_MODEL_LEN=1` 只放宽 scheduler/config
|
||
校验，不会扩展模型内部 RoPE cache；server 还必须显式传
|
||
`--hf-overrides '{"max_position_embeddings":147456}'`。runner 对
|
||
`MAX_MODEL_LEN>40960` 自动同时设置这两层。长上下文 job 默认使用
|
||
host-local vLLM compile cache；FlashInfer workspace 按 topology 复用，
|
||
避免每个 rho/trial 重编译同一组 fused-MoE kernels。两者只影响启动，
|
||
不进入 replay latency。
|
||
|
||
### G6：每种 mode 独立标定 rho
|
||
|
||
不能复用 P+D rho：
|
||
|
||
- P+D 同时按 raw/prefix-adjusted prefill tokens/s 与 decode tokens/s 看 knee；
|
||
- prefill-only 因 OSL=1，重新按 prefill work 标定；
|
||
- strict decode-only 因无 prefill，按 decode tokens/s 和 batch fixed point 标定。
|
||
|
||
每种 workload×mode 选择 `low/mid/near-knee` 三点；正式点必须亚临界：全请求完成、无持续 backlog、drain tail≤10%、waiting p99 不单调随时间增长。跨 knee 点若运行，只作为 overload boundary，不支持“不发散”结论。
|
||
|
||
`drain tail` 必须同时列出最后完成请求的 arrival、ISL、OSL、waiting
|
||
和 E2E。早于 cutoff 到达但 OSL 很长的请求可以在最后 arrival 后继续
|
||
decode；这属于 intrinsic response tail，不等价于 arrival cutoff 时仍有
|
||
持续增长的 queue backlog。亚临界判断以 queue/waiting trajectory 和
|
||
tail driver 分解共同决定，不能只用一个 drain 秒数。
|
||
|
||
### G7：strict decode-only capability gate
|
||
|
||
先在 10min synthetic trace 上验证：
|
||
|
||
- real connector 确认没有执行 prefill kernel；
|
||
- Frontier ledger 第一个阶段就是 decode，computed tokens=ISL；
|
||
- 相同 context length 下两侧 KV block count 一致；
|
||
- connector preload/transfer 时间独立记账，不混入 TPOT；
|
||
- decode batch telemetry 能覆盖 b1 到目标 batch。
|
||
|
||
若 vLLM 0.20 community stack 没有等价 connector，严格 case 保持 BLOCKED；可另跑 decode-dominant proxy，但单独命名和汇报。
|
||
|
||
## 正式实验矩阵与推进顺序
|
||
|
||
### Phase A：code P+D（第一优先级）
|
||
|
||
1. **A0 CPU/data：** G0–G4；
|
||
2. **A1 max-len smoke：** TP4→TP2；TP1 只在 KV gate 通过后加入；
|
||
3. **A2 paired 10min canary：** TP4/MNS16，low rho，real+sim；
|
||
4. **A3 calibration：** 各 rho 只先跑 sim，冻结 low/mid/near-knee；
|
||
5. **A4 full：** TP4/MNS16、TP2/MNS16 × 3 rho × 2 trial × 60–75min；
|
||
6. **A5 held-out：** 只在 development window 判据冻结后，对第二日期段跑 TP4 的 mid/near-knee。
|
||
|
||
若某 topology 的 near-knee 过载，像现有 chat TP2/ρ0.01 一样排除，不为凑齐矩阵强跑。
|
||
|
||
当前状态：A0–A3 完成。A4 第一批为 TP4
|
||
`rho={0.0002,0.0008,0.0016}` trial 1，以及 TP2 `rho=0.0002`
|
||
trial 1 diagnostic；其余 TP2 cell 等该 diagnostic 验证 canary bad case
|
||
后再决定是否扩展。
|
||
|
||
### Phase B：chat/code prefill-only
|
||
|
||
- 复用各自已物化 window，只把 OSL 改为 1；
|
||
- primary：TP4/MNS16、TP2/MNS16 × 3 独立 rho × 2 trial；
|
||
- 报 TTFT/CDF/quantiles、prefill tokens/s、prefix hit、waiting、chunk/context 分带 residual；
|
||
- TPOT 记为 N/A，E2E 仅作为“一 token completion”辅助值；
|
||
- code 必须继续使用 profile-v6 long-context；chat 使用已验证 profile-v5。
|
||
|
||
### Phase C：chat/code strict decode-only
|
||
|
||
先做 batch-sensitive screening，再决定是否铺满：
|
||
|
||
- **C0 capability canary：** 两 workload × TP4 × MNS{16,128}，10min；
|
||
- **C1 core full：** TP{2,4} × MNS{16,128} × rho{low,near-knee} × 2 trial；
|
||
- **C2 conditional expansion：** 只有当 C1 的 batch 分布从 b≤8 跨到 b>8，或 accuracy gap 随 MNS 改变>5pp，才补 MNS{32,64} 与 mid rho。
|
||
|
||
decode profile/serving anchors 至少覆盖实际 batch p99。当前 whole-layer grid 只对少数 b≤8 有证据，且 b6 有长尾；在 MNS128 case 前必须补 b{1,2,4,8,16,32,64,128} 或实际访问 bucket，不能把 b8 常数外推到 b128。
|
||
|
||
已安装 vLLM 0.20.0 的 `DecodeBenchConnector` 会在首次 schedule 时把
|
||
`request.num_tokens-num_computed_tokens-1` 个 token 标为 external，
|
||
同步向已分配的每层 KV blocks 写 dummy non-zero values，再从最后一个
|
||
prompt token 开始 forward。因此它适合测大 context 下的 decode
|
||
compute/scheduling，但 connector fill 发生在 client admission 之后：
|
||
fill time 必须单独记账并从 KV-ready arrival/TPOT 口径中排除。
|
||
dummy KV 也不提供真实 prompt-content 或 MoE-routing fidelity。
|
||
|
||
Frontier commit `deadc4a3` 的 `Request` 已支持构造
|
||
`num_processed_tokens`，但 `TraceReplayRequestGenerator` 不读取该列；
|
||
因此 sim 侧仍需一个显式、可测试的 `initial_computed_tokens` trace
|
||
contract。C0 必须同时证明 real 首个 model step 是 decode、Frontier
|
||
首个 ledger stage 是 decode，之后才能解除 strict decode-only 的 BLOCKED。
|
||
|
||
## 指标与判据
|
||
|
||
共同口径：
|
||
|
||
- 分布统计偏差：`(sim statistic-real statistic)/real statistic`，不是 per-request MAPE；
|
||
- mean/p50/p90/p99 与 empirical CDF；
|
||
- 5min 分窗，前 15min warmup 不进漂移 slope；
|
||
- batch histogram、time-weighted running/waiting、drain tail、preemption；
|
||
- 两 trial pooled 结果和 trial-to-trial noise floor 分开报告。
|
||
|
||
判据分两层：
|
||
|
||
1. **准确度：** primary latency mean/p90/p99 的 |bias|≤15% 为强通过，15–30% 为有界但需标注 correction，>30% 立 bad case；任何 topology 排序或 SLO feasibility 翻转都单独判 failure，不能被平均值掩盖。
|
||
2. **长时稳定：** `|residual Theil–Sen slope|×12 / real noise floor < 1` 为 H-BOUNDED；只适用于亚临界 cell。
|
||
|
||
mode-specific：
|
||
|
||
- P+D：TTFT/TPOT/E2E 全部 primary；
|
||
- prefill-only：TTFT primary，TPOT N/A；
|
||
- strict decode-only：TPOT primary，TTFT 仅表示 admission/connector overhead，不进入 compute-fidelity gate。
|
||
|
||
## 成本与调度
|
||
|
||
- Phase A core：12 个 60–75min jobs（2 topology×3 load×2 trial），约 15 host-hours；按 TP 加权约 45 H20-GPU-hours，加 2–4 个 smoke/canary；
|
||
- Phase B 两 workload：24 个 full jobs，按相同 75min 上界约 90 H20-GPU-hours；
|
||
- Phase C 不一次铺满。C0 4 个 10min canary；C1 32 个 full jobs；C2 按触发条件追加。
|
||
|
||
每个 job fresh server；只在 `dash1`–`dash4` 全 8 卡 idle/healthy 时启动。即使 TP2/TP4 job 只用部分 GPU，也不在同一 host 并跑，避免 fresh-server 空窗竞态。每一批使用新的 jobs TOML，现有 dispatcher 非幂等。
|
||
|
||
## 预期产物
|
||
|
||
- `inputs/code-audit.json`、`inputs/code-window/window-manifest.json`；
|
||
- P+D/prefill-only 的 paired `frontier.csv`、`real_requests.jsonl` 与 manifest；
|
||
- profile-v6-code-longctx raw/merged profile 与 variance report；
|
||
- 每 cell real/sim request metrics、server telemetry、stage ledger；
|
||
- `results/code-pd-fidelity.md`；
|
||
- 最终 `chat/code × P+D/prefill-only/decode-only` compatibility table。
|
||
|
||
## 已知边界
|
||
|
||
- code trace 来自 GLM5.1 业务，serving model 是 Qwen3-30B；若无原 prompt text，测试只能保持 shape/prefix 结构，不能证明内容相关 routing fidelity；
|
||
- `max_model_len=128k/256k` 解决的是接入上界，不自动解决 32k 以上 profile 外推；
|
||
- strict decode-only 只测 decode engine；完整 PD 分离还需要单独建模 prefill、KV transfer、backpressure 与 KV-ready arrival。
|
||
|
||
## 执行记录（2026-07-23）
|
||
|
||
- fleet probe：dash1–dash4 均为 8×H20；32 张卡 memory.used=0、
|
||
utilization=0、无 compute process、uncorrected ECC=0；
|
||
- 两个 formatted trace 都严格满足 512-token source hash contract；
|
||
- 0513：2,108,130 个有效请求、6090 个 zero-usage source 行；稳定
|
||
development window=`[3480,7140)`，61min、1,078,928 请求；
|
||
- 0529：1,977,423 个有效请求、6031 个 zero-usage source 行；冻结为
|
||
held-out，稳定候选 window=`[2640,6240)`；
|
||
- development window：ISL p50/p90/p99/max =
|
||
20,051/88,224/125,803/202,371；OSL p50/p90/p99/max =
|
||
78/758/6449/131,072；`ISL+OSL max=202,745`；
|
||
- full-window 131072 coverage=99.399%，262144 coverage=100%。但
|
||
session sampling 的候选 `rho<=0.0032` 实际 max total=137,016，因此
|
||
primary server cap 将按最终 cell max 对齐，不为未抽中的 202k outlier
|
||
直接预留 262k；
|
||
- source 无 Qwen-aligned prompt/token IDs。raw canonical prompt 使用 GLM
|
||
token contract，不能同时保持 Qwen token content 与 trace ISL；本 campaign
|
||
采用 synthetic Qwen tokens 保持 length/hash/prefix shape，并降级内容 claim。
|
||
- selected rho=0.0032 中有 1355 个可检查 parent links：tail rewrite
|
||
p50/p90/p95/p99/max=1/1/4/57/169 个 source blocks，说明 coder
|
||
`parent_chat_id` 不等价于 append-only prompt。source hash 序列作为 prefix
|
||
truth；synthetic content block 生成后再计算 parent-sensitive runtime
|
||
identities，避免“相同内容块出现在不同前缀后”造成 Frontier false hit。
|
||
- 远端 Qwen3-30B `config.json` 的原生 position limit 是 40960
|
||
(`rope_theta=1e6`,无 rope_scaling)。147456 profile smoke 在显式
|
||
`VLLM_ALLOW_LONG_MAX_MODEL_LEN=1` 下成功；该 override 只支持
|
||
performance/shape fidelity，不形成生成质量或模型长上下文正确性 claim，
|
||
并作为 provenance 中的显式实验变量。
|
||
- profile-v6-code-longctx 覆盖 TP1/2/4、KV context 到 131072，
|
||
33 个 long-context rows；两次 fresh-process repeat 的最大相对差
|
||
4.648%，旧 anchor drift 最大 1.7%。attention profile SHA256 =
|
||
`fbcf7e1f95789a6f6d771e24d1fc60958b7daf04eb0db260d27869a19d71d550`。
|
||
- TP4 `max_model_len=147456` smoke 已在 dash4 通过。server 日志同时确认
|
||
`max_model_len=147456` 与 `hf_overrides.max_position_embeddings=147456`；
|
||
20,051+78、119,702+68、136,774+242 三个 shape 均成功。对应
|
||
TTFT=853.29/12,699.04/3,820.55ms，TPOT=16.65/7.21/8.13ms。
|
||
最长请求的非单调 TTFT 来自 cold compile/cache state，因此这里只作为
|
||
runtime support gate，不作为 profile accuracy 数据。
|
||
- calibration 全部使用同一 profile-v6 SHA。TP4 的 `rho=0.0016`
|
||
decode batch max=16、drain=21.07s，仍通过 10% 亚临界 gate；TP2 的
|
||
`rho=0.0016` waiting p50=332.97s、drain=976.86s，明确过载并排除。
|
||
完整 compact table 在 `results/calibration-summary.json`。
|
||
- TP2/TP4 的 `rho={0.0002,0.0004,0.0008,0.0016}` 61min full paired
|
||
inputs 已在 CPFS 物化；每个 paired row digest 和 Frontier CSV SHA
|
||
均与 calibration input 逐项一致。manifest 副本在
|
||
`results/paired-input-manifests/`。最大一个目录约 901MiB，不把大型
|
||
token arrays 提交进 Git。
|
||
- code prefill-only 的最大 calibration cache 已物化：
|
||
3477 requests、总 prefill 115,828,371 tokens、OSL 全为 1，
|
||
paired digest=`40865068e02414612ba1cd4595894e20e85e01fd34d73f8660185552d531ecea`。
|
||
- 多 host 并发 server startup 暴露出 shared CPFS AOT cache 和每-job
|
||
FlashInfer JIT 的 apparatus cost。它发生在 readiness 前，不进入 TTFT；
|
||
runner commit `d5bb974` 改为长上下文默认使用 host-local vLLM cache，
|
||
并按 topology 复用 FlashInfer workspace。
|
||
- 第一轮 paired real canary 的 3 次旧 client 运行都只在同一个
|
||
`106709+197` 请求失败，根因是 `return_token_ids` 把 100k+ prompt
|
||
vector 放进单条 SSE event，超过 aiohttp 默认 512KiB line limit。
|
||
commit `e1f2557` 把 exact client read buffer 提到 8MiB；700KiB
|
||
单-event runtime 对照和随后 TP4×2、TP2×1 的 53/53 replay 均通过。
|
||
- TP4 canary 的 real-vs-sim prefix hit ratio =
|
||
`0.239908/0.239973`；pure-decode batch max 都为 4，
|
||
`share(b>1)=15.87%/15.69%`（real 两 trial）vs `16.35%`（sim）。
|
||
TTFT mean/p50/p90/p95/p99 bias =
|
||
`-8.3/-4.1/-8.8/-13.1/-6.3%`，E2E =
|
||
`+2.2/+6.1/+11.0/+1.4/-1.3%`。长 drain 的同一
|
||
`61976+21361` 请求 real=92.61/92.34s、sim=91.37s，不是 backlog。
|
||
- TP4 若把 OSL=4 请求纳入 TPOT，mean/p99 bias 会被单个
|
||
`~213ms/token` 样本放大到 `-29.9%/-71.5%`；OSL≥8 后
|
||
mean/p50/p90/p95/p99 bias =
|
||
`+8.7/+8.2/+0.6/+13.4/+3.7%`。因此 raw TPOT 仍保留，但正式报告必须
|
||
同时给 OSL threshold sensitivity，不能把短输出的三段 inter-token
|
||
interval 当作稳定 decode service。
|
||
- TP4 canary 两 trial 的 real SLO pass rate 都是 `50/53=94.34%`，
|
||
sim 为 `52/53=98.11%`，在 95% feasibility threshold 上发生翻转；
|
||
这由两个临界 TTFT 请求和上述 OSL=4 请求共同造成，作为明确 bad case
|
||
进入 1h 检验，不能被总体 latency gap 掩盖。
|
||
- TP2 canary 的 cache/batch/drain 仍对齐，但 TTFT p90 bias=`-32.1%`，
|
||
E2E p90/p95=`-18.4%/-23.8%`。因此先只启动 low-rho 1h diagnostic，
|
||
不直接铺满 TP2 六个正式 jobs。
|
||
- code prefill-only 已完成 10-cell Frontier calibration。TP2
|
||
`rho=0.0032` drain=1384.59s、waiting p50=751.01s，明确过载；
|
||
`0.0004/0.0008/0.0016` 冻结为 low/mid/near-knee。TP4 到
|
||
`rho=0.0032` 仍只有 9.09s drain，暂称 highest-tested，追加更高 rho
|
||
后才冻结 near-knee。compact table 在
|
||
`results/prefill-only-calibration-summary.json`。
|
||
- 2026-07-23 18:37 UTC 启动 A4 wave 1：dash1=`TP4/rho0.0002/t1`、
|
||
dash3=`TP4/rho0.0008/t1`、dash4=`TP4/rho0.0016/t1`、
|
||
dash2=`TP2/rho0.0002/t1 diagnostic`；四台启动前再次确认 8×H20
|
||
memory/utilization=0、无 compute process、uncorrected ECC=0。
|