这是《AI 私有化实战：把模型跑在你自己的机器上》第 10 讲。
前九讲的输入输出都是文本。真实系统里还有截图、语音、图表、发票照片------「多模态」就是给本地栈补上这一块。
多模态的私有化有一个和前九讲都不同的坑：它的「装得下」不是按一个文件算的，是按两个文件算的；而且装得下不等于跑得动。 这一讲把这两件事都量出来。
原理：多模态 = 主模型 + 投影器
一个多模态模型在磁盘上通常是两个文件：
- 主模型（thinker / LLM 部分）：负责理解和生成，和纯文本模型长得一样。
- 投影器 （mmproj，multi-modal projector）：一个「翻译器」，把像素或音频采样转成主模型认识的空间。没有它，主模型看到图就是看到一堵墙------视觉直接不可用。
为什么值得当成两个文件看？看加载命令就知道（这是本讲 OCR 那台实际的启动参数）：
bash
llama-server -m /data/model/modelscope/models/Abiray/OvisOCR2-GGUF/OvisOCR2-Q8_0.gguf \
--mmproj /data/model/modelscope/models/Abiray/OvisOCR2-GGUF/mmproj-F16.gguf \
--n-gpu-layers 0 --ctx-size 2048 --port 8963--mmproj 是单独一个参数，指向单独一个文件------主模型和投影器从来不是同一个文件。漏了它，服务照样起、照样回话，只是「看不到」。
为什么投影器要单独一个文件？因为它是两种几何之间的桥：图像是像素网格（比如 1024 乘 768 的网格），主模型的输入是 token 序列（一个接一个的离散位置）。投影器做的事，是把「一片像素」压成「一串主模型能读的位置」。这个转换是训练出来的，不是规则------所以它必须和主模型配套（不同主模型的输入空间不同，投影器不能通用），也就必须以独立文件的形式跟着模型走。
这个结构带来一个立刻有用的推论：多模态的显存下限 = 主模型权重 + 投影器权重，而权重就是文件大小------下载之前就能算。 不需要装、不需要跑、不需要猜。
还有一个容易忽略的配套问题：两个文件的量化档位可以不同（本讲 OvisOCR2 主模型是 Q8_0、投影器是 F16，qwen3-omni 主模型是 Q4_K_M、投影器是 Q8_0），但必须配套------A 模型的投影器不能接 B 模型的主模型，输入空间对不上，接上就是噪声。所以「找投影器」不是「找个差不多的」，是「找这个主模型的」。
动手做：三个模型两段算 + 一条延迟曲线
台架是 tools/private_lab/mm_probe.py，全程 CPU（--n-gpu-layers 0），不占 27B 的卡。它量三件事：
- 两段显存：三个模型的主模型 + 投影器文件大小（不加载模型，读文件就定）；
- 主模型 ≠ 多模态：一个没有配套投影器的 1B 模型，视觉是什么状态；
- 装得下 ≠ 跑得动：同一张 OCR 图，三个尺寸，延迟曲线。
复现命令（在仓库根目录跑）：
bash
python3 tools/private_lab/mm_probe.py --json out/private/L10/mm_probe.json退出码：0 = OCR 读对且两段显存算出，1 = 关键项失败。
结果一：两段显存------下载前就能定
| 模型 | 主模型 | 投影器 | 合计 | 投影器占比 |
|---|---|---|---|---|
| OvisOCR2（OCR 专用） | 0.756 GB | 0.191 GB | 0.947 GB | 20.2% |
| qwen3-omni（thinker） | 17.283 GB | 1.234 GB | 18.517 GB | 6.7% |
| MiniCPM5-1B | 1.074 GB | 无 | 1.074 GB | --- |
三行各说明一件事：
OvisOCR2：小模型上，投影器不是零头。 主模型 0.756 GB，投影器 0.191 GB------投影器占了 20.2%。如果你按「1B 模型 ≈ 1 GB」做预算，会差出 0.191 GB。OCR 这种专用小模型，投影器的占比尤其高。
qwen3-omni：「omni 模型」不是「小模型」。 主 17.283 GB + 投影器 1.234 GB = 18.517 GB------和第 1 讲量的 27B 文本模型（约 19 GB 量级）是同一档。投影器占比掉到 6.7%：主模型越大，投影器越不成比例。但注意，这是 thinker（思考）部分，音频部分如果另有权重文件，账还要再加。
MiniCPM5-1B：主模型 ≠ 多模态。 1.074 GB 的主模型，没有配套 mmproj------视觉就是关的。它加载、推理、回话都正常，唯独「看不到」。这是本讲最值钱的一个反例：按模型名估显存的人，会以为「1B 多模态，装得下」，实际上装下的是一个纯文本模型。
再看「投影器占比」这一列：OvisOCR2 占 20.2%，qwen3-omni 占 6.7%。从这两个点看，方向是主模型越小，投影器占比越高------投影器的参数量跟着「要翻译的模态复杂度」走，不太跟着主模型规模走。样本只有两个，这只是趋势，不是定律；但足以让你在给小模型做预算时多留一手。所以小多模态模型上，投影器是「显眼的配角」；大多模态模型上，它退成「零头」。预算时：小模型按两笔算，大模型也不能完全当零头（1.234 GB 也是 1.234 GB）。
这个「下载前就能定」的工作流值得展开一下，因为它能拦下最贵的一类错误------下了 20 GB 才发现装不下。正确顺序是：① 看目标模型的文件清单，找出主模型和 mmproj；② 两个文件大小相加；③ 和「显存 − 上下文预算 − 系统预留」比。第 1 讲给过上下文预算的算法（KV 缓存按上下文长度线性涨），两边一扣，装不装得下在下载前就定死了。本讲三个模型里，OvisOCR2 合计 0.947 GB，任何一张能跑 27B 的卡都装得下；qwen3-omni 合计 18.517 GB，要按 27B 的口径去抠上下文预算------同一个「omni」标签，预算差 19.5 倍。
这套算法可以直接抄（对任意两个 gguf 文件都成立）：
python
import os
def two_stage(main_path: str, proj_path: str) -> float:
"""多模态显存下限 = 主模型 + 投影器（读文件即得，不用加载）"""
main_gb = os.path.getsize(main_path) / 1024 ** 3
proj_gb = os.path.getsize(proj_path) / 1024 ** 3
return round(main_gb + proj_gb, 3)
# 例：OvisOCR2 = 0.756 + 0.191 = 0.947 GB
# 例：qwen3-omni = 17.283 + 1.234 = 18.517 GB
# 主模型没有配套 mmproj？视觉不可用，先别算账，先找投影器结果二：装得下 ≠ 跑得动------OCR 延迟曲线
装下 OvisOCR2（0.947 GB）之后，跑一张白底黑字的发票图（两行字：Invoice No: 2026-0847 / Total: 1280.50 CNY），判据是回复里同时含这两个数。
| 图尺寸 | 延迟（CPU） | 读对 |
|---|---|---|
| 256x192 | 1.31 秒 | 是 |
| 512x384 | 1.41 秒 | 是 |
| 1024x768 | 1.81 秒 | 是 |
三档全读对------0.947 GB 的 OCR 专用模型，读发票这种结构化视觉任务是够用的。但看延迟列：图从 256x192 到 1024x768，延迟从 1.31 秒涨到 1.81 秒，慢了 38%（1.81 ÷ 1.31 ≈ 1.38）。
为什么会涨？图进模型之前要先被切成视觉 token------图越大，token 越多，前向计算越多 。换到 GPU 上，这条曲线的主导项会挪位置：权重侧变快了，而视觉 token 的数量一个不少，所以延迟里「输入有多大」占的比例只会更高。一句话：卡越快，缩图越值钱。 含义是：多模态的延迟预算要拆成两笔------权重是固定开销（下载前就知道），输入是可变开销（每次请求都不同，而且没有上限）。你的业务是 200 像素的图标识别，还是 4K 截图理解，延迟差的不是一点半点。
还有一条没量但要心里有数：本讲只量了视觉。音频的瓶颈在采样率和时长（一段 30 秒的语音，token 数远超一张 1024x768 的图），视觉和音频各有各的曲线，别拿视觉的延迟去推音频的延迟。
这条曲线还有一个实用推论：同一张图，先降尺寸再进模型，比装更大的卡便宜。 1024x768 比 256x192 慢 0.5 秒，而本讲最小的 256x192 也读对了------说明可用的下限比 256x192 还低，多数 OCR 场景（发票、截图、表格）缩到 512 宽绰绰有余。如果你的输入源是手机拍照（4000 万像素往上），进模型之前先缩到 1024 宽，省下的不是 0.5 秒，是「大图把视觉 token 堆满、把生成挤出去」的那一整段延迟。缩图是免费的，加卡不是。
判据：怎么装下
把两段结论合成一张决策表：
| 你的任务 | 选什么 | 为什么 |
|---|---|---|
| 读结构化图（发票、截图文字、表格） | OCR 专用小模型（本讲 0.947 GB 档） | 专用模型投影器占比高但绝对值小，CPU 上 1.31--1.81 秒/张可用 |
| 通用视觉理解（描述、推理、多图） | omni/thinker 档（本讲 18.517 GB 档） | 能力在 thinker 里，显存按 27B 量级预算 |
| 音频转写 / 语音理解 | 先查文件清单：有没有音频专用权重段 | 本讲没量音频，账没算完之前不排期 |
| 任何「1B 多模态」 | 先查有没有配套 mmproj | 没有就是纯文本，装下也白装 |
筛选顺序（如果只能留一个多模态模型）：① 任务能不能被 OCR 专用模型接住（能 → 0.947 GB 档，省下的显存给 27B）；② 不能 → 看 thinker 档装不装得下（两段合计 18.517 GB，和 27B 同档，二选一）；③ 都不行 → 回免费档（第 6 讲的路由，免费档的视觉模型走同一个入口逻辑）。
为什么第一步就问「OCR 专用能不能接住」？因为多模态的显存是和主力生成模型抢同一张卡的。0.947 GB 的 OCR 模型可以和 27B 共存（合计不超 27B 的预算），18.517 GB 的 thinker 和 27B 二选一------选专用小模型不只是「省 19.5 倍显存」，是「多模态和主力生成可以共存」这件事本身。如果你的系统里生成和视觉都要常驻，这道选择题的答案在第一步就定了。
常见坑
坑一：按模型名估显存。 「MiniCPM5-1B，1B 嘛，装得下」------装下了，视觉是关的。显存按文件算，能力按文件清单算，名字只是标签。
坑二：只量「装得下」，不量「跑得动」。 0.947 GB 装下了，1024x768 的图在 CPU 上要 1.81 秒；同一张图缩到 256x192 只要 1.31 秒。上线前把「你最大的输入」那一档量出来，写进延迟预算------拿最小档的 1.31 秒去承诺 SLA，等于给用户签一张兑现率不明的欠条。
坑三：拿视觉延迟推音频延迟。 两者的 token 生成机制不同（音频按采样率/时长算 token，视觉按图尺寸算）。本讲只量了视觉，音频的曲线要单独量，别外推。
坑四：投影器乱配。 A 模型的 mmproj 接 B 模型的主模型，服务能起、能回话，但「看到的」是噪声------输入空间对不上，没有报错，只有错图。两个文件必须同来源配套，下载时把文件清单（主模型名 + mmproj 名）一起抄下来，别只记主模型名。
这一讲拿走什么
四样东西：
- 一个算法：多模态显存下限 = 主模型文件 + 投影器文件，读文件即得，下载前就能定。
- 三个数：0.947 GB（OCR 专用，投影器占 20.2%）；18.517 GB（omni thinker，投影器占 6.7%）；1.074 GB（无投影器 = 纯文本，视觉不可用）。
- 一条曲线：OCR 延迟 1.31 → 1.41 → 1.81 秒（256x192 → 1024x768，CPU），三档全对------能力够，延迟随输入涨。
- 一条筛选顺序：OCR 专用能接住吗 → 接不住，thinker 装得下吗 → 都不行，回免费档。
课后思考题
第一题：你的多模态任务，瓶颈是权重还是输入？
提示：把本讲两段拆开看------权重是固定开销（0.947 GB 或 18.517 GB，下载前就知道），输入是可变开销（图尺寸、语音时长，每次请求都不同）。如果你的输入尺寸波动大（同一系统里既有小图标又有 4K 截图），瓶颈大概率在输入侧：固定权重可以一次装好，可变输入要按最大档留延迟余量。
第二题：如果只能留一个多模态模型，你按什么筛？
提示：按「任务被专用模型接住的概率」筛，不按「模型名气」筛。先列你最常出现的多模态请求是什么形态（发票？截图？语音？），再问：这个形态有没有 1 GB 以下的专用模型能接住？有 → 留专用，省下的显存给主力生成模型；没有 → 才轮到 thinker 档。本讲的 0.947 GB 和 18.517 GB 差了 19.5 倍，选错一个，显存差出整个 27B 的位置。
下一讲进入部署的最后一环：部署完必须过的几道闸。前十讲量的都是「装得下、跑得动、读得对」，下一讲量的是「上线之后」------服务起没起、模型对不对、延迟达不达标、断了怎么知道。私有化的最后一公里不是模型，是闸。
评论区可以报个数：你机器上的多模态模型，主模型和投影器加起来多少 GB？有没有人踩过「装下了但看不到」的坑？