你平时调大模型接口，输入是一段文字，输出也是文字。可一旦牵扯到图片理解、视频分析，事情就变得微妙起来——照片明明是一堆像素，凭什么能塞进基于语言训练出来的模型里？这里头最关键的一道关口，就是把图像信号转成模型能吃的“软Token”。我这两年做多模态相关项目，几乎天天跟“视觉输入”这个词打交道，今天就把照片和视频帧是怎么一步步变成软Token这件事，从原理到实操完整捋一遍，顺便分享一些不跑一遍绝不会知道的细节。
先说一个所有做多模态的人都绕不开的困惑：图片分辨率动辄上百万像素，模型算力再强也不可能逐个像素去理解。那么问题来了，我们到底该把图片“切成什么形状”、把视频“抽成什么节奏”，才能让大模型既不丢失关键语义，又不至于把算力烧成灰？这篇文章就是围绕这个问题展开的。适合正在入门多模态、想做图文理解或视频问答、以及想搞清楚LMM（大型多模态模型）最底层输入格式的朋友，尤其是那些已经在跑CLIP、LLaVA、Qwen-VL这类模型，但还不清楚视觉分支“前几层”到底做了什么的人。看了这篇文章，你会对从图像到Token的全链路有一个彻底清晰的认知，并且可以直接上手验证“我的视频到底会变成多少个Token”这个问题。
1. 照片为什么进不了大模型的嘴：像素矩阵与Token的本质差异
1.1 大模型只会读变长序列，不会读“图像”
文本大模型的核心输入形式是Token序列——一串带位置信息的离散向量。Transformer的自注意力机制，本质上是在一堆向量之间两两计算关联度。不管是GPT还是Llama，它们对输入的唯一要求就是：给我一个形状为 [seq_len, hidden_size] 的二维矩阵。
而图片是什么？最常见的表示是一个三维数组 [height, width, channels]，通道数通常是3（RGB）。你不可能直接把三维矩阵塞进一个期望二维输入的模型里，就算强行 reshape 成一个长条向量，模型也不知道哪里是“上”、哪里是“相邻”，更可怕的是计算量完全不可接受。
所以问题的本质变成了：如何把三维像素信息，转化成一个模型能理解、能参与注意力计算的一维Token序列，而且这个转化过程要尽量保留视觉语义。
1.2 直接拉平像素为什么行不通
最粗暴的想法是把每个像素当作一个特征维度，拉平成一个超长向量。比如一张 512x512 的RGB图，拉平之后是 512x512x3=786432 个数字。放在 FFN（前馈网络）里做一次线性变换，参数就是百万级别起步，多头注意力更是直接瘫痪。而且更致命的是——像素与像素之间的关系是强局部的，这种局部性完全被一维拉平破坏了。
业界早期走的是另一条路：用CNN做特征提取，把图片浓缩成一个小尺寸的特征图，再想办法接入Transformer。但在ViT（视觉Transformer）提出来之后，思路变了：干脆把图片当成一堆“小图片块”的集合，把这个集合按顺序排列成一个Token序列。这也是照片能变成Token的最根本前提——图片本质上也是序列，只不过这个序列的元素不是词，而是被切出来的图像块。
2. 一张图变Token的三道工序：Patch切分、线性投影与位置编码
2.1 Patch切分：把整张图切成小豆腐块
以ViT最经典的配置为例，输入图片通常是 224x224，patch_size 是 16x16。224除以16等于14，也就是说图片被切成了 14x14=196 个小块，每个小块是一个只有3个通道的 16x16 区域。
你可以把这件事类比成拼图游戏：整幅画太大，机器一口吃不下，我们就按固定大小切成拼图片，把每一片单独编码，再按顺序把拼图片排成一串。这些“拼图片”就是视觉Token的前身。
这里有一个关键选择：patch_size 为什么是16而不是4或者32？
- 如果patch太小，比如4x4：224x224会生成 56x56=3136 个Token，算力直接上升一个量级，自注意力的复杂度是Token数量的平方，3136的平方比196的平方大了255倍还要多。
- 如果patch太大，比如32x32：Token数量降到了 7x7=49，算力是省了，但每个小块承载的语义过于混杂，边缘细节、纹理信息被严重稀释，下游任务精度会下滑。
所以16x16是在“Token数量可控”和“语义粒度足够细”之间取得的平衡点。现代一些模型改成14x14，配合分辨率提升，比如把输入改成336x336，原因是336除以14正好是24，可以多出细节又不会让序列爆炸。
2.2 线性投影：每一个小豆腐块都会“说人话”
切出196个小块之后呢？每个小块还是一个 16x16x3 的像素矩阵，这一步需要把它压缩成一个向量。具体做法是把每个patch拉平成一维向量，维度是 16x16x3=768，然后过一个可学习的线性层，也就是一个矩阵乘法：
token_vector = flatten(patch) @ W_proj + b_projW_proj 的形状一般是 [768, hidden_size]，如果你用的是ViT-Base，hidden_size=768，乘出来就是一个768维的向量。这整个操作叫“Patch Embedding”。
这个线性层到底在干吗？一句话：把768维的原始像素信息压缩、重排成768维的语义空间向量。这个过程很像查字典——只不过这个字典是通过训练学出来的。像素值本身是一个绝对物理量，模型很难直接拿来做语义对比，但经过线性变换之后，每个patch向量所处的位置就落在了一个“语义空间”里：相近语义的图像块，在这个空间里的距离更近。
2.3 把位置信息编进去，不然零件还是那堆零件
光有196个向量还不够。Transformer的注意力机制本身是不感知顺序的，它把所有输入向量当成一堆无序的集合。对文本来说，"我爱你"和"你爱我"完全反义，对图像来说，左上角的猫和右上角的猫天差地别。所以必须给每个Token补一个位置编码。
最常用的方案是可学习位置编码：初始化一个 [196, 768] 的可训练矩阵，加到patch embedding上。
token_sequence = patch_embeddings + pos_embeddings在图像这个场景里，位置编码的意义甚至比文本更复杂。文本的位置是一维的“第几个词”，图像的位置是二维的“第几行第几列”。所以有些实现会把位置编码拆成行方向+列方向来处理，比如Swin Transformer里就用到了相对位置偏移表。但ViT的做法相对简单粗暴，直接用二维可学习位置编码，效果也足够好。
2.4 那个特殊的CLS Token：整张图的“代言人”
在ViT的标准实现中，所有patch token前面还会拼接一个特殊的可学习向量，叫CLS token，它自己也有一个专属位置编码。这一步很多人不理解：为什么要塞一个啥内容都没有的向量进去？
打个比方：CLS token就像班级里选出来的班长，他本身不需要交作业，但每次老师提问（分类任务）都让他来回答。通过训练，模型学会了把“整张图总结出来的全局信息”浓缩到这个向量里。在预训练阶段，这个向量后面接的是对比学习或者分类头；在微调阶段，它也可以直接作为整个图像的代表向量。但它不是必须的——一些模型比如DeiT变体会用所有token的平均池化来代替CLS，也能得到不错的效果，只是ViT从架构上沿袭了BERT的习惯，保留了CLS token这一路。
做完这四步，一张 224x224 的照片就变成了一个 1x197x768 的张量，其中197是196个patch token加1个CLS token。这就是照片变成Token的完整链路。
3. 视频帧的专属难题：时间轴、冗余帧与计算量爆破
3.1 视频的本质是一堆长得差不多的照片
如果说照片是一帧，那视频就是一连串帧。一个10秒的视频，30fps的话就是300帧。每一帧拿出来都可以单独走一遍第二节的流程。但问题来了——如果简单粗暴地把300帧每帧都切成196个Token，那就是58800个Token。就算主流模型的上下文窗口是128K，这也占据了小半壁江山，自注意力计算量更是呈平方级爆炸。
而且别忘了，视频相邻帧之间存在大量冗余：同一只猫在镜头前待了3秒，这期间它可能只是耳朵动了动，背景基本没变。如果每一帧都独立切patch、独立编码，模型会接收到海量几乎一样的信息，纯粹的浪费。
3.2 视频Token化的主流思路：先抽帧，再编码
目前实际项目中处理视频输入，最主流的做法不是“逐帧全部处理”，而是“先采样抽帧，再对采样帧做图像Token化”。比如一个5秒的视频，我们每秒抽1帧，一共5帧，每帧得到196个Token，合计980个Token。这个数量级就能被绝大多数LLM（大语言模型）接受了。
关键问题在于怎么抽：
- 均匀抽帧：每隔固定间隔取一帧，简单可靠，比如
fps=1就是每秒一帧。 - 关键帧抽帧：只取I帧（关键帧），这些帧是完整编码的，信息密度最高，B帧和P帧只是差分，单独取出来没有意义。这种方式适合做视频摘要。
- 场景切分抽帧：先做镜头检测，每个镜头取代表性的几帧。复杂一点，但效果最好，适合长视频。
3.3 把时间维写进Token：3D Patch和Tube Embedding
抽完帧之后，每一帧依然是独立的图像。但视频本质上是有时间维度的——同一只猫在第1秒和第5秒出现，模型应该知道它的动作轨迹。所以只做纯空间Token化还不够，得把时间信息也编进去。
学术界有一系列做法，最经典的是Tube Embedding：把连续几帧里处在同一空间位置的patch堆叠成一个“管道”式的3D块，然后对这个3D块整体做embedding，相当于一次性把时空信息编码进一个Token。另一个代表是TimeSformer，它先把每一帧单独做空间注意力，再做跨帧的时间注意力，把注意力的计算拆成两个阶段，大幅降低了计算复杂度。
工业界落地的时候更简洁：直接给每一帧的Token序列拼接一个“帧序号”编码，或者把帧序号当作一个额外的特殊Token拼在每帧开头。这种方式有点像是给视觉Token加上了“第几集”的标签，让模型知道信息在时间轴上的排布。
3.4 一个易被忽视的边界：视频长并不等于Token越多越好
我会在后面的实操部分给出具体计算。但这里先点一句：如果你的模型上下文窗口是4096，那么Token预算大概只有4000个。按每秒1帧、每帧196个Token来算，20秒视频就已经3920个Token，几乎占满。所以一旦项目涉及长视频，你必须提前设计好Token压缩率，而不是任由抽帧数量膨胀。
常用的压缩技巧：
- 降分辨率：把每帧从224x224降到112x112，patch不变的情况下Token数从196降到49。
- 增加patch_size：把16改成32，Token数直接除以4。
- 增加抽帧间隔：从fps=1改成fps=0.5，每秒只取半帧，即2秒一帧。
- 帧融合：把相邻4帧的Token做池化，产生一个聚合Token，兼顾连续性和压缩率。
4. 从ffmpeg查询到逐帧导出：亲手把一段视频变成Token矩阵
概念讲完了，这一节我们上手。我用ffmpeg把一段视频逐帧导出，再用Python模拟Patch Embedding，整个过程能让你“看见”Token是怎么从视频里长出来的。
4.1 ffprobe：先摸清视频的底细
处理任何视频之前，第一步都是搞清楚它有多少帧、什么分辨率、什么帧率。我一般用ffprobe，它是ffmpeg家族里的“侦察兵”。命令如下：
ffprobe -v error -select_streams v:0 \ -show_entries stream=width,height,r_frame_rate,duration \ -of default=noprint_wrappers=1 input.mp4输出大概是这样的：
width=1920 height=1080 r_frame_rate=30/1 duration=10.000000这几个参数直接决定了你的Token预算：
- 帧率是30fps，时长10秒，共300帧。
- 如果每帧都转Token，以224x224、patch16计算，就是300x196=58800个Token。
- 这显然不现实，所以接下来要按策略抽帧。
4.2 ffmpeg按需求抽帧：两种最常见方式
场景一：均匀抽帧，每秒取一帧。
mkdir -p frames ffmpeg -i input.mp4 -vf "fps=1,scale=224:224" frames/frame_%04d.jpg这条命令做了两件事：按每秒1张的频率抽帧，同时把每帧缩放到224x224。frame_%04d.jpg的意思是输出文件名按 frame_0001.jpg、frame_0002.jpg 这样递增。如果你的输入是1080p，直接缩到224x224会变形，所以在生产中通常还会加上crop逻辑，先按中心裁剪成正方形再缩放：
ffmpeg -i input.mp4 -vf "crop=ih:ih:(iw-ih)/2:0,scale=224:224,fps=1" frames/frame_%04d.jpg这个裁剪表达式解释一下：crop=ih:ih表示裁剪区域的宽和高都等于原视频的高，这样就得到一个正方形；(iw-ih)/2是居中偏移。生产项目里推荐用这个，避免画面被拉伸失真。
场景二：只取关键帧，适合做视频摘要。
ffmpeg -i input.mp4 -vf "select='eq(pict_type,I)',scale=224:224" -vsync vfr frames/keyframe_%04d.jpgeq(pict_type,I)是筛选条件，只保留I帧，-vsync vfr表示不强制补齐缺失的帧数。
4.3 Python模拟Patch Embedding：把一张帧变成Token矩阵
帧导出之后，我用Python来模拟ViT的Patch切分和线性投影。先读入一张帧，切成16x16的patch，拉平后乘一个模拟的投影矩阵。完整代码如下：
import cv2 import numpy as np img = cv2.imread("frames/frame_0001.jpg") img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) # BGR转RGB H, W, C = img.shape print(f"输入图像尺寸: {H}x{W}x{C}") patch_size = 16 num_patches_h = H // patch_size num_patches_w = W // patch_size num_patches = num_patches_h * num_patches_w print(f"Patch数量: {num_patches_h}x{num_patches_w}={num_patches}") hidden_size = 768 patch_dim = patch_size * patch_size * C # 16*16*3=768 patches = np.zeros((num_patches, patch_dim)) idx = 0 for i in range(num_patches_h): for j in range(num_patches_w): patch = img[i*patch_size:(i+1)*patch_size, j*patch_size:(j+1)*patch_size] patches[idx] = patch.flatten() idx += 1 # 模拟线性投影层 W_proj: [patch_dim, hidden_size] np.random.seed(42) W_proj = np.random.randn(patch_dim, hidden_size).astype(np.float32) / np.sqrt(patch_dim) b_proj = np.zeros(hidden_size, dtype=np.float32) token_embeddings = patches @ W_proj + b_proj # shape: [196, 768] print(f"Token矩阵形状: {token_embeddings.shape}")这里patch_dim=768是个有趣的巧合——16x16x3正好也是768，和ViT-Base的hidden_size一样。很多初学者会以为这个数字有某种深意，其实纯属维度巧合：patch拉平后是768维，经过W_proj映射到768维，恰好不升不降。如果是ViT-Large，hidden_size=1024，维度就从768升到1024，这才是正常情况。
4.4 加入位置编码和CLS Token
拿到token_embeddings后，再接上位置编码和CLS token：
# 可学习位置编码: [196, 768] pos_embeddings = np.random.randn(num_patches, hidden_size).astype(np.float32) * 0.02 # CLS token + 对应位置编码 cls_token = np.random.randn(1, hidden_size).astype(np.float32) * 0.02 cls_pos = np.random.randn(1, hidden_size).astype(np.float32) * 0.02 final_tokens = np.concatenate([cls_token + cls_pos, token_embeddings + pos_embeddings], axis=0) print(f"最终输入Transformer的序列形状: {final_tokens.shape}") # [197, 768]到这里，“照片变成软Token”的最后一环也完成了。如果把整个视频5帧都压进来，得到的形状就是[5*197, 768]，也就是985个Token。这个序列可以直接拼进任何标准的Transformer Block里面做注意力计算。
5. 软Token到底“软”在哪：视觉Token与文本Token的本质差异
5.1 文本Token是离散的“硬编码”，视觉Token是连续的“软向量”
为什么我们反复强调“软Token”？要理解这件事，得先看看文本Token是怎么来的。
文本走的是Tokenizer：一句话先被切成词或子词，然后每个词查词表拿到一个整数ID。举个直观的例子，“猫”查表得到ID值是 8934，“狗”查表得到 6732。这个ID是离散的、唯一的、不可微的——你不可能给“猫”这个ID加上0.1，它就不再是“猫”了，中间没有任何可导的梯度通路。这是“硬Token”。
视觉Token完全不是这个路数。我们前面做的 Patch Embedding，输入是连续的像素值，过了一个可学习的线性层，输出还是连续向量。这里没有查表、没有离散化、没有argmax，每一段都是可导的。所以你在第五章节看到的那个模拟的W_proj矩阵，在实际训练中会被梯度持续更新，从而不断调整“什么样的像素组合应该落在语义空间的什么位置”。
软Token的核心价值就在于可微与可学习。
5.2 软Token让视觉和文本落在同一个向量世界里
还有一个非常关键的细节：做完Patch Embedding之后，视觉Token的维度是 hidden_size（比如768），文本Token的embedding维度也是hidden_size。这两者可以直接拼接到同一个序列里，一起进Transformer。
这正是LLaVA这类模型的做法：图片走CLIP的视觉编码器得到576个Token（336x336分辨率，patch14），文本走语言模型的embedding，二者拼成一个混合序列。模型在这个混合序列上做自注意力时，视觉Token和文本Token会互相做attention——图片里的“红色圆形”可以和文字里的“苹果”产生关联。跨模态对齐就是在这个“共享向量空间”里完成的。
而软Token还有一层更极致的玩法：在一些Prompt Tuning方法里，甚至可以在输入序列前面加一串纯随机的、没有实际语义的连续向量，通过训练让这串向量学会携带特定任务的信息。这种向量也被叫作“软提示”，和视觉软Token在形态上是一家人——它们都是连续的、可学习的、作为模型输入前缀参与计算的向量。
5.3 视觉Token的“语义密度”远低于文本Token
这里要泼一盆冷水：虽然照片变成了和文本同构的Token序列，但这并不代表197个视觉Token的信息量能抵得上197个文本Token。实际情况是，一个文本Token往往携带了高度浓缩的语义（比如“苹果”两个字就激活了完整的概念），而一个视觉Patch Token通常只描述了画面中很小的一个局部纹理。这就是为什么视觉任务通常需要比文本任务多得多的Token才能get到同样的语义——一张图196个Token，很多模型还是需要预先用CLIP做对齐、或者在后端接一个Query Transformer来做注意力池化（如Flamingo的做法），本质都是在压缩视觉Token的语义冗余。
5.4 从软Token到理解：视觉Token只是“原材料”
最后强调一个常见认知误区：视觉Token并不是“模型看懂了图片”的最终形态。它只是把图片切碎、编码、排序后的“原材料”。模型真正理解图片，靠的是后面几十层Transformer对这批Token做多轮注意力计算——某一层关注到猫的耳朵和眼睛的Token关系，另一层把“毛茸茸”的纹理Token和“猫”的语义Token关联起来。所谓多模态理解，底层也就是这些Token之间一层层做attention的结果。
6. 做视觉Token化时，我踩过的坑和现在的处理习惯
6.1 别盲目堆分辨率，位置编码会先崩溃
有一段时间我为了提升精度，直接把输入图片从224x224加到448x448，patch_size保持16不变。Token数量直接从196变成了784。模型倒是没报错，但效果反而变差了。
排查后发现两个问题：第一，预训练模型的位置编码是196个位置训练出来的，你强行塞784个位置，新位置没有被训练过，模型“不认识”这些位置；第二，即便用插值强行拉伸位置编码，高频细节的位置关系也已经被破坏。后来的处理习惯是，如果确实需要高分辨率，优先考虑保留局部信息的混合架构（比如把高分辨率的小图patch和低分辨率的全局Token同时输入），而不是简单放大分辨率。实测下来，用多尺度融合的效果比单张高分辨率输入要稳定得多。
6.2 抽帧别贪多，Token永远比你想象的更容易爆
还是那句话：10秒30fps的视频，逐帧Token化是58800个Token。这在很多模型里已经逼近或超过输入上限了。我做视频理解项目时，每段视频统一用每秒1帧、224x224、patch16的标准配置，Token数大概980个/10秒视频。如果需要更高时间精度，我会把帧率提到2fps，但同步降低分辨率到168x168（会得到 10x10=100 个patch/frame），总Token数控制在 2fps x 10秒 x 100patch = 2000左右。先算后跑，养成习惯。
6.3 ffmpeg输出格式的坑：千万别忽略位深和色彩空间
这个坑我印象太深了。ffmpeg默认导出jpg是8bit RGB，但如果你的源视频是10bit HDR，导出的画面色调会发灰、发暗。模型喂这种图，embedding出的Token和训练分布偏差极大，精度会掉得莫名其妙。
现在的处理习惯是在ffmpeg命令里显式加色彩空间转换：
ffmpeg -i input.mp4 -vf "crop=ih:ih:(iw-ih)/2:0,scale=224:224,fps=1,format=yuv420p,eq=gamma=1.0" frames/frame_%04d.jpgformat=yuv420p是确保输出格式统一，eq=gamma=1.0是我常用的色彩校正保护。这种问题在纯看视频时发现不了，但一旦做视觉Token化，所有像素差异都会通过Embedding被放大进语义空间，不可不防。
6.4 生产环境的建议：直接把Token化搬进Dataloader
最后一个经验，送给准备做工程的同学：千万别把所有帧先导成jpg存盘，再训练的时候读盘转Token。这么做的IO开销和时间成本完全是浪费的。正确做法是在Dataloader里用PyAV或OpenCV直接读视频流，在内存里完成抽帧、缩放、Patch化，CPU算子解包直接出Token。我这边生产环境用的是一套基于PyAV的读取管线，4秒内可以完成一段10秒视频的全部Token化，比“ffmpeg导图+OpenCV读图”的方案快了一个数量级。这样做还有一个额外好处：抽帧参数和图像增强可以直接联动，比如每帧做随机裁剪和色彩抖动时，Token的自然分布也会跟着变化，模型泛化性会好不少。
视觉Token化是一条不复杂但细节极多的链路。从照片的Patch切分，到视频帧的抽帧策略，再到软Token如何在神经网络的梯度中“呼吸”，每一步都决定了最后模型能否真的“看懂”画面。我自己最大的体会是：动手跑一遍，哪怕只是把几行模拟代码执行一次，对这套机制的理解会完全不一样。尤其是你自己亲手把一段视频变成了一堆数字矩阵之后，再去读各种多模态模型的代码，会顺畅很多——因为它们绝大多数工作都在处理你看过的那种Token序列。
