sherpa-onnx,模型sherpa-onnx-streaming-paraformer-bilingual-zh-en,LLM为Qwen3-1.7B, 引擎为CTranslate
推理引擎(Nvidia生态)
CUDA 生态
Cuda toolkit是底层工具包,提供了编译器（nvcc）、调试器（cuda-gdb）、内存分析工具（nvprof）以及基础运行库（cudart）. 并且提供并行计算能力比如如何开辟显存（cudaMalloc）、如何把数据从内存拷贝到显存（cudaMemcpy）、如何定义线程块和网格。
而另外一部分CudaX 是建立在 CUDA Toolkit 之上的一系列高级函数库,核心组件包括- -
- cuDNN：专门用于深度学习（卷积、池化）。
- cuBLAS：专门用于线性代数（矩阵乘法，大模型的底层）。
- cuFFT：专门用于快速傅里叶变换（信号处理中常用）。
- NVENC/NVDEC：视频编解码加速（FFmpeg 硬件加速）。
同样的,Nvidia生态也不允许用户态程序触碰寄存器,nvcc将C++代码编译为PTX中间指令,CudaDriver中的实时编译器(JIT)根据运行时环境,翻译成机器码.
推理引擎简介
在模型部署工程中，推理引擎的核心任务是将训练好的模型权重和计算图（Computational Graph）转换为目标硬件上的高效底层算子调用。其优化手段通常包括算子融合（Operator Fusion）、常量折叠（Constant Folding）、精度校准（Quantization）以及特定硬件的内核优化（Kernel Tuning）。
贴上ai回答如下
1. NVIDIA TensorRT
定位： 针对 NVIDIA GPU 的高性能深度学习推理优化器。
Trade-off：
优势： 极致的性能。通过对计算图的深度重构和针对特定显卡架构（如 Ampere 的 Tensor Core）生成高度优化的 CUDA Kernel，能榨干 NVIDIA 硬件的吞吐量。
代价： 强硬件绑定（仅限 NVIDIA GPU）；预编译成本高，首次启动或硬件环境变更时需要漫长的序列化过程（Build Engine）；灵活性差，对于非标准算子或自定义层，通常需要手写插件（Plugin）。
典型应用场景： 自动驾驶感知算法部署。在车载边缘计算平台（如 Orin）或云端视觉处理集群中，性能是第一优先级。
2. ONNX Runtime (ORT)
定位： 微软开发的跨平台、跨后端的高性能推理引擎。
Trade-off：
优势： 互操作性最强。支持多种后端（Execution Providers），如 CUDA、TensorRT、DirectML、OpenVINO 等。它充当了硬件抽象层，极大降低了跨平台部署的工程成本。
代价： “中间层”开销。虽然它能调用各家硬件的 SDK，但在某些极端场景下，其抽象层引入的开销和算子转换损失，使其性能往往略逊于硬件厂商的原生引擎（如 TensorRT）。
典型应用场景： 跨平台桌面端软件。例如在 Windows/Linux 上运行的实时翻译或图像增强软件，开发者只需维护一套 ONNX 模型即可适配不同的显卡或 CPU。
3. vLLM
定位： 专为大语言模型（LLM）设计的高吞吐量推理框架。
Trade-off：
优势： 显存利用率极高。通过 PagedAttention 技术解决了 LLM 推理中 KV Cache 造成的内存碎片化问题，大幅提升了并发请求的吞吐量。
代价： 资源预占高。为了性能，vLLM 通常会预先占满大部分显存作为 Page 池，不适合与其他任务共用显卡；且对于单次请求的延迟优化并非其核心强项，其优势在于高并发。
典型应用场景： LLM API 服务化。如在云端构建类似 ChatGPT 的高并发对话接口服务。
4. NCNN / MNN
定位： 针对移动端（ARM 架构）优化的极致轻量化引擎（NCNN 由腾讯开发，MNN 由阿里开发）。
Trade-off：
优势： 无第三方依赖，库体积极小（通常只有几 MB），对 ARM CPU 和 VULKAN 驱动进行了手写汇编级优化。在低功耗、低算力设备上表现极佳。
代价： 开发门槛高。对复杂算子支持较慢，且模型转换过程有时会出现精度偏差，需要开发者具备较强的底层算力调试经验。
典型应用场景： 手机 App 实时视觉任务。如手机银行的活体检测、美颜滤镜或轻量化 OCR。
推理引擎对比摘要
| 引擎 | 核心优势 | 核心折损 (Trade-off) | 典型硬件 |
|---|---|---|---|
| TensorRT | 峰值性能、算子融合 | 硬件锁定、编译时间长 | NVIDIA GPU |
| ONNX Runtime | 兼容性、生态成熟 | 相比厂商 SDK 存在性能微损 | 跨平台 (CPU/GPU) |
| vLLM | 高并发、KV Cache 管理 | 显存预占、不适合非 LLM 模型 | NVIDIA GPU (H100/A100) |
| NCNN | 轻量、无依赖、ARM 优化 | 算子支持不全、调试难度高 | 手机、嵌入式 ARM |
FunASR
funasr是一个完整的asr框架,将流式处理的复杂的都封装在了流水线内,其包括VAD,ASR,Punc(标点恢复模型), ITN (反向文本正则化,可以配合热词使用),LM. 基本工作流程是这样的:
在 Python 开发环境下，FunASR 使用 AutoModel 作为入口，内部通过 Pipeline 类来管理模型, 每个子模型（VAD、ASR、Punctuation）都遵循统一的 call 接口。输入通常是 ndarray 或 torch.Tensor，输出则是标准的 dict 结构。
对于核心的asr模型，有两种方案,其一还offline也就是非流式,另外是流式即paraformer,项目中应该保留两种接口,非流式用于音频文件的转录,而流式用于实时的识别. 集成到项目中同样有两种方案,首先是完全基于Python的,另外是C++Runtime, 由于GIL锁等等python的性能原因,所以选择C++runtime继续推进.另外,funasr本身会提供2Pass方式来对识别结果进行纠正,其工作链路是第 1 Pass： 极低延迟的流式识别（部分准确度）。第 2 Pass： 当一句话结束时，利用非流式模型进行整体修正（高准确度）。
对于asr而言,最优的无疑是架构在onnx上的sherpa-onnx, sherpa-onnx 用纯 C++ 把这些繁琐的语音前处理（Audio Frontend）、流式解码器（Streaming Decoders）、文本正则化（TTS Text Normalization）全部封装好了。类似于Funasr的流水线,但是使用纯C++核心,同时提供各类语言绑定,适合端侧.
Whisper
典型的端到端方案, 性能原因弃用.
添加一个LM来做更有趣的事
Qwen2.5-1.5B是一个不错的选择,但是在工程实现上要格外注意asr管道输出到LLM的缓冲计算,这个区域应该是可伸缩的,可以借鉴webrtc对带宽的探测方案,实现缓冲区的调控,推理引擎应该是用CTranslate2
同时还要注意LLM 的 Prompt 预处理开销, 在推理引擎中设置Prefix Caching,来实现KVcache复用,减小开销,减小延迟.这是一个针对 OpenNMT 和 Fairseq 模型的高性能推理引擎。它支持权重量化（INT8/INT16）和层融合。
音频捕捉方案
WASAPI库可以实现更为简单的音频捕捉,而区别于ffmpeg的复杂管道配置, 这也是asr方案使用python而非C++实现的重要原因. 其能够直接从硬件抽象层（或驱动层）获取 PCM 数据。步骤如下
- 通过 IMMDeviceEnumerator 获取默认或指定的 eCapture 设备。
- 以 AUDCLNT_SHAREMODE_SHARED（共享模式）或 AUDCLNT_SHAREMODE_EXCLUSIVE（独占模式）初始化 IAudioClient。
- 使用 IAudioCaptureClient::GetBuffer 读取麦克风采集的音频帧。
需要注意的是WASAPI 并不支持直接“按进程”过滤音频，但它支持 环回模式 (Loopback)，用于捕获正在通过渲染设备（如扬声器、耳机）播放的所有声音。另外一定要用共享模式,否则会阻塞其他应用访问音频数据
