Kimi K3 CPU decode optimizations: MXFP4 kernels, parallel expert streaming, NUMA placement - #2
Open
neilcouture wants to merge 1 commit into
Open
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
(within-tolerance), benchmarked in
benches/kernels.rs. This was the single biggestknown K3 perf lever (MXFP4 was scalar-only).
--preload-experts, pinning skipped at fullresidency, mlock failure logged once. Preload startup: ~30 min → ~9 min.
latent_moe: across-expert parallelism, v2 flattened to (expert × row-block) tasks.src/numa.rs,--numa/--numa-threads): topology + placement primitives,pinned per-socket pools, expert home nodes, flattened domain dispatch, attention split,
QTSharded/DenseQTrow-sharding forlm_head(2.7× on that bucket).src/bin/gen_k3_synth.rs) so schedulingchanges can be gated without the 2.8T checkpoint.
attempts that were measured and reverted (KDA-projection sharding,
target-cpu=native).Correctness
(bit-identical logits run-to-run); kernel changes are bit-exact or within-tolerance as
documented per phase.
teacher_forced_decode_benchonly,never free-running greedy decode.
Reproducing