LLM rate-limit·타임아웃
LLM API rate-limit / 타임아웃 처리 패턴
맞춤법 검사에서 LLM 폴백이 자꾸 느리거나, rate-limit·타임아웃 오류가 나나요? 바른의 교정
파이프라인은 마지막 단계에서 LLM을 사용하는데, 외부 API 한도와 응답 지연이 그대로 영향을 줍니다.
이 문서로 대처 패턴을 정리해요.
증상
- 교정 응답이 느리고, LLM 폴백 단계에서 지연이 길어집니다.
- LLM 제공자의 rate-limit(요청 한도 초과)이나 타임아웃 오류가 보입니다.
- 같은 문장을 반복 교정할 때만 빨라지고, 새 문장은 느립니다.
원인
바른의 맞춤법 검사는 규칙 교정으로 대부분을 처리하고, 남은 어려운 어절만 LLM으로 폴백합니다.
이때 LLM은 OpenAI 또는 Gemini 같은 외부 API를 호출하므로, 제공자의 요청 한도와 응답 지연이
그대로 교정 성능에 반영됩니다.
| 원인 | 설명 |
|---|---|
| rate-limit | 동시 요청이 제공자 한도를 넘음 |
| 타임아웃 | 응답이 설정 시간 내 오지 않음 |
| 캐시 미스 | 처음 보는 어절은 LLM을 새로 호출 |
해결
revise-ai.json에서 동시 요청 수와 타임아웃을 조절할 수 있어요.
-
동시 요청 수를 조절하세요.
max_concurrent_requests로 LLM에 동시에 보내는 요청 수를 제한합니다. rate-limit이 잦다면 이 값을 낮춰보세요. -
타임아웃을 조정하세요.
request_timeout_seconds로 응답 대기 시간을 정합니다. 너무 짧으면 정상 응답도 타임아웃되고, 너무 길면 지연이 누적됩니다.설정만 바꿀 때는 재빌드가 필요 없어요
revise-ai.json과 프롬프트 파일만 바꾸는 변경은 이미지 재빌드 없이 반영할 수 있습니다. 다만 변경 후에는 서버가 새 설정을 읽도록 적용 절차를 따르세요. -
캐시를 활용하세요. 어절 교정 결과와 띄어쓰기 판별 결과는 캐시됩니다. 같은 입력이 반복되면 LLM을 다시 부르지 않아 빨라집니다.
예방·팁
- 트래픽이 몰리는 환경이라면
max_concurrent_requests를 보수적으로 잡아 rate-limit을 예방하세요. - 반복 입력이 많은 워크로드는 캐시 효과가 커서 LLM 호출이 크게 줄어듭니다.
자주 묻는 질문
Q. LLM rate-limit 오류를 줄이려면 어떻게 하나요?
revise-ai.json의 max_concurrent_requests를 낮춰 동시 요청 수를 제한하세요. 캐시가 반복 입력의
재호출을 줄여줍니다.
Q. 교정 타임아웃은 어디서 조정하나요?
revise-ai.json의 request_timeout_seconds로 응답 대기 시간을 조정합니다. 너무 짧으면 정상
응답도 타임아웃되고 너무 길면 지연이 쌓이니, 환경에 맞춰 균형을 잡으세요.
Q. LLM 없이도 맞춤법 검사가 되나요?
규칙 기반 교정(띄어쓰기, 빈도 오타, 비표준어 등)은 LLM 없이 동작합니다. 다만 규칙으로 처리하지 못한 어려운 어절은 LLM 단계의 도움을 받습니다.
Q. revise-ai.json만 바꾸면 다시 빌드해야 하나요?
아니요. revise-ai.json과 프롬프트 파일만 바꾸는 변경은 이미지 재빌드 없이 반영할 수 있어요.
다만 변경 후에는 서버가 새 설정을 읽도록 적용 절차를 따르세요. 동시 요청 수나 타임아웃을 조정하는
경우 특히 유용합니다.
Q. 같은 문장만 빠르고 새 문장은 느려요. 왜 그런가요?
어절 교정과 띄어쓰기 판별 결과가 캐시되기 때문이에요. 이미 본 입력은 LLM을 다시 부르지 않아 빠르지만, 처음 보는 어절은 LLM을 새로 호출하는 캐시 미스라 느립니다. 반복 입력이 많은 워크로드일수록 캐시 효과가 커집니다.
도움이 되었나요?