尧图网站建设 
LiteLLM 生产部署指南3 条命令跑通网关成本、密钥、监控一次配好【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm假设你的团队同时在用 OpenAI、Anthropic 和 Bedrock现在要让业务代码只对接一个地址还能回答这个月各团队花了多少钱。LiteLLM ProxyAI 网关就是干这件事的一个 OpenAI 兼容入口背后路由到 100 家模型服务自带虚拟密钥、预算控制和成本记账。下面按先跑起来再加固的顺序带你走一遍全程用 Docker Compose不装 Python 环境。一、部署前的三件小事开工前把这三件事过一遍后面不会卡在环境上检查 Docker执行docker compose version能打印版本号说明 Docker 和 Compose 插件都就位。确认端口空闲网关占 4000、数据库 5432、监控 9090。跑ss -tlnp | grep -E 4000|5432|9090没有输出就可以直接用默认配置。拉取代码git clone https://gitcode.com/GitHub_Trending/li/litellm然后cd litellm。仓库里的 docker-compose.yml 就是本次部署的编排文件Docker 部署文档 记录了非 root 构建的完整流程。做完这一步你会得到一份可部署的代码目录且确认三个端口不会被抢占。二、一条命令先跑起来准备密钥与最小配置网关需要两把钥匙。在仓库根目录创建.env# 管理面主密钥所有后台接口的总入口 LITELLM_MASTER_KEYsk-$(openssl rand -hex 16) # 数据面签名密钥随机即可泄露后已签发的虚拟密钥会失效 LITELLM_SALT_KEY$(openssl rand -base64 32)再写一份最小化config.yaml只挂一个模型、一个入口model_list: - model_name: chat-default litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY general_settings: master_key: os.environ/LITELLM_MASTER_KEY注意os.environ/前缀它让密钥从环境变量读取而不是明文写进配置文件。把OPENAI_API_KEY或对应厂商的密钥也追加进.env。完成后目录里应有.env、config.yaml两个新文件。启动并验证成功一条命令启动全部服务docker compose up -d --build构建首次会拉镜像并编译 UI耐心等一两分钟。然后逐条验证docker compose ps # 三个服务都应为 Up curl http://localhost:4000/health/liveliveness # 返回 200 即存活 docker compose logs -f litellm # 看到 Application started 即可 CtrlC 退出最后打开http://localhost:4000/ui输入主密钥登录管理界面。你能看到模型列表和chat-default这个模型组说明网关、数据库、UI 三件套全部就绪。三、它背后到底在跑什么别把docker compose up后面黑箱运行。容器里其实跑着三个组件架构文档 里有完整的请求时序图组件职责源码位置LiteLLM ProxyFastAPI 网关鉴权、限流、预算、路由核心已用 Rust 重写提速litellm/proxy/LiteLLM SDK把各厂商请求/响应转成统一 OpenAI 格式处理流式litellm/llms/PostgreSQL 16持久化模型配置、虚拟密钥、团队与花费流水docker-compose.yml 中db服务Prometheus抓取网关 4000 端口的/metrics保留 15 天prometheus.yml一次请求的完整链路是客户端打/v1/chat/completions→ 网关校验虚拟密钥并查预算 → 路由层选部署实例 → SDK 转换格式后转发上游 → 响应回来后按 token 计费、异步写库同时把成本放进x-litellm-response-cost响应头。理解这条链路后调优就有抓手了都在 config.yaml 里路由策略router_settings.routing_strategy例如usage-based-routing-v2按各实例负载分配流量。重试与超时litellm_settings.num_retries和request_timeout单模型还能配rpm、stream_timeout。缓存litellm_settings.cache: true开启响应缓存配 Redis 后跨实例共享。水平扩展加实例前先看 docker-compose.yml 里被注释的 Redis 配置——多副本的限流计数、花费汇总、共享健康检查都需要一个协调用 Redis否则各实例各算各的账。四、从开发到生产的加固开发机上能跑不等于能上生产。按下面这张表逐项过加固项操作验证方式主密钥保密只放.env不要提交进版本库定期轮换git status确认.env未跟踪轮换后旧密钥调/key/info返回 401签名密钥保密LITELLM_SALT_KEY用高强度随机值丢失会导致已签发密钥无法解密备份到密码管理器.env不入 Git端口暴露生产环境把 5432 从 docker-compose.yml 的ports中删掉数据库只留在内网ss -tlnp看不到 5432容器降权仓库提供了非 root、只读根文件系统的加固编排用docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d起服务docker/README.md 的 Hardened 一节有验证命令虚拟密钥收敛给每个团队发限定模型范围和有效期的密钥别把主密钥发出去curl -X POST http://localhost:4000/key/generate -H Authorization: Bearer $LITELLM_MASTER_KEY -d {models:[chat-default],duration:30d,max_parallel_requests:5}用新密钥打/v1/chat/completions成功但访问gpt-4o等其他模型被拒数据库备份每天定时导出docker compose exec db pg_dump -U llmproxy litellm backup_$(date %F).sql恢复到空库能成功登录 UI做完这一节你应该有一份可提交的docker-compose.yml去掉了 5432 映射、一个密钥轮换日期约定以及第一条能正常备份的数据库。五、监控与成本看得见网关自带 Prometheus 指标prometheus.yml 已配好每 15 秒抓取一次。打开http://localhost:9090重点关注这几类请求量litellm_proxy_total_requests_metric按 API key、团队、模型分组是容量和异常流量的第一信号。花费总花费与按 key/团队拆分的花费指标对照预算曲线看哪个团队在烧钱。延迟部署维度的耗时分布配合num_retries观察重试是否放大长尾。接告警不用换栈Prometheus 原生支持即可在prometheus.yml同级放一个告警规则文件写rules_file指过去典型规则是5 分钟 4xx/5xx 比例超过 10% 持续 10 分钟和某团队花费达到预算 80%。告警动作交给 Alertmanager 转发到 IM 或邮件。另外管理界面里的 Usage 和 Audit Logs 页面能直接查单笔请求的成本与管理操作记录排障时比翻日志快得多。六、踩坑速查表现象原因处理容器反复重启日志报Master key is not initialized.env里没写LITELLM_MASTER_KEY或 Compose 没加载.env在仓库根目录补上该变量docker compose up -d重启docker compose ps显示 litellm 一直 unhealthy首次启动要跑数据库迁移超过了健康检查的start_period等 40 秒左右再看一次仍失败就docker compose logs litellm查数据库连接错误UI 打开但所有接口 401登录用的主密钥与.env里不一致或中间多带了空格重新从.env复制完整值登录调用返回 404 Model Not Found请求里的model写成了厂商名如gpt-4o-mini而不是model_name统一用配置文件里定义的model_name本例是chat-default多副本部署后限流失效、花费对不上没配协调 Redis各实例本地计数按 docker-compose.yml 中注释启用redis_host相关配置后重新up -d构建阶段报build_admin_ui.sh: not found没在仓库根目录执行构建工作目录不对回到仓库根目录再跑docker compose up -d --build七、收尾 Checklist部署完成前逐项打勾确认docker compose ps三个服务均为 Up 且 litellm 健康curl http://localhost:4000/health/liveliveness返回 200UI 能登录model_list里的模型可正常对话.env包含随机生成的LITELLM_MASTER_KEY与LITELLM_SALT_KEY.env未进入版本库git status干净5432 端口未对宿主机外暴露至少给一个团队签发了带模型范围和有效期的虚拟密钥并实测越权模型被拒每日pg_dump备份已排进 crontab 或 CIPrometheus 能查到请求量与花费指标至少配了一条 4xx/5xx 比例告警记录了一次主密钥轮换的演练步骤改.env→docker compose up -d→ 旧密钥立即失效全部勾完这套 LiteLLM 网关就算真正生产可用了入口统一、密钥收敛、账目可见。后续加模型、加路由策略都只是改一份 config.yaml 的事。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LiteLLM 生产部署指南：3 条命令跑通网关，成本、密钥、监控一次配好
LiteLLM 生产部署指南3 条命令跑通网关成本、密钥、监控一次配好【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm假设你的团队同时在用 OpenAI、Anthropic 和 Bedrock现在要让业务代码只对接一个地址还能回答这个月各团队花了多少钱。LiteLLM ProxyAI 网关就是干这件事的一个 OpenAI 兼容入口背后路由到 100 家模型服务自带虚拟密钥、预算控制和成本记账。下面按先跑起来再加固的顺序带你走一遍全程用 Docker Compose不装 Python 环境。一、部署前的三件小事开工前把这三件事过一遍后面不会卡在环境上检查 Docker执行docker compose version能打印版本号说明 Docker 和 Compose 插件都就位。确认端口空闲网关占 4000、数据库 5432、监控 9090。跑ss -tlnp | grep -E 4000|5432|9090没有输出就可以直接用默认配置。拉取代码git clone https://gitcode.com/GitHub_Trending/li/litellm然后cd litellm。仓库里的 docker-compose.yml 就是本次部署的编排文件Docker 部署文档 记录了非 root 构建的完整流程。做完这一步你会得到一份可部署的代码目录且确认三个端口不会被抢占。二、一条命令先跑起来准备密钥与最小配置网关需要两把钥匙。在仓库根目录创建.env# 管理面主密钥所有后台接口的总入口 LITELLM_MASTER_KEYsk-$(openssl rand -hex 16) # 数据面签名密钥随机即可泄露后已签发的虚拟密钥会失效 LITELLM_SALT_KEY$(openssl rand -base64 32)再写一份最小化config.yaml只挂一个模型、一个入口model_list: - model_name: chat-default litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY general_settings: master_key: os.environ/LITELLM_MASTER_KEY注意os.environ/前缀它让密钥从环境变量读取而不是明文写进配置文件。把OPENAI_API_KEY或对应厂商的密钥也追加进.env。完成后目录里应有.env、config.yaml两个新文件。启动并验证成功一条命令启动全部服务docker compose up -d --build构建首次会拉镜像并编译 UI耐心等一两分钟。然后逐条验证docker compose ps # 三个服务都应为 Up curl http://localhost:4000/health/liveliveness # 返回 200 即存活 docker compose logs -f litellm # 看到 Application started 即可 CtrlC 退出最后打开http://localhost:4000/ui输入主密钥登录管理界面。你能看到模型列表和chat-default这个模型组说明网关、数据库、UI 三件套全部就绪。三、它背后到底在跑什么别把docker compose up后面黑箱运行。容器里其实跑着三个组件架构文档 里有完整的请求时序图组件职责源码位置LiteLLM ProxyFastAPI 网关鉴权、限流、预算、路由核心已用 Rust 重写提速litellm/proxy/LiteLLM SDK把各厂商请求/响应转成统一 OpenAI 格式处理流式litellm/llms/PostgreSQL 16持久化模型配置、虚拟密钥、团队与花费流水docker-compose.yml 中db服务Prometheus抓取网关 4000 端口的/metrics保留 15 天prometheus.yml一次请求的完整链路是客户端打/v1/chat/completions→ 网关校验虚拟密钥并查预算 → 路由层选部署实例 → SDK 转换格式后转发上游 → 响应回来后按 token 计费、异步写库同时把成本放进x-litellm-response-cost响应头。理解这条链路后调优就有抓手了都在 config.yaml 里路由策略router_settings.routing_strategy例如usage-based-routing-v2按各实例负载分配流量。重试与超时litellm_settings.num_retries和request_timeout单模型还能配rpm、stream_timeout。缓存litellm_settings.cache: true开启响应缓存配 Redis 后跨实例共享。水平扩展加实例前先看 docker-compose.yml 里被注释的 Redis 配置——多副本的限流计数、花费汇总、共享健康检查都需要一个协调用 Redis否则各实例各算各的账。四、从开发到生产的加固开发机上能跑不等于能上生产。按下面这张表逐项过加固项操作验证方式主密钥保密只放.env不要提交进版本库定期轮换git status确认.env未跟踪轮换后旧密钥调/key/info返回 401签名密钥保密LITELLM_SALT_KEY用高强度随机值丢失会导致已签发密钥无法解密备份到密码管理器.env不入 Git端口暴露生产环境把 5432 从 docker-compose.yml 的ports中删掉数据库只留在内网ss -tlnp看不到 5432容器降权仓库提供了非 root、只读根文件系统的加固编排用docker compose -f docker-compose.yml -f docker-compose.hardened.yml up -d起服务docker/README.md 的 Hardened 一节有验证命令虚拟密钥收敛给每个团队发限定模型范围和有效期的密钥别把主密钥发出去curl -X POST http://localhost:4000/key/generate -H Authorization: Bearer $LITELLM_MASTER_KEY -d {models:[chat-default],duration:30d,max_parallel_requests:5}用新密钥打/v1/chat/completions成功但访问gpt-4o等其他模型被拒数据库备份每天定时导出docker compose exec db pg_dump -U llmproxy litellm backup_$(date %F).sql恢复到空库能成功登录 UI做完这一节你应该有一份可提交的docker-compose.yml去掉了 5432 映射、一个密钥轮换日期约定以及第一条能正常备份的数据库。五、监控与成本看得见网关自带 Prometheus 指标prometheus.yml 已配好每 15 秒抓取一次。打开http://localhost:9090重点关注这几类请求量litellm_proxy_total_requests_metric按 API key、团队、模型分组是容量和异常流量的第一信号。花费总花费与按 key/团队拆分的花费指标对照预算曲线看哪个团队在烧钱。延迟部署维度的耗时分布配合num_retries观察重试是否放大长尾。接告警不用换栈Prometheus 原生支持即可在prometheus.yml同级放一个告警规则文件写rules_file指过去典型规则是5 分钟 4xx/5xx 比例超过 10% 持续 10 分钟和某团队花费达到预算 80%。告警动作交给 Alertmanager 转发到 IM 或邮件。另外管理界面里的 Usage 和 Audit Logs 页面能直接查单笔请求的成本与管理操作记录排障时比翻日志快得多。六、踩坑速查表现象原因处理容器反复重启日志报Master key is not initialized.env里没写LITELLM_MASTER_KEY或 Compose 没加载.env在仓库根目录补上该变量docker compose up -d重启docker compose ps显示 litellm 一直 unhealthy首次启动要跑数据库迁移超过了健康检查的start_period等 40 秒左右再看一次仍失败就docker compose logs litellm查数据库连接错误UI 打开但所有接口 401登录用的主密钥与.env里不一致或中间多带了空格重新从.env复制完整值登录调用返回 404 Model Not Found请求里的model写成了厂商名如gpt-4o-mini而不是model_name统一用配置文件里定义的model_name本例是chat-default多副本部署后限流失效、花费对不上没配协调 Redis各实例本地计数按 docker-compose.yml 中注释启用redis_host相关配置后重新up -d构建阶段报build_admin_ui.sh: not found没在仓库根目录执行构建工作目录不对回到仓库根目录再跑docker compose up -d --build七、收尾 Checklist部署完成前逐项打勾确认docker compose ps三个服务均为 Up 且 litellm 健康curl http://localhost:4000/health/liveliveness返回 200UI 能登录model_list里的模型可正常对话.env包含随机生成的LITELLM_MASTER_KEY与LITELLM_SALT_KEY.env未进入版本库git status干净5432 端口未对宿主机外暴露至少给一个团队签发了带模型范围和有效期的虚拟密钥并实测越权模型被拒每日pg_dump备份已排进 crontab 或 CIPrometheus 能查到请求量与花费指标至少配了一条 4xx/5xx 比例告警记录了一次主密钥轮换的演练步骤改.env→docker compose up -d→ 旧密钥立即失效全部勾完这套 LiteLLM 网关就算真正生产可用了入口统一、密钥收敛、账目可见。后续加模型、加路由策略都只是改一份 config.yaml 的事。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考