LiteLLM 插件完全指南3 步把 AI 应用接入任意第三方工具【免费下载链接】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上上周给团队 demo 一个 AI 客服老板随口问了一句这十万次调用到底花了多少钱哪家模型最容易超时我愣在原地——数据散落各处谁也没接。后来我发现答案其实藏在LiteLLM 插件系统里。LiteLLM 是一个主打轻量的 AI 网关AI Gateway能用 OpenAI 兼容格式调用 100 LLM API自带成本追踪、负载均衡、guardrails 和日志能力。而它的插件机制让日志、监控、安全这类外部工具不再需要你重写一遍适配代码。读完整篇你会拿到三样东西一个 10 分钟能跑通的首次集成、一套讲透钩子生命周期的原理拆解以及一份从零开发 LiteLLM 自定义插件的完整示例。三步完成首次集成先把日志自动落到 S3先上结果——下面这段最小示例可以直接跑跑通后你每次 LLM 调用的请求与响应日志都会自动写进 S3 桶import litellm from litellm.integrations.s3 import S3Logger # 第 1 步实例化一个现成的日志插件 s3_logger S3Logger( s3_bucket_nameyour-bucket, s3_pathlogs/litellm/, s3_region_nameus-east-1 ) # 第 2 步通过 callbacks 参数把插件挂上去 response litellm.completion( modelgpt-3.5-turbo, messages[{role: user, content: Hello World}], callbacks[s3_logger] ) # 第 3 步去 S3 桶里确认 logs/litellm/ 下出现了日志对象搞定 ✅为什么这么做三个动作对应三件事实例化插件S3Logger是 LiteLLM 内置的第三方工具适配器你只声明日志去哪桶、路径、区域不用关心怎么传。注册回调callbacks[s3_logger]这一行是全部魔法的入口插件从此接管了这次调用的生命周期事件。零改动业务代码注意completion的参数一个字都没变——这正是插件系统的意义所在业务逻辑不感知外部系统的存在。所有现成插件都放在 litellm/integrations/ 目录S3 的实现就在 litellm/integrations/s3.py。机制拆解插件系统到底怎么工作会用之后花两分钟把原理看懂后面排错会快很多。插件系统采用模块化设计核心就三块插件管理器统一注册和调度、钩子机制挂载到请求生命周期的不同阶段、标准化接口所有插件的公共方言。一次调用发生时内部流程是这样的插件注册第三方工具实现标准接口后通过callbacks注册进来钩子挂载插件把自己挂到请求前、响应后、出错时等不同生命周期节点事件触发当这些事件真实发生插件管理器自动调用对应钩子函数。所有插件要遵守的公共方言定义在 litellm/integrations/custom_logger.py 的CustomLogger基类里最关键的三个方法是log_success_event(kwargs, response_obj, start_time, end_time)调用成功时的同步日志钩子async_log_success_event(kwargs, response_obj, start_time, end_time)对应的异步版本log_failure_event(kwargs, response_obj, start_time, end_time)调用失败时的钩子下面这张截图就是一个日志插件挂上之后的真实效果——每次 LiteLLM 调用都变成了可追踪的结构化 trace延迟、token 数、成本一目了然记住这张事件 → 钩子的映射关系后面写自定义插件时你只需要挑自己想听的事件在对应方法里写逻辑即可。典型集成场景实操日志、监控、安全内置插件覆盖了 20 多种常用服务AWS、Datadog、Slack 等都在 litellm/integrations/ 里这里挑三个最高频的场景讲。把日志搬进 S3审计与合规的基本盘前面快速上手已经跑通了 S3。再补一句实战细节S3Logger还支持从环境变量读密钥、指定s3_endpoint_url接兼容 S3 协议的自建存储甚至服务端加密参数生产环境基本不用改代码只改配置。适合场景调用留痕、合规审计、离线分析。用 Prometheus 盯住每一次调用监控诉求更轻实例化 litellm/integrations/prometheus_services.py 中的PrometheusService然后把它放进litellm.callbacks所有 LLM 请求就会自动产出指标——请求量、延迟分布、错误率直接进 Grafana。这一步就是LiteLLM 集成 Prometheus的全部工作量通常五分钟以内。给敏感内容上一道安检门合规场景要用的是 litellm/integrations/custom_guardrail.py 里的CustomGuardrail。初始化时给它两个参数guardrail_name比如content-filter用于请求里引用和supported_event_hooks声明它挂在哪些节点如pre_call、post_call。挂上之后带敏感内容的请求会在到达模型之前被拦截并返回明确错误而不是回答完再擦屁股。上面是 Proxy 面板里的审计日志视图配合安全钩子使用谁改了什么、哪些请求被拦下全程可查。从零开发一个自定义插件Token 统计器内置的不够用自定义插件开发就三步继承基础类 → 定义钩子 → 注册回调。下面这个 Token 统计器完整可跑跟着做一遍就懂了from litellm.integrations.custom_logger import CustomLogger import time # 第 1 步继承 CustomLogger 基类 class TokenCounterLogger(CustomLogger): def __init__(self): self.token_stats { total_tokens: 0, request_count: 0 } # 第 2 步实现你关心的钩子这里是成功事件 def log_success_event(self, kwargs, response_obj, start_time, end_time): if hasattr(response_obj, usage): self.token_stats[total_tokens] response_obj.usage.total_tokens self.token_stats[request_count] 1 print(f累计请求: {self.token_stats[request_count]}, 累计Token: {self.token_stats[total_tokens]}) # 第 3 步实例化并通过 callbacks 注册 counter TokenCounterLogger() response litellm.completion( modelgpt-3.5-turbo, messages[{role: user, content: Hello World}], callbacks[counter] )三步拆开看继承CustomLogger拿到标准插槽重写log_success_event把自己的逻辑填进调用成功这个事件里钩子的参数里就有完整的请求上下文和响应对象想取什么取什么最后callbacks[counter]一行完成注册。这就是 LiteLLM 插件开发的完整闭环换个钩子方法比如改监听log_failure_event就能做别的统计。踩坑清单与调优建议这几个坑我帮你趟过了照着检查一遍能省不少事⚡ 耗时操作请走异步钩子在主链路上你要是同步去写慢存储整个请求都会被拖住。耗时逻辑统一放到async_log_success_event这类异步方法里处理。 别一条一条传攒着发高 QPS 下逐条上传会把带宽和连接数打爆。参考 litellm/integrations/s3_v2.py 的做法——先进内存队列达到批量大小或到达刷新间隔再一次性 flush 上传吞吐直接上一个台阶。 用缓存减少重复计算比如 prompt 相关开销可以借助 litellm/router_utils/prompt_caching_cache.py 的缓存策略让重复请求不再重复付费。⚔️ 多个插件抢同一个钩子插件可以并行挂在同一事件上但执行顺序会影响结果。挂多个时留意优先级设置把拦截类插件放在记录类插件前面心里才踏实。 插件自己也会吃资源监控/日志插件是寄生在主请求链路上的自身开销要盯着看别让它从观察者变成瓶颈。 版本兼容要留心核心版本迭代较快升级 LiteLLM 时记得核对插件接口有没有变动贡献规范见 CONTRIBUTING.md。写在最后现在 litellm/integrations/ 目录里已经有 20 多种主流服务集成从 AWS 到 Datadog、Slack 基本都有现成轮子未来插件系统还会开放更多生命周期钩子社区也在往成本监控、多模态处理这些场景上加料。如果你按上面的步骤写出了自己觉得好用的插件欢迎通过 CONTRIBUTING.md 提个 PR让它被更多人用到 。对了先收藏一下——下期预告《LiteLLM 插件市场使用指南》教你把散落各处的集成配置统一管理。【免费下载链接】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 步把 AI 应用接入任意第三方工具
LiteLLM 插件完全指南3 步把 AI 应用接入任意第三方工具【免费下载链接】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上上周给团队 demo 一个 AI 客服老板随口问了一句这十万次调用到底花了多少钱哪家模型最容易超时我愣在原地——数据散落各处谁也没接。后来我发现答案其实藏在LiteLLM 插件系统里。LiteLLM 是一个主打轻量的 AI 网关AI Gateway能用 OpenAI 兼容格式调用 100 LLM API自带成本追踪、负载均衡、guardrails 和日志能力。而它的插件机制让日志、监控、安全这类外部工具不再需要你重写一遍适配代码。读完整篇你会拿到三样东西一个 10 分钟能跑通的首次集成、一套讲透钩子生命周期的原理拆解以及一份从零开发 LiteLLM 自定义插件的完整示例。三步完成首次集成先把日志自动落到 S3先上结果——下面这段最小示例可以直接跑跑通后你每次 LLM 调用的请求与响应日志都会自动写进 S3 桶import litellm from litellm.integrations.s3 import S3Logger # 第 1 步实例化一个现成的日志插件 s3_logger S3Logger( s3_bucket_nameyour-bucket, s3_pathlogs/litellm/, s3_region_nameus-east-1 ) # 第 2 步通过 callbacks 参数把插件挂上去 response litellm.completion( modelgpt-3.5-turbo, messages[{role: user, content: Hello World}], callbacks[s3_logger] ) # 第 3 步去 S3 桶里确认 logs/litellm/ 下出现了日志对象搞定 ✅为什么这么做三个动作对应三件事实例化插件S3Logger是 LiteLLM 内置的第三方工具适配器你只声明日志去哪桶、路径、区域不用关心怎么传。注册回调callbacks[s3_logger]这一行是全部魔法的入口插件从此接管了这次调用的生命周期事件。零改动业务代码注意completion的参数一个字都没变——这正是插件系统的意义所在业务逻辑不感知外部系统的存在。所有现成插件都放在 litellm/integrations/ 目录S3 的实现就在 litellm/integrations/s3.py。机制拆解插件系统到底怎么工作会用之后花两分钟把原理看懂后面排错会快很多。插件系统采用模块化设计核心就三块插件管理器统一注册和调度、钩子机制挂载到请求生命周期的不同阶段、标准化接口所有插件的公共方言。一次调用发生时内部流程是这样的插件注册第三方工具实现标准接口后通过callbacks注册进来钩子挂载插件把自己挂到请求前、响应后、出错时等不同生命周期节点事件触发当这些事件真实发生插件管理器自动调用对应钩子函数。所有插件要遵守的公共方言定义在 litellm/integrations/custom_logger.py 的CustomLogger基类里最关键的三个方法是log_success_event(kwargs, response_obj, start_time, end_time)调用成功时的同步日志钩子async_log_success_event(kwargs, response_obj, start_time, end_time)对应的异步版本log_failure_event(kwargs, response_obj, start_time, end_time)调用失败时的钩子下面这张截图就是一个日志插件挂上之后的真实效果——每次 LiteLLM 调用都变成了可追踪的结构化 trace延迟、token 数、成本一目了然记住这张事件 → 钩子的映射关系后面写自定义插件时你只需要挑自己想听的事件在对应方法里写逻辑即可。典型集成场景实操日志、监控、安全内置插件覆盖了 20 多种常用服务AWS、Datadog、Slack 等都在 litellm/integrations/ 里这里挑三个最高频的场景讲。把日志搬进 S3审计与合规的基本盘前面快速上手已经跑通了 S3。再补一句实战细节S3Logger还支持从环境变量读密钥、指定s3_endpoint_url接兼容 S3 协议的自建存储甚至服务端加密参数生产环境基本不用改代码只改配置。适合场景调用留痕、合规审计、离线分析。用 Prometheus 盯住每一次调用监控诉求更轻实例化 litellm/integrations/prometheus_services.py 中的PrometheusService然后把它放进litellm.callbacks所有 LLM 请求就会自动产出指标——请求量、延迟分布、错误率直接进 Grafana。这一步就是LiteLLM 集成 Prometheus的全部工作量通常五分钟以内。给敏感内容上一道安检门合规场景要用的是 litellm/integrations/custom_guardrail.py 里的CustomGuardrail。初始化时给它两个参数guardrail_name比如content-filter用于请求里引用和supported_event_hooks声明它挂在哪些节点如pre_call、post_call。挂上之后带敏感内容的请求会在到达模型之前被拦截并返回明确错误而不是回答完再擦屁股。上面是 Proxy 面板里的审计日志视图配合安全钩子使用谁改了什么、哪些请求被拦下全程可查。从零开发一个自定义插件Token 统计器内置的不够用自定义插件开发就三步继承基础类 → 定义钩子 → 注册回调。下面这个 Token 统计器完整可跑跟着做一遍就懂了from litellm.integrations.custom_logger import CustomLogger import time # 第 1 步继承 CustomLogger 基类 class TokenCounterLogger(CustomLogger): def __init__(self): self.token_stats { total_tokens: 0, request_count: 0 } # 第 2 步实现你关心的钩子这里是成功事件 def log_success_event(self, kwargs, response_obj, start_time, end_time): if hasattr(response_obj, usage): self.token_stats[total_tokens] response_obj.usage.total_tokens self.token_stats[request_count] 1 print(f累计请求: {self.token_stats[request_count]}, 累计Token: {self.token_stats[total_tokens]}) # 第 3 步实例化并通过 callbacks 注册 counter TokenCounterLogger() response litellm.completion( modelgpt-3.5-turbo, messages[{role: user, content: Hello World}], callbacks[counter] )三步拆开看继承CustomLogger拿到标准插槽重写log_success_event把自己的逻辑填进调用成功这个事件里钩子的参数里就有完整的请求上下文和响应对象想取什么取什么最后callbacks[counter]一行完成注册。这就是 LiteLLM 插件开发的完整闭环换个钩子方法比如改监听log_failure_event就能做别的统计。踩坑清单与调优建议这几个坑我帮你趟过了照着检查一遍能省不少事⚡ 耗时操作请走异步钩子在主链路上你要是同步去写慢存储整个请求都会被拖住。耗时逻辑统一放到async_log_success_event这类异步方法里处理。 别一条一条传攒着发高 QPS 下逐条上传会把带宽和连接数打爆。参考 litellm/integrations/s3_v2.py 的做法——先进内存队列达到批量大小或到达刷新间隔再一次性 flush 上传吞吐直接上一个台阶。 用缓存减少重复计算比如 prompt 相关开销可以借助 litellm/router_utils/prompt_caching_cache.py 的缓存策略让重复请求不再重复付费。⚔️ 多个插件抢同一个钩子插件可以并行挂在同一事件上但执行顺序会影响结果。挂多个时留意优先级设置把拦截类插件放在记录类插件前面心里才踏实。 插件自己也会吃资源监控/日志插件是寄生在主请求链路上的自身开销要盯着看别让它从观察者变成瓶颈。 版本兼容要留心核心版本迭代较快升级 LiteLLM 时记得核对插件接口有没有变动贡献规范见 CONTRIBUTING.md。写在最后现在 litellm/integrations/ 目录里已经有 20 多种主流服务集成从 AWS 到 Datadog、Slack 基本都有现成轮子未来插件系统还会开放更多生命周期钩子社区也在往成本监控、多模态处理这些场景上加料。如果你按上面的步骤写出了自己觉得好用的插件欢迎通过 CONTRIBUTING.md 提个 PR让它被更多人用到 。对了先收藏一下——下期预告《LiteLLM 插件市场使用指南》教你把散落各处的集成配置统一管理。【免费下载链接】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），仅供参考