[Bug]: Gemini 4 Argon: CONTINUATION finish reason is mapped to “stop”, so truncated output looks complete

快速结论：使用 gemini-4-argon 长输出时，Google 在达到单次输出上限后返回 finishReason: CONTINUATION，但旧版 LiteLLM 未做映射，把该结束原因降级成 stop，于是被截断或为空的回答在客户端看起来是“正常完成”；排查重点应放在 LiteLLM 版本与 finish reason 映射上，报错原文为 [Bug]: Gemini 4 Argon: CONTINUATION finish reason is mapped to "stop", so truncated output looks complete。

适用环境：LiteLLM v1.104.5；模型 gemini-4-argon，经 Vertex AI 全局端点调用；请求参数 reasoning_effort: "high"、max_tokens: 200000；同时涉及流式与非流式两种模式。Issue 未确认操作系统、Python、CUDA 或显卡环境。

最快修复方案：升级到包含 PR #46240 的 LiteLLM 版本（维护者说明从 v1.108.0-rc.1 起可用）。Issue 已确认当前 main 上 map_finish_reason("CONTINUATION") 返回 length，但 v1.104.5 早于该修复。

注意事项：升级后，非流式路径的 finish_reason 会被正确映射为 length，但 Issue 讨论指出流式路径仍不携带 native_finish_reason，且 continuation_token 在流式与非流式两条路径都未被暴露，因此流式客户端仍可能无法区分“截断”和“结束”，也无法据此续写。该问题被定性为设计决策，是否由 LiteLLM 内部自动续跑尚未确定；Issue 中也未说明 v1.104.5 的 backport 是否完成。

问题场景

用户在 LiteLLM 中调用 Vertex AI 全局端点上的 gemini-4-argon，开启高推理投入并设置很大的 max_tokens，要求模型输出很长的内容（Issue 给出的复现任务是“对 1 到 400 的每个整数 n 判断 n^2+n+41 是否为素数，并展示每次除法，不用代码”）。当模型触及单次输出上限但还有内容要说时，Google 以 finishReason: CONTINUATION 和 continuation_token 结束响应。LiteLLM v1.104.5 未映射 CONTINUATION，返回的 finish_reason 为 stop，导致调用方支付了全部 token，却拿到空内容或被截断的内容，重试逻辑与 Agent 会误认为回答已完整。

报错原文

[Bug]: Gemini 4 Argon: CONTINUATION finish reason is mapped to "stop", so truncated output looks complete

Unmapped finish_reason 'CONTINUATION', defaulting to 'stop'

finishReason: CONTINUATION
finish_reason: "stop"

原因分析

可能原因是旧版 LiteLLM 的 litellm/litellm_core_utils/core_helpers.py 中 _FINISH_REASON_MAP 缺少 CONTINUATION 条目，因此遇到该结束原因时按默认值 stop 处理。Issue 讨论确认，当前 main（4fc2bba1）的 Gemini/Vertex 块中已有 "CONTINUATION": "length"，所以 v1.104.5 缺少该修复。另有两点属于未解决部分：一是该映射没有测试固定，未来改动字典可能再次静默丢失；二是流式 chunk 中没有 native_finish_reason，且 continuation_token 未在响应中暴露，流式客户端无法判断回答被截断，也无法继续生成。

环境排查

确认 LiteLLM 版本：Issue 复现版本为 v1.104.5，修复版本为 v1.108.0-rc.1 起；需确认实际安装版本是否低于修复版本。
确认调用的模型名与端点：gemini-4-argon，Vertex AI 全局端点。
确认请求参数中的 reasoning_effort 与 max_tokens，Issue 中为 "high" 和 200000。
确认使用流式还是非流式调用；Issue 中非流式结果可见 provider_specific_fields.native_finish_reason 为 CONTINUATION，流式则不存在该字段。
确认返回的 finish_reason 是否为 stop，以及是否存在日志“Unmapped finish_reason ‘CONTINUATION’, defaulting to ‘stop’”。
检视响应中是否出现 continuation_token；Issue 报告者表示未检查该 token 是否出现在响应体任意位置。

解决步骤

先记录当前 LiteLLM 版本，并对照 Issue 中提到的版本边界：v1.104.5 存在该问题，修复包含在 PR #46240 中，维护者称从 v1.108.0-rc.1 起可用。
将 LiteLLM 升级到包含 PR #46240 的版本，升级后检查 litellm/litellm_core_utils/core_helpers.py 中 _FINISH_REASON_MAP 是否包含 "CONTINUATION": "length"。
非流式调用时，用同一个长输出任务复测，确认 finish_reason 不再是 stop，而是 length，以便客户端识别回答被截断。
如果无法立即升级，可优先尝试在调用方对 provider_specific_fields.native_finish_reason == "CONTINUATION" 做额外判断；但 Issue 未验证该方案，且流式路径没有该字段，因此只能作为临时缓解。
如果升级后仍需要处理被截断的流式输出，需先确认维护者选择哪一种设计：由 LiteLLM 暴露 continuation_token 让调用方自行续写，还是由 LiteLLM 内部运行续写循环；Issue 关闭时该决策尚未明确。

验证方法

升级后，用 gemini-4-argon 触发长输出并检查返回结果：非流式响应的 finish_reason 应为 length，同时不应再出现“Unmapped finish_reason ‘CONTINUATION’, defaulting to ‘stop’”日志。用 Issue 中的复现提示词，或任意会超过单次输出上限的任务验证内容是否仍显示为被截断。若流式输出仍表现为正常结束，则可能只完成了映射修复，continuation_token 与自动续写部分尚未解决。