部署中心
每条路径都列出适用场景、验证版本、启动命令、生产责任和已知限制。
通过 vLLM 内置的 FunASR 架构，在 NVIDIA GPU 上提供兼容 OpenAI 的多语言转写与热词接口。
当前原生 vLLM 路径依赖社区转换 checkpoint；要求官方权重链路时使用官方 FunASR split-engine。实测仅覆盖单张 H100，必须按目标 GPU、音频、语言、热词与流量复测。
把 SenseVoiceSmall 构建为原生 FP16 TensorRT engine，并通过 Triton 提供可批处理的 GPU 推理服务。
TensorRT plan 不保证跨 GPU 架构或 TensorRT 版本可移植，必须在目标环境重新构建并复测精度、显存和容量。
使用 v0.2.0 的九个预编译包或源码构建，在 CPU、Vulkan、CUDA 和边缘设备上运行 FunASR GGUF 模型。
预编译 GPU 包只覆盖标注的后端和架构；Windows AMD Vulkan 的崩溃修复仍需问题报告者实机复测，其他设备也必须在目标硬件验证。
用一个无 Python 运行时的 C++ 二进制提供 SenseVoice REST、SSE、SRT/VTT 与 OpenAI Realtime WebSocket 转写。
当前官方验证覆盖 Linux 源码构建；服务不内置生产认证、TLS、多租户配额或持久队列，必须由网关和基础设施补齐。
用原生 C++ / GGML 在 CPU 或 GPU 上运行 Fun-ASR-Nano 与 SenseVoice Q8，并提供离线 CLI、兼容 OpenAI 的本地接口和 SenseVoice 缓冲流式结果。
SenseVoice 已合并到 audio.cpp main@979e070f，但尚未进入 tagged release；正式包发布前应固定该主线提交，且当前两条路径都不提供词级 timestamps。
把 FunASR 模型作为 `/v1/audio/transcriptions` 私有服务接入现有 SDK、代理和工作流。
示例服务不内置生产认证、租户配额和全套可观测性，这些必须由网关和基础设施补齐。
通过 WebSocket 在线或 2-pass 协议处理麦克风、会议字幕和实时语音流。
真实容量由音频实时比、分块、VAD、连接数和客户端背压共同决定，文件 RTFx 不能替代并发测试。
用 Docker Compose 验证，再用带持久模型缓存、探针和 ClusterIP 的 Kubernetes 模板部署。
CPU 示例不是 CUDA 生产镜像；GPU 驱动、镜像、调度和容量仍需平台团队验证。
在通用 CPU 上用 ONNX Runtime 和 C++ 路径部署离线、在线与 2-pass ASR。
模型转换、算子支持和线程参数受平台影响；必须使用目标 CPU 与真实音频测容量。
把模型能运行推进到可观测、可扩缩、可回滚且边界清晰的生产服务。
清单不能替代目标业务的负载、准确率、故障和安全演练。
