FunASR Documentation
中文文档 | English documentation | Model Zoo | Releases
Start Here
| Your task | Guide |
|---|---|
| Install and check the Python environment | Installation / 中文 |
| Choose a model, language, or timestamp capability | Model selection / 中文 |
| Run the first transcription | Quickstart / 中文 / CLI |
| Configure AutoModel, generate, and streaming cache | Python SDK / 中文 |
| Move from Whisper or a cloud API | Migration / 中文 |
Train and Extend
| Your task | Guide |
|---|---|
| Select a recipe, prepare data, train and evaluate | Fine-tuning / 中文 |
| Add a custom architecture to AutoModel | Model registration / 中文 |
| Locate supported checkpoints and individual licenses | Model Zoo / 中文 |
Models and Deployment
| Your task | Guide |
|---|---|
| Compare CPU, GPU, realtime and API runtimes | Deployment matrix / 中文 |
| Handle streaming speech boundaries and finalization | Streaming VAD / 中文 |
| Detect keywords and manage utterance-end KWS results | Keyword spotting / 中文 |
| Distinguish speaker vectors, anonymous labels and emotion tags | Speakers and emotion tags / 中文 |
| Transcribe and diarize with third-party MOSS | MOSS / 中文 |
| Accelerate with the FunASR vLLM split engine | vLLM / 中文 |
| Evaluate native vLLM serving | Validation record |
| Deploy llama.cpp, TensorRT, Docker or Kubernetes | Deployment manuals |
| Choose a service entry point and runtime SDK | Runtime guide / 中文 |
| Select a development or serving container | Docker / 中文 |
| Expose a Python HTTP transcription service | Server / 中文 |
Integrate Against a Contract
Python SDK, Python HTTP, native vLLM HTTP and C++ WebSocket are different interfaces. Choose the matching protocol before selecting a client.
- Agent integration / 中文: HTTP, MCP, desktop recording and local subtitles
- HTTP schema, JavaScript, workflow integration
- C++ WebSocket protocol and ONNX binary output
- HTTP security and Kubernetes manifests
Evaluate and Operate
- Performance methodology and realtime WebSocket benchmarks
- Troubleshooting / 中文
- Use cases, community integrations, and repository responsibilities
The product-site documentation is rendered from these Markdown sources. Edit the source once; the site build updates article content, navigation and local search. The catalogue lives in documentation.json. The established GitHub Pages tutorial, training and model-registration URLs are generated from the same guides. The API reference is separately extracted from Python source. Historical C++ release notes remain in the runtime archive; they are not current deployment recommendations. Model weights retain their individual licenses; the FunASR toolkit is MIT licensed.
Build the Product Documentation
From the repository root:
python -m pip install -r web-pages/product-site/requirements-site.txt
python web-pages/product-site/build.py --output /tmp/funasr-docs
python web-pages/product-site/validate.py /tmp/funasr-docs
python scripts/gen_api_docs.py
python web-pages/product-site/export_docs.py --site /tmp/funasr-docs --output gh-pages-output
python -m http.server --directory /tmp/funasr-docs 8000
Build the Sphinx Reference
The legacy Sphinx reference is a separate local build. Use an isolated environment
with the dependency versions in the legacy-docs-links job of
product-site.yml; installing only the
FunASR package does not reproduce that builder. From the repository root:
python -m pytest tests/test_sphinx_links.py tests/test_reference_docs_contract.py -q
python -m sphinx -b html -n -E -d /tmp/funasr-sphinx-doctrees docs /tmp/funasr-sphinx-html
Open /tmp/funasr-sphinx-html/index.html after the build. Markdown heading
fragments remain usable alongside existing Sphinx anchors, including numbered
and Chinese headings. Missing destinations still produce warnings; inspect the
build log rather than treating an exit code alone as proof of correct links.
The GitHub Pages publishing workflow uses the product documentation exporter
and generated API reference, not this standalone Sphinx output.