嗨大家好，我是你们的老朋友小米，31岁，Java程序员，热爱研究新技术。上周在公司茶水间碰到产品经理老王，眉头紧锁地说他正在折腾“AI助手”，但老是搞不懂为啥我们用OpenAI的模型特别顺，换个模型就各种报错。
我一听这不就是Spring AI 聊天模型兼容性和功能支持的问题嘛！今天这篇文章，我就用讲故事的方式，跟大家聊聊我踩过的那些坑、试过的那些模型，从以下几个维度横向对比一下目前 Spring AI 支持的主要聊天模型：
- 多模态能力
- 工具/函数调用
- 流式传输支持
- 重试机制
- 可观察性
- 内置 JSON 返回
- 本地部署能力
- OpenAI API 兼容性
我们会聊到 OpenAI、Gemini、Mistral、Ollama、Cohere、HuggingFace、Azure OpenAI、AWS Bedrock 等八位“大佬”。结尾附上模型对比表格，省你反复试错。
项目上线前的一通电话
先说个故事：我有个朋友阿辉，前段时间负责给他们 SaaS 系统接入一个 AI 文档问答功能。一开始用的是 OpenAI 的 GPT-4，体验绝佳，轻松接入 Spring AI，效果一级棒。但后来出于成本和隐私考虑，公司领导一句话：“能不能换成本更低还能本地部署的？”
他立刻找上我：“小米，Spring AI 支持 Ollama 你知道吧？Mistral 的模型不错吧？我能不能直接替换模型实现？”
“能是能，”我说，“但得看你要哪些功能。”
于是我把我踩过的坑、试过的模型，整理成了这篇“大乱斗”。
多模态：谁能听我说图？
OpenAI 的 GPT-4（尤其是 gpt-4o）和 Google Gemini 可谓是目前多模态界的双子星。Spring AI 在 GeminiChatClient 和 OpenAiChatClient 都支持传入图片内容，甚至是图片+文字混合对话。
但其他模型，比如：
- Ollama（用 Mistral、LLaMA）
- HuggingFace（多数模型）
- Cohere
- Bedrock
对不起，目前 Spring AI 上基本 不支持多模态输入，即使模型本身可能能支持，客户端也不支持构建复杂的 message 结构传入图片。
所以如果你的应用对图文理解强依赖，目前首选还是 GPT-4o 和 Gemini。
函数/工具调用：谁能打通业务？
这个功能对我们开发者来说超关键！比如让 AI 调用一个天气 API、查数据库、生成报告等。
目前 Spring AI 对函数调用的支持主要依赖 OpenAI 风格的 Function Calling（也支持 Tools 格式），支持程度如下：
- OpenAI：完美支持 function/tools
- Azure OpenAI：等同支持
- Gemini（v1） ：支持，走 tools 格式
- Cohere：支持类似 function 的调用，但配置复杂
- Ollama、Mistral、HuggingFace、Bedrock：Spring AI 暂不支持函数/工具调用能力
所以如果你想接入 AI + 工具协作的应用场景，例如“AI 助手查快递”、“AI 执行 SQL”，OpenAI、Azure OpenAI 和 Gemini 是你的首选。
流式传输：速度体验谁更爽？
这个功能我太有发言权了。很多用户都吐槽：“模型响应慢？是不是挂了？”
其实不一定——没用流式。
流式传输（Streaming）让你可以边生成边渲染，非常适合用户体验提升。
- OpenAI/Azure OpenAI：完美支持，Spring AI 用 StreamingChatClient
- Ollama：本地部署也支持流式，效果不错
- Mistral via OpenAI API：只要走 OpenAI 协议也支持
- Gemini：支持，但不够灵活，Spring AI 还在优化中
- Cohere、HuggingFace、Bedrock：基本都不支持
所以想实现像 Notion AI 那种字一个一个打出来的感觉？推荐 OpenAI 或本地 Ollama。
重试机制：谁更健壮？
在实际应用中，调用模型难免超时、限流、报错。Spring AI 支持通过 Spring Retry 配置自动重试。但前提是底层客户端要能抛出明确异常。
- OpenAI、Azure OpenAI：标准 SDK，异常结构规范，重试稳定
- Gemini：Google 的 SDK 稍有差异，但支持
- HuggingFace、Cohere：需自己配置
- Ollama、Mistral 本地 HTTP 模型：异常捕获不稳定
所以如果你想让模型服务稳如老狗，推荐还是主流云模型或 Spring AI 自带客户端。
可观察性：谁告诉我哪里慢了？
作为一个追求可观测性的小米，我最在意的就是：请求耗时多少？模型在做啥？有没有报错？
Spring AI 自带了对 ObservationRegistry 的集成，能与 Micrometer 配合打通 Prometheus、Grafana 监控。
但可惜并不是所有模型都能暴露详细 trace：
- OpenAI / Azure / Gemini：支持全链路 trace
- Ollama / HuggingFace：可通过日志 hack 一些信息
- Mistral / Bedrock：缺少完善的 observability 接口
内置 JSON 返回能力：谁能直接搞定结构化数据？
用 AI 生成结构化 JSON，是不少 AI 工程应用的刚需。Spring AI 提供 JsonOutputParser 搭配 FunctionCall 实现结构化响应解析。
但模型能不能理解“你必须生成一个 JSON”？很关键。
- OpenAI GPT-4：系统指令强大，格式严格可控
- Gemini：输出 JSON 准确率高
- Ollama：有时候格式跑飞
- HuggingFace / Bedrock：大概率返回乱码结构
建议 JSON 输出相关的任务，首选还是 GPT-4 或 Gemini。
本地部署能力：谁最自由？
这点是很多团队转向本地部署的重要原因：隐私、安全、无网也能跑。
目前 Spring AI 最好用的本地模型是：
- Ollama（支持 Mistral、LLaMA、Phi 等）
- LM Studio（兼容 OpenAI 接口）
- HuggingFace 本地部署需自己写代码打包
- Gemini、OpenAI、Cohere、Bedrock：均为云模型
所以如果你需要脱网运行，Spring AI + Ollama 是最佳拍档。
OpenAI API 兼容性：谁是“影分身”？
最让我惊喜的是，Spring AI 并不是只支持 OpenAI！只要有兼容 OpenAI 协议的模型，就能直接接入，比如：
- Mistral.ai 的 HTTP 接口
- Ollama
- LM Studio
- Groq（最近也火）
这也是 Spring AI 的魅力所在：一套代码，多个模型复用，轻松切换。
最终总结表格
聊完你更想用哪个？
阿辉听完之后感慨万千：“原来换个模型这么复杂，早知道直接用 OpenAI 或者 Ollama 多省心。”
是啊，Spring AI 给我们提供了很棒的抽象层，但选择模型的时候，功能支持差异还是得仔细比较。
如果你正考虑接入 Spring AI，不妨先理清楚自己的需求，再结合上表选择合适的模型 —— 这样才能事半功倍！
END
我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
如果你觉得有帮助，记得点个 【在看】 和 【分享】 给你的技术小伙伴哦！
