gemini 经 endless 在 09-16 小量试切，09-17 起分批放量：09-17 solving_module_humc_single，09-18 generate_recap_text，09-19 question_type_module_v2_simulator，09-22 切完 question_type_module_solver_mode_v1 与 generate_flashcard_text 后到 51.3–52.1%。09-23 起只切了 5 个小 code（合计日请求约 3,200），今日至今 51.6%。

09-12~15 的高点不是网关切换：那几天多个 code 改用 gpt-5.6-luna（gpt 系列本来就经 endless 调用），09-16 换回 gemini 直连。

同模型可直接切 21.3pp：16 个 code 当前用的模型已经在 endless 上跑，只需换通道。需先开通模型 14.7pp：主要是 gemini-3-flash 和 3.1-flash-lite。自建 qwen 8.0pp，是否纳入迁移待定。其余 3.9pp 是部分走 endless、长输出和长尾。

每日走 endless 的 Top 20 和 98 个待切换 code 的完整列表见 PromptCode 请求半月报 →「Endless 切换进度」tab。

按 09-26 请求量排序。「切到此行后」表示从第 1 行切到这一行时的整体 endless 占比，今天切到哪一行由你们定；in / out 为近 7 天平均 token（含 endless 流量）。generate_flashcard_image / generate_recap_image 的 text 版本已分别在 09-22 / 09-18 起用同一模型 gemini-3.8-flash 跑在 endless 上。

• 部分走 endless +2.7pp：answer_reference_highlight 与 _image 版本约 9% 走 endless。endless 侧是 gpt-5.5，直连侧是 gemini-3-flash，这是按模型分流，不是网关灰度。
• 自建 qwen +8.0pp：只有 question_type_combined 一个 code（Qwen3.6-35B），它走不走 endless 决定"100%"的分母。
• 长输出 +0.7pp：solving_generate_simulator 平均输出 3,828 token，模型已在 endless 上，切之前先确认 endless 的流式超时设置。
• 长尾 +0.5pp：60 个 09-26 请求 <1,000 的 code，加上已切换 code 的直连残余，可以随主批次一起带走。

4 月见顶（日均 304 万），5 月起随业务与模型切换回落，8 月触底后 9 月回升约 34%。给网关做容量规划时用 近 30 天日均 110 万 + 历史峰值 431 万 两个数，不要只用当前值——去年同期到峰值的爬坡只用了 3 个月。

日内峰谷比 6.4 倍（Gemini，180 天）：最忙的是 UTC 01–02 时（北京 09–10 时）约 30 QPS，最闲的是 UTC 09–10 时（北京 17–18 时）不到 5 QPS。网关限流阈值必须按峰值秒级设定，按日均设会在每天高峰被打穿。历史秒级峰值 211 QPS，出现在 4 月业务高点，是当前常态的 14 倍。

99.2% 的请求是 流式（SSE），平均持续 4.24 秒、P99 接近 30 秒。网关必须按长连接容量而非 QPS 容量做规划，且空闲超时不能低于 60 秒。

典型请求是 大输入、小输出：输入约 3,200 token、输出约 270 token，比例接近 12:1。对网关意味着上行带宽和请求体解析是瓶颈，不是下行。

网关必须原样透传 prompt caching 语义（cache_control / implicit cache）。缓存命中的月份（4–6 月）cached token 占输入的 30–36%，最近仍有 11%；一旦网关重写或重排 prompt 导致缓存失效，输入侧计费会按未缓存价重算——按 4 月口径相当于凭空多付三成输入成本。

模型迭代非常快：9 个月里主力模型换了 4 代，2026-09 当月新上线的 gemini-3.8-flash、gpt-5.6-luna、gemini-3.5-flash-lite 合计已占 20%。接新模型的速度是选型的硬指标，比当前支持的模型清单更重要。

91% 流量压在 Google GenAI 单一通道上。网关方案要能同时代理 Gemini 原生 API、Azure OpenAI、OpenAI 兼容端点、自建 vLLM/Qwen 端点 四类协议；只做 OpenAI-compatible 转换会丢掉 Gemini 的 thinking / implicit cache / 多模态字段。

现状是直连供应商的时延，网关引入的额外跳数必须控制在可接受范围内。建议把下表写进 SLA，按 网关自身开销 P99 < 50 ms 验收。

共 20+ 个独立 API key / 业务线共用同一批模型配额，网关必须支持 按 key 的独立限流、配额与成本归集。当前 Top 25 业务场景（promptCode）覆盖 ~85% 流量，单场景输入规模从 1.3K 到 16K token 不等，说明限流不能只按请求数、还要按 token 速率（TPM）。

按申请书自述口径独立复算：server_event_log、近 180 天、modelName LIKE '%gemini%' 且排除 embedding、token 计 input+output+thinking+tool、取历史最大值。九项数字全部能用申请书自述的方法复现。「申请值相对实测」为正，是申请书「向上取整」留的余量（例如日请求 3,458,928 取整成 4,000,000，多 15.6%），不是算错；为负的三项（−0.4%~−1.0%）是统计窗口差一两天的正常漂移。「可复现」只说明算法对得上，不代表该用这个数——第 9 项就是例子。

需要修改的三处

一 · 「单次请求最大 2,040,160 tokens」要换成干净口径的值：输入上限 769,472，或总量上限 854,257。该记录为 2026-03-29 的 gemini-2.5-flash 调用，构成是 prompt 90,016 + completion 13,123 + toolToken 1,937,021——tool token 占 95%，且同一条记录在表中重复出现两行、promptCode 为空。gemini-2.5-flash 的上下文窗口是 1M，2M 的 total 不可能是一次真实上下文。把它写进申请书，Google 会理解成业务需要 2M context window。干净口径有两个，按申请字段的含义选一个：单请求输入上限 max promptToken = 769,472；单请求总量（输入 + 输出 + thinking + tool）上限，剔除 promptCode 为空、或 toolToken 占总量一半及以上的记录后为 854,257（2026-03-29 ~ 09-26 共 276,994,432 次 Gemini 请求，其中 toolToken 占一半及以上的有 249,913 条，占 0.09%）。两个值都在 1M 上下文以内。这批重复的 tool-token 记录本身建议让后端排查埋点。

二 · 「当前业务流量仍处于持续增长阶段」与数据相反。Gemini 月度日均：4 月 2.43 M → 8 月 0.87 M，半年下降 58%；9 月回升至 1.01 M，只是从 8 月低点反弹 16%。申请的 400 万/日约为当前实际的 4 倍。按历史峰值申请本身完全合理，但「持续增长」这个理由站不住——Google 调自己那侧的用量记录，看到的是一条下行曲线。建议改为「按半年历史峰值 + 季节性波动预留申请」，并补一句 4 月峰值对应的业务事件与复现可能性。

三 · 高峰时段偏宽，不是写反。数据记录为北京时间（UTC+8）。180 天实测每小时请求最高在 北京 09–10 时（UTC 01–02），约 1,970 万/小时；最低在 北京 17–18 时（UTC 09–10），约 310 万/小时。申请书的高峰窗口「北京 18:00–次日 14:00 / UTC 10:00–次日 06:00」覆盖了真正的高峰，但把北京 18–22 点和 13 点这 6 个低于平均的小时也算了进去，起点正好是全天最低的 UTC 10 点。实测高于日均的时段是 北京 23:00–次日 13:00（UTC 15:00–次日 05:00）：「流量主要集中在夜间和次日上午」成立，「晚间」不成立。

两处建议（非错误）

• Flash 与 Pro 拆开报量。申请书写「目标模型：Gemini Flash 和 Gemini Pro 系列」，但 Pro 实际占比 <0.2%（180 天）。若 Google 按模型分别发放配额，Pro 报 250 QPS 会拿到用不上的额度，也削弱申请的可信度。
• 点明输入口径含缓存。平均输入 3,204 tokens 中包含 cachedToken。Gemini 的 TPM 配额确实计入 cached，所以口径没错，但文档里明写一句，可以避免后续与账单对账时口径打架。