Module hardware 

2026-09-30: The hardware axis of the circuit (met circuit plan --hardware <device>): point a model and a target device at it and get the fused plan the device’s kernel class can run, the gap report against that class’s kernel set ranked by the device’s roofline, decode and prefill estimates, and a memory-fit check.

• device: kernels/DEVICES.toml, the SKU registry (roofline, native instruction kinds).
• class: a class’s chain, rules and families, inherited along HARDWARE.toml inherits.
• avail: which kernels the device can run, read from the sources’ guards.
• exec: how a node’s declared formats execute on the device (never a silent upcast).
• plan / gaps / estimate: fuse with gaps marked, classify, estimate.
• model: the model seam (model::CircuitSource).

Owner: metrale-circuit (hardware). Invariants:

• Pure: every file arrives through sources::KernelTree (SBIO); nothing reads the disk, the environment or a clock.
• Deterministic: the same inputs render the same report bytes (the --check tests rely on it).

Re-exports

pub use device::Device;

pub use device::Registry;

pub use device::parse_devices;

pub use model::CircuitSource;

pub use model::InstancesSource;

pub use model::ModelSpec;

pub use model::ModelUnderPlan;

pub use model::PrecisionChoice;

pub use model_checkpoint::CheckpointSource;

pub use sources::ClassSources;

pub use sources::KernelTree;

pub use sources::Module;

Modules

avail

2026-09-30: Which kernels a device can run: a rule’s kernel is available when the class compiles its module and names the function, no MODEL.toml declares it absent, the class’s build defines do not compile its region out, and the device runs natively the instruction kind its source guard stands for (kernels/DEVICES.toml [[guard]]).

class

2026-09-30: A kernel class (kernels/<class>/) as the planner sees it: its inheritance chain and build defines from HARDWARE.toml, its fusion rules (FUSIONS.toml, inherited and overridden along the chain) and its kernel families (KERNEL_FAMILIES.toml, with points rediscovered from the class’s own resolved sources and evidence kept per class).

device

2026-09-30: kernels/DEVICES.toml: the GPU SKUs a circuit is planned for, the kernel class each builds, its roofline and the tensor-core instruction kinds it runs natively, plus the source guards that compile a kernel only where an instruction kind exists.

estimate

2026-09-30: Roofline estimates on one device: the decode step at a batch, prefill of a prompt, and whether weights plus KV and recurrent state fit in the device’s usable memory.

exec

2026-09-30: How a weight-reading node executes its DECLARED formats on a device. The declared precision is never changed here; what varies per device is the instruction that carries it:

gaps

2026-09-30: The Venn/gap table of one plan on one device: every node of the mode’s section, grouped by site (a template node across its layers), classified against the families the device can run, and ranked by its share of the device’s estimated step time.

model

2026-09-30: The model side of a hardware plan: a circuit at its checkpoint’s formats, the serving policy its rules read, and the kernel target (<model>/<quant>) whose sources a class compiles for it. CircuitSource is the one seam between the hardware axis and how a circuit is instantiated (today kernels/circuits/INSTANCES.toml; the checkpoint instantiation plugs in behind the same trait).

model_checkpoint

2026-09-30: The model source over the checkpoint itself: config.json (and the sidecar hf_quant_config.json) resolved by crate::resolve_checkpoint at the declared formats, with the serving policy derived from the checkpoint and the engine’s stated defaults. A recipe request goes to the recipe’s golden instance (InstancesSource), whose formats are the recipe’s.

plan

2026-09-30: Plan one model on one device: resolve the device’s class (chain, rules, kernel sources, families), check the class’s build against the device, fuse every requested mode and row count with the kernels the device can run, and mark every node no rule covers as a gap instead of failing.

sources

2026-09-30: What the caller resolves from the kernel tree for one class: the modules a target of the class compiles (after inheritance, shadows and [modules] renames), every file the resolution stages, and the kernels its MODEL.tomls declare absent. The pure planner reads nothing else about the sources.

tc_policy

2026-10-02: The tensor-core policy of a kernel class (kernels/<class>/HARDWARE.toml [tensor_core_policy]): which ops, at which modes, row counts and weight formats, a plan MUST run on a tensor-core kernel, and the stated exemptions. audit checks one fused plan against it from the compute units the class’s kernel families declare (venn::compute).

Structs

HwReport

2026-09-30: A built hardware report.

OnePlan

2026-09-30: One fused plan of model on device_id at run, with the policy and plan header it was made under: the plan met circuit plan --format plan prints and met circuit display --hardware draws.

Enums

HwError

2026-09-30: Why a hardware plan could not be built.

Constants

PREFILL_TOKENS

2026-09-30: Prompt lengths every report estimates.

Functions

build_report

2026-09-30: Build the report of model on device_id.

display_on

2026-09-30: Draw one as met circuit display does (placeholder groups show their novel emitter).

plan_one

2026-09-30: Plan model on device_id at run.

plan_text

2026-09-30: one’s plan text, followed by each applicable route’s plan under a heading that names the route, its condition and the settings it is planned as. 2026-10-02: Each group line names the compute unit its kernels run on (compute=).

port_lists

2026-09-30: The port lists of a matrix: per device (in the order given), every rule kernel some model’s policy could select that the device cannot run, with why and how many of the matrix’s models are affected.

render_report

2026-09-30: The report text.

summary_row

2026-09-30: The report’s row of the roadmap matrix: coverage, the top five gaps at C=16, and the memory fit.

Type Aliases

PortList

2026-09-30: One device’s port list: kernel to (why the device cannot run it, how many of the matrix’s models need it).