推理节点宕机时的流式连接保活与透明重试-开发者社区

推理节点宕机时的流式连接保活与透明重试

在基于 Server-Sent Events（SSE）与 WebSocket 构建的大模型流式交互基础设施中，用户提问与大模型生成回复是一个长达数秒乃至数十秒的长生命周期流式连接过程。

然而，在底层承载推理计算的 GPU 服务器集群（如 vLLM / TensorRT-LLM 节点）中，硬件环境面临着极其严峻的突发故障风险：

GPU 显卡在持续高负荷运行下偶发触发显存 ECC 致命错误（Uncorrectable ECC Error）导致驱动崩溃；
推理容器由于处理超长上下文突发触发 CUDA OOM 并被底层守护进程强行处决；
宿主机物理网络偶发丢包导致与网关之间的长连接突然断开。

如果网关层缺乏**“流式中断的透明无感重试与连接保活（Streaming Failover & Resume）”机制**：

用户在手机前端看着大模型正在输出一段长篇回答，回答输出到第 100 个字时突然戛然而止并弹窗报错Connection Lost (502 / 504)；
用户不得不沮丧地清空会话并重新发起提问，不仅极度伤害用户体验，而且之前已经消耗的 GPU 算力全部白白浪费！

在模型网关层构建**“基于 Token 序列指纹与断点续传（Token-Level Resumption）的透明容灾重试中枢”**，实现即使后端 GPU 节点当场炸机、前端用户依然能够丝滑接收完整回答，是构建企业级大模型基础设施的标志性技术高地。

流式推理中断的传统痛点 vs 透明无感续传

[传统粗暴实现 (无断点续传)] 用户提问 -> GPU 节点-1 输出了 50 个 Token -> [GPU 节点-1 突发显存 OOM 崩溃断链!] | v [网关直接向前端抛出 Connection Reset 报错! 用户界面中断报错，之前算的 50 个 Token 全部作废!] -------------------------------------------------------------------------------------- [工业级透明断点续传架构 (Seamless Streaming Resume)] 用户提问 -> 网关在内存环形队列中持续缓存已吐出的 50 个 Token... -> [GPU 节点-1 突发崩溃断链!] -> 网关在 50ms 内感知到连接中断! -> 【核心动作】: 网关将原本的 Prompt + "已生成的 50 个 Token 拼接作为新前缀" -> 毫秒级重定向调度至备用【GPU 节点-2】! -> GPU 节点-2 从第 51 个 Token 继续向下生成并返回... -> 网关将第 51 个 Token 及其后续数据无缝拼接推向前端用户! -> 【用户端毫无察觉，仅感受到微弱的一顿 (100ms)，随后回答继续流畅输出!】

网关层透明断点续传的工业级架构实现

为了实现前端用户的 100% 零感知，网关与下游推理引擎之间必须维护一个具备自适应断点感知与 Prompt 重组能力的中间状态机：

// 生产级大模型流式推理透明容灾重试执行器 @Component public class ResilientStreamingGatewayHandler { @Autowired private LoadBalancerClient loadBalancer; @Autowired private HttpClient streamingHttpClient; public Flux<ServerSentEvent<String>> handleStreamingInference(LlmChatRequest request) { // 创建用于记录在途已吐出 Token 的内存滑动缓冲队列 (Token Sliding Buffer) StringBuilder generatedTokenBuffer = new StringBuilder(); AtomicInteger attemptCounter = new AtomicInteger(0); return executeInferenceStream(request, generatedTokenBuffer, attemptCounter) .onErrorResume(StreamingNodeDisruptionException.class, ex -> { log.warn("Downstream GPU node crashed mid-stream! Attempting transparent token resumption..."); // 1. 检查是否超出最大重试次数 (最多允许透明重试 2 次) if (attemptCounter.incrementAndGet() > 2) { return Flux.error(new MaxRetryExceededException("Streaming recovery failed after 2 attempts.")); } // 2. 构造【断点续传全新 Prompt 上下文】: 将已输出的部分拼接在最后 LlmChatRequest resumedRequest = cloneRequestWithPrefix(request, generatedTokenBuffer.toString()); // 3. 动态调度至健康的全新 GPU 节点继续执行流式生成！ return executeInferenceStream(resumedRequest, generatedTokenBuffer, attemptCounter); }); } private Flux<ServerSentEvent<String>> executeInferenceStream( LlmChatRequest request, StringBuilder tokenAccumulator, AtomicInteger attempt) { // 从负载均衡器挑选一个健康的 GPU 推理实例 ServiceInstance targetGpuNode = loadBalancer.chooseHealthyInstance("llm-inference-cluster"); return streamingHttpClient.post() .uri(targetGpuNode.getUri() + "/v1/chat/completions") .bodyValue(request) .responseStream((response, body) -> { if (response.status().code() != 200) { return Flux.error(new StreamingNodeDisruptionException("GPU node returned error code: " + response.status().code())); } return body.asString(); }) .map(tokenChunk -> { // 实时将新吐出的 Token 累加至内存缓冲区 tokenAccumulator.append(tokenChunk); return ServerSentEvent.builder(tokenChunk).build(); }) .onErrorMap(IOException.class, ex -> new StreamingNodeDisruptionException("Socket reset mid-stream", ex)); } }

生产级断点重试的三大核心避坑军规

在落地流式断点续传时，必须对如下三个微观边界进行严密处理：

1. 前端 SSE 连接的“物理心跳保活（PING Keep-Alive）”

当后端 GPU 节点发生崩溃、网关在进行重试重路由的50ms～200ms 空窗期内：

网关与移动端 App 之间的物理 TCP 连接绝对不能断开；
网关的独立异步心跳定时器必须向客户端持续发送: ping\n\nSSE 注释保活帧，防止移动端网络中间的 NAT 代理或 CDN 节点因超时过早主动掐断连接！

2. 模型上下文重组时的“停止词与格式防畸变（Prefix Injection Sanitization）”

将已生成的文本拼接为新 Prompt 发给备用节点时：

必须根据所使用的大模型微调模板（如 ChatML / Llama-3 模板），正确注入<|im_start|>assistant\n以及已生成的文本前缀；
并通知备用节点启用prefix_caching（前缀 KV Cache 命中优化），使备用节点在10ms 内极速命中缓存并直接开始生成后续 Token！