尧图网页设计 
Spring AI 调 vLLM 部署的 deepseek 报 400用 Jetty 客户端快速排查修复【免费下载链接】spring-aiAn Application Framework for AI Engineering项目地址: https://gitcode.com/GitHub_Trending/spr/spring-ai如果你用 Spring AI 的 OpenAiChatModel 对接 vLLM 部署的 deepseek 模型调用时稳定收到 400而 curl 直连却一切正常大概率不是配置写错而是 HTTP 客户端的发送方式与 vLLM 不兼容。本文给出判断信号、根因定位以及替换默认 HTTP 客户端为 Jetty 的最小修复方案和验证清单。这类 400 长什么样先花两分钟确认你是不是踩中了同款问题满足下面三条基本可以锁定用 curl 或独立脚本直连同一 vLLM 地址模型名、base URL、Key 全部确认无误返回正常 换成 Spring AI 的 OpenAiChatModel 发同样的 chat completion 请求必现 400响应里提示 body 缺失或 input 为 nullBadRequestError换 prompt、换参数都复现与是否流式、是否带 tools 无关。如果你只是 Key 写错或地址少了/v1curl 也会失败那就先回到常规配置排查。为什么请求看起来正确却仍然失败问题的关键不在 URL、Key 或 model 名而在请求体的传输方式。HTTP 客户端在发送 body 时可以选择带 Content-Length 的一次性发送也可以采用分块传输编码chunked transfer encoding即把请求体分段推给服务端。Spring 默认的 HTTP 客户端在某些场景下会走后者而 vLLM 侧的请求解析对分块请求支持不完整它没能把分段内容拼回完整 body于是把整个请求体当作None处理直接以 400 拒绝并提示必填字段缺失。你看到的缺字段其实是服务端根本没读到字段。最小改动把默认 HTTP 客户端换成 Jetty修复思路很简单换一个发送行为稳定的 HTTP 客户端。Jetty 客户端对这类同步 POST 请求会正常携带完整 body实测可消除上述 400。第一步为项目引入 Jetty 客户端依赖同步 REST 与响应式 WebClient 各需一个dependency groupIdorg.eclipse.jetty/groupId artifactIdjetty-client/artifactId /dependency dependency groupIdorg.eclipse.jetty/groupId artifactIdjetty-reactive-httpclient/artifactId /dependency第二步在构建 OpenAI 客户端时把 Rest 和 Web 两条链路的请求工厂都指定为 Jetty 实现OpenAiApi api OpenAiApi.builder() .baseUrl(baseUrl) .apiKey(apiKey) .restClientBuilder(RestClient.builder() .requestFactory(new JettyClientHttpRequestFactory())) .webClientBuilder(WebClient.builder() .clientConnector(new JettyClientHttpConnector())) .build();如果你使用的是 1.x 系列版本OpenAiChatModel 基于 OpenAiApi 构建可直接套用上面的写法若你升级到了 2.xspring-ai-openai 模块已切换到官方 OpenAI Java SDK 之上源码见 models/spring-ai-openai/此时没有 restClientBuilder/webClientBuilder 这两个入口按同样思路在 SDK 客户端初始化处替换底层 HTTP 连接即可。修复后如何确认重新构建并重启应用让新的依赖与 Bean 生效而不是只改了代码✅ 复跑之前必现 400 的那条调用确认返回正常内容而非 BadRequestError打开 debug 日志观察出站请求的连接客户端确认实际走的是 Jetty 实现用同一模型、同一 prompt 对比 Spring AI 调用与 curl 直连的响应两者应一致若接了流式输出追加验证一次 streaming 请求避免只在非流式路径上修好了。后续跟进持续关注 vLLM 对分块传输请求的解析修复上游修好后临时适配即可移除把替换 HTTP 客户端作为这类 400 的第一排查动作沉淀到团队文档⚠️ 引入其他推理服务如自研网关、私有部署框架时优先确认其 HTTP 兼容性避免重复踩坑。【免费下载链接】spring-aiAn Application Framework for AI Engineering项目地址: https://gitcode.com/GitHub_Trending/spr/spring-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Spring AI 调 vLLM 部署的 deepseek 报 400？用 Jetty 客户端快速排查修复
Spring AI 调 vLLM 部署的 deepseek 报 400用 Jetty 客户端快速排查修复【免费下载链接】spring-aiAn Application Framework for AI Engineering项目地址: https://gitcode.com/GitHub_Trending/spr/spring-ai如果你用 Spring AI 的 OpenAiChatModel 对接 vLLM 部署的 deepseek 模型调用时稳定收到 400而 curl 直连却一切正常大概率不是配置写错而是 HTTP 客户端的发送方式与 vLLM 不兼容。本文给出判断信号、根因定位以及替换默认 HTTP 客户端为 Jetty 的最小修复方案和验证清单。这类 400 长什么样先花两分钟确认你是不是踩中了同款问题满足下面三条基本可以锁定用 curl 或独立脚本直连同一 vLLM 地址模型名、base URL、Key 全部确认无误返回正常 换成 Spring AI 的 OpenAiChatModel 发同样的 chat completion 请求必现 400响应里提示 body 缺失或 input 为 nullBadRequestError换 prompt、换参数都复现与是否流式、是否带 tools 无关。如果你只是 Key 写错或地址少了/v1curl 也会失败那就先回到常规配置排查。为什么请求看起来正确却仍然失败问题的关键不在 URL、Key 或 model 名而在请求体的传输方式。HTTP 客户端在发送 body 时可以选择带 Content-Length 的一次性发送也可以采用分块传输编码chunked transfer encoding即把请求体分段推给服务端。Spring 默认的 HTTP 客户端在某些场景下会走后者而 vLLM 侧的请求解析对分块请求支持不完整它没能把分段内容拼回完整 body于是把整个请求体当作None处理直接以 400 拒绝并提示必填字段缺失。你看到的缺字段其实是服务端根本没读到字段。最小改动把默认 HTTP 客户端换成 Jetty修复思路很简单换一个发送行为稳定的 HTTP 客户端。Jetty 客户端对这类同步 POST 请求会正常携带完整 body实测可消除上述 400。第一步为项目引入 Jetty 客户端依赖同步 REST 与响应式 WebClient 各需一个dependency groupIdorg.eclipse.jetty/groupId artifactIdjetty-client/artifactId /dependency dependency groupIdorg.eclipse.jetty/groupId artifactIdjetty-reactive-httpclient/artifactId /dependency第二步在构建 OpenAI 客户端时把 Rest 和 Web 两条链路的请求工厂都指定为 Jetty 实现OpenAiApi api OpenAiApi.builder() .baseUrl(baseUrl) .apiKey(apiKey) .restClientBuilder(RestClient.builder() .requestFactory(new JettyClientHttpRequestFactory())) .webClientBuilder(WebClient.builder() .clientConnector(new JettyClientHttpConnector())) .build();如果你使用的是 1.x 系列版本OpenAiChatModel 基于 OpenAiApi 构建可直接套用上面的写法若你升级到了 2.xspring-ai-openai 模块已切换到官方 OpenAI Java SDK 之上源码见 models/spring-ai-openai/此时没有 restClientBuilder/webClientBuilder 这两个入口按同样思路在 SDK 客户端初始化处替换底层 HTTP 连接即可。修复后如何确认重新构建并重启应用让新的依赖与 Bean 生效而不是只改了代码✅ 复跑之前必现 400 的那条调用确认返回正常内容而非 BadRequestError打开 debug 日志观察出站请求的连接客户端确认实际走的是 Jetty 实现用同一模型、同一 prompt 对比 Spring AI 调用与 curl 直连的响应两者应一致若接了流式输出追加验证一次 streaming 请求避免只在非流式路径上修好了。后续跟进持续关注 vLLM 对分块传输请求的解析修复上游修好后临时适配即可移除把替换 HTTP 客户端作为这类 400 的第一排查动作沉淀到团队文档⚠️ 引入其他推理服务如自研网关、私有部署框架时优先确认其 HTTP 兼容性避免重复踩坑。【免费下载链接】spring-aiAn Application Framework for AI Engineering项目地址: https://gitcode.com/GitHub_Trending/spr/spring-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考