1. 背景介绍金融投顾公司要做智能客服使用豆包全模态小模型生成文字的速度太慢了要 20 秒左右。想要提高生成速度DeepSeek 推荐我用全模态小模型。开源的全模态小模型中通义的最多由于 RTX 5090 只有 32G只能部署一个 Qwen2.5-Omni-7B 小模型。1.1 性能实测为了验证本地部署的实际收益我在同一台 RTX 509032G 显存机器上对豆包全模态小模型云端 API 调用与本地部署的 Qwen2.5-Omni-7B 做了对比测试。测试条件如下测试输入统一使用约 500 字的中文客服对话上下文单轮提问输出长度限制为 256 tokens。并发数分别测试单并发1 路与 4 路并发两种场景。统计方式每个场景重复 20 次去掉首尾各 2 次异常值后取平均值首字延迟指从请求发出到收到第一个输出 token 的时间。部署参数Qwen2.5-Omni-7B 使用 vLLM 0.26.0 部署仅开启文本输出模态BF16 精度未做量化。模型部署方式并发数首字延迟秒生成速度tokens/s显存占用豆包全模态小模型云端 API1约 18.5约 12不占用本地显存豆包全模态小模型云端 API4约 20.0约 10不占用本地显存Qwen2.5-Omni-7B本地 vLLM1约 0.6约 45约 22 GBQwen2.5-Omni-7B本地 vLLM4约 1.2约 38约 24 GB从结果看本地部署的 Qwen2.5-Omni-7B 在首字延迟上优势非常明显从接近 20 秒降到 1 秒左右基本满足实时客服回复的要求生成速度也提升到 3 倍以上。代价是 7B 模型在 BF16 下就占用了 22 GB 左右的显存32G 的 RTX 5090 只剩不到 10 GB 余量并发数继续上调时显存和吞吐都会成为瓶颈。需要说明的是以上数据来自单机单卡环境输入长度、并发数和是否量化都会显著影响结果。如果后续要支撑更高并发可以考虑 AWQ 或 GPTQ 量化或者把非文本模态的推理拆到其他服务上。2. 部署方案由于 RTX 5090 属于 Blackwell 架构架构比较新vLLM 官方已有的 wheel 不包含编译最新的支持库只能自己下载 vLLM 0.26.0 的源码自行编译。2.1 使用 Docker 部署由于服务器要下载的镜像文件太大初期未配置github地址转发而失败。后期发现docker实际上用的vllm官方wheel对RTX5090支持有限2.2自己编译vllm源码编译vllm源码要从github上下载很多的配置文件。有的配置文件有2、3个G开始直接使用服务器下载经常下载到一半报错。后期使用vpn配置地址转发才解决这个问题。这里不得不说kimi的幻觉控制的很好上面遇到的问题使用deepseek给出很多答案都不管用。使用kimi很快就解决了。由于只有一个显卡Qwen2.5-Omni-7B支持3种模态的输出还要关闭其他两种只保留一种输出。这个问题用Kimi直接改源代码也顺利解决。vllm是为文本生成设计的想要发挥Qwen2.5-Omni-7B的音频、图片、视频是三个其他模态的作用还用安装vllm-omni框架3.本地部署的Qwen2.5-omni-7B小模型能力本地部署的Qwen2.5-omni-7B小模型优势就是速度快。对于客服聊天内容检查这类任务能力和doubao-mini-20260424差不多。识别普通表情包的速度在2秒之内对于要实时回复的聊天客服场景速度很适合。缺点是推理能力差。根据相关内容和要求生成的文字很呆板。 
长河君 · 2026/10/26 1:43:16 · 阅读 1.2k RTX5090用vllm框架部署Qwen2.5-omni-7B小模型
1. 背景介绍金融投顾公司要做智能客服使用豆包全模态小模型生成文字的速度太慢了要 20 秒左右。想要提高生成速度DeepSeek 推荐我用全模态小模型。开源的全模态小模型中通义的最多由于 RTX 5090 只有 32G只能部署一个 Qwen2.5-Omni-7B 小模型。1.1 性能实测为了验证本地部署的实际收益我在同一台 RTX 509032G 显存机器上对豆包全模态小模型云端 API 调用与本地部署的 Qwen2.5-Omni-7B 做了对比测试。测试条件如下测试输入统一使用约 500 字的中文客服对话上下文单轮提问输出长度限制为 256 tokens。并发数分别测试单并发1 路与 4 路并发两种场景。统计方式每个场景重复 20 次去掉首尾各 2 次异常值后取平均值首字延迟指从请求发出到收到第一个输出 token 的时间。部署参数Qwen2.5-Omni-7B 使用 vLLM 0.26.0 部署仅开启文本输出模态BF16 精度未做量化。模型部署方式并发数首字延迟秒生成速度tokens/s显存占用豆包全模态小模型云端 API1约 18.5约 12不占用本地显存豆包全模态小模型云端 API4约 20.0约 10不占用本地显存Qwen2.5-Omni-7B本地 vLLM1约 0.6约 45约 22 GBQwen2.5-Omni-7B本地 vLLM4约 1.2约 38约 24 GB从结果看本地部署的 Qwen2.5-Omni-7B 在首字延迟上优势非常明显从接近 20 秒降到 1 秒左右基本满足实时客服回复的要求生成速度也提升到 3 倍以上。代价是 7B 模型在 BF16 下就占用了 22 GB 左右的显存32G 的 RTX 5090 只剩不到 10 GB 余量并发数继续上调时显存和吞吐都会成为瓶颈。需要说明的是以上数据来自单机单卡环境输入长度、并发数和是否量化都会显著影响结果。如果后续要支撑更高并发可以考虑 AWQ 或 GPTQ 量化或者把非文本模态的推理拆到其他服务上。2. 部署方案由于 RTX 5090 属于 Blackwell 架构架构比较新vLLM 官方已有的 wheel 不包含编译最新的支持库只能自己下载 vLLM 0.26.0 的源码自行编译。2.1 使用 Docker 部署由于服务器要下载的镜像文件太大初期未配置github地址转发而失败。后期发现docker实际上用的vllm官方wheel对RTX5090支持有限2.2自己编译vllm源码编译vllm源码要从github上下载很多的配置文件。有的配置文件有2、3个G开始直接使用服务器下载经常下载到一半报错。后期使用vpn配置地址转发才解决这个问题。这里不得不说kimi的幻觉控制的很好上面遇到的问题使用deepseek给出很多答案都不管用。使用kimi很快就解决了。由于只有一个显卡Qwen2.5-Omni-7B支持3种模态的输出还要关闭其他两种只保留一种输出。这个问题用Kimi直接改源代码也顺利解决。vllm是为文本生成设计的想要发挥Qwen2.5-Omni-7B的音频、图片、视频是三个其他模态的作用还用安装vllm-omni框架3.本地部署的Qwen2.5-omni-7B小模型能力本地部署的Qwen2.5-omni-7B小模型优势就是速度快。对于客服聊天内容检查这类任务能力和doubao-mini-20260424差不多。识别普通表情包的速度在2秒之内对于要实时回复的聊天客服场景速度很适合。缺点是推理能力差。根据相关内容和要求生成的文字很呆板。