spring
很多人问这两个问题，背后其实是同一个担心：Spring AI会不会被某一种部署方式绑死。结论很明确，Spring AI可以集成DeepSeek，而且不限制只能本地调用，你既可以直连DeepSeek云端API，也可以把Spring AI指向你自建的网关或本地推理服务，关键在于把模型提供方的接口地址与鉴权方式配对好。
一、Spring AI可以集成DeepSeek吗
Spring AI可以集成DeepSeek，常见做法是把DeepSeek当成OpenAI兼容接口来接入。DeepSeek官方文档明确说明其API格式兼容OpenAI，并给出了base_url为https://api.deepseek.com，同时也说明可以使用带v1的形式作为兼容入口。
1、先确认你要走云端还是走自建网关
如果你要直连DeepSeek云端，就以DeepSeek官方base_url为准；如果你公司有统一的AI网关，也可以把base_url换成内网网关地址，Spring AI侧的思路不变，只是请求目标变了。
2、把鉴权方式先处理成可部署的形态
在Spring Boot里更稳的做法是把API Key放到环境变量或密钥管理系统，再在应用配置里引用，避免把Key写进仓库；Spring AI的OpenAI集成使用spring.ai.openai.api-key这类配置项来承接Key。
3、配置base-url时要提前选定一种写法并保持一致
DeepSeek既支持https://api.deepseek.com，也支持https://api.deepseek.com/v1作为兼容入口，但Spring AI这边的聊天接口默认会在base-url后追加路径，默认路径是/v1/chat/completions。你如果把base-url写成带/v1的形式，又不调整completions-path，就容易出现路径重复导致请求404。
4、模型名要用DeepSeek侧认可的标识
DeepSeek文档给出的模型标识包含deepseek-chat与deepseek-reasoner，前者偏通用对话，后者偏推理型输出。你在Spring AI里选择模型时，实际就是把这个模型标识传给服务端。
5、接通后先用最短链路做一次验收
建议你先做一个最简单的接口调用页面或临时接口，只验证三件事：请求能到达、能返回内容、延迟与错误码可解释。等这条链路稳定后，再加工具调用、结构化输出或更复杂的提示词，不然一上来就堆功能，很难判断是哪里出了问题。
二、Spring AI是不是只能调用本地DeepSeek
Spring AI不是只能调用本地DeepSeek，它本质上是按模型提供方来配置客户端，你把base-url指到哪里，它就调用哪里。很多人产生只能本地的印象，往往是因为他们用Ollama在本机跑模型，Spring AI就配置成了localhost而已。
1、云端DeepSeek属于最常见的接入方式之一
你把spring.ai.openai.base-url指向DeepSeek官方地址，并提供DeepSeek的API Key，就属于云端调用，不涉及本地模型部署。DeepSeek明确提供了面向OpenAI兼容的接入方式。
2、本地运行属于可选路线而不是限制条件
如果你希望离线或内网运行，常见路线是用Ollama这类本地推理服务承载模型，然后Spring AI走Ollama集成，Ollama默认服务地址通常是[http://localhost:11434]
3、本地并不等同于DeepSeek云端的同一套能力
本地模型的能力与云端API的能力会有差异，例如上下文长度、工具调用支持、输出稳定性，这些取决于你本地运行的具体模型与推理服务能力；Spring AI负责的是连接与调用方式统一，但不保证不同后端效果一致。
4、同一套业务代码可以同时支持云端与本地
比较稳的做法是把模型选择与base-url做成环境级配置，开发环境可以连本地，测试与生产连云端或内网网关，业务代码只依赖Spring AI提供的ChatClient调用方式即可。
5、如果你在内网环境，优先考虑可控的访问链路
很多团队的真实约束是网络与合规，而不是技术能不能接。你可以把DeepSeek云端接入放在统一出口或网关后面，再让Spring AI只连接内网地址，这样审计、限流、日志也更好管。
三、接入后常见问题怎么排查
把DeepSeek接进Spring AI之后，最常见的报错并不复杂，通常集中在路径拼接、模型名、鉴权与推理模式差异四类。你按顺序排查，会比反复改配置更快。
1、请求404优先检查base-url与completions-path是否叠加
Spring AI的OpenAI聊天默认路径是/v1/chat/completions，如果你把base-url写成带/v1的形式，就要把chat.completions-path改成不带/v1的路径，否则很容易变成/v1/v1这类重复。
2、请求401或403先检查Key来源与生效位置
重点确认Key是不是被应用正确读取到，以及是否在不同环境里被错误覆盖；再确认你调用的是DeepSeek服务端认可的鉴权方式与接口入口。
3、请求400多半与模型名或参数不兼容有关
先把模型名固定为deepseek-chat做基线验证，确认基础对话没问题后再切到deepseek-reasoner；DeepSeek文档对模型标识与能力有明确说明。
4、推理型模型的输出形态需要你在业务侧想清楚怎么用
deepseek-reasoner会涉及推理模式相关的返回内容与参数要求，接入时要确认你希望展示给用户的是什么，哪些内容需要过滤或仅用于内部分析，同时也要注意SDK或调用端对新参数的支持情况。
5、延迟变高时先从超时与重试的边界入手
推理型请求的耗时通常更长，建议你先把调用链路的超时策略、重试策略、并发上限定清楚，再谈提示词优化；否则一旦流量上来，问题会表现为随机失败或线程堆积，排查成本更高。
总结
Spring AI可以集成DeepSeek吗，Spring AI是不是只能调用本地DeepSeek，这两个问题放在一起看，答案就是Spring AI不绑部署形态。DeepSeek提供OpenAI兼容API，你用Spring AI的OpenAI集成把base-url与模型名配对好，就能直连云端；如果你要离线或内网，也可以让Spring AI走Ollama等本地推理服务。把路径拼接、模型标识、鉴权与推理模式这四件事先理顺，接入就会比较稳定。
