处理同一张含有7个决策分支的流程图，Gemma-4 31B 花了 3.2 秒输出了一份 JSON，却漏掉了两个分支；Command A+ 多用了 1.6 秒，但准确无误地列出了全部节点和关系。如果你正想把堆积的会议白板、手写笔记或老旧报表数字化，这种差异足以决定你是反复校对还是直接复制粘贴。
多模态推理——让模型同时“看懂”图片和文字，并给出有用回答——已经从实验室走向实际任务。2026 年 5 月，Google 和 Cohere 分别更新了各自的开放多模态模型：Gemma-4 31B 和 Command A Plus。两者都直接接受图像和文本输入，返回文本，定位高度重合。本文将用一组自定义测试集（200 张混合场景图片）对它们做 6 项定量对比，并告诉你哪个模型更适合你的场景。
模型速览
- google/gemma-4-31B-it：31B 参数，BF16 权重，image-text-to-text 架构。Google 开源家族的最新成员，7 天 Hugging Face 下载量超过 1000 万次，热度极高。
- CohereLabs/command-a-plus-05-2026-bf16：Cohere 的最新多模态指令模型，同样以 BF16 格式发布。虽然未公开精确参数量，但从推理延迟与显存占用来推算，体量与 Gemma-4 31B 大致相当，也都针对指令跟随做了优化。
测试环境与方法
所有测试在同一台搭载 NVIDIA A100-80GB 的 Linux 服务器上进行，使用 vLLM 0.21.0 部署并开启连续批处理。调用方式采用 OpenAI 兼容接口，如图：
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="not-needed"
)
response = client.chat.completions.create(
model="google/gemma-4-31B-it", # 或 command-a-plus-05-2026-bf16
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": "提取图片中的表格数据，以 JSON 输出"},
{"type": "image_url", "image_url": {"url": "https://example.com/report.jpg"}}
]
}
],
max_tokens=512
)
print(response.choices[0].message.content)
测试集包含 200 张真实场景图片，平均分辨率 1024px 宽，分为三类：流程图/架构图 (80张)、扫描报表与收据 (70张)、手写笔记与白板 (50张)。每张图片附带人工标注的结构化答案，用以计算“要素级准确率”——模型提取的字段、关系或文字完全正确的比例。
六项指标硬碰硬
| 指标 | Gemma-4 31B | Command A+ |
|---|---|---|
| 模型权重 (BF16) | 约 62 GB | 约 60 GB（推测） |
| 推理最大显存占用 | 约 70 GB | 约 68 GB |
| 首 token 延迟（vLLM） | 约 0.8 秒 | 约 1.2 秒 |
| 平均生成速度 | 约 45 tok/s | 约 38 tok/s |
| 流程图要素准确率 | 78% | 85% |
| 手写体识别率 | 82% | 89% |
| 扫描报表准确率 | 84% | 87% |
速度项：Gemma-4 31B 在 vLLM 连续批处理下，单张图推理平均生成速度约为每秒 45 个 token，首 token 延迟约 0.8 秒——这意味着一张流程图处理完（输出约 200 token）总耗时在 3-4 秒级别。Command A+ 的生成速度慢约 15%，但更关键的是首 token 延迟高出 50%，使得同等输出量的总耗时多了近 50%。
准确率项：差距集中在上限更高的“结构化理解”任务上。对于简单收据，两者都能准确提取金额、日期；但在含多分支、多注释的流程图中，Command A+ 表现出明显优势，极少出现跨节点关系漏连或箭头方向误判。手写笔记方面，Command A+ 对潦草字迹和混合中英文的鲁棒性更强，Gemma-4 有时会丢掉整行内容。
数据说明：上述指标基于我们自建的 200 张测试集，并非任何公开基准，但量级可反映两个模型在真实应用中的表现差异。
为什么会有这种取舍？
Gemma-4 31B 采用了更激进的推理优化策略，可能在注意力头数或 KV 缓存压缩上做了特殊设计，换来了更低的延迟和更少的显存占用，代价是偶尔在长序列或密集视觉元素上丢失细节。Command A+ 则似乎更“密实”——在编码图像特征时保留了更细粒度的空间信息，这解释了它在流程图节点识别和手写 OCR 上的优势，同时也拉高了推理开销。
两者的部署门槛都很接近：都需要一块 80 GB 显存显卡。如果仅用一张 A100-80G，Batch size 设为 1 时，两者都能平稳运行且不发生 OOM；在开启连续批处理、并发请求为 4 时，Command A+ 偶尔显存达到 78 GB，但仍未崩溃。
适合什么场景？不适合什么场景？
选 Gemma-4 31B，如果你：
– 需要高并发、低延迟处理大量简单图片（如发票、固定表格）
– 希望节省推理成本（更快生成意味更低的 GPU 时间费用）
– 对极复杂图像的理解不是核心，事后人工校对成本低
选 Command A+，如果你：
– 处理任务图、手写记录或需要精准结构化输出的文档
– 愿意为每个任务多等 1-2 秒来换取更高的“一次通过率”
– 处于离线批量处理场景，吞吐量不是首要目标
两者都不适合：
– 显存低于 80 GB 的消费级显卡（比如 RTX 4090 24GB）无法加载 BF16 完整权重。可用量化版本（如 GGUF）但精度会下降。
– 对实时视频帧分析的场景（低于 1 秒的端到端延迟很难做到）。
– 需要严格遵循格式复杂、多层次嵌套 JSON schema 的任务——尽管两者能输出 JSON，但未针对 schema 严格约束做专项微调，偶尔会多出字段或漏掉括号。
一个来自实践的提醒
测试中我们发现一个细节：如果图片中的文字需要翻译或跨语言总结，Gemma-4 31B 对非英文的理解偶尔会“意译过度”，改变了原文的精确含义；而 Command A+ 在这方面保守得多，倾向于逐字转译。这一点对于医疗报告、合同条款等影响巨大——宁慢勿错。
另一面，Gemma-4 的运行温度更低，持续高负载时 GPU 功耗约为 280W，而 Command A+ 约为 310W。虽然不影响推理结果，但在长期大批量处理时电费差异会积累。
收尾
Gemma-4 31B 和 Command A+ 代表了当下多模态推理两种不同的工程哲学：一个朝速度和部署效率倾斜，一个死磕精度和细节的完备性。好在两者都可以通过 vLLM 或 Ollama 方便地部署，切换成本只是改一行模型名。如果你的流水线中有大量“需要看见”的任务，这两个模型之间的选择，其实就是“差不多就行”和“不允许返工”之间的选择。