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/litellmlitellm 是一个用 OpenAI 格式统一调用 100 多家 LLM 的 AI 网关它的请求钩子机制让你能在调用被转发之前做拦截在响应返回之后做加工敏感信息扫描、违禁词过滤、审计留痕只需继承一个类改三个方法。一条 prompt 里的 API Key你敢直接发给模型吗想象这样一个场景你的团队把客服机器人接上了 litellm用户随口在 prompt 里贴了一串 Stripe 测试密钥这条内容原封不动转发给了云端模型密钥就此进入外部日志。类似的麻烦还有竞品相关术语不允许出现在回复里、某些内容需要合规审核、每条调用都要留下审计轨迹。如果靠在每个业务调用处手动写 if 判断十几条调用链下来很快就乱掉。请求钩子的价值就在于把这类逻辑集中到网关层所有请求统一经过同一道检查。三个钩子位置pre_call、success、streaminglitellm 的钩子机制围绕请求生命周期设了三个挂载点都定义在 litellm/integrations/custom_logger.py 的CustomLogger基类上async_pre_call_hook请求发给模型之前触发拿到本次调用的用户身份和请求参数此时拦截可以返回 400请求根本不会出网关async_post_call_success_hook非流式响应返回后触发拿到完整的模型响应对象async_post_call_streaming_hook流式场景下逐块触发处理每个 chunk。触发点在代理的请求分发处litellm/proxy/proxy_server.py 中可以看到await proxy_logging_obj.pre_call_hook(...)的调用即所有 /chat/completions 请求都会先过这一层。以仓库内置的违禁词钩子为例核心逻辑只有几行class _ENTERPRISE_BannedKeywords(CustomLogger): def test_violation(self, test_str: str): for word in self.banned_keywords_list: if word in test_str.lower(): raise HTTPException(status_code400, detail{error: fKeyword banned. Keyword{word}})它在 pre 阶段扫请求文本在 success 和 streaming 阶段扫响应文本命中即抛 400详见 enterprise/enterprise_hooks/banned_keywords.py。三步配置你自己的请求钩子克隆仓库浏览 litellm/proxy/example_config_yaml/ 下的示例配置。这里存放了大量litellm_settings的真实写法照着抄不会错。实现钩子类继承CustomLogger按需覆盖async_pre_call_hook等方法。为什么要用基类而不是写独立函数——只有注册进回调管理器的类才会被代理在请求链路上自动调用。在proxy_config.yaml的litellm_settings里注册你的钩子回调项支持类路径或模块.类名两种写法然后以litellm --config proxy_config.yaml启动。用一条会触发拦截规则的测试请求验证预期收到 400 而不是模型响应说明钩子已经生效。三个高频场景怎么用违禁词双向过滤面向 C 端的产品需要保证输入输出都干净。用banned_keywords_list配置词表后请求和响应会被同时检查——pre 阶段拦输入success/streaming 阶段拦输出命中关键词直接 400 并返回具体是哪个词。词表既可以是列表也可以是文件路径按行读取。敏感信息扫描用户可能在对话里带上云厂商密钥、JWT、私有仓库 token。enterprise/litellm_enterprise/enterprise_callbacks/secret_detection.py 内置了数十种检测器AWSKeyDetector、StripeDetector、JwtTokenDetector等在调用前把命中的内容替换或屏蔽密钥不再随 prompt 流向模型。审计追踪与可观测性合规要求每次调用可追溯时把钩子和日志回调一起注册即可每条请求的输入、输出、耗时、token 用量和成本都会落到日志。上图的 Langfuse 集成面板就是这类效果——完整的请求轨迹包含输入输出与成本估算排查问题不用翻后端日志。常见坑流式钩子漏配、词表未设置、目录混用流式响应为什么过滤没生效非流式响应走async_post_call_success_hook流式响应走的是async_post_call_streaming_hook两个钩子参数和触发时机完全不同。如果你的接口开了stream: true只写了 success 钩子就会整条漏过。启动报错banned_keywords_list ... None set怎么办违禁词钩子要求词表非空必须是列表或文件路径没配置时初始化直接抛异常。先配置词表再启用该钩子。enterprise 目录下的钩子能直接用吗enterprise/enterprise_hooks/ 和 enterprise/litellm_enterprise/enterprise_callbacks/ 属于企业版实现需要企业版权限。开源场景下自己继承CustomLogger写同等逻辑即可基类是开源的。litellm 的请求钩子把调用前拦截、调用后加工变成了标准能力安全、合规、审计需求都不必再侵入业务代码。克隆仓库git clone https://gitcode.com/GitHub_Trending/li/litellm开始使用配置写法参考 litellm/proxy/example_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/litellmlitellm 是一个用 OpenAI 格式统一调用 100 多家 LLM 的 AI 网关它的请求钩子机制让你能在调用被转发之前做拦截在响应返回之后做加工敏感信息扫描、违禁词过滤、审计留痕只需继承一个类改三个方法。一条 prompt 里的 API Key你敢直接发给模型吗想象这样一个场景你的团队把客服机器人接上了 litellm用户随口在 prompt 里贴了一串 Stripe 测试密钥这条内容原封不动转发给了云端模型密钥就此进入外部日志。类似的麻烦还有竞品相关术语不允许出现在回复里、某些内容需要合规审核、每条调用都要留下审计轨迹。如果靠在每个业务调用处手动写 if 判断十几条调用链下来很快就乱掉。请求钩子的价值就在于把这类逻辑集中到网关层所有请求统一经过同一道检查。三个钩子位置pre_call、success、streaminglitellm 的钩子机制围绕请求生命周期设了三个挂载点都定义在 litellm/integrations/custom_logger.py 的CustomLogger基类上async_pre_call_hook请求发给模型之前触发拿到本次调用的用户身份和请求参数此时拦截可以返回 400请求根本不会出网关async_post_call_success_hook非流式响应返回后触发拿到完整的模型响应对象async_post_call_streaming_hook流式场景下逐块触发处理每个 chunk。触发点在代理的请求分发处litellm/proxy/proxy_server.py 中可以看到await proxy_logging_obj.pre_call_hook(...)的调用即所有 /chat/completions 请求都会先过这一层。以仓库内置的违禁词钩子为例核心逻辑只有几行class _ENTERPRISE_BannedKeywords(CustomLogger): def test_violation(self, test_str: str): for word in self.banned_keywords_list: if word in test_str.lower(): raise HTTPException(status_code400, detail{error: fKeyword banned. Keyword{word}})它在 pre 阶段扫请求文本在 success 和 streaming 阶段扫响应文本命中即抛 400详见 enterprise/enterprise_hooks/banned_keywords.py。三步配置你自己的请求钩子克隆仓库浏览 litellm/proxy/example_config_yaml/ 下的示例配置。这里存放了大量litellm_settings的真实写法照着抄不会错。实现钩子类继承CustomLogger按需覆盖async_pre_call_hook等方法。为什么要用基类而不是写独立函数——只有注册进回调管理器的类才会被代理在请求链路上自动调用。在proxy_config.yaml的litellm_settings里注册你的钩子回调项支持类路径或模块.类名两种写法然后以litellm --config proxy_config.yaml启动。用一条会触发拦截规则的测试请求验证预期收到 400 而不是模型响应说明钩子已经生效。三个高频场景怎么用违禁词双向过滤面向 C 端的产品需要保证输入输出都干净。用banned_keywords_list配置词表后请求和响应会被同时检查——pre 阶段拦输入success/streaming 阶段拦输出命中关键词直接 400 并返回具体是哪个词。词表既可以是列表也可以是文件路径按行读取。敏感信息扫描用户可能在对话里带上云厂商密钥、JWT、私有仓库 token。enterprise/litellm_enterprise/enterprise_callbacks/secret_detection.py 内置了数十种检测器AWSKeyDetector、StripeDetector、JwtTokenDetector等在调用前把命中的内容替换或屏蔽密钥不再随 prompt 流向模型。审计追踪与可观测性合规要求每次调用可追溯时把钩子和日志回调一起注册即可每条请求的输入、输出、耗时、token 用量和成本都会落到日志。上图的 Langfuse 集成面板就是这类效果——完整的请求轨迹包含输入输出与成本估算排查问题不用翻后端日志。常见坑流式钩子漏配、词表未设置、目录混用流式响应为什么过滤没生效非流式响应走async_post_call_success_hook流式响应走的是async_post_call_streaming_hook两个钩子参数和触发时机完全不同。如果你的接口开了stream: true只写了 success 钩子就会整条漏过。启动报错banned_keywords_list ... None set怎么办违禁词钩子要求词表非空必须是列表或文件路径没配置时初始化直接抛异常。先配置词表再启用该钩子。enterprise 目录下的钩子能直接用吗enterprise/enterprise_hooks/ 和 enterprise/litellm_enterprise/enterprise_callbacks/ 属于企业版实现需要企业版权限。开源场景下自己继承CustomLogger写同等逻辑即可基类是开源的。litellm 的请求钩子把调用前拦截、调用后加工变成了标准能力安全、合规、审计需求都不必再侵入业务代码。克隆仓库git clone https://gitcode.com/GitHub_Trending/li/litellm开始使用配置写法参考 litellm/proxy/example_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），仅供参考