Skip to content

logismos

A GPU inference stack for transformer embedding models, built from the device upward in Rust and HIP for AMD hardware. CPU correctness proven; GPU cutover waits on hardware access.

PHASE 4 BLOCKED ON HARDWARE Repo → Rust · HIP/hipBLASLt · AMD gfx1100 Phases 0-3 complete — Stella 1.5B v5 runs end-to-end on CPU with golden-fixture parity · logismos/README.md status line; crates/logismos/tests/phase_3_stella_parity.rs
logismos · CPU golden-fixture parity test · phase_3_stella_parity, against a committed fixture 1:00 · .tape

RECORDING FORTHCOMING: cargo test -p logismos --test phase_3_stella_parity passing against the committed CPU baseline fixture

What this shows: The correctness harness passing on CPU, against a fixture committed to the repo — proof the inference path is correct independent of GPU hardware. What it doesn’t show: Any GPU run. Phase 4 is hardware-blocked; this recording won't stage one to imply otherwise.

What it is

logismos is a GPU inference stack for transformer embedding models, built from the device upward in Rust and HIP, targeting AMD’s gfx1100 architecture (the W7900). It exists because the alternatives didn’t: Candle has no ROCm backend, and AMD deprecated ONNX Runtime’s ROCm support. Rolling this from scratch keeps the hardware boundary owned in-repo instead of depending on either gap closing upstream.

Decisions and trade-offs

Build the correctness harness before the GPU is available to prove performance

Phases 0 through 3 are complete and CPU-verified: Stella 1.5B v5 runs end-to-end on CPU with parity against a committed golden fixture. Phase 4, the GPU cutover, is blocked on hardware — the AMD W7900 host used for this work is down for recovery, so GPU code paths are unverified until it returns. Rather than treat that as a reason to stop, the project used the wait to build and lock in a CPU correctness harness first. A team without that discipline would have GPU code with nothing to check it against once hardware access resumed; this one has a golden fixture already waiting.

DecisionChoseRejectedCost accepted
Scope boundaryTensor ops on HIP, transformer inference, Stella 1.5B end to end, the EmbeddingModel contract — named explicitlyGrowing into training, non-AMD GPUs, runtime graph optimization, multi-GPUReal capabilities left out on purpose, keeping a 27-crate, ~11K-line project that small by choice
Framework scopeScoped exactly to the knowledge substrate’s actual consumer needBuilding a general-purpose inference frameworkLess reusable for a different model or a different GPU vendor

What’s solid / what’s open

Solid: Phases 0 through 3 — the full CPU inference path for Stella 1.5B, verified against a committed golden fixture, with the exact parity test anyone can run.

Open, stated plainly rather than hidden: Phase 4, the GPU cutover, is blocked on hardware. The AMD W7900 host this work targets is down for recovery; GPU-specific code paths exist but are unverified until it’s back. This is a hardware-availability blocker, not a code-quality one — the CPU path it’s blocked behind is the thing this page can actually show working.

Numbers, and how they were measured

ClaimMethodWhere to check
CPU golden-fixture parity test passescargo test -p logismos --test phase_3_stella_parityphases/03-stella/golden/ in the repo — the fixture itself
10,947 lines Rust (code-only), 12,689 including commentstokei against a local clone, 2026-07-20reproducible: tokei on a fresh clone
27 workspace crates, deliberately small and tightly scopedcrate count in the workspace Cargo.tomlreproducible on a fresh clone

Where to look