1. LiteLLM 1.95.0 启动就崩问题出在 FastAPI 的导入符号上如果你在本地用litellm[proxy]1.95.0搭统一模型网关装完包、敲下litellm --version或直接启动 Proxy终端立刻甩出一行ImportError: cannot import name get_flat_dependant from fastapi.dependencies.utils那这篇就是写给你的。这个报错的特点是它发生在请求发出之前连版本号都来不及打印看起来像 LiteLLM 装坏了实际上大概率是依赖解析把 FastAPI 拉到了一个不兼容的版本。LiteLLM 是一个把 OpenAI、Anthropic、Gemini 等多家模型接口统一成 OpenAI 兼容格式的代理层适合本地部署、团队共享 Key、做模型路由和成本统计的 Python 开发者。它的 Proxy 模式基于 FastAPI 构建管理端点模块会从fastapi.dependencies.utils导入get_flat_dependant这个内部符号。当 pip 在干净环境里为 LiteLLM 1.95.0 自动解析依赖时可能装到 FastAPI 0.141.x而这个版本里该符号已经不可用于是 CLI 和 Proxy 双双启动失败。我实测的环境是 macOS arm64、Python 3.11.15、LiteLLM 1.95.0自动解析到的 FastAPI 是 0.141.1。把 FastAPI 固定到 0.136.3 后导入恢复、CLI 正常、Proxy 能起、回环请求全通。下面把可复制的锁定片段、降级命令、启动验证和 TaoToken 接入配置一次讲清楚你照着做就能把服务拉回来。2. 先确认版本矩阵再决定要不要锁 FastAPI排查这类 ImportError最忌讳看到报错就无脑重装。正确顺序是先打印四个关键值Python、LiteLLM、FastAPI、Starlette 的实际版本以及get_flat_dependant这个符号到底存不存在。只有确认符号缺失、且 Traceback 指向同一个导入位置才适用本文的版本锁定方案。2.1 用一段脚本把版本和符号一起打出来在虚拟环境里执行下面这段输出会直接告诉你是否命中本文场景import importlib.metadata as md from fastapi.dependencies import utils print(python, __import__(sys).version) print(litellm, md.version(litellm)) print(fastapi, md.version(fastapi)) print(starlette, md.version(starlette)) print(get_flat_dependant, hasattr(utils, get_flat_dependant))如果最后一行是False而报错又是cannot import name get_flat_dependant那基本可以确定是 FastAPI 版本过高。如果最后一行是True却仍报同样的错那问题不在版本别照抄本文的锁定去查是不是装了两套环境。2.2 为什么只升级 LiteLLM 不够LiteLLM 1.95.0 的 Proxy 依赖范围写的是fastapi0.136.3,1.0这个范围本身很宽pip 会优先选最新满足条件的版本。问题在于 FastAPI 在 0.136.3 之后的某个版本里调整了fastapi.dependencies.utils的内部结构get_flat_dependant被移除或改名而 LiteLLM 1.95.0 的代码还在按老路径导入。这不是 LiteLLM 装错了而是依赖解析选了一个合法但不兼容的版本。注意这是 2026-08-07 对 LiteLLM 1.95.0 这组版本的实测边界不代表上游承诺永远固定在 0.136.3。升级 LiteLLM 后要重新验证别把临时锁定当永久方案。3. 可复制的依赖锁定与降级命令确认命中后修复动作其实很小把 FastAPI 固定到 0.136.3。但关键是别只在终端敲一次pip install要把组合写进约束文件否则下次重建环境又会漂移。3.1 从零建虚拟环境并锁定版本python3.11 -m venv .venv .venv/bin/python -m pip install -U pip .venv/bin/pip install litellm[proxy]1.95.0 fastapi0.136.3 .venv/bin/pip check .venv/bin/litellm --version成功信号至少包括两行No broken requirements found.和LiteLLM: Current Version 1.95.0。如果pip check报冲突说明还有别的包在拉不同版本的 FastAPI需要一并约束。3.2 已经装乱了怎么降级如果环境里已经装了 0.141.x直接降级即可不用删环境重来.venv/bin/pip install fastapi0.136.3 .venv/bin/pip check .venv/bin/python -c from fastapi.dependencies import utils; print(hasattr(utils, get_flat_dependant))最后一行打印True就说明符号回来了。如果 pip 提示有其他包依赖更高版本 FastAPI用pip install fastapi0.136.3 --force-reinstall强制覆盖再跑一次pip check看有没有新冲突。3.3 把约束写进 requirements.txtlitellm[proxy]1.95.0 fastapi0.136.3部署或 CI 里固定执行这三步任何一步失败就阻断发布python -m pip install -r requirements.txt python -m pip check litellm --version这样做的价值是把能启动拆成可观察的小信号依赖解析、模块导入、CLI 版本打印各自有证据出问题能快速定位是哪一层。4. 启动 Proxy 并接入 TaoToken 统一通道依赖修好后下一步是让 Proxy 真正跑起来并验证连通性。这里给一份最小 config 骨架同时演示如何把 TaoToken 作为统一 Key/API 通道接进 LiteLLM 的model_list。4.1 最小 config.yaml 骨架model_list: - model_name: demo-model litellm_params: model: openai/demo-model api_base: http://127.0.0.1:42317/v1 api_key: sk-loopback general_settings: master_key: sk-master-loopback这里的地址和密钥都只用于本地回环夹具不是线上服务配置。启动命令显式传入绝对路径避免工作目录变化导致找不到文件NO_PROXY127.0.0.1,localhost \ .venv/bin/litellm --config $(pwd)/config.yaml \ --host 127.0.0.1 --port 42318成功日志里应出现Application startup complete。如果停在Config file not found说明路径不对如果停在yaml.parser.ParserError说明 YAML 缩进或括号坏了先用yaml.safe_load单独解析一遍。4.2 把 TaoToken 接进 model_listTaoToken 提供统一的 Key 和 API 通道你可以在 LiteLLM 里把它当成一个 OpenAI 兼容上游来配。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。配置时把api_base指向 TaoToken 的兼容端点api_key换成你在控制台生成的 Keymodel_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_base: https://taotoken.net/api/v1 api_key: os.environ/TAOTOKEN_API_KEY general_settings: master_key: sk-your-master-key用os.environ/TAOTOKEN_API_KEY从环境变量读取避免把 Key 写进文件。启动前导出export TAOTOKEN_API_KEY你的TaoToken Key这样 LiteLLM 对外暴露的还是 OpenAI 兼容接口内部把请求转发到 TaoToken 通道团队里其他人只需要拿你的 master_key 就能用不用各自配一堆上游 Key。Key 的生成和管理在控制台完成接入细节可以对照接入文档。4.3 验证请求与成功结果服务起来后按健康、模型列表、对话三层逐级验证curl -fsS http://127.0.0.1:42318/health/liveliness curl -fsS http://127.0.0.1:42318/v1/models \ -H Authorization: Bearer sk-master-loopback curl -fsS http://127.0.0.1:42318/v1/chat/completions \ -H Authorization: Bearer sk-master-loopback \ -H Content-Type: application/json \ -d {model:demo-model,messages:[{role:user,content:probe through proxy}]}本次回环结果是健康返回存活文本模型列表包含demo-model对话返回LOOPBACK_OK:probe through proxy且finish_reasonstop。三步的成功信号分别是存活文本、预期模型 ID 和finish_reasonstop缺一不可。如果你的真实服务只支持流式还要另写流式探针别把非流式回环结果当成流式兼容证明。5. 本篇常见错排查修完导入错误不代表万事大吉下面三条是修复后仍可能踩的坑按现象对号入座。5.1 固定后仍报相同 ImportError最常见原因是 pip 和 litellm 不属于同一个虚拟环境。先查实际入口which python which pip which litellm .venv/bin/python -m pip show litellm fastapi starlette如果which litellm指向系统路径而不是.venv/bin/litellm说明你启动的是另一套环境。不要在系统 Python 里继续覆盖安装本文环境的系统默认 Python 是 3.9.6本身不满足 LiteLLM 1.95.0 的版本要求所有命令都要明确用 3.11 虚拟环境。5.2 ImportError 消失但配置打不开依赖修好不代表配置正确。传入不存在的路径会得到Exception: Config file not found用绝对路径$(pwd)/config.yaml先排除工作目录问题。如果文件存在但 YAML 坏了启动会停在yaml.parser.ParserError先独立解析from pathlib import Path import yaml path Path(config.yaml).resolve() print(path) print(yaml.safe_load(path.read_text()))这一步只验证 YAML 结构不证明模型可调用后面仍要跑健康、模型列表和最小对话。5.3 服务活着但本地上游返回 502本次测试机有系统代理环境第一次启动时 LiteLLM 自身的健康和模型列表都返回 200但对 127.0.0.1 上游的请求没到达夹具最终被重试两次并映射为 502。把本地地址加入NO_PROXY后同一请求立即返回 200。判断标准是LiteLLM 有上游失败日志但本地夹具完全没收到请求。若夹具已收到请求应继续查响应契约、路径和模型而不是盲目加代理变量。6. 把临时修复变成可维护约束不要只在终端执行一次pip install fastapi0.136.3就完事。至少把当前组合写进约束文件并在依赖文件旁留一行注释注明 LiteLLM 版本、触发的导入符号、验证日期和回归命令。升级 LiteLLM 时先复制一份约束文件在干净环境里只改一个变量重新检查依赖解析、导入、配置读取和回环请求全部通过才删除旧约束。如果你是在服务器、容器或团队电脑上排查把顺序固定下来先记录python --version和sys.executable确认环境再用pip show记录安装位置和版本然后用短脚本检查get_flat_dependant是否存在接着跑pip check最后执行litellm --version。CLI 能打印版本后再启动 Proxy启动通过只说明配置被读到、ASGI 能监听端口不说明上游可调用所以最小回归必须包含健康、模型列表和一次非流式对话。以后再遇到类似 ImportError先比较版本矩阵而不是凭印象把所有依赖一起升级或降级。需要长期跑编码或 Agent 场景的话可以了解下 Coding Plan 的额度方案只想先验证模型通不通直接开模型对话试一条最快接入和排障相关的 Key 管理、文档细节去 API Keys 和接入文档里对照即可。