现在大家对基础模型能力诉求越来越高了不再满足文本输入而是混合输入。比如一张界面截图、一份业务图表、一页扫描合同、一张发票等模型不仅要能看懂文件中的内容还要能把内容变成可执行的步骤、提取结构化的信息或者是给出业务结论。也就是说对于多模态的理解和执行能力要求变高了而目前国内支持多模态的几款模型有Step 3.7 Flash、Qwen3.6-flash、MiniMax M3等。那这几款多模态模型在生产环境下的实际表现怎么样呢它们到底能不能用于生产环境以前大家都喜欢看评分榜单说实话估计很多人对榜单分数都没那么在意很多模型的公开分数都很亮眼但真到了具体任务里就歇菜了。这里我们也不玩虚的直接用真实环境的任务来进行横向对比多模态理解和执行能力。测评说明为了测试保证公平性这里我把测评方式和测评标准先摆出来不偏袒任何一家模型行就是行不行就不行只用事实和数据说话。这里我们确保在同一个任务场景下用相同的提示词、相同的配置参数、以及相同的工具或方法来测试不同模型的执行情况唯一的变量就是模型。并且这里把每个任务的执行结果和时间、token消耗都一并呈现出来。最终主要看三个点质量一次对话能不能给出可用结果是否需要反复追问。速度端到端返回是否足够快能不能适合 Agent 高频调用。成本模型单价和token消耗还看后续要不要人工投入。因为评价一个模型能不能在生产环境使用核心就看这三个关键维度。下面我选择了两个案例都是目前公司高频使用到多模态模型的场景一个是在Agent中使用一个是在业务场景以API方式使用。场景一根据流程图还原业务逻辑在写代码前前后端会在一起设计整个技术方案这一步少不了系统架构图或者业务流程图方案敲定之后才进入编码环节而现在有多模态的加持我们完全可以把敲定的流程图给到AI帮我们提取里面方案逻辑并制定实现计划。比如我们需要完成微信小程序的登录鉴权并按照如下流程图的逻辑来实现这里总共分为10步数箭头先把截图放入项目文件中然后打开Claude Code输入如下提示词微信小程序登录方案.png 获取图片中流程逻辑首先是Step 3.7 Flash的输出Step3.7-flash给出了参与方、完整流程、核心设计思路其中识别完整流程为10步总步数和每一步的逻辑与原始流程图完全吻合这里质量输出还是杠杠的。它不仅能识别图片中的文案、还能理解图片中的流程逻辑完整准确无误的表达了流程图的逻辑。下面是MiniMax M3的输出MinMax M3的输出总共也是10个步骤每步的逻辑均正确。下面我再看Qwen3.6-flash的输出Qwen3.6-flash的输出总共为9个步骤比参照标准少了一个步骤它把步骤3、4进行了合并但是整体逻辑是正确的。上面每个任务底部都有对应的模型名称、执行时间、Token消耗这里我把每个模型执行的数据整理到表格中维度Step 3.7 FlashMinMax M3Qwen3.6-flash时间API时间15s20s19sToken消耗(Input、Output、cache Read、cache write)728、1.1k、54.4k、027.9k、1.2k、228、0251、1.9k、0、28.6ktoken价格换算¥0.0246¥0.0688¥0.0483在这个场景下如果只看输出质量其实三个模型没有明显的差距。但是根据我们前面定下的标准来看Step 3.7 Flash的表现更有优势速度更快、成本更低而且生成质量稳定。这个场景非常值得一试开发中有大量的业务流程图之前我们还要花不少时间口述给AI并且容易出错现在有多模态模型的帮助确保质量的同时可以节约很多的时间成本。下面我们再看一个在业务系统中使用多模态模型的案例。场景二利用多模态辅助发票录入系统我们业务中有一个录入票据到系统的环节流程是先拍照上传人工在根据票据信息依次录入系统表单操作起来耗时耗力之前想通过OCR识别来解决但是识别误差很大仍然需要人工确认。因为OCR识别有个问题它是机械的识别信息。目前我们正在借助多模态模型进行优化它的优势是不仅能理解信息还能思考。下面是一张电子发票任务是让模型识别票据中的信息并结构化输出关键字段信息以便自动录入系统减少人工录入成本。这里因为是在业务系统中以API的方式调用因此写了一段测试脚本其中图片地址和提示词都一致其中提示词设置如下请从这张票据图片中提取结构化信息按照如下 JSON 结构返回 { 发票类型string, 发票号码string, 开票日期string, 发票金额string, 税率string, 税额string, 项目名称string 购买方纳税人识别号string, 购买方开户行string, 销售方名称string, 销售方纳税人识别号string, 销售方开户行string, }下面我们还是按照前面的顺序依次来看每个模型的表现。我们先把模型切换到Step 3.7 Flash并运行脚本从结果来看Step 3.7 Flash提取结果完全正确耗时5.6s总消耗1409 tokens。我们在把模型切换到MinMax M3并运行脚本从结果来看MinMax M3提取结果也完全正确耗时6.1s总消耗2216 tokens。下面我们在将模型切换到千问-3.6-flash并运行脚本从结果可以看出千问的表现也很稳的跟前面两个模型的表现差不多没有出现错误提取的情况总耗时7.38s总消耗2008 tokens。这里在汇总下每个模型执行的情况维度Step 3.7 FlashMinMax M3Qwen3.6-flash时间API时间5.6s6.1s7.38sToken消耗(Input、Output、cache Red、cache write)802、607、0、01686、530、1672、01165、843、0、0token价格换算¥0.0060¥0.0086¥0.0075在这个场景中三者的生成质量仍然没有差异都能按照要求的JSON结构对票据中的信息准确提取但是在响应速度和Token的消耗上面Step 3.7 Flash仍然具有优势一些。这个识别成本可以说非常低了一张票据的结构化信息提取成本不到1分钱并且在这张样例发票上三者都能正确提取字段。因此把多模态运用到票据结构化信息提取这个场景下非常值得一试。总结以上这两个案例一个是在Agent中使用一个是在业务接口中使用验证的其实都是同一件事模型拿到复杂视觉输入后能不能根据我们的要求把它转成后续可直接使用的结果。这里我把两个场景下的实测的结果整理到下面这张表里维度Step 3.7 FlashMinMax M3Qwen3.6-flash速度快中中Token消耗少多中Token价格换算为人民币便宜贵中稳定性优优优整体而言在两个场景下三个模型的质量稳定性都很好没有出现错误提取的情况但如果放到生产环境里看质量只是第一关后面还要看响应速度、调用成本和是否适合高频接入。综合这几个维度我个人会更倾向于把 Step 3.7 Flash 放进 Agent 或业务 API 里优先测试。它在两个场景里都保持了比较好的输出质量同时速度更快、Token 消耗更低整体更符合“生产可用”的要求。当然这并不是说一个模型可以覆盖所有场景真正上线前还是要拿自己的业务样本去跑一轮。好了以上测评仅代表个人实际测评大家也可用类似的任务去感受一下Step 3.7 Flash的多模态理解和执行的整体表现。