本文作者kaiyuanVLM视觉-语言融合全流程解析基于Kimi K2.5/VL想深耕AI Infra领域欢迎访问InfraTech库内容涵盖大模型基础、PyTorch/vLLM/SGLang框架入门、性能加速等核心方向配套50知识干货及适合初学者的notebook练习:https://github.com/CalvinXKY/InfraTechVLMVision-Language Model在处理多模态输入时需要将视频、图像与文本统一到同一套表示中再送入语言模型。本文以原生视觉–语言模型Kimi K2.5为例梳理视觉与语言从输入到进入LLM前的主要步骤。1 整体流程概览整体计算流程可概括为语言模块LLM与视觉模块ViT协同工作。视觉侧数据图像、视频等由 MoonViT[1]处理文本经分词与embedding后与视觉特征在token序列层面融合再一并送入大语言模型做后续计算。结合K2.5的模型结构可以看出数据在与LLM融合前的流转路径。K2.5由MoonViT LLM构成其中LLM侧采用MLA MoE等结构。与一般纯文本LLM相比差异主要在于输入态在VLM中各类模态最终都要变成token序列或与之等价的inputs_embeds才能被语言模型处理。词表除文本token外还会为视觉占位等预留特殊id如配置中的media_placeholder_token_id。高清图地址https://github.com/CalvinXKY/InfraTech/blob/main/models/kimi_k_2_5视觉与语言融合的关键步骤预处理经ImageProcessor完成抽帧视频、尺寸调整、padding再切分为Patch得到模型可用的视觉张量。Patch嵌入对patch做卷积式嵌入并叠加位置编码含时间与空间。编码经多层Encoder堆叠提取高层视觉特征。Patch池化与merge通过merge_kernel等在空间及配置下的时间维度聚合压缩视觉token数量。MM Projector将视觉hidden维度映射到与文本一致的text_hidden_size如MLP / PatchMerger。序列拼接按占位符将视觉特征写入文本embedding序列得到最终送入LLM的inputs_embeds与attention_mask。2 视觉数据的表示图像可由像素张量[W, H, C]描述分别对应宽Width、高Height与通道Channel如RGB。视频可视为带时序的帧序列记为[T, H, W, C]时间维在前与代码中navit_patchify的(T, H, W, C)一致。单帧图像可看作T1的特例。为让LLM处理视觉信息需要建立从[T, H, W, C]到「视觉token」的映射。其中C通常固定如3图像的H/W、视频的T/H/W均可随输入变化因此预处理与patch划分会随分辨率与时序长度调整。朴素做法是将T×H×W×C全部展平再喂网络但参数量与显存不可接受。工程上先通过resize / patch / merge / projector降低token数与维度再提取特征并与文本对齐。2.1 抽帧与尺寸调整视频在时间维上帧率往往较高而模型推理通常不需要逐帧密集采样因此会先抽帧降低有效T。为便于后续patch与对齐会对H、W做缩放并常配合padding使尺寸满足patch_size与merge_kernel的整除约束。在K2.5中经Navit风格resize后的空间尺寸不必全局统一可与原图长宽比相关相比强行统一到固定方形更有利于极端长宽比图像的信息保留。图片分块Patch与抽特征相邻像素往往高度相关不必以单像素为最小单元。ViT类做法是将图像划为多个patch以patch为单元嵌入并编码在相同信息量下显著降低序列长度。patch_size记为P越大token越少、计算越省但细节损失通常越大反之则更细、更耗算力。Patch化后视觉张量常用两项描述pixel_values形状(L, C, P, P)grid_thw形状(T, H, W)其中H H / PW W / P关系为L T × H × W T × (H / P) × (W / P)此处H、W指预处理与padding之后的高宽且需能被P整除。完成Patch与归一化后即可经MoonViT编码。例如某段视频经抽帧与resize后为(T, H, W, C) (2, 504, 644, 3)若vt_hidden_size 1152则编码阶段可得到长度为T×H×W的视觉token序列具体H、W由P与最终H、W决定。2.2 时间维池化Temporal Pooling为继续压缩序列可在时间维对多帧特征做池化默认实现中为对T维求平均。池化后该段视觉在时间上坍缩为单一时间片对应的token集合等价于不再单独保留多帧各自的完整token条带。例如上例中若T2且仅在merge前按时间平均则与两帧各自全长序列相比有效视觉token数会按设计减少具体倍数与merge_kernel、grid共同决定。2.3 投影MM Projector在控制视觉token数量的同时模型通过merge_kernel_size等在空间上分组聚合再经MM Projectormulti-modal projector将视觉hidden映射到与文本embedding相同的最后一维text_hidden_size以便与语言分支在同一向量空间内拼接或替换占位符。2.4 文本与占位符文本经分词器得到token ids序列长度与字符/子词数量相关。同一词可能被拆成多个token取决于tokenizer设计最终都映射为词表中的id。单词的分词与转token ids示例句子转token ids示例在VLM中文本序列里会为视觉内容预留位置通常用特殊占位token表示在配置中对应media_placeholder_token_id。占位符个数一般与视觉条目数图像张数、视频chunk数等一致并与batch内视觉特征列表顺序对齐。2.5 视觉–文本序列合并Merge视觉经projector得到形如[N_img_tokens, text_hidden]的张量文本经embedding得到[seq_len, text_hidden]。在占位符处用对应段的视觉向量展开并替换该位置从而得到合并后的inputs_embeds与更新后的attention_mask及position_ids。下图示意仅含单个视觉输入时例如原文字序列长度为8若该段视觉展开为414个token则合并后序列长度变为8 - 1 414 421减1为去掉一个占位符所占的1个文本位置。2.6 代码演示可参考K2.5相关示例将上述各阶段的shape用脚本打印以便对照。InfraTech[2]库中提供了一条从图像预处理到merge前的流程演示便于逐步核对张量形状与配置项patch_size、merge_kernel_size、grid_thw等代码位置https://github.com/CalvinXKY/InfraTech/blob/main/models/kimi_k_2_5/vision_text_merge_demo.ipynb输出如下 1) 输入图片 PIL size (W,H): (640, 480) 2) resize/pad 配置 {num_tokens: 414, new_width: 640, new_height: 480, pad_width: 4, pad_height: 24, sampled_nframes: 1} 3) resize pad 后 pixel_values (T,H,W,C): (1, 504, 644, 3) 4) normalize 后 normalized (T,H,W,C): (1, 504, 644, 3) 5) patchify 后 pixel_values (L,C,P,P): (1656, 3, 14, 14) grid_thw (T,H,W): (1, 36, 46) grid_thws (B,3): (1, 3) 6) vision tower 编码后(示意) vision_hidden (sum(T*H*W), vt_hidden): (1656, 1024) 7) tpool_patch_merger 后 merged_for_projector (N_img_tokens, K, vt_hidden): (414, 4, 1024) 8) mm_projector 后(示意) image_features (N_img_tokens, text_hidden): (414, 768) 9) merge 前文本输入(示意) input_ids: (1, 12) inputs_embeds(text): (1, 12, 768) attention_mask: (1, 12) placeholder token id: 32000 (位置3) 10) 与图像特征 merge 后(进入LLM前) merged_inputs_embeds: (1, 425, 768) merged_attention_mask: (1, 425) 说明: 1个占位符token被替换为 414 个图像token。小结Kimi K2.5类VLM将图像/视频先经预处理与Patch化得到pixel_values与grid_thw且LT×H’×W’再经MoonViT编码随后用merge含时间池化等压缩视觉token经MM Projector对齐到与文本相同的text_hidden_size。文本侧通过占位符token与视觉条目一一对应最终在序列上做Merge得到送入LLM的inputs_embeds与配套mask。整条链路的要点是视觉与文本在token/向量空间统一再交给语言模型计算。[3]图片源自NVIDIA技术blog参考:[1]https://github.com/MoonshotAI/Kimi-VL[2]https://github.com/CalvinXKY/InfraTech[3]https://developer.nvidia.cn/blog/build-with-kimi-k2-5-multimodal-vlm-using-nvidia-gpu-accelerated-endpointsInfraTech申明未经允许不得转载
)
