关于onnx并发问题

[jacksonSuu]

现在我们业务是用的onxx部署的c版本的实时asr，能够实现48核48的并发。但是现在业务上跑不了热词，想换模型上gpu，但是并发路数没有cpu的这个实时性好，怎么解决这个问题。
cpu上目前用的是speech_paraformer-large-vad-punc_asr_nat-zh-cn-16k-common-vocab8404-onnx。
gpu上想上qwen3-asr

[LauraGPT]

这个场景建议先拆成两个问题看：

1. 如果当前 ONNX C 实时链路已经能做到 48 核 / 48 路并发，不建议只因为“热词”就直接整体切到 GPU 大模型。热词如果是业务词表纠错/替换，优先考虑在 ONNX 输出后做文本级后处理，这样可以保留 CPU 链路的并发能力。
2. 如果热词必须在解码阶段生效，或者确实要上 Qwen3-ASR，GPU 侧需要按目标延迟重新做 continuous batching / 并发压测；同一张 GPU 的“并发路数”和 CPU ONNX 不是一一对应的，通常要看音频切片长度、batch 策略、是否开 VAD/SPK、以及可接受首包/尾包延迟。

另外，FunASR 已合入 AutoModel.generate() 的文本级后处理热词能力：#3108。这个能力先覆盖 Python AutoModel 路径；你们的 C/ONNX 服务也可以先在业务层用同样思路做轻量后处理，避免改模型推理链路。

为了给出更具体的迁移方案，麻烦补充三项信息：

• 热词需求是“识别阶段偏置”还是“识别后固定纠错/替换”？
• 每路实时音频的期望端到端延迟上限是多少？
• GPU 型号、目标并发路数，以及当前 Qwen3-ASR 的启动/推理命令。

[LauraGPT]

已把这个场景补进部署选型文档：#3120 已合并。

新增入口：

• docs/deployment_matrix_zh.md → “我已有高并发 ONNX，但需要热词”
• docs/deployment_matrix.md → “I already have high-concurrency ONNX and need hotwords”

核心建议是：如果你们当前 ONNX/C++ 实时链路已经能做到 48 核 / 48 路并发，且热词主要是公司名、产品名、专有名词或固定误识别纠错，优先保留 ONNX 链路，在最终文本上做确定性后处理；不要只因为热词就把整条链路迁到 GPU 大模型。

只有当热词必须在解码阶段影响识别，或者 Qwen3-ASR/Fun-ASR-Nano 在多语言、语义理解、长音频质量上确实明显更好时，再用 GPU 路径重新压测。压测时建议同时记录首包延迟、尾包延迟、音频切片长度、VAD 策略、同时说话路数和 GPU 利用率。

如果后续还需要更具体的迁移建议，麻烦补充：

• 目标热词列表里是固定替换/纠错，还是必须影响解码？
• 每路实时音频可接受的端到端延迟上限；
• GPU 型号、目标并发路数、Qwen3-ASR 启动/推理命令；
• 当前 ONNX C 服务的 chunk/VAD 策略和热词失败样例。