Compute Architecture

Tribunus Compute is built on a compile-time architecture. Unlike traditional inference engines that defer kernel selection, memory layout, and scheduling decisions to runtime, Tribunus freezes every decision before the first token is generated. The runtime does not dispatch, guess, or JIT-compile — it replays a pre-certified compute image.

Pipeline Overview

Model → PhaseIR → Candidates → Oracle → Admission → Compute Image

Every step runs at compile time. The output is a single frozen artifact that bundles prequalified backend code, placement manifests, memory layouts, and evidence receipts from every gate along the pipeline.

PhaseIR — Canonical Model Representation

The compiler ingests a trained model and lowers it into PhaseIR, a canonical intermediate representation consumed uniformly by all backend codegen passes. PhaseIR captures every property the compiler needs: operations, tensor shapes, data types, memory layouts, quantization metadata, and control-flow boundaries.

PhaseIR is lossless — it preserves the original numerical contract of the model. Any backend that consumes PhaseIR must produce results within the oracle’s tolerance of the FP32 reference. The IR also carries provenance metadata (model hash, source framework, conversion toolchain version) so every compute image is traceable back to its origin.

Backend Candidate Generation

For each operation in PhaseIR, the compiler generates kernel candidates from multiple sources. A matrix multiplication, for example, may produce candidates from:

• Triton — tiled kernel with configurable block sizes, pipeline stages, and warp scheduling
• cuBLASLt (NVIDIA) — vendor-tuned GEMM with heuristic search over tile/config space
• Metal 3 (Apple Silicon) — Metal Shading Language kernels with threadgroup sizing per GPU generation
• rocBLAS (AMD) — ROCm-tuned BLAS with architecture-specific tile selection
• oneDNN (Intel) — primitive descriptors with AMX/AVX code paths on Xeon, Level Zero on Arc GPUs
• TT-NN (Tenstorrent) — systolic array kernels with explicit data-movement scheduling

Each candidate is compiled to device code independently. The compiler may generate dozens or hundreds of candidates per operation, each representing a different point in the accuracy-performance trade-off space.

The 6-Check Admission Pipeline

Every candidate must pass six serial checks before it is admitted into a compute image:

1. Oracle check — Output compared against the FP32 golden reference at per-element ULP tolerance. A single failure rejects the candidate regardless of performance.
2. Shape check — Candidate produces correct output for all static shapes declared in PhaseIR. Dynamic shape fallbacks are tested at representative bounds.
3. Layout check — Memory layout (row-major, column-major, blocked, interleaved) matches the compute image’s global placement plan. Layout mismatches are caught here, not at runtime.
4. Timing check — Wall-clock execution time must fall within the pipeline’s per-operation budget. Budgets are derived from the target’s peak FLOP/s and memory bandwidth.
5. Replay check — The candidate’s execution path must be deterministic and replayable from the compute image without external state. Random seeds, hardware RNG, and imprecise timers are disallowed.
6. Cache-key check — The candidate’s autotune cache key (backend x op x dtype x shape x batch x quant) is validated against the deployment target. A mismatch forces re-evaluation at the next compile.

A candidate that passes all six checks is admitted. A candidate that fails any check is discarded — the compiler may re-lower with different tile sizes, loop orders, or accumulator types and try again.

The Compute Image

The output of the admission pipeline is a compute image: a self-contained, cryptographically signed artifact containing:

• Prequalified backend code — the exact device binaries (Metal shaders, CUDA fatbins, ROCm code objects, oneDNN primitive caches, TT-NN kernel descriptors) that passed every check
• Placement manifest — which kernels run on which device, execution order, synchronization barriers
• Memory layout — tensor placements, buffer sizes, alignment constraints, page tables for KV cache
• Evidence receipts — per-kernel oracle results, timing measurements, cache-key signatures

At inference time, the runtime loads the compute image and replays it. No compilation, no autotuning, no accuracy verification — the image was already certified. This is what makes Tribunus Compute’s latency predictable: every microsecond of runtime work was measured and approved at compile time.

The compile-time architecture extends to multi-backend deployment. A single compile produces a single compute image with backend-specific regions. If the deployment target is Apple Silicon, the Metal region activates; if NVIDIA, the CUDA region. The same compile-time guarantees apply to every region.