端侧语音部署踩坑：模型能跑不等于终端真的能用

最近参与端侧语音项目，目标比较明确：设备不能依赖公网，最好能够在内网甚至完全断网的情况下运行。

听起来就是把模型下载下来，然后启动。

真正部署以后才发现， "模型能跑"和"系统能用"是两回事。

尤其是在一些资源比较有限的设备，以及国产软硬件环境中，模型、推理框架、驱动和系统之间经常会互相牵制。

一、先确认设备到底有多少资源

以前做模型测试，我比较习惯直接看：

复制代码

GPU显存
CPU核心数
内存

后来发现还不够。

端侧部署至少需要确认：

复制代码

CPU
内存
GPU/NPU
显存/共享内存
磁盘
操作系统
驱动版本
推理框架
Python/C++运行环境

尤其是信创环境，不能简单按照开发机上的 CUDA + PyTorch 环境复制过去。

所以我现在部署前都会先跑一个环境检查：

python 复制代码

import platform
import os
import psutil

print("系统:", platform.platform())
print("CPU:", platform.processor())
print("CPU核心:", os.cpu_count())

memory = psutil.virtual_memory()

print("总内存:",
      round(memory.total / 1024**3, 2),
      "GB")

print("可用内存:",
      round(memory.available / 1024**3, 2),
      "GB")

先把硬件边界摸清楚，再决定模型怎么部署。

二、不要默认"模型越大越好"

端侧最现实的问题就是资源。

假设有两个模型：

css 复制代码

模型A
精度：高
内存：大
速度：慢

模型B
精度：稍低
内存：小
速度：快

如果跑在服务器上，我可能更倾向于A。

但如果跑在普通终端上，B可能反而更合适。

尤其是会议语音这种持续运行的任务，不能只看单次识别效果。

我更关注：

这几个指标需要一起看。

三、量化是端侧优化里绕不开的一步

如果硬件和推理框架支持，模型量化通常是比较直接的优化方向。

例如：

复制代码

FP32
 ↓
FP16
 ↓
INT8

模型权重占用会明显下降。

一个简单的概念：

ini 复制代码

FP32 = 32 bit
FP16 = 16 bit
INT8  = 8 bit

理论上只看权重存储：

复制代码

FP32 → FP16
约减少一半

FP32 → INT8
约减少四分之三

当然，实际内存和速度不会严格按照这个比例变化，因为还涉及激活、算子和运行时开销。

所以量化以后一定要重新测试：

复制代码

准确率
延迟
内存
CPU

不能看到模型变小了，就直接认为优化成功。

四、一个容易忽略的问题：启动速度

离线设备有一个很现实的场景：

设备开机以后，用户马上就要使用。

如果模型初始化需要很长时间，用户看到的就是：

所以我更建议：

同时增加状态接口：

csharp 复制代码

@app.get("/health")
def health():
    return {
        "status": "ready",
        "model": "loaded"
    }

业务程序只需要判断：

vbnet 复制代码

READY → 接收语音
LOADING → 暂不接收
ERROR → 提示异常

不要让业务层直接猜模型现在到底有没有加载完成。

五、离线部署最容易被忽略的是依赖

开发环境：

复制代码

pip install xxx

然后模型启动。

到了真正的离线环境：

复制代码

没有公网
没有pip源
没有自动下载

这时候才发现模型运行需要一堆依赖。

所以比较稳妥的做法是提前制作离线安装包：

arduino 复制代码

offline_package/
├── wheels/
├── models/
├── config/
├── scripts/
└── requirements.txt

安装：

css 复制代码

pip install --no-index \
  --find-links=./wheels \
  -r requirements.txt

模型也不要让程序启动时自动联网下载。

应该明确指定本地路径：

ini 复制代码

MODEL_PATH = "./models/asr"

model = load_model(
    MODEL_PATH
)

这样断网以后，系统仍然能够正常运行。

六、信创环境不能只测试"能不能启动"

如果项目涉及国产CPU、操作系统或者国产AI加速硬件，测试思路应该变化。

不能只验证：

还应该测试：

尤其要注意：

开发机能运行，不代表目标信创设备一定能运行。

实际部署前，最好准备一台与最终环境一致的验证机。

七、端侧功耗也应该进入测试表

以前做服务端ASR，我几乎不会关注功耗。

但到了端侧，功耗会直接影响设备体验。

如果一个模型：

erlang 复制代码

CPU长期100%

即使识别速度不错，也可能带来：

复制代码

发热
降频
续航下降
风扇噪声

最后反过来影响语音识别。

所以可以简单记录：

lua 复制代码

import time
import psutil

start = time.time()

# 执行一次ASR
result = asr.transcribe(audio)

elapsed = time.time() - start

print("推理耗时:", elapsed)
print("CPU占用:", psutil.cpu_percent())
print("内存占用:", psutil.virtual_memory().percent)

连续跑几十分钟甚至几个小时，比只跑一条测试音频更有意义。

八、我的端侧评测表现在会这样设计

这样测下来，才比较接近真实项目。

九、端侧语音真正需要解决的是什么？

做了一段时间以后，我越来越不喜欢单纯讨论：

"这个ASR模型准确率是多少？"

因为真正部署的时候，模型只是其中一部分。

完整链路应该是：

如果还要进一步做会议场景：

所以我现在对端侧语音的理解更简单：

不是把云端模型搬到设备上，就叫端侧智能。

真正可用的端侧方案，要同时解决：

复制代码

听得懂
反应快
资源少
功耗低
断网可用
环境可控

尤其是在信创和离线部署场景中，工程适配的重要性有时候甚至不低于模型本身。

十、总结

这次熙瑾会悟项目端侧部署最大的感受就是：

模型能跑，只是项目的开始。

从开发机迁移到真正的端侧设备，还需要解决：

模型量化
推理框架适配
驱动兼容
离线依赖
音频前处理
内存控制
CPU占用
功耗
长时间稳定运行

所以以后再看到"支持离线部署"这几个字，我会继续往下问：

在哪种设备上？

什么系统？

需要什么驱动？

模型占多少内存？

连续运行几个小时怎么样？