尧图网站建设 
FunASR Docker 部署实战运行镜像选型、源构建与 CPU 实时识别服务的容器化方案【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR本篇技术文章基于 FunASR 仓库的 Docker 部署文档 展开系统讲解在容器环境中使用 FunASR 的三条核心路径——离线/在线 C 运行时服务、基于源码重建的 online CPU 运行时、以及 Python SDK 开发环境。读完本文你将掌握如何按场景选择正确的镜像、如何用docker image inspect在暴露服务之前安全核查镜像、如何从当前源码树构建funasr-wss-server-2pass服务镜像以及 online-cpu-entrypoint.sh 暴露的全部环境变量覆盖机制。1. 先选执行路径再拉镜像仓库文档开篇就给出了一个关键判断PythonAutoModelSDK、C 运行时服务、开发环境是仓库的三种不同产品形态。在已发布的运行时镜像内部安装更新版本的 Python 包既不会重新编译其中的 C 可执行文件也不会让该服务自动支持全部 Python 侧模型。因此拉取任何镜像之前应先明确自己要的是哪一种执行路径。1.1 宿主机 Docker 与 GPU 前提按 Docker Engine 官方指引安装 Linux 版 Docker或为 macOS/Windows 使用 Docker Desktop。文档明确提醒不要把未经审阅的安装脚本直接 pipe 进提权 shell。安装后用以下两条命令验证docker version docker infoGPU 容器还要求宿主机已安装兼容的驱动并完成容器 GPU 环境配置。--gpus all只是“请求访问 GPU”它不会安装驱动也无法让一个 CPU 镜像变成 GPU 镜像。使用前应核对你要拉取的镜像与宿主机的架构是否匹配。2. 五条运行路径与仓库记录的镜像清单以下镜像引用均出自当前 checkout 的仓库文档属于仓库层面的证据文档同时声明这并不代表注册表可用性、安全更新或推理效果在本次文档评审中经过实测验证。路径仓库记录的镜像或构建方式后续指引离线 C CPU 服务registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-cpu-0.4.7离线 CPU 服务指南离线 C GPU 服务registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-gpu-0.2.1离线 GPU 服务指南在线/2pass C CPU 服务registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-online-cpu-0.1.13在线服务指南从当前 checkout 重建 online CPU 运行时Dockerfile.online.cpu基于 digest 固定的基础镜像同上会重新编译 C 服务并安装当前源码树Python SDK 开发自行选定并验证过的 Python/PyTorch 环境源码安装指南需记录基础镜像 digest 与包版本2.1 历史镜像仅作为参考不是推荐配置当前维护的源码构建路径与旧版页面曾宣传的开发镜像是两回事。仓库保留了如下历史记录历史开发镜像registry.cn-hangzhou.aliyuncs.com/modelscope-repo/modelscope:ubuntu20.04-py38-torch1.11.0-tf1.15.5-1.8.1。它在此页仅作为历史参考保留不是当前推荐的 FunASR 运行镜像也不保证与新模型依赖兼容。旧 CPU 标签funasr-runtime-sdk-cpu-0.4.1同样属于历史版本镜像演进详见 运行时发布历史。在线 CPU 镜像的版本演进在 在线服务指南 中以表格形式逐版记录如 0.1.12 支持 SensevoiceSmall 的 2pass-offline 模式、0.1.11 修复内存泄漏、0.1.9 起支持 ARM64 等选镜像时可按需回溯。3. 不暴露服务地核查一个已发布镜像原文档给出的标准做法是先拉镜像、核查架构与 digest然后以“仅开 shell”的方式进入容器做离线检查而不是直接启动服务。以离线 CPU 运行时为例在希望放置模型目录的目录下依次执行POSIX shellIMAGEregistry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-cpu-0.4.7 docker pull $IMAGE docker image inspect $IMAGE --format {{.Os}}/{{.Architecture}} {{json .RepoDigests}} mkdir -p ./funasr-models docker run --rm -it --name funasr-runtime-shell \ --mount typebind,src$(pwd)/funasr-models,dst/workspace/models \ --entrypoint /bin/bash $IMAGE几个要点值得注意docker image inspect这一行同时打印了Os/Architecture与RepoDigests对应文档反复强调的“记录精确镜像 digest”要求--entrypoint /bin/bash把容器降级为纯 shell——这启动的是一个调试环境不是配置好的转写服务模型目录通过 bind mount 挂到/workspace/modelsexit后临时容器随--rm删除而挂载的模型文件在宿主机上保留若需从另一终端检查或停止该容器docker ps --filter namefunasr-runtime-shell docker stop funasr-runtime-shell进入服务验证阶段前文档给出了明确的安全边界测试服务应绑定回环地址例如-p 127.0.0.1:10095:10095在访问控制与传输安全配置完成之前不要暴露公网端口避免--privileged、宿主机 root 挂载、把凭据烧进镜像、以及未经审查的公网端口暴露部分历史指南命令使用了较宽的权限例如 runtime/quick_start.md 中的示例使用了--privilegedtrue应评估自身需求而不是照抄。4. 从源码构建 online CPU 运行时镜像这是当前 checkout 中完整维护的容器化构建路径对应文件 runtime/dockerfile/Dockerfile.online.cpu。在仓库根目录、审阅 Dockerfile 与构建上下文后执行docker build -f runtime/dockerfile/Dockerfile.online.cpu \ -t funasr-online-cpu:local .需要强调funasr-online-cpu:local只是本地自选的构建标签不是已发布的注册表版本。且构建完成本身不等于模型推理测试——后续启动与验证应遵循 在线运行时指南并不要假设本地镜像包含了提交后的新代码除非重新构建。4.1 Dockerfile 逐段解析结合 Dockerfile.online.cpu 的实际内容构建过程可以拆成四步digest 固定的多架构基础镜像。基础镜像是公开版funasr-runtime-sdk-online-cpu-0.1.13但通过 manifest digest 固定sha256:2a54c20f...保证构建可复现。注释# syntaxdocker/dockerfile:1.7表明使用了 BuildKit 语法。按架构选择依赖目录。利用ARG TARGETARCHamd64 使用onnxruntime-linux-x64-1.14.0与ffmpeg-master-latest-linux64-gpl-sharedarm64 使用onnxruntime-linux-aarch64-1.17.1与ffmpeg-master-latest-linuxarm64-gpl-shared其他架构直接报错退出。这也解释了为什么 0.1.9 起该镜像系列支持 ARM64。安装源码树并编译 C 服务。先pip install --no-cache-dir -e ./editable 模式安装当前 checkout再执行cmake -S runtime/websocket -B runtime/websocket/build \ -DCMAKE_BUILD_TYPERelease \ -DENABLE_PORTAUDIOOFF \ -DONNXRUNTIME_DIR${onnxruntime_dir} \ -DFFMPEG_DIR${ffmpeg_dir} cmake --build runtime/websocket/build --parallel $(nproc)产物即runtime/websocket/build/bin/funasr-wss-server-2pass。设置入口与端口。COPY runtime/dockerfile/online-cpu-entrypoint.sh /usr/local/bin/online-cpu-entrypoint.sh并置0755随后EXPOSE 10095、VOLUME [/workspace/models]ENTRYPOINT指向该脚本。这些约束并非文档口头声明而是有自动化测试把关的tests/test_online_cpu_dockerfile.py 断言了 digest 固定、COPY . /workspace/FunASR、editable 安装、cmake 编译参数、入口脚本与端口等关键标记.github/workflows/test-online-cpu-docker.yml 则用docker/build-push-actionv6在linux/amd64平台完整构建该镜像并直接执行funasr-wss-server-2pass --help做冒烟验证。4.2 入口脚本与环境变量覆盖online-cpu-entrypoint.sh 是本地构建镜像与预构建镜像的关键差异点——它会直接拉起服务而不经过预构建镜像的交互式守护包装。脚本逻辑set -euo pipefail容器可替换入口若第一个参数不以-开头直接exec $方便把容器当普通命令环境使用模型与热词目录FUNASR_DOWNLOAD_MODEL_DIR默认/workspace/models确定模型根目录FUNASR_HOTWORD_FILE默认${model_root}/hotwords.txt指定服务端热词文件脚本会mkdir -p并touch热词文件保证存在线程数自动推导解码线程FUNASR_DECODER_THREAD_NUM默认$(nproc)IO 线程FUNASR_IO_THREAD_NUM默认为(decoder_threads 15) / 16模型 ID 覆盖FUNASR_MODEL_DIR默认 Paraformer-large 带 VAD/PUNC 的离线模型、FUNASR_ONLINE_MODEL_DIR流式模型、FUNASR_VAD_DIRFSMN VAD、FUNASR_PUNC_DIR、FUNASR_ITN_DIR、FUNASR_LM_DIRngram FST 语言模型分别对应 2pass 服务的各阶段模型端口与其他参数FUNASR_PORT默认10095、FUNASR_MODEL_THREAD_NUM默认 1--certfile /--keyfile 表示默认不启用 SSL末尾$透传额外命令行参数等价于 SDK_advanced_guide_online.md 中run_server_2pass.sh的手动参数方式。因此启动本地构建镜像的最小命令可以写成docker run --rm -p 10096:10095 \ -v $PWD/funasr-runtime-resources/models:/workspace/models \ funasr-online-cpu:local若要指定模型或端口例如改用带时间戳输出的离线模型并监听 9000 端口则通过环境变量覆盖docker run --rm -p 9000:9000 \ -v $PWD/funasr-runtime-resources/models:/workspace/models \ -e FUNASR_PORT9000 \ -e FUNASR_MODEL_DIRdamo/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx \ funasr-online-cpu:local4.3 与预构建镜像启动方式的对照SDK_advanced_guide_online.md 记录了官方推荐的两种启动方式拉取 0.1.13 镜像后进入容器手动执行bash run_server_2pass.sh --download-model-dir /workspace/models ...显式列出各模型目录参数或从源码构建后由入口脚本自动完成同等配置。二者的模型参数完全对应区别在于参数是“命令行显式给出”还是“环境变量默认值 覆盖”。5. Python SDK 开发路径不发明通用开发镜像文档对 SDK 开发路径的立场非常克制不虚构一个“通用开发镜像标签”或模型兼容矩阵。正确做法是自行选择一个经过审查与验证的 Python/PyTorch 容器基础镜像与包版本自行记录按 安装指南 将当前 checkout 安装进去跑通 SDK 教程 作为冒烟验证。同时文档重申容器内的边界条件同样适用模型缓存策略、离线准备流程、trust_remote_code的信任决策安装指南建议默认trust_remote_codeFalse除非所选模型确实需要且你已审查过其代码、以及软件与模型相互独立的许可证FunASR 软件为 MIT模型权重各有独立条款参见 LICENSE 与 MODEL_LICENSE。6. 复现性清单把 digest、commit 与模型版本一起存档原文档的最后一段是整个部署流程的收尾要求也是工程上最值得照做的一条将精确的镜像 digest、源码 commit 与模型版本与你的测试结果一起保存。结合本文的源码证据这份清单具体应包含镜像 digestdocker image inspect $IMAGE --format {{json .RepoDigests}}的输出对应 Dockerfile.online.cpu 中BASE_IMAGE的固定方式源码 commit本地构建镜像时 checkout 的 git 提交号——因为 editable 安装 C 编译意味着镜像内容完全取决于构建时的源码树模型修订各阶段模型ASR/online ASR/VAD/PUNC/ITN/LM在模型库中的 ID 与快照版本测试结果如 test-online-cpu-docker.yml 中对funasr-wss-server-2pass --help的冒烟检查是你本地验证流程的最小参照。更多运行时入口可继续查阅 运行时总览 与 快速上手本文的中文姊妹篇见 docker_zh.md。【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 FunASR Docker 部署实战：运行镜像选型、源构建与 CPU 实时识别服务的容器化方案
FunASR Docker 部署实战运行镜像选型、源构建与 CPU 实时识别服务的容器化方案【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR本篇技术文章基于 FunASR 仓库的 Docker 部署文档 展开系统讲解在容器环境中使用 FunASR 的三条核心路径——离线/在线 C 运行时服务、基于源码重建的 online CPU 运行时、以及 Python SDK 开发环境。读完本文你将掌握如何按场景选择正确的镜像、如何用docker image inspect在暴露服务之前安全核查镜像、如何从当前源码树构建funasr-wss-server-2pass服务镜像以及 online-cpu-entrypoint.sh 暴露的全部环境变量覆盖机制。1. 先选执行路径再拉镜像仓库文档开篇就给出了一个关键判断PythonAutoModelSDK、C 运行时服务、开发环境是仓库的三种不同产品形态。在已发布的运行时镜像内部安装更新版本的 Python 包既不会重新编译其中的 C 可执行文件也不会让该服务自动支持全部 Python 侧模型。因此拉取任何镜像之前应先明确自己要的是哪一种执行路径。1.1 宿主机 Docker 与 GPU 前提按 Docker Engine 官方指引安装 Linux 版 Docker或为 macOS/Windows 使用 Docker Desktop。文档明确提醒不要把未经审阅的安装脚本直接 pipe 进提权 shell。安装后用以下两条命令验证docker version docker infoGPU 容器还要求宿主机已安装兼容的驱动并完成容器 GPU 环境配置。--gpus all只是“请求访问 GPU”它不会安装驱动也无法让一个 CPU 镜像变成 GPU 镜像。使用前应核对你要拉取的镜像与宿主机的架构是否匹配。2. 五条运行路径与仓库记录的镜像清单以下镜像引用均出自当前 checkout 的仓库文档属于仓库层面的证据文档同时声明这并不代表注册表可用性、安全更新或推理效果在本次文档评审中经过实测验证。路径仓库记录的镜像或构建方式后续指引离线 C CPU 服务registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-cpu-0.4.7离线 CPU 服务指南离线 C GPU 服务registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-gpu-0.2.1离线 GPU 服务指南在线/2pass C CPU 服务registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-online-cpu-0.1.13在线服务指南从当前 checkout 重建 online CPU 运行时Dockerfile.online.cpu基于 digest 固定的基础镜像同上会重新编译 C 服务并安装当前源码树Python SDK 开发自行选定并验证过的 Python/PyTorch 环境源码安装指南需记录基础镜像 digest 与包版本2.1 历史镜像仅作为参考不是推荐配置当前维护的源码构建路径与旧版页面曾宣传的开发镜像是两回事。仓库保留了如下历史记录历史开发镜像registry.cn-hangzhou.aliyuncs.com/modelscope-repo/modelscope:ubuntu20.04-py38-torch1.11.0-tf1.15.5-1.8.1。它在此页仅作为历史参考保留不是当前推荐的 FunASR 运行镜像也不保证与新模型依赖兼容。旧 CPU 标签funasr-runtime-sdk-cpu-0.4.1同样属于历史版本镜像演进详见 运行时发布历史。在线 CPU 镜像的版本演进在 在线服务指南 中以表格形式逐版记录如 0.1.12 支持 SensevoiceSmall 的 2pass-offline 模式、0.1.11 修复内存泄漏、0.1.9 起支持 ARM64 等选镜像时可按需回溯。3. 不暴露服务地核查一个已发布镜像原文档给出的标准做法是先拉镜像、核查架构与 digest然后以“仅开 shell”的方式进入容器做离线检查而不是直接启动服务。以离线 CPU 运行时为例在希望放置模型目录的目录下依次执行POSIX shellIMAGEregistry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-cpu-0.4.7 docker pull $IMAGE docker image inspect $IMAGE --format {{.Os}}/{{.Architecture}} {{json .RepoDigests}} mkdir -p ./funasr-models docker run --rm -it --name funasr-runtime-shell \ --mount typebind,src$(pwd)/funasr-models,dst/workspace/models \ --entrypoint /bin/bash $IMAGE几个要点值得注意docker image inspect这一行同时打印了Os/Architecture与RepoDigests对应文档反复强调的“记录精确镜像 digest”要求--entrypoint /bin/bash把容器降级为纯 shell——这启动的是一个调试环境不是配置好的转写服务模型目录通过 bind mount 挂到/workspace/modelsexit后临时容器随--rm删除而挂载的模型文件在宿主机上保留若需从另一终端检查或停止该容器docker ps --filter namefunasr-runtime-shell docker stop funasr-runtime-shell进入服务验证阶段前文档给出了明确的安全边界测试服务应绑定回环地址例如-p 127.0.0.1:10095:10095在访问控制与传输安全配置完成之前不要暴露公网端口避免--privileged、宿主机 root 挂载、把凭据烧进镜像、以及未经审查的公网端口暴露部分历史指南命令使用了较宽的权限例如 runtime/quick_start.md 中的示例使用了--privilegedtrue应评估自身需求而不是照抄。4. 从源码构建 online CPU 运行时镜像这是当前 checkout 中完整维护的容器化构建路径对应文件 runtime/dockerfile/Dockerfile.online.cpu。在仓库根目录、审阅 Dockerfile 与构建上下文后执行docker build -f runtime/dockerfile/Dockerfile.online.cpu \ -t funasr-online-cpu:local .需要强调funasr-online-cpu:local只是本地自选的构建标签不是已发布的注册表版本。且构建完成本身不等于模型推理测试——后续启动与验证应遵循 在线运行时指南并不要假设本地镜像包含了提交后的新代码除非重新构建。4.1 Dockerfile 逐段解析结合 Dockerfile.online.cpu 的实际内容构建过程可以拆成四步digest 固定的多架构基础镜像。基础镜像是公开版funasr-runtime-sdk-online-cpu-0.1.13但通过 manifest digest 固定sha256:2a54c20f...保证构建可复现。注释# syntaxdocker/dockerfile:1.7表明使用了 BuildKit 语法。按架构选择依赖目录。利用ARG TARGETARCHamd64 使用onnxruntime-linux-x64-1.14.0与ffmpeg-master-latest-linux64-gpl-sharedarm64 使用onnxruntime-linux-aarch64-1.17.1与ffmpeg-master-latest-linuxarm64-gpl-shared其他架构直接报错退出。这也解释了为什么 0.1.9 起该镜像系列支持 ARM64。安装源码树并编译 C 服务。先pip install --no-cache-dir -e ./editable 模式安装当前 checkout再执行cmake -S runtime/websocket -B runtime/websocket/build \ -DCMAKE_BUILD_TYPERelease \ -DENABLE_PORTAUDIOOFF \ -DONNXRUNTIME_DIR${onnxruntime_dir} \ -DFFMPEG_DIR${ffmpeg_dir} cmake --build runtime/websocket/build --parallel $(nproc)产物即runtime/websocket/build/bin/funasr-wss-server-2pass。设置入口与端口。COPY runtime/dockerfile/online-cpu-entrypoint.sh /usr/local/bin/online-cpu-entrypoint.sh并置0755随后EXPOSE 10095、VOLUME [/workspace/models]ENTRYPOINT指向该脚本。这些约束并非文档口头声明而是有自动化测试把关的tests/test_online_cpu_dockerfile.py 断言了 digest 固定、COPY . /workspace/FunASR、editable 安装、cmake 编译参数、入口脚本与端口等关键标记.github/workflows/test-online-cpu-docker.yml 则用docker/build-push-actionv6在linux/amd64平台完整构建该镜像并直接执行funasr-wss-server-2pass --help做冒烟验证。4.2 入口脚本与环境变量覆盖online-cpu-entrypoint.sh 是本地构建镜像与预构建镜像的关键差异点——它会直接拉起服务而不经过预构建镜像的交互式守护包装。脚本逻辑set -euo pipefail容器可替换入口若第一个参数不以-开头直接exec $方便把容器当普通命令环境使用模型与热词目录FUNASR_DOWNLOAD_MODEL_DIR默认/workspace/models确定模型根目录FUNASR_HOTWORD_FILE默认${model_root}/hotwords.txt指定服务端热词文件脚本会mkdir -p并touch热词文件保证存在线程数自动推导解码线程FUNASR_DECODER_THREAD_NUM默认$(nproc)IO 线程FUNASR_IO_THREAD_NUM默认为(decoder_threads 15) / 16模型 ID 覆盖FUNASR_MODEL_DIR默认 Paraformer-large 带 VAD/PUNC 的离线模型、FUNASR_ONLINE_MODEL_DIR流式模型、FUNASR_VAD_DIRFSMN VAD、FUNASR_PUNC_DIR、FUNASR_ITN_DIR、FUNASR_LM_DIRngram FST 语言模型分别对应 2pass 服务的各阶段模型端口与其他参数FUNASR_PORT默认10095、FUNASR_MODEL_THREAD_NUM默认 1--certfile /--keyfile 表示默认不启用 SSL末尾$透传额外命令行参数等价于 SDK_advanced_guide_online.md 中run_server_2pass.sh的手动参数方式。因此启动本地构建镜像的最小命令可以写成docker run --rm -p 10096:10095 \ -v $PWD/funasr-runtime-resources/models:/workspace/models \ funasr-online-cpu:local若要指定模型或端口例如改用带时间戳输出的离线模型并监听 9000 端口则通过环境变量覆盖docker run --rm -p 9000:9000 \ -v $PWD/funasr-runtime-resources/models:/workspace/models \ -e FUNASR_PORT9000 \ -e FUNASR_MODEL_DIRdamo/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx \ funasr-online-cpu:local4.3 与预构建镜像启动方式的对照SDK_advanced_guide_online.md 记录了官方推荐的两种启动方式拉取 0.1.13 镜像后进入容器手动执行bash run_server_2pass.sh --download-model-dir /workspace/models ...显式列出各模型目录参数或从源码构建后由入口脚本自动完成同等配置。二者的模型参数完全对应区别在于参数是“命令行显式给出”还是“环境变量默认值 覆盖”。5. Python SDK 开发路径不发明通用开发镜像文档对 SDK 开发路径的立场非常克制不虚构一个“通用开发镜像标签”或模型兼容矩阵。正确做法是自行选择一个经过审查与验证的 Python/PyTorch 容器基础镜像与包版本自行记录按 安装指南 将当前 checkout 安装进去跑通 SDK 教程 作为冒烟验证。同时文档重申容器内的边界条件同样适用模型缓存策略、离线准备流程、trust_remote_code的信任决策安装指南建议默认trust_remote_codeFalse除非所选模型确实需要且你已审查过其代码、以及软件与模型相互独立的许可证FunASR 软件为 MIT模型权重各有独立条款参见 LICENSE 与 MODEL_LICENSE。6. 复现性清单把 digest、commit 与模型版本一起存档原文档的最后一段是整个部署流程的收尾要求也是工程上最值得照做的一条将精确的镜像 digest、源码 commit 与模型版本与你的测试结果一起保存。结合本文的源码证据这份清单具体应包含镜像 digestdocker image inspect $IMAGE --format {{json .RepoDigests}}的输出对应 Dockerfile.online.cpu 中BASE_IMAGE的固定方式源码 commit本地构建镜像时 checkout 的 git 提交号——因为 editable 安装 C 编译意味着镜像内容完全取决于构建时的源码树模型修订各阶段模型ASR/online ASR/VAD/PUNC/ITN/LM在模型库中的 ID 与快照版本测试结果如 test-online-cpu-docker.yml 中对funasr-wss-server-2pass --help的冒烟检查是你本地验证流程的最小参照。更多运行时入口可继续查阅 运行时总览 与 快速上手本文的中文姊妹篇见 docker_zh.md。【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考