LiteLLM 架构深度解析：AI Gateway（Proxy）与 SDK 双层设计下的请求全链路

本文基于仓库根目录的架构文档 ARCHITECTURE.md 展开，完整梳理 LiteLLM “AI Gateway（代理层）+ SDK（调用层）” 的双层架构：从 POST /v1/chat/completions 进入代理后的认证、限流、路由、成本归因全流程，到 SDK 侧的 Provider 翻译层机制，再到 Redis/PostgreSQL 基础设施与数据访问层约定。读完后，你将能准确判断一个新功能或一次 bug 应该改哪一层、哪个文件，并理解 LiteLLM 如何在“网关治理”与“多 Provider 兼容”之间划分职责。

1. 总体设计：Gateway 用 SDK 发所有 LLM 调用

LiteLLM 由两部分组成：AI Gateway（litellm/proxy/） 和 SDK（litellm/）。核心原则是：代理不自己直连任何 LLM 厂商，而是复用 SDK 完成实际的模型调用：

OpenAI SDK (client)    ──▶  LiteLLM AI Gateway (proxy/)  ──▶  LiteLLM SDK (litellm/)  ──▶  LLM API
Anthropic SDK (client) ──▶  LiteLLM AI Gateway (proxy/)  ──▶  LiteLLM SDK (litellm/)  ──▶  LLM API
Any HTTP client        ──▶  LiteLLM AI Gateway (proxy/)  ──▶  LiteLLM SDK (litellm/)  ──▶  LLM API

• AI Gateway 在 SDK 之上叠加认证、限流、预算、路由等治理能力；
• SDK 负责实际的 LLM Provider 调用、请求/响应格式转换和流式处理。

这一分工意味着：所有厂商兼容性问题都落在 SDK 的翻译层，所有租户治理问题都落在 Proxy 层——修改代码前，先判断问题属于哪一层。仓库同时包含 litellm-rust/ 下的 Rust crate 子项目（含 ADDING_A_PROVIDER.md 等文档），从目录结构看是 SDK 的 Rust 侧实现/扩展，与 Python 主链路并行演进，但本文主体仍聚焦架构文档描述的 Python 双层层。

2. AI Gateway 请求主链路：一次 /v1/chat/completions 的完整旅程

架构文档给出了一条从客户端到 PostgreSQL 的时序链（已按文档原文整理）：

sequenceDiagram
    participant Client
    participant ProxyServer as proxy/proxy_server.py
    participant Auth as proxy/auth/user_api_key_auth.py
    participant Redis as Redis Cache
    participant Hooks as proxy/hooks/
    participant Router as router.py
    participant Main as main.py + utils.py
    participant Handler as llms/custom_httpx/llm_http_handler.py
    participant Transform as llms/{provider}/chat/transformation.py
    participant Provider as LLM Provider API
    participant CostCalc as cost_calculator.py
    participant LoggingObj as litellm_logging.py
    participant DBWriter as db/db_spend_update_writer.py
    participant Postgres as PostgreSQL

    Client->>ProxyServer: POST /v1/chat/completions
    ProxyServer->>Auth: user_api_key_auth()
    Auth->>Redis: Check API key cache
    Redis-->>Auth: Key info + spend limits
    ProxyServer->>Hooks: max_budget_limiter, parallel_request_limiter
    Hooks->>Redis: Check/increment rate limit counters
    ProxyServer->>Router: route_request()
    Router->>Main: litellm.acompletion()
    Main->>Handler: BaseLLMHTTPHandler.completion()
    Handler->>Transform: ProviderConfig.transform_request()
    Handler->>Provider: HTTP Request
    Provider-->>Handler: Response
    Handler->>Transform: ProviderConfig.transform_response()
    Transform-->>Handler: ModelResponse
    Handler-->>Main: ModelResponse

    Main->>LoggingObj: update_response_metadata()
    LoggingObj->>CostCalc: _response_cost_calculator()
    CostCalc->>CostCalc: completion_cost(tokens × price)
    CostCalc-->>LoggingObj: response_cost
    LoggingObj-->>Main: Set response._hidden_params["response_cost"]
    Main-->>ProxyServer: ModelResponse (with cost in _hidden_params)

    ProxyServer->>ProxyServer: Extract cost from hidden_params
    ProxyServer->>LoggingObj: async_success_handler()
    LoggingObj->>Hooks: async_log_success_event()
    Hooks->>DBWriter: update_database(response_cost)
    DBWriter->>Redis: Queue spend increment
    DBWriter->>Postgres: Batch write spend logs (async)
    ProxyServer-->>Client: ModelResponse + x-litellm-response-cost header

可以把这条链路归纳为四段：

1. 治理段（Proxy 层）：user_api_key_auth.py 完成 API key 校验（先查 Redis 缓存，miss 时落库）；随后依次经过 max_budget_limiter、parallel_request_limiter 等钩子做预算与并发限流，计数器同样存在 Redis。
2. 路由段：router.py 负责负载均衡与 fallback，最终调用 litellm.acompletion() 进入 SDK。
3. 翻译与调用段（SDK 层）：BaseLLMHTTPHandler（llm_http_handler.py）编排“transform_request → HTTP → transform_response”三段式，Provider 差异被隔离在 llms/{provider}/chat/transformation.py。
4. 成本归因段：响应返回后由 litellm_logging.py 调 cost_calculator.py 计算成本，写入 response._hidden_params["response_cost"]，再由代理层异步落库并回写 x-litellm-response-cost 响应头。

Proxy 侧的组件视角可以进一步概括为：

graph TD
    subgraph "Incoming Request"
        Client["POST /v1/chat/completions"]
    end

    subgraph "proxy/proxy_server.py"
        Endpoint["chat_completion()"]
    end

    subgraph "proxy/auth/"
        Auth["user_api_key_auth()"]
    end

    subgraph "proxy/"
        PreCall["litellm_pre_call_utils.py"]
        RouteRequest["route_llm_request.py"]
    end

    subgraph "litellm/"
        Router["router.py"]
        Main["main.py"]
    end

    subgraph "Infrastructure"
        DualCache["DualCache<br/>(in-memory + Redis)"]
        Postgres["PostgreSQL<br/>(keys, teams, spend logs)"]
    end

    Client --> Endpoint
    Endpoint --> Auth
    Auth --> DualCache
    DualCache -.->|cache miss| Postgres
    Auth --> PreCall
    PreCall --> RouteRequest
    RouteRequest --> Router
    Router --> DualCache
    Router --> Main
    Main --> Client

从组件图可以看出一个关键设计：认证与路由都压在 DualCache（内存 + Redis 双层缓存）之上，PostgreSQL 只在缓存未命中时被打到。这解释了为什么限流和鉴权能做到高吞吐——热路径不碰数据库。

Proxy 核心文件定位表

位置	职责
proxy_server.py	主 API 端点、启动时初始化后台任务
proxy/auth/	认证（API key、JWT、OAuth2），核心入口为 user_api_key_auth.py
proxy/hooks/	代理级回调（预算、限流、缓存校验等）
router.py	负载均衡、fallback
router_strategy/	路由算法，如 lowest_latency.py、simple_shuffle.py

LLM 专属代理端点分布

代理并非只有 /v1/chat/completions，各 LLM 形态的端点按功能拆分为独立子包：

端点	目录	用途
/v1/messages	proxy/anthropic_endpoints/	Anthropic Messages API
/vertex-ai/*	proxy/vertex_ai_endpoints/	Vertex AI 透传
/gemini/*	proxy/google_endpoints/	Google AI Studio 透传
/v1/images/*	proxy/image_endpoints/	图像生成
/v1/batches	proxy/batches_endpoints/	批处理
/v1/files	proxy/openai_files_endpoints/	文件上传
/v1/fine_tuning	proxy/fine_tuning_endpoints/	微调任务
/v1/rerank	proxy/rerank_endpoints/	重排序
/v1/responses	proxy/response_api_endpoints/	OpenAI Responses API
/v1/vector_stores	proxy/vector_store_endpoints/	向量库
/*（透传）	proxy/pass_through_endpoints/	直连 Provider 透传

Proxy Hooks：治理逻辑的插件化扩展点

代理层回调统一放在 proxy/hooks/，文档列出的核心钩子包括：

钩子	文件	用途
max_budget_limiter	proxy/hooks/max_budget_limiter.py	预算上限执行
parallel_request_limiter	proxy/hooks/parallel_request_limiter_v3.py	按 key/用户的并发限流
cache_control_check	proxy/hooks/cache_control_check.py	缓存控制校验
responses_id_security	proxy/hooks/responses_id_security.py	Response ID 安全校验
litellm_skills	proxy/hooks/litellm_skills/	Skills 注入

扩展方式：实现 CustomLogger 接口并注册进 proxy/hooks/init.py 中的 PROXY_HOOKS。从源码结构看，hooks 目录还存在更多细分实现（如 dynamic_rate_limiter_v3.py、max_budget_per_session_limiter.py、max_iterations_limiter.py 等），说明限流/预算策略是可插拔演进的多版本机制。

3. 基础设施组件：Redis 与 PostgreSQL 的职责划分

AI Gateway 依赖外部基础设施做缓存与持久化，架构文档给出的全景如下：

graph LR
    subgraph "AI Gateway (proxy/)"
        Proxy["proxy_server.py"]
        Auth["auth/user_api_key_auth.py"]
        DBWriter["db/db_spend_update_writer.py<br/>DBSpendUpdateWriter"]
        InternalCache["utils.py<br/>InternalUsageCache"]
        CostCallback["hooks/proxy_track_cost_callback.py<br/>_ProxyDBLogger"]
        Scheduler["APScheduler<br/>ProxyStartupEvent"]
    end

    subgraph "SDK (litellm/)"
        Router["router.py<br/>Router.cache (DualCache)"]
        LLMCache["caching/caching_handler.py<br/>LLMCachingHandler"]
        CacheClass["caching/caching.py<br/>Cache"]
    end

    subgraph "Redis (caching/redis_cache.py)"
        RateLimit["Rate Limit Counters"]
        SpendQueue["Spend Increment Queue"]
        KeyCache["API Key Cache"]
        TPM_RPM["TPM/RPM Tracking"]
        Cooldowns["Deployment Cooldowns"]
        LLMResponseCache["LLM Response Cache"]
    end

    subgraph "PostgreSQL (proxy/schema.prisma)"
        Keys["LiteLLM_VerificationToken"]
        Teams["LiteLLM_TeamTable"]
        SpendLogs["LiteLLM_SpendLogs"]
        Users["LiteLLM_UserTable"]
    end

    Auth --> InternalCache
    InternalCache --> KeyCache
    InternalCache -.->|cache miss| Keys
    InternalCache --> RateLimit
    Router --> TPM_RPM
    Router --> Cooldowns
    LLMCache --> CacheClass
    CacheClass --> LLMResponseCache
    CostCallback --> DBWriter
    DBWriter --> SpendQueue
    DBWriter --> SpendLogs
    Scheduler --> SpendLogs
    Scheduler --> Keys

各组件的职责与关键类：

组件	用途	关键文件/类
Redis	限流计数、API key 缓存、TPM/RPM 跟踪、部署冷却、LLM 响应缓存、spend 队列	caching/redis_cache.py（RedisCache）、caching/dual_cache.py（DualCache）
PostgreSQL	API key、团队、用户、消费日志	proxy/utils.py（PrismaClient）、proxy/schema.prisma
InternalUsageCache	代理级限流 + API key 缓存（内存 + Redis）	proxy/utils.py（InternalUsageCache）
Router.cache	TPM/RPM 跟踪、部署冷却、客户端缓存	router.py（Router.cache: DualCache）
LLMCachingHandler	SDK 级 LLM 响应/嵌入缓存	caching/caching_handler.py、caching/caching.py
DBSpendUpdateWriter	批量聚合 spend 更新以减少 DB 写压力	proxy/db/db_spend_update_writer.py
Cost Tracking	计算并记录响应成本	proxy/hooks/proxy_track_cost_callback.py（_ProxyDBLogger）

后台任务（APScheduler）

所有周期性任务在代理启动时由 ProxyStartupEvent.initialize_scheduled_background_jobs() 注册。文档列出的任务清单：

任务	间隔	用途	文档给出的关键文件
update_spend	60s	批量写消费日志到 PostgreSQL	proxy/db/db_spend_update_writer.py
reset_budget	10–12min	重置 key/用户/团队预算	proxy/management_helpers/budget_reset_job.py
add_deployment	10s	从 DB 同步新模型部署	proxy/proxy_server.py（ProxyConfig）
cleanup_old_spend_logs	cron/间隔	清理旧消费日志	proxy/management_helpers/spend_log_cleanup.py
check_batch_cost	30min	计算批处理任务成本	proxy/management_helpers/check_batch_cost_job.py
check_responses_cost	30min	计算 Responses API 成本	proxy/management_helpers/check_responses_cost_job.py
process_rotations	1h	API key 自动轮换	proxy/management_helpers/key_rotation_manager.py
_run_background_health_check	持续	模型部署健康检查	proxy/proxy_server.py
send_weekly_spend_report	每周	Slack 消费告警	proxy/utils.py（SlackAlerting）
send_monthly_spend_report	每月	Slack 消费告警	proxy/utils.py（SlackAlerting）

与当前源码的对照：文档中部分“关键文件”列的是历史路径。在当前仓库中，ResetBudgetJob 实际位于 proxy/common_utils/reset_budget_job.py（management_helpers/ 目录如今承载的是团队/审计类辅助逻辑）；引用具体文件前建议按类名在当前源码中检索确认。

从 proxy_server.py 的实际实现看，调度器配置有几处值得注意的工程细节：

• 使用 AsyncIOScheduler + MemoryJobStore + AsyncIOExecutor，并显式关闭时区感知，以降低常驻内存开销；
• 每个任务都带 replace_existing=True 与较大的 misfire_grace_time，避免重复注册与积压计算；
• 源码注释明确记录了一次内存泄漏修复：APScheduler 的 jitter 参数（normalize()/_apply_jitter()）曾造成大量内存分配，因此当前实现改为“固定间隔 + 少量随机偏移”（如预算重置间隔在 min/max 之间加随机值，update_spend 间隔为 proxy_batch_write_at + 随机 0–5s）；
• add_deployment 任务同样带有“间隔从 10s 提升到 30s 下限”的内存优化注释，因此文档表格中的“10s”应理解为设计意图，当前默认按 30s 量级运行（见 proxy_server.py）。

除了文档表格列出的任务外，当前源码中还注册了若干相邻任务，如 proxy_worker_heartbeat_job（多副本心跳）、update_daily_tag_spend_job（标签维度日消费，间隔为主写间隔的倍数倍率）、update_gateway_requests_job（网关请求计数 flush）、periodic_reload_job（周期性重载模型价格表与 Anthropic beta 头），以及基于队列大小触发的 _monitor_spend_logs_queue 异步任务——这些都印证了文档中“spend 更新走队列 + 定时批量落库”的设计（见 proxy_server.py）。

成本归因（Cost Attribution）八步链路

1. litellm.acompletion() 返回后，响应进入 utils.py 的包装层；
2. 调用 update_response_metadata()（llm_response_utils/response_metadata.py）；
3. logging_obj._response_cost_calculator()（litellm_logging.py）通过 litellm.completion_cost()（cost_calculator.py）计算成本；
4. 成本写入 response._hidden_params["response_cost"]；
5. proxy/common_request_processing.py 从 hidden_params 取出成本并写入响应头 x-litellm-response-cost；
6. logging_obj.async_success_handler() 触发回调，包括 _ProxyDBLogger.async_log_success_event()；
7. DBSpendUpdateWriter.update_database() 把 spend 增量入队到 Redis；
8. 后台任务 update_spend 每 60s 将队列中的 spend 批量刷入 PostgreSQL。

这条链路的设计要点是：响应主路径只做一次廉价的元数据写入（_hidden_params），真正的 DB 写入全部异步化、批量化，既不阻塞请求，也避免每请求一次 DB 写。

4. 数据访问层：litellm/models 与 litellm/repositories

数据库实体定义与数据访问被放在 litellm/ 根目录下的两个包中，这样 Gateway 和 SDK 都能使用而不必 import proxy 内部：

• litellm/models/：所有持久化实体的 Pydantic 规范定义（LiteLLM_VerificationToken、LiteLLM_TeamTable、LiteLLM_UserTable 等）。proxy/_types.py 重新导出这些模型以兼容旧 import。
• litellm/repositories/：数据访问层。BaseRepository[T] 提供泛型 CRUD（find_by_id、find_many、create、update、delete、count、exists）；实体仓库在其上叠加领域查询。

源码中可以确认的核心类位置：

• repositories/base_repository.py：class BaseRepository(ABC, Generic[T])
• repositories/verification_token_repository.py：VerificationTokenRepository(BaseRepository[LiteLLM_VerificationToken])
• repositories/team_repository.py：TeamRepository(BaseRepository[LiteLLM_TeamTable])
• repositories/user_repository.py：UserRepository(BaseRepository[LiteLLM_UserTable])

该层需要遵守的四条约定：

关注点	处理方式
JSON 列	Prisma 的 Json 列按 JSON 字符串存储；仓库在写入时 json.dumps()、读取时 json.loads()（见 _to_model 与 _build_*_data 辅助函数）
先归档后删除	delete_team/delete_token 在单个 prisma_client.db.tx() 事务内把行拷贝到 LiteLLM_Deleted* 表再删原行；归档载荷显式构造，只写归档表实际存在的列
列名与字段名映射	模型字段与 DB 列不一致时（如 org_id 对应 organization_id 列），由仓库双向显式转换，不依赖 Pydantic 猜测
数组变更	追加使用 Prisma 原子 push（add_member、add_admin、add_models）避免读-改-写竞态；删除因 Prisma 无原子数组移除，回退为读-改-写

新增实体的标准流程：在 litellm/models/ 定义模型 → 若旧代码从那里 import 则在 proxy/_types.py 重新导出 → 在 litellm/repositories/ 添加仓库（普通 CRUD 继承 BaseRepository；需要加密、归档或原子数组更新时补充定制方法）→ 参照 tests/test_litellm/repositories/ 镜像测试。

5. SDK 请求流：completion() 到 Provider API

SDK（litellm/）是直连用户与 AI Gateway 共同依赖的核心调用层，流程如下：

graph TD
    subgraph "SDK Entry Points"
        Completion["litellm.completion()"]
        Messages["litellm.messages()"]
    end

    subgraph "main.py"
        Main["completion()<br/>acompletion()"]
    end

    subgraph "utils.py"
        GetProvider["get_llm_provider()"]
    end

    subgraph "llms/custom_httpx/"
        Handler["llm_http_handler.py<br/>BaseLLMHTTPHandler"]
        HTTP["http_handler.py<br/>HTTPHandler / AsyncHTTPHandler"]
    end

    subgraph "llms/{provider}/chat/"
        TransformReq["transform_request()"]
        TransformResp["transform_response()"]
    end

    subgraph "litellm_core_utils/"
        Streaming["streaming_handler.py"]
    end

    subgraph "integrations/ (async, off main thread)"
        Callbacks["custom_logger.py<br/>Langfuse, Datadog, etc."]
    end

    Completion --> Main
    Messages --> Main
    Main --> GetProvider
    GetProvider --> Handler
    Handler --> TransformReq
    TransformReq --> HTTP
    HTTP --> Provider["LLM Provider API"]
    Provider --> HTTP
    HTTP --> TransformResp
    TransformResp --> Streaming
    Streaming --> Response["ModelResponse"]
    Response -.->|async| Callbacks

SDK 关键文件：

文件	职责
main.py	入口：completion()、acompletion()、embedding()
utils.py	get_llm_provider() 完成 model → provider 解析
llms/custom_httpx/llm_http_handler.py	中央 HTTP 编排器
llms/custom_httpx/http_handler.py	底层 HTTP 客户端（HTTPHandler/AsyncHTTPHandler）
llms/{provider}/chat/transformation.py	Provider 专属转换
litellm_core_utils/streaming_handler.py	流式响应处理
integrations/	异步回调（Langfuse、Datadog 等），在主线程之外执行

注意图中“integrations（async, off main thread）”这层含义：日志与观测回调不会阻塞模型调用主路径，这与第 3 节代理侧“成本归因异步化”是同构的设计思想。

6. 翻译层（Translation Layer）：多 Provider 兼容的核心机制

请求进入后会经过翻译层在各 API 格式之间转换。每个翻译独立成文件，可单独测试与修改——这是 LiteLLM 能支撑 100+ LLM API 的关键组织方式。

翻译文件速查表

入站 API	Provider	翻译文件
/v1/chat/completions	Anthropic	llms/anthropic/chat/transformation.py
/v1/chat/completions	Bedrock Converse	llms/bedrock/chat/converse_transformation.py
/v1/chat/completions	Bedrock Invoke	llms/bedrock/chat/invoke_transformations/anthropic_claude3_transformation.py
/v1/chat/completions	Gemini	llms/gemini/chat/transformation.py
/v1/chat/completions	Vertex AI	llms/vertex_ai/gemini/transformation.py
/v1/chat/completions	OpenAI	llms/openai/chat/gpt_transformation.py
/v1/messages（透传）	Anthropic	llms/anthropic/experimental_pass_through/messages/transformation.py
/v1/messages（透传）	Bedrock	llms/bedrock/messages/invoke_transformations/anthropic_claude3_transformation.py
/v1/messages（透传）	Vertex AI	llms/vertex_ai/vertex_ai_partner_models/anthropic/experimental_pass_through/transformation.py
透传端点	全部	proxy/pass_through_endpoints/llm_provider_handlers/

实战示例：调试 prompt caching

当 /v1/messages → Bedrock Converse 的 prompt caching 不生效、而 Bedrock Invoke 正常时，按文档给定的排查路径：

1. Bedrock Converse 翻译：llms/bedrock/chat/converse_transformation.py
2. Bedrock Invoke 翻译：llms/bedrock/chat/invoke_transformations/anthropic_claude3_transformation.py
3. 对比两者在 transform_request() 中对 cache_control 的处理差异。

翻译的统一契约

每个 Provider 有一个继承自 BaseConfig（llms/base_llm/chat/transformation.py）的 Config 类：

class ProviderConfig(BaseConfig):
    def transform_request(self, model, messages, optional_params, litellm_params, headers):
        # 将 OpenAI 格式转换为 Provider 格式
        return {"messages": transformed_messages, ...}

    def transform_response(self, model, raw_response, model_response, logging_obj, ...):
        # 将 Provider 格式转回 OpenAI 格式
        return ModelResponse(choices=[...], usage=Usage(...))

BaseLLMHTTPHandler（llm_http_handler.py）负责调用这两个方法——修 Provider 问题几乎永远不需要改 handler 本身，只需改对应 Provider 的 Config。这正是“治理在 Proxy、兼容在 SDK、差异在 translation”三层分离思想的落点。

7. 新增/修改 Provider 的完整清单

新增 Provider

1. 创建 llms/{provider}/chat/transformation.py；
2. 实现 Config 类，提供 transform_request() 与 transform_response()；
3. 在 tests/llm_translation/test_{provider}.py 添加测试。

新增功能（如 prompt caching）

1. 按上表找到对应翻译文件；
2. 修改 transform_request() 处理新参数；
3. 添加验证转换结果的单元测试。

跨路径测试清单

功能改动需在所有请求路径上验证：

测试	文件模式
OpenAI 透传	tests/llm_translation/test_openai*.py
Anthropic 直连	tests/llm_translation/test_anthropic*.py
Bedrock Invoke	tests/llm_translation/test_bedrock*.py
Bedrock Converse	tests/llm_translation/test_bedrock*converse*.py
Vertex AI	tests/llm_translation/test_vertex*.py
Gemini	tests/llm_translation/test_gemini*.py

翻译层的单元测试方式

翻译层的设计目标之一就是不发真实 API 请求即可单测。文档给出的示例（以 Bedrock Converse 的 prompt caching 为例）：

from litellm.llms.bedrock.chat.converse_transformation import BedrockConverseConfig

def test_prompt_caching_transform():
    config = BedrockConverseConfig()
    result = config.transform_request(
        model="anthropic.claude-3-opus",
        messages=[{"role": "user", "content": "test", "cache_control": {"type": "ephemeral"}}],
        optional_params={},
        litellm_params={},
        headers={}
    )
    assert "cachePoint" in str(result)  # 验证 cache_control 已被正确翻译

这种“直接实例化 Config 并断言 transform_request() 输出”的测试模式，在 tests/llm_translation/ 目录下有大量同类用例可参照。

8. 结语：把架构当作“改动地图”使用

回到 ARCHITECTURE.md 开篇的定位——它首先是一份贡献者改动地图。把全文浓缩成四条决策规则：

1. 认证/限流/预算问题 → 查 proxy/auth/ 与 proxy/hooks/，热路径依赖 Redis，勿引入同步 DB 查询；
2. 路由/负载均衡问题 → 查 router.py 与 router_strategy/，TPM/RPM 与冷却状态在 Router.cache（DualCache）；
3. 某 Provider 的格式/参数/流式问题 → 查 llms/{provider}/chat/transformation.py，只改 Config，不改 BaseLLMHTTPHandler；
4. 成本/落库/后台任务问题 → 沿“_hidden_params → DBSpendUpdateWriter → Redis 队列 → update_spend 批量落库”链路排查，并结合 proxy_server.py 中 initialize_scheduled_background_jobs() 的实际任务注册确认间隔与开关（如 disable_reset_budget、STORE_MODEL_IN_DB）。

掌握这条从 HTTP 端点、治理钩子、路由、SDK 翻译、成本归因到 Redis/PostgreSQL 落地的完整链路，就能在 LiteLLM 中快速定位任意功能归属的层次与文件，做出边界清晰的修改。