per-minute speech-to-text APIs vs Fun-ASR: the 1,606 star alternative worth checking

Fun-ASR is an Apache-2.0 speech recognition model from the QwenAudio organisation, with 1,606 GitHub stars and a commit four days before verification. It offers a local alternative to per-minute transcription APIs, and its dialect coverage is the part Western tooling rarely matches. Worth a serious evaluation if you process Mandarin-adjacent audio at volume; not a drop-in replacement for every pipeline.

Why it matters

The economics of transcription APIs are simple and, for anyone running a lot of audio, uncomfortable. Deepgram, AssemblyAI and the hosted Whisper endpoint all bill by the minute. That model is fine when you are transcribing a few support calls a week. It becomes a line item you have to defend when you are processing thousands of hours of call-centre recordings, podcast archives or meeting captures, and it becomes a hard blocker when the audio cannot legally leave your infrastructure.

Local inference changes the shape of that cost. You pay for the machine once, and the marginal cost of the next hour of audio is the electricity and the wall-clock time. There is no per-minute meter, no monthly quota, no invoice that scales linearly with your success. The trade-off is operational: you own the GPU, the model weights, the upgrades and the failure modes. For teams already running inference infrastructure, that trade is usually worth making. For teams that are not, it is a new discipline to learn.

Fun-ASR is interesting less because it is another open speech model and more because of where it is strong. The editorial case for it rests on three things: local execution with no per-minute billing, dialect and accent coverage that Western APIs generally handle poorly, and four documented deployment paths so you are not locked into one serving stack. The first and third are common to most open ASR models. The second is the actual differentiator, and it is the reason a team outside the Chinese-speaking market should still read this.

The "because Z"

1. Local inference drives the marginal cost per audio hour to zero, against per-minute billing on hosted APIs. This is the core argument and it does not depend on any benchmark. With Deepgram, AssemblyAI or the Whisper API, every additional hour of audio produces an additional charge, and that charge is predictable and linear. With Fun-ASR running on your own hardware, the 1,606 stars and the Apache-2.0 licence are the only numbers the repository gives us about adoption and terms; the cost curve is a property of local inference in general, not a published figure from this project. The practical consequence is that your cost becomes a step function: you buy capacity in GPU-sized increments, and within that capacity the thousandth hour costs the same as the first. Whether that beats an API depends entirely on your volume and your existing hardware. Below a few dozen hours a month, it usually does not.

2. Fun-ASR-Nano covers 7 Chinese dialects and 26 regional accents, a surface where Western APIs are typically weaker. The dialects named in the brief are Wu, Cantonese, Min, Hakka, Gan, Xiang and Jin, alongside 26 regional accents. Treat these as claims from the project's own documentation rather than independently verified coverage: no accuracy figures were supplied for this article, and I am not going to invent any. What can be said without a benchmark is that dialect and accent robustness is a known weak point for models trained predominantly on standard Mandarin and English, and that a model explicitly scoped to this surface is addressing a real gap. If your audio includes Cantonese speakers, Hakka speakers or heavily accented Mandarin, this is the feature that justifies the evaluation, and you should measure it on your own data before committing.

3. Four deployment paths are provided: Hugging Face Transformers, vLLM, llama.cpp in GGUF format, and embedded use. This matters because it decouples the model from a serving stack. Transformers is the reference path and the easiest way to get a first transcription out. vLLM is the throughput path for batched server-side work. The GGUF path via llama.cpp is the one that makes local and edge deployment realistic on hardware without a data-centre GPU, and the embedded option covers the case where the model ships inside another product. The practical benefit is that you are not dependent on a third-party service for inference, and you are not dependent on a single runtime either. If vLLM's release cadence moves in a direction you dislike, the Transformers path still works. That optionality is worth more than it sounds when you are committing to a model for years.

The data

Tool	License	Stars	Last commit
Fun-ASR	Apache-2.0	1606	2026-11-09

Verified via the GitHub API on 2026-11-13.

The table is deliberately short because the verified data block is short. I have no star counts, licence terms or commit dates for Deepgram, AssemblyAI or the Whisper API in this dataset, and comparing them numerically would mean fabricating figures. What the table does establish is that Fun-ASR is permissively licensed, actively maintained as of four days before verification, and not archived. Those three facts are the ones that matter for an adoption decision, and all three are favourable.

The trap to avoid

The licence is not the trap here. Apache-2.0 is permissive, allows commercial use, modification and redistribution, and carries a patent grant. For a model you intend to embed in a product, that is about as clean as open-source licensing gets. The repository is also not dormant: the last commit was 2026-11-09, four days before the verification date, and the project is not archived. No alerts were raised during verification, so there is no hidden licence or activity problem to disclose.

The trap is the one that applies to every local-inference migration, and it is a lock-in trap of a subtler kind. Moving from a per-minute API to a self-hosted model does not just change who sends the invoice; it transfers the entire operational burden to you. You become responsible for GPU provisioning, model upgrades, regression testing when weights change, monitoring for silent quality drift, and the on-call rotation when the inference server falls over at 3am. The API vendor was, whatever else it was, absorbing all of that. Teams routinely underestimate this line item because it does not appear on any invoice.

There is a second, related trap specific to this model. The dialect and accent coverage is the reason to consider Fun-ASR, and it is also the claim you are least able to verify from the outside. The repository's star count tells you people are paying attention; it tells you nothing about word error rate on Hakka. If you switch on the strength of the coverage claim without running your own audio through it, you have replaced a vendor's marketing with a project's marketing and called it diligence. Build an evaluation set from your actual recordings, including the accented and dialect speech you care about, before you commit. The same applies to the four deployment paths: pick the one you can actually operate, not the one that benchmarks best in someone else's blog post.

The verdict

Switch if you process meaningful volume of Chinese-language audio, especially audio that includes the dialects and accents listed above, and if you already run GPU inference infrastructure or are willing to build it. The Apache-2.0 licence, the recent commit activity and the four deployment paths make this a low-risk thing to evaluate, and the local-inference cost model is genuinely better at scale. Do not switch if your volume is small enough that per-minute billing is cheap, if your audio is predominantly English, or if you have no appetite for owning inference operations; in those cases the hosted APIs remain the rational choice, and the dialect coverage buys you nothing you need.

References

1. Fun-ASR — Apache-2.0, 1606 stars, last commit 2026-11-09, primary language C.
2. Fun-ASR official site.
3. modelscope.cn page linked from the Fun-ASR README.
4. huggingface.co page linked from the Fun-ASR README.
5. huggingface.co page linked from the Fun-ASR README.

All figures were read from the GitHub API (api.github.com) on 2026-11-13. They move: re-check before you ship.