1. 背景介绍

金融投顾公司要做智能客服，使用豆包全模态小模型，生成文字的速度太慢了，要 20 秒左右。想要提高生成速度，DeepSeek 推荐我用全模态小模型。开源的全模态小模型中通义的最多，由于 RTX 5090 只有 32G，只能部署一个 Qwen2.5-Omni-7B 小模型。

1.1 性能实测

为了验证本地部署的实际收益，我在同一台 RTX 5090（32G 显存）机器上，对豆包全模态小模型（云端 API 调用）与本地部署的 Qwen2.5-Omni-7B 做了对比测试。测试条件如下：

• 测试输入：统一使用约 500 字的中文客服对话上下文，单轮提问，输出长度限制为 256 tokens。
• 并发数：分别测试单并发（1 路）与 4 路并发两种场景。
• 统计方式：每个场景重复 20 次，去掉首尾各 2 次异常值后取平均值；首字延迟指从请求发出到收到第一个输出 token 的时间。
• 部署参数：Qwen2.5-Omni-7B 使用 vLLM 0.26.0 部署，仅开启文本输出模态，BF16 精度，未做量化。

从结果看，本地部署的 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秒之内，对于要实时回复的聊天客服场景，速度很适合。

缺点是推理能力差。根据相关内容和要求生成的文字，很呆板。