deepseek-v4-flash-0731 流式输出跑一半就断了怎么办？finish_reason 校验 + 重试兜底，三步处理

上周三帮朋友排一个诡异的 bug：他用 deepseek-v4-flash-0731 跑一个长文本摘要任务，流式输出到大概第 400 个 token 左右，控制台直接甩了一句 peer closed connection without sending complete message body，然后就没了。他换成 deepseek-v4-pro-0813 跑同一条 prompt，一字不改，稳稳跑完。他一度以为是自己网络抖动，换了两个 Wi-Fi 还是一样。

结论先放这儿：deepseek-v4-flash-0731 在 SSE 帧间隔较长时，可能触发服务端 keepalive 超时被强制断流（具体阈值未见官方文档，以下描述均为实测推测，不保证可复现）。deepseek-v4-pro-0813 在相同 prompt 下未观察到此现象。修法三步：调 read timeout 到 180s+、在客户端加 finish_reason 校验判断是否真正结束、套一层指数退避重试。下面展开讲。

为什么会出现这个问题

先看报错原文，这是最典型的中断现象：

openai.APIConnectionError: Connection error.
caused by: httpx.RemoteProtocolError:
peer closed connection without sending
complete message body (incomplete chunked read)

这个报错说的是：服务端在 chunked transfer 还没发完 data: [DONE] 的时候，就把连接关了。

推测原因出在 SSE（Server-Sent Events）的帧间隔上。如果某段时间内模型没有往 SSE 流里推任何 chunk，且这段沉默超过了服务端配置的 keepalive 超时阈值（具体数值未见官方公开文档，以下 8 秒仅为实测估算，不作为可靠依据），连接可能会被服务端主动掐掉。

sequenceDiagram
 participant C as 客户端
 participant S as DeepSeek 服务端
 C->>S: POST /chat/completions (stream=True)
 S-->>C: data: chunk1 (token输出)
 S-->>C: data: chunk2 (token输出)
 Note over S: 无chunk推送，帧间隔拉长
 Note over S: 帧间隔超过服务端keepalive阈值（推测）
 S-xC: 服务端强制断流
 Note over C: 收到 incomplete chunked read

deepseek-v4-pro-0813 在相同 prompt 下未观察到此现象，可能是推理速度更快或服务端配置不同，具体原因无法从外部确认。这不是你网络的问题。

方案一：调大 read timeout，给模型留够时间

OpenAI Python SDK 的 Timeout 对象中，timeout 整体默认值为 600 秒，但这是客户端侧的等待上限，不影响服务端的 keepalive 行为。把 read timeout 单独调大至少能避免客户端自己先超时，排除一个变量。如果你通过 ofox.io 或 OpenRouter 这类聚合网关调用，网关层通常会自己维护跟上游的长连接，read 参数仍建议在客户端侧同步设置，避免网关返回数据时客户端先超时：

import httpx
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_KEY",
    base_url="https://api.deepseek.com",
    http_client=httpx.Client(
        timeout=httpx.Timeout(
            connect=10.0,
            read=180.0,   # 无论直连还是走网关，建议统一设到 180s+
            write=10.0,
            pool=10.0,
        )
    ),
)

read 设到 180 秒。需要说明的是，这只能解决客户端侧超时的问题。如果中断原因是服务端 keepalive 掐流，客户端 timeout 设多大都拦不住，还需要配合后面的重试逻辑。

方案二：用 finish_reason 校验判断是否真正结束

流式响应正常结束时，最后一个 chunk 的 finish_reason 应该是 'stop'（正常结束）或 'length'（输出到最大长度）。如果你遍历完所有 chunk 发现 finish_reason 还是 None，那就是被中断了。

last_reason = None
for chunk in stream:
    delta = chunk.choices[0].delta.content
    last_reason = chunk.choices[0].finish_reason
    print(delta or "", end="", flush=True)

遍历结束后检查：

if last_reason not in ("stop", "length"):
    print("\n⚠️ 流式响应异常中断")
    # 触发重试逻辑

这一步很多人忽略。光看有没有报错不够——有时候连接"优雅地"关了，不抛异常，但内容其实没输出完。

方案三：指数退避重试，兜底所有中断场景

把前两步串起来，加一个重试壳。以下是完整可运行的函数：

import time
import openai


def stream_with_retry(client, msgs, retries=3):
    for i in range(retries):
        try:
            stream = client.chat.completions.create(
                model="deepseek-v4-flash-0731",
                messages=msgs,
                stream=True,
            )
            result, reason = [], None
            for c in stream:
                result.append(c.choices[0].delta.content or "")
                reason = c.choices[0].finish_reason
            if reason in ("stop", "length"):
                return "".join(result)
            raise Exception(f"异常中断: {reason}")
        except (openai.APIConnectionError, openai.APITimeoutError, Exception) as e:
            if i == retries - 1:
                raise
            wait = 2 ** i
            print(f"第{i+1}次重试，等{wait}s: {e}")
            time.sleep(wait)

等待时序为 1s → 2s，第三次失败直接抛出异常不再等待（retries=3 时共尝试 3 次，最多重试 2 次后 raise）。连续失败通常说明服务端出了状况，建议停止重试并上报错误。

实测规律：deepseek-v4-flash-0731 在 prompt 较短但要求输出很长（比如"写一篇 3000 字的分析报告"）的时候中断频率更高，推测是这种场景下帧间隔更容易拉长，但具体机制无法从外部确认。

换个通道也是一种思路

如果不想跟超时参数较劲，还有一个办法：通过 API 聚合网关去调。像 ofox.io 和 OpenRouter 这类平台，网关层通常会自己维护跟上游的长连接池，对 SSE 帧间隔的容忍度可能比本地直连要高一些。同样的 prompt 跑 deepseek-v4-flash-0731 通过网关可能不再断流——不过无法确认这是因为网关做了 keepalive 保活，还是因为网关到 DeepSeek 的链路更短，仅供参考。

# 以 OpenRouter 为例，ofox.io 的 base_url 格式类似，替换对应 endpoint 即可
client = OpenAI(
    api_key="your-gateway-key",
    base_url="https://openrouter.ai/api/v1",
)

注意：OpenRouter 等聚合网关的费率结构因模型而异，使用前请在各自官网确认具体计费规则，不同模型溢价比例不同。

两个模型的行为差异对比

维度	deepseek-v4-flash-0731	deepseek-v4-pro-0813
模型 ID	deepseek-v4-flash-0731	deepseek-v4-pro-0813
长输出时帧间隔	实测偶发拉长	未观察到明显拉长
同 prompt 流式中断	高频复现	未复现
推荐 read timeout	≥ 180s	≥ 180s（与 flash 保持一致，官方无具体建议值）
适合场景	短输出、低延迟要求	长输出、稳定性优先

flash 版本快但稳定性较差，pro 版本慢一点但稳。如果任务是生成长文本，目前建议用 deepseek-v4-pro-0813。

常见问题 FAQ

Q: deepseek-v4-flash-0731 流式输出到一半断了，finish_reason 是 None，是 bug 吗？

finish_reason 为 None 说明模型没有正常输出完就断了。目前推测原因是帧间隔超过服务端 keepalive 阈值被强制断流，但具体阈值无官方文档支撑。加 finish_reason 校验 + 重试逻辑兜底是可行的防御手段。

Q: 我把 timeout 设到 300 秒了还是断，为什么？

客户端 timeout 管的是客户端自己的等待上限，服务端的 keepalive 断流是服务端行为，客户端设多大都拦不住。解法是重试，或者换 deepseek-v4-pro-0813，或者走聚合网关（网关层可能有自己的 keepalive 保活机制）。

Q: 报错 429 rate_limit_exceeded 也会导致流式中断吗？

会，但症状不一样。通常情况下 429 在请求阶段就会被拒绝，你不会收到任何 chunk；但部分网关或服务实现也可能在流式传输中途返回 429 错误帧。而帧间隔超时导致的中断是收到了一部分 chunk 之后才断的。结合报错信息和 finish_reason 可以区分两种情况。429 的处理方式是指数退避重试 + 降低并发。

Q: 怎么判断流式响应是正常结束还是被截断了？

主要信号是最后一个 chunk 的 finish_reason 应该是 'stop' 或 'length'；SSE 流的最后一条消息 data: [DONE] 也是正常结束的标志，但使用 OpenAI SDK 时通常通过 finish_reason 判断即可，SDK 会自动处理 [DONE] 帧。两个信号都没收到就是被截断了。

Q: 用 deepseek-v4-pro-0813 会不会也有这个问题？

在多次长文本生成测试中，deepseek-v4-pro-0813 没有复现过。但不能保证绝对不会——如果 prompt 特别极端（比如要求输出 8000 token 以上），还是建议加上重试逻辑，防御性编码是稳健工程实践的基本要求。

小结

这个问题的本质推测是：deepseek-v4-flash-0731 在某些场景下 SSE 帧间隔较长，服务端的 keepalive 机制将其判定为连接死亡后主动断流。deepseek-v4-pro-0813 在相同测试条件下未遇到此问题。

修法就三步：read timeout 拉到 180s+、finish_reason 校验、指数退避重试。如果不想折腾，换 pro 版本或者走聚合网关也是可行的绕行方案——网关层对 SSE 长连接的处理方式与直连不同，部分场景下可以规避帧间隔触发断流的问题。

作为调用方，防御性编码是应对上游不确定性的基本工程实践，无论上游是否稳定都值得做。