20장. 캐싱, 재시도, 폴백 전략

LLM 서비스는 잘 대답할 때보다 잘 실패할 때 진짜 실력이 드러난다. 평소에는 답변 품질이 좋아 보이는 모델 하나면 충분해 보인다. 그런데 트래픽이 몰리고, 공급자 지연 시간이 치솟고, 429와 503이 번갈아 튀기 시작하면 갑자기 질문이 바뀐다.

"이 모델이 똑똑한가?"가 아니라,

"이 서비스는 무너지지 않는가?"

이 장의 핵심도 바로 여기 있다. LLM 서비스의 안정성은 모델 성능보다 실패했을 때 어떻게 버티는지에서 갈린다. 버티는 방법은 화려하지 않다. 같은 요청을 다시 계산하지 않도록 캐싱하고, 다시 시도할 가치가 있는 실패만 짧게 재시도하고, 그래도 안 되면 다른 경로로 우회하는 것이다. 듣기에는 단순하지만, 이 세 가지를 제대로 설계한 팀과 그렇지 않은 팀의 운영 난이도는 완전히 달라진다.

실패는 예외가 아니라 운영의 기본값이다

기존 웹 서비스에서도 외부 API 장애는 흔하다. 하지만 LLM API는 실패 양상이 조금 더 까다롭다. 응답 시간이 길고, 공급자별 레이트 리밋 정책이 다르며, 같은 요청이라도 출력 형식이 흔들릴 수 있기 때문이다. 그래서 "실패하면 재시도" 같은 한 줄 규칙으로는 오래 버티기 어렵다.

먼저 실패를 세 종류로 나누는 습관이 필요하다.¹

이 분류가 왜 중요할까. 실패를 구분하지 않으면 모든 에러에 같은 정책이 적용된다. 그러면 재시도해도 절대 성공하지 않을 요청을 괜히 반복하게 되고, 반대로 잠깐 기다리면 될 요청까지 너무 빨리 포기하게 된다. 실무에서 장애를 키우는 가장 흔한 방식이 바로 이 "무차별 재시도"다.

캐싱: 가장 빠르고 가장 싼 호출은 아예 안 하는 호출이다

성능 최적화 이야기를 시작하면 많은 팀이 먼저 모델을 바꾸거나 프롬프트를 줄이려 한다. 물론 그것도 중요하다. 하지만 더 직접적인 방법이 있다.

같은 답을 또 물어보지 않는 것이다.

반복되는 요청이 많은 서비스에서는 캐싱이 가장 강력한 안정화 수단이다. 호출이 줄어들면 비용이 줄고, 지연 시간이 줄고, 공급자 장애 영향을 받는 요청 수도 함께 줄어든다. 말 그대로 가장 좋은 API 호출은 하지 않은 호출이다.²

캐싱은 크게 세 층으로 나눠 생각하면 편하다.

첫째는 응답 캐시다. 입력과 조건이 같으면 이전 결과를 그대로 돌려준다. FAQ 답변, 제목 생성, 짧은 요약, 분류처럼 비교적 결정적인 작업에 잘 맞는다.

둘째는 프롬프트 캐시다. 시스템 프롬프트, 공통 지시문, 긴 컨텍스트 블록처럼 여러 요청에서 반복되는 입력 조각을 재사용하는 방식이다. 사용자 눈에는 잘 안 보이지만, 비용 절감 효과가 꽤 크다.

셋째는 의미 기반 캐시다. 문장이 완전히 같지 않아도 사실상 같은 질문이면 같은 답을 재사용하는 방식이다. 예를 들어 "환불 정책 알려줘"와 "환불 규정이 어떻게 돼?"가 같은 문서 집합과 같은 정책 버전을 가리킨다면 의미 캐시 후보가 될 수 있다.

여기서 중요한 함정이 하나 있다. 캐시는 적중률만 높으면 좋은 것이 아니다. 안전하게 맞아야 한다. 그래서 실무에서는 단순 적중률보다 "안전한 적중률"을 봐야 한다는 이야기가 나온다.³

예를 들어 이런 캐시 키는 위험하다.

key = hash(user_input)

겉보기엔 단순하고 예쁘지만, 실제 서비스에서는 빠르게 사고로 이어진다. 같은 질문이라도 다음 조건이 다르면 답이 달라질 수 있기 때문이다.

• 프롬프트 템플릿 버전

• 사용자 권한과 테넌트

• 참조한 문서 버전이나 데이터 스냅샷

• 응답 언어와 형식

• 모델 별칭 또는 출력 계약 버전

그래서 실전 캐시 키는 보통 이런 식으로 더 길어진다.

key = hash(
  task_type +
  normalized_input +
  prompt_template_version +
  tenant_id +
  permission_scope +
  context_snapshot_version +
  response_schema_version +
  locale
)

조금 투박해 보여도 이 편이 안전하다. 캐시는 빠름의 기술이면서 동시에 오답 전파를 막는 기술이기도 하다.

무엇을 캐시하고, 무엇을 캐시하지 말아야 할까

모든 LLM 응답을 캐시하는 것은 좋지 않다. 캐싱은 "반복 가능성"과 "재사용 안전성"이 높은 작업부터 시작해야 한다.

잘 맞는 경우는 이런 작업이다.

• FAQ 응답

• 분류와 태깅

• 제목 생성

• 고정 문서 집합에 대한 요약

• 변환 규칙이 명확한 재작성

반대로 주의가 필요한 경우도 있다.

• 개인 정보가 섞인 대화 응답

• 권한별로 답이 달라지는 내부 검색 결과

• 실시간 데이터에 강하게 의존하는 답변

• 스트리밍 중간 조각

• 고신뢰 판단이 필요한 생성 결과

특히 스트리밍 응답은 끝까지 정상 완료된 뒤에만 캐시에 넣는 편이 안전하다. 도중에 연결이 끊긴 조각을 캐싱하면 다음 사용자에게 반쯤 끊긴 문장을 자신 있게 돌려주는 코미디가 벌어진다.

TTL과 무효화는 품질 정책이다

캐시 TTL(Time To Live)은 단순한 성능 파라미터가 아니다. 제품 품질 정책에 가깝다.

환불 정책처럼 자주 바뀌지 않는 정보는 긴 TTL이 가능하다. 반면 가격, 재고, 최신 공지, 실시간 리서치처럼 바뀌기 쉬운 정보는 TTL을 짧게 잡거나 아예 캐싱하지 않는 편이 낫다.

RAG 계열 기능에서는 더 조심해야 한다. 같은 질문이어도 지식 베이스가 업데이트되면 답이 달라져야 한다. 이때는 질문만 캐시 키에 넣으면 안 되고, 검색 인덱스 버전이나 문서 스냅샷 버전을 함께 넣어야 한다.

캐시는 "어제의 정답"을 "오늘의 오답"으로 바꿀 수 있다. 그래서 TTL은 메모리 절약 설정이 아니라 서비스 신선도 설정이라고 생각하는 편이 좋다.

재시도: 많이 하는 것이 아니라 잘하는 것이다

재시도는 외부 API와 함께 사는 서비스의 기본 체력이다. 하지만 재시도는 잘못 넣으면 치료제가 아니라 독이 된다. 공급자가 이미 힘들어하는데 똑같은 요청을 같은 타이밍에 다시 몰아넣으면, 장애는 더 커지고 우리 큐도 같이 흔들린다.

그래서 재시도의 원칙은 간단하다.

짧게, 선택적으로, 간격을 두고 다시 시도한다.

공급자가 Retry-After 헤더를 준다면 그 값을 우선 존중해야 하고, 그렇지 않다면 지수 백오프를 쓰는 편이 좋다.⁴ 예를 들어 1초, 2초, 4초처럼 기다리는 시간이 점점 늘어나는 방식이다. 여기에 약간의 무작위 시간, 즉 jitter를 더하면 여러 서버가 같은 순간에 한꺼번에 다시 요청하는 문제를 줄일 수 있다.⁵

간단한 규칙은 이렇다.

delay = min(base * 2^attempt, max_delay)
wait = random(0, delay)

숫자만 보면 별것 아닌데, 이 작은 랜덤성이 장애 상황에서 꽤 큰 차이를 만든다. 모두가 4초 뒤 정확히 다시 달려드는 것과, 0초에서 4초 사이에 흩어져 들어가는 것은 공급자 입장에서 완전히 다른 풍경이다.

재시도는 한 레이어에서만 하라

실무에서 정말 자주 보는 사고가 있다. HTTP 클라이언트가 한 번 재시도하고, 서비스 레이어가 또 재시도하고, 작업 큐 소비자가 다시 재처리하고, 프론트엔드가 사용자 클릭으로 한 번 더 보낸다.

이 구조에서는 원래 요청 1건이 장애 순간 8건, 12건, 20건으로 불어난다. LLM API는 토큰 비용이 붙기 때문에, 이 중복 증폭은 단순한 트래픽 문제가 아니라 비용 폭증 문제이기도 하다.

그래서 원칙은 명확하다. 재시도는 한 계층에서만 책임진다.

대화형 API라면 애플리케이션 서비스 계층에서 짧게 1~2회만 재시도하고 끝내는 편이 좋다. 반대로 야간 배치 작업이라면 큐 워커 계층에서 더 긴 재시도를 맡길 수 있다. 둘 다 하는 것은 보통 과하다.

무엇을 재시도하고, 무엇을 포기할까

재시도하기 좋은 오류는 대체로 예측 가능하다.

• 429 Too Many Requests

• 408 Request Timeout

• 500, 502, 503, 504

• 네트워크 일시 단절

• 공급자 과부하 계열 오류

반면 이런 오류는 보통 바로 실패시키는 편이 맞다.

• 400 잘못된 요청 형식

• 401, 403 인증·권한 오류

• 존재하지 않는 모델 ID

• 필수 파라미터 누락

• 같은 입력으로 반복될 콘텐츠 필터 거부

다만 예외도 있다. 예를 들어 컨텍스트 길이 초과는 400 계열일 수 있지만, 입력을 줄이면 성공할 수 있다. 이런 경우는 "같은 요청 재시도"가 아니라 입력 축소 후 재실행으로 보는 편이 더 정확하다.

타임아웃 예산을 먼저 정하라

재시도는 무료가 아니다. 시간이 든다. 따라서 사용자가 기다릴 수 있는 총 시간, 즉 타임아웃 예산 안에서만 돌아야 한다.

예를 들어 채팅 UI의 P95 목표가 8초라면, 공급자 1회 호출에 30초 타임아웃을 걸고 재시도 3번 하는 설계는 처음부터 성립하지 않는다. 이 경우에는 첫 시도 3초, 재시도 1회 2초, 남은 시간에 폴백 2초 같은 식으로 예산을 나누는 편이 더 현실적이다.

좋은 재시도 정책은 "최대한 많이 해보는 정책"이 아니라 제품의 시간 제한 안에서 성공 확률을 높이는 정책이다.

서킷 브레이커와 쿨다운: 아픈 공급자를 계속 찌르지 마라

공급자가 10분째 불안정한데도 모든 요청이 항상 그 공급자를 1순위로 두고 시작한다면 무슨 일이 벌어질까. 매 요청마다 타임아웃을 맞고, 매 요청마다 재시도를 하고, 매 요청마다 폴백까지 타게 된다. 사용자는 느리고, 우리 시스템은 지치고, 비용은 올라간다.

이때 필요한 것이 서킷 브레이커다. 이름은 거창하지만 아이디어는 단순하다. 일정 시간 동안 특정 공급자나 특정 모델의 실패가 너무 많으면, 잠깐 그 경로를 닫아 버리는 것이다. 그러고 나서 조금 뒤에 아주 소량만 다시 흘려 보내 회복 여부를 확인한다.

상태는 보통 세 가지로 생각하면 쉽다.

• Closed: 평소 상태, 정상 호출

• Open: 실패가 너무 많아 일시 차단

• Half-Open: 소량만 다시 흘려 보내 회복 테스트

LiteLLM 같은 라우터 계열 도구도 배포 단위 실패 수를 기준으로 쿨다운 시간을 두는 방식을 지원한다.⁶ 중요한 것은 전역적으로 하나를 끄는 것이 아니라, 공급자별·배포별·모델별로 따로 관리하는 것이다. GPT 계열의 한 리전이 흔들린다고 해서 모든 공급자를 동시에 포기할 필요는 없다.

실무적으로는 이런 식의 감각이 유용하다.

"5분 동안 실패율이 급격히 높아지면 60초 쿨다운" "연속 실패 N회면 Open 전환" "Half-Open에서는 테스트 요청만 통과"

숫자는 서비스마다 다르지만 방향은 비슷하다. 핵심은 실패한 공급자에게 매 요청마다 매번 희망을 거는 낭만을 버리는 것이다.

폴백: 다른 모델로 보내는 것이 아니라 서비스 계약을 지키는 것이다

폴백을 이야기하면 흔히 "OpenAI가 안 되면 Claude, Claude가 안 되면 Gemini" 같은 순서를 먼저 떠올린다. 물론 맞다. 하지만 그것만으로는 부족하다. 좋은 폴백은 단순한 공급자 교체가 아니라 서비스 계약 유지 전략이다.

계층형으로 생각하면 이해가 쉽다.¹

1단계: 같은 모델 짧게 재시도

429나 순간적인 503이라면 같은 모델을 한두 번 다시 시도해볼 가치가 있다. 다만 무한정 기다리지는 않는다.

2단계: 같은 공급자의 대체 모델

주 모델이 과부하일 때는 같은 공급자의 더 가벼운 모델로 내려가는 편이 빠를 수 있다. 인증과 네트워크 경로가 같아서 운영 복잡도도 상대적으로 낮다.

3단계: 다른 공급자로 전환

공급자 자체가 불안정하면 이 단계가 진짜 안전망이 된다. 다만 이때부터는 프롬프트 호환성, 구조화 출력, 툴 호출 형식 차이를 흡수할 수 있어야 한다.

4단계: 축소 응답으로 전환

여기서 많은 팀이 실수한다. "모든 생성 기능은 반드시 생성으로 끝나야 한다"고 생각하는 것이다. 실제 서비스는 그렇지 않다. 둘 다 실패하면 차라리 제한된 응답이 더 낫다.

예를 들어 이렇게 축소할 수 있다.

• 챗봇: 자유 생성 대신 FAQ 검색 결과 반환

• 요약: 실시간 요약 대신 핵심 문장 몇 개 추출

• 고객지원: 자동 답변 대신 상담 연결 안내

• 내부 업무 도구: 캐시된 마지막 성공 결과와 경고 메시지 제공

완벽한 답보다 제한된 답이 낫고, 제한된 답보다 예측 가능한 답이 더 낫다.

기능마다 폴백 기준은 달라야 한다

모든 기능이 똑같이 폴백되면 오히려 위험하다.

요약, 분류, 태깅, 제목 생성 같은 작업은 모델이 바뀌어도 서비스가 비교적 안정적으로 버틸 수 있다. 반면 결제 안내, 규정 해석, 법률·의료 보조처럼 잘못 답하면 문제가 되는 기능은 "다른 생성 모델로 계속 시도"보다 안전 모드로 내려가는 것이 더 나을 수 있다.

폴백의 목표는 늘 가용성 100%가 아니다. 어떤 기능에서는 오답을 줄이는 것이 더 중요하다. 그러니 폴백 정책도 기능별로 달라야 한다.

출력 검증이 없는 폴백은 절반짜리다

폴백 체인을 잘 만들어 놓고도 실제 운영에서 사고가 나는 이유는, 다른 모델이 준 결과를 같은 계약으로 검증하지 않기 때문이다.

예를 들어 1차 모델은 {"label":"refund","confidence":0.92} 형태를 주는데, 폴백 모델은 {"category":"refund"}만 반환할 수 있다. API 호출 자체는 성공이지만, 서비스 입장에서는 실패다. 응답이 왔다는 사실보다 쓸 수 있는 응답이 왔는지가 더 중요하다.

그래서 폴백 뒤에는 반드시 출력 검증이 필요하다.

• JSON 스키마 검증

• 필수 필드 존재 여부 확인

• 허용 라벨 집합 검증

• 빈 응답 또는 너무 짧은 응답 차단

• 안전 필터 후처리

정리하면, 폴백은 "누가 대답했는가"의 문제가 아니라 우리 서비스가 받을 수 있는 형태로 대답했는가의 문제다.

스트리밍은 일반 응답과 다르게 다뤄야 한다

스트리밍은 체감 속도를 크게 올려 주지만, 장애 대응 관점에서는 조금 까다롭다. 일반 요청은 실패하면 조용히 다른 공급자로 넘길 수 있다. 하지만 스트리밍은 첫 토큰이 사용자 화면에 보이는 순간 상황이 바뀐다.

이미 사용자에게 일부 내용이 전달된 뒤에는, 뒤늦게 다른 공급자로 갈아타도 자연스럽게 이어 붙일 수 없다. 새 모델은 처음부터 다시 생성할 가능성이 높고, 그러면 문장이 중복되거나 앞뒤 문맥이 어긋난다. 그래서 스트리밍에서는 첫 청크가 나가기 전까지만 재시도와 폴백을 투명하게 적용할 수 있고, 첫 청크 이후 실패는 보통 사용자에게 드러내야 한다.⁷

이 특성 때문에 스트리밍 장애 대응은 UI 설계와 함께 봐야 한다.

예를 들어 이런 방식이 현실적이다.

• 첫 청크 전 실패: 자동 재시도 또는 폴백

• 첫 청크 후 실패: "응답이 중간에 끊겼습니다. 이어서 다시 생성할까요?" 버튼 제공

• 부분 결과 저장: 이미 받은 텍스트는 보존

• 재생성 요청 시: 이전 부분을 참고하되, 중복 생성 방지 지시 추가

스트리밍은 멋진 기능이지만, 운영 입장에서는 "부분 성공"이라는 새로운 실패 모드를 데려온다는 점을 기억해야 한다.

레이트 리미터는 재시도보다 앞에 있어야 한다

재시도는 실패 후 대응이다. 레이트 리미터는 실패 전 예방이다. 둘은 비슷해 보여도 역할이 다르다.

클라이언트 측에서 요청 빈도와 동시성을 제어하면 429를 맞기 전에 속도를 조절할 수 있다. LangChain 쪽 문서도 요청 빈도 제한과 최대 동시성 제한으로 공급자 레이트 리밋을 피하는 방식을 소개한다.⁸

이 원칙은 꽤 중요하다. 장애 순간에는 "더 빨리 더 많이 보내야 하나?"라는 착각이 생기기 쉬운데, 실제로는 그 반대다. 공급자가 힘들어할 때는 더 천천히, 더 적게 보내는 것이 전체 성공률을 올린다.

실전 순서는 보통 이렇다.

1. 캐시 조회

2. 예산·쿼터·레이트 리미터 확인

3. 공급자 선택

4. 짧은 재시도

5. 폴백

6. 출력 검증

7. 캐시 저장과 로그 기록

이 순서가 좋은 이유는 분명하다. 이미 캐시로 해결 가능한 요청은 공급자에 보내지 않는다. 보내더라도 레이트 리미터가 먼저 속도를 조절한다. 그리고 실패가 나면 그때 재시도와 폴백이 움직인다. 즉, 방어선이 앞단부터 겹겹이 쌓이는 구조다.

캐싱, 재시도, 폴백은 따로가 아니라 하나의 파이프라인이다

실무에서는 이 세 가지를 각각 독립 기능처럼 붙이기 쉽다. 하지만 운영 관점에서는 하나의 흐름으로 설계하는 편이 낫다.

Client
  -> API / Worker
    -> Cache Lookup
      -> Rate Limiter / Budget Guard
        -> Circuit Breaker Check
          -> Primary Provider Call
            -> Retry Policy
              -> Fallback Chain
                -> Output Validator
                  -> Cache Store
                    -> Response / Degraded Response

여기서 중요한 것은 정책 결정과 비즈니스 로직을 분리하는 것이다. 제품 코드는 "요약을 해줘", "분류를 해줘", "답변을 만들어줘" 정도만 말하고, 캐시 여부, 재시도 횟수, 폴백 순서, 축소 응답 규칙은 공통 서비스 계층이나 게이트웨이가 맡는 편이 유지보수에 훨씬 좋다.³

이 구조를 잘 잡아두면 장애 대응이 코드 수정을 요구하지 않는다. 설정과 정책 변경으로도 상당 부분 조정할 수 있다.

무엇을 측정해야 진짜 안정적인지 알 수 있을까

가용성은 단순 성공률 하나로 보이지 않는다. LLM 서비스는 "겉으로는 성공했지만 내부적으로는 이미 비명을 지르는 상태"가 자주 생긴다. 그래서 다음 지표들을 따로 봐야 한다.

• cache hit ratio: 캐시 적중률

• safe hit ratio: 적중했지만 품질 기준도 통과한 비율³

• retry rate: 요청 중 재시도가 발생한 비율

• fallback rate: 주 경로가 아닌 보조 경로를 탄 비율

• degraded response ratio: 축소 응답이 나간 비율

• circuit open duration: 서킷이 열린 시간

• provider별 p95 latency: 공급자별 꼬리 지연 시간

• cost per successful task: 실제로 유효한 결과 하나를 만드는 비용

이 지표들이 필요한 이유는 간단하다. 겉보기 200 OK만 보면 서비스가 멀쩡해 보일 수 있기 때문이다. 하지만 내부적으로 재시도와 폴백이 급증하고 있다면, 이미 장애의 전조에 들어간 것이다.

특히 fallback rate가 갑자기 치솟는 날은 조용히 지나가면 안 된다. 사용자는 아직 답을 받고 있을지 몰라도, 서비스는 이미 예비 엔진으로 날고 있는 중이기 때문이다.

흔한 안티패턴

좋은 전략을 배우는 것만큼, 나쁜 습관을 빨리 버리는 것도 중요하다.

• 모든 계층에서 재시도한다.

• 캐시 키를 사용자 입력 문자열 하나로 끝낸다.

• 폴백 모델 응답을 검증 없이 그대로 사용한다.

• 400, 401, 403 오류까지 기계적으로 재시도한다.

• 스트리밍 도중 실패했는데 조용히 다른 모델로 이어 붙이려 한다.

• 개인 정보나 권한별 응답을 평문 캐시에 그대로 저장한다.

• 고신뢰 기능에서도 무조건 다른 생성 모델로만 폴백한다.

이 안티패턴들의 공통점은 하나다. 모두 "성공률 숫자"만 보고 "서비스 계약"을 잊는다는 점이다. 안정성은 성공 응답 개수만으로 생기지 않는다. 예상 가능한 방식으로 동작하는 것에서 생긴다.

도입 순서는 작게 시작하는 편이 좋다

처음부터 거대한 AI 게이트웨이와 복잡한 정책 엔진을 만드는 것은 보통 과하다. 대신 아래 순서로 올라가면 현실적이다.

먼저 오류를 재시도 가능, 우회 가능, 즉시 실패로 나눈다. 그다음 재시도는 한 레이어에서만 짧게 넣는다. 이후 반복 요청이 많은 엔드포인트에 응답 캐시를 붙인다. 그리고 공급자별 서킷 브레이커와 폴백 체인을 추가한다. 마지막으로 축소 응답과 운영 대시보드를 붙이면 된다.

이 순서를 추천하는 이유는 간단하다. 캐싱만 잘해도 트래픽과 비용이 먼저 줄고, 재시도만 바로잡아도 장애 시 증폭이 크게 줄며, 폴백은 그다음에야 효과를 제대로 볼 수 있기 때문이다. 순서를 바꾸면 시스템만 복잡해지고 얻는 체감은 적을 수 있다.

결국 중요한 것은 "정답을 계속 내는 능력"이 아니라 "망가지지 않는 방식"이다

LLM 서비스의 안정성은 고성능 모델을 붙였다고 자동으로 생기지 않는다. 같은 요청을 반복해서 계산하지 않게 만들고, 다시 시도할 가치가 있는 실패만 짧게 다루고, 공급자가 흔들릴 때는 다른 경로로 우회하고, 그마저 안 되면 서비스가 약속한 최소 계약을 지키는 방식으로 축소해야 한다.

이게 바로 캐싱, 재시도, 폴백의 본질이다.

정리하면 이렇게 말할 수 있다.

캐싱은 낭비를 줄이는 기술이고, 재시도는 일시적 실패를 흡수하는 기술이며, 폴백은 구조적 실패를 견디는 기술이다.

그리고 이 셋이 함께 돌아갈 때 비로소 LLM 기능은 "데모"를 넘어 "서비스"가 된다.

참고

¹[AI] AI 서비스 장애 대응: LLM API 장애 시 Fallback 전략 설계

²Optimizing LLM Performance with Caching, Fallback, and Load Balancing

³2026 개발 트렌드: LLM Gateway + Prompt Cache가 AI 기능 비용과 지연을 통제하는 방식

⁴LLM API Error Handling and Retry Patterns - Library

⁵LLM API Retry & Fallback: Build a Resilient Client

⁶Router - Load Balancing | liteLLM

⁷Retry and Fallback: How Edgee Keeps Your LLM Requests Reliable

⁸How to handle model rate limits