图像26ms比文本83ms还快Jev-Omni各模态延迟实测对比【免费下载链接】Jev-Omni项目地址: https://ai.gitcode.com/hf_mirrors/akhilaaa3/Jev-Omni多模态大模型通常意味着「重」视觉编码器、音频编码器、时序对齐、以及一串串自回归生成的 token。但当 Jev-Omni 的实测数据摆出来时结论却反了过来——在 H200 的 warm 推理中图像输入只要 26ms文本却要 83ms13 秒音频 31ms16 帧视频 504ms。图像比文本快三倍这在以「文本是主模态」为默认前提的 LLM 生态里几乎是一种反直觉的信号。这个 12B 参数的开源多模态决策分类器不生成任何解释文本而是对用户给出的选项直接输出校准后的概率分布。本文基于仓库源码与实测数据拆解四条输入路径的延迟差异到底从哪来以及这些数字对实时决策系统的选型意味着什么。四路输入的延迟全表仓库 README.md 的 Speed 一节给出了官方口径的基准H200 warm 推理、20 次优化后端请求的中位数预处理与网络传输时间不计入。输入模态输入规模实测延迟H200 warm端到端参考GB10 实测文本~2k token83 ms~1 s图像单张26 ms~1 s音频13 秒31 ms~1 s视频16 帧504 ms~4 s两套数据口径不同前者是纯模型推理warm、优化后端后者是社区部署实测的端到端时长含 ffmpeg 转码、帧抽取、网络与预处理。理解这个差异很重要模型本身已经快到了个位数毫秒到半秒的级别剩下的延迟大头反而转移到了多模态输入的前处理管道上。这份数据的第二个看点是文本竟然不是最快的。要解释这一点必须回到 Jev-Omni 的架构——它不是一个典型的「聊天式」多模态模型而是一个一次前向传播、零输出 token的分类器。为什么图像反而比文本快投影器与 token 化路径关键在 jev_omni.py 中JevOmni.predict的实现无论哪种模态最终都是self.model(**inputs, use_cacheFalse, ...)的单次前向传播随后从解码器的最后一层隐藏状态直接映射到选项 logits全程没有自回归解码self._capture.clear() with torch.autocast(cuda, dtypetorch.bfloat16): self.model(**inputs, use_cacheFalse, **self._extra) probs self.head(self._capture[hidden], torch.tensor([len(options)], deviceself.device))[0, :len(options)].softmax(-1)use_cacheFalse意味着不存在 KV cache 随生成长度膨胀的问题决策头 _Head256 只是一个归一化后的单层线性映射hidden 3840 → 256 个选项槽位class _Head256(torch.nn.Module): Decision head: normalise the last hidden state, one logit per option slot. def __init__(self, hidden): super().__init__() self.register_buffer(mu, torch.zeros(1, hidden)) self.register_buffer(sd, torch.ones(1, hidden)) self.linear torch.nn.Linear(hidden, 256, dtypetorch.float32)在「单次前向 固定开销决策头」的框架下延迟就几乎只由送入 Transformer 主干的 token 数量与注意力成本决定。四条路径的 token 化策略在 config.json 中一目了然文本约 2k token 直接进入 48 层 Gemma 主干逐 token 走完完整的注意力与 FFN 计算这是 83ms 的来源。图像视觉塔采用patch_size16切分、model_patch_size48、pooling_kernel_size3池化最终压缩为num_soft_tokens280个固定数量的 soft token再经mm_embed_dim3840的投影注入主干。280 个 token 对比 2k 文本 token计算量相差约一个数量级26ms 由此而来。音频audio_samples_per_token640即每 640 个采样点压成一个 token。13 秒 16kHz 单声道音频约 20.8 万样本折算约 300 token与图像同量级31ms 与之吻合。预处理中音频还会被 ffmpeg 限制在 30 秒、重采样到 16kHz 单声道。视频_video_frames对视频均匀采样 16 帧每帧都走完整视觉 token 化路径16 × 280 ≈ 4480 个视觉 token是四条路径中 token 数最多的一条504ms 的差距完全符合预期。所以「图像比文本快」的本质是投影器把图像压缩成了固定且少量的 soft token而文本的 2k token 只能原样进入主干。视觉模态的「信息压缩率」远高于文本在决策分类这种不需要逐 token 生成的范式下反而成了最快的路径。这与生成式多模态模型的直觉完全相反——那边图像往往更慢因为要先生成大量视觉表征再解码。延迟数据对实时决策场景的选型意义把两套延迟数据放在一起会得到一个对工程选型非常有用的结论warm 推理的毫秒级数字证明了架构效率但真实系统预算必须以端到端口径为准。图像与音频26/31ms 的 warm 推理 约 1s 的端到端说明瓶颈在输入解码与预处理图片解码、ffmpeg 转码而不在模型。对于 OCR 审核、票据判定、语音质检这类高频封闭选项场景Jev-Omni 可以把模型耗时压到近乎可忽略系统吞吐主要由 IO 管道决定。文本83ms 对应约 2k token 的输入意味着输入越长文本路径越慢。仓库明确说明该场景按「一次一问」计费——README.md 中指出状态会被重复发送这也解释了为什么长文本批量判定的成本会线性上升。实时决策系统若以文本为主应尽量压缩 state 长度或把短问句判定作为主要形态。视频504ms 的 warm 推理、约 4s 的端到端定位只能是准实时。视频是 16 帧均匀采样后的多帧图像序列token 总量天然最大适合内容审核、事件回放这类秒级容忍的判定不适合逐帧流式决策。成本维度同样值得纳入选型。由于 决策头直接输出概率、不产生任何输出 token推理费用仅由输入 token 决定——README 的成本测算中Jev-Omni 按每次提问一调用的方式计价仍能在 DecisionBench Medium 上拿到 87.57% 的状态宏平均准确率并与商用大模型同框对比而延迟与成本的「快」并没有牺牲概率质量DecisionBench Medium 上 ECE 低至 0.040010 分桶校准曲线紧贴理想对角线一句话总结这份延迟表的工程含义Jev-Omni 的架构把「多模态理解」从生成式范式切换成了判别式范式图像、音频因此享受到 token 压缩的红利成为最快的输入通道文本的延迟与输入长度强相关视频则以秒级为代价换取 16 帧的全局上下文。对实时决策系统而言选型的核心不再是「哪个模态模型跑得快」而是「把模态前处理管道优化到和模型推理同一个量级」——因为 26ms 之后瓶颈早就转移到你自己的代码里了。【免费下载链接】Jev-Omni项目地址: https://ai.gitcode.com/hf_mirrors/akhilaaa3/Jev-Omni创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考