응답이 느릴 때

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

분절 단계는 한 번에 80자를 처리하고 더 긴 문장은 나누어 처리하므로, 매우 긴 입력은 분할 처리량이 늘어 시간이 더 걸립니다. 적정 길이의 문장 단위로 보내면 응답이 빨라집니다.

GPU로 설정했어도 실행 프로바이더 초기화에 실패하면 CPU로 폴백되어 가속을 받지 못합니다. 기동 로그에 폴백 경고가 없는지, GPU 사용률이 올라가는지 확인하세요. 폴백됐다면 GPU 드라이버·CUDA·cuDNN·ONNX 런타임 호환을 점검해야 합니다.

정상입니다. 바른은 모델과 사전을 기동 시 미리 메모리에 올려두므로 첫 요청보다 이후 요청이 안정적으로 빠릅니다. 맞춤법 검사 기능이 포함된 빌드에서는 어절·띄어쓰기 판별 결과가 캐시되어, 반복 입력일수록 LLM 호출이 줄어 응답이 더 빨라집니다.

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

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

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

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

실행 프로바이더를 확인하세요. GPU 환경이면 executionProvider가 gpu인지, 그리고 실제로 GPU로 도는지 보세요. CPU로 폴백됐다면 가속을 못 받습니다(GPU 폴백 참고).
입력 길이를 점검하세요. 분절(Segmenter)은 한 번에 80자를 처리하고, 더 긴 문장은 나누어 처리합니다. 지나치게 긴 입력은 분할 처리량이 늘어 느려질 수 있어요. 적정 길이로 잘라 보내면 응답이 빨라집니다.
한 요청의 문장 수를 조절하세요. 한꺼번에 너무 많은 문장을 보내면 처리 시간이 누적됩니다. 대량 처리라면 적당한 단위로 나누어 보내세요.
교정의 LLM 사용을 확인하세요(맞춤법 검사 빌드). 맞춤법 검사는 어려운 어절을 LLM으로 폴백합니다. 외부 API 지연이 응답에 직접 반영되니, 느리다면 LLM rate-limit/타임아웃 문서의 동시 요청 수·타임아웃·캐시 설정을 점검하세요.
반복 입력은 캐시를 활용하세요(맞춤법 검사 빌드). 같은 어절·띄어쓰기 판별은 캐시되어 재호출을 줄입니다. 반복이 많은 워크로드일수록 효과가 큽니다.

빠른 진단 순서

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

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

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

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

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

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

도움이 되었나요?