Deepseek V4 속도 제한: 대용량 처리를 위한 프로덕션 패턴

안녕하세요, 저는 Dora입니다. 지난주에 작은 문제에 발이 걸렸습니다. 메모 앱에 새 도구를 연결하던 중 무해한 프롬프트 배치 처리 과정에서 429 오류가 연달아 발생하는 걸 계속 보게 됐습니다. 극적인 일은 아니었지만, 작업 흐름을 끊기엔 충분했습니다. 그 계기로 익숙한 토끼굴로 다시 빠져들었습니다. Deepseek V4 레이트 리밋은 어떻게 될 것이며, 어느 쪽이든 문제없도록 어떻게 설계해야 할까?

저는 화려한 스펙을 쫓지 않습니다. 스펙이 바뀌어도 안정적으로 유지되는 시스템을 만들려 합니다. 그래서 지금 Deepseek V4 레이트 리밋에 대해 제가 생각하는 방식과, 상한선이 불분명하거나 계속 변할 때 제가 의지하는 패턴들을 정리해 봤습니다.

예상 레이트 리밋

단 하나의 마법 같은 숫자를 찾아 이 글을 읽으러 오셨다면, 저는 그걸 갖고 있지 않습니다. 2026년 1월 테스트 기준으로, Deepseek V4 레이트 리밋에 대한 공식적이고 명확한 수치를 아직 확인하지 못했습니다. 설령 확인했더라도, 제공사는 계정 등급, 지역, 어뷰징 신호에 따라 제한을 바꿉니다. 또한 분당 요청 수(RPM)와 분당 토큰 수(TPM)를 별도로 관리하고, 동시 스트림에 상한을 두기도 합니다.

대신 제가 주목하는 것들:

분당 요청 수(RPM): 호출을 몇 번이나 보낼 수 있는지.
분당 토큰 수(TPM): 특히 긴 컨텍스트에서 더 크게 작용하는 숨겨진 제약.
동시성(Concurrency): API가 허용하는 동시 진행 요청 수.
재시도 시맨틱스: Retry-After나 X-RateLimit-* 같은 헤더가 있고 신뢰할 수 있는지.

저는 이것들을 날씨처럼 대합니다. 확인하면 유용하지만, 항상 맑을 거라 믿는 건 현명하지 않습니다.

현재 V3 제한을 기반으로

2025년 말 메모를 보면, v3는 대부분의 현대 LLM API처럼 낮은 볼륨에서는 예측 가능하고 엣지에서는 민감하게 동작했습니다. RPM과 토큰 예산 모두로 표현된 상한을 확인했고, 헤더는 백오프를 안내하기에 충분했으며, 긴 프롬프트는 제 예상보다 훨씬 빠르게 여유분을 소진했습니다.

따라서 v4가 v3의 패턴을 따른다면, 제가 계획하는 내용은 다음과 같습니다:

크기 비교 수준의 동등성: v4가 출시 시점에 v3보다 터무니없이 여유롭지는 않을 것으로 가정합니다. 새 모델은 처음엔 타이트하게, 나중에 느슨해지는 경향이 있습니다.
토큰 우선 사고방식: RPM보다 TPM에 더 많은 여유를 둡니다. 요청 하나가 길면 작은 요청 여러 개와 맞먹을 수 있습니다.
버스트 vs. 지속 부하: 짧은 급증이 꾸준한 흐름보다 429를 더 자주 유발합니다. 버스트는 클라이언트 측에서 평탄화합니다.

실질적으로, 이는 요청 수가 아닌 토큰 기준으로 큐 크기를 조정한다는 뜻입니다. 사용자가 30페이지 문서를 붙여넣으면, 단 하나의 요청이더라도 이후 몇 분이 “비싼” 시간이 될 것을 예상합니다. 그리고 제한이 시간대와 IP에 따라 달라질 수 있다는 사실도 인정합니다. 당연한 말처럼 들리지만, 모든 게 잘 돌아가다가 갑자기 그렇지 않게 될 때까지는 잊어버리기 쉽습니다.

클라이언트 측 패턴

첫 채팅부터 반복 가능한 API 루프까지 이런 설정을 빠르게 구현하고 싶다면, 제 짧은 DeepSeek V4 빠른 시작 가이드를 확인해 보세요.

이것들은 지원팀에 상한 상향을 요청하기 전에 제가 먼저 찾는 패턴들입니다. 지루하다는 게 바로 핵심입니다. 정신적 부담을 줄이고 제한을 배경 소음처럼 느끼게 만들어 줍니다.

지수 백오프

첫 번째 시도는 지터가 있는 단순 백오프입니다. 복잡하지 않습니다.

제가 관찰한 것들:

처음 몇 번은 느리게 느껴졌습니다. 거의 끄려 했습니다. 그러다 급증 구간에서 재시도 폭풍에 갇히는 일이 없어졌다는 걸 알아챘습니다.
지터가 중요했습니다. 없으면 배치 작업들이 “썬더 허드” 현상을 일으켜 동시에 재시도했습니다.
Retry-After가 있을 때 이를 존중하는 게 영리하게 구는 것보다 시간을 더 아꼈습니다. 서버가 언제 다시 시도하라고 알려주면, 그 말을 따릅니다.

일상적인 튜닝 방법:

작게 시작: 기본 지연 250~500ms.
지수: 매 재시도마다 두 배로, 합리적인 상한(8~16초)까지. 상한에 두 번 도달하면 컨텍스트와 함께 로그에 기록합니다.
우아하게 포기: 4~6번 시도 후, 힌트가 담긴 타입 오류를 전파합니다(더 작은 배치나 나중에 재시도 권장).

도움이 된 작은 디테일: 429에 대한 재시도와 5xx에 대한 재시도를 분리합니다. 이야기가 다릅니다. 429는 “너무 많이 밀고 있다”는 뜻이고, 5xx는 “서비스가 불안정하다”는 뜻입니다. 5xx에서는 더 길게 백오프합니다.

요청 큐잉

UI나 크론 작업이 “텍스트일 뿐”이라는 이유로 무제한 호출을 보내도록 내버려 두지 않습니다. 그게 레이트 리밋을 개인적으로 느끼게 만드는 방법입니다.

예상보다 잘 작동한 것들:

토큰 가중 큐. 동시에 N개 요청 대신, 토큰 예산이 채워질 때까지 요청을 허용합니다. 그런 다음 큐가 숨 쉬게 둡니다.
작은 배치 윈도우. 짧은 윈도우(200~500ms)로 요청을 묶어 앱이 느리게 느껴지지 않으면서 마이크로 버스트를 평탄화합니다.
우선순위 레인. 사용자가 직접 트리거한 작업이 먼저: 백그라운드 동기화는 기다립니다. 이것만으로도 최악의 급증이 사라졌습니다.

마주친 어려움:

토큰 추정이 완벽하지 않습니다. 클라이언트에 저렴한 추정기를 두고 응답이 돌아올 때 실제 사용량으로 보정합니다. 정확한 것보다 충분히 좋은 것이 낫습니다.
취소. 사용자가 페이지를 떠나면 대기 중인 호출을 취소해 화면에 보이는 것들을 위한 예산을 확보합니다. 기본적으로 들릴 수 있지만, 실질적인 사이클을 아꼈습니다.

제가 따르는 단순한 규칙: 큐가 임계값(길이가 아닌 시간 기준)을 넘으면 조용한 알림을 보여줍니다. 호들갑 없이. “꾸준히 처리 중”이라는 한 줄이면 충분합니다. 사용자는 속도만큼이나 어조를 읽습니다.

서킷 브레이커

제한이 강하게 걸리거나 오류가 쌓이면, 수천 번의 재시도가 유용한 척하는 걸 원하지 않습니다. 서킷 브레이커는 시스템에 쉬어갈 권한을 줍니다.

제가 사용하는 방식:

지속적인 실패율에서 트립: 예를 들어, 롤링 1분 내 호출의 25~30%가 429/5xx인 경우.
하프오픈 상태: 잠시 멈춘 후, 소수의 카나리 요청을 통과시킵니다. 성공하면 브레이커가 닫힙니다.
UI 동작: “API가 스로틀링 중: 곧 재개합니다”와 같은 부드러운 배너를 표시합니다. 실제 진행이 없을 때 진행 중인 것처럼 보이는 스피너는 피합니다.

조용한 발견: 제약을 솔직하게 인정했을 때 사용자들이 더 너그러웠습니다. 브레이커가 앱을 취약하게 만들지 않았습니다. 오히려 솔직하게 느껴지게 했습니다.

모니터링과 알림

예전에는 레이트 리밋을 엣지 케이스로 취급해서 로그가 빈약했습니다. 그건 실수였습니다. v4가 다가오면서, 저는 먼저 가드레일을 만들고 제한이 어떻게 되든 받아들이기로 했습니다.

지금 제가 수집하는 것들:

상태 코드와 이유. 엔드포인트별, 호출자별(사용자 vs. 작업)로 구분한 429. 5xx는 별도 추적.
실효 토큰 비용. 요청당 프롬프트 + 완성 토큰. RPM만으로는 설명하기 어려운 동작을 이것이 설명합니다.
지연 시간 백분위수. 경로별 P50, P95, P99. 급증은 종종 스로틀링에 선행합니다.
재시도 메타데이터. 시도 횟수, 총 백오프 시간, Retry-After 준수 여부.
클라이언트 측 동시성. 429가 발생하는 순간 진행 중인 호출 수.

또한 작은 일별 요약도 유지합니다: “요청 수, 토큰, 오류율, 추가된 평균 백오프.” 자체 대시보드가 필요한 대시보드를 만들지 않고도 트렌드를 파악하기에 충분합니다.

저를 귀찮게 하지 않은 알림들:

급증이 아닌 바닥 이상의 429 비율. 429가 10분 동안 2~3%를 초과하는 경우를 신경 씁니다. 한 번의 튀는 값은 알림을 보내지 않습니다.
백오프 시간 예산. 사용자가 세션당 평균 X초 이상의 백오프를 기다리고 있다면 알고 싶습니다.
토큰 이상 징후. 중앙값 프롬프트 크기가 3배로 뛰면, 누군가 변경 사항을 배포했거나 사용자 행동이 바뀐 것입니다.

사람 측면에서, 저는 제한을 백엔드 문제만이 아닌 제품 제약으로 취급합니다. 무거운 컨텍스트 업로드를 위한 인터페이스를 만들고 있다면, 힌트를 제공합니다:

“대용량 파일은 백그라운드에서 처리될 수 있습니다. 완료되면 알려드리겠습니다.”
“짧은 요약 먼저, 심층 분석은 그 다음.”

그냥 예의 바른 게 아닙니다. 레이트 리밋이 감당할 수 있는 패턴으로 사용을 유도하는 것입니다.

문서화에 대한 짧은 말: 가능하면 공식 문서나 헤더를 통해 동작을 확인합니다. v4가 명확한 레이트 헤더(Retry-After, X-RateLimit-Remaining, 또는 토큰 카운터)와 함께 출시된다면 그대로 로그에 기록합니다. 헤더가 없거나 모호하면, 관찰된 상한에 넉넉한 안전 마진을 두고 대처합니다.

이것이 중요한 이유

개발자에게: 정확한 수치 없이도 자신 있게 출시할 수 있습니다. 가변성을 고려해 설계하고 재시도는 조용하게 유지하세요.
규모 있는 팀에게: 현재 제한을 클라이언트가 잘 준수하고 있음을 증명한 후 상한 상향을 요청하세요. 대부분의 제공사는 합리적인 백오프와 깔끔한 로그를 보면 더 긍정적으로 반응합니다.
개인 개발자에게: 단순하게 유지하세요. 작은 큐, 지터가 있는 기본 백오프, 알림 한두 개면 충분히 먼 길을 갑니다.

이걸 즐기지 못할 사람