# Larry v4-600 TP2×4 768P 吞吐结果

## 有效运行

- 运行目录：`results/lora-v4-600-tp2x4-768p-8nfe-5s-20260830-run2`
- 模型/任务：MiniMax-H3 FL2VA
- 框架：SGLang 0.5.18
- 拓扑：TP2×4，8× RTX 6000D
- 输出：768P、5 秒、16:9
- LoRA：`minimax_h3_turbo_v4_step600_ema.safetensors`，scale 1.0，静态 `auto` merge
- 采样：请求 `num_inference_steps=9`，对应 8 次 denoiser evaluation
- 正式样本：32 条，每实例 8 条；实例间并行，实例内串行

| 指标 | 结果 |
|---|---:|
| 成功/失败 | 32 / 0 |
| Machine wall time | 1007.212 s |
| Machine QPS | 0.03177085 |
| 折算请求量 | 114.38 条/小时 |
| 平均端到端时延 | 125.6795 s |
| P50 | 125.6533 s |
| P95 | 125.6944 s |

## 与已有 Base 的对比

已有 Base TP2×4 混合分辨率实验中，768P FL2VA 的平均时延为 281.5203 秒。该分桶只有 8 条且混在 480/720/768/1080P 序列中，因此没有独立的纯 768P machine wall time；按四实例串行服务估算，Base 纯 768P 吞吐约为 `4 / 281.5203 = 0.01420856 QPS`，即约 51.15 条/小时。

| 指标 | Base | Larry v4-600 | 变化 |
|---|---:|---:|---:|
| 请求网格点 | 20 | 9 | -55% |
| 实际 denoiser evaluations | 19 | 8 | -57.9% |
| 768P 平均时延 | 281.5203 s | 125.6795 s | 2.240× 加速 |
| 768P machine QPS | 约 0.01420856 | 0.03177085 | 约 2.236× |
| 每小时请求量 | 约 51.15 | 114.38 | 约 +63.23 条 |

理论 NFE 比值为 `19 / 8 = 2.375×`，实际端到端时延加速为 2.240×，约达到理论比例的 94.3%；剩余差异来自文本/图片编码、VAE decode、封装写盘和请求调度等非 denoise 固定成本。

对比限制：Base 来自 SGLang 0.5.17 的既有混合分辨率运行，LoRA 来自 SGLang 0.5.18 的纯 768P 运行。当前结果足以给出工程吞吐提升，但若要严格拆分 LoRA 与框架升级各自贡献，应在 0.5.18 上补跑同样 32 条纯 768P Base 20-grid 对照。

## 兼容性记录

首次 `run1` 已成功完成模型推理，但新 Conda 环境的 `bin` 未加入非交互 tmux 的 `PATH`，导致最终输出校验找不到 `ffprobe`。正式样本尚未开始，编排器自动停止服务并释放 GPU。脚本随后显式加入 `sglang-lora/bin`，`run2` 的 warmup 和 32 条正式样本全部通过。