Heterogeneous accelerators / workload routing

Compute is a systems problem.

Onion treats GPUs, TPUs, Gaudi, CPUs, memory, model artifacts, compiler state, and network fabric as one schedulable system. The goal is simple: place each AI workload where it can execute correctly, efficiently, and without being trapped behind a single hardware path.

Inspect control plane →Hardware model

WORKLOAD / VISUAL MODEL PIPELINEACTIVE

A source image transformed into a finished visual scene

visual model / workflow studyinput → output

01 / INVENTORY

Describe the node: memory, runtime, topology, locality, current state.

02 / PLACE

Score the workload against the hardware and route it deliberately.

03 / EXECUTE

Load, compile, run, stream, retain useful artifacts, release capacity.

The systems thesis

Every accelerator is a node. Every model is a workload.

Useful compute emerges when capacity is described, measured, routed, cached, compiled, and released as one coherent system.

01 / ENABLE

Make room for other people’s ideas.

Access should help a project begin, not become another barrier to clear.

02 / OWN

Keep the useful layer open.

Self-host the core, inspect the routing, and move between the hardware you can reach.

03 / SHARE

Turn spare capacity into momentum.

Contributors, operators, and teams can participate without pretending they all need the same deal.

“Open source can have super powers when the compute is organized.”

One network / two lanes

Choose how close you want to be to the metal.

The public core stays open. The operating model can meet a community member or a team with a deadline.

Lane ACommunity

Attach capacity. Expose a node.

Register local or shared hardware, publish its capabilities, and let the scheduler place work where memory, data, runtime state, and load make sense.

Self-hosted
Shared resources
Open workflows

Lane BPrivate access

Connect a project. Ship the work.

Use a managed pool when setup is the bottleneck. Reach the models and workflows you need, then scale without rebuilding your whole stack.

Managed endpoints
Usage-shaped scale
No dead-end lock-in

01Register capacity

02Score the node

03Route the job

04Load or evict

05Stream the result

Systems / Compute

Hardware-aware by design.

A useful network respects the awkward details: memory pressure, topology, drivers, precision, and the cost of moving data.

From one GPU to a room of accelerators.

Onion treats heterogeneous hardware as a feature. The scheduler can reason about CPU, RAM, VRAM, current load, locality, and the model already in memory.

GPUTPUIntel GaudiPyTorchJAXDiT / transformersCompilersKernelsPrecisionShardingMulti-acceleratorStreaming jobs

Two labeled rack servers with accelerator cards and storage bays — Useful capacity has many shapes. The job is to make it composable.

Research direction

Visual AI is the proving ground.

Image and video workloads expose every compromise in a system. That makes them a good place to measure honestly and improve in public.

Before and after frames from a visual generation workflow

01 / Image generation

Open diffusion, flow matching, and DiT.

Measure correctness, throughput, memory efficiency, compilation, and accelerator utilization in image workflows.

Dense feature visualizations comparing vision model representations

02 / Video generation

Make long sequences tractable.

Study open video models, long-sequence attention, memory pressure, distributed execution, and inference efficiency.

Benchmark chart showing model ranking improving as training environments scale

03 / Benchmarks

Benchmark the environment too.

Reproduce the result, publish the optimization note, and upstream the fix where possible.

Accelerator and fabric topology diagram — Topology is part of the workload.

Open systems should explain their shape.

We document the path from model to machine: architecture, fabric, routing, and the trade-offs that normally disappear behind a product page.

Reproducible notes · upstreamable fixes · fewer black boxes

Control plane / scheduler

The system decides where work should run.

Placement is a systems problem: memory headroom, topology, current load, model residency, transfer cost, compiler state, and runtime compatibility all matter.

scheduler / reference stateresearch model

queue: READY / heterogeneous workload classes
placement: memory → locality → load → topology
residency: prefer warm model / cached artifact / compiled graph
runtime: PyTorch / JAX / accelerator-native paths
precision: BF16 / FP16 / FP8 / quantized where validated
handoff: stream result / retain artifact / release capacity

capacity classeshardware-aware placement

Class	Memory model	Primary concern	State
NVIDIA GPU	HBM / GDDR	graphs + kernels	TARGET
AMD Instinct	large HBM	ROCm + collectives	TARGET
Intel Gaudi	HBM + fabric	graph compile + scale	TARGET
Cloud TPU	HBM / pod slice	XLA + sharding	TARGET
CPU / edge	system RAM	latency + locality	FALLBACK

Fabric / execution path

A workload is a route through the machine.

The useful abstraction is not “a GPU.” It is the whole path from artifact to memory to fabric to runtime to result.

Artifact path

Execution path

Return path

model.store

node.cache

accelerator

result.stream

Network entrypoint

Three ways into the system.

Onion is organized around resources and workloads, not a generic contact funnel.

onion://entryprotocol / human-readable

[01]attach-capacityRegister a machine or pool as a schedulable resource.

[02]submit-workloadDescribe a model, benchmark, compiler problem, or visual AI workload for placement.

[03]upstream-fixTurn a systems optimization into a reproducible note or upstream patch.

Research network / implementation details evolve with the hardware.inspect control plane ↑