Skip to content

Kimi K3 CPU decode optimizations: MXFP4 kernels, parallel expert streaming, NUMA placement - #2

Open
neilcouture wants to merge 1 commit into
ferrumox:mainfrom
neilcouture:optimize-performance
Open

Kimi K3 CPU decode optimizations: MXFP4 kernels, parallel expert streaming, NUMA placement#2
neilcouture wants to merge 1 commit into
ferrumox:mainfrom
neilcouture:optimize-performance

Conversation

@neilcouture

@neilcouture neilcouture commented Aug 2, 2026

Copy link
Copy Markdown

Summary

Optimization series for Kimi K3 decode on a dual-socket target box, measured against the
real 2.8T checkpoint at every gate. Headline (from PERFORMANCE.md's full-effort scoreboard):
decode goes from 36.8 s/token at the Phase 0 baseline to 16.9 s/token after the
kernel/streaming phases, and 1.26 s/token in live serving with the NUMA work — with
logits bit-identical across every scheduling configuration tested, pinned by per-run
FNV-1a fingerprints.

What's included

  • MXFP4 matmul: scalar kernel hygiene (bit-exact), then an AVX-512 tier
    (within-tolerance), benchmarked in benches/kernels.rs. This was the single biggest
    known K3 perf lever (MXFP4 was scalar-only).
  • Expert streaming: parallel miss loads, --preload-experts, pinning skipped at full
    residency, mlock failure logged once. Preload startup: ~30 min → ~9 min.
  • latent_moe: across-expert parallelism, v2 flattened to (expert × row-block) tasks.
  • NUMA (src/numa.rs, --numa / --numa-threads): topology + placement primitives,
    pinned per-socket pools, expert home nodes, flattened domain dispatch, attention split,
    QTSharded/DenseQT row-sharding for lm_head (2.7× on that bucket).
  • Synthetic K3-at-scale fixture generator (src/bin/gen_k3_synth.rs) so scheduling
    changes can be gated without the 2.8T checkpoint.
  • PERFORMANCE.md: every phase logged with exact commands and hardware, including the
    attempts that were measured and reverted (KDA-projection sharding, target-cpu=native).

Correctness

  • Scheduling-only changes are accepted only on identical logits fingerprints
    (bit-identical logits run-to-run); kernel changes are bit-exact or within-tolerance as
    documented per phase.
  • Timing methodology follows the repo convention: teacher_forced_decode_bench only,
    never free-running greedy decode.

Reproducing

cargo run --release --example teacher_forced_decode_bench -- \
    --model <kimi-k3-dir> --steps 30 --expert-cache 896
cargo bench --bench kernels -- mxfp4

 numactl --interleave=all ./target/release/rabbit --model /data/hf/hub/kimi-k3 --serve --port 8000 --expert-cache 896 --no-usage-cache --preload-experts --threads 48 --numa --numa-threads 192

…aming, NUMA placement

Squashed port of the k3-optimize work:
- MXFP4 matmul: scalar kernel hygiene (bit-exact) plus an AVX-512 tier
  (within-tolerance), benchmarked in benches/kernels.rs
- Expert streaming: parallel miss loads, preload, skip pinning at full
  residency, honest logging
- latent_moe: across-expert parallelism (bit-identical v1)
- NUMA: src/numa.rs topology + placement primitives, --numa flag,
  pinned per-node pools, expert home nodes, per-socket pools with
  flattened domain dispatch, attention split
- QTSharded/DenseQT row-sharding (lm_head kept; KDA projections
  measured and reverted)
- K3 output filter stripping chat-envelope close markup
- Synthetic K3-at-scale fixture generator (src/bin/gen_k3_synth.rs)
  and target-box baseline; PERFORMANCE.md updated with measurements,
  including reverted attempts

Co-Authored-By: Claude <noreply@anthropic.com>
ManuelSLemos added a commit that referenced this pull request Aug 13, 2026
…f all cycles

Squashed from release/v0.28.0 (2 commits, full detail there):
- Real perf profiling (perf stat + perf record -g against the real checkpoint
  mid-decode) contradicted the previous version's conclusion outright: IPC 2.01 and a
  6.13% cache-miss ratio are not the profile of a memory-bandwidth-bound workload. The
  call graph showed __powisf2 -- compiler-rt's GENERIC power routine -- at ~29% of
  total cycles, called from inside matmul_mxfp4_avx512's hot loop.
- Traced to quant::e8m0_decode computing 2f32.powi(byte as i32 - 127), roughly 1.5
  billion times per decode token (once per 32-element MXFP4 block), for something
  IEEE-754 already encodes directly: an E8M0 byte IS f32's own biased exponent field,
  same bias of 127, so f32::from_bits((byte as u32) << 23) is the same value with one
  shift instead of a libm call. byte==0 (2^-127) needs its own subnormal bit pattern,
  being below f32's normal exponent range.
- Verified bit-exact against the old formula for all 255 valid bytes (exhaustive test).
  Real end-to-end, same 40-token prompt and --expert-cache 7, nothing else changed:
  270.2s -> 240.2s total (-11.1%), expert-matmul phase 132.6s -> 101.4s (-23.5%),
  0.148 -> 0.167 tok/s (+12.5%). Isolated kernel: 222.2us -> 145.4us warm (-31%),
  470.7us -> 220.8us cold (-52%).
- Then checked perf's new #2 instead of assuming it was another one: dot_i4_f32_avx512
  at 27.1% looked suspicious, doing ~0.3% of matmul_mxfp4's arithmetic for ~77% as many
  cycles. A matching real-scale bench (a real kv_b-sized ~6.29MiB matrix, warm vs
  cache-evicted) found only a 17% cold penalty, ~7-8ms/token at real call volume --
  negligible against ~5s/token, and flatly inconsistent with 27% of cycles. Ruled out
  as a perf sampling-attribution artifact across many short calls, not a second bug.
- The lesson is recorded in PERFORMANCE_KIMI_K3.md because it cost real time: every
  synthetic benchmark in the prior version was internally consistent and pointed at a
  plausible memory-bandwidth wall, and that story was simply wrong -- a large part of
  "compute" was one badly-chosen libm call. Real hardware-counter profiling settled in
  minutes what hours of indirect benchmarking could only speculate about. Get perf
  working EARLY on any future performance work here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant