出前攔截，響應(yīng)返回后處理)
litellm 鉤子快速指南請求發(fā)出前攔截響應(yīng)返回后處理【免費下載鏈接】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先用一句話說清 litellm它是 LLM 世界里的網(wǎng)關(guān)用一套 OpenAI 格式就能調(diào)用 100 多家模型的 APIOpenAI、Claude、Bedrock、VertexAI 都在內(nèi)順帶把成本跟蹤、限流、負(fù)載均衡都包了。這篇文章聊的是它最實用的一個特性——鉤子hook。靠幾個鉤子你能在請求預(yù)處理和響應(yīng)后處理兩個階段各做點事業(yè)務(wù)代碼一行不用動。一次線上事故GitHub token 被原樣發(fā)給了模型我們做過一個聊天應(yīng)用用戶可以把倉庫鏈接貼進(jìn) prompt讓模型幫忙分析代碼。某天有人貼了個帶 token 的鏈接請求穿過網(wǎng)關(guān)直達(dá)模型token 進(jìn)了第三方日志事后只能緊急輪換密鑰。如果網(wǎng)關(guān)上有一個關(guān)卡這個請求在出門前就會被攔下。為什么網(wǎng)關(guān)是最后一道防線你的前端、后端都可能被繞過但流量最終都要從網(wǎng)關(guān)過。把安全檢查放在網(wǎng)關(guān)層等于給所有出口裝了同一道閘。鉤子的三個關(guān)卡大白話講鉤子就是掛在請求生命周期上的函數(shù)。litellm 在請求發(fā)往模型之前、響應(yīng)回來之后會依次調(diào)用你注冊好的函數(shù)函數(shù)里寫什么——攔截、改寫、打日志——全由你決定。翻倉庫能發(fā)現(xiàn)鉤子實現(xiàn)分布在幾處官方企業(yè)鉤子在 enterprise/enterprise_hooks/代理自帶的限流、預(yù)算類鉤子在 litellm/proxy/hooks/。記住兩個方法名就夠async_pre_call_hookpre-call 鉤子請求發(fā)出前執(zhí)行async_post_call_success_hook和async_post_call_streaming_hookpost-call 鉤子響應(yīng)成功返回后執(zhí)行流式場景下每個數(shù)據(jù)塊都會過一次。一個請求的完整生命周期就這兩個時間點能管住。請求發(fā)出前三個值得裝的 pre-call 鉤子先查身份這個人有沒有資格進(jìn)來block_user_list.py 是最簡單的例子。它的async_pre_call_hook從請求里取出user字段對照一份阻止列表命中就直接返回 400請求根本到不了模型。適合的場景某個濫用賬號被投訴了或者某客戶欠費了——把 id 加進(jìn)列表就行不用改代碼。把密鑰泄漏擋在出門之前密鑰檢測是另一類高頻需求大白話就是請求出門前先掃一遍文本里有沒有長得像 API key 的東西。secret_detection.py 里內(nèi)置了幾十種常見密鑰的正則OpenAI、GitHub、Slack 都有。前面那個 token 事故裝上它就當(dāng)場攔截。給濫用流量的用戶限個流共用一把 key 時一個用戶批量跑任務(wù)就能把額度吃光。這里解釋兩個概念TPM 是每分鐘 token 數(shù)RPM 是每分鐘請求數(shù)都是限流用的額度。litellm 現(xiàn)成的限速器不少parallel_request_limiter.py 管并發(fā)請求數(shù)max_iterations_limiter.py管 agent 調(diào)用的最大輪數(shù)。限流建議按用戶 / 團(tuán)隊粒度做別卡在整個實例上不然一個人的突發(fā)會拖慢所有人。響應(yīng)返回后post-call 鉤子負(fù)責(zé)收尾給響應(yīng)內(nèi)容掃一遍違禁詞banned_keywords.py 是教科書級實現(xiàn)。它查兩個位置async_post_call_success_hook在非流式調(diào)用里掃完整響應(yīng)async_post_call_streaming_hook在流式輸出里對每個到達(dá)的塊做檢查。命中違禁詞直接拋錯內(nèi)容到不了用戶眼前。前后鉤子配合著用pre-call 做輸入審post-call 做輸出審內(nèi)容安全就多了一層兜底。把全過程記進(jìn)追蹤鏈路響應(yīng)回來之后post-call 鉤子還順手做日志、埋點這類后處理。想把它可視化可以接 Langfuse 這類追蹤工具實現(xiàn)在 litellm/integrations/langfuse/。每個請求的輸入、輸出、耗時、token 用量、成本都能在一個界面里看全。線上模型行為不對的時候這種調(diào)試體驗非常省時間。三步寫出自己的鉤子寫一個實現(xiàn)鉤子方法的類繼承CustomLogger基類實現(xiàn)async_pre_call_hook或 post-call 方法。參數(shù)里你常用的就兩個data請求體和response響應(yīng)對象。想拒絕請求直接拋HTTPException。注冊進(jìn)配置重啟生效在代理配置 YAML 的callbacks字段里注冊你的鉤子類重啟服務(wù)即生效。如果只想觀察不想攔截就把它當(dāng)普通日志回調(diào)寫不拋異常即可。兩個容易踩的坑流式調(diào)用要單獨實現(xiàn)流式版本的 post-call 鉤子否則只查得到響應(yīng)開頭鉤子邏輯盡量快。它掛在主鏈路同步關(guān)卡上慢了用戶直接感知到延遲。按業(yè)務(wù)場景挑現(xiàn)成的鉤子內(nèi)容安全輸入輸出各裝一道pre-call 掛banned_keywords做輸入檢查prompt_injection_detection.py防提示注入post-call 用同一套詞表查輸出。enterprise/enterprise_hooks/ 目錄里還有 OpenAI、Google 的 moderation 鉤子開箱即用。成本控制給預(yù)算設(shè)個天花板max_budget_limiter.py 在 pre-call 階段給 key 或團(tuán)隊的花費設(shè)上限超了直接拒。再配model_max_budget_limiter.py按模型細(xì)分防止某個模型單價低但調(diào)用量失控。合規(guī)審計每次變更都留痕需要過合規(guī)審查時用 post-call 鉤子把請求和響應(yīng)落進(jìn)自己的存儲。代理自帶審計日志key 的創(chuàng)建、刪除、輪換這類管理操作都有記錄可查。想快速跑通一個 litellm 鉤子不用從零造輪子先git clone https://gitcode.com/GitHub_Trending/li/litellm再讀倉庫根目錄的 README.md 和 ARCHITECTURE.md從上面五個場景里挑你最有共鳴的一個今天就把第一個鉤子裝起來。【免費下載鏈接】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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 litellm 鉤子快速指南：請求發(fā)出前攔截，響應(yīng)返回后處理
litellm 鉤子快速指南請求發(fā)出前攔截響應(yīng)返回后處理【免費下載鏈接】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先用一句話說清 litellm它是 LLM 世界里的網(wǎng)關(guān)用一套 OpenAI 格式就能調(diào)用 100 多家模型的 APIOpenAI、Claude、Bedrock、VertexAI 都在內(nèi)順帶把成本跟蹤、限流、負(fù)載均衡都包了。這篇文章聊的是它最實用的一個特性——鉤子hook。靠幾個鉤子你能在請求預(yù)處理和響應(yīng)后處理兩個階段各做點事業(yè)務(wù)代碼一行不用動。一次線上事故GitHub token 被原樣發(fā)給了模型我們做過一個聊天應(yīng)用用戶可以把倉庫鏈接貼進(jìn) prompt讓模型幫忙分析代碼。某天有人貼了個帶 token 的鏈接請求穿過網(wǎng)關(guān)直達(dá)模型token 進(jìn)了第三方日志事后只能緊急輪換密鑰。如果網(wǎng)關(guān)上有一個關(guān)卡這個請求在出門前就會被攔下。為什么網(wǎng)關(guān)是最后一道防線你的前端、后端都可能被繞過但流量最終都要從網(wǎng)關(guān)過。把安全檢查放在網(wǎng)關(guān)層等于給所有出口裝了同一道閘。鉤子的三個關(guān)卡大白話講鉤子就是掛在請求生命周期上的函數(shù)。litellm 在請求發(fā)往模型之前、響應(yīng)回來之后會依次調(diào)用你注冊好的函數(shù)函數(shù)里寫什么——攔截、改寫、打日志——全由你決定。翻倉庫能發(fā)現(xiàn)鉤子實現(xiàn)分布在幾處官方企業(yè)鉤子在 enterprise/enterprise_hooks/代理自帶的限流、預(yù)算類鉤子在 litellm/proxy/hooks/。記住兩個方法名就夠async_pre_call_hookpre-call 鉤子請求發(fā)出前執(zhí)行async_post_call_success_hook和async_post_call_streaming_hookpost-call 鉤子響應(yīng)成功返回后執(zhí)行流式場景下每個數(shù)據(jù)塊都會過一次。一個請求的完整生命周期就這兩個時間點能管住。請求發(fā)出前三個值得裝的 pre-call 鉤子先查身份這個人有沒有資格進(jìn)來block_user_list.py 是最簡單的例子。它的async_pre_call_hook從請求里取出user字段對照一份阻止列表命中就直接返回 400請求根本到不了模型。適合的場景某個濫用賬號被投訴了或者某客戶欠費了——把 id 加進(jìn)列表就行不用改代碼。把密鑰泄漏擋在出門之前密鑰檢測是另一類高頻需求大白話就是請求出門前先掃一遍文本里有沒有長得像 API key 的東西。secret_detection.py 里內(nèi)置了幾十種常見密鑰的正則OpenAI、GitHub、Slack 都有。前面那個 token 事故裝上它就當(dāng)場攔截。給濫用流量的用戶限個流共用一把 key 時一個用戶批量跑任務(wù)就能把額度吃光。這里解釋兩個概念TPM 是每分鐘 token 數(shù)RPM 是每分鐘請求數(shù)都是限流用的額度。litellm 現(xiàn)成的限速器不少parallel_request_limiter.py 管并發(fā)請求數(shù)max_iterations_limiter.py管 agent 調(diào)用的最大輪數(shù)。限流建議按用戶 / 團(tuán)隊粒度做別卡在整個實例上不然一個人的突發(fā)會拖慢所有人。響應(yīng)返回后post-call 鉤子負(fù)責(zé)收尾給響應(yīng)內(nèi)容掃一遍違禁詞banned_keywords.py 是教科書級實現(xiàn)。它查兩個位置async_post_call_success_hook在非流式調(diào)用里掃完整響應(yīng)async_post_call_streaming_hook在流式輸出里對每個到達(dá)的塊做檢查。命中違禁詞直接拋錯內(nèi)容到不了用戶眼前。前后鉤子配合著用pre-call 做輸入審post-call 做輸出審內(nèi)容安全就多了一層兜底。把全過程記進(jìn)追蹤鏈路響應(yīng)回來之后post-call 鉤子還順手做日志、埋點這類后處理。想把它可視化可以接 Langfuse 這類追蹤工具實現(xiàn)在 litellm/integrations/langfuse/。每個請求的輸入、輸出、耗時、token 用量、成本都能在一個界面里看全。線上模型行為不對的時候這種調(diào)試體驗非常省時間。三步寫出自己的鉤子寫一個實現(xiàn)鉤子方法的類繼承CustomLogger基類實現(xiàn)async_pre_call_hook或 post-call 方法。參數(shù)里你常用的就兩個data請求體和response響應(yīng)對象。想拒絕請求直接拋HTTPException。注冊進(jìn)配置重啟生效在代理配置 YAML 的callbacks字段里注冊你的鉤子類重啟服務(wù)即生效。如果只想觀察不想攔截就把它當(dāng)普通日志回調(diào)寫不拋異常即可。兩個容易踩的坑流式調(diào)用要單獨實現(xiàn)流式版本的 post-call 鉤子否則只查得到響應(yīng)開頭鉤子邏輯盡量快。它掛在主鏈路同步關(guān)卡上慢了用戶直接感知到延遲。按業(yè)務(wù)場景挑現(xiàn)成的鉤子內(nèi)容安全輸入輸出各裝一道pre-call 掛banned_keywords做輸入檢查prompt_injection_detection.py防提示注入post-call 用同一套詞表查輸出。enterprise/enterprise_hooks/ 目錄里還有 OpenAI、Google 的 moderation 鉤子開箱即用。成本控制給預(yù)算設(shè)個天花板max_budget_limiter.py 在 pre-call 階段給 key 或團(tuán)隊的花費設(shè)上限超了直接拒。再配model_max_budget_limiter.py按模型細(xì)分防止某個模型單價低但調(diào)用量失控。合規(guī)審計每次變更都留痕需要過合規(guī)審查時用 post-call 鉤子把請求和響應(yīng)落進(jìn)自己的存儲。代理自帶審計日志key 的創(chuàng)建、刪除、輪換這類管理操作都有記錄可查。想快速跑通一個 litellm 鉤子不用從零造輪子先git clone https://gitcode.com/GitHub_Trending/li/litellm再讀倉庫根目錄的 README.md 和 ARCHITECTURE.md從上面五個場景里挑你最有共鳴的一個今天就把第一個鉤子裝起來。【免費下載鏈接】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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考