已成功配置Dify调用vLLM版Whisper-large-v3语音转写服务：Dify端设32并发、120秒超时与自动重试；vLLM端启用--max-num-seqs 128、--enforce-eager及bfloat16优化，并使用host.docker.internal确保容器网络连通。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
确认Whisper服务已就绪且可被Dify访问
你已在A100或RTX 6000 Ada上成功部署whisper-large-v3的vLLM服务，并监听在http://localhost:8003，现在要让Dify稳定调用它并撑住高并发语音转写请求。
进入Dify控制台「设置→模型供应商→添加模型」，选择「自定义API」类型；模型名称填whisper-vllm-a100，模型类型选asr；Endpoint填http://host.docker.internal:8003/v1/audio/transcriptions——【必须用host.docker.internal而非localhost，否则Docker容器内Dify无法解析宿主机服务】。
勾选「启用流式响应」，不填API Key（vLLM本地服务默认无鉴权）；点击保存后，等待状态变为「已连接」再继续下一步。
配置Dify端ASR节点的并发参数
新建或编辑一个语音处理应用，在「编排→节点管理」中找到Audio-to-Text节点，点击进入配置面板。
将「ASR引擎」下拉菜单切换为刚添加的whisper-vllm-a100；展开「高级设置」，把「最大并发请求数」从默认5改为32——这是A100显存充足（40GB）且vLLM已启用PagedAttention时的安全上限。
「超时时间」设为120秒：音频文件普遍较大，过短会频繁触发timeout错误；同时勾选「启用自动重试」，重试次数设为2，避免单次网络抖动导致整条流水线失败。
调整vLLM服务端的关键启动参数
在部署vLLM服务的终端中，停止当前进程，用以下命令重启服务：
CUDA_VISIBLE_DEVICES=0 vllm serve /models/whisper-large-v3 --served-model-name whisper-large-v3 --task transcription --dtype bfloat16 --swap-space 16 --port 8003 --gpu-memory-utilization 0.7 --max-num-seqs 128 --max-model-len 448 --enforce-eager --api-key sk-dify
其中--max-num-seqs 128是核心：它允许vLLM在同一GPU上并发处理最多128个音频片段（非128路实时流），配合Dify端32并发，能实现4倍吞吐缓冲；【若跳过此步直接调高Dify并发，vLLM会因请求积压触发OOM Killer强制杀进程】。
--enforce-eager禁用CUDA图优化，牺牲约8%推理速度，但大幅提升多路并发下的稳定性，尤其在音频长度差异大（如10秒会议片段 vs 90分钟访谈）时避免context mismatch异常。
验证并发能力与定位瓶颈
第一步：用cURL模拟20路并发请求，每路上传一段15秒MP3音频：
for i in {1..20}; do curl -X POST http://localhost:5001/api/applications/{app_id}/audio-to-text \ -F "file=@sample_$i.mp3" \ -H "Authorization: Bearer {api_key}" & done; wait
第二步：观察Dify后台「监控→API调用统计」中的成功率与P95延迟；同时在vLLM服务端执行nvidia-smi，确认GPU利用率稳定在65%~80%，显存占用不超过36GB。
第三步：若出现大量503错误，立即检查vLLM日志中是否含Out of memory或batch size too large——此时需回到上一步，将--max-num-seqs下调至96并重试。
