Qwen3-ASR-1.7B与Dify平台集成：打造个性化语音识别应用

Qwen3-ASR-1.7B与Dify平台集成：打造个性化语音识别应用

最近在折腾一个智能客服的项目，需要把语音对话转成文字，市面上开源的语音识别模型试了一圈，效果总是不太理想。要么是识别不准，要么是部署太麻烦，要么就是对中文支持不够好。直到我发现了阿里开源的Qwen3-ASR-1.7B，试了一下效果确实不错，特别是对中文和方言的支持，比之前用的Whisper系列要好不少。

但光有模型还不够，怎么把它变成一个能用的服务呢？这时候我想到了Dify这个平台。Dify是个低代码的AI应用开发平台，能帮你快速把各种AI模型包装成API服务，还自带Web界面。把Qwen3-ASR集成到Dify里，不就能快速搭建一个语音识别应用了吗？

今天我就来分享一下这个完整的集成过程，从模型部署到API封装，再到前端展示，一步步带你打造一个个性化的语音识别应用。

1. 为什么选择Qwen3-ASR-1.7B？

在开始动手之前，先简单说说为什么我选了Qwen3-ASR-1.7B。用了一段时间，感觉它有这几个特点特别实用：

多语言支持很全面：这个模型能识别30种语言，还有22种中文方言。对我们做中文应用来说，这意味着它能听懂广东话、四川话这些方言，甚至还能识别带口音的普通话。之前用其他模型，遇到带口音的音频就经常识别错误，这个模型在这方面表现好很多。

识别准确率不错：特别是在复杂环境下，比如有背景音乐、噪音比较大的情况，它还能保持比较稳定的识别效果。我试过把一段有背景音乐的中文歌曲给它识别，准确率能达到85%以上，这已经相当不错了。

支持流式识别：这个功能对实时应用特别有用。比如做语音转文字的实时字幕，或者语音助手，音频是一段段传过来的，模型能边听边识别，不用等整个音频传完。Qwen3-ASR支持流式推理，延迟控制得比较好。

模型大小适中：1.7B的参数规模，在现在的硬件上跑起来压力不大。我用一张RTX 3060的显卡就能跑，显存占用大概在4-5GB左右。如果对速度要求更高，还可以用0.6B的版本，那个更轻量。

开源生态完整：阿里不仅开源了模型权重，还提供了完整的推理框架，支持vLLM加速、异步服务这些功能。这意味着部署起来会方便很多，不用自己从头写推理代码。

2. 环境准备与模型部署

要集成到Dify，首先得把Qwen3-ASR模型跑起来。我选择用vLLM来部署，因为vLLM的推理效率比较高，还支持流式输出。

2.1 基础环境搭建

我用的是一台Ubuntu 20.04的服务器，显卡是RTX 3060 12GB。如果你的环境不一样，可能需要调整一些步骤。

# 创建虚拟环境 python -m venv qwen_asr_env source qwen_asr_env/bin/activate # 安装基础依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install modelscope

这里要注意PyTorch的版本，Qwen3-ASR需要PyTorch 2.0以上版本。如果你的显卡比较老，可能需要用老一点的PyTorch版本。

2.2 下载模型

模型可以从ModelScope或者HuggingFace下载，国内用户用ModelScope会快一些：

# 设置缓存路径（可选） export MODELSCOPE_CACHE=/path/to/your/cache # 下载模型 python -c "from modelscope import snapshot_download; snapshot_download('Qwen/Qwen3-ASR-1.7B')"

下载完成后，模型会保存在~/.cache/modelscope/hub/Qwen/Qwen3-ASR-1.7B目录下。整个模型大概3.5GB左右，下载需要一些时间。

2.3 使用vLLM部署服务

vLLM是专门为大语言模型推理优化的框架，对Qwen3-ASR支持得不错：

# 安装vLLM和Qwen3-ASR推理包 pip install vllm pip install qwen-asr[vllm] # 启动服务 qwen-asr-serve Qwen/Qwen3-ASR-1.7B \ --gpu-memory-utilization 0.8 \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 4096

这个命令会启动一个HTTP服务，监听在8000端口。--gpu-memory-utilization 0.8表示使用80%的显存，你可以根据自己显卡的情况调整。

服务启动后，可以用下面的代码测试一下：

import requests import json url = "http://localhost:8000/v1/chat/completions" headers = {"Content-Type": "application/json"} # 准备测试音频（这里用了一个公开的测试音频URL） data = { "messages": [ { "role": "user", "content": [ { "type": "audio_url", "audio_url": { "url": "https://qianwen-res.oss-cn-beijing.aliyuncs.com/Qwen3-ASR-Repo/asr_en.wav" } } ] } ] } response = requests.post(url, headers=headers, json=data, timeout=300) result = response.json() print("识别结果：") print(result['choices'][0]['message']['content'])

如果一切正常，你会看到类似这样的输出：

识别结果： language: English text: This is a test audio for speech recognition.

3. 在Dify中创建语音识别应用

现在模型服务已经跑起来了，接下来就是把它集成到Dify里。Dify是个可视化的AI应用开发平台，能帮你快速搭建AI应用，不用写太多代码。

3.1 创建新的Dify应用

首先登录Dify平台（我用的社区版），创建一个新的应用：

1. 点击"创建新应用"
2. 选择"对话型应用"（语音识别本质上也是对话，用户输入音频，AI返回文字）
3. 给应用起个名字，比如"智能语音识别"
4. 选择工作流模式，这样后面可以自定义处理逻辑

3.2 配置模型连接

在应用设置里，需要配置模型连接。Dify支持通过API连接外部模型服务：

1. 进入"模型供应商"设置
2. 选择"自定义API"
3. 填写API信息：
   • 基础URL：http://localhost:8000/v1（就是刚才启动的vLLM服务地址）
   • API密钥：可以留空，因为本地服务不需要认证
   • 模型名称：填写Qwen3-ASR-1.7B

这里有个小技巧：Dify默认的对话API格式和vLLM的格式可能不太一样，需要在"高级设置"里调整一下请求体格式。不过Qwen3-ASR的vLLM服务兼容OpenAI的API格式，所以直接用Dify的OpenAI配置就行。

3.3 设计工作流

工作流是Dify的核心功能，可以定义整个处理流程。对于语音识别应用，我设计了这样一个流程：

用户上传音频 → 检查音频格式 → 调用Qwen3-ASR API → 处理识别结果 → 返回文字

具体操作步骤：

1. 在工作流编辑器中，拖入一个"开始"节点
2. 添加一个"代码"节点，用来检查音频文件格式
3. 添加一个"LLM"节点，配置为调用Qwen3-ASR服务
4. 添加一个"文本处理"节点，清理和格式化识别结果
5. 最后用"结束"节点返回结果

在"LLM"节点的配置里，关键是要设置正确的提示词。虽然Qwen3-ASR是语音识别模型，但通过vLLM服务调用时，还是需要按照对话格式来：

用户上传了一段音频，请将音频内容转写成文字。 音频文件：{{audio_file}}

这里的{{audio_file}}是一个变量，会在运行时替换成实际的音频文件。

3.4 处理音频上传

Dify本身支持文件上传，但需要做一些配置才能处理音频文件：

1. 在应用设置的"功能"标签页，开启"文件上传"功能
2. 设置允许的文件类型：.wav,.mp3,.m4a等常见音频格式
3. 设置文件大小限制，根据你的需求来，一般10-50MB够用了

然后在工作流中，可以通过{{#context.files}}来获取用户上传的文件。需要写一段Python代码来处理音频文件，比如转换成base64编码或者上传到临时存储：

def handle_audio_file(files): """处理上传的音频文件""" if not files: return None audio_file = files[0] # 检查文件类型 if not audio_file.filename.lower().endswith(('.wav', '.mp3', '.m4a', '.ogg')): return "错误：只支持wav、mp3、m4a、ogg格式的音频文件" # 这里可以将文件保存到临时位置，或者直接处理 # 如果是本地部署，可以直接用文件路径 # 如果是云端部署，可能需要上传到对象存储 return audio_file.url # 返回文件访问URL

4. 实现流式语音识别

对于实时语音识别场景，流式处理很重要。比如做语音转文字的字幕，或者语音助手，用户一边说话，一边就能看到识别结果。

4.1 配置流式输出

Qwen3-ASR支持流式推理，vLLM也支持流式响应。在Dify中配置流式输出：

1. 在LLM节点设置中，开启"流式响应"选项
2. 在工作流输出设置中，选择"流式输出"

这样当用户上传音频时，识别结果会一个字一个字地显示出来，体验更好。

4.2 前端界面优化

Dify可以自定义Web界面，我调整了一下界面，让它更适合语音识别应用：

1. 在"应用外观"设置中，上传一个麦克风图标作为应用图标
2. 修改欢迎语，提示用户上传音频文件或直接录音
3. 添加一个录音按钮（需要浏览器支持Web API）

对于录音功能，需要在前端添加一些JavaScript代码：

// 简单的录音功能示例 class AudioRecorder { constructor() { this.mediaRecorder = null; this.audioChunks = []; } async startRecording() { try { const stream = await navigator.mediaDevices.getUserMedia({ audio: true }); this.mediaRecorder = new MediaRecorder(stream); this.audioChunks = []; this.mediaRecorder.ondataavailable = (event) => { this.audioChunks.push(event.data); }; this.mediaRecorder.start(); return true; } catch (error) { console.error("录音失败:", error); return false; } } stopRecording() { return new Promise((resolve) => { this.mediaRecorder.onstop = () => { const audioBlob = new Blob(this.audioChunks, { type: 'audio/wav' }); resolve(audioBlob); }; this.mediaRecorder.stop(); }); } }

这段代码实现了基本的录音功能，用户可以在网页上直接录音，然后自动上传识别。

5. 实际应用效果测试

部署完成后，我测试了几个不同的场景，看看实际效果怎么样。

5.1 普通话识别测试

我录了一段普通话的测试音频："今天天气不错，我们出去散步吧"。模型准确识别出来了，连标点符号都加上了。这点比很多其他模型要好，有些模型识别出来的文字没有标点，读起来很费劲。

5.2 方言识别测试

作为一个四川人，我特意用四川话测试了一下："你吃饭没得？"。模型识别成了"你吃饭没有？"，虽然"没得"变成了"没有"，但意思完全正确，这个表现已经很不错了。

5.3 英语识别测试

英文识别效果也很好，我用了带一点口音的英语测试，模型还是能准确识别。Qwen3-ASR支持多种英语口音，这对国际化应用很有帮助。

5.4 实时流式识别测试

我测试了实时录音转文字的功能，说一句话，基本上说完1-2秒后文字就出来了。延迟在可接受范围内，做实时字幕或者语音助手够用了。

5.5 长音频处理测试

我上传了一个15分钟的会议录音，模型处理了大约30秒返回结果。识别准确率大概在90%左右，有些人名和专业术语识别错了，但整体内容都能看懂。

6. 性能优化与成本控制

在实际使用中，我发现了一些可以优化和改进的地方。

6.1 模型选择建议

Qwen3-ASR有1.7B和0.6B两个版本，怎么选呢？

• 1.7B版本：准确率更高，特别是对复杂音频和方言的支持更好。适合对准确率要求高的场景，比如会议记录、字幕生成。
• 0.6B版本：速度更快，资源占用更少。128并发下能达到2000倍吞吐，10秒处理5小时音频。适合对实时性要求高、并发量大的场景，比如直播字幕、语音助手。

如果你的显卡显存足够（8GB以上），建议用1.7B版本。如果资源有限或者需要高并发，用0.6B版本。

6.2 缓存优化

对于重复的音频或者相似的音频，可以加一层缓存。比如用户上传了一个音频，识别完成后把结果缓存起来，下次同样的音频直接返回缓存结果，不用再调用模型。

在Dify中可以通过"变量"功能实现简单的缓存，或者用外部的Redis缓存。

6.3 批量处理

如果需要处理大量音频文件，可以做成批量处理模式。Dify的工作流可以触发，写一个脚本批量上传音频，然后收集识别结果。

import os import requests def batch_process_audio(folder_path, dify_api_url, api_key): """批量处理音频文件""" results = [] for filename in os.listdir(folder_path): if filename.endswith(('.wav', '.mp3')): file_path = os.path.join(folder_path, filename) # 上传到Dify应用 with open(file_path, 'rb') as f: files = {'file': (filename, f, 'audio/wav')} response = requests.post( dify_api_url, files=files, headers={'Authorization': f'Bearer {api_key}'} ) if response.status_code == 200: result = response.json() results.append({ 'file': filename, 'text': result.get('text', ''), 'language': result.get('language', '') }) return results

6.4 成本估算

自己部署模型的成本主要是：

1. 服务器成本：如果用云服务器，带GPU的实例大概每月500-2000元，取决于显卡型号
2. 电费成本：如果用自己的机器，主要考虑电费
3. 维护成本：需要定期更新、监控服务状态

相比使用商业API（比如按分钟收费的语音识别服务），自己部署的长期成本会更低，特别是使用量大的时候。而且数据完全在自己掌控中，对隐私要求高的场景很合适。

7. 遇到的问题和解决方案

在集成过程中，我遇到了一些问题，这里分享一下解决方案。

7.1 音频格式问题

Qwen3-ASR对音频格式有一定要求，最好是16kHz采样率的单声道WAV文件。如果用户上传的是MP3或者其他格式，需要先转换。

我写了一个预处理函数，用pydub库处理音频格式：

from pydub import AudioSegment import tempfile def preprocess_audio(input_path, output_path=None): """预处理音频文件，转换为模型需要的格式""" if output_path is None: output_path = tempfile.mktemp(suffix='.wav') # 加载音频 audio = AudioSegment.from_file(input_path) # 转换为单声道 if audio.channels > 1: audio = audio.set_channels(1) # 重采样到16kHz if audio.frame_rate != 16000: audio = audio.set_frame_rate(16000) # 保存为WAV格式 audio.export(output_path, format='wav') return output_path

7.2 长音频处理超时

处理很长的音频时（比如超过10分钟），可能会遇到超时问题。Dify默认的请求超时时间可能不够。

解决方案有两个：

1. 调整Dify的超时设置（如果有权限）
2. 把长音频切成短片段，分段识别，最后合并结果

分段识别的代码示例：

def split_long_audio(audio_path, chunk_duration_ms=60000): """将长音频切分成片段""" audio = AudioSegment.from_file(audio_path) chunks = [] for i in range(0, len(audio), chunk_duration_ms): chunk = audio[i:i + chunk_duration_ms] chunk_path = tempfile.mktemp(suffix='.wav') chunk.export(chunk_path, format='wav') chunks.append(chunk_path) return chunks def merge_transcriptions(transcriptions): """合并分段识别结果""" # 简单的合并，可以根据需要添加更智能的合并逻辑 merged_text = ' '.join([t['text'] for t in transcriptions]) return merged_text

7.3 并发性能问题

当多个用户同时使用时，可能会出现并发性能问题。vLLM本身支持并发，但需要合理配置。

在启动服务时，可以调整这些参数：

• --max-num-seqs：最大并发序列数，根据GPU内存调整
• --gpu-memory-utilization：GPU内存利用率，不要设得太满
• --tensor-parallel-size：如果有多张GPU，可以设置张量并行

对于高并发场景，可以考虑用多个vLLM实例，前面加一个负载均衡。

8. 扩展应用场景

这个语音识别应用搭建好后，还可以扩展到更多场景：

8.1 会议记录助手

把语音识别和会议记录结合起来，可以做一个智能会议记录助手：

1. 实时识别会议发言
2. 自动区分不同发言人（需要配合声纹识别）
3. 生成会议纪要
4. 提取会议行动项

8.2 视频字幕生成

结合视频处理，可以自动生成视频字幕：

1. 提取视频中的音频
2. 识别音频内容
3. 生成字幕文件（SRT格式）
4. 自动时间轴对齐（可以用Qwen3-ForcedAligner）

8.3 语音客服质检

用于客服场景的质量检查：

1. 识别客服通话录音
2. 分析通话内容
3. 检查是否使用规范用语
4. 自动评分和反馈

8.4 教育场景应用

在教育领域也有很多应用：

1. 课堂录音转文字
2. 语音作业批改
3. 口语练习评估
4. 听力材料生成

总结

整体用下来，Qwen3-ASR-1.7B和Dify的集成效果还是挺不错的。部署过程比想象中简单，主要是vLLM和Dify的生态都比较成熟，很多问题都有现成的解决方案。

Qwen3-ASR的识别准确率确实可以，特别是对中文和方言的支持，比之前用过的开源模型要好。Dify则大大降低了应用开发的门槛，不用写前后端代码，通过可视化配置就能搭建一个可用的应用。

当然也有一些可以改进的地方。比如音频预处理可以做得更智能一些，自动处理各种格式的音频。性能方面，如果要做高并发服务，可能还需要进一步优化，比如用更高效的推理框架，或者做模型量化。

如果你也想搭建一个语音识别应用，我建议先从简单的开始，把基础功能跑通，然后再慢慢添加高级功能。Qwen3-ASR和Dify的组合是个不错的起点，既有不错的识别效果，又降低了开发难度。

实际部署时要注意资源分配，特别是GPU内存。如果显存不够，可以考虑用0.6B的版本，或者做模型量化。对于生产环境，还要考虑监控、日志、故障恢复这些运维问题。

总的来说，用开源模型和工具搭建AI应用已经越来越可行了。虽然可能没有商业产品那么完善，但自主可控、成本可控，还能根据自己需求定制，这些优势对很多场景来说还是很重要的。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。