尧图网站建设 
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你给业务接了 OpenAI、Anthropic、Bedrock 等七八家模型厂商。出问题时很难快速判断是自家代码还是厂商的锅财务还要按团队拆成本。这正是 litellm回调 机制要解决的问题它在每次模型调用之后提供统一入口让你集中完成日志、成本与告警而不必在每个调用点写审计逻辑。它到底解决什么问题回调是一种通知钩子litellm 每次执行模型调用时会在几个关键节点主动调用你预先注册的函数。你不需要改业务代码只需要接收事件然后做你想做的事。它的价值集中在三处统一日志与成本不管调的是 OpenAI、Bedrock 还是本地 vLLM日志字段一致不用为每家厂商单独解析。故障前先告警调用失败或超时的那一刻就能推送到 Slack而不是等用户来报障。即插即用的可观测性Datadog、Langfuse 这类平台填一行配置即可接入不用写代码。litellm 回调系统核心钩子速览基类是 CustomLogger。它本身很薄每个空方法就是一个可覆写的钩子。常用的如下表钩子触发时机log_pre_api_call请求发出前可检查并记录参数log_post_api_call响应返回后拿到完整请求与响应log_stream_event流式响应的每个分块持续触发log_success_event调用成功含模型、tokens、成本、耗时log_failure_event调用失败含异常信息async_log_audit_log_event审计日志写入时触发有两个点值得注意。第一每个钩子都有同名 async_ 版本。在 proxy 的高并发场景下走异步路径更常见因为日志上报在后台执行不阻塞主调用流程。第二每个事件都携带一个标准化的日志对象。调用了哪个模型、谁调用user、team、花了多少 tokens、成本几何、耗时多少字段都齐了直接从对象取用即可。proxy 自带面板里还有 Audit Logs 页面。回调数据落库后谁改了什么可以直接查询三步跑通最小 litellm 回调第一步继承 CustomLogger只实现你关心的钩子其余方法保持原样。第二步实例化后放进 completion 的 callbacks 参数。该参数接收列表可以一次注册多个回调。下面的例子会为每次成功调用打印模型名from litellm import completion from litellm.integrations.custom_logger import CustomLogger class CostLogger(CustomLogger): async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): print(fmodel{kwargs.get(model)} success, cost recorded) completion( modelgpt-4o-mini, messages[{role: user, content: hello}], callbacks[CostLogger()], )SDK 模式到这里就完成了。第三步如果是 proxy 模式一行代码都不用写。在 proxy_server_config.yaml 里声明回调名即可。仓库自带的 proxy_server_config.yaml 里就是这样的写法litellm_settings: success_callback: [prometheus] failure_callback: [prometheus]可用的回调名可以在 callback_configs.json 中核对。datadog、datadog_metrics、langfuse、langfuse_otel 都已预置每个条目还声明了需要填的环境变量。proxy 还支持更细的粒度配置里的 default_team_settings 可以为每个团队单独指定回调让不同团队的数据进不同的观测项目。进阶技巧与调优批量上报什么时候该用 CustomBatchLogger调用量上来后一条条上报是性能瓶颈网络抖一下还会丢数据。改成继承 CustomBatchLogger框架会把事件排队后批量发送。内置的 Datadog 日志与 Slack 告警都采用这种模式。四种常用集成怎么选 按需接入不要全接。四种常见集成的差异比想象中大集成核心功能适用场景配置复杂度SlackAlerting失败、预算超限、慢响应告警运维即时响应低datadog_metrics延迟、成本、错误率指标持续监控与趋势分析中langfuse完整 trace逐次回放调试模型行为低prometheus拉取式指标端点已有 Prometheus 技术栈低SlackAlerting 开箱程度最高配好 webhook 后预算超限、响应过慢、模型故障outage告警乃至定期花费报表都有现成实现。Datadog 指标侧重延迟、成本、错误率这些数字适合长期趋势观察。Langfuse 走得更深把每次调用做成可回放的 trace最适合排查这次模型为什么答错。以 langfuse 为例配好之后每次调用的输入输出、延迟与成本都能在 trace 页面看到日志体积怎么控制回调上线后最常见的抱怨是日志涨得太快。构造 CustomLogger 时传 turn_off_message_loggingTrue可以关掉消息全文记录只保留指标字段。对不想把用户输入落到磁盘的合规场景这个参数特别有用。踩过的坑与排查回调的问题大多集中在数据没到。动手改代码前先对照下表大部分情况靠现象就能定位现象原因解法回调不触发只实现了同步 log_ 钩子而实际事件走异步路径补上对应的 async_ 钩子流式场景没有日志只实现了 success/failure 钩子流式事件走 log_stream_event需单独实现日志文件暴涨消息全文都写进了日志turn_off_message_loggingTrue只留指标字段指标时有时无数据还在批量队列里尚未发出确认继承自 CustomBatchLogger并检查批量发送周期继续深入回调开发的完整说明litellm/integrations/Readme.mdLangfuse、Arize 的真实接入示例cookbook/logging_observability/批量上报实现源码custom_batch_logger.py回调数据就位后下一步自然是把它和预算管理、限流规则结合起来让看得到变成能自动响应。如果你正在规划多厂商网关回调配置值得放在设计的第一步而不是事后补上。【免费下载链接】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 回调实战：给多模型调用统一加日志与监控
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你给业务接了 OpenAI、Anthropic、Bedrock 等七八家模型厂商。出问题时很难快速判断是自家代码还是厂商的锅财务还要按团队拆成本。这正是 litellm回调 机制要解决的问题它在每次模型调用之后提供统一入口让你集中完成日志、成本与告警而不必在每个调用点写审计逻辑。它到底解决什么问题回调是一种通知钩子litellm 每次执行模型调用时会在几个关键节点主动调用你预先注册的函数。你不需要改业务代码只需要接收事件然后做你想做的事。它的价值集中在三处统一日志与成本不管调的是 OpenAI、Bedrock 还是本地 vLLM日志字段一致不用为每家厂商单独解析。故障前先告警调用失败或超时的那一刻就能推送到 Slack而不是等用户来报障。即插即用的可观测性Datadog、Langfuse 这类平台填一行配置即可接入不用写代码。litellm 回调系统核心钩子速览基类是 CustomLogger。它本身很薄每个空方法就是一个可覆写的钩子。常用的如下表钩子触发时机log_pre_api_call请求发出前可检查并记录参数log_post_api_call响应返回后拿到完整请求与响应log_stream_event流式响应的每个分块持续触发log_success_event调用成功含模型、tokens、成本、耗时log_failure_event调用失败含异常信息async_log_audit_log_event审计日志写入时触发有两个点值得注意。第一每个钩子都有同名 async_ 版本。在 proxy 的高并发场景下走异步路径更常见因为日志上报在后台执行不阻塞主调用流程。第二每个事件都携带一个标准化的日志对象。调用了哪个模型、谁调用user、team、花了多少 tokens、成本几何、耗时多少字段都齐了直接从对象取用即可。proxy 自带面板里还有 Audit Logs 页面。回调数据落库后谁改了什么可以直接查询三步跑通最小 litellm 回调第一步继承 CustomLogger只实现你关心的钩子其余方法保持原样。第二步实例化后放进 completion 的 callbacks 参数。该参数接收列表可以一次注册多个回调。下面的例子会为每次成功调用打印模型名from litellm import completion from litellm.integrations.custom_logger import CustomLogger class CostLogger(CustomLogger): async def async_log_success_event(self, kwargs, response_obj, start_time, end_time): print(fmodel{kwargs.get(model)} success, cost recorded) completion( modelgpt-4o-mini, messages[{role: user, content: hello}], callbacks[CostLogger()], )SDK 模式到这里就完成了。第三步如果是 proxy 模式一行代码都不用写。在 proxy_server_config.yaml 里声明回调名即可。仓库自带的 proxy_server_config.yaml 里就是这样的写法litellm_settings: success_callback: [prometheus] failure_callback: [prometheus]可用的回调名可以在 callback_configs.json 中核对。datadog、datadog_metrics、langfuse、langfuse_otel 都已预置每个条目还声明了需要填的环境变量。proxy 还支持更细的粒度配置里的 default_team_settings 可以为每个团队单独指定回调让不同团队的数据进不同的观测项目。进阶技巧与调优批量上报什么时候该用 CustomBatchLogger调用量上来后一条条上报是性能瓶颈网络抖一下还会丢数据。改成继承 CustomBatchLogger框架会把事件排队后批量发送。内置的 Datadog 日志与 Slack 告警都采用这种模式。四种常用集成怎么选 按需接入不要全接。四种常见集成的差异比想象中大集成核心功能适用场景配置复杂度SlackAlerting失败、预算超限、慢响应告警运维即时响应低datadog_metrics延迟、成本、错误率指标持续监控与趋势分析中langfuse完整 trace逐次回放调试模型行为低prometheus拉取式指标端点已有 Prometheus 技术栈低SlackAlerting 开箱程度最高配好 webhook 后预算超限、响应过慢、模型故障outage告警乃至定期花费报表都有现成实现。Datadog 指标侧重延迟、成本、错误率这些数字适合长期趋势观察。Langfuse 走得更深把每次调用做成可回放的 trace最适合排查这次模型为什么答错。以 langfuse 为例配好之后每次调用的输入输出、延迟与成本都能在 trace 页面看到日志体积怎么控制回调上线后最常见的抱怨是日志涨得太快。构造 CustomLogger 时传 turn_off_message_loggingTrue可以关掉消息全文记录只保留指标字段。对不想把用户输入落到磁盘的合规场景这个参数特别有用。踩过的坑与排查回调的问题大多集中在数据没到。动手改代码前先对照下表大部分情况靠现象就能定位现象原因解法回调不触发只实现了同步 log_ 钩子而实际事件走异步路径补上对应的 async_ 钩子流式场景没有日志只实现了 success/failure 钩子流式事件走 log_stream_event需单独实现日志文件暴涨消息全文都写进了日志turn_off_message_loggingTrue只留指标字段指标时有时无数据还在批量队列里尚未发出确认继承自 CustomBatchLogger并检查批量发送周期继续深入回调开发的完整说明litellm/integrations/Readme.mdLangfuse、Arize 的真实接入示例cookbook/logging_observability/批量上报实现源码custom_batch_logger.py回调数据就位后下一步自然是把它和预算管理、限流规则结合起来让看得到变成能自动响应。如果你正在规划多厂商网关回调配置值得放在设计的第一步而不是事后补上。【免费下载链接】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），仅供参考