FunASR 在 vLLM 0.27.1 上的原生部署验证从兼容性探针到生产边界【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASRFunASR 仓库中记录的vllm_native_funasr_validation.md是一份针对 Fun-ASR-Nano 模型在 vLLM 原生FunASRForConditionalGeneration架构下的一次可复现兼容性与并发探针记录。本文以此验证记录为主体结合仓库中的 vLLM 使用指南、源码实现与配套测试系统讲解 vLLM 原生转录服务vllm serve的启动参数、内存与 KV Cache 观测、热词hotword行为、/v1/audio/transcriptions端点用法以及上线前必须明确的运维边界。读完本文你将掌握如何复现该验证、如何依据目标 GPU 正确配置服务参数以及哪些结论可以推广、哪些结论绝不能照搬。验证记录的性质与适用边界先明确这份记录的角色定位它是一次兼容性与并发探针compatibility and concurrency probe不是准确率基准accuracy benchmark也不是生产容量承诺production capacity claim。验证日期为 2026-08-13。这一点在仓库中还被专门约束为测试契约tests/test_vllm_model_source_docs.py 中的test_documentation_hub_keeps_official_and_historical_native_entries_separate等用例要求文档站始终把「官方原生验证」与「历史社区原生验证」作为两条独立记录维护不允许混用时间数据。这也解释了为什么仓库同时存在两份性质不同的原生 vLLM 记录记录权重来源验证日期文档路径历史社区原生 vLLM 验证本文主体社区转换权重allendou/Fun-ASR-Nano-2512-vllm2026-08-13docs/vllm_native_funasr_validation.md官方原生 vLLM 验证官方快照FunAudioLLM/Fun-ASR-Nano-2512-vllm2026-09-07docs/vllm_official_native_validation.md两者的耗时数据互不通用官方记录明确声明「不是对历史耗时的重新标注也不代表速度提升的证据」。因此阅读本文的所有时间数字时请始终记住它们只属于当时那份社区转换权重与那一台 H100 环境。固定软件栈Pinned Stack把环境锁死的意义验证记录给出了完整的环境快照这是「可复现」的前提GPUNVIDIA H100 80GB HBM3驱动 550.127.08vLLM0.27.1cu129官方 x86_64 发布 wheelwheel SHA-256 为bf0d52faa2a51e7a01c6856a7a8a2d1307fd0ff711415d34168a67ffac0fa47bTorch2.13.0cu129CUDA 可用模型allendou/Fun-ASR-Nano-2512-vllmrevisione718b36e2578203ec893e9b488239225f8d668e2权重 SHA-256 为96dfbec48282dd24d3334369a01e9e909f321ee39a1b0003c528c5379f68c1a6音频依赖av 18.1.0、scipy 1.18.0、soundfile 0.14.0、soxr 1.1.0为什么这份清单如此强调 SHA-256 而不是只写版本号因为allendou/Fun-ASR-Nano-2512-vllm是社区转换的完整权重包不属于官方 FunAudioLLM 组织的发布物。vLLM 侧的原生FunASRForConditionalGeneration架构、转录端点、热词支持和初始化修复都是上游 vLLM 的能力但被加载的 checkpoint 不是官方权重发布。需要官方权重链路时应改用 官方 split-engine 指南对应FunAudioLLM/Fun-ASR-Nano-2512AutoModelVLLM的分体引擎路径或者官方原生快照验证记录 docs/vllm_official_native_validation.md。关于版本依赖docs/vllm_guide.md 还提醒了一个常见误区不同 vLLM 发布版声明的依赖三元组并不通用例如 0.19.1 声明torch2.10.0、torchaudio2.10.0、torchvision0.25.0而 0.27.1 声明torch2.13.0、torchaudio2.11.0、torchvision0.28.0。这些只是声明约束不是安装成功的证明不要在已验证的环境中单独升级 torch/torchaudio升级应在全新环境重做验证。启动原生 vLLM 转录服务验证使用的启动命令如下CUDA_VISIBLE_DEVICES0 .venv/bin/vllm serve \ allendou/Fun-ASR-Nano-2512-vllm \ --revision e718b36e2578203ec893e9b488239225f8d668e2 \ --served-model-name fun-asr-nano \ --host 127.0.0.1 --port 8899 \ --dtype float32 \ --gpu-memory-utilization 0.40 \ --enforce-eager逐个参数说明其作用与依据CUDA_VISIBLE_DEVICES0选择 GPU 0单卡机器不必设置多卡机器据此隔离进程详见 docs/vllm_guide.md 对CUDA_VISIBLE_DEVICES的说明。--revision把权重锁定在验证时使用的确切 commit避免后续仓库更新破坏复现性。--served-model-name fun-asr-nano对外暴露的模型名将出现在/v1/models与转录请求的model字段中。--host 127.0.0.1 --port 8899仅监听回环地址这是验证与推荐的默认做法暴露公网前必须经过网关。--dtype float32服务整体以 FP32 计算。FAQ 中说明若改用fp16音频前端与适配器保持 float16但 Qwen3 解码器会被 FunASR 自动切到 bfloat16因为 vLLM 的 float16 解码可能产生劣化的重复输出在不支持 BF16 的硬件上应使用fp32。相关解析逻辑见 funasr/models/fun_asr_nano/inference_vllm.py 的_resolve_vllm_dtype。--gpu-memory-utilization 0.40给 vLLM 的显存占比。这是本环境下的取值不是普适值详见下文内存观测。--enforce-eager禁用 CUDA Graph便于调试与稳定复现。引擎启动后的观测记录显示引擎成功解析了FunASRForConditionalGeneration架构保留 40,960 的最大模型长度resolved max model length分配了17.52 GiB 的 KV Cache对应 82,016 tokens并在该长度下报告2.00x 的最大并发度。第二次启动缓存命中在引擎 profile、KV Cache 创建与 warmup 上耗时 20.30 秒。所有 API 请求都只在/health返回 HTTP 200 之后才发送——这是启动就绪的判定标准。一个典型的显存配置教训记录明确指出--gpu-memory-utilization 0.20对于完整模型长度是不足的——它只为 KV Cache 留下 1.70 GiB而单条 40,960 token 的请求就需要 8.75 GiB。因此不要盲目照抄 0.40 这个数值应根据目标 GPU 与负载规模来设定。正确做法是先用目标 GPU 上实际会出现的最大输入长度做一次内存测算再为 KV Cache 预留足够余量。这也与 docs/vllm_guide.md 中「本文档不承诺普适的显存下限或并发容量」的表述一致。输入与结果三个探针的完整记录所有计时都是服务健康后的客户端墙钟时间localhost包含音频加载、模型执行与解码不包含模型下载与服务器启动时间。探针输入结果中文基线6 秒example/zh.mp3SHA-2560e64de19e4ff9a02e682955c9112f32d2317cfdbb5bc2f3504664044c993f195HTTP 200耗时 0.968 s开饭时间早上九点至下午五点。中文热词同一输入hotwords开放时间,开放时间,开放时间HTTP 200耗时 0.214 s开放时间早上九点至下午五点。双并发请求8 秒英文 8 秒日文示例均 HTTP 200总墙钟 1.123 s英文 1.036 s日文 1.111 s英文结果为The tribal chieftain called for the boy, and presented him with fifty pieces of gold.日文结果为うちの中学は弁当制で、持っていけない場合は、五十円の学校販売のパンを買う。curl等价请求形如对应官方验证记录中的完整请求格式curl --max-time 45 -fsS http://127.0.0.1:8899/v1/audio/transcriptions \ -F fileexample/zh.mp3;typeaudio/mpeg \ -F modelfun-asr-nano -F languagezh -F response_formatjson需要特别提醒的是这些耗时是单次观测值不是延迟分布更不是吞吐或容量证据官方验证记录甚至比本文的社区记录更严格地标注了「首个中文请求未预热」。热词行为能到达生成 prompt但不是确定性纠错记录中一个很有价值的观察是热词的「剂量效应」单个开放时间热词没有改变基线输出仍是开饭时间…重复三次开放时间,开放时间,开放时间之后歧义短语被改写为开放时间早上九点至下午五点。这证明了请求参数确实到达了生成 prompt但同时也说明热词强度是一种需要在代表性音频上验证的策略而不是确定性的纠错机制。从源码层面可以进一步理解热词进入 prompt 的路径在 funasr/models/fun_asr_nano/inference_vllm.py 的_build_prompt_text中热词会被拼进上下文提示语**上下文信息**与热词列表[...]随后_build_input_embeds将其与|startofspeech|/|endofspeech|标记、system prompt 一起编码为文本嵌入与音频适配器输出拼接后以EmbedsPrompt(prompt_embedsinput_embeds.float())提交给 vLLM见 inference_vllm.py。也就是说热词本质上是「提示工程」层面的干预它影响解码先验但不保证改写任何具体发音。这与官方验证记录中「保留基线错误、重复热词改变了该样本的输出、并非通用热词策略」的表述互为印证。双并发请求的意义双并发英文 日文同时到达全部返回 200且与串行请求的文本一致。这只是一个功能性并发探针验证引擎在并发调度下不会出错而不是证明它能支撑多少并发会话。并发容量取决于同时说话人数、静音占比、话语长度、GPU 容量等因素不存在普适的「支持 N 连接」数字。操作边界Operational Boundaries验证记录给出了四条上线前必须遵守的边界每一条都对应真实的踩坑点安装vllm[audio]音频扩展。缺少 audio extra 时合法的 MP3 上传会返回 HTTP 400Invalid or unsupported audio file。这与官方验证记录使用 multipartaudio/mpegMIME、依赖 av/soundfile/scipy/soxr 的音频解码链路一致。非英文音频必须显式传language。当前 vLLM FunASR 适配器在省略语言参数时默认按英文处理这会导致非英文音频的转写质量下降。仓库中的语言别名映射zh→中文、en→英文、ja→日文、ko→韩文见 inference_vllm.py。服务进程保持私密认证、TLS、限流、音频大小/时长限制全部放在网关层。vLLM 原生服务本身不提供这些能力docs/vllm_guide.md 也强调原生 HTTP API 不继承 FunASR WebSocket 服务的 VAD、partial 预览、会话状态与 SPK 处理。必须在真实的生产 GPU、驱动、语言与流量分布上重新运行准确率、延迟、并发、内存与热词测试。历史观测不等于当前部署的性能承诺。与其他服务形态的边界关系理解这份验证记录还需明确它与仓库中其他 ASR 服务形态的边界这也是 docs/vllm_guide.md 与 docs/model_selection.md 反复强调的原生 vLLM 转录本文vllm serve提供/v1/audio/transcriptions的请求/响应式转录不注册/v1/realtime。vLLM 只为声明了 realtime 任务的模型注册该 WebSocket 端点而FunASRForConditionalGeneration不在其中。FunASR split-engine分体引擎使用官方FunAudioLLM/Fun-ASR-Nano-2512权重通过AutoModelVLLM加载音频编码在 PyTorch 侧、解码在 vLLM 侧支持离线批处理与serve_vllm.py/serve_realtime_ws.py服务详见 docs/vllm_guide.md。实时流式需求应使用 FunASR 流式 SDK 推理或流式 ASR 服务而不是原生 vLLM 端点。model_selection.md中的选型表把这一点总结得很清楚见 docs/model_selection.mdsplit-engine 与原生 vLLM 使用不同的加载契约与不同的 checkpoint 布局AutoModelVLLM期望model.pt、config.yaml与Qwen3-0.6B/目录而原生路径期望完整的 safetensors 布局两者不能互换。延伸阅读与仓库证据完整的 vLLM 分体引擎指南安装、架构、SDK、服务docs/vllm_guide.md官方原生 vLLM 验证记录官方快照、启动参数、原始响应哈希docs/vllm_official_native_validation.md 及配套机器可读元数据 docs/benchmark/vllm_official_native_20260907.json模型选型表区分三条 vLLM 路径docs/model_selection.md原生引擎源码FunASRNanoVLLM的加载、prompt 构建与批量编码逻辑见 funasr/models/fun_asr_nano/inference_vllm.pyrepetition_penalty在 prompt-embeds 模式下的中性化处理见 funasr/models/fun_asr_nano/vllm_utils.pyEmbedsPrompt 模式下没有可惩罚的 prompt token ID非 1.0 的值会触发 CUDA scatter 越界断言源码会强制回退为 1.0 并告警文档契约测试区分官方/社区验证记录、约束原生路径边界的测试见 tests/test_vllm_model_source_docs.py最后再强调一次这份验证记录的阅读姿势把它当作「在固定软硬件栈上的一次可复现的兼容性探针」。环境锁得越死、边界划得越清这份记录对生产部署的参考价值就越大而任何脱离固定栈的性能外推都超出了这份文档的承诺范围。【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
FunASR 在 vLLM 0.27.1 上的原生部署验证从兼容性探针到生产边界【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASRFunASR 仓库中记录的vllm_native_funasr_validation.md是一份针对 Fun-ASR-Nano 模型在 vLLM 原生FunASRForConditionalGeneration架构下的一次可复现兼容性与并发探针记录。本文以此验证记录为主体结合仓库中的 vLLM 使用指南、源码实现与配套测试系统讲解 vLLM 原生转录服务vllm serve的启动参数、内存与 KV Cache 观测、热词hotword行为、/v1/audio/transcriptions端点用法以及上线前必须明确的运维边界。读完本文你将掌握如何复现该验证、如何依据目标 GPU 正确配置服务参数以及哪些结论可以推广、哪些结论绝不能照搬。验证记录的性质与适用边界先明确这份记录的角色定位它是一次兼容性与并发探针compatibility and concurrency probe不是准确率基准accuracy benchmark也不是生产容量承诺production capacity claim。验证日期为 2026-08-13。这一点在仓库中还被专门约束为测试契约tests/test_vllm_model_source_docs.py 中的test_documentation_hub_keeps_official_and_historical_native_entries_separate等用例要求文档站始终把「官方原生验证」与「历史社区原生验证」作为两条独立记录维护不允许混用时间数据。这也解释了为什么仓库同时存在两份性质不同的原生 vLLM 记录记录权重来源验证日期文档路径历史社区原生 vLLM 验证本文主体社区转换权重allendou/Fun-ASR-Nano-2512-vllm2026-08-13docs/vllm_native_funasr_validation.md官方原生 vLLM 验证官方快照FunAudioLLM/Fun-ASR-Nano-2512-vllm2026-09-07docs/vllm_official_native_validation.md两者的耗时数据互不通用官方记录明确声明「不是对历史耗时的重新标注也不代表速度提升的证据」。因此阅读本文的所有时间数字时请始终记住它们只属于当时那份社区转换权重与那一台 H100 环境。固定软件栈Pinned Stack把环境锁死的意义验证记录给出了完整的环境快照这是「可复现」的前提GPUNVIDIA H100 80GB HBM3驱动 550.127.08vLLM0.27.1cu129官方 x86_64 发布 wheelwheel SHA-256 为bf0d52faa2a51e7a01c6856a7a8a2d1307fd0ff711415d34168a67ffac0fa47bTorch2.13.0cu129CUDA 可用模型allendou/Fun-ASR-Nano-2512-vllmrevisione718b36e2578203ec893e9b488239225f8d668e2权重 SHA-256 为96dfbec48282dd24d3334369a01e9e909f321ee39a1b0003c528c5379f68c1a6音频依赖av 18.1.0、scipy 1.18.0、soundfile 0.14.0、soxr 1.1.0为什么这份清单如此强调 SHA-256 而不是只写版本号因为allendou/Fun-ASR-Nano-2512-vllm是社区转换的完整权重包不属于官方 FunAudioLLM 组织的发布物。vLLM 侧的原生FunASRForConditionalGeneration架构、转录端点、热词支持和初始化修复都是上游 vLLM 的能力但被加载的 checkpoint 不是官方权重发布。需要官方权重链路时应改用 官方 split-engine 指南对应FunAudioLLM/Fun-ASR-Nano-2512AutoModelVLLM的分体引擎路径或者官方原生快照验证记录 docs/vllm_official_native_validation.md。关于版本依赖docs/vllm_guide.md 还提醒了一个常见误区不同 vLLM 发布版声明的依赖三元组并不通用例如 0.19.1 声明torch2.10.0、torchaudio2.10.0、torchvision0.25.0而 0.27.1 声明torch2.13.0、torchaudio2.11.0、torchvision0.28.0。这些只是声明约束不是安装成功的证明不要在已验证的环境中单独升级 torch/torchaudio升级应在全新环境重做验证。启动原生 vLLM 转录服务验证使用的启动命令如下CUDA_VISIBLE_DEVICES0 .venv/bin/vllm serve \ allendou/Fun-ASR-Nano-2512-vllm \ --revision e718b36e2578203ec893e9b488239225f8d668e2 \ --served-model-name fun-asr-nano \ --host 127.0.0.1 --port 8899 \ --dtype float32 \ --gpu-memory-utilization 0.40 \ --enforce-eager逐个参数说明其作用与依据CUDA_VISIBLE_DEVICES0选择 GPU 0单卡机器不必设置多卡机器据此隔离进程详见 docs/vllm_guide.md 对CUDA_VISIBLE_DEVICES的说明。--revision把权重锁定在验证时使用的确切 commit避免后续仓库更新破坏复现性。--served-model-name fun-asr-nano对外暴露的模型名将出现在/v1/models与转录请求的model字段中。--host 127.0.0.1 --port 8899仅监听回环地址这是验证与推荐的默认做法暴露公网前必须经过网关。--dtype float32服务整体以 FP32 计算。FAQ 中说明若改用fp16音频前端与适配器保持 float16但 Qwen3 解码器会被 FunASR 自动切到 bfloat16因为 vLLM 的 float16 解码可能产生劣化的重复输出在不支持 BF16 的硬件上应使用fp32。相关解析逻辑见 funasr/models/fun_asr_nano/inference_vllm.py 的_resolve_vllm_dtype。--gpu-memory-utilization 0.40给 vLLM 的显存占比。这是本环境下的取值不是普适值详见下文内存观测。--enforce-eager禁用 CUDA Graph便于调试与稳定复现。引擎启动后的观测记录显示引擎成功解析了FunASRForConditionalGeneration架构保留 40,960 的最大模型长度resolved max model length分配了17.52 GiB 的 KV Cache对应 82,016 tokens并在该长度下报告2.00x 的最大并发度。第二次启动缓存命中在引擎 profile、KV Cache 创建与 warmup 上耗时 20.30 秒。所有 API 请求都只在/health返回 HTTP 200 之后才发送——这是启动就绪的判定标准。一个典型的显存配置教训记录明确指出--gpu-memory-utilization 0.20对于完整模型长度是不足的——它只为 KV Cache 留下 1.70 GiB而单条 40,960 token 的请求就需要 8.75 GiB。因此不要盲目照抄 0.40 这个数值应根据目标 GPU 与负载规模来设定。正确做法是先用目标 GPU 上实际会出现的最大输入长度做一次内存测算再为 KV Cache 预留足够余量。这也与 docs/vllm_guide.md 中「本文档不承诺普适的显存下限或并发容量」的表述一致。输入与结果三个探针的完整记录所有计时都是服务健康后的客户端墙钟时间localhost包含音频加载、模型执行与解码不包含模型下载与服务器启动时间。探针输入结果中文基线6 秒example/zh.mp3SHA-2560e64de19e4ff9a02e682955c9112f32d2317cfdbb5bc2f3504664044c993f195HTTP 200耗时 0.968 s开饭时间早上九点至下午五点。中文热词同一输入hotwords开放时间,开放时间,开放时间HTTP 200耗时 0.214 s开放时间早上九点至下午五点。双并发请求8 秒英文 8 秒日文示例均 HTTP 200总墙钟 1.123 s英文 1.036 s日文 1.111 s英文结果为The tribal chieftain called for the boy, and presented him with fifty pieces of gold.日文结果为うちの中学は弁当制で、持っていけない場合は、五十円の学校販売のパンを買う。curl等价请求形如对应官方验证记录中的完整请求格式curl --max-time 45 -fsS http://127.0.0.1:8899/v1/audio/transcriptions \ -F fileexample/zh.mp3;typeaudio/mpeg \ -F modelfun-asr-nano -F languagezh -F response_formatjson需要特别提醒的是这些耗时是单次观测值不是延迟分布更不是吞吐或容量证据官方验证记录甚至比本文的社区记录更严格地标注了「首个中文请求未预热」。热词行为能到达生成 prompt但不是确定性纠错记录中一个很有价值的观察是热词的「剂量效应」单个开放时间热词没有改变基线输出仍是开饭时间…重复三次开放时间,开放时间,开放时间之后歧义短语被改写为开放时间早上九点至下午五点。这证明了请求参数确实到达了生成 prompt但同时也说明热词强度是一种需要在代表性音频上验证的策略而不是确定性的纠错机制。从源码层面可以进一步理解热词进入 prompt 的路径在 funasr/models/fun_asr_nano/inference_vllm.py 的_build_prompt_text中热词会被拼进上下文提示语**上下文信息**与热词列表[...]随后_build_input_embeds将其与|startofspeech|/|endofspeech|标记、system prompt 一起编码为文本嵌入与音频适配器输出拼接后以EmbedsPrompt(prompt_embedsinput_embeds.float())提交给 vLLM见 inference_vllm.py。也就是说热词本质上是「提示工程」层面的干预它影响解码先验但不保证改写任何具体发音。这与官方验证记录中「保留基线错误、重复热词改变了该样本的输出、并非通用热词策略」的表述互为印证。双并发请求的意义双并发英文 日文同时到达全部返回 200且与串行请求的文本一致。这只是一个功能性并发探针验证引擎在并发调度下不会出错而不是证明它能支撑多少并发会话。并发容量取决于同时说话人数、静音占比、话语长度、GPU 容量等因素不存在普适的「支持 N 连接」数字。操作边界Operational Boundaries验证记录给出了四条上线前必须遵守的边界每一条都对应真实的踩坑点安装vllm[audio]音频扩展。缺少 audio extra 时合法的 MP3 上传会返回 HTTP 400Invalid or unsupported audio file。这与官方验证记录使用 multipartaudio/mpegMIME、依赖 av/soundfile/scipy/soxr 的音频解码链路一致。非英文音频必须显式传language。当前 vLLM FunASR 适配器在省略语言参数时默认按英文处理这会导致非英文音频的转写质量下降。仓库中的语言别名映射zh→中文、en→英文、ja→日文、ko→韩文见 inference_vllm.py。服务进程保持私密认证、TLS、限流、音频大小/时长限制全部放在网关层。vLLM 原生服务本身不提供这些能力docs/vllm_guide.md 也强调原生 HTTP API 不继承 FunASR WebSocket 服务的 VAD、partial 预览、会话状态与 SPK 处理。必须在真实的生产 GPU、驱动、语言与流量分布上重新运行准确率、延迟、并发、内存与热词测试。历史观测不等于当前部署的性能承诺。与其他服务形态的边界关系理解这份验证记录还需明确它与仓库中其他 ASR 服务形态的边界这也是 docs/vllm_guide.md 与 docs/model_selection.md 反复强调的原生 vLLM 转录本文vllm serve提供/v1/audio/transcriptions的请求/响应式转录不注册/v1/realtime。vLLM 只为声明了 realtime 任务的模型注册该 WebSocket 端点而FunASRForConditionalGeneration不在其中。FunASR split-engine分体引擎使用官方FunAudioLLM/Fun-ASR-Nano-2512权重通过AutoModelVLLM加载音频编码在 PyTorch 侧、解码在 vLLM 侧支持离线批处理与serve_vllm.py/serve_realtime_ws.py服务详见 docs/vllm_guide.md。实时流式需求应使用 FunASR 流式 SDK 推理或流式 ASR 服务而不是原生 vLLM 端点。model_selection.md中的选型表把这一点总结得很清楚见 docs/model_selection.mdsplit-engine 与原生 vLLM 使用不同的加载契约与不同的 checkpoint 布局AutoModelVLLM期望model.pt、config.yaml与Qwen3-0.6B/目录而原生路径期望完整的 safetensors 布局两者不能互换。延伸阅读与仓库证据完整的 vLLM 分体引擎指南安装、架构、SDK、服务docs/vllm_guide.md官方原生 vLLM 验证记录官方快照、启动参数、原始响应哈希docs/vllm_official_native_validation.md 及配套机器可读元数据 docs/benchmark/vllm_official_native_20260907.json模型选型表区分三条 vLLM 路径docs/model_selection.md原生引擎源码FunASRNanoVLLM的加载、prompt 构建与批量编码逻辑见 funasr/models/fun_asr_nano/inference_vllm.pyrepetition_penalty在 prompt-embeds 模式下的中性化处理见 funasr/models/fun_asr_nano/vllm_utils.pyEmbedsPrompt 模式下没有可惩罚的 prompt token ID非 1.0 的值会触发 CUDA scatter 越界断言源码会强制回退为 1.0 并告警文档契约测试区分官方/社区验证记录、约束原生路径边界的测试见 tests/test_vllm_model_source_docs.py最后再强调一次这份验证记录的阅读姿势把它当作「在固定软硬件栈上的一次可复现的兼容性探针」。环境锁得越死、边界划得越清这份记录对生产部署的参考价值就越大而任何脱离固定栈的性能外推都超出了这份文档的承诺范围。【免费下载链接】FunASROpen-source speech recognition toolkit for training, inference, streaming ASR, VAD, punctuation, speaker diarization pipelines, and OpenAI-compatible/MCP serving.项目地址: https://gitcode.com/GitHub_Trending/fun/FunASR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
