Files
aituner/runs/frontier-fidelity-envelope-v1/qwen235-v020-portability-card.md

2.0 KiB

EXP-SIMFID-Q235-V020-PORTABILITY: large FP8 MoE boundary case

Status: compatibility gate prepared. No Qwen235 vLLM 0.20/deadc4a profile or real/simulator latency result exists yet; historical vLLM 0.10.2 SLO data is explicitly excluded.

Scope

This is the requested Qwen3-235B-A22B-FP8 case, kept separate from the Qwen30 surface. Its purpose is first to establish whether the current Frontier stack can even represent the same large-FP8-MoE runtime; it is not evidence that a Qwen30 profile generalizes.

Item Frozen proposal
model Qwen3-235B-A22B-FP8: FP8 e4m3/dynamic-block checkpoint; BF16 compute/KV contract recorded at runtime
engine community vLLM 0.20.0 (88d34c640…)
simulator Frontier deadc4a…, with frontier.__file__ recorded by each profiler
candidate plans TP4/EP1 and TP8/EP8, each MNS 64/128, MBT=8192
first workload Fixed-P: ISL=2048, OSL=1, prefix off, provisional global QPS=1.6
objective mean/p90 TTFT and E2E; TPOT=N/A

TP1/TP2 do not fit the 239-GB checkpoint. TP8/EP1 is not assumed legal: only the two plans above have existing historical memory/topology evidence.

Gates

  1. A fresh vLLM 0.20 TP4 and TP8 server must load the checkpoint and return an exact 2048→1 response without FP8 fallback. This is a compatibility smoke, not a latency sample.
  2. New model-specific vLLM 0.20/deadc4a profiles must cover linear, router, FP8 MoE, prefill attention, and TP collectives for TP4/TP8. Old vLLM 0.10.2 CUDA-event CSVs are forbidden inputs.
  3. The profile manifest binds model config/quantization, vLLM, exact Frontier import path/commit, hardware, and finite shape coverage. CPU replay must emit legal request metrics before a real surface is launched.
  4. Only then run the four-plan real/simulator Fixed-P surface with three fresh trials; a missing simulator cell is coverage failure, not a poor config.

This ordering prevents a profile-runtime mismatch from being misreported as a simulator tuning failure.