VLM 推理服务工程：vision token budget、分辨率分层与预处理管线

纯文本 LLM 的成本单位是 input token + output token，文本长度可控且压缩手段成熟（prompt 裁剪、KV Cache 压缩、推测解码）。VLM 多了一个维度：每张图像会被视觉编码器切成固定大小的 patch，每个 patch 映射为一个或多个 vision token——图像分辨率直接决定 token 数量，而图像数量在生产场景中往往不受调用方控制。

arXiv 2608.07427（Jalli et al., 2026-08-07）在电信时序异常检测任务上给出了量化对照：同一批 24 个 KPI 的 4G/5G 基站数据，文本表示需要把每个浮点窗口展开为 token，在 128K 上下文窗口内就装不下，必须截断；而把同样的数据画成 2D 图后送入 VLM，input token 压缩 3.6-10.4 倍，推理能耗下降 1.8-2.5 倍，同时 fine-tuned Llama-3.2-90B-Vision 的精度比 text-only 版本高 220.7%（arXiv 2608.07427）。

但这个「效率红利」有一个前提：图像必须被工程化治理。一张未经处理的 4K 照片在 LLaVA 类架构（14×14 patch）下会产生超过 10,000 个 vision token，相当于 4-5 页文本——如果业务场景每天处理 10 万张用户上传图，成本会直接爆炸。VLM 推理服务工程的核心任务，就是把「图像 → vision token → 推理成本」这条链路变成可控、可估算、可缓存的。

边界说明：本文聚焦 vision 模态特有的 token 编码/分辨率/预处理问题，不涉及纯文本推理的路由、KV Cache 压缩或 prefill/decode 硬件分离——这些在 infer-cost-stack-001、infer-kv-cache-001、disaggregated-inference-001 中已覆盖。

所有主流 VLM（LLaVA、Qwen2.5-VL、Pixtral、Claude Vision、GPT-4o）的视觉编码都遵循同一范式：图像被切成固定大小的 patch，每个 patch 经 ViT 编码为一个 embedding，再经 projection 层映射为 LLM 可消费的 token 序列。 差异只在 patch size、是否支持动态分辨率、以及是否做 2×2 token merging。

2.1 静态分辨率方案（LLaVA-1.5 / LLaVA-NeXT 基线）

LLaVA 系列使用 CLIP ViT-L/14 作为视觉编码器，patch size = 14×14 像素。图像先被 resize 到固定分辨率（通常 336×336 或 672×672），然后切 patch：

• 336×336 → (336/14)² = 576 个 vision token
• 672×672 → (672/14)² = 2304 个 vision token

LLaVA-NeXT 引入 token merging（2×2 合并），把 2304 压缩到 576，但代价是细粒度信息损失——对 OCR 密集场景（文档、表格）影响显著。

2.2 动态分辨率方案（Qwen2.5-VL / InternVL2 / Pixtral）

为了兼顾「远距离小目标」和「近距离文字」，2025-2026 年的主流 VLM 都转向动态分辨率：图像按原始比例切分为多个 448×448（或 336×336）的 tile，每个 tile 独立编码后拼接。

Qwen2.5-VL 的规则（Qwen2.5-VL 技术报告）：

• 最小 tile = 28×28 patch（即 14×14 pixel patch × 2 stride）
• 图像按 28×28 网格切分，不足部分 padding
• token count = ⌈H/28⌉ × ⌈W/28⌉

一张 1024×1024 的图像 → ⌈1024/28⌉² = 37×37 = 1369 个 vision token。
一张 1920×1080 的图像 → 69×39 = 2691 个 vision token。
一张 4K（3840×2160）图像 → 138×78 = 10,764 个 vision token——这就是为什么原始高分辨率图像必须被预处理。

2.3 OpenAI 与 Anthropic 的 API 层抽象

OpenAI 的 vision API 用 detail 参数（low / high / auto）暴露分辨率选择：low 固定 512×512 + 85 token，high 先缩到 768px 短边再切 tile（每个 tile 512×512 = 85 token + 85 全局 token）。Anthropic 的 Claude Vision 按图像像素数分档：≤ 1568×1568 约 1000-2000 token，更大图像会自动缩放。

对服务工程的意义：无论底层模型用什么 patch size，API 层都必须暴露「分辨率档位」给调用方，否则成本不可控。

2.4 动态分辨率的成本影响

动态分辨率方案（Qwen2.5-VL、InternVL2）的优势是保留了图像细节，但代价是 vision token 数不可预测——同一张图，分辨率不同 token 数差 10 倍以上。这对服务工程的影响是：

预算约束困难：调用方无法在请求前预估成本，因为 vision token 数取决于图像原始分辨率。解决方案是服务层在 API gateway 做 token 预估（按目标模型的 patch size 公式计算），并在响应头中返回实际消耗的 vision token 数。

批处理效率低：同一批图像如果分辨率差异大，vision token 数差异也大，无法高效 batching。解决方案是按分辨率档位分桶，同档位图像一起 batching。

缓存键复杂：同一张图在不同分辨率下的 vision token 序列不同，缓存必须按 (image_hash, resolution_tier) 联合索引。

这些工程复杂度是动态分辨率方案的隐性代价——选型时不能只看精度收益，必须评估服务工程的复杂度成本。

生产环境的 VLM 服务不能把所有图像都按最高分辨率送入——成本会爆炸，延迟会不可接受。必须根据任务语义选择分辨率档位。 三级分层是工程上最常见的决策框架：

Thumbnail（缩略图档，~200-500 token）：用于分类、场景识别、NSFW 检测等「看大意」任务。图像缩放到 224×224 或 336×336，token 数 < 500。典型场景：电商商品图分类、社交媒体内容审核初筛。

Standard（标准档，~1000-2000 token）：用于一般性视觉问答、图表理解、简单 OCR。图像缩放到短边 768px 或 1024px，token 数 1000-2000。典型场景：用户上传图片的通用问答、文档页面级理解。

High-res（高分档，~3000-10000+ token）：用于精细 OCR、表格提取、缺陷检测、医学影像。保留原始分辨率或缩放到短边 1568px+，token 数 3000+。典型场景：发票/合同 OCR、工业质检、病理切片分析。

3.1 决策信号

分辨率档位的选择不能靠调用方手动指定（会出错），必须由服务层根据以下信号自动决策：

1. 任务类型路由：API 请求中携带 task_type（classify / vqa / ocr / detect），服务层映射到档位。
2. 图像元数据启发：文件大小 > 2MB 且 MIME 为 image/png → 可能是截图/文档 → 倾向 high-res；文件大小 < 100KB → 可能是缩略图 → thumbnail 足够。
3. 内容感知：先用轻量分类器（MobileNet 级）判断图像是否包含文字/表格/小目标，命中则升级到 standard 或 high-res。
4. 成本预算约束：调用方在请求头中携带 max_tokens_per_image，服务层在预算内选最高可用档位。

3.2 决策流程

下图给出生产环境分辨率分层决策的完整流程。关键设计点是「默认 standard + 按需升级/降级」，避免默认 high-res 导致的成本失控。

分辨率分层解决「每张图送多少 token」，预处理管线解决「有些图根本不需要送」和「送之前先压缩信息密度」。 生产环境每天处理百万级图像时，预处理管线的 ROI 远高于模型升级。

4.1 图像去重（perceptual hash）

用户上传的图像中，大量是重复或近似的——同一张商品图被不同卖家上传、同一份文档被多次扫描、同一张截图被反复转发。用 pHash（perceptual hash）或 CLIP embedding 做去重，可以在进入 VLM 之前拦截 30-60% 的冗余请求。

工程实现：维护一个 LRU 的 image_hash → response 映射表（TTL 24h-7d），新图像先算 hash，命中则直接返回缓存响应，token 成本为零。

4.2 智能裁剪（smart crop）

很多图像的有效信息只占画面的一部分——扫描件周围有黑边、商品图背景占 70% 面积、截图包含无关的浏览器 UI。智能裁剪在送 VLM 之前把无效区域切掉，直接减少 vision token 数。

方法：

• 黑边检测：扫描四边像素，找到内容边界，裁剪（对扫描件有效）。
• 显著性检测：用轻量 saliency 模型找到视觉焦点区域，裁剪到焦点 + 20% padding。
• OCR 前置：先用 PaddleOCR / Tesseract 跑一遍，如果整张图只有文字且 OCR 置信度 > 0.9，直接把 OCR 文本送 LLM（纯文本模式），完全跳过 VLM——这是最激进的压缩。

4.3 预处理管线拓扑

下图给出预处理管线的完整拓扑。关键设计点是「短路路径」：去重命中、OCR 前置命中、分类置信度足够高时，都可以绕过 VLM，直接把结果返回。

VLM 服务的成本估算必须把 vision token 和 text token 统一到一个 budget 框架下，否则无法做路由、限流和计费。

5.1 单请求 token 估算

给定一张图像和一段 prompt，单请求的 input token 数为：

其中 vision_tokens 的计算取决于模型和分辨率档位（见第 2 节表格）。对于动态分辨率模型，服务层必须在请求到达模型之前完成 token 数预估——否则无法做预算约束。

预估方法：服务层拿到图像尺寸后，按目标模型的 patch size 公式直接算出 vision token 数（不需要实际跑视觉编码器）。这个计算是 O(1) 的，可以在 API gateway 层完成。

5.2 成本归因与计费

VLM 服务的计费不能简单按「请求数」——一张 thumbnail 和一张 high-res 4K 图的成本差 10-20 倍。合理的计费维度是：

• 按 vision token 数计费：最精确，但调用方难以预估账单。
• 按分辨率档位计费：thumbnail / standard / high-res 三档定价，调用方可预估。
• 按图像像素数计费：与 vision token 数近似线性，实现简单。

OpenAI 的 vision API 采用「按 tile 数计费」（low = 85 token 等价，high = 85 × tile 数 + 85），本质上就是按分辨率档位计费。

5.3 Budget 约束的工程实现

调用方在请求头中携带 X-Max-Token-Budget: 5000，服务层的处理逻辑：

1. 计算当前图像的 vision token 数（按目标档位）。
2. 如果 vision_tokens + text_tokens(preview) > budget，自动降级分辨率档位。
3. 如果最低档（thumbnail）仍超预算，拒绝请求并返回 413 Payload Too Large。

这个机制保证调用方的账单不会因单张图像意外失控。

5.4 成本优化的反馈环

VLM 推理成本治理不是一次性配置，而是需要建立反馈环持续优化：

监控维度：

• 每请求平均 vision token 数（按任务类型分桶）
• 分辨率档位分布（thumbnail/standard/high-res 占比）
• 缓存命中率（L1/L2/L3 分别统计）
• 预处理管线短路率（去重命中/OCR 前置命中/分类命中）

优化触发条件：

• 如果 high-res 占比 > 30%，检查是否有任务类型可以降级到 standard
• 如果缓存命中率 < 20%，检查图像重复率是否真的低，或缓存 TTL 设置过短
• 如果预处理管线短路率 < 10%，检查 OCR 置信度阈值是否过高，或分类器是否不够准确

成本归因报表：
按调用方、任务类型、分辨率档位生成成本报表，识别成本热点。典型发现：某调用方的「文档 OCR」任务 80% 的图像其实是纯文字扫描件，应该走 OCR 前置短路而不是 VLM——这种洞察只能从成本归因报表中获得。

VLM 推理的缓存命中率在生产场景中远高于预期——同一张图被不同用户/不同任务重复请求的概率很高。 多层缓存是降低平均成本的最有效手段。

6.1 缓存层级

L1：精确去重缓存（pHash 精确匹配）

• 键：图像 pHash（64-bit）
• 值：完整 VLM 响应
• TTL：24h-7d（根据业务场景）
• 命中率：用户上传场景 30-60%，文档扫描场景 70%+

L2：语义缓存（CLIP embedding 近似匹配）

• 键：图像 CLIP embedding（768/1024 维）
• 值：完整 VLM 响应
• 匹配：cosine similarity > 0.95 视为命中
• 命中率：在 L1 基础上额外 5-15%
• 代价：需要向量索引（FAISS / HNSW），维护成本高于 L1

L3：任务级缓存（task_type + image_hash）

• 键：(task_type, image_hash)
• 值：该任务在该图上的响应
• 用途：同一张图在不同任务（classify vs vqa vs ocr）上的响应不同，必须分开缓存

6.2 缓存一致性

图像缓存的最大风险是「图像内容没变但正确答案变了」——模型更新、prompt 模板变更、业务规则调整都会导致旧缓存失效。

工程实践：

• 模型版本作为缓存键的一部分：cache_key = hash(model_version, task_type, image_hash)
• Prompt 模板变更时批量失效 L1/L2 缓存
• 监控缓存命中率：突然下降意味着模型更新或 prompt 变更未同步清理缓存

6.3 缓存的经济性

假设 VLM 推理成本 $0.01/请求，缓存命中成本 $0.0001/请求（Redis 读取），缓存命中率 50%：

• 无缓存：$0.01 × 1M = $10,000/天
• 50% 命中：$0.01 × 500K + $0.0001 × 500K = $5,050/天
• 节省约 50% 成本

缓存的 ROI 在图像重复率高的场景（电商、文档处理）远高于图像 unique 的场景（医学影像、工业质检）。

6.4 缓存实现的工程细节

L1 精确去重缓存的实现相对简单：用 pHash（perceptual hash）或 dHash（difference hash）计算图像指纹，64-bit 整数作为 Redis key，TTL 24h-7d。pHash 的优势是对轻微压缩、格式转换、尺寸缩放免疫——同一张图被不同用户上传，pHash 通常相同。

L2 语义缓存的实现复杂度显著上升：需要把图像经 CLIP 编码为 768/1024 维向量，存入向量索引（FAISS / HNSW / Milvus），查询时做近似最近邻搜索。cosine similarity > 0.95 视为命中，返回缓存响应。L2 的额外命中率通常只有 5-15%，但向量索引的运维成本（内存占用、索引重建、查询延迟）远高于 Redis。工程决策点：只有当 L1 命中率 < 30% 且业务对延迟不敏感时，才值得引入 L2。

L3 任务级缓存的必要性来自一个事实：同一张图在不同任务上的正确答案可能完全不同。一张商品图在「分类」任务上的响应是「电子产品 > 手机」，在「VQA」任务上的响应是「这是一张 iPhone 15 Pro 的产品图，背景为白色」，在「OCR」任务上的响应是图中文字内容。如果 L3 不区分任务类型，就会返回错误答案。

缓存一致性的工程实践：模型版本作为缓存键的一部分（cache_key = hash(model_version, task_type, image_hash)），模型更新时旧缓存自动失效。Prompt 模板变更时批量失效 L1/L2 缓存（Redis SCAN + DEL）。监控缓存命中率：突然下降意味着模型更新或 prompt 变更未同步清理缓存，需要告警。

VLM 推理成本治理不是一次性工程，而是随业务规模演进的持续优化。 以下是分阶段实施路径：

Phase 1（0-30 天）：基础治理

• 实现分辨率分层 API（thumbnail / standard / high-res 三档）
• 实现 pHash 去重缓存（L1）
• 建立 vision token 估算器（API gateway 层 O(1) 计算）

Phase 2（30-90 天）：预处理管线

• 实现智能裁剪（黑边检测 + 显著性）
• 实现 OCR 前置短路（纯文字图跳过 VLM）
• 实现 budget 约束（X-Max-Token-Budget 请求头）

Phase 3（90-180 天）：高级优化

• 实现语义缓存（L2，CLIP embedding 近似匹配）
• 实现内容感知分辨率决策（轻量分类器）
• 建立成本归因与计费系统

决策框架

与纯文本推理成本治理的区别

本文聚焦 vision 模态特有的成本维度。纯文本推理的路由、KV Cache 压缩、推测解码、prefill/decode 硬件分离等方法论在 infer-cost-stack-001、infer-kv-cache-001、disaggregated-inference-001 中已覆盖——VLM 服务工程是在这些基础之上叠加 vision 维度的治理，而非替代。

来源：arXiv 2608.07427（Jalli et al., 2026-08-07, VLM 能耗与精度对照实验）；Qwen2.5-VL 技术报告（动态分辨率机制）；OpenAI Vision Guide（detail 参数与 tile 计费）；Anthropic Claude Vision（像素分档）；LLaVA-NeXT（token merging 机制）