betterflow — English streaming transducer (sherpa-onnx) — MIRROR of a deleted upstream artefact

NON-COMMERCIAL USE ONLY. Read the Licence section before you do anything with these files. betterflow does not license this model and cannot grant you rights to it. These bytes are Banafo's.

Streaming zipformer2 transducer exported to ONNX for on-device dictation. Emits partials DURING speech, so first-partial latency is constant rather than proportional to utterance length — the property batch whisper structurally lacks.

  • encoder.int8.onnx (65.7 MB) + decoder.onnx (0.59 MB) + joiner.onnx (0.32 MB) + tokens.txt (652 lines) — 66.59 MB total
  • Load with sherpa-onnx OnlineRecognizer.from_transducer, model_type="zipformer2"
  • Encoder architecture: num_encoder_layers = 2,2,3,4,3,2, encoder_dims = 192,256,384,512,384,256

Provenance — exactly which files these are

Origin: Banafo / Kroko-ASR. All credit for these weights belongs to Banafo; betterflow trained nothing here.

decoder.onnx, joiner.onnx and tokens.txt are byte-identical to Banafo's own en_decoder.onnx, en_joiner.onnx and en_tokens.txt. encoder.int8.onnx is Banafo's en_encoder.onnx with the encoder's Conv nodes dynamically quantized to int8 (see below); nothing else was changed.

file here sha256 bytes upstream identity
encoder.int8.onnx f077cb14630ca9d6b51b8c777a82d39354defaa97fbee1c692454e3bca0364f8 68,859,294 int8 of en_encoder.onnx (d4881c57449d581e0770fd53fa66c2fdc6cd167d92ece7c715e603defc96d9d4, 70,092,599 B)
decoder.onnx 455ba38466fce8d5a57e7db68a323b684079ca4d9e1dd93a740d9b2429aae3b1 617,488 byte-identical to en_decoder.onnx
joiner.onnx d406f616736350e2a7df3e39398b78eb2fc1a2ca6973a19d3853fa3227e25b52 336,817 byte-identical to en_joiner.onnx
tokens.txt 396dbeb5f4858875690716084f54e90d339679d0ba3e6b5b584f3d7589254d2d 6,310 byte-identical to en_tokens.txt

Those four files were present on Banafo/Kroko-ASR at every revision from abf40825c0e1 (2025-01-29) through 76e3e6657fc6 (2025-09-29), and were deleted from upstream on 2025-10-06, commit d45212aeb212, titled verbatim: Remove old format models.

‼️ This repository is a MIRROR, and that is the whole reason it exists

The upstream files are gone. This repository exists so that betterflow's published measurements remain reproducible — a number is not reproducible if the bytes it was measured on cannot be fetched. It is not a redistribution channel, not a relicensing, and not an endorsement of any particular downstream use.

If you want these weights for your own purposes, go to Banafo, not to us. If Banafo asks us to take this down, we will.

Licence — non-commercial only, quoted from upstream

Banafo has never published a completed licence for these .onnx files. The LICENSE file on Banafo/Kroko-ASR is zero bytes at every revision that carried them, and the HF metadata reads license: other / license_name: test. What upstream did write, verbatim:

From https://huggingface.co/Banafo/Kroko-ASR/raw/4ade2288b485/README.md (commit 4ade2288b485, 2025-09-25) — the only statement upstream has made that distinguishes the two artefact families:

( update september 2025 - CC-BY-SA models were just uploaded, the new ones (with .data extension ) are CC-BY-SA licensed, the .onnx are still non-commercial only. Github and readme updates coming soon. )

And the ## License section, identical at every revision that carried these files (fa401e5ab9b4, 933859c3057c, c683ee760ec7, 4ade2288b485), verbatim:

License

The license is still under consideration (likely Coqui). The model is intended to be dual-licensed:

  • Free for non-commercial use.
  • Affordable license for commercial use.

‼️ These files are not CC-BY-SA. Do not let anyone tell you otherwise.

The CC-BY-SA statement on Banafo's current model card is about the .data models (Kroko-<LANG>-Community-{64,128}-L-Streaming-001.data, ~155.8 MB each). It is not about these .onnx files. betterflow's own records asserted CC-BY-SA for these bytes for two days and were wrong; the correction is recorded in ml/data/runs/2026-08-06-kroko-licence.md in the betterflow repo. The licence above — "still under consideration", "non-commercial only" — is the accurate one.

For commercial use, contact Banafo. We cannot sell, sublicense, or grant what we do not hold.

‼️ tokens.txt has 652 lines. That is CORRECT for this encoder.

There are 650-line English token files in circulation (two variants, 6,218 B and 6,296 B). They belong to a different model — the .data Community model, whose encoder is num_encoder_layers = 2,2,4,5,4,2 / encoder_dims = 192,256,512,768,512,256 against this one's 2,2,3,4,3,2 / 192,256,384,512,384,256. Never pair a 650-line file with this encoder. The 652-line file here is Banafo's own en_tokens.txt, hash 396dbeb5…, and it is the only correct pairing.

The trap runs both ways: a copy of this 652-line file also sits inside the .data model's directory tree, where it is equally wrong. Match tokens to the encoder by architecture, not by directory.

A mismatched token file does not raise: it decodes confident, fluent-looking nonsense.

tokens.txt carries no sentence punctuation. Punctuation is a downstream text-cleanup responsibility, not a model one.

‼️ Only the ENCODER is int8-quantized. That is deliberate.

decoder.onnx and joiner.onnx are shipped as Banafo published them, in fp32. Quantizing them as well produces degenerate repetitive output: they are sub-megabyte networks with almost no weights to quantize, and they sit inside the autoregressive loop where error compounds token over token. This matches the sherpa-onnx zoo convention.

‼️ If the fp32 encoder fails on macOS, that is your ONNX Runtime, not this model

Save yourself the two days we spent. macOS arm64 ONNX Runtime 1.27.0 miscomputes fp32 Conv in a streaming zipformer2 encoder. The sherpa_onnx 1.13.4 macOS pip wheel vendors its own libonnxruntime.1.27.0.dylib, so you hit this even if you have a newer onnxruntime installed — sherpa never loads yours.

The failure does not raise. It returns a short, plausible, non-empty string ('Oh,' for eleven seconds of clean English) and it is not deterministic: six runs at dither=0.0, num_threads=1, identical bytes, gave three different transcripts. That is what reading uninitialized memory looks like.

Two independent fixes, each sufficient:

  1. Use ONNX Runtime 1.28.0 — it executes the unmodified fp32 graph correctly.
  2. Quantize the Conv nodes — which is what encoder.int8.onnx here already does. Converting a single node, /conv/conv.0/Conv (the first Conv2d of the subsampling front-end), is enough to restore the complete correct transcript.

encoder.int8.onnx in this repository carries ZERO fp32 Conv nodes (70 ConvInteger), so it is clear of this trap and decodes correctly on macOS arm64 and Android alike. The mechanical check:

python -c "import onnx,sys;from collections import Counter; \
  print(Counter(n.op_type for n in onnx.load(sys.argv[1],load_external_data=False).graph.node)['Conv'])" encoder.int8.onnx
# -> 0

The full diagnosis, including the 2×2 that isolates it to the ORT version, is in ml/data/runs/2026-08-06-macos-harness-diagnosis.md in the betterflow repo.

Measured — with the subject stated

Every number below names the model, the machine, the corpus and n, because a number without its subject is not a measurement.

what value model machine / runtime corpus n
WER, pooled 5.6% this bundle (f077cb14…) Android, Pixel-class device, sherpa-onnx AAR (ORT 1.27.0) librispeech-en 30 utterances
WER, median 0.0% this bundle same librispeech-en 30
Gate 4, language match 99% latin script, coherent this bundle macOS arm64 M4, sherpa_onnx 1.13.4 pip wheel en-kroko/test_wavs/0.wav + jfk.wav 2 clips

Gate-4 decode, verbatim, 2026-08-07:

0.wav   : Ask not what your country can do for you. Ask what you can do for your country
jfk.wav : and saw my fellow Americans ask not what your country can do for you ask what you can do for your country

‼️ 5.6% is a FLOOR, not a promise

librispeech-en is read audiobook English: clean, close-mic, scripted, largely US-accented, no code-switching, no disfluency. It is the easy case for an English ASR model. Treat 5.6% as the best this bundle will ever look.

Unmeasured, and do not extrapolate to any of it: conversational or spontaneous speech; non-US/UK accents, including Indian English; noisy or far-field audio; code-switched English–Indic speech; domain vocabulary; first-partial latency on device; and WER at any n larger than 30.

Verification

Verified before hosting with ml/export/verify_streaming_bundle.py (betterflow repo) on sherpa-onnx 1.13.4 — the version vendored in the betterflow client, so this exercises the engine that actually ships. Gate 4 passed at 99% latin script; the fp32-vs-int8 CER printed alongside it is meaningless here because the fp32 baseline is the macOS Conv defect described above, not a functioning reference.

There is no fp32-vs-int8 quality comparison for this bundle, and there cannot be one on macOS until sherpa ships a wheel built against ORT ≥ 1.28.

Citation / attribution

If you use these weights, attribute Banafo — Kroko-ASR (https://huggingface.co/Banafo/Kroko-ASR). The int8 quantization and this mirror are betterflow's only contribution.

Downloads last month

-

Downloads are not tracked for this model. How to track
Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support