응답이 느릴 때 점검할 5가지 (GPU·실행 프로바이더·입력 길이)

분석·교정 응답이 느린가요? 원인은 실행 프로바이더, 입력 길이, LLM 사용 여부 등 몇 군데로 좁혀집니다. 차례로 점검해봐요.

바른의 처리 속도에 영향을 주는 요소를 정리하면 이래요.

요소	설명
실행 프로바이더	`executionProvider`(cpu/gpu)와 폴백 여부
입력 길이	분절은 160자 단위로 처리, 긴 문장은 분할
문장 수	한 요청에 담긴 문장·어절 수
LLM 사용(맞춤법 검사 빌드)	교정에서 LLM 폴백·띄어쓰기 판별 호출

실행 프로바이더를 확인하세요. GPU 환경이면 executionProvider가 gpu인지, 그리고 실제로 GPU로 도는지 보세요. CPU로 폴백됐다면 가속을 못 받습니다(GPU 폴백 참고).
입력 길이를 점검하세요. 분절(Segmenter)은 한 번에 160자를 처리하고, 더 긴 문장은 나누어 처리합니다. 지나치게 긴 입력은 분할 처리량이 늘어 느려질 수 있어요. 적정 길이로 잘라 보내면 응답이 빨라집니다.
한 요청의 문장 수를 조절하세요. 한꺼번에 너무 많은 문장을 보내면 처리 시간이 누적됩니다. 대량 처리라면 적당한 단위로 나누어 보내세요.
문맥 판단이 필요한 문장이 섞였는지 보세요(맞춤법 검사 빌드). 맞춤법 검사는 표기만으로 가릴 수 없는 어절을 AI 판정에 맡깁니다. 그 판정은 외부 서비스를 거치므로 응답이 길어질 수 있어요. 긴 문서라면 문단 단위로 나누어 보내고, 지연이 반복되면 문의해 주세요.
반복 입력은 캐시를 활용하세요(맞춤법 검사 빌드). 같은 어절·띄어쓰기 판별은 캐시되어 재호출을 줄입니다. 반복이 많은 워크로드일수록 효과가 큽니다.

빠른 진단 순서

GPU 폴백 여부 → 입력 길이 → 문장 수 → (교정이면) AI 판정이 걸린 문장 순으로 보면 원인을 빠르게 좁힐 수 있어요.

실행 프로바이더입니다. GPU로 설정했는데 CPU로 폴백됐는지 확인하세요. 그 다음 입력 길이(분절은 160자 단위 처리)와 한 요청의 문장 수, 교정이라면 LLM 사용 여부를 점검합니다.

분절은 한 번에 160자를 처리하고 더 긴 문장은 나누어 처리하기 때문입니다. 입력이 매우 길면 분할 처리량이 늘어 시간이 더 걸립니다. 적정 길이로 잘라 보내면 빨라집니다.

교정은 규칙 처리 뒤 어려운 어절을 LLM으로 폴백하는데, 외부 API 응답 지연이 그대로 반영됩니다. 동시 요청 수·타임아웃 설정과 캐시 활용으로 개선할 수 있습니다.

GPU로 설정했어도 실행 프로바이더 초기화에 실패하면 CPU로 폴백돼 가속을 못 받습니다. 기동 로그에 폴백 경고가 없는지, GPU 사용률이 올라가는지 확인하세요. 자세한 진단은 GPU 폴백 문서를 보면 됩니다.

정상입니다. 형태소 분석은 모델·사전을 기동 시 미리 메모리에 올려두므로, 첫 요청보다 이후 요청이 안정적으로 빠릅니다. 맞춤법 검사 기능이 포함된 빌드에서는 어절·띄어쓰기 판별 캐시 덕분에 반복 입력일수록 더 빨라집니다.