【免费下载链接】InternVL_2_5_HiCo_R64项目地址https://ai.gitcode.com/OpenGVLab/InternVL_2_5_HiCo_R64点击查看免费下载InternVL2.5_HiCo_R64OpenGVLab 开源的长视频多模态大语言模型在处理长视频时最常被吐槽的就是显存不足和推理太慢。好消息是这个模型本身就内置了 HiCo 层级 token 压缩技术每帧只需 64 个视觉 token即 R64只要掌握下面 10 个工程优化技巧绝大多数 24GB 显卡都能流畅跑起长视频推理。一、先搞懂显存去哪了InternVL2.5_HiCo_R64 的模型结构在动手优化之前先明白显存被谁占走了视觉编码器ViT负责把视频帧切块、提取特征源码见 modeling_intern_vit.py语言模型InternLM2.5-7B负责理解视频内容并生成回答源码见 modeling_internlm2.py权重总量全部参数以 bfloat16 存储合计约16.1GB见 model.safetensors.index.json 中的total_size字段分 4 个 safetensors 文件存储也就是说光加载模型权重就要占掉约 16GB 显存再加上 KV Cache 和激活值开销。24GB 显卡如 RTX 4090/3090比较从容16GB 显卡则需要配合下面的技巧精打细算。二、10 个工程优化技巧清单技巧 1用 bfloat16 加载模型显存立省一半模型默认精度就是 bfloat16见 config.json 中的torch_dtype字段。加载时保持半精度即可避免被某些库默认转成 float32model AutoModel.from_pretrained(model_path, trust_remote_codeTrue) model model.to(torch.bfloat16).cuda()⚠️ 不要用 fp16InternLM2 的激活值范围较大fp16 容易溢出产生 NaN。技巧 2安装 Flash Attention 2显存与速度双降这是收益最高的一步。模型配置中 ViT 和 LLM 都声明了flash_attention_2modeling_internvl_chat_hico.py 会根据 flash-attn 是否安装自动切换注意力实现。装了 flash-attn注意力计算不显式存储完整注意力矩阵长上下文场景下显存占用和耗时都大幅下降没装 flash-attnViT 会打印Warning: Flash Attention is not available, use_flash_attn is set to False.见 modeling_intern_vit.py此时退回 eager 注意力长视频极易 OOMpip install flash-attn --no-build-isolation技巧 3用 num_segments 控制抽帧数量显存随帧数线性增长长视频推理的显存大头是抽帧数。视频加载函数load_video中的num_segments参数直接决定送入模型的帧数num_segments视觉 token 数64/帧适用场景322,048短视频、小显存卡128README 默认8,192长视频理解的主力档位512上限32,768超长视频精细分析需大显存显存占用 ≈ 视觉 token 数 × 序列长度开销帧数翻倍KV Cache 几乎翻倍。显存紧张时优先砍帧数而不是砍其他参数。另外load_video支持get_frame_by_durationTrue模式会按视频时长自动计算帧数并强制限制在128~512 帧之间每 4 秒 1 帧这是官方推荐的安全区间。技巧 4长视频推理建议 max_num1单帧单图块dynamic_preprocess的max_num参数控制每帧最多切成几个 448×448 图块。每多一个图块该帧的视觉 token 就多一份显存开销线性上涨max_num1每帧只保留 1 个图块长视频场景的推荐值README 示例即用此值max_num6细粒度感知能力更强但 token 数最多膨胀 6 倍只适合短片段精析对长视频理解这一目标而言时间维度的信息量远比单帧的空间细节重要max_num1是性价比最高的选择。技巧 5理解 R64 内置压缩别重复造轮子很多人不知道这个模型天生省显存。在 modeling_internvl_chat_hico.py 中local_num_frames 4每 4 帧为一组做层级压缩num_tome_tokens 256一组 4 帧经 ToMe token 合并后只剩 256 个 token摊到每帧仅 64 个这就是 R64 的含义合并算法实现在 merge_tokens 与bipartite_soft_matching函数中也就是说相比未压缩版本每帧 256 个 token视觉 token 已经压缩到 1/4。你不需要再额外做 token 裁剪把力气花在帧数和精度上即可。技巧 6用 bound 参数做时间窗口切片分段处理超长视频load_video的bound参数接受(start, end)时间区间秒配合get_index只抽取指定窗口内的帧。工程上的正确姿势是将 1 小时视频按 10 分钟切窗逐窗推理每个窗口独立加载、推理、释放峰值显存只取决于单窗口帧数汇总各窗口的文字结果再做整体总结这比一次性抽满 512 帧硬扛稳定得多特别适合会议录像、课程视频这类超长素材。技巧 7限制 max_new_tokens生成阶段直接提速官方评测使用的生成配置参考 README.md 与 generation_config.json为generation_config dict(do_sampleFalse, temperature0.0, max_new_tokens1024, top_p0.1, num_beams1)要点do_sampleFalse贪心解码速度最快、结果可复现max_new_tokens1024是上限做选择题/短问答时可压到 64~256生成耗时立降不要开 beam searchnum_beams1显存和耗时都会成倍增加技巧 8多轮对话复用上下文别每轮重编码视频model.chat支持history参数实现见 modeling_internvl_chat_hico.py。追问视频里有几个人刚才那个红色物体是什么这类问题时直接传入上一轮返回的chat_history即可无需重新抽帧、重新跑 ViT第二轮起响应速度接近纯文本对话。技巧 9预处理也是瓶颈缓存抽帧结果、减少重复解码load_video内部用 decord 的VideoReader解码视频num_threads1再逐帧做缩放、切块、归一化。对同一个视频反复提问时把pixel_values抽帧结果缓存到内存或磁盘一次抽帧、多次问答记得统一转成pixel_values.to(torch.bfloat16).to(model.device)避免 CPU→GPU 传输时多一次精度转换开销大批量离线任务可用torch.no_grad()包住整个推理流程跳过不必要的图构建技巧 10OOM 时的调参顺序按性价比排序推理报CUDA out of memory时按以下顺序逐项下调每改一项都重新试跑降num_segments128 → 64 → 32——收益最大降max_num确保为 1降max_new_tokens确认 flash-attn 已生效日志无 Flash Attention 告警用nvidia-smi观察峰值显存为下一档参数留出余量 排查小抄模型配置文件 config.json、对话模板 conversation.py、分词器 tokenization_internlm2.py 都可以作为核对版本与参数行为的依据。三、总结一张表带走核心参数参数推荐值作用精度bfloat16权重约 16.1GB半精度加载flash-attn必装ViT LLM 双加速防 OOMnum_segments32~128控制帧数 控制显存max_num1单帧单图块省 tokenmax_new_tokens按需 64~1024控制生成耗时bound 窗口10 分钟/窗超长视频分段推理一句话总结显存不足时砍帧数、保精度、上 Flash Attention推理太慢时限输出、复历史、分窗口。掌握 InternVL2.5_HiCo_R64 的 R64 压缩机制和这几个关键参数长视频推理在 24GB 显卡上跑起来将不再是难题。赞分享【免费下载链接】InternVL_2_5_HiCo_R64项目地址https://ai.gitcode.com/OpenGVLab/InternVL_2_5_HiCo_R64点击查看免费下载相关推荐WeVisDoc-4B推理优化10大技巧输出截断、显存不足、速度慢一网打尽WeVisDoc 4B推理优化10大技巧输出截断、显存不足、速度慢一网打尽 WeVisDoc 4B 是面向文档页面图片的端到端解析模型由 Qwen3 VL人工智能大模型计算机视觉OCRVideoChat-R1_7B推理调优nframes、max_pixels与显存优化的10个技巧VideoChat R1_7B推理调优nframes、max_pixels与显存优化的10个技巧 VideoChat R1_7B 是基于 Qwen2.5 VLSuperset 地理可视化不显示地图怎么办配置 MAPBOX_API_KEYSuperset 地理可视化不显示地图怎么办配置 MAPBOX_API_KEY 在 Apache Superset 中打开基于 Mapbox 的地理可视化图表数据可视化数据分析后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】InternVL_2_5_HiCo_R64项目地址https://ai.gitcode.com/OpenGVLab/InternVL_2_5_HiCo_R64点击查看免费下载InternVL2.5_HiCo_R64OpenGVLab 开源的长视频多模态大语言模型在处理长视频时最常被吐槽的就是显存不足和推理太慢。好消息是这个模型本身就内置了 HiCo 层级 token 压缩技术每帧只需 64 个视觉 token即 R64只要掌握下面 10 个工程优化技巧绝大多数 24GB 显卡都能流畅跑起长视频推理。一、先搞懂显存去哪了InternVL2.5_HiCo_R64 的模型结构在动手优化之前先明白显存被谁占走了视觉编码器ViT负责把视频帧切块、提取特征源码见 modeling_intern_vit.py语言模型InternLM2.5-7B负责理解视频内容并生成回答源码见 modeling_internlm2.py权重总量全部参数以 bfloat16 存储合计约16.1GB见 model.safetensors.index.json 中的total_size字段分 4 个 safetensors 文件存储也就是说光加载模型权重就要占掉约 16GB 显存再加上 KV Cache 和激活值开销。24GB 显卡如 RTX 4090/3090比较从容16GB 显卡则需要配合下面的技巧精打细算。二、10 个工程优化技巧清单技巧 1用 bfloat16 加载模型显存立省一半模型默认精度就是 bfloat16见 config.json 中的torch_dtype字段。加载时保持半精度即可避免被某些库默认转成 float32model AutoModel.from_pretrained(model_path, trust_remote_codeTrue) model model.to(torch.bfloat16).cuda()⚠️ 不要用 fp16InternLM2 的激活值范围较大fp16 容易溢出产生 NaN。技巧 2安装 Flash Attention 2显存与速度双降这是收益最高的一步。模型配置中 ViT 和 LLM 都声明了flash_attention_2modeling_internvl_chat_hico.py 会根据 flash-attn 是否安装自动切换注意力实现。装了 flash-attn注意力计算不显式存储完整注意力矩阵长上下文场景下显存占用和耗时都大幅下降没装 flash-attnViT 会打印Warning: Flash Attention is not available, use_flash_attn is set to False.见 modeling_intern_vit.py此时退回 eager 注意力长视频极易 OOMpip install flash-attn --no-build-isolation技巧 3用 num_segments 控制抽帧数量显存随帧数线性增长长视频推理的显存大头是抽帧数。视频加载函数load_video中的num_segments参数直接决定送入模型的帧数num_segments视觉 token 数64/帧适用场景322,048短视频、小显存卡128README 默认8,192长视频理解的主力档位512上限32,768超长视频精细分析需大显存显存占用 ≈ 视觉 token 数 × 序列长度开销帧数翻倍KV Cache 几乎翻倍。显存紧张时优先砍帧数而不是砍其他参数。另外load_video支持get_frame_by_durationTrue模式会按视频时长自动计算帧数并强制限制在128~512 帧之间每 4 秒 1 帧这是官方推荐的安全区间。技巧 4长视频推理建议 max_num1单帧单图块dynamic_preprocess的max_num参数控制每帧最多切成几个 448×448 图块。每多一个图块该帧的视觉 token 就多一份显存开销线性上涨max_num1每帧只保留 1 个图块长视频场景的推荐值README 示例即用此值max_num6细粒度感知能力更强但 token 数最多膨胀 6 倍只适合短片段精析对长视频理解这一目标而言时间维度的信息量远比单帧的空间细节重要max_num1是性价比最高的选择。技巧 5理解 R64 内置压缩别重复造轮子很多人不知道这个模型天生省显存。在 modeling_internvl_chat_hico.py 中local_num_frames 4每 4 帧为一组做层级压缩num_tome_tokens 256一组 4 帧经 ToMe token 合并后只剩 256 个 token摊到每帧仅 64 个这就是 R64 的含义合并算法实现在 merge_tokens 与bipartite_soft_matching函数中也就是说相比未压缩版本每帧 256 个 token视觉 token 已经压缩到 1/4。你不需要再额外做 token 裁剪把力气花在帧数和精度上即可。技巧 6用 bound 参数做时间窗口切片分段处理超长视频load_video的bound参数接受(start, end)时间区间秒配合get_index只抽取指定窗口内的帧。工程上的正确姿势是将 1 小时视频按 10 分钟切窗逐窗推理每个窗口独立加载、推理、释放峰值显存只取决于单窗口帧数汇总各窗口的文字结果再做整体总结这比一次性抽满 512 帧硬扛稳定得多特别适合会议录像、课程视频这类超长素材。技巧 7限制 max_new_tokens生成阶段直接提速官方评测使用的生成配置参考 README.md 与 generation_config.json为generation_config dict(do_sampleFalse, temperature0.0, max_new_tokens1024, top_p0.1, num_beams1)要点do_sampleFalse贪心解码速度最快、结果可复现max_new_tokens1024是上限做选择题/短问答时可压到 64~256生成耗时立降不要开 beam searchnum_beams1显存和耗时都会成倍增加技巧 8多轮对话复用上下文别每轮重编码视频model.chat支持history参数实现见 modeling_internvl_chat_hico.py。追问视频里有几个人刚才那个红色物体是什么这类问题时直接传入上一轮返回的chat_history即可无需重新抽帧、重新跑 ViT第二轮起响应速度接近纯文本对话。技巧 9预处理也是瓶颈缓存抽帧结果、减少重复解码load_video内部用 decord 的VideoReader解码视频num_threads1再逐帧做缩放、切块、归一化。对同一个视频反复提问时把pixel_values抽帧结果缓存到内存或磁盘一次抽帧、多次问答记得统一转成pixel_values.to(torch.bfloat16).to(model.device)避免 CPU→GPU 传输时多一次精度转换开销大批量离线任务可用torch.no_grad()包住整个推理流程跳过不必要的图构建技巧 10OOM 时的调参顺序按性价比排序推理报CUDA out of memory时按以下顺序逐项下调每改一项都重新试跑降num_segments128 → 64 → 32——收益最大降max_num确保为 1降max_new_tokens确认 flash-attn 已生效日志无 Flash Attention 告警用nvidia-smi观察峰值显存为下一档参数留出余量 排查小抄模型配置文件 config.json、对话模板 conversation.py、分词器 tokenization_internlm2.py 都可以作为核对版本与参数行为的依据。三、总结一张表带走核心参数参数推荐值作用精度bfloat16权重约 16.1GB半精度加载flash-attn必装ViT LLM 双加速防 OOMnum_segments32~128控制帧数 控制显存max_num1单帧单图块省 tokenmax_new_tokens按需 64~1024控制生成耗时bound 窗口10 分钟/窗超长视频分段推理一句话总结显存不足时砍帧数、保精度、上 Flash Attention推理太慢时限输出、复历史、分窗口。掌握 InternVL2.5_HiCo_R64 的 R64 压缩机制和这几个关键参数长视频推理在 24GB 显卡上跑起来将不再是难题。赞分享【免费下载链接】InternVL_2_5_HiCo_R64项目地址https://ai.gitcode.com/OpenGVLab/InternVL_2_5_HiCo_R64点击查看免费下载相关推荐WeVisDoc-4B推理优化10大技巧输出截断、显存不足、速度慢一网打尽WeVisDoc 4B推理优化10大技巧输出截断、显存不足、速度慢一网打尽 WeVisDoc 4B 是面向文档页面图片的端到端解析模型由 Qwen3 VL人工智能大模型计算机视觉OCRVideoChat-R1_7B推理调优nframes、max_pixels与显存优化的10个技巧VideoChat R1_7B推理调优nframes、max_pixels与显存优化的10个技巧 VideoChat R1_7B 是基于 Qwen2.5 VLSuperset 地理可视化不显示地图怎么办配置 MAPBOX_API_KEYSuperset 地理可视化不显示地图怎么办配置 MAPBOX_API_KEY 在 Apache Superset 中打开基于 Mapbox 的地理可视化图表数据可视化数据分析后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
