AI 应用落地时常遇到三个现实问题：① 数据敏感或环境无外网，不能把图片、音频、文本传到云端 API；② 一个业务往往要同时用到多个模型（检测、分割、OCR、语音识别等），若每个模型各起一个进程，内存占用与启动开销大、管理分散；③ 推理能力需要被桌面端、工作流节点、脚本乃至别的语言统一调用，缺一个标准入口。本项目立项，就是做一个可本地私有化部署的 ONNX 推理引擎与配套管理器：一个服务实例同时常驻多个模型，对外统一暴露 HTTP 接口，既可由桌面管理器一键拉起，也可单独部署到其它机器或容器。面向智能制造质检、语音转写、文档 OCR、实验室数据处理等对数据合规与离线运行有要求的场景。
分为服务端与管理器两部分。 服务端 onnx_server.exe ：① 模型池——一个实例同时加载多个 .onnx，可查看每个模型的加载状态、耗时与输入/输出签名（形状/类型），支持动态维覆盖、线程数、图优化级别、预载开关等参数；② HTTP 接口——`GET /health` （健康检查与实例身份）、`GET /v1/models` （模型清单与自检）、`POST /v1/infer` （任意 ONNX 通用张量推理，支持 float32/64/16、int64/32、uint8/int8、bool）、`POST /v1/tasks/` （任务语义端点，现已内置语音识别 ASR）；③ 鉴权——可启用 Bearer API Key，默认仅监听本机；④ 扩展点——新增一类能力只需加一个任务适配器并注册，底座与路由不变。 管理器 onnx_manager ：① 多实例管理——新增/复制/删除实例，每实例独立名称、端口、API Key 与模型池；② 模型池可视化编辑（弹窗表格 + 字段表单）；③ 启停控制——单个或一键全部启停、连接测试、一键复制 API 地址；④ 实时日志、健康检查与启动耗时统计；⑤ 进程接续——关闭程序默认保留服务，下次启动自动接管，并扫描清理残留进程；⑥ 启动成功后自动登记为「AI 服务商」，供画布节点直接调用；⑦ 配置、窗口几何、分割条与列宽自动记忆。
我负责服务端与管理器的完整设计与实现。技术栈：C++17 + CMake；服务端以 onnxruntime 做推理、cpp-httplib 提供 HTTP、kaldi-native-fbank + FFmpeg 做音频前端与解码，且刻意只链 Qt Core（不依赖界面/SQL/OpenSSL），以便单独部署；管理器用 Qt 6.8（Widgets / Network），经 QProcess 托管服务进程、用 HTTP 做健康检查，配置复用工程内 CoreModule（AppSettings / SQLite）。亮点与难点：① 两端契约落在`models.json` 与 HTTP 协议上而非 C++ 头文件——任一端换语言重写都能对接，服务因此可独立部署；② 服务端用 pimpl 完全隔离 ONNX Runtime 头文件，调用方无需感知 ORT；③ 多模型并发的线程模型——会话以 shared_ptr 持有、加载与卸载在锁外进行，推理中卸载也不会析构正在使用的会话；④ 容错——配置结构性错误直接拒绝启动，但单个模型文件缺失或加载失败只标记该模型，服务照常运行；⑤ 扩展点设计——任务适配器 + 注册表，新增能力不动底座，路由用一条正则覆盖全部任务；⑥ 内置 ASR 任务实现了 FFmpeg 解码 → Kaldi 风格 fbank → LFR → CMVN → ONNX → CTC 解码 → 词表查表的纯 C++ 全链路，输出与官方 Python 参考逐字一致（其中 CMVN 必须以 double 计算、抖动置 0 以保证可复现）；⑦ 踩坑并解决：用管道捕获服务 stdout 却不持续读取会让管道写满、服务永远到不了监听——管理端改为异步排空，并始终写日志文件以便接管态排查。
评论