레이트 리밋과 재시도: 견고한 LLM 호출 만들기

거의 모든 LLM 통합의 첫 버전은 개발자의 노트북에서는 작동하다가, 프로덕션에서 처음 바빠진 오후에 쓰러집니다. 이유는 모델인 경우가 드뭅니다. 호스팅된 API는 공유 네트워크 서비스이고, 공유 네트워크 서비스는 평범하고 예측 가능한 방식으로 실패하기 때문입니다. 한계를 부과하고, 타임아웃이 나고, 가끔 "잠시 후 다시 시도하라"는 것 이상의 의미가 없는 오류를 반환합니다. 취약한 통합과 믿음직한 통합의 차이는 영리함이 아닙니다. 일관되게 적용된 약간의 재시도 규율입니다. 이 가이드는 무엇이 잘못되는지, 그리고 각 경우를 어떻게 침착하게 처리하는지를 다룹니다.

호출이 실패하는 이유 (그리고 어떤 실패가 정상인가)

실패를 두 더미로 분류하는 것부터 시작하십시오. 둘은 정반대의 대응을 요구하기 때문입니다.

일시적 실패는 일시적이며, 지속적인 의미에서 여러분의 잘못이 아닙니다. 서비스가 잠깐 과부하였거나, 레이트 리밋에 걸렸거나, 요청이 타임아웃됐거나, 연결이 끊겼습니다. 핵심 특징은 같은 요청을 그냥 다시 보내면 성공할 수도 있다는 점입니다. 재시도가 존재하는 이유가 바로 이런 실패들입니다.

영구적 실패는 반복해도 나아지지 않습니다. 잘못된 형식의 요청, 유효하지 않은 키, 정책을 위반하는 프롬프트, 모델에 비해 너무 큰 입력 — 이것을 다시 보내는 일은 시간과 할당량을 낭비할 뿐이며, 더 나쁘게는 레이트 리밋에 더 깊이 파고들 수 있습니다. 핵심 특징은 요청이 운이 나쁜 게 아니라 틀렸다는 점입니다.

견고한 LLM 코드에서 가장 중요한 단 하나의 습관은 이 둘을 구별하고 다르게 대응하는 것입니다. 영구적 실패를 재시도하는 것은 버그입니다. 일시적 실패에 강하게 실패하는 것도 버그입니다. 대부분의 취약한 통합은 이 두 실수 중 하나를 곳곳에서 저지릅니다.

레이트 리밋 이해하기

레이트 리밋은 가장 흔한 일시적 실패이며, 처벌이 아닙니다. 공유 서비스가 단일 클라이언트가 압도하는 것으로부터 자신과 다른 사용자들을 보호하는 방식입니다. 제공자는 보통 한 번에 몇 가지 축을 따라 사용량에 상한을 둡니다 — 한 윈도 안에서 몇 건의 요청을 하는지, 그리고 그 윈도에서 얼마나 많은 총 작업량(흔히 토큰으로 측정)을 밀어 넣는지입니다. 한 상한 아래에 머물면서도 다른 상한에 걸릴 수 있습니다.

실용적인 결과는, 요청 수만 세어서는 처리량을 가늠할 수 없다는 점입니다. 아주 큰 요청 몇 개가 요청 상한에는 한참 못 미치면서도 토큰 예산을 소진할 수 있습니다. 레이트 리밋이 발동하면 서비스는 그 사실을 명시적으로 알려 주며, 흔히 얼마나 기다려야 하는지에 대한 힌트도 줍니다. 올바른 대응은 더 세게 두드리는 것이 아닙니다. 속도를 늦추고 나중에 다시 오는 것입니다.

두 가지 습관이 대부분의 레이트 리밋 고통을 시작되기 전에 막습니다. 첫째, 응답 헤더와 오류 본문을 읽으십시오 — 제공자는 거기에 현재 사용량과 한계를 노출하며, 그 정보가 지능적으로 물러나기 위한 입력입니다. 둘째, 여러분 자신의 트래픽을 고르게 펴십시오. 작업이 한꺼번에 몰린다면, 전부를 한 번에 쏘는 대신 펼쳐서, 한계에 들이받는 대신 점진적으로 다가가게 하십시오.

올바르게 재시도하기

재시도를 할 때, 어떻게 재시도하느냐가 엄청나게 중요합니다. 순진한 접근 — 즉시, 계속해서 재시도 — 은 적극적으로 해롭습니다. 서비스가 과부하라면 즉각적인 재시도의 홍수가 상황을 더 악화시키고, 여러분은 살아남으려 애쓰던 바로 그 문제의 일부가 됩니다. 규율 있는 접근에는 세 가지 재료가 있습니다.

지수 백오프. 첫 재시도 전에 잠깐 기다리고, 이후 매 재시도마다 대기 시간을 대략 두 배로 늘리십시오. 첫 번째 작은 차질에는 빠른 두 번째 기회를 주고, 지속적인 문제에는 점진적으로 더 많은 숨 쉴 틈을 줍니다. 이 단일 패턴이 일시적 실패의 대다수를 해결합니다.

지터. 각 대기 시간에 작은 무작위 양을 더하십시오. 그것이 없으면, 같은 순간에 실패한 많은 클라이언트가 모두 같은 순간에 재시도해, 서비스를 다시 과부하시키는 동기화된 쇄도가 생깁니다. 지터는 재시도를 펼쳐 줍니다. 규모에서는 작은 변화가 큰 효과를 내며, 이것을 건너뛰는 것은 전형적인 실수입니다.

재시도 상한. 시도 횟수와 들일 총 시간을 제한하십시오. 영원히 재시도하는 것은 짧은 장애를, 자원을 묶고 기다리는 누군가를 좌절시키는, 멈춰 버린 요청으로 바꿉니다. 상한을 넘으면 깔끔하게 포기하고 진짜 실패를 드러내십시오.

종합하면, 일시적 오류에서는 지수 백오프에 지터를 더해 기다리고, 정해진 한계까지 재시도하며, 얼마나 기다려야 하는지에 대한 힌트가 제공되었다면 여러분이 계산한 지연보다 그것을 우선하십시오.

타임아웃, 그리고 재시도의 한계

모든 호출에는 타임아웃이 필요하며, 그것을 고르는 일은 진짜 트레이드오프입니다. 너무 짧으면 성공했을 요청을 버려, 느리지만 멀쩡한 응답을 실패로 바꿉니다. 너무 길면 멈춰 버린 요청이 시스템을 매달고 사용자를 묶습니다. 실제로 기대하는 응답 길이에 기반해 타임아웃을 고르고, 긴 생성은 정당하게 더 오래 걸린다는 점을 기억하십시오 — 한 줄짜리 답에 맞춰 튜닝한 타임아웃은 긴 답에 대한 요청을 잘못 죽일 것입니다.

타임아웃은 사람들을 무는 방식으로 재시도와 상호작용합니다. 서버가 아직 작업 중인데 여러분 쪽에서 요청이 타임아웃될 수 있습니다. 무턱대고 재시도하면 같은 비싼 작업을 두 번 실행할 수 있습니다. 읽기 전용 생성이라면 그저 낭비입니다. 효과를 일으키는 어떤 호출 — 메시지 전송, 레코드 기록, 도구 실행 — 이라면 중복 실행은 진짜 버그입니다. 방어책은 멱등성입니다. 효과를 일으키는 작업을 두 번 해도 안전하도록 설계하십시오. 흔히 서버가 반복을 인식하고 중복을 제거하는 데 쓸 수 있는 고유 키를 붙이는 방식입니다.

재시도가 소진됐을 때 우아하게 실패하기

견고함은 복구만의 문제가 아닙니다. 복구가 불가능할 때 잘 실패하는 것이기도 합니다. 때로는 서비스가 정말로 다운되어 어떤 백오프도 도움이 되지 않으니까요. 우아한 실패에는 몇 가지 속성이 있습니다.

• 경계가 있습니다. 사용자나 호출 시스템이 무한정 매달리는 대신, 합리적인 시간 안에 명확한 답을 받습니다.
• 붕괴하는 대신 점진적으로 낮아집니다. 제품이 허용하는 곳에서는 빈 오류 대신 유용한 무언가 — 캐시된 결과, 더 단순한 비모델 경로, 정직한 "현재 일시적으로 사용할 수 없음" — 로 폴백하십시오.
• 보입니다. 나중에 이해할 수 있을 만큼 충분한 맥락과 함께 실패를 로깅하고, 모니터링할 수 있는 신호를 드러내, 상승하는 실패율이 사용자가 그것을 에스컬레이션하기 전에 여러분에게 닿게 하십시오.

성숙한 통합의 표식은 결코 실패하지 않는다는 것이 아닙니다. 실패할 때 하류의 어떤 것도 놀라지 않는다는 것입니다.

아프기 전에 보기

보지 못하는 것은 튜닝할 수 없습니다. 최소한 유형별 실패율, 재시도가 얼마나 자주 발동하고 얼마나 자주 최종적으로 성공하는지, 백오프에 쓴 시간을 포함한 지연 시간, 그리고 레이트 리밋에 얼마나 가깝게 운영하고 있는지를 추적하십시오. 마지막 것이 조기 경보 시스템입니다. 상한을 향해 기어오르는 사용량은 벽에 부딪힌 뒤가 아니라 그 전에 트래픽을 펴고, 프롬프트를 최적화하고, 더 높은 한계를 요청하라는 신호입니다. 대부분의 레이트 리밋 사고는 — 보고 있는 사람에게는 — 몇 시간 전부터 추세로 보입니다.

정리

견고한 LLM 호출은 짧고 지루한 규율로 귀결됩니다. 일시적 실패와 영구적 실패를 분리하고 각각에 올바르게 대응하십시오. 일시적 실패는 지수 백오프, 지터, 단호한 상한으로 재시도하되 — 결코 즉각적인 빡빡한 루프로는 하지 마십시오. 트래픽을 고르게 펴고 서비스가 알려 주는 것을 읽어 레이트 리밋을 존중하십시오. 타임아웃을 의도적으로 설정하고, 효과를 일으키는 호출은 멱등으로 만들어 재시도가 결코 두 번 실행되지 않게 하십시오. 재시도가 소진되면 경계가 있고, 보이고, 점진적으로 낮아지는 방식으로 실패하며, 벽 앞에서 행동하도록 한계를 지켜보십시오. 어느 것도 화려하지 않지만, 그 전부가 바쁜 오후를 견뎌 내는 통합과 그러지 못하는 통합을 가르는 것입니다.