通义千问2.5-omni-7b全模态本地部署

本地部署一个只吃文字的模型，多数人踩一遍坑就熟了；换成全模态，多了音频、图像、视频这些输入通道，环境依赖、显存占用和调用方式都会变样，很容易卡在装不上或者跑了没反应。这篇按「先备环境、再起服务、最后打通多模态调用」的顺序，把判断标准和排查动作列清楚，数字部分统一指向站内对应页面去核。

本地跑一个纯文本模型，多数人折腾一两轮就摸清了套路。换成全模态就不一样了——图像、音频、视频三条输入通道一加进来，环境依赖、显存占用、调用方式全都跟着变。显卡能装下文本模型，不代表能同时扛住一路视频加实时音频；之前能跑的推理框架版本，到多模态这里很可能直接报错。

这篇不堆概念，按「开工前确认什么、服务怎么起、多模态请求怎么打通」三段走。每段给判断标准和排查动作，涉及显存、价格、并发这些数字的部分，统一指到站内对应页面去看当时的数，别照搬别人博客里的旧值。少数场景（比如只是单张图短文本、并发几乎为零），下面有些步骤可以简化，遇到会单独说明。

开工前先确认三件事：显存、依赖、权重来源

先别急着下权重。第一件事是估显存：参数量乘量化档位是粗算，真正吃显存的是输出分辨率和音频切片长度——同一张图放大两档、音频按不同时长切片，占用能差出一个数量级。想知道你这张卡跑某个档位还剩多少余量，到 /models/deploy 按卡型跑一遍，比看别人的截图靠谱。

第二件事是依赖。多模态分支对推理框架版本通常比纯文本更挑，驱动、CUDA、框架三者版本对不上是最高频的翻车点。选 ollama、llama.cpp 还是 vLLM 这类服务框架，先到 /tools 把换算和检测类工具过一遍再决定，别装到一半才发现不支持音频输入。

第三件事是权重来源和许可证。从官方模型库或可信镜像拿，下载页写「开源」不等于随便用。商用或再分发前，把许可证里关于商用、再分发、署名这几条单独拎出来读，拿不准术语就去 /ai-dict/category/safety 对照。这一步花十分钟，能省掉后面一堆麻烦。

把服务跑起来：权重、量化、启动参数

权重拿到手，第一步不是把所有模态全开，而是跑通最小闭环：一段短文本加一张图，确认模型能加载、能返回结果。一次性全开音频和视频，报错会混在一起，你根本分不清是权重没对齐、还是输入格式写错了。最小闭环通了，再逐个加通道。

1. 加载最小权重先只启文本+图像分支，跑一条最短的问答，确认进程不崩、返回结构正常。
2. 逐通道开依次加音频、视频，每加一个就重跑一次请求，记录那个通道的显存峰值和首次延迟。
3. 调启动参数设备指定、端口、并发数分开调。先用默认并发跑通，显存卡边时先降并发，而不是立刻换卡。

量化档位怎么选，看两条线：能不能跑起来，和要不要保精度。低比特量化通常能省掉一大截显存，但图像细节和语音识别的损失得自己验——拿几张有文字细节的图、一段带口音的音频，量化前后各跑一次对比。量化档位的取舍逻辑，参考 /ai-dict/category/tech 里的解释，别只信「省显存」三个字。

打通多模态调用：图像、音频、视频各怎么喂

三个通道的接口形态差别不小：图像走 base64 还是 URL、音频走整文件还是流式、视频是抽帧还是整段送，不同服务框架给出的字段都不一样，没有通用写法。稳妥做法是先用命令行或一段几十行的 Python 脚本打一发最小请求，把返回结构摸清楚，再往业务代码里搬。

• 图像：先测一张小图，确认返回结构和 token 计数方式，再试高分辨率图和批量。
• 音频：分清整文件上传和流式输入两种形态，切片长度直接决定显存和延迟。
• 视频：抽帧送还是整段送差别很大，先用短片段验证通路，再谈长视频。
• 组合输入：只用图、只用音频、图文一起，各测一次并记录延迟和显存峰值。
• 并发：先单请求跑通，再逐步加压，QPS 别拍脑袋定。

本地跑虽然不产生 API 调用费，但耗时和资源口径要按同样思路估。图理解这类多模态请求的计费/换算思路，可参考 /tools/token-price-calculator，把本地延迟和显存峰值折算成类似口径，方便和调用云端 API 做对比。并发上量之前，先看 /gpu-concurrency-estimate 这类页面给的口径，再决定压到多少。

什么时候不适用这套：如果你只是偶尔跑一张图、几乎不考虑并发，音频和视频两条通道可以先不接，最小闭环加图像就够用；反过来，一旦要上音频流或视频，前面省的步骤基本都得补回来，早确认比晚返工省事。

全模态本地部署的关键不是把四个通道都打开，而是每次只加一个变量，知道是谁把显存吃掉的。