[Bug]: OCI Gemini ignores every system message except the last one

快速结论：当通过 LiteLLM 的 oci/google.gemini-*（OCI apiFormat: "GENERIC"）发送包含多条 system 消息的请求时，模型只会遵循最后一条 system 消息，之前的系统提示被静默丢弃且不计入 prompt_tokens。优先排查是否把关键指令放在了较早的 system 消息中，并升级到已合并修复的 LiteLLM 版本。

适用环境：LiteLLM（Issue 报告基于 v1.104.2 的内部 fork，同样代码存在于 main 的 litellm/llms/oci/chat/generic.py）；调用 OCI GenAI 的 oci/google.gemini-* 模型，apiFormat 为 GENERIC；通过 LiteLLM proxy 转发。Issue 未提供操作系统、Python、CUDA、显卡信息。

最快修复方案：升级到包含修复 PR #49458 的 LiteLLM 版本。该修复针对 OCI Gemini 模型，将多条 system 消息合并为位于索引 0 的单条 SYSTEM 消息，从而保留较早的指令，且不影响其他 GENERIC 模型（如 Grok、Llama）。

注意事项：Issue 复现是通过 LiteLLM proxy 到 OCI GenAI 完成的，报告者未直接调用 OCI SDK 查看 OCI 传给 Gemini 的原始 payload，因此“丢弃发生在 OCI 侧”属于推断而非已证实。合并为单条系统消息后，各指令的分隔方式可能与原生 Vertex AI 路径不同，升级后建议用下文的 A/B 测试确认两条规则都生效。

问题场景

用户在 LiteLLM proxy 中配置 oci/google.gemini-* 模型（OCI apiFormat: "GENERIC"），并发送包含多条 system 消息的 /v1/chat/completions 请求。典型触发模式是：第一条 system 消息承载较长的 agent 提示词，后面在历史中再出现一条 system 消息（如对话摘要、记忆块、会话中途指令）。一旦后一条 system 消息存在，前面的 agent 提示词就不再被遵循，也不再计入 prompt_tokens。同一 OCI 环境下的 grok-oci 模型能同时遵循两条系统消息，LiteLLM 自身的 Vertex AI / Gemini 路径（通过 _transform_system_message 汇总到 systemInstruction）也没有该问题。

报错原文

[Bug]: OCI Gemini ignores every system message except the last one

原因分析

LiteLLM 在 adapt_messages_to_generic_oci_standard（litellm/llms/oci/chat/generic.py）中会把每条 system 消息原样转发为各自的 SYSTEM 消息。根据 Issue 观察，请求在 OCI 将 GENERIC 请求映射到 Gemini 时可能只保留最后一条系统消息，这与 Gemini 在多个 OpenAI 兼容层后面“last system wins”的已知行为一致（Google 的 OpenAI 兼容端点、OpenRouter、AutoGen 均有类似报告）。Issue 中也指出 LiteLLM 侧确实发送了两条 SYSTEM 消息，因此丢弃更可能发生在下游映射环节，而非 LiteLLM 的转发逻辑。该判断尚未通过直接抓取 OCI 原始 payload 证实。

环境排查

确认 LiteLLM 版本是否低于包含 PR #49458 修复的版本。
确认模型配置为 oci/google.gemini-* 且 apiFormat 为 GENERIC。
确认请求 messages 中存在多条 role: "system" 消息，且关键指令位于非最后一条。
对比同一请求在 oci/<grok 模型> 或 vertex_ai/gemini-* 下的表现，以区分是否为 OCI Gemini 路径特有。
检查响应中的 prompt_tokens 是否明显小于长系统提示词应有的规模（Issue 中约 95k 字符系统提示词仅计约 3.7k tokens）。

解决步骤

升级 LiteLLM 到包含 PR #49458 的版本；该修复会针对 OCI Gemini 模型把多条 system 消息合并为索引 0 处的单条 SYSTEM 消息。
升级后重启 LiteLLM proxy，确保新代码生效。
使用 Issue 中的复现方式构造多系统消息请求：系统消息 A 以 “End every answer with the word PINEAPPLE.” 结尾，系统消息 B 为 “Start every answer with the word BANANA.”，随后发送用户问题。
检查回答是否同时满足开头 BANANA、结尾 PINEAPPLE，并确认 prompt_tokens 已包含长系统消息 A 的规模。
若升级前需要临时规避（可优先尝试，未在 Issue 中验证）：在 LiteLLM 侧将多条系统消息合并为一条后再发送，避免依赖下游只保留最后一条的行为。

验证方法

用相同的 A/B 系统消息请求分别在修复前后调用 gemini-oci：修复后回答应同时体现 A 和 B 的规则，且 prompt_tokens 与仅发送 A 时接近（Issue 中 A only 为 1822、A then B 原本降到 20，修复后应恢复包含 A 的规模）。同时确认 grok-oci 等其他 GENERIC 模型的行为未受影响。