fix(audio): bump funasr pin for Fun-ASR-Nano models to ~=1.3

[m199369309]

Problem

Deploying Fun-ASR-Nano-2512 on a 4090 worker node fails after downloading:

AssertionError: FunASRNano is not registered

Root Cause

The model_spec.json virtualenv packages for both Fun-ASR-Nano models pinned funasr 1.2.7 (commit b25472b0, 2025-08-15), which predates the model release and does not support the FunASRNano model class.

Version Timeline

2025-08   funasr 1.2.7 released (previously pinned version)
2025-12   Fun-ASR-Nano-2512 model released (config.yaml: model: FunASRNano)
2026-01   funasr 1.3.0 released (first version with FunASRNano class)
2026-06   funasr 1.3.14 released (current latest)

Fix

Replace the git pin with funasr~=1.3 (equivalent to >=1.3.0, <2.0.0 per PEP 440):

- "funasr @ git+https://github.com/modelscope/FunASR@b25472b0b562d04f411da30ff9cc59786f68b0f2"
+ "funasr~=1.3"

Why ~=1.3:

• First deployment auto-pulls the latest 1.3.x (currently 1.3.14)
• Subsequent venv rebuilds auto-get 1.3.15+ bug fixes
• Will NOT auto-upgrade when funasr 2.0 is released (the ~= operator with a two-segment version is equivalent to >=1.3.0, <2.0.0)
• Allows minor-version bumps within 1.x (e.g., 1.4.x, 1.5.x) which are backward-compatible

Impact

Item	Description
Files changed	1 (model_spec.json)
Models affected	2 (Fun-ASR-Nano-2512, Fun-ASR-MLT-Nano-2512)
Older models	None (paraformer/SenseVoice have no virtualenv, use parent env)
Rollback	Revert the commit

Post-Deploy Verification

Clean old virtual environments after deploying:

rm -rf /data/models/virtualenv/v4/Fun-ASR-Nano-2512/
rm -rf /data/models/virtualenv/v4/Fun-ASR-MLT-Nano-2512/

Re-deploy the model and confirm the log shows funasr version: 1.3.14.

[gemini-code-assist]

Code Review

This pull request updates the funasr dependency in xinference/model/audio/model_spec.json from a specific git commit to a version constraint of funasr~=1.3.0. The feedback suggests clarifying the versioning intent: if the goal is to allow any compatible 1.x release, the constraint should be adjusted to funasr~=1.3 instead of locking it to the 1.3.x branch.

[LauraGPT]

FunASR-side note: the direction of this PR looks right for the Fun-ASR-Nano registration failure. Moving off the old pinned Git commit lets Xinference pick up the packaged FunASR 1.3.x registry entries for the Nano model specs.

One small consistency check before merge: the current PR head 8a042df1 still changes both entries to "funasr~=1.3.0", even though the replies above say it was corrected to "funasr~=1.3". Either range can be defensible, but the code and explanation should match:

• funasr~=1.3.0 means >=1.3.0,<1.4.0 and keeps Xinference on the 1.3.x line.
• funasr~=1.3 means >=1.3,<2.0 and allows later compatible 1.x releases.

For the immediate Nano registration unblock, staying on ~=1.3.0 is fine if that narrower range is intentional; otherwise the latest commit still needs the two package strings changed to ~=1.3.

[LauraGPT]

CI follow-up from the FunASR side: I inspected the only failing check on the current head (build_test_job (macos-latest, metal, 3.10), run 28807981588, job 85428684059).

This does not look caused by the FunASR dependency change in this PR. The diff only updates the two FunASR virtualenv.packages entries in xinference/model/audio/model_spec.json, while the failing tests are MLX LLM tests:

FAILED xinference/model/llm/mlx/tests/test_mlx.py::test_load_mlx
FAILED xinference/model/llm/mlx/tests/test_mlx.py::test_load_mlx_vision
FAILED xinference/model/llm/mlx/tests/test_mlx.py::test_mlx_parallel_inference

The traceback is from importing mlx_lm, where mlx_lm/tokenizer_utils.py calls:

AutoTokenizer.register("NewlineTokenizer", fast_tokenizer_class=NewlineTokenizer)

and the installed Transformers path then tries to read key.__module__, producing:

AttributeError: 'str' object has no attribute '__module__'

So I would treat the red macOS Metal check as an unrelated MLX/Transformers compatibility failure (or rerun it), not as evidence against the FunASR pin direction. The only FunASR-side nit I still see is the package spec currently being funasr~=1.3.0; if the intended range is the title's ~=1.3, the patch still needs that small edit.

[LauraGPT]

Thanks for getting this merged. I synced the FunASR-side deployment docs so users who already run Xinference can discover this route from the FunASR repo as well:

• docs: add Xinference deployment route modelscope/FunASR#3117
• docs mention using a Xinference build that includes this PR, so older releases do not get mistaken for the fixed model spec.