AuroraASR-1M: 950,000-parameter speech recognition, weight sharing and compact deployment

1. An architecture that reuses the same weights

AuroraASR-1M applies each of its 4 Conformer-lite blocks twice and has 949,073 parameters in total. Rather than assigning separate weights to each computation stage, it reuses learned values. It produces results using CTC, which handles alignment between speech and text.

Training used only 960 hours of LibriSpeech audio, with no other speech or text data. Training for 379 epochs took about 10 hours on an RTX Pro 6000. Input is 16kHz single-channel English audio. Output is primarily lowercase, without punctuation or case distinctions.

2. Read error rates alongside evaluation methods

Word error rate measures word insertions, deletions, and substitutions against a reference; lower is better. With 32-bit weights, the model scored 11.43% on LibriSpeech test-clean and 26.50% on test-other. It used greedy decoding, selecting the most likely output at each step, without an external language model.

Femto-ASR, cited in the model card, reported 10.95% and 25.36% on the same two evaluation sets with 2.39 million parameters. However, competing models' figures came from their own cards or papers. The source explicitly notes that differing text normalization prevents strict comparison. These figures should not be read as a ranking remeasured under identical conditions.

This model's error rates were calculated on lowercased text with punctuation removed. The validation set was used to select the model during training, while the test set was used only for final evaluation.

3. Quantization benefits storage

Weight files are 3.81MB at 32-bit, 1.91MB at 16-bit, and 1.06MB at 8-bit. Under the same evaluation method, 16-bit and 8-bit word error rates were about 11.42% and 11.43% on test-clean, and about 26.48% and 26.54% on test-other, respectively. Reported error rates changed little at lower precision.

The 8-bit approach stores weights as small integers and restores them for computation. It reduces download size and memory use and works on CPUs and GPUs without a special runtime, but does not speed up arithmetic itself. It is a choice for reducing storage costs, not a guarantee of faster computation.

4. Speed also depends on preprocessing conditions

The real-time factor is processing time divided by audio duration; 1 means playback time, and lower is faster. Processing 100 test-clean utterances totaling 13.3 minutes at 32-bit with a batch size of 1 yielded 0.0007 on GPU and 0.0023 on CPU. Both values include audio feature extraction and conversion to text.

The GPU was an NVIDIA RTX PRO 6000 Blackwell Server Edition, with 20 host CPU threads used for feature extraction. The CPU measurement used a single thread pinned to one core; the specific CPU model was not provided. These figures cannot readily be generalized to speeds on arbitrary devices.

5. Loading requires allowing repository code

The following excerpt from the source example loads the model and feature extractor. It requires trust_remote_code=True because it uses custom code from the repository.

import soundfile as sf
from transformers import AutoModelForCTC, AutoFeatureExtractor

repo = "AuroraAI-Research/AuroraASR-1M"
model = AutoModelForCTC.from_pretrained(repo, trust_remote_code=True).eval() # FP32
# model = AutoModelForCTC.from_pretrained(repo, subfolder="int8", trust_remote_code=True).eval() # INT8
# model = AutoModelForCTC.from_pretrained(repo, subfolder="fp16", trust_remote_code=True).half().cuda().eval() # FP16
fe = AutoFeatureExtractor.from_pretrained(repo, trust_remote_code=True)

The source reads an audio file into a floating-point array and outputs the result with model.transcribe(wav).__getitem__(0). The code above includes only the loading step; actual transcription requires an audio array in the input format described earlier.

AuroraASR-1M is worth considering when a small deployment size is the priority, and adoption decisions should account for both reported error rates and actual execution conditions.