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