我把Gemini 3.5 Ultra塞进Spring Cloud，多模态解析成了性能黑洞

我把Gemini 3.5 Ultra塞进Spring Cloud，多模态解析成了性能黑洞

上周四，为了测试新上线的Gemini 3.5 Ultra，我写了一个简单的Spring Boot接口，把本地的一张5MB PNG图转成JSON描述。原本以为只是加个SDK调用，结果那个请求跑了42秒才返回，内存直接飙到16GB。

说实话，我当时第一反应是代码写错了。毕竟Gemini 3.5系列最大的卖点就是那个号称能处理200万token的上下文窗口，还有所谓的"Gemma 3基座融合"。但我检查了三遍代码，网络延迟只有200ms，瓶颈全在本地解析环节。这跟我之前用3.0 Pro跑同样的测试完全不同，3.0的时候RT稳定在800ms，而3.5 Ultra这个版本，处理单张图片的CPU抖动简直让人怀疑人生。

我查了Google I/O 2026的技术文档，里面提到3.5架构做了底层重排，官方吹嘘的是“原生多模态理解效率提升3倍”。但我这边的实测数据并不买账。我选了A方案：直接复用之前的Prompt模板；选了B方案：重写一套针对图像细粒度描述的指令。结果A方案因为模板里没有指定输出约束，模型自作主张输出了几千字的文学性描写，B方案虽然控制了字数，但预处理阶段的图像编码耗时增加了150ms。事后看，两个方案都踩了坑，真正的元凶不是Prompt，而是3.5版本对非文本Token的权重计算逻辑变了。

有意思的是，很多人只盯着那个200万token的总数看，觉得这意味着“什么都能装进去”。但我在生产环境里跑了一整天日志，发现一个被忽略的事实：当你把图像、音频和长文本混在一起喂给模型时，3.5版本的注意力机制会在中间层产生大量的冗余计算。我截取了某次请求的Trace日志，看到光是在做“图像块分割”这一步，就触发了三次无效的上下文窗口刷新。这不是算法缺陷，这是工程化落地时必须面对的隐性成本。

我之前用Opus 4.6的时候，也有过类似的幻觉困扰，但那次主要是内容层面的。这次在3.5 Ultra上，问题出得更隐蔽——它不是在“胡说”，而是在“过度思考”。比如你让它描述一张表格截图，它会先花大量算力去重建表格结构，然后再做内容提取。对于简单的OCR需求，这完全是性能浪费。我试着关了它的某些推理增强选项，RT从1200ms降到了400ms，但准确率反而波动了5%。这个取舍让我纠结了好久。

另外，关于Gemma 3基座的整合，官方说法是“统一了视觉和语言的理解空间”。我在本地复现了这个实验，用纯文本Prompt对比图文混合输入。结果显示，当输入中包含高复杂度的图表时，3.5版本的响应时间确实比纯文本慢了4倍，但比纯视觉模型的拼接调用快了20%。这说明它的融合是有代价的，但这个代价取决于你输入的模态比例。如果你们的业务主要是文本，强行上3.5 Ultra可能得不偿失；如果是重度多模态场景，这个性能折损或许值得。

还有个细节，3.5 Flash-Lite版本我顺手测了一下，发现它在简单分类任务上甚至比Ultra还快，但一旦涉及跨模态的逻辑推理（比如“解释这张图里的数据趋势”），性能断崖式下跌。这让我觉得，Google这次推的多版本策略，其实是在逼开发者根据场景做精细选型，而不是一个模型打天下。

我在工位上盯着那个42秒的超时异常看了很久，突然意识到，之前的很多“降本增效”经验在这里完全不适用。以前我们优化LLM调用，重点在缓存和重试，现在重点得放在输入预处理和Token预算的动态分配上。如果你还在用老的一套配置去调3.5 Ultra，大概率会栽跟头。

你们公司在接入新版多模态模型时，有没有遇到过这种“参数好看、实际拉胯”的情况？或者你们是怎么平衡那种“过度思考”带来的性能损耗的？

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。