LLM API 異常處理 3 步快速排查法free-llm-api-resources 錯誤處理從 429 到 503 一次講清【免費下載鏈接】free-llm-api-resourcesA list of free LLM inference resources accessible via API.項目地址: https://gitcode.com/GitHub_Trending/fre/free-llm-api-resources你照著列表里的某個免費端點發了句 Hi彈回 429。free-llm-api-resources 錯誤處理、LLM API 異常處理從哪下手429 限流怎么解、API 錯誤碼速查看什么咱們就從這條報錯聊起。 先搞清楚——這個錯到底是誰的鍋報錯上來先別慌。剛上手 LLM API 調用的人最容易犯的錯是拿到一個 4xx 就猛改 prompt。其實十秒鐘判清鍋在哪一層比盯著 traceback 干瞪眼強得多鍋在哪一層現場表現10 秒判據對面還沒收到你的請求DNS 解析失敗、連接超時、連接被重置換個端點也連不上多半是網絡的事請求到了回話讀不懂JSONDecodeError響應是 HTML 頁或半截內容先看 Content-Type 是不是 application/json門沒讓你進401 未授權、403 禁止訪問key 失效、沒開通該模型都是它對方忙不過來429 限流、503 服務不可用隔一會兒能通或公告里有故障這張表就是你要的 API 錯誤碼速查入口版先認現場再對號入座。土辦法是拿 curl -v 復現一次——卡在建連是網絡層收到響應但解析炸是格式層彈 401/403 是權限層。層沒判對后面的藥就下錯了。 對癥下藥——每類錯誤的修復動作退著試三次別手動重發免費端點負載高網絡層抽風是常態手動重發既累又沒節奏還容易順手把配額刷沒。import time, requests def call(url, payload): for wait in (1, 2, 4): try: return requests.post(url, jsonpayload, timeout10) except requests.exceptions.RequestException: time.sleep(wait)坑位提醒重試只認網絡層錯誤響應正常返回的 4xx重試一萬遍也不會變。先驗 Content-Type再解 JSON有些服務掛了會直接回一個 HTML 錯誤頁上來就 r.json() 必炸。響應頭里其實早寫明了真相只是沒人告訴你該看哪。r requests.get(url, timeout10) ctype r.headers.get(Content-Type, ) if application/json not in ctype: raise ValueError(f拿到的是 {ctype}不是 JSON) data r.json()坑位提醒流式響應的 Content-Type 是 text/event-stream別拿 JSON 規則去卡它。429 限流怎么解讀 Retry-After單獨排隊429 不是拒絕你是讓你等而且通常還告訴你等多久。免費檔配額大多按天計今天刷爆睡一覺基本回血。r requests.post(url, jsonpayload, timeout10) if r.status_code 429: wait int(r.headers.get(Retry-After, 5)) time.sleep(wait) r requests.post(url, jsonpayload, timeout10)坑位提醒Retry-After 缺省時按 5 秒起步別用死循環去刷免費配額。先等后換503 和 5xx 別硬剛5xx 是對面自己先趴了服務恢復快慢不受你控制硬重試只會雪上加霜。if 500 r.status_code 600: time.sleep(10) r requests.post(url, jsonpayload, timeout10)坑位提醒503 連著出現直接切備用端點別在一個坑里戀戰。401 和 403 別混著處理401 是我不認識你403 是認識你但不給這個資源。兩個碼都指向身份與授權排查順序一致先 key后模型。if r.status_code 401: print(key 沒認查環境變量、大小寫、多余空格) elif r.status_code 403: print(key 認了但沒權限換模型或去控制臺開通)坑位提醒key 從 .env 讀出來常帶換行符先 strip() 再懷疑別的。LLM API 重試策略一句話帶過網絡抖動 1s/2s/4s 退避429 單獨排隊讀 Retry-After其余 4xx 直接認。這套節奏幾行 if 就能落地真上量了再考慮 tenacity 這類重試庫。回到項目里看一眼——free-llm-api-resources 怎么兜底的項目拉取各家模型清單時兜底套路如出一轍。src/pull_available_models.py 里的抓取函數基本是這個骨架try: r requests.get(url, timeout10) r.raise_for_status() except requests.exceptions.RequestException as e: logger.error(f拉取失敗: {e}) # JSON 解析分支同理 return []請求掛了、解析炸了各走一個 except都是記日志加返回空列表不拖垮整份清單。src/data.py 里的 HYPERBOLIC_IGNORED_MODELS 也把已知坑位提前標了出來——照著做你自家的黑名單就行。? 給自己裝一層防彈衣排查是救火下面三樣是防火日志帶上時間戳、狀態碼、模型名、參數摘要按狀態碼分流4xx 認、429 排、5xx 退避所有請求設超時再備一個備用端點三句話排查清單卡住的時候按順序走三句話基本能定位看錯誤類型定下是哪一層的鍋驗 key 有效性檢查請求參數查該模型的狀態頁或服務公告三步走完還沒定位說明鍋在對方那邊切端點比繼續調參有用。還想再深一層項目看完自己寫調用代碼時這三個方向值得提前想把日志接到告警通道429 一出現就推送別等用戶先發現。翻翻 src/data.py 里的 LAMBDA_IGNORED_MODELS哪些模型該進黑名單項目替你踩過坑了。給每次調用帶一個 request id串起整條請求鏈路排查不再靠猜。報錯這事見多了就不慌了——下一個免費端點等你去試。【免費下載鏈接】free-llm-api-resourcesA list of free LLM inference resources accessible via API.項目地址: https://gitcode.com/GitHub_Trending/fre/free-llm-api-resources創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 LLM API 異常處理 3 步快速排查法：free-llm-api-resources 錯誤處理從 429 到 503 一次講清
LLM API 異常處理 3 步快速排查法free-llm-api-resources 錯誤處理從 429 到 503 一次講清【免費下載鏈接】free-llm-api-resourcesA list of free LLM inference resources accessible via API.項目地址: https://gitcode.com/GitHub_Trending/fre/free-llm-api-resources你照著列表里的某個免費端點發了句 Hi彈回 429。free-llm-api-resources 錯誤處理、LLM API 異常處理從哪下手429 限流怎么解、API 錯誤碼速查看什么咱們就從這條報錯聊起。 先搞清楚——這個錯到底是誰的鍋報錯上來先別慌。剛上手 LLM API 調用的人最容易犯的錯是拿到一個 4xx 就猛改 prompt。其實十秒鐘判清鍋在哪一層比盯著 traceback 干瞪眼強得多鍋在哪一層現場表現10 秒判據對面還沒收到你的請求DNS 解析失敗、連接超時、連接被重置換個端點也連不上多半是網絡的事請求到了回話讀不懂JSONDecodeError響應是 HTML 頁或半截內容先看 Content-Type 是不是 application/json門沒讓你進401 未授權、403 禁止訪問key 失效、沒開通該模型都是它對方忙不過來429 限流、503 服務不可用隔一會兒能通或公告里有故障這張表就是你要的 API 錯誤碼速查入口版先認現場再對號入座。土辦法是拿 curl -v 復現一次——卡在建連是網絡層收到響應但解析炸是格式層彈 401/403 是權限層。層沒判對后面的藥就下錯了。 對癥下藥——每類錯誤的修復動作退著試三次別手動重發免費端點負載高網絡層抽風是常態手動重發既累又沒節奏還容易順手把配額刷沒。import time, requests def call(url, payload): for wait in (1, 2, 4): try: return requests.post(url, jsonpayload, timeout10) except requests.exceptions.RequestException: time.sleep(wait)坑位提醒重試只認網絡層錯誤響應正常返回的 4xx重試一萬遍也不會變。先驗 Content-Type再解 JSON有些服務掛了會直接回一個 HTML 錯誤頁上來就 r.json() 必炸。響應頭里其實早寫明了真相只是沒人告訴你該看哪。r requests.get(url, timeout10) ctype r.headers.get(Content-Type, ) if application/json not in ctype: raise ValueError(f拿到的是 {ctype}不是 JSON) data r.json()坑位提醒流式響應的 Content-Type 是 text/event-stream別拿 JSON 規則去卡它。429 限流怎么解讀 Retry-After單獨排隊429 不是拒絕你是讓你等而且通常還告訴你等多久。免費檔配額大多按天計今天刷爆睡一覺基本回血。r requests.post(url, jsonpayload, timeout10) if r.status_code 429: wait int(r.headers.get(Retry-After, 5)) time.sleep(wait) r requests.post(url, jsonpayload, timeout10)坑位提醒Retry-After 缺省時按 5 秒起步別用死循環去刷免費配額。先等后換503 和 5xx 別硬剛5xx 是對面自己先趴了服務恢復快慢不受你控制硬重試只會雪上加霜。if 500 r.status_code 600: time.sleep(10) r requests.post(url, jsonpayload, timeout10)坑位提醒503 連著出現直接切備用端點別在一個坑里戀戰。401 和 403 別混著處理401 是我不認識你403 是認識你但不給這個資源。兩個碼都指向身份與授權排查順序一致先 key后模型。if r.status_code 401: print(key 沒認查環境變量、大小寫、多余空格) elif r.status_code 403: print(key 認了但沒權限換模型或去控制臺開通)坑位提醒key 從 .env 讀出來常帶換行符先 strip() 再懷疑別的。LLM API 重試策略一句話帶過網絡抖動 1s/2s/4s 退避429 單獨排隊讀 Retry-After其余 4xx 直接認。這套節奏幾行 if 就能落地真上量了再考慮 tenacity 這類重試庫。回到項目里看一眼——free-llm-api-resources 怎么兜底的項目拉取各家模型清單時兜底套路如出一轍。src/pull_available_models.py 里的抓取函數基本是這個骨架try: r requests.get(url, timeout10) r.raise_for_status() except requests.exceptions.RequestException as e: logger.error(f拉取失敗: {e}) # JSON 解析分支同理 return []請求掛了、解析炸了各走一個 except都是記日志加返回空列表不拖垮整份清單。src/data.py 里的 HYPERBOLIC_IGNORED_MODELS 也把已知坑位提前標了出來——照著做你自家的黑名單就行。? 給自己裝一層防彈衣排查是救火下面三樣是防火日志帶上時間戳、狀態碼、模型名、參數摘要按狀態碼分流4xx 認、429 排、5xx 退避所有請求設超時再備一個備用端點三句話排查清單卡住的時候按順序走三句話基本能定位看錯誤類型定下是哪一層的鍋驗 key 有效性檢查請求參數查該模型的狀態頁或服務公告三步走完還沒定位說明鍋在對方那邊切端點比繼續調參有用。還想再深一層項目看完自己寫調用代碼時這三個方向值得提前想把日志接到告警通道429 一出現就推送別等用戶先發現。翻翻 src/data.py 里的 LAMBDA_IGNORED_MODELS哪些模型該進黑名單項目替你踩過坑了。給每次調用帶一個 request id串起整條請求鏈路排查不再靠猜。報錯這事見多了就不慌了——下一個免費端點等你去試。【免費下載鏈接】free-llm-api-resourcesA list of free LLM inference resources accessible via API.項目地址: https://gitcode.com/GitHub_Trending/fre/free-llm-api-resources創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考