FunASR 语音识别本地部署实录（上）：我为什么自建？音频不出本机，30 分钟跑通转写接口

原文链接：FunASR 语音识别本地部署实录（上）：我为什么自建？音频不出本机，30 分钟跑通转写接口

语音转写这事，我一直不太想把音频交到云上。会议录音、客户电话这类素材，出了本机心里就不踏实。

前阵子我把 FunASR 跑成了本机服务，对外暴露 OpenAI 兼容的接口，装包、写代码到 curl 通第一个请求，半小时内的事。动手前我做了三个决定：用什么机器、用什么模型、对外暴露成什么样子。这篇按这三个决定往下写，最后附上实测数据。

一、为什么自建，而不是直接调云 API

先说动机：这套服务从一开始就是给我自己用的，本地自测、日常转写，要求不高，够用就行。自己用，就没必要为它开云账号、传音频、盯账单，本地跑一份更顺手。

但自建不是因为它便宜。算笔账：阿里云百炼的 Paraformer 接口，一小时几毛钱；讯飞语音转写要好几块，同一条音频差出几十倍也不稀奇。转写量大了自建确实划算，可云上地板价就在那里，省下的钱多半抵不过折腾的时间。

真正让我下决心的，是另外两件事。一是数据边界，会议录音、客户电话、内部访谈这类素材本身敏感，走云 API 等于把原始音频交给别人，"原始录音在别人服务器上"这道坎，我自己过不去。二是可控性，热词、说话人分离、后续微调，能力握在自己手里，想加就加，不用等厂商排期。

自建的成本也要说清楚，别想得太美。电费忽略不计，贵的是我的时间。前面说的半小时，是环境顺的情况下装包加跑通；真算总账，装环境、踩坑、维护零零散散加起来不少，但这是一次性投入，跑起来之后基本不用管。云 API 那边是持续账单，还有个坑：按音频时长计费，静音段也算钱，我转的录音大段停顿很常见，这笔钱花得有点冤。

所以我的判断是：自建适合转写量大、音频敏感不能出内网、要离线部署的人；偶尔转几段的话，直接调云 API 更省心。

二、选型：机器、模型、接口形态

机器：M1 Pro 32GB，够用

我手上这台是 MacBook Pro 2021，M1 Pro、10 核 CPU、32GB 统一内存，没有独立 NVIDIA GPU。这一条直接定了路线：vLLM、TensorRT 这类吃 CUDA 的高吞吐方案全部排除，只能走 CPU 推理。

Paraformer-zh 是 220M 参数的模型，配套的 FSMN-VAD 只有 0.4M 参数，CT-PUNC 标点模型 290M 参数，三个权重加起来 2GB 上下，32GB 内存毫无压力。CPU 上能跑多少倍实时，我实测短音频 4 倍左右、长录音 1.8 倍，具体数据在下一篇，先给结论：个人开发场景够用。

其实还有一个更轻的选项：官方 2026 年 6 月上线的 llama.cpp/GGUF 运行时，单二进制、不用 Python，q8 量化后模型体积减半，边缘设备都能跑。我没选它，是因为我的下游是 LangChain、Dify 这类 HTTP 客户端，要的是服务接口，而且热词、说话人这些参数在 Python 链路里调起来更顺手。GGUF 适合无人值守的边缘盒子，两种定位不一样。

模型：为什么是 Paraformer-zh 三件套

FunASR 仓库里挂着一整族模型，我最后选了 Paraformer-zh 加 VAD 加标点，理由就一条：中文场景下它是"稳稳跑通"的默认选项，社区资料最全，坑都有人替你踩过了。

Paraformer 是达摩院语音实验室的模型，2022 年发表在 INTERSPEECH 上，非自回归架构，解码单步完成，所以快。三个模型的分工是这样：FSMN-VAD 先把长音频切成"有人说话"的段落，Paraformer-zh 逐段识别，CT-PUNC 再把标点补回来。FunASR 的 AutoModel 里用 vad_model 和 punc_model 两个参数自动串联，拼接代码都不用自己写。

对比着说。Fun-ASR-Nano 是通义实验室 2025 年 12 月发布的 LLM-ASR 路线模型，800M 参数，中英日加方言口音都行，但对算力要求高，官方还明确不保证可靠的字级时间戳，而我要时间戳做字幕对齐，直接不选。SenseVoice 偏多语种和情感识别，一遍出转写加语种加情感标签，纯中文转写没有明显增益。Whisper 系中文不是强项，官方在 184 集中文测试集上给过一组基准，Paraformer 字错率不到 10%，whisper.cpp 的 large-v3-turbo 是 23% 出头，差两倍多。

热词这一点单独说。转写业务术语、人名地名的时候，hotword 参数直接把词注入，识别率肉眼可见地提升，这是 Paraformer 系的看家本领，也是我选它而不是 Whisper 的另一个原因。

接口：对齐 OpenAI，下游零改造

模型定了，接口形态也得定。FunASR 官方部署选择器里标了"生产验证"的几条路径，和我的场景对得上的就是 OpenAI 兼容 API 这条：/v1/audio/transcriptions 路径、file / model / response_format 三个请求字段、text / language / duration / segments 这套返回键名，都是 Whisper API 的公开契约。LangChain、Dify、n8n 这些对接过 OpenAI 音频接口的客户端，切到本机服务不用改一行代码。

整条链路长这样，请求先进网关，再到 FastAPI 服务，进程内完成 VAD 切分、Paraformer 推理、CT-PUNC 标点，权重缓存在本地，第二次起服务直接命中：

三、搭建：30 分钟跑通

机器、模型、接口三件事定完，剩下的就是装包、写代码、起服务。

装包

FunASR 依赖里有一批带 C 扩展的包（kaldi-native-fbank、onnxruntime、sentencepiece），从默认 PyPI 源拉会卡半天，我直接切清华镜像：

python3 -m pip install --break-system-packages \   -i https://pypi.tuna.tsinghua.edu.cn/simple \   funasr fastapi 'uvicorn[standard]' python-multipart soundfile

这台机器的 Python 解释器不在默认路径上，后面所有命令我都用绝对路径，避免 shell 找不到包。

代码的三个要点

server.py 大概 180 行，三个关键判断：

模型启动时一次性加载。冷启动把权重读进内存要 8 秒上下，之后每次推理只是前向计算，所以放在启动钩子里，三个模型一起加载好。

字段名严格对齐 OpenAI。路径、请求字段、返回键名全按 Whisper 契约来，客户端拿到 JSON 不会关心后端跑的是哪个模型。

上传上限做成环境变量，默认 200MB。OpenAI 默认的 25MB 对双轨立体声录音不够用，这个下一篇会具体讲。

处理流程见下图：文件落到临时路径，soundfile 解码成数组，AutoModel.generate 一次串起 VAD、识别、标点三步：

启动和第一个请求

首次启动主要耗在下载模型，5 到 8 分钟，之后权重缓存在 ~/.cache/modelscope/，再启动加载只要 8 秒。服务起来后有四个端点：

端点	用途
/health	健康检查，带上已加载模型信息
/v1/models	列出模型别名
/v1/audio/transcriptions	转写主接口
/docs	Swagger 交互文档

启动时我特意只开 1 个 worker。模型加载后驻留在进程内存里，2GB 上下的权重，开多个 worker 就等于复制多份，再大的内存也经不起这么造。要扛并发，正确做法是外面挂队列，而不是无脑加 worker。

官方 5.55 秒的示例音频，1.31 秒处理完，RTF 0.24，约 4 倍实时。OpenAI 的 Python SDK 可以零改造对接：

from openai import OpenAI client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="not-needed") print(client.audio.transcriptions.create(model="paraformer", file=open("a.wav", "rb")).text)

到这里服务骨架就搭好了。顺带说一句，官方仓库现在也有 openai_api 的现成示例，思路和我这套一样，直接抄也省事。官方在部署页里写得很直白：示例服务不内置生产认证，这些要由网关补齐，这个边界我认同。

四、小结

一句话总结选型：要时间戳和热词选 Paraformer，要方言口音选 Fun-ASR-Nano，要多语种加情感标签选 SenseVoice。我的场景是中文转写加字幕对齐，Paraformer-zh 三件套最合适。

多说一句，语音模型圈更新太快，这份选型结论大概率撑不过半年，但判断方法不会过时。

服务能 curl 通只是开始，更长的录音才是真考验。下一篇我拿一段 63MB、34 分钟的双轨录音实测，看看 RTF 会掉到什么程度，以及上线前要补的事。觉得有用的话，顺手点个关注。

---

本文用到

1. FunASR 官方文档. FunASR - 可私有化部署的语音智能基础设施
2. ModelScope Paraformer-zh 模型卡片. Paraformer语音识别-中文-通用-16k-离线-large-pytorch
3. FunASR GitHub 仓库. https://github.com/modelscope/FunASR