SSE 的背压不能放在最后补配置调整后记录生效范围和观察到的变化。没有这些信息下一次回滚或排障时很难分辨是流量变化还是配置副作用。流式响应有自己的连接生命周期。缓存完整响应会改变首字节时间和内存占用长上下文则会放大上游处理时间。先测量请求长度、活跃连接和下游消费速度再决定在哪里限流和截断。当客户端断开时反向取消应能传到上游否则连接数看似正常模型或代理仍在白白工作。把超时、心跳和队列上限配合起来才能避免慢消费者拖住整个服务。大模型应用后端的常见反模式大模型后端与常规接口的差别在于长连接、长上下文和外部推理依赖。缓存、内存和限流策略都要按这些约束重新评估。不要缓存流式响应本身把常规响应缓存直接套到流式接口上会改变数据何时到达客户端。缓存策略应先区分完整结果、检索结果和传输中的事件流。缓冲会改变响应行为流式输出Server-Sent Events的底层原理是利用 HTTP 1.1 的Transfer-Encoding: chunked或者 HTTP/2 的 Stream 机制逐字Token将模型吐出的数据推给前端。当给这种接口套上传统缓存中间件时网关会尝试等待整个 HTTP 响应全部结束凑齐完整 Body 后再刷给客户端。结果就是首个事件延后网关可能等待更多响应内容后再下发客户端看不到预期的渐进输出。缓冲占用增长并发流较多或单条内容较长时缓冲区会增加网关的内存压力。上限应由压测结果和容器限制决定。在合适的层级做缓存缓存必须做在语义提取层与向量匹配层如利用 GPTCache 机制而不是做在 HTTP 响应传输层。在网关层必须显式关闭 Buffer 缓冲# Nginx 针对 SSE 接口的正确配置 location /api/v1/llm/stream { proxy_pass http://llm_backend; proxy_set_header Connection ; proxy_http_version 1.1; proxy_chunked_transfer_encoding on; # 核心必须关闭代理缓冲保证 Chunk 实时下发 proxy_buffering off; proxy_cache off; }不要无节制拼接长上下文大模型应用通常需要组装系统提示词System Prompt、少样本示例Few-Shot、历史对话上下文Memory以及 RAG 召回的文档。整个 Prompt 常常达到 32KB 到 128KB 级别。很多开发者随手写出如下代码// 错误反模式高并发下产生海量 String 临时对象 public String buildPrompt(String sysPrompt, ListString memoryList, String ragDocs) { String finalPrompt sysPrompt \n; for (String msg : memoryList) { finalPrompt History: msg \n; // 每次循环都分配新 String 对象 } finalPrompt Context: ragDocs; return finalPrompt; }用测量结果指导优化当请求并发和上下文长度上升时循环中的字符串拼接会增加短生命周期对象。是否已经影响回收频率和 CPU应通过分配剖析与基准测试判断。修正姿势使用对象池或者高效的文本 Buffer 拼接器如 Go 语言的bytes.Buffer/strings.Builder或 Java 的预分配StringBuilder// 修正后代码预分配容量减少内存重分配 public String buildPromptOptimized(String sysPrompt, ListString memoryList, String ragDocs) { // 预估总长度 64KB避免频繁 resize 扩容 StringBuilder sb new StringBuilder(64 * 1024); sb.append(sysPrompt).append(\n); for (int i 0; i memoryList.size(); i) { sb.append(History: ).append(memoryList.get(i)).append(\n); } sb.append(Context: ).append(ragDocs); return sb.toString(); }为长连接设计背压机制当模型输出速度高于客户端消费速度时未下发的数据会在链路的某个缓冲区累积。需要通过背压和连接上限把累积限制在可控范围内。从连接到上游的限流策略引入背压Backpressure与队列限流使用 Reactive Streams如 Reactor / RxJava或者 Go Channel 的阻塞写入机制。当网络 TCP 发送缓冲区满了之后暂停从 LLM 推理引擎拉取下一个 Token反压给上游。全局 Connection Pool 保护在 Gateway 限制单节点 SSE 长连接的总数上限例如单个 Pod 不超过 2000 个连接超过阈值立刻优雅拒绝并提示“AI 正在思考中请稍后再试”。断线重连与 Context ID 恢复客户端网络抖动断开后必须携带Last-Event-ID重新建立连接。后端根据 ID 从 Redis 恢复生成状态而不是让用户重新重新生成一遍。搭建大模型后端底座必须尊重长连接与高延时的物理规律。抛弃简单的 CRUD 思维做好内存精细化管理与流式背压控制才是扛住高并发的硬道理。 大模型应用后端的常见反模式
SSE 的背压不能放在最后补配置调整后记录生效范围和观察到的变化。没有这些信息下一次回滚或排障时很难分辨是流量变化还是配置副作用。流式响应有自己的连接生命周期。缓存完整响应会改变首字节时间和内存占用长上下文则会放大上游处理时间。先测量请求长度、活跃连接和下游消费速度再决定在哪里限流和截断。当客户端断开时反向取消应能传到上游否则连接数看似正常模型或代理仍在白白工作。把超时、心跳和队列上限配合起来才能避免慢消费者拖住整个服务。大模型应用后端的常见反模式大模型后端与常规接口的差别在于长连接、长上下文和外部推理依赖。缓存、内存和限流策略都要按这些约束重新评估。不要缓存流式响应本身把常规响应缓存直接套到流式接口上会改变数据何时到达客户端。缓存策略应先区分完整结果、检索结果和传输中的事件流。缓冲会改变响应行为流式输出Server-Sent Events的底层原理是利用 HTTP 1.1 的Transfer-Encoding: chunked或者 HTTP/2 的 Stream 机制逐字Token将模型吐出的数据推给前端。当给这种接口套上传统缓存中间件时网关会尝试等待整个 HTTP 响应全部结束凑齐完整 Body 后再刷给客户端。结果就是首个事件延后网关可能等待更多响应内容后再下发客户端看不到预期的渐进输出。缓冲占用增长并发流较多或单条内容较长时缓冲区会增加网关的内存压力。上限应由压测结果和容器限制决定。在合适的层级做缓存缓存必须做在语义提取层与向量匹配层如利用 GPTCache 机制而不是做在 HTTP 响应传输层。在网关层必须显式关闭 Buffer 缓冲# Nginx 针对 SSE 接口的正确配置 location /api/v1/llm/stream { proxy_pass http://llm_backend; proxy_set_header Connection ; proxy_http_version 1.1; proxy_chunked_transfer_encoding on; # 核心必须关闭代理缓冲保证 Chunk 实时下发 proxy_buffering off; proxy_cache off; }不要无节制拼接长上下文大模型应用通常需要组装系统提示词System Prompt、少样本示例Few-Shot、历史对话上下文Memory以及 RAG 召回的文档。整个 Prompt 常常达到 32KB 到 128KB 级别。很多开发者随手写出如下代码// 错误反模式高并发下产生海量 String 临时对象 public String buildPrompt(String sysPrompt, ListString memoryList, String ragDocs) { String finalPrompt sysPrompt \n; for (String msg : memoryList) { finalPrompt History: msg \n; // 每次循环都分配新 String 对象 } finalPrompt Context: ragDocs; return finalPrompt; }用测量结果指导优化当请求并发和上下文长度上升时循环中的字符串拼接会增加短生命周期对象。是否已经影响回收频率和 CPU应通过分配剖析与基准测试判断。修正姿势使用对象池或者高效的文本 Buffer 拼接器如 Go 语言的bytes.Buffer/strings.Builder或 Java 的预分配StringBuilder// 修正后代码预分配容量减少内存重分配 public String buildPromptOptimized(String sysPrompt, ListString memoryList, String ragDocs) { // 预估总长度 64KB避免频繁 resize 扩容 StringBuilder sb new StringBuilder(64 * 1024); sb.append(sysPrompt).append(\n); for (int i 0; i memoryList.size(); i) { sb.append(History: ).append(memoryList.get(i)).append(\n); } sb.append(Context: ).append(ragDocs); return sb.toString(); }为长连接设计背压机制当模型输出速度高于客户端消费速度时未下发的数据会在链路的某个缓冲区累积。需要通过背压和连接上限把累积限制在可控范围内。从连接到上游的限流策略引入背压Backpressure与队列限流使用 Reactive Streams如 Reactor / RxJava或者 Go Channel 的阻塞写入机制。当网络 TCP 发送缓冲区满了之后暂停从 LLM 推理引擎拉取下一个 Token反压给上游。全局 Connection Pool 保护在 Gateway 限制单节点 SSE 长连接的总数上限例如单个 Pod 不超过 2000 个连接超过阈值立刻优雅拒绝并提示“AI 正在思考中请稍后再试”。断线重连与 Context ID 恢复客户端网络抖动断开后必须携带Last-Event-ID重新建立连接。后端根据 ID 从 Redis 恢复生成状态而不是让用户重新重新生成一遍。搭建大模型后端底座必须尊重长连接与高延时的物理规律。抛弃简单的 CRUD 思维做好内存精细化管理与流式背压控制才是扛住高并发的硬道理。