图片 Token 计算机制：从切分规则到部署配置

图片 Token 计算机制从切分规则到部署配置适用模型Qwen3.5-35B-A3B本文主要对象视觉处理继承 Qwen3-VL、Qwen3-VL、Qwen2.5-VL兼述 OpenAI GPT-4V/4o总述多模态模型中图片占用的 token 数由切分规则在输入前就确定是纯几何计算先按模型规则规整图片分辨率再按固定网格切块每块对应一个视觉 token。这与文本 token 依赖内容BPE 编码有本质区别——图片 token 只取决于宽高两个数字与图片内容、清晰度、色彩通道数完全无关。理解这一点后图片 token 预算可以在请求发出前用简单算术精确算出进而可以推导出部署时最大上下文长度这一配置的真实含义它决定了 KV Cache 池的容量水位直接约束并发吞吐。本文按切分原理 → token 数计算 → patch 到 token 的变换链条 → 上下文预算 → 部署配置逐层展开。一、图片 Token 的核心机制切分即定价主流多模态模型LLaVA、Qwen-VL、GPT-4V的视觉侧采用 ViTVision Transformer编码处理流程图片按固定大小的方块patch网格切分典型 patch 为 14×14、16×16 或 28×28 像素每个 patch 经编码器变换成一个视觉向量视觉 token视觉 token 与文本 token 拼接成同一序列一起喂给 LLM。由此得到基础公式图片 token 数 ≈ (缩放后宽 / factor) × (缩放后高 / factor)关键认知是切分即定价token 数在预处理阶段就完全确定不是模型看图后动态算出来的。这是各 API 厂商能提前给出一张图 xxx tokens定价表的原因。二、Qwen3.5-35B-A3B 的完整计算规则关键前提视觉处理完全继承 Qwen3-VL。Qwen3.5-35B-A3Bmodel_type: qwen3_5_moe的preprocessor_config.json使用Qwen3VLProcessorQwen2VLImageProcessorFast视觉侧参数与 Qwen3-VL 逐项一致差异只在文本侧 MoE 主干256 专家、每 token 激活 8 个、40 层、2 个 KV 头。因此图片 token 计算规则两代通用。规则参数来源Qwen/Qwen3.5-35B-A3B 模型仓库preprocessor_config.json官方配置与 Qwen3-VL 系列一致参数值含义patch_size16每 patch 为 16×16 像素merge_size2相邻 2×2 patch 合并为 1 个 tokenfactor32单 token 对应 32×32 1024 像素min_pixels65,536单图下限 64 tokenmax_pixels16,777,216单图上限 16,384 tokensmart_resize 规整流程来源qwen-vl-utils 0.0.14vision_process.py官方源码宽高各自 round 到 32 的倍数总像素超过 16,777,216 时等比缩小压回 16K token 上限内总像素低于 65,536 时放大拉到 64 token 下限token 数 (规整后高/32) × (规整后宽/32)每图额外 2 个特殊 token|vision_start|/|vision_end|。与 Qwen2.5-VL 的区别Qwen2.5-VL 是 14 patchfactor28、默认单图上限 1280 tokenQwen3-VL / Qwen3.5 是 16 patchfactor32、默认上限 16,384 token。同一张图两代规则下 token 差异可达数倍。实测验证官方逻辑本地复刻运行方法见 qwen-vl-utils 源码原图尺寸smart_resize 后视觉 token含起止符100×100256×25664触发下限保护66640×480640×4803003021280×7201280×7048808821080×19201088×1920204020422048×20482048×2048409640983333×2500样例图3328×249681128114其中 3333×2500 这张实拍商品图在 Qwen2.5-VL 规则下仅 1230 token上限钳制更强压到 1148×840同图异规差异 6.6 倍——跨模型比预算时必须先对齐规则。三、Patch 到 Token 的变换链条Token 的本质序列中一个位置上的一个高维向量不是一个数字也不是一个像素。文本侧一个 BPE 词元经 embedding 查表变成一个向量图片侧一个 patch 内的全部像素数字经一个可学习的线性投影层压缩成一个向量。像素是原料token 是压缩后的成品。完整变换链条Qwen3.5-35B-A3B 官方config.json实配vision_config 27 层 / hidden 1152 / patch 16与 Qwen3-VL 一致原图(任意尺寸)smart_resize规整到 32 的倍数钳制像素区间切 16x16 patch(768 个数字/个)线性投影768 个数字 → 1152 维向量ViT 自注意力(27 层, 1 patch 1 token)2x2 合并4 个 patch 向量 → 1 个视觉 token拼进文本序列进入 LLM要点澄清RGB 三个数字不是一个 token一个 16×16 patch 内有 16×16×3768 个数字整体经线性层压缩为一个向量才是一个 token两级一个 tokenViT 内部 1 patch 1 token细粒度进 LLM 前 2×2 合并后 4 patch 1 tokenLLM 侧最终粒度 32×32 像素。合并纯粹是为了给 LLM 减负——token 数除以 4用一半空间精度换四倍上下文空间与一个字多个 token的类比文本 token 长短取决于内容BPE图片 token 取决于分辨率几何网格真正类似多字一 token的是视频的时间维度打包temporal_patch_size2相邻两帧共享 patch 位置MoE 与 token 计算无关tokenization 发生在进模型之前Qwen3.5-35B-A3BMoE256 专家中每 token 激活 8 个与 dense 版的图片处理逻辑完全一致。四、上下文预算图片与文本共享同一个池最大上下文 8K指的是文本 token 图片视觉 token 共享同一预算。一张高清图轻松吃掉 1~8K token多模态场景下有效上下文比标称值缩水很快图片开销必须在 prompt 设计时显式预算。预算公式最大上下文 ≥ 图片 token 总和 文本 prompt系统提示词指令多轮历史 输出预留 安全余量注意多轮对话中历史图片持续占位需按同时出现的所有图之和计算而非单图最大值。输入 token 的预先估算方法三要素请求发出前input token 可精确预估需要三样东西要素决定什么从哪获取① 图片分辨率切出多少块分子业务侧原图尺寸或服务端钳制后的实际尺寸② 模型 token 计算规则每块多大分母 上下限钳制preprocessor_config.jsonpatch/merge/min_pixels/max_pixels③ 文本提示词文本 token模型对应 tokenizerAutoTokenizer离线跑一遍实践中比知道三要素更关键的是三个坑①要按钳制后的分辨率算不是原图同一张 3333×2500 图Qwen3.5 规则下 8112 tokenQwen2.5-VL 规则下仅 1230max_pixels 先压到 1148×840只看原图会高估 6.6 倍。严谨做法是原图尺寸过一遍目标模型的 smart_resize 再计数更简单的工程做法是业务侧主动控分辨率按目标 token 数反推像素上限token×1024缩图后上传预算完全可控②跨模型不可移植patch/merge/上限是各家架构自选32/28/512 tile换模型必须重查配置无行业标准③文本是唯一需要真跑 tokenizer 的部分图片部分纯算术、微秒级、零依赖文本依赖具体模型 BPE 词表中文约 1 字/token 仅是粗估精确值需离线加载 tokenizer文本 prompt 通常自写、长度固定算好可复用。易漏算的三块视业务形态加进预算多图直接累加每张独立过规则多轮对话历史图和文本持续占位按会话窗口内所有内容之和算视频token ≈ 帧数 × 单帧图 token 每帧时间戳文本 token3~5 个/帧帧数是隐藏的乘法因子最容易爆。完整估算公式input_tokens Σ(每张图 smart_resize 后按模型规则计数 2) tokenizer(prompt文本) [帧时间戳 历史轮次]三要素全部在请求前可知、不依赖模型服务本身——这套估算适合做成网关层预检超限拒到 4xx而非事后发现超长。五、部署配置最大上下文长度如何影响吞吐平台部署提示最大上下文长度(K)该配置影响吞吐效率请根据实际业务合理设置的底层原因KV Cache 显存账Qwen3.5-35B-A3B40 层、GQA 2 个 KV 头、head_dim 256、bf16来源模型仓库config.jsontext_config每 token KV 2 × 层数 × KV头数 × head_dim × 精度字节 2 × 40 × 2 × 256 × 2B ≈ 80 KB / token30K 上下文请求的 KV Cache 上限 ≈ 2.4GB。显存 模型权重 KV Cache 池 激活预留KV 池大小是死的每条请求的上限占用越大池子里能塞的并发序列数越少——这就是吞吐受损的真实含义约束的是并发请求数不是批处理 token 数。两代引擎的差异来源vLLM PagedAttention 论文及 vLLM/SGLang 官方文档引擎模式分配机制大 max_len 的代价静态预分配每请求一次性预留完整 max_len 的 KV短请求浪费最严重max_len 翻倍并发近乎减半PagedAttention / continuous batching按 block 按需分配如 16 token/块不全额预占但调度器按最坏情况留水位max_len 越大并发上限越低配置取值建议合理值 业务输入 P99图片文本 输出预留 约 10% 余量单图单轮场景20K 图 文本 输出 ≈ 配 24K~28K恰好设 20K 会因输出无空间而失败多图/多轮场景按最大图片数 × 单图 token 文本 输出累加单图 token 的 min/maxmin_pixels/max_pixels与最大上下文长度是两个独立旋钮前者管图片预处理钳制后者管推理上下文预算两边必须配套若按 20K 图做预算需确认部署侧已放开单图 16,384 token 默认上限MoE 的隐性优势KV Cache 只由注意力部分决定40 层、2 个 KV 头与 256 个专家无关激活专家少意味着激活显存小同显存下可比 35B dense 模型撑更高并发。前置知识最大上下文为何启动后不可运行时修改以 SGLang 为例vLLM、TensorRT-LLM、TGI 同理最大上下文长度是启动期定死的这是当前一代推理引擎架构的共同约束而非 SGLang 独有缺陷。具体有三层原因KV Cache 池启动时一次性划走显存SGLang 启动时按mem_fraction_static把一块固定显存划给 KV 池并确定max_total_num_tokens池内总 token 容量。池子是预分配的固定预算运行中所有在跑请求的 KV 都住在这块显存里热调整等价于对在飞请求整体迁移显存引擎不提供此能力启动期绑定的组件RadixAttention 前缀缓存树以 token 页为节点容量管理建立在池子尺寸之上、CUDA Graph 预热解码阶段为各 batch size 捕获计算图静态形状假设包含序列长度上界、调度器准入水位线按在跑请求最坏可增长量计算上限即 context-length——三者在启动期一次性构建任何运行时变更都要求全量重建--context-length的真实含义它决定单条请求最多能占池子里多长不是池子本身大小。改它要重启向上可以设到模型max_position_embeddings范围内Qwen3.5-35B-A3B 为 256K不需要换权重代价是池内并发进一步下降。运行时可用的软调节手段不重启前提下替代改配置需求运行时手段某请求特别长无需改全局调度器按池内实际余量准入长请求只是占更久、并发更挤上下文配小了想放大只能重启换--context-length模型支持范围内直接调参权重不变临时限制成本/防滥用网关层做 token 数预检按max_pixels钳制后算输入长度超限拒到 4xx比重启服务实用压单图 token 开销请求级传max_pixels参数钳制图片完全运行时可调不影响其他请求若业务存在长短混杂流量需要分池隔离属于 PD 分离/多实例路由层面的架构设计问题单实例配置无法解决。引用来源Qwen3.5-35B-A3B 官方模型配置patch_size/merge_size/min_pixels/max_pixels 及 40 层/2 KV 头/256 专家等Hugging Face 模型仓库Qwen/Qwen3.5-35B-A3B的preprocessor_config.json与config.jsonhttps://huggingface.co/Qwen/Qwen3.5-35B-A3B含镜像 hf-mirror.comQwen3-VL-30B-A3B-Instruct 配置与之交叉核对视觉侧一致smart_resize 与图片预处理逻辑qwen-vl-utils 官方源码GitHub https://github.com/huggingface/qwen-vl-utils版本 0.0.14src/qwen_vl_utils/vision_process.pyPyPI 包本地解包核对Qwen2.5-VL 动态分辨率与默认上限qwen-vl-utils 官方仓库及 Qwen2.5-VL 技术报告https://github.com/QwenLM/Qwen2.5-VLOpenAI GPT-4V/4o 图片 tile 定价规则512 tile、85/170 tokensOpenAI 官方文档https://platform.openai.com/docs/guides/visionPagedAttention 显存管理与 continuous batching 机制vLLM 论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》https://arxiv.org/abs/2309.06180及 vLLM 官方文档https://docs.vllm.aiLLaVA-1.5 固定 336×336 输入、576 视觉 tokenLLaVA 论文《Visual Instruction Tuning》https://arxiv.org/abs/2304.08485SGLang 启动期显存预分配mem_fraction_static / max_total_num_tokens、RadixAttention 前缀缓存与 CUDA Graph 机制SGLang 官方文档https://docs.sglang.ai及 GitHub 仓库https://github.com/sgl-project/sglang文中实测表格数据本地按官方源码逻辑复刻运行验证脚本image_token_calc.py对齐 qwen-vl-utils 0.0.14smart_resize