|
| 1 | +# B200 Optimization Suite |
| 2 | + |
| 3 | +This suite separates three questions that must not be collapsed into one |
| 4 | +speedup number: |
| 5 | + |
| 6 | +1. Does each kernel produce correct output on SM100a? |
| 7 | +2. Which Blackwell math pipeline is best for a given dense expert shape? |
| 8 | +3. Does dynamic expert-tile assignment recover enough load balance to pay for |
| 9 | + its queue overhead? |
| 10 | + |
| 11 | +## Implemented paths |
| 12 | + |
| 13 | +| Path | Purpose | Blackwell mechanisms | |
| 14 | +| --- | --- | --- | |
| 15 | +| CUTLASS grouped baseline | Irregular MoE reference | Portable grouped GEMM | |
| 16 | +| 1-SM collective | Optimized native reference | TMA, auto-staged warp specialization, tcgen05, TMEM, TMA epilogue, persistent CLC | |
| 17 | +| 2-SM collective | Cooperative native reference | 2-SM tcgen05, TMA multicast, auto-staged warp specialization, TMEM, persistent CLC | |
| 18 | +| Direct CuTe | Inspectable teaching kernel | Explicit TMA barriers, TMEM allocation, tcgen05 MMA, TMEM-to-register load | |
| 19 | +| Scheduler probe | Project-owned policy experiment | Persistent CTAs, static assignment, atomic dynamic queue, chunked claims | |
| 20 | + |
| 21 | +The scheduler probe intentionally uses deterministic integer work proportional |
| 22 | +to `valid_m * valid_n`; it does not execute GEMM. Its latency measures queue and |
| 23 | +load-balancing behavior in isolation. It must not be reported as a GEMM |
| 24 | +speedup. The native collective benchmarks measure the math pipeline, while a |
| 25 | +later integration combines project-owned expert-tile acquisition with that |
| 26 | +pipeline. |
| 27 | + |
| 28 | +## Build |
| 29 | + |
| 30 | +```bash |
| 31 | +cmake -S . -B build-gpu-make -G "Unix Makefiles" \ |
| 32 | + -DCMAKE_BUILD_TYPE=Release \ |
| 33 | + -DBLACKWELL_MOE_ENABLE_CUDA=ON \ |
| 34 | + -DBLACKWELL_MOE_ENABLE_SM100_NATIVE=ON \ |
| 35 | + -DBLACKWELL_MOE_CUDA_ARCHITECTURES=100 \ |
| 36 | + -DBLACKWELL_MOE_BUILD_TESTS=ON |
| 37 | + |
| 38 | +cmake --build build-gpu-make -j "$(nproc)" |
| 39 | +``` |
| 40 | + |
| 41 | +The native translation units are compiled for `compute_100a/sm_100a`; the |
| 42 | +architecture-accelerated suffix is required for tcgen05 and TMEM. |
| 43 | + |
| 44 | +## Run everything once |
| 45 | + |
| 46 | +```bash |
| 47 | +./tools/run_b200_optimization_suite.sh \ |
| 48 | + build-gpu-make \ |
| 49 | + results/b200-optimization-suite |
| 50 | +``` |
| 51 | + |
| 52 | +For a cheaper smoke run before the full matrix: |
| 53 | + |
| 54 | +```bash |
| 55 | +BLACKWELL_MOE_WARMUP=5 BLACKWELL_MOE_ITERATIONS=20 \ |
| 56 | + ./tools/run_b200_optimization_suite.sh \ |
| 57 | + build-gpu-make \ |
| 58 | + results/b200-optimization-smoke |
| 59 | +``` |
| 60 | + |
| 61 | +The script runs all correctness tests first and stops on the first failure. It |
| 62 | +then writes: |
| 63 | + |
| 64 | +- `environment.txt`: GPU, driver, CUDA, and CMake metadata; |
| 65 | +- `correctness.log`: CPU, grouped-GEMM, scheduler, and SM100a gates; |
| 66 | +- `grouped_baseline.csv`: routing-distribution baseline; |
| 67 | +- `native_1sm_vs_2sm.csv`: 1-SM/2-SM crossover sweep; |
| 68 | +- `direct_cute.csv`: explicit primitive path; |
| 69 | +- `scheduler_probe.csv`: static/dynamic and claim-size sweep; |
| 70 | +- a compressed `.tar.gz` archive next to the result directory. |
| 71 | + |
| 72 | +## How to read the scheduler rows |
| 73 | + |
| 74 | +- `median_ms` and `p95_ms` include the probe kernel but exclude host workload |
| 75 | + generation and the queue reset. |
| 76 | +- `observed_cta_work_cv` is measured from device counters after execution. |
| 77 | +- `tail_ratio = max(CTA work) / mean(CTA work)`; lower is better. |
| 78 | +- `observed_utilization = mean(CTA work) / max(CTA work)`; higher is better. |
| 79 | +- `claim_size=1` maximizes adaptability and atomic traffic; larger chunks |
| 80 | + amortize atomics but can reintroduce tail imbalance. |
| 81 | + |
| 82 | +The desired result is a crossover, not a universal winner. Uniform workloads |
| 83 | +should expose dynamic-queue overhead. Heavy-hitter and Zipf workloads should |
| 84 | +show whether reduced tail imbalance compensates for that overhead. Sparse |
| 85 | +workloads additionally test active-expert compaction because zero-token experts |
| 86 | +produce no device work items. |
| 87 | + |
| 88 | +## Runtime validation boundary |
| 89 | + |
| 90 | +GitHub Actions compile every CUDA target for `sm_100a` in an official CUDA 13 |
| 91 | +development container, but Actions do not provide a B200. A green CI check |
| 92 | +therefore proves compilation only. Correctness, latency, generated SASS, and |
| 93 | +performance-counter claims remain unvalidated until this suite runs on B200. |
0 commit comments