Furiosa RNGD AI accelerator card in red with specifications highlighting TFLOPS, HBM3 memory, SRAM, and memory bandwidth.

Generate more tokens per watt

Tensor Contraction Processor, architected in the shape of AI

OUR APPROACH

A computer architecture built around how AI models compute

Clean-slate design for the AI era

We didn’t adapt a GPU or a CPU. We built the architecture AI inference actually needs, with the freedom to reshape memory, compute and control around it.

Tensor contraction: the highest useful abstraction for AI

The primitive operation in every AI model is a tensor contraction. We built the chip around that. The hardware looks like the model, not like a grid of threads or a matrix-multiply unit.

Diagram: neural network layers reduce to tensor contractions, which the TCP executes natively

Hardware becomes efficient

Because the silicon executes whole contractions, operands stay put and data barely has to move.

Software becomes programmable

Because the silicon speaks the model’s own abstraction, the gap between model and hardware nearly closes.

HARDWARE

A high-level abstraction makes hardware efficient with less data movement and flexible dataflow

Diagram comparing data movement in the TCP, which keeps data in local SRAM, with a GPU, which moves it across caches

DATA LOCALITY

Less data movement, higher utilization

In production inference, data movement is the biggest lever on performance per watt. On GPUs, fixed 2D execution grids mean the software stack keeps reshaping and shuffling data across caches and register files, which adds latency and power.

The TCP runs multi-dimensional operations directly on-chip, keeps data in local SRAM, and minimizes movement to and from memory.

Two 3D cubes, one light and one dark, separated by a multiplication sign on a black background.

DATAFLOW

Flexible dataflow adaptation for diverse tensor shapes

Fixed-size systolic arrays such as Tensor Processing Units (TPUs) deliver high density but are bound to rigid, fixed-dimension physical systolic arrays built for uniform matrix multiplication. When subjected to the highly variable, asymmetric tensor shapes characteristic of production inference, these rigid grids suffer from massive structural under-utilization and bubble injection.

The TCP redefines generality through micro-architectural plasticity, deploying flexible execution units anchored by fluid dot-product primitives. By integrating these primitives directly inside the compute blocks, the hardware exposes multiple physical pathways for data flow. The compiler can dynamically configure these lanes to modify data-reuse vectors in real time, maintaining peak hardware utilization across diverse tensor layouts.

SOFTWARE

A high-level abstraction makes software easy to program and optimize

@tcl.tensor_operation
def e8m0_to_f32(e):
    bits = tcl.operation.shl(e, 23)
    return tcl.commit(tcl.operation.reinterpret_as_float(bits)) 

@tcl.tensor_operation
def mxfp4_quantized_einsum(
        w_f4, x, scale, lut, contracted_axes, reduce_axes, output_axes
    ):
    w = tcl.fetch.table_lookup(w_f4, lut)
    acc = tcl.operation.contract(w, x, contracted_axes=contracted_axes)
    acc = tcl.operation.mulf(acc, scale)
    y = tcl.operation.reduce(acc, axes=reduce_axes, op=tcl.Addf)
    return tcl.commit.permute(tcl.commit.typecast(y, tcl.bf16), output_axes)

@tcl.kernel
def mxfp4_matmul(
        x: tcl.bf16[M, Ko, Ki], 
        w: tcl.f4_e2[N, Ko, Ki], 
        scale: tcl.u8[N, Ko]
    ) -> tcl.bf16[M, N]:
    L = tcl.Axis(16)
    f4_to_bf16_table: tcl.bf16[L] = tcl.vector(          
    	[0.0, 0.5, 1.0, ..., -6.0] 
    )
    scale_f32 = e8m0_to_f32(scale)
    return mxfp4_quantized_einsum(
        w, x, scale_f32, f4_to_bf16_table, [Ki], [Ko], [M, N]
    )

PROGRAMMING INTERFACE

Easy to lay out mathematical intention, easy to optimize

Lay out the math in code

The TCP matches the mathematical expression of the workload directly in silicon, treating the tensor operation as a first-class citizen. When you want finer control, TCL and vISA give you kernel-level access.

Let the compiler fit it to the hardware

Because hardware executions on the Tensor Contraction Processor are predictable, the compiler plans memory allocation and instruction scheduling ahead of time and searches a bounded space of shapes and tactics. New models run well without hand-written kernels.

COMPILER

Driving global compiler optimization

Eliminating runtime data orchestration overhead requires an architectural contract that substitutes dynamic hardware scheduling with static, compile-time layout optimization. Legacy architectures introduce hardware-controlled caching and dynamic thread scheduling, creating non-deterministic execution behaviors that force the compiler into reactive mitigation.

On the TCP, execution is structured and predictable, so parallelism and data routing can be planned at compile time. The Furiosa Compiler treats the whole network graph as one optimization problem and minimizes data movement end to end.

SWEET SPOT FOR INFERENCE

Block diagram showing four slices labeled Slice 00 to Slice 03, each containing sections for SRAM, Fetch Unit with a grey status bar, Operation Unit with a brown Contraction Engine bar, Vector Engine, and Commit Unit.

A rigid trade-off

Chip design has long traded one thing for another: GPUs are general but spend energy on control and data movement; fixed-function arrays are efficient but rigid.

Built for tensor contraction

The Tensor Contraction Processor sits between the two: programmable enough for changing models and agentic workloads, and efficient because it runs tensor contraction natively. By mapping the higher-dimensional geometry of the tensor directly onto the silicon, the TCP unifies software-programmable dataflow generality with the deterministic power efficiency of dedicated primitives.