1. 环境准备与核心思路
大家好，我是老张，在AI和智能硬件这块摸爬滚打了十来年，今天想和大家聊聊一个非常实用的项目：如何在只有CPU的服务器上，稳稳当当地部署一个高并发的离线语音转写服务。我知道很多朋友的公司或者个人项目，预算有限，没有强大的GPU服务器，但又需要处理大量的音频转写任务，比如会议录音整理、客服质检、视频字幕生成等等。这时候，FunASR这个纯CPU也能跑的离线语音识别模型，简直就是救星。
但官方的部署文档更多是面向开发者的“玩具级”演示，真扔到生产环境，面对几十上百个用户同时上传文件，原生的WebSocket服务可能直接就“躺平”了。我亲自踩过这个坑，所以今天带来的这套方案，核心目标就是**“稳”和“高并发”**。我们会用Docker把环境封装得干干净净，用Nginx做反向代理和负载均衡（哪怕目前只有一个后端服务，Nginx的连接管理和缓冲池也能极大提升并发能力），最后再把官方那个有点复杂的前端界面，大刀阔斧地简化成一个开箱即用、小白也能直接上手的工具页。
我这次实战的服务器配置很“寒酸”：一台2核4G的Ubuntu云服务器，纯CPU环境。就是在这种资源受限的条件下，我们通过一系列优化，让它能比较从容地应对中小规模的并发请求。下面，我就把每一步的操作、背后的原理，以及我踩过的那些坑，毫无保留地分享给大家。
2. 基础部署：拉取镜像与启动容器
万事开头难，我们先从把FunASR的服务跑起来开始。官方提供了Docker镜像，这大大简化了部署，但有些细节需要注意。
2.1 获取与启动Docker镜像
首先，我们需要拉取正确的CPU版本镜像。这里要注意，镜像标签版本可能会更新，我实战时用的是funasr-runtime-sdk-cpu-0.4.6，你可以去官方仓库查看最新版本。
sudo docker pull registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-cpu-0.4.6镜像拉取完成后，别急着直接docker run。官方示例是前台运行，我们生产环境一定要用后台守护进程模式。更重要的是，FunASR运行时需要下载语音识别模型，这些模型文件很大（几个GB），如果每次启动容器都重新下载，既耗时又耗流量。所以，我们必须创建一个本地目录，把它“挂载”到容器内部，让模型文件持久化保存在我们的服务器硬盘上。
# 在当前目录下创建一个用于存放模型的持久化目录 mkdir -p ./funasr-runtime-resources/models目录创建好之后，就可以启动容器了。下面这条命令参数比较多，我逐一解释：
-d：后台运行。-p 10095:10095：将容器内部的10095端口映射到宿主机的10095端口。FunASR的WebSocket服务默认跑在这个端口。-it：虽然后台运行，但保留交互式终端的一些特性，方便以后进入容器。--privileged=true：给容器特权模式。这是因为FunASR内部的一些库可能需要更高的系统权限来操作，为了避免后续出现莫名其妙的权限错误，我这里直接给了。（安全提示：在生产环境，如果条件允许，应尝试更细粒度的权限控制，但为了部署顺利，我们先这样用）-v $PWD/funasr-runtime-resources/models:/workspace/models：这是关键！把刚才创建的本地目录，挂载到容器内的/workspace/models路径。这样，模型文件就会下载并保存在你的服务器本地，而不是容器内部。
sudo docker run -d -p 10095:10095 -it --privileged=true -v $PWD/funasr-runtime-resources/models:/workspace/models registry.cn-hangzhou.aliyuncs.com/funasr_repo/funasr:funasr-runtime-sdk-cpu-0.4.6执行后，用docker ps命令看一下，如果容器状态是Up，就说明启动成功了。记下你的CONTAINER ID，后面我们要进入容器操作。
2.2 进入容器并启动核心服务
容器虽然跑起来了，但里面的FunASR转写服务还没启动呢。我们需要进入容器，手动执行启动脚本。
# 将 a941fe3c5084 替换为你自己的容器ID sudo docker exec -it a941fe3c5084 /bin/bash进入容器后，你会发现身处一个Linux环境中。FunASR的代码已经被放在容器里了。我们切换到服务脚本所在的目录：
cd FunASR/runtime接下来就是最关键的启动命令了。官方提供的run_server.sh脚本有很多参数，我基于实战经验做了一些调整和优化：
nohup bash run_server.sh \ --download-model-dir /workspace/models \ --certfile 0 \ --vad-dir damo/speech_fsmn_vad_zh-cn-16k-common-onnx \ --model-dir damo/speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx \ --punc-dir damo/punc_ct-transformer_cn-en-common-vocab471067-large-onnx \ --lm-dir damo/speech_ngram_lm_zh-cn-ai-wesp-fst \ --itn-dir thuduj12/fst_itn_zh \ --hotword /workspace/models/hotwords.txt > log.txt 2>&1 &我来拆解一下这几个重要参数：
--download-model-dir /workspace/models：指定模型下载目录。这里就是我们挂载的本地目录，模型会下到这里，永久保存。--certfile 0：这个很重要。官方默认会启用SSL（WSS），但对于我们内网或HTTP环境下的反向代理，SSL配置反而复杂。设为0就是关闭SSL，使用普通的WS协议，后面用Nginx来处理SSL（如果需要的话）会更方便。- 后面一系列的
--vad-dir、--model-dir等参数，指定了使用的VAD（语音活动检测）、识别、标点、语言模型等。这些都是目前中文场景下效果比较好的开源模型。 --hotword：热词表路径。你可以创建一个hotwords.txt文件，里面每行放一个你想让模型优先识别的词（比如公司名、产品名、专业术语），能显著提升特定词汇的识别准确率。文件需要放在之前挂载的/workspace/models目录下，并在容器内对应位置创建好。- 最后
> log.txt 2>&1 &是把日志输出到文件，并在后台运行。
执行命令后，建议用tail -f log.txt实时查看日志。你会看到它在下载模型（如果第一次运行），下载完成后会启动服务。看到类似“Uvicorn running on http://0.0.0.0:10095”的日志，就说明服务启动成功了。
3. Nginx反向代理与高并发调优
好了，现在FunASR服务已经在容器内的10095端口跑起来了。但直接暴露这个端口给用户是不行的，一是没有负载均衡和高并发处理能力，二是无法优雅地处理WebSocket协议。这时候，Nginx就要登场了。它不仅是简单的“转发请求”，更是我们提升并发能力的“神器”。
3.1 为什么需要Nginx？
你可以把FunASR的原生服务想象成一个“手艺精湛但一次只能接待一位顾客的老师傅”。客户（前端页面）直接找他，他处理得很好，但门口排长队他就忙不过来了，而且沟通（WebSocket握手）起来也比较“原生态”。
Nginx则像一个“专业的接待经理和调度员”。它坐在老师傅门口，所有客户先找它。它的本事是：
- 缓冲与排队：能同时接待大量客户，管理好他们的连接，有序地转交给后端的老师傅，避免老师傅被瞬间涌来的请求冲垮。
- 协议优化：专门负责处理与客户的复杂沟通（HTTP/WebSocket协议转换、头部信息处理），让老师傅专心干活。
- 资源管理：可以配置连接超时时间，防止一些“慢客户”长期占用老师傅的资源。
所以，即使我们后端只有一个FunASR容器，加上Nginx，整个系统的并发能力和稳定性也能提升一个档次。
3.2 Nginx核心配置详解
下面是我经过多次压力测试后，调整出的一个适用于纯CPU环境的Nginx配置片段。你需要将它整合到你Nginx的nginx.conf的http {}块中，或者放在/etc/nginx/conf.d/下的一个独立配置文件里（比如funasr.conf）。
worker_processes auto; # 自动设置为与CPU核心数相等。对于2核服务器，就是2个worker进程。 worker_rlimit_nofile 200000; # 设置每个worker进程能打开的最大文件描述符数量。高并发下这个值一定要调大。 events { use epoll; # Linux系统下高性能的事件驱动模型，必须开启。 worker_connections 65536; # **每个**worker进程允许的最大连接数。2个worker就能处理13万+的连接（虽然实际达不到，但留足余量）。 multi_accept on; # 让一个worker能够一次性接受所有的新连接，提高效率。 } http { # ... 其他http全局配置 ... # 这个map块是处理WebSocket连接升级的关键 map $http_upgrade $connection_upgrade { default upgrade; # 如果请求头里有Upgrade，就返回upgrade '' close; # 否则就返回close } server { listen 10096; # Nginx对外监听的端口，用户通过这个端口访问。你可以改成80或443（需配SSL）。 server_name _; # 匹配所有域名，你也可以换成你自己的域名。 location / { proxy_pass http://127.0.0.1:10095; # 核心：转发到我们Docker容器跑的服务 proxy_http_version 1.1; # 必须使用HTTP 1.1，才能支持WebSocket # 下面三行是WebSocket代理的核心配置 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; # 超时时间非常重要！语音转写是长任务，需要设置得非常长。 proxy_read_timeout 36000s; # 后端服务器响应的超时时间，10小时 proxy_send_timeout 36000s; # 向后端服务器发送请求的超时时间，10小时 proxy_connect_timeout 30s; # 与后端服务器建立连接的超时时间 # 以下是一些优化缓冲和重试的配置，有助于提升稳定性 proxy_buffering off; # 对于流式响应（WebSocket），关闭代理缓冲，实现实时传输。 proxy_request_buffering off; # 关闭请求体缓冲，加快上传速度。 proxy_next_upstream error timeout http_500 http_502 http_503 http_504; # 定义在什么情况下请求下一个上游服务器（虽然我们只有一个）。 } } }配置完成后，运行sudo nginx -t测试配置语法是否正确，然后sudo systemctl reload nginx重新加载配置使其生效。别忘了在服务器防火墙和安全组中，放行你配置的Nginx监听端口（例如10096）。
3.3 参数调优背后的思考
这里重点说说几个关键参数为什么这么设。worker_connections设得大，是为了应对大量并发连接。proxy_read_timeout和proxy_send_timeout设成36000秒（10小时），是因为语音转写，尤其是长音频文件，处理时间可能很长，如果超时时间太短，连接会被Nginx强行切断，导致转写失败。proxy_buffering off对于WebSocket通信至关重要，因为我们需要的是实时、流式地传输识别结果，如果Nginx在中间做了缓冲，前端就会收到延迟的、成块的数据，体验很差。
我实测下来，经过Nginx这一层代理后，前端页面与服务的连接稳定性明显增强，在模拟20-30个并发上传小音频文件的场景下，服务没有出现崩溃或拒绝连接的情况，而直连后端服务则很容易出错。
4. 前端界面简化与定制优化
官方提供的Web Demo功能很全，但对于只想简单上传文件、拿到转写文字的用户来说，界面显得有些复杂，包含了实时录音、模型选择等我们离线部署用不上的功能。我们的目标是：一个输入框（上传文件）、一个按钮（开始转写）、一个区域（显示结果），干净利落。
4.1 剥离与重构HTML/JS
官方前端是一个Vue项目，但我们不需要那么重。我直接将其核心功能剥离出来，写成了一个单一的HTML文件，配合一个修改过的main.js。核心改动如下：
- 移除冗余UI：删除了录音、模型切换、高级参数设置等所有与“文件转写”无关的组件和代码。
- 简化流程：页面加载后，自动连接我们部署好的WebSocket服务（地址配置在JS里）。用户选择文件后，点击“转写”按钮，直接将文件二进制数据通过WebSocket发送到后端。
- 优化交互：
- 上传时显示进度条。
- 转写结果采用流式输出，也就是后端识别出一句话，前端就实时显示一句话，而不是等整个文件处理完再一起显示。这种“逐字打出”的体验非常好，让用户感知到服务正在工作。
- 增加“复制结果”和“清空”按钮，方便实用。
- 错误处理：对网络断开、服务异常、文件格式错误等情况做了简单的提示，避免页面卡死。
这里贴一下核心的连接与发送代码逻辑（简化版）：
// 配置你的服务器地址，注意端口是Nginx监听的10096 const wsUrl = `ws://你的服务器IP:10096`; let socket = new WebSocket(wsUrl); socket.onopen = function() { console.log('连接转写服务成功'); document.getElementById('status').innerText = '服务已连接'; }; socket.onmessage = function(event) { // 接收后端流式返回的JSON数据 const data = JSON.parse(event.data); if (data.text) { // 将识别出的文本实时追加到结果区域 const resultDiv = document.getElementById('result'); resultDiv.innerText += data.text; // 自动滚动到底部 resultDiv.scrollTop = resultDiv.scrollHeight; } }; // 文件处理函数 async function handleFileUpload(file) { const arrayBuffer = await file.arrayBuffer(); const audioBlob = new Blob([new Uint8Array(arrayBuffer)], { type: file.type }); // 将音频Blob通过WebSocket发送 socket.send(audioBlob); }4.2 部署与访问
前端就是一些静态文件（HTML、JS、CSS）。你可以把它们放在服务器上的任何一个目录，然后用Nginx再配置一个静态文件服务，或者更简单点，直接在你刚才的Nginx配置里加一个location块来提供这个HTML文件。
server { listen 10096; server_name _; # 静态文件服务，用于访问前端页面 location / { root /path/to/your/frontend/files; # 你的HTML文件所在目录 index index.html; } # WebSocket服务代理 location /ws { proxy_pass http://127.0.0.1:10095; # ... 上述所有的proxy配置 ... } }这样，用户访问http://你的服务器IP:10096就能看到简洁的上传页面，进行转写了。所有通信都通过同一个端口的/ws路径进行，避免了跨域问题。
5. 性能监控、运维与踩坑记录
服务跑起来不是终点，怎么让它跑得稳、跑得久，才是关键。在纯CPU环境下，资源就是一切。
5.1 监控容器资源使用
一定要养成监控的习惯。使用docker stats命令可以实时查看容器的CPU、内存占用。
sudo docker stats <你的容器ID或名称>你会发现，在转写任务进行时，CPU使用率会飙升到接近100%（一个核心）。这就是纯CPU计算的特性。内存占用则相对稳定，主要被加载的模型占用。通过监控，你可以了解单次转写的资源消耗，从而估算出你的服务器大概能承受的并发数。例如，2核服务器，理论上可以同时处理2个转写任务而不至于负载过高（通过Nginx排队）。
5.2 日志与问题排查
日志是你的“黑匣子”。FunASR服务的日志（我们之前输出到log.txt）和Nginx的error log (/var/log/nginx/error.log) 是排查问题的首要位置。
我踩过的一个典型坑：前端连接成功，但一上传文件就断开。查看Nginx错误日志发现upstream timed out (110: Connection timed out)。这就是因为最初的proxy_read_timeout设置得太短（比如60秒），长音频处理超时。按照前面说的，把它调到非常大（或直接关掉）就解决了。
另一个坑：模型文件下载失败。因为网络原因，从ModelScope拉取模型可能会中断。解决方法就是进入容器，手动检查/workspace/models目录下的文件是否完整，或者尝试重新执行启动脚本（它会检查模型是否存在，不存在则下载）。
5.3 进阶优化思路
如果你的并发需求继续增长，单机CPU撑不住了，可以考虑以下方向：
- 水平扩展：这是最直接的办法。在另一台服务器上再部署一套相同的FunASR服务（注意模型目录可以通过NFS等方式共享）。然后修改Nginx配置，在
upstream块中配置多个后端服务器地址，Nginx会自动进行负载均衡。这样就从“一个老师傅”变成了“多个老师傅”，并发能力成倍提升。 - 任务队列：对于非实时性的批量文件转写，可以引入任务队列（如Redis + Celery）。前端上传文件后，立即返回一个任务ID，后端将任务放入队列异步处理。用户可以通过任务ID轮询或等待WebSocket通知获取结果。这样能彻底解耦请求和处理，避免HTTP长连接占用。
- 模型量化：关注FunASR社区，看是否有更小、更快的量化模型发布，能在精度损失不大的情况下，显著降低计算开销。
最后想说的是，这套方案是我在资源紧张的情况下摸索出来的，它可能不是性能最优的，但一定是性价比最高、最易于落地的。从Docker封装、Nginx调优到前端简化，每一步都是为了降低运维难度，提升服务可靠性。技术选型没有银弹，适合自己场景的才是最好的。希望这份详细的实战记录，能帮你少走弯路，快速搭建起属于自己的离线语音转写服务。如果在操作中遇到任何问题，欢迎随时交流讨论。
