从单机 Demo 到生产弹性：Spring AI Alibaba 在 K8s 上的容量规划、压测与工程化实践摘要：很多团队接入 Spring AI Alibaba 后，接口很快能跑通，但一进入生产环境就会遇到另一类问题：长连接挤爆连接池、输出 token 拉长 RT、外部模型限流引发雪崩、HPA 跟不上真实负载、压测结果无法指导扩容。本文从架构原理、容量建模、工程化治理、Kubernetes 弹性与压测方法五个层面，给出一套可以直接复用的生产级方案，并补充完整代码、配置样例与实战分析。1. 为什么 AI 应用的容量规划不能照搬传统 Web 方法在传统 Web 服务中，我们通常用QPS + CPU + RT估算容量，方法虽然粗糙，但多数场景够用。但对接大模型后，系统负载模式发生了根本变化：一个请求会持续更久。传统接口几十毫秒到几百毫秒结束，AI 对话常常持续数秒到数十秒。输出长度高度不确定。输入 prompt 只有几百 token，但输出可能是 50 token，也可能是 3000 token。限制项不再只有 CPU/内存，还包括RPM、TPM、下游模型并发配额、连接池容量、线程占用和客户端缓冲区。流式响应将“请求完成时间”拆成了多个指标，业务更关心首字延迟而不是整个响应结束时间。在云上调用模型时，推理虽然发生在 DashScope 侧，但客户端应用依然要承担连接维持、SSE 解码、上下文拼装、工具调用、重试、缓存与观测开销。所以，Spring AI Alibaba 应用的容量规划，本质上不是“一个 Pod 能抗多少 QPS”，而是：在目标 SLA、模型配额、业务 token 分布和集群资源约束下， 一个 Pod 能稳定承载多少有效 Token Throughput。2. 业务场景与目标约束为了让方法论更具体，本文以一个典型企业智能客服场景为例：场景：订单咨询、售后问答、知识库解释、工单总结技术栈：Spring Boot 3.3 + Spring AI Alibaba + DashScope + Redis + Prometheus + Kubernetes调用模式：70% 同步问答，20% 流式输出，10% Function Calling目标 SLA：P95 TTFT 3sP95 全量响应时间 15s错误率 1%高峰期可弹性扩容到 10 倍流量工程目标：不因下游模型抖动拖垮应用可以通过监控和压测反推出容量上限支持后续多模型路由、缓存、异步化演进这类系统的核心矛盾不是“能不能调通”，而是“在成本、时延、稳定性之间做工程化平衡”。3. Spring AI Alibaba 调用链路与资源消耗原理3.1 一次请求到底经历了什么以ChatClient调用为例，一次看似简单的prompt - answer背后，通常包含如下链路：Client - API Gateway / Ingress - Spring MVC / WebFlux Controller - Prompt Assembly（系统提示词、历史对话、RAG 片段、工具描述） - Spring AI Alibaba ChatClient - HTTP Client Connection Pool - DashScope API - 模型推理 - SSE / JSON 反序列化 - Tool Calling / 后处理 - Result Serialization - Client这一链路会同时消耗多类资源：阶段主要资源风险点Prompt 组装CPU / Heap历史消息过长导致内存上升HTTP 建连与等待连接池 / 线程长连接导致连接耗尽SSE 解码CPU / Direct Memory流式 chunk 过多时解析成本变高Tool 调用线程 / 下游连接模型调用和业务查询叠加放大 RT重试与超时线程 / 队列限流后重试风暴响应缓存与日志Heap / I/O大响应体落日志、落缓存导致膨胀3.2 AI 应用里的关键指标建议统一采用下面这组指标，而不是只盯QPS：指标含义价值RPMRequests Per Minute请求速率上限TPMTokens Per Minute真正反映模型吞吐TTFTTime To First Token首字体验和排队情况TPOTTime Per Output Token模型输出效率Active Requests活跃请求数评估在途负载Pool Pending Acquire连接等待数判断连接池瓶颈429 Rate下游限流比率判断模型配额是否撞线Fallback Rate降级比例判断系统是否长期过载3.3 为什么 Output Token 比 Input Token 更关键生产里很多团队会高估 Prompt 长度的影响、低估输出长度的影响。对于云上模型调用场景，Output Token往往更直接决定：连接占用时长SSE chunk 数量客户端解码时间请求生命周期长度单位时间内可完成的请求数换句话说，一个 3000 token 的长回答，往往比一个 3000 token 的长输入更容易把客户端服务拖慢。4. 生产级架构：不仅能调用，还要能承压4.1 推荐架构┌──────────────────────┐ │ API Gateway/Ingress │ │ 鉴权/限流/灰度/超时 │ └──────────┬───────────┘ │ ┌────────────────▼────────────────┐ │ Spring AI Alibaba Application │ │ │ │ 1. Controller / Stream Endpoint │ │ 2. Prompt Assembly │ │ 3. Concurrency Guard │ │ 4. Model Routing │ │ 5. ChatClient / EmbeddingClient │ │ 6. Tool Calling │ │ 7. Metrics / Tracing / Logging │ └──────────┬───────────────┬───────┘ │ │ ┌────────────▼───────┐ ┌──▼────────────┐ │ Redis / Semantic │ │ Prometheus / │ │ Cache / Rate Bucket │ │ Grafana / Loki│ └────────────┬────────┘ └───────────────┘ │ ┌────────▼────────┐ │ DashScope / │ │ Tongyi Qwen API │ └─────────────────┘4.2 生产架构里必须额外补上的能力相比 Demo 版本，生产至少要多出六个治理层：并发护栏：限制单 Pod 在途请求数，避免过载。超时与取消传播：客户端断开后，尽快中断下游流式处理。模型路由：不同请求走不同模型，控制成本和时延。缓存层
从单机 Demo 到生产弹性：Spring AI Alibaba 在 K8s 上的容量规划、压测与工程化实践
从单机 Demo 到生产弹性：Spring AI Alibaba 在 K8s 上的容量规划、压测与工程化实践摘要：很多团队接入 Spring AI Alibaba 后，接口很快能跑通，但一进入生产环境就会遇到另一类问题：长连接挤爆连接池、输出 token 拉长 RT、外部模型限流引发雪崩、HPA 跟不上真实负载、压测结果无法指导扩容。本文从架构原理、容量建模、工程化治理、Kubernetes 弹性与压测方法五个层面，给出一套可以直接复用的生产级方案，并补充完整代码、配置样例与实战分析。1. 为什么 AI 应用的容量规划不能照搬传统 Web 方法在传统 Web 服务中，我们通常用QPS + CPU + RT估算容量，方法虽然粗糙，但多数场景够用。但对接大模型后，系统负载模式发生了根本变化：一个请求会持续更久。传统接口几十毫秒到几百毫秒结束，AI 对话常常持续数秒到数十秒。输出长度高度不确定。输入 prompt 只有几百 token，但输出可能是 50 token，也可能是 3000 token。限制项不再只有 CPU/内存，还包括RPM、TPM、下游模型并发配额、连接池容量、线程占用和客户端缓冲区。流式响应将“请求完成时间”拆成了多个指标，业务更关心首字延迟而不是整个响应结束时间。在云上调用模型时，推理虽然发生在 DashScope 侧，但客户端应用依然要承担连接维持、SSE 解码、上下文拼装、工具调用、重试、缓存与观测开销。所以，Spring AI Alibaba 应用的容量规划，本质上不是“一个 Pod 能抗多少 QPS”，而是：在目标 SLA、模型配额、业务 token 分布和集群资源约束下， 一个 Pod 能稳定承载多少有效 Token Throughput。2. 业务场景与目标约束为了让方法论更具体，本文以一个典型企业智能客服场景为例：场景：订单咨询、售后问答、知识库解释、工单总结技术栈：Spring Boot 3.3 + Spring AI Alibaba + DashScope + Redis + Prometheus + Kubernetes调用模式：70% 同步问答，20% 流式输出，10% Function Calling目标 SLA：P95 TTFT 3sP95 全量响应时间 15s错误率 1%高峰期可弹性扩容到 10 倍流量工程目标：不因下游模型抖动拖垮应用可以通过监控和压测反推出容量上限支持后续多模型路由、缓存、异步化演进这类系统的核心矛盾不是“能不能调通”，而是“在成本、时延、稳定性之间做工程化平衡”。3. Spring AI Alibaba 调用链路与资源消耗原理3.1 一次请求到底经历了什么以ChatClient调用为例，一次看似简单的prompt - answer背后，通常包含如下链路：Client - API Gateway / Ingress - Spring MVC / WebFlux Controller - Prompt Assembly（系统提示词、历史对话、RAG 片段、工具描述） - Spring AI Alibaba ChatClient - HTTP Client Connection Pool - DashScope API - 模型推理 - SSE / JSON 反序列化 - Tool Calling / 后处理 - Result Serialization - Client这一链路会同时消耗多类资源：阶段主要资源风险点Prompt 组装CPU / Heap历史消息过长导致内存上升HTTP 建连与等待连接池 / 线程长连接导致连接耗尽SSE 解码CPU / Direct Memory流式 chunk 过多时解析成本变高Tool 调用线程 / 下游连接模型调用和业务查询叠加放大 RT重试与超时线程 / 队列限流后重试风暴响应缓存与日志Heap / I/O大响应体落日志、落缓存导致膨胀3.2 AI 应用里的关键指标建议统一采用下面这组指标，而不是只盯QPS：指标含义价值RPMRequests Per Minute请求速率上限TPMTokens Per Minute真正反映模型吞吐TTFTTime To First Token首字体验和排队情况TPOTTime Per Output Token模型输出效率Active Requests活跃请求数评估在途负载Pool Pending Acquire连接等待数判断连接池瓶颈429 Rate下游限流比率判断模型配额是否撞线Fallback Rate降级比例判断系统是否长期过载3.3 为什么 Output Token 比 Input Token 更关键生产里很多团队会高估 Prompt 长度的影响、低估输出长度的影响。对于云上模型调用场景，Output Token往往更直接决定：连接占用时长SSE chunk 数量客户端解码时间请求生命周期长度单位时间内可完成的请求数换句话说，一个 3000 token 的长回答，往往比一个 3000 token 的长输入更容易把客户端服务拖慢。4. 生产级架构：不仅能调用，还要能承压4.1 推荐架构┌──────────────────────┐ │ API Gateway/Ingress │ │ 鉴权/限流/灰度/超时 │ └──────────┬───────────┘ │ ┌────────────────▼────────────────┐ │ Spring AI Alibaba Application │ │ │ │ 1. Controller / Stream Endpoint │ │ 2. Prompt Assembly │ │ 3. Concurrency Guard │ │ 4. Model Routing │ │ 5. ChatClient / EmbeddingClient │ │ 6. Tool Calling │ │ 7. Metrics / Tracing / Logging │ └──────────┬───────────────┬───────┘ │ │ ┌────────────▼───────┐ ┌──▼────────────┐ │ Redis / Semantic │ │ Prometheus / │ │ Cache / Rate Bucket │ │ Grafana / Loki│ └────────────┬────────┘ └───────────────┘ │ ┌────────▼────────┐ │ DashScope / │ │ Tongyi Qwen API │ └─────────────────┘4.2 生产架构里必须额外补上的能力相比 Demo 版本，生产至少要多出六个治理层：并发护栏：限制单 Pod 在途请求数，避免过载。超时与取消传播：客户端断开后，尽快中断下游流式处理。模型路由：不同请求走不同模型，控制成本和时延。缓存层
