流式响应正常结束，也可能只生成一半

把现有 OpenAI 兼容客户端切到 Kimi K3.1 Pro，请求成功、流连接正常关闭，也可能只拿到半截回答。原文提醒的是一个容易漏掉的接入细节：程序读取了生成文本，却没有检查模型为什么结束。

作者围绕这个问题给出了流式终止检查、token 预算、模型变体比较和重试处理。对维护 AI 对话、代码生成或工具调用服务的开发者，最有用的结论是：接口能调用，只完成了接入的第一步，回答是否完整还要由应用判断。

连接正常关闭，为什么回答还会断在半句

原文讨论的是 Chat Completions 接口，关键字段叫 finish_reason。自然结束时通常是 stop；撞到输出上限时是 length。非流式调用可以直接查看响应对象，流式调用则需要检查末尾的数据块。

问题出在不少手写循环只读取 delta.content。最后一个块可能没有正文，只携带终止原因。如果代码遇到空正文就跳过整块，截断信号也一起丢了。

流结束只能说明传输结束，不能证明回答完整。

下面这段代码同时收集文本和终止原因，把输出达到上限变成应用可处理的错误：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.example.com/v1",
    api_key="sk-...",
)

stream = client.chat.completions.create(
    model="kimi-k3.1-pro",  # use the exact ID your provider lists
    messages=[{"role": "user", "content": user_prompt}],
    max_tokens=2048,
    stream=True,
)

finish_reason = None
for chunk in stream:
    choice = chunk.choices[0]
    if choice.delta.content:
        yield choice.delta.content
    if choice.finish_reason:
        finish_reason = choice.finish_reason

if finish_reason == "length":
    raise RuntimeError("Generation hit the token cap mid-output")

要盯住循环之后的 if finish_reason == "length"：检查不能依赖最后一块有没有正文。

这段代码表达了检测思路，还不是完整的生产实现。它默认 chunk.choices[0] 存在，也没有处理终止原因始终缺失等情况。更实际的问题是，文本已经通过 yield 发给用户，末尾抛错并不能收回这些内容。前端仍需要把这次回答标成未完成，避免保存时当成正常结果。

输出预算太小会截断，太大也会失败

max_tokens 有两头风险：设得太小，回答写不完；设得太大，输入加上预留输出超过上下文限制，整个请求可能被拒绝。作者还提醒，不传这个参数时，部分服务商会采用偏保守的默认值，但没有给出具体服务商和默认数字。

因此，预算要从服务商文档中的上下文上限倒推。下面的函数先减去输入占用，再把输出限制在业务上限内：

def budgeted_max_tokens(prompt_tokens, context_limit, cap=4096):
    remaining = context_limit - prompt_tokens
    if remaining <= 0:
        raise ValueError(f"Prompt exceeds the context limit by {-remaining} tokens")
    return min(cap, remaining)

关键是 return min(cap, remaining)。这里的 4096 是示例采用的输出上限，不是 Kimi K3.1 Pro 的上下文长度；前一段代码里的 2048 也只是调用示例。

原文要求使用与服务商一致的 tokenizer，也就是把文本切成 token 的计数规则，不能直接拿字符数代替。不过，文章没有提供具体 tokenizer、上下文窗口数值，也没有展开消息封装等额外开销如何计入。接入时这些信息仍需补齐。

算出可用空间，只能帮助请求满足容量约束，不能保证答案一定写得完。

切到 Highspeed，先验证业务结果

按原文说法，K3.1 Pro 和 K3.1 Pro Highspeed 使用不同的模型字符串，并不是在同一个模型上打开速度开关。切换会影响延迟和输出，不能默认得到完全相同的文本。

作者建议把真实业务提示词分别发给两个变体，在 temperature=0 时比较返回内容；示例 parity_report 返回 identical、a、b，其中 identical 只是判断两段文本是否相等。

这个检查适合发现差异，但不能直接评价差异是否有害。对接下游解析器时，更应该检查 JSON 能否解析、字段是否齐全、代码是否满足约束。文本不同可能都合格，文本相同也不代表正确。

模型 ID 也要固定在明确的位置。示例中的 kimi-k3.1-pro 需要按服务商模型列表核对，原文没有提供 Highspeed 的准确 ID。作者提到拼写错误可能返回 404，但不能把这个状态码当成所有服务商统一的诊断规则。

重试之前，先看请求有没有执行过动作

原文给出的 call_with_retry 默认 attempts=4、base=1.0，仅在异常文本包含 429 时重试，通过 time.sleep(base * 2 ** attempt) 做指数退避，其余异常继续抛出。

它想解决的是限流后的恢复问题。但这里还有一个边界：重新请求模型，与重新执行模型触发的工具，并不是同一件事。工具如果已经执行，整条流程重跑就可能重复产生副作用。

作者因此建议为工具调用设置幂等键（idempotency key），让重复请求能够被识别。这个方向成立，不过文章没有实现幂等机制。示例通过异常字符串识别 429，也属于简化写法，实际项目更适合读取 SDK 提供的结构化错误信息。

前面检测到 length 后，同样不宜直接照搬限流重试。保持原来的输出上限再生成一次，并没有消除截断原因。

我的判断

这篇最有价值的是把「回答是否完整」从模型表现问题，拉回了接口处理问题。相比只累计文本，检查 finish_reason 成本很低，也能直接暴露一类静默失败。

但它是一份接入检查建议，不是一份 Kimi 性能评测。原文没有展示 Pro 与 Highspeed 的延迟、质量、价格对照，也没有提供截断发生率。标题突出 Kimi，正文多数做法其实适用于采用相似 Chat Completions 协议的服务。

作者明确说这些检查是其补充内容，但没有给出测试记录和运行结果。因此，代码可以作为实现起点，关于变体表现和生产可靠性的结论，还要靠自己的业务样本验证。

能拿来做什么

• 在 Node 流式代理中同时处理正文和 finish_reason，将 length 转成前端可识别的未完成状态，并随回答一起保存。
• 给请求入口补上 token 预算，核对服务商的上下文限制与计数方式，把输入超限和输出截断分别记录。
• 切换 Pro 或 Highspeed 前，用真实提示词比较结果；涉及结构化输出时，优先检查解析和业务约束。
• 为工具执行层加入幂等键，再处理限流重试，避免把模型请求重试扩大成整条业务流程重放。