Model reference · open weights
tiron is an open-weight audio or speech model from Trelis. tiron (BF16) weighs 3.1 GB; the smallest configuration that runs it is RTX 3060 12 GB.
For self-hosting, compare this build's requirements below with the GPU you plan to rent.
Summary of the Trelis/tiron model card, 2026-10-01
What it is
| Released by | Trelis |
|---|---|
| Released | 2026-07-18 |
| Parameters | 1.5B |
| VRAM | 3.1 GB for the weights |
What it runs on
| Card | One stream | Memory |
|---|---|---|
| RTX 3060 12 GB | fits | 11.6 GB |
| RTX 4060 Ti 16 GB | fits | 15.4 GB |
| RTX 3090 24 GB | fits | 23.4 GB |
| RTX 4090 24 GB | fits | 23.4 GB |
| RTX 5090 32 GB | fits | 31.0 GB |
| L40S 48 GB | fits | 44.0 GB |
| A100 80 GB | fits | 78.2 GB |
| H100 80 GB | fits | 78.1 GB |
| RTX PRO 6000 Blackwell 96 GB | fits | 93.8 GB |
| DGX Spark (GB10) 128 GB unified | fits | 107 GB |
| H200 141 GB | fits | 138 GB |
| B200 180 GB | fits | 176 GB |
From the model card
Released 21 July 2026. Updated 23 July 2026.
Tiron is an open-weights multi-speaker meeting transcription model. It jointly transcribes and attributes speech to speakers in a single decoding pass: for each 30-second audio window it emits an inline transcript with turn markers (up to 8 speakers per window) and timestamps.
Tiron uses the Whisper large-v3 architecture with an extended token vocabulary (…, ``). It is a drop-in WhisperForConditionalGeneration checkpoint.
On whole-meeting benchmarks, Tiron outperforms leading commercial transcription APIs on every test set we evaluated, and trades leads with the best open research models. Tiron runs at ~43× real-time on a single GPU in 3–12 GB of VRAM, decoding chunks in parallel (see Benchmarks).
For whole meetings (beyond a single 30s window), use the open-source harness at TrelisResearch/tiron, which adds chunking, cross-window speaker linking (ECAPA voice embeddings), and SRT/VTT/JSON output.
universal-3.5-pro under the identical scoring harness.Pooled corpus cpWER (lower is better) on held-out whole-meeting test sets, scored with identical references, normalization, and `` masking for every system:
| Test set | AssemblyAI u3-pro | AssemblyAI u3.5-pro | MOSS-TD 0.9B | Tiron | Tiron (21 Jul) |
|---|---|---|---|---|---|
| AMI (4 meetings) | 39.49 | 39.29 | 28.61 | 34.68 | 35.24 |
| ICSI (3 meetings) | 34.64 | 30.50 | 21.84 | 21.24 | 20.91 |
| NOTSOFAR-1 (10 meetings) | 39.55 | 39.14 | 25.86 | 36.23 | 37.55 |
| Macro (mean of corpora) | 37.89 | 36.31 | 25.44 | 30.71 | 31.23 |
Tiron leads both AssemblyAI models on every corpus (−19% macro vs universal-3-pro, −15% vs universal-3.5-pro). MOSS-Transcribe-Diarize (Apache-2.0, ~2.5B incl. encoder) decodes the whole meeting in a single 128k context — it leads on AMI and NOTSOFAR-1, and the two are effectively tied on ICSI. Google Gemini 3.1 Pro is competitive on short clips but truncates or fails on longer meetings and cannot be scored across full corpora.
MOSS numbers use a quality-preserving vLLM decode configuration. We found MOSS's scores are sensitive to serving configuration (an aggressive speed-oriented vLLM config cost it several points on NOTSOFAR-1), so we report its best-quality vLLM decode here.
Speed (× real-time, whole-meeting inference over all 17 meetings; median [range]). Each system's speed is measured in the same configuration as its accuracy numbers above:
| System | ×RT median [range] | Notes |
|---|---|---|
| Tiron | 43× [8×–76×] | single GPU, chunk-parallel, 3–12 GB VRAM |
| MOSS-TD (vLLM) | 3× [1×–8×] quality decode · ~41× speed-oriented | whole-meeting 128k context; accuracy above is the quality decode |
Tiron is chunk-based, so a meeting's 30-second windows decode in parallel on one GPU — that is where its speed comes from. | AssemblyAI u3.5-pro | 34× [7×–94×] | cloud API round-trip (incl. upload/queue) |
Meetings evaluated (whole-meeting audio, far-field where applicable) — published with references and attribution as Trelis/tiron-eval-meetings, with minimal replication scripts in eval/ of the harness repo:
ES2004a, IS1009a, TS3003a, EN2002aBmr013, Bmr018, Bro021MTG_32040, MTG_32063, MTG_32072, MTG_32074, MTG_32092, MTG_32179, MTG_32185, MTG_32256, MTG_32257, MTG_32322Scoring notes: cpWER is concatenated-permutation WER over whole meetings (transcription and speaker-attribution errors both count). Each corpus figure is pooled — total errors ÷ total reference words across that corpus's meetings — and the macro is the mean of the three corpus figures. On NOTSOFAR-1, stretches the human annotators marked `` (unintelligible) are masked from both hypothesis and reference for every system, so no system is rewarded for staying silent there. AMI and ICSI are unaffected by this mask.
Measurement uncertainty — whole-meeting cpWER on small corpora is a noisy instrument for every system, and all numbers here are single decoding runs. Individual meetings can move by a few points between runs (speaker-count estimation flips, and in single-context decoders one divergent token early in the decode can cascade across the meeting); serving configuration can shift some systems' corpus figures by several points (see the MOSS note above). Corpus figures should be read as ±1 point, and cross-system gaps under ~2 points as ties. Expect small differences when reproducing.
Per 30-second window the model emits speaker blocks with within-window timestamps:
Speaker indices are local to the window (first speaker to talk is ``). The harness links speakers across windows into stable meeting-level identities using ECAPA voice embeddings.
Quoted from the model card on Hugging Face. The full card is behind the Hugging Face link above.