응답이 느릴 때

Q: 바른 응답이 느릴 때 가장 먼저 점검할 것은 무엇인가요?

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

Q: 입력 문장이 길면 분석이 느려지나요?

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

Q: GPU로 설정했는데도 바른 응답이 빠르지 않아요.

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

Q: 첫 요청만 느리고 이후 요청은 빠른데 정상인가요?

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

Q: What are the main causes of slow response times in Bareun?

Check five things in order: whether the execution provider silently fell back from GPU to CPU, input length (segmentation processes 80 characters at a time, so very long text gets split into more chunks), the number of sentences per request, and for spell-check builds, LLM fallback latency and whether repeated input is benefiting from the correction cache. Working through this list from GPU fallback down to LLM settings narrows the cause quickly.

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

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

증상

형태소 분석 또는 맞춤법 교정 응답 시간이 깁니다.
어떤 요청은 빠른데 특정 입력만 느립니다.
GPU를 설정했는데도 기대만큼 빠르지 않습니다.

원인

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

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

해결 — 점검할 5가지

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

빠른 진단 순서

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

예방·팁

형태소 분석은 모델·사전을 기동 시 미리 올려두므로, 첫 요청보다 이후 요청이 안정적으로 빠릅니다.
입력을 자연스러운 문장 단위로 보내면 분할 오버헤드를 줄일 수 있습니다.

자주 묻는 질문

Q. 응답이 느릴 때 가장 먼저 무엇을 보나요?

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

Q. 입력이 길면 왜 느려지나요?

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

Q. 맞춤법 검사가 형태소 분석보다 느린 이유는?

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

Q. GPU를 설정했는데도 빠르지 않아요.

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

Q. 첫 요청만 느리고 이후가 빨라요. 정상인가요?

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

도움이 되었나요?