Fun-ASR: two 800M checkpoints, a pinned revision, and a release list that goes backwards

Two checkpoints, both 800M, with different language promises

The opening line makes the point that matters for anyone choosing between them: checkpoint capabilities are distinct. Fun-ASR-Nano-2512 is trained on tens of millions of hours of speech and covers Chinese, English and Japanese, with Chinese reaching into seven dialects, Wu, Cantonese, Min, Hakka, Gan, Xiang and Jin, plus 26 regional accents that the table names in part, listing Henan, Shanxi, Hubei, Sichuan, Chongqing, Yunnan, Guizhou, Guangdong and Guangxi among more than twenty others. English and Japanese are said to cover multiple regional accents too, and two extra tasks sit alongside recognition: lyric recognition and rap speech recognition. Fun-ASR-MLT-Nano-2512 is the multilingual one, an 800M checkpoint trained on hundreds of thousands of hours and covering 31 languages, from Korean, Vietnamese, Indonesian, Thai, Malay and Filipino through Arabic and Hindi to most of the European set. Both carry 800M parameters, so size is not the differentiator; coverage is. Both also integrate with FunASR for inference and serving, which is why one of them is published on the hub twice, once for the Transformers path and once for the toolkit path, and why the repository can name a FunASR release as current while its quickstart avoids the toolkit entirely. Both names end in 2512, a date suffix that identifies the release of the family they belong to and says nothing about which one is newer in capability.

The Transformers path pins a revision and refuses remote code

The quickstart says no toolkit installation and no remote Python code are needed, and the code shows both claims being taken seriously:

import torch
from transformers import AutoModelForSpeechSeq2Seq, AutoProcessor

torch.set_num_threads(4)
model_id = "FunAudioLLM/Fun-ASR-Nano-2512-hf"
revision = "d93b302ee7fd505e1b3576120fc142fc6f7820e1"
audio = "https://huggingface.co/FunAudioLLM/Fun-ASR-Nano-2512/resolve/272c57b82523ada6fd87095e955f8e29100979ab/example/en.mp3"

processor = AutoProcessor.from_pretrained(
    model_id, revision=revision, trust_remote_code=False, token=False
)

Four choices are visible in those lines. trust_remote_code is False on both the processor and the model, so the checkpoint cannot execute code from the hub, which is the setting that turns a model download into something you can reason about. token=False means no account is required to fetch it. The revision is a full commit hash rather than a branch, so a later upload to the same repository cannot change what you run. And the sample audio is also pinned to a commit hash in its resolve URL, so the example reproduces. The thread count is set to four, which is a reminder that inference here is local CPU work rather than a hosted call.

Five floors in requirements.txt, five exact pins in the quickstart

Two version strategies live in one repository and they do not agree. The quickstart install is exact:

python -m pip install 'transformers==5.17.0' 'torch==2.10.0' 'torchaudio==2.10.0' 'librosa==0.11.0' 'soundfile==0.13.1'

The requirements file at the root is all floors: torch>=2.9.0, torchaudio>=2.9.0, transformers>=4.51.3, funasr>=1.3.26, followed by zhconv, whisper_normalizer, pyopenjtalk-plus, compute-wer and openai-whisper. The gap matters. The quickstart asks for a Transformers major release well past the floor, so a resolve that satisfies requirements.txt alone will not give you the documented environment, and a resolve that satisfies the quickstart ignores the toolkit stack entirely. The FunASR line has its own drift: the file names FunASR 1.4.15 as the current Python release for source installs while requirements asks for 1.3.26 or newer. And the presence of two text normalisation packages plus compute-wer alongside openai-whisper tells you scoring and normalisation are part of the workflow, without the file saying which one is used where.

The release list goes 0.2.1, then 0.1.10

The three most recent releases are all named for the same runtime rather than for the models: runtime-llamacpp-v0.1.9 on 2026-07-24, runtime-llamacpp-v0.2.1 on 2026-08-27, and runtime-llamacpp-v0.1.10 on 2026-09-05. Read in publishing order that is 0.1.9, then 0.2.1, then 0.1.10, so the highest patch of the older minor line was published after the newer minor line, which is either two branches being maintained or a version scheme that drifted. Either way the tags cannot be sorted by semver and assumed to be chronological. The news section points readers at a fourth identifier, a runtime v0.2.6, which is not among the three releases listed here. The last commit on the default branch is dated 2026-09-10, five days after the newest tag.

The 93 percent figure arrives without test conditions

One number in the core features list stands out. Far-field high-noise recognition is described as deeply optimised for distant sound pickup and noisy environments, with the examples being conference rooms, in-vehicle situations and industrial sites, and the claim is that recognition accuracy improves to 93%. No dataset, no word error rate, no noise level and no baseline are attached to it anywhere in the visible text, so it is a claim about a scenario rather than a measurement you can compare against anything. The rest of the section is more careful: the dialect list is enumerated as seven named varieties, and the accent line is cut off mid-word after the word inc, so the count of 26 comes from the opening paragraph rather than from a visible list. For a project whose selling point is dialect coverage, that is the number to go and check yourself.

Four serving paths and one third-party diarizer

The deployment story is split between this repository and others, and the file is clear about which is which. Production deployment here covers realtime WebSocket serving, native vLLM batch and streaming paths, and verified llama.cpp packages in GGUF form for Linux, macOS and Windows, and those are the releases tagged above. The diarization model is somebody else's: MOSS-Transcribe-Diarize is a third-party OpenMOSS model for offline long-form transcription with timestamps and anonymous speaker labels, and its deployment paths are listed as FunASR service, Docker, Kubernetes, vLLM, SGLang, LocalAI and FunClip. So a long-audio workflow with speaker labels is a different model behind a different stack, and the word anonymous in its description is doing real work, since the labels are placeholders rather than identified speakers. The repository's own examples carry the local side: quickstart inference, direct inference, speaker diarization, a vLLM batch example and a streaming SDK.

Training scaffolding sits next to the serving code

The top-level listing mixes two projects. On the inference side there are examples/, docs/, tools/, tests/, client_python.py, client_test.py, client_mic.html for a browser client, serve_realtime_ws.py for the realtime server, and a runtime/ directory that matches the llama.cpp release tags. On the training side there is ctc.py, decode.py, a deepspeed_conf/ directory and finetune.sh, none of which any visible document explains, plus a data/ directory. That mixture is also why GitHub records the primary language for this repository as C while everything visible in the file is Python, which points at the compiled runtime rather than at the model code. Nothing in the tree suggests which of these pieces the two checkpoints were trained with beyond the existence of a DeepSpeed configuration and a CTC loss module, so the training recipe is not documented here. Two of those files are named for what they do rather than for a module, demo1.py, demo2.py and demo_vllm.py, which is a naming style that does not survive contact with a repository of any size and gives a reader no way to guess which demo to run first.

Four readmes, two model hosts, one space

The file is published in four languages, with links at the top to a Chinese, a Japanese and a Korean version beside the English one, and all four are in the tree. Models are hosted in two places: ModelScope and Hugging Face, and the Nano checkpoint exists on Hugging Face twice, once as Fun-ASR-Nano-2512-hf for the Transformers path and once as Fun-ASR-Nano-2512 for the FunASR path, while the multilingual checkpoint has a single Hugging Face repository. Two online demo spaces are linked, one on each host. The repository's configured homepage is a Hugging Face space for Fun-ASR-Nano, while the page's own navigation links to funasr.com as the project homepage, so following the two leads takes you to a demo rather than to documentation.

Editorial conclusion

Fun-ASR is worth evaluating if your audio is Chinese, Japanese or English with dialect and accent variation, because that is where its stated coverage is specific and its example set is dense. Three things to check before you commit. The two checkpoint names both end in 2512 and both claim 800M parameters, so the only way to tell them apart is the language list, and the multilingual one is a separate download with a separate Transformers recipe. The version strategy is inconsistent: the quickstart pins five exact versions including a major Transformers release, while requirements.txt asks only for floors that are several majors behind, so the two documented setups are not the same environment. And the release list cannot be read in order, since 0.1.10 was published nine days after 0.2.1 while the file points readers at a 0.2.6 runtime that is not among the visible tags. Apache 2.0, last push 2026-09-10.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. QwenAudio/Fun-ASR on GitHub
4. README
5. Releases