청구서 읽기용 기본 모델로 어떤 로컬 비전 모델을 출시할까? 내 청구서로 8종 테스트했다
원문 제목 — Which local vision model would you ship as the default for reading invoices? I tested 8 on my own bills
📄 전문 번역
이메일로 받은 청구서를 읽어주는 소형 Mac 앱 판매를 앞두고 있으며, 앱이 기본으로 제안할 로컬 모델을 정해야 한다. 결정을 내리지 못해 자신의 청구서 PDF 19개를 Ollama로 돌려봤다. 페이지 이미지, 동일 프롬프트, thinking 비활성화 조건으로 M4 Pro 48GB 통합 메모리 맥에서 한 번에 한 모델씩 테스트했다. 여섯 필드(청구서 여부, 금액, 마감일, IBAN, 결제 방식, 참조번호)가 모두 맞아야만 성공으로 쳤고, 그중 두 개는 여러 결제가 담긴 PDF였으므로 점수는 17점 만점이다.
qwen3.5:9b는 15/17에 페이지당 약 16초, qwen3-vl:8b-instruct는 15/17에 약 22초, qwen3.5:9b-mxfp8(8비트)은 14/17에 약 25초, qwen3.8:27b-nvfp4는 13/17에 약 41초, qwen2.5vl:7b는 12/17에 약 21초, qwen3.5:4b는 7/17, gemma4:e4b는 4/16(조기 중단)을 기록했다. glm-ocr은 금액과 IBAN은 잘 읽지만 참조번호에 근처의 무관한 텍스트를 섞어 넣었고, qwen3-vl:8b(thinking 빌드)는 thinking을 꺼도 계속 추론하며 청구서당 수 분이 걸렸다.
추론(thinking)이 이번 테스트에서는 큰 걸림돌이었다. 켜자 9B는 한 청구서를 5초 대신 38초에 처리했고, 4B는 토큰을 소진해 아무 결과도 반환하지 못했다.
현재 앱은 qwen3.5:9b를 기본 제안한다. 하지만 15/17은 여전히 두 청구서에서 필드가 틀리거나 빠졌다는 뜻이며 16GB Mac이 필요하다. 이를 기본값으로 출시할 것인가, 아니면 이 크기대에서 청구서를 더 잘 읽는 모델이 있는가. 소규모 테스트, 크로아티아 청구서, Mac 한 대였던 만큼 다른 이용자들의 경험도 듣고 싶다며 상세 내용은 영상으로도 공개했다.
미리 밝히자면 앱은 필자가 만든 Billcalm으로 Mac 전용이며 12월 출시 예정의 유료 일회성 구매 제품이고 오픈소스가 아니다. 이 글은 레딧 사용자 yodin1이 제출했다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
필자는 M4 Pro 48GB 맥에서 자신의 청구서 PDF 19개로 로컬 비전 모델 8종을 비교했고, qwen3.5:9b와 qwen3-vl:8b-instruct가 17점 만점에 15점으로 공동 최고점을 기록했다. 테스트에서 thinking 모드는 속도와 정확도 모두에 부정적이었으며 4B 모델은 토큰 소진으로 결과를 내지 못했다. 댓글에서는 Gemma 4의 기본 이미지 토큰 한도 280이 낮아 OCR 오류를 유발한다는 지적과 함께 한도 상승 시 --ubatch-size 조정이 필요하다는 경험이 공유됐다. 필자는 자신의 유료 Mac 앱 Billcalm의 기본 모델로 qwen3.5:9b를 탑재할지 의견을 묻고 있다.
— 루키 · glm-5.3-flash:cloud
llama-server에서 Gemma 4의 기본 --image-max-tokens(280)은 안정적인 OCR에 너무 낮다는 점을 발견했다. 이 한도에서는 8.5x11 페이지를 토큰화 전에 약 700x900픽셀까지 축소해야 한다. 다만 값을 올리면(560 또는 1120) llama.cpp 크래시를 피하려 --ubatch-size도 같거나 더 크게 올려야 했다. Qwen의 기본 최댓값은 약 4096이라 이 문제를 피할 수 있었겠지만 당시엔 테스트하지 않았다. 추론은 정확도에 도움이 됐지만 필자의 경우 Gemma 4 26B가 이미지당 약 20분이 걸렸다(오래된 32GB PC에서 CPU 전용 실행).
감사하다. Ollama로 Gemma 4 E4B를 사용했으므로 어떤 이미지 설정을 썼는지 확인해야겠다. 이미지 토큰 한도를 올리니 정확도가 눈에 띄게 좋아졌는가. 이 청구서들은 텍스트 레이어가 있어 제안 덕분에 또 다른 테스트를 해볼 수 있다. 동일 청구서에 동일 JSON 필드를 요청해 이미지만, 추출 텍스트만, 둘을 함께 넣는 세 가지를 비교한 뒤 각 출력을 정답과 필드별로 대조해볼 생각이다. 일부 모델이 애먼 결제 참조번호에 텍스트 추가가 도움이 될지 궁금하다.
기본값 280에서는 숫자가 뒤바뀌는 사소하지만 심각한 오류가 나왔다. 1120으로 올리니 오류가 사라졌지만, 당시 llama 웹 UI로 테스트 중이었고 이 UI가 이미지를 약 480토큰 상당으로 축소하고 있었다(Gemma 4 토큰은 48x48픽셀, Qwen은 32x32). 그래서 1120이 아니라 560 품질보다 약간 낮은 수준을 보고 있었고, 스크립트로 이미지를 올리기 전까지 --ubatch-size 문제(기본값에선 512토큰 초과 시 크래시)를 발견하지도 못했다.
토큰 한도에 대한 좋은 분석이다. 내 환경에서 Gemma가 처리에 실패했던 이유가 상당히 설명된다. 전체 페이지에 기본값 280은 우스울 만큼 낮다. qwen3.5:9b가 4096을 쓰는 것이 그렇게 빠른 이유 중 하나다. 내 설정에선 페이지당 16초뿐이었다. 이중 검증 아이디어도 흥미롭다. 여섯 필드 정도엔 과할 수 있지만 엉망인 IBAN을 잘못 읽는 엣지 케이스는 잡아줄 수 있을 것이다.
PDF 읽기 도구가 설치되지 않은 것이 아닌가. PDF의 문제는 읽을 수 있는 형식이라도 컴퓨터가 표 레이아웃을 이해하기 어려울 때가 있다는 점이다.