Skip to main content

Metria

PyPI CI Metria core

Metria verifies changes to LLM inference systems.

Give it a reference configuration and a candidate configuration. Metria checks what actually ran, rejects an unjustified comparison, measures behavioral change, and evaluates the result against your explicit acceptance criteria.

Test inference changes before you ship them.

The current end-to-end CLI verifies a local llama.cpp CPU thread-count change. It holds the pinned model, qualified capture provider, prompt workload, and other settings fixed, checks native readback, and retains both runs with a reviewable report. The Python runtime adapters and research components support additional building blocks; their presence does not establish a qualified CLI workflow.

Start with one change

For the current development features, install a checkout with Python 3.10–3.14:

git clone https://github.com/dipeshbabu/metria.git
cd metria
python -m pip install .

Prepare the pinned runtime, model, and reference/candidate recipe using the local verification guide, then run:

metria verify study.json --output verification --json

The root Python package has no runtime dependencies. Native engines and models are installed separately. Each output directory must be new.

Published Metria 0.1.0 provides the initial local verifier. The development checkout adds the canonical result, richer diagnostics, explicit policies, performance deltas, and CI integration described here. See the release notes for the published release's scope.

Start with the copyable workflows: a qualified local configuration change, synthetic PASS/FAIL/invalid-comparison fixtures, and clearly staged templates for runtime upgrades, KV precision, quantization, and build regressions. Synthetic examples require no model or GPU and are labeled as test evidence throughout.

Read the decision

Every result separates four questions:

Section What it answers
Change What intentionally differs between reference and candidate?
Evidence What ran, what stayed controlled, and what evidence is missing?
Impact Where did token trajectories diverge, and what compatible systems impact was observed?
Verdict Did execution finish, was comparison valid, and did your policy pass?
verification/
  verification.json
  report.md
  reference.run.json
  candidate.run.json

The original manifest.json filename remains a compatibility alias. The canonical JSON and Markdown report include separate lifecycle, comparison, and policy states. Timeouts, failed runs, insufficient evidence, and unexpected differences remain visible instead of becoming a successful comparison.

Metria distinguishes requested → resolved → observed: a requested setting states intent; the resolved artifact/configuration identifies what will launch; native observation checks what actually applied. A requested CPU thread change must appear in runtime readback before its behavioral result is accepted. An undeclared tokenizer or generation change prevents comparison.

The first behavioral method is KV Fidelity-compatible token-trajectory analysis. It reports prefix agreement, exact matches, first-divergence positions, category rates, and prompt identifiers that help locate drift without dumping prompt text. See behavioral diagnostics.

The current systems method reports compatible cold-process request latency, including startup and model loading. TTFT, decode-only throughput, and device/KV memory remain unavailable until an authoritative method is supported. The report retains trial policy and limitations; see performance evidence.

VERIFIED means valid comparison and completed analysis. Add an explicit acceptance policy for PASS/FAIL. Metria supplies no universal behavior or safety threshold; PASS means your stated criteria were met after the evidence gates passed.

Use it in code review and CI

Run the same command as a job step and preserve its exit status:

- name: Verify inference change
  run: metria verify .metria/change.json --output metria-verification --json

The CI guide defines distinct failure exits, retained artifacts, and a GitHub Actions summary adapter. The copyable workflow keeps the report and records even when verification fails. A real CI workload needs the same qualified runtime/model provisioning as local use.

Scope and qualification

Surface Scope
metria verify Qualified local llama.cpp CPU thread changes, plain greedy completion, pinned model/provider, one reference and one candidate
Runtime adapters llama.cpp and vLLM Python APIs; qualification applies only to retained runtime/model/device configurations
Supporting commands Recipe validation/digests, capability inspection, and saved-record comparison for preparation and debugging
KV Fidelity Independently versioned behavioral methodology/component consumed by Metria's verification path
TurboQuant Reference Portable research/reference implementation with its own lifecycle

See runtime qualification. A mocked contract test, installed engine, or visible GPU is not a real-engine qualification. New routes must prove their identity, requested change, and required captures.

Metria focuses on one inference change at a time. Broad experiment matrices, generic benchmark orchestration, arbitrary plugin discovery, automatic search, Pareto dashboards, additional runtimes solely for breadth, training optimization, and hosted services are deferred until they directly strengthen this verifier. The product decision is tracked in #50.

Supporting APIs and repository

Use the recipe CLI, inspection guide, and saved-record comparison to prepare or debug a verification. The core architecture documents the reusable study/run/evidence machinery behind that workflow.

src/metria/ owns verification and shared evidence contracts. components/kv-fidelity/ owns focused behavioral methods; components/turboquant-reference/ owns the research reference implementation. Current guidance lives in docs/; dated investigations in research/; retained evidence in artifacts/. Historical results keep their original scope and known gaps under the provenance policy.

For development:

uv sync --locked --all-packages
uv run pre-commit install
uv run python -m pytest

See Contributing, Governance, and Support. Cite CITATION.cff and the specific retained report when relying on an experimental result.

Original software uses Apache-2.0; see LICENSE and NOTICE. Third-party/model-derived material retains its separately documented rights.

Metadata

Release files for metria 0.1.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for metria 0.1.1
File Size Uploaded
metria-0.1.1.tar.gz 141.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for metria 0.1.1
File Interpreter ABI Platform
metria-0.1.1-py3-none-any.whl Python 3 none any Details

Total release size: 286.2 kB

Release files / metria-0.1.1.tar.gz

Download URL metria-0.1.1.tar.gz
Size 141.6 kB
Tags Source
SHA-256 checksum
How to use checksums
c416e790233f9a4a1ddf8710e8a7afc52d5376dbaaff08ada7672d4d11771877
BLAKE2b-256 checksum
How to use checksums
d93475c0289f8461d3ad9e0cae3987b72bf06c1b6523727d012dc3273873afa4
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 28, 2026.

Transparency log

Release files / metria-0.1.1-py3-none-any.whl

Download URL metria-0.1.1-py3-none-any.whl
Size 144.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
d818762a0da91407b6eebf6c24329af7c404acf69ddc1bdd625fef7ffd7b2377
BLAKE2b-256 checksum
How to use checksums
cb6b95b5c7ae41d117cce000c9371d03a4c419fc1a8ed0f3a87393ac8b4ee6ca
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 28, 2026.

Transparency log

Release history Release notifications | RSS feed

0.1.2

2 release files

This release

0.1.1 This release

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page