[Bug]: Decisions API should not hardcode an arbitrary 128-question limit

快速结论：通过 LiteLLM 代理向 /v1/systemone 发起的 Decisions 请求中，questions 字典超过 128 项时会被 LiteLLM 本地校验拒绝并返回 400，请求根本不会转发到上游。优先确认是不是问题数量触发了这个硬编码上限，而不是上游模型/供应商的上下文限制。

适用环境：LiteLLM v1.106.0；Docker 部署的 Proxy；模型配置为 mode: evaluation、max_input_tokens: 262144，经 OpenRouter 调用 perplexity/pplx-decider-v1.2。Issue 中未确认操作系统、Python、CUDA 或显卡信息。

最快修复方案：暂无确认的一步修复方案。Issue 中报告者自称已有修复和回归测试、准备提交 PR，但讨论链未给出该 PR 的合入版本或可用配置开关，不能据此给出确定操作。

注意事项：不要盲目调大 max_input_tokens，该报错是 questions 条目数校验，不是 token 超限。在上游侧仍可能有 body 大小、嵌套和上下文限制；移除本地 128 上限属代码层改动，升级前需确认所用 LiteLLM 版本是否已包含对应修复。

问题场景

用户在 Docker 部署的 LiteLLM Proxy 上，通过 http://localhost:4000/v1/systemone 调用评估模式模型（pplx-decider-v1.2，走 OpenRouter）。请求体 questions 中包含 154 个问题项，LiteLLM 在转发前做请求校验时直接返回 HTTP 400。使用 1 到 128 个问题时不受影响。

报错原文

HTTP 400: litellm.BadRequestError: Invalid Decisions request:
1 validation error for DecisionsRequestBody
questions
  Dictionary should have at most 128 items after validation, not 154
  [type=too_long]

原因分析

LiteLLM 的 Decisions 请求体校验对 questions 设置了最多 128 项的硬编码上限。Issue 报告者指出，TypeSafe 当前官方 OpenAPI schema 中 SystemOneRequest.questions 只声明了 minProperties: 1，没有 maxProperties；请求规则文档也只描述了 body 大小、嵌套和上下文限制，未规定最大问题数。因此该上限被报告者视为 LiteLLM 单方面的任意限制。可能原因是本地校验规则与实际 provider 能力不一致，上游本可通过上下文限制兜底，而这里在校验层提前拒绝。

环境排查

确认 LiteLLM 版本：Issue 复现于 v1.106.0；若使用其他版本，需核对该版本是否仍包含 128 项校验。
确认请求确实经过 LiteLLM Proxy 的 /v1/systemone 端点，而不是直连上游。
统计请求 JSON 中 questions 实际条目数，确认是否大于 128。
核对模型配置中的 mode: evaluation 与 max_input_tokens，排除其他校验错误叠加。
检查代理日志中是否有上游返回的错误；若请求完全未到上游，可佐证是本地校验拦截。
Issue 未提供 Python、CUDA、显卡等信息，若环境中存在其他报错，需另行单独排查。

解决步骤

先用 Issue 中同款请求（154 个问题）复现，确认响应体中的 [type=too_long] 与 Dictionary should have at most 128 items 完全一致，排除其他 400 原因。
将 questions 临时缩减到 128 项或以下，验证请求可正常转发，从而确认问题与数量上限直接相关。
在业务侧按更大批次拆分问题、分多次请求调用，可优先尝试作为临时规避手段；注意这会改变单次请求语义，需业务确认可行。
如需根除上限，可优先尝试升级到包含该修复的 LiteLLM 版本；升级前查阅对应版本 release 说明，确认 Decisions 校验已调整。
若需要在当前版本自行修改，只能作为代码层变更处理（放宽或移除 questions 的 maxProperties 校验），并自行补充回归测试；Issue 未提供具体补丁内容，不宜照抄。
修改或升级后，重新用包含 154 个问题的请求测试，并观察上游是否返回自身的限制错误。

验证方法

重新发送相同结构的 154 项 questions 请求，若不再返回 Invalid Decisions request / Dictionary should have at most 128 items，而是进入上游处理并返回正常结果（或仅由上游按自身规则报错），即可确认本地 128 项限制已解除。同时用 128 项以内的请求回归，确认原有合法请求未受影响。