Daniel Han 816c5fb78d Batch-size sweep: flex@256 vs vLLM@256 + max-autotune check ... Added the final two entries to results/flex_vs_vllm.md: | Batch | LoRA | vLLM tok/s | flex tok/s | flex/vLLM | |-------|------|-----------:|-----------:|----------:| | 256 | no | 21170 | 7074 | 33 %| flex scales sub-linearly past batch ~128 (7074 @ 256 vs 6501 @ 128 is only a 9 % jump for 2x batch), while vLLM keeps climbing (14996 -> 21170). That's expected: vLLM's chunked prefill + per-step kernel packing is more efficient at huge batches. For GRPO's realistic batch range (4-64 concurrent seqs) the flex path sits at 30-55 % of vLLM. Also tried `FLEX_COMPILE_MODE=max-autotune-no-cudagraphs` on the flex_attention compile (gated via env var). Same throughput as default compile (2186 vs 2189 at batch 32). max-autotune with cudagraphs crashes because it nests its own cudagraph_trees inside our CUDA graph capture and hits `Cannot prepare for replay during capturing stage`.		2026-04-20 16:17:19 +00:00
..
stats	Batch-size sweep: flex@256 vs vLLM@256 + max-autotune check	2026-04-20 16:17:19 +00:00
flex_vs_vllm.md	Batch-size sweep: flex@256 vs vLLM@256 + max-autotune check	2026-04-20 16:17:19 +00:00
grpo_equivalence.md	Phase 2: 30-step equivalence + pairwise diffs vs vLLM	2026-04-20 15:03:32 +00:00
lora_rollout_baselines.md	Phase 1+3: LoRA rollout benchmarks + CB sync driver + Phase 4 scaffold	2026-04-20 14:01:16 +00:00
notebook_ref_10.md	Add Phase 0+1 GRPO backend comparison scaffolding	2026-04-20 13:54:06 +00:00