ValueError: gammavariate: alpha and beta must be > 0.0

快速结论：该报错发生在 LiteLLM 代理重启后，AdaptiveRouter 从数据库重新加载状态时，将持久化的增量数据直接覆盖了冷启动先验，导致部分 BanditCell 的 alpha 或 beta 参数为 0，进而在 Thompson 采样调用 random.betavariate 时抛出 ValueError。优先排查方向是确认状态表中是否存在 alpha=0 或 beta=0 的行记录，并检查当前 LiteLLM 版本是否已合并修复该问题的 PR。

适用环境：LiteLLM v1.86.2（Issue 作者报告版本）及 v1.90.0（评论者官方 Docker 镜像复现版本）；PostgreSQL 作为状态数据库；启用 auto_router/adaptive_router 模型；多轮对话场景下产生满意度-only 学习单元时易触发。

最快修复方案：暂无确认的一步修复方案。Issue 中提出的修复方案（将持久化增量与冷启动先验合并而非覆盖）对应的 PR #29398 在 Issue 关闭时尚未合并到 v1.90.0 或 main 分支。可在合并前手动清理被污染的 AdaptiveRouter 状态表（删除或重置 alpha=0 或 beta=0 的行）作为临时缓解手段。

注意事项：清理状态表会丢失已学习的路由数据；该问题同时存在次要影响——即使不崩溃，覆盖写入也会丢弃分层先验，导致重启后学习到的路由被破坏。升版本前应确认修复是否已合入。

问题场景

用户在运行 LiteLLM 代理服务时，配置了 auto_router/adaptive_router 模型。当代理经历一次重启后，向该模型发送匹配请求时返回 HTTP 500 错误。触发条件为：状态表中存在一个只有满意度（satisfaction）没有失败记录的学习单元（持久化后表现为 beta=0），或只有失败没有满意度的单元（alpha=0）。一条干净的多轮满意对话即可产生此类数据，并在约 10 秒的刷新间隔内被持久化。

报错原文

ValueError: gammavariate: alpha and beta must be > 0.0

原因分析

根因是 AdaptiveRouter.load_state_from_db 在重新加载持久化状态时，用数据库行的原始值直接覆盖了每个冷启动先验（cold-start prior）：

self._cells[(rt, row.model_name)] = BanditCell(alpha=row.alpha, beta=row.beta)

但 AdaptiveRouterUpdateQueue.flush_state_to_db 持久化的是累计增量而非绝对后验（使用 Prisma 的 {"increment": ...} 以避免多 pod 互相覆盖），且 _compute_bandit_delta 将满意度映射为 +alpha。因此：

仅满意度（satisfaction-only）的单元持久化后 beta = 0
仅失败（negative-only）的单元持久化后 alpha = 0

重启后这些数据被加载为 BanditCell(alpha, 0) / BanditCell(0, beta)——原本保证 beta >= 0.5 的冷启动先验（通过 initial_cell 实现）被丢弃。随后 thompson_sample 调用 random.betavariate(alpha, beta)，只要 alpha <= 0 或 beta <= 0 即抛出异常。由于 pick_best 会对分类后的 request_type 池中每一个模型的单元进行采样，一个被污染的单元会导致该请求类型下的所有请求返回 500，直至状态表被清空。

次要问题：即使不崩溃，覆盖写入也会丢弃分层种子先验（例如一个包含一次满意和一次失败的单元会重新加载为 Beta(1,1) 而非 prior + (1,1)），从而在多次重启后破坏已学习的路由能力。

环境排查

LiteLLM 版本：确认是否为 v1.86.2 或 v1.90.0（Issue 中两个版本均已复现，main 分支在关闭时仍未修复）
数据库类型：PostgreSQL（Prisma 增量写入）
配置项：确认 auto_router 或 adaptive_router 已开启
状态表数据：查询 LiteLLM_AdaptiveRouterState 表中是否存在 alpha=0 或 beta=0 的行
触发门槛：SIGNAL_GATE_MIN_MESSAGES 默认值为 4，确认对话轮次是否超过该阈值

解决步骤

确认问题版本：检查 LiteLLM 版本是否为 v1.86.2 至 v1.90.0（含）之间，或 main 分支在 2026-06-27 之前的构建。

查询数据库状态表，定位被污染的数据：

SELECT router_name, request_type, model_name, alpha, beta, total_samples
FROM "LiteLLM_AdaptiveRouterState"
WHERE alpha <= 0 OR beta <= 0;

临时缓解：删除或重置上述被污染的行（例如 UPDATE 将 alpha/beta 设为 1），使代理可以正常返回请求。
跟踪修复进展：关注 PR #29398 是否合并到 LiteLLM 的发布版本中——该 PR 实现的是“冷启动先验 + 持久化增量”的正确行为。
若修复已合入，升级 LiteLLM 至包含该修复的版本后重启代理。

验证方法

重启 LiteLLM 代理后，向此前触发报错的 auto_router/adaptive_router 模型发送匹配请求，确认不再返回 HTTP 500。同时可检查 /adaptive_router/state 接口：修复前重启后单元格的 total_samples 会变为 0（确认了先验丢失），修复后应显示先验与增量合并后的正确样本数。