Skip to content

perf(llama32_1b): batched dispatch + sibling fusion on the dual-hart … - #225

Open
karabambus wants to merge 1 commit into
aifoundry-org:mainfrom
karabambus:llama32-uberkernel-ours-submission
Open

perf(llama32_1b): batched dispatch + sibling fusion on the dual-hart …#225
karabambus wants to merge 1 commit into
aifoundry-org:mainfrom
karabambus:llama32-uberkernel-ours-submission

Conversation

@karabambus

@karabambus karabambus commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Board resultivan@aifoundry2, trusted harness, runtime ef15baf34

metric value
decode 17.5318 tok/s — 3 reps [17.5732, 17.5237, 17.5318], CV 0.12%
prefill 77.5222 tok/s
perplexity 15.3098 (CPU 15.31, ET-vs-CPU relative difference 1.3e-05)
generation validated, expected OK OK OK…, 96 tokens

Previous best passing run on this harness was 13.9664 tok/s, so +25.5% at unchanged quality.

⚠ CI's Trusted Llama board evaluation on this PR fails before running any benchmark —
the launcher build dies with undefined reference to google::LogMessage::… while linking
erbium_soc1sim_argbuf_dynmem. Exit code 2, which the workflow maps to
infrastructure-error. The same failure hits #215, #221, #226, #227 and #228 across three
teams, which is why the leaderboard has not updated since 2026-07-24. Resolve trusted candidate and Leaderboard gate pass here, so the candidate itself resolves fine.

Note: #228 supersedes this PR — same stack plus a log-depth barrier release, measured at
17.8109 tok/s at the same PPL.


What changed

Three layers, all on the decode path:

  1. Dual-hart K-split Q8_0 kernel unchanged from our previously validated revision. mul_mat_Q8_0.c and platform.h are byte-identical to 635ef76b2; this PR does not touch the dot product.

  2. Sibling mul_mat fusion. The decode graph emits two sets of independent Q8_0 mul_mats per layer that share one activation and write disjoint outputs. The Q/K/V projections and the FFN gate/up pair. They need no barrier between them, so each set is issued as a single instruction: 32 groups, 48 of 347 launches removed per token.

  3. Batched dispatch with a cross-shire publish protocol. The graph runs as one launch instead of ~347, with an on-device barrier between ops rather than a host round-trip.

This is not correct on its own. Batching removes the per-launch chip-wide L1+L2 evict that firmware performs after every launch, and on ET-SoC-1 that evict is the only thing publishing a kernel's output across shires. The kernels store dst with plain fsw.ps, which is not visible cross-shire.

So the host now decodes each op's source and destination ranges and, when a later instruction reads an earlier one's output, marks that producer. The dispatcher fences and evicts only those ranges past L2 after the producing instruction. It reuses the barrier already at the top of the next iteration to separate the publish from the consumer's read, so no barrier is added. Weights and any output nobody re-reads cost nothing.

Two defects in the barrier were fixed along the way, both on the path executed before every instruction: the chip-wide counter lived in .bss, which the linker script marks NOLOAD so its zeros are never written to the device; and the release credited a hardcoded 33 shires regardless of the launch mask, which leaks credits into shires the launch does not own.

Provenance

The batched-dispatch mechanism is from the upstream ET backend (llama.cpp #24179, Martin Chang). The K-split kernel, the sibling fusion, the graph reordering, the cross-shire publish protocol and the barrier fixes are ours.

@karabambus
karabambus requested a review from AFOliveira as a code owner July 26, 2026 10:59
@github-actions github-actions Bot added track: week-2-challenge Week 2 focused hardware challenge track: llama-3.2-1b-performance Global Llama 3.2 1B performance prize labels Jul 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

track: llama-3.2-1b-performance Global Llama 3.2 1B performance prize track: week-2-challenge Week 2 focused hardware challenge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant