대부분의 스마트폰 앱보다 작은 모델로 복잡한 PDF, 테이블, 수식에서 텍스트를 추출할 수 있다면 어떨까요? GLM-OCR은 단 0.9억 개의 매개변수로 최첨단 문서 이해를 달성합니다. 평범한 하드웨어에서도 실행될 만큼 가벼우면서도 OmniDocBench V1.5 리더보드에서 94.62점으로 최고를 기록할 만큼 정확합니다.
기존 OCR 도구는 문서 구조 처리에서 어려움을 겪습니다. 테이블 서식을 손상시키고, 수학 수식을 잘못 읽으며, 다중 열 레이아웃에서 실패합니다. 클라우드 API는 이러한 문제를 해결하지만 요청당 비용을 청구하고 민감한 문서를 제3자 서버로 보냅니다. GLM-OCR은 두 가지 문제를 모두 해결합니다. 상업적 사용을 위한 라이선스 비용 없이 MIT 라이선스 하에 프로덕션 수준의 정확도로 복잡한 레이아웃을 로컬에서 처리합니다.
GLM-OCR 아키텍처 이해
GLM-OCR은 문서 이해에 최적화된 세 가지 구성 요소의 인코더-디코더 아키텍처를 사용합니다. CogViT 시각 인코더는 수십억 개의 이미지-텍스트 쌍으로 사전 학습된 가중치를 사용하여 문서 이미지를 처리합니다. 레이아웃 이해에 중요한 공간 관계를 보존하면서 시각적 특징을 추출합니다.
경량 크로스모달 커넥터가 인코더와 디코더 사이에 위치합니다. 이 구성 요소는 시각적 토큰을 효율적으로 다운샘플링하여 정확성을 희생하지 않고 계산 오버헤드를 줄입니다. GLM-0.5B 언어 디코더는 일반 단락부터 복잡한 중첩 테이블에 이르기까지 모든 것을 처리하는 구조화된 텍스트 출력을 생성합니다.
이 모델은 2단계 추론 파이프라인을 사용합니다. 첫째, PP-DocLayout-V3는 문서 구조(헤더, 단락, 테이블, 그림 식별)를 분석합니다. 둘째, 병렬 인식은 각 영역을 동시에 처리합니다. 이 접근 방식은 기존 OCR이 모든 것을 비구조화된 텍스트로 평면화하는 것과 달리 문서 계층 구조를 유지합니다.
훈련 혁신은 성능을 더욱 향상시킵니다. 다중 토큰 예측 손실은 여러 토큰을 동시에 예측하여 훈련 효율성을 향상시킵니다. 안정적인 전체 작업 강화 학습은 다양한 문서 유형에 대한 일반화 능력을 강화합니다. 결과: 수식 인식에서 96.5%, 테이블 인식에서 86.0%의 정확도를 달성하며 정보 추출 작업에서 선도적인 성능을 보입니다.
추론 시 GLM-OCR은 단일 GPU에서 초당 1.86개의 PDF 페이지를 처리합니다. 이는 비교 가능한 모델보다 훨씬 빠릅니다. 0.9억 개의 매개변수 수는 엔터프라이즈 클러스터 대신 소비자 하드웨어에 배포할 수 있음을 의미합니다.
모델 사양
GLM-OCR은 최대 8K 해상도(7680×4320 픽셀)의 문서를 처리합니다. 영어, 중국어, 일본어, 한국어를 포함한 8개 언어를 인식합니다. 이 모델은 래스터 이미지(PNG, JPEG)와 벡터 입력 모두를 처리합니다. 일반적인 추론은 FP16 정밀도에서 4-6GB VRAM을 소비하며, RTX 3060과 같은 소비자 GPU 또는 AWS g4dn.xlarge와 같은 클라우드 인스턴스에 적합합니다.
> | 하드웨어 | 필요 VRAM | 페이지/초 | 사용 사례 |
--------------------------------------------------------------------
> | RTX 3060 | 4-6GB | ~1.5 | 개발 |
> | RTX 4090 | 4-6GB | ~2.5 | 프로덕션 |
> | AWS g4dn.xlarge | 16GB | ~1.8 | 클라우드 배포 |
> | 4x A100 (TPS=4) | 80GB | ~7.0 | 엔터프라이즈 |로컬 배포 옵션
GLM-OCR은 인프라 및 성능 요구 사항에 따라 네 가지 배포 방법을 지원합니다. 각 방법은 Hugging Face의 동일한 기본 모델 가중치를 사용하지만, 다양한 시나리오에 최적화되어 있습니다.
- vLLM은 프로덕션 워크로드에 대한 처리량과 지연 시간의 최상의 균형을 제공합니다. 효율적인 메모리 관리를 위한 PagedAttention을 구현하고 높은 동시성 시나리오를 위한 연속 배칭을 지원합니다.
- SGLang은 런타임 최적화를 통해 최대 성능을 제공합니다. 추론 속도가 가장 빨라야 할 때 투기적 디코딩 및 구조화된 생성에 탁월합니다.
- Ollama는 가장 간단한 설정을 제공합니다. 하나의 명령으로 모델을 로컬에 다운로드하고 실행합니다. Python 종속성이나 구성 파일이 필요 없습니다. 프로토타이핑 및 개인 사용에 적합합니다.
- Transformers는 직접적인 Python 통합을 가능하게 합니다. 개발, 디버깅 또는 추론 파이프라인에 대한 세밀한 제어가 필요할 때 사용하십시오.
모든 방법은 Hugging Face의 GLM-OCR 가중치(zai-org/GLM-OCR)를 필요로 합니다. 이 모델은 CUDA를 지원하는 NVIDIA GPU에서 실행됩니다. CPU 전용 추론도 가능하지만, 속도가 현저히 느려집니다.
프로덕션을 위한 vLLM 설정
vLLM은 OpenAI 호환 API 엔드포인트를 통해 프로덕션 준비가 된 추론을 제공합니다. 이를 통해 GLM-OCR을 현재 OpenAI의 비전 모델을 사용하는 기존 애플리케이션에 교체할 수 있습니다.
설치
CUDA 지원 vLLM 설치:
pip install -U vllm --extra-index-url https://wheels.vllm.ai/nightly
컨테이너화된 배포의 경우, 공식 Docker 이미지를 사용하십시오:
docker pull vllm/vllm-openai:nightly
호환 가능한 Transformers 설치 — vLLM은 GLM-OCR 지원을 위해 최신 개발 버전을 필요로 합니다:
pip install git+https://github.com/huggingface/transformers.git
서비스 시작
GLM-OCR로 vLLM 서버 시작:
vllm serve zai-org/GLM-OCR \
--allowed-local-media-path / \
--port 8080 \
--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'
--allowed-local-media-path 플래그는 모델이 로컬 이미지 파일에 접근할 수 있도록 합니다. 이를 문서 디렉터리 또는 제한 없는 접근을 위해 /로 설정하십시오 (프로덕션 환경에서는 주의해서 사용).
--speculative-config는 GLM-OCR의 기능인 다중 토큰 예측(Multi-Token Prediction)을 활성화하여 여러 토큰을 동시에 예측함으로써 추론 속도를 높입니다.
클라이언트 통합
실행 중일 때, 표준 HTTP 요청을 통해 GLM-OCR과 상호 작용합니다:
curl --location --request POST 'http://localhost:8080/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data-raw '{
"model": "zai-org/GLM-OCR",
"messages": [
{
"role": "user",
"content": [
{"type": "image_url", "image_url": {"url": "file:///path/to/document.png"}},
{"type": "text", "text": "Extract all text from this document"}
]
}
]
}'
OpenAI 호환 응답 형식은 기존 SDK가 수정 없이 작동한다는 것을 의미합니다. OpenAI 클라이언트를 http://localhost:8080으로 지정하고 zai-org/GLM-OCR을 모델 이름으로 사용하십시오.
프로덕션 구성
높은 처리량 배포를 위해 여러 GPU에 걸쳐 텐서 병렬 처리를 추가하십시오:
vllm serve zai-org/GLM-OCR \
--tensor-parallel-size 4 \
--gpu-memory-utilization 0.95 \
--max-model-len 8192 \
--allowed-local-media-path / \
--port 8080
--tensor-parallel-size를 GPU 수에 맞게 조정하십시오. GPU 사용률을 모니터링하고 배치 크기를 늘려 처리량을 극대화하십시오.
모니터링 및 확장
vLLM 성능을 내장된 /metrics 지표 엔드포인트를 통해 추적하십시오. Prometheus 호환 데이터에는 요청 지연 시간, 큐 깊이 및 GPU 사용률이 포함됩니다. 큐 깊이가 10개 요청을 초과하거나 GPU 메모리가 90%에 도달할 때 경고를 설정하십시오. 수평 확장을 위해 로드 밸런서 뒤에 여러 vLLM 인스턴스를 배포하여 스티키 세션을 통해 요청 간 컨텍스트를 유지하십시오.
모델 성능과 함께 프로덕션 지표를 추적하려면 **Apidog의 API 모니터링 기능** 사용을 고려하십시오.
SGLang 고성능 추론
SGLang은 최대 추론 속도를 위한 고급 런타임 최적화를 제공합니다. 투기적 디코딩 및 구조화된 생성에 탁월하여 대기 시간에 민감한 애플리케이션에 이상적입니다.
설치
Docker를 통해 SGLang 설치 (종속성 격리에 권장):
docker pull lmsysorg/sglang:dev
또는 소스에서 설치:
pip install git+https://github.com/sgl-project/sglang.git#subdirectory=python
호환 가능한 Transformers 설치:
pip install git+https://github.com/huggingface/transformers.git
서비스 시작
최적화된 투기적 디코딩으로 SGLang 시작:
python -m sglang.launch_server \
--model zai-org/GLM-OCR \
--port 8080 \
--speculative-algorithm NEXTN \
--speculative-num-steps 3 \
--speculative-eagle-topk 1 \
--speculative-num-draft-tokens 4
투기적 디코딩 매개변수는 여러 토큰을 동시에 초안 작성하고 병렬로 검증하여 추론 속도를 높입니다. --speculative-num-steps는 하드웨어에 따라 조정하십시오. 값이 높을수록 속도는 빨라지지만 더 많은 메모리가 필요합니다.
구조화된 출력
SGLang의 구조화된 생성은 GLM-OCR이 유효한 JSON 또는 다른 스키마를 출력하도록 보장합니다:
import sglang as sgl
@sgl.function
def extract_invoice(s, image_path):
s += sgl.user(sgl.image(image_path) + "Extract invoice data as JSON")
s += sgl.assistant(sgl.gen("json_output", json_schema={
"type": "object",
"properties": {
"invoice_number": {"type": "string"},
"date": {"type": "string"},
"total": {"type": "number"},
"items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": {"type": "string"},
"quantity": {"type": "integer"},
"price": {"type": "number"}
}
}
}
}
}))
result = extract_invoice.run(image_path="invoice.png")
print(result["json_output"])
이는 사후 처리 또는 재시도 로직 없이 기계 판독 가능한 출력을 보장합니다. 구조화된 응답을 제공하는 API 엔드포인트의 경우, Apidog의 스키마 유효성 검사는 출력 형식이 예상 JSON 구조와 일치하는지 자동으로 확인할 수 있습니다.
vLLM 대신 SGLang을 선택해야 할 때
구조화된 출력 또는 투기적 디코딩이 필요할 때 SGLang을 선택하십시오. SGLang의 정규식 제한 생성은 유효한 JSON 스키마를 보장하여 재시도 로직을 제거합니다. 투기적 알고리즘은 충분한 메모리를 가진 GPU에서 토큰 생성 속도를 30-40% 가속화합니다.
> | 기능 | vLLM | SGLang |
---------------------------------------------------------------
> | 처리량 | 높음 | 매우 높음 |
> | 지연 시간 | 좋음 | 탁월함 |
> | OpenAI 호환 | 예 | 아니요 |
> | 구조화된 출력 | 수동 | 내장 |
> | 커뮤니티 지원 | 탁월함 | 성장 중 |
> | 설정 복잡성 | 중간 | 높음 |
> | 최적 사용처 | 프로덕션 API | 속도에 민감한 앱 |엄격한 지연 시간 요구 사항이 없는 표준 OCR의 경우, vLLM은 더 간단한 구성과 더 나은 커뮤니티 지원으로 충분한 성능을 제공합니다.
Transformers 직접 통합
개발, 디버깅 또는 사용자 지정 파이프라인의 경우 Transformers 라이브러리를 직접 사용하십시오. 이는 vLLM 또는 SGLang에 비해 낮은 처리량의 대가로 최대의 유연성을 제공합니다.
설치
최신 Transformers를 소스에서 설치:
pip install git+https://github.com/huggingface/transformers.git
기본 추론
Python에서 GLM-OCR 로드 및 실행:
from transformers import AutoProcessor, AutoModelForImageTextToText
import torch
MODEL_PATH = "zai-org/GLM-OCR"
# Prepare input
messages = [
{
"role": "user",
"content": [
{"type": "image", "url": "document.png"},
{"type": "text", "text": "Text Recognition:"}
],
}
]
# Load model and processor
processor = AutoProcessor.from_pretrained(MODEL_PATH)
model = AutoModelForImageTextToText.from_pretrained(
MODEL_PATH,
torch_dtype="auto",
device_map="auto",
)
# Process input
inputs = processor.apply_chat_template(
messages,
tokenize=True,
add_generation_prompt=True,
return_dict=True,
return_tensors="pt"
).to(model.device)
inputs.pop("token_type_ids", None)
# Generate output
generated_ids = model.generate(**inputs, max_new_tokens=8192)
output_text = processor.decode(
generated_ids[0][inputs["input_ids"].shape[1]:],
skip_special_tokens=False
)
print(output_text)
device_map="auto"는 사용 가능한 GPU에 모델 레이어를 자동으로 분산합니다. 단일 GPU 배포의 경우, 전체 모델을 하나의 장치에 로드합니다. CPU 전용 추론의 경우 device_map="cpu"로 변경하십시오. 성능이 현저히 느려질 것으로 예상됩니다.
배치 처리
여러 문서를 효율적으로 처리:
import os
from pathlib import Path
def batch_process(directory, output_file):
documents = list(Path(directory).glob("*.png")) + \
list(Path(directory).glob("*.pdf"))
results = []
for doc_path in documents:
# Convert PDF to images if needed
if doc_path.suffix == ".pdf":
images = convert_pdf_to_images(doc_path)
else:
images = [doc_path]
for image in images:
text = extract_text(image) # Your extraction function
results.append({
"file": str(doc_path),
"page": image.page_num if hasattr(image, 'page_num') else 1,
"text": text
})
# Save results
with open(output_file, 'w') as f:
json.dump(results, f, indent=2)
# Usage
batch_process("./invoices/", "extracted_data.json")
프로덕션에서 문서를 처리할 때, Apidog의 워크스페이스 관리는 여러 문서 처리 엔드포인트를 논리적인 그룹으로 구성하여 다양한 워크플로우를 테스트하고 모니터링하기 쉽게 돕습니다.
메모리 최적화
VRAM이 제한된 GPU의 경우 양자화를 사용하십시오:
from transformers import BitsAndBytesConfig
quantization_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_compute_dtype=torch.float16
)
model = AutoModelForImageTextToText.from_pretrained(
MODEL_PATH,
quantization_config=quantization_config,
device_map="auto",
)
4비트 양자화는 문서 이해 작업에서 정확도에 미치는 영향을 최소화하면서 메모리 사용량을 75% 절감합니다.
엣지 케이스 처리
필체가 많거나 기울기 각도가 심한 문서는 정확도를 떨어뜨립니다. GLM-OCR로 보내기 전에 디스큐잉 알고리즘으로 이미지를 전처리하십시오. 여러 페이지로 된 PDF의 경우, 전체 파일을 전달하는 대신 페이지를 별도의 이미지로 추출하십시오. 이는 개별 페이지가 실패할 때 병렬 처리를 가능하게 하고 오류 처리를 단순화합니다. 워터마크가 있는 문서는 때때로 텍스트 영역에서 오탐(false positive)을 유발할 수 있습니다. 특정 영역에서 왜곡된 출력이 보이면 대비 조정을 시도해 보십시오.
실제 GLM-OCR 사용 사례
GLM-OCR은 여러 프로덕션 시나리오에서 뛰어난 성능을 발휘합니다:
청구서 처리
재무 팀은 스캔된 청구서에서 항목, 날짜 및 총액을 추출합니다. 이 모델은 테이블 구조를 유지하여 수동 검토 없이 정확한 총액 계산을 보장합니다. 로컬 배포와 API 비용 없이 하루에 수천 건의 청구서를 처리하십시오.
기술 문서
엔지니어링 팀은 PDF 매뉴얼과 사양을 검색 가능한 텍스트로 변환합니다. 수식 인식을 통해 수학 방정식을 보존하여 기술 콘텐츠를 기계 판독 가능하게 만듭니다. 레거시 문서 현대화 프로젝트에 이상적입니다.
법률 문서 분석
법률 전문가는 문서 계층 구조를 존중하는 OCR로 계약 및 합의서를 검토합니다. 다중 열 레이아웃 처리는 단락이 잘못 병합되지 않도록 보장합니다. 개인 정보 보호 우선 접근 방식은 민감한 데이터를 온프레미스에 유지합니다.
의료 기록
의료 기관은 환자 양식 및 처방전을 디지털화합니다. 8개 언어를 인식하여 다국어 의료 환경에 유용합니다. 로컬 배포는 데이터를 내부적으로 유지함으로써 HIPAA 규정 준수 요구 사항을 충족합니다.
결론
GLM-OCR은 0.9억 개의 매개변수 패키지로 프로덕션 수준의 문서 이해를 제공합니다. 이를 로컬에 배포하고, 데이터 개인 정보 보호를 유지하며, 요청당 비용 없이 클라우드 API에 필적하는 처리량을 달성할 수 있습니다. 이 아키텍처는 기존 OCR이 놓치는 복잡한 레이아웃, 테이블 및 수식을 처리하며, MIT 라이선스는 무제한 상업적 사용을 허용합니다.
높은 처리량과 OpenAI 호환성이 필요한 프로덕션 배포에는 vLLM을 선택하십시오. 최대 추론 속도가 중요할 때는 SGLang을 사용하십시오. 개발 및 사용자 지정 파이프라인에는 Transformers를 선택하십시오. 각 옵션은 동일한 기본 모델을 실행하므로 재훈련이나 재조정 없이 배포 방법을 전환할 수 있습니다.
청구서에서 데이터를 추출하거나, 기술 문서를 파싱하거나, 양식 처리를 자동화하는 등 문서 처리 파이프라인을 구축할 때, Apidog로 API 테스트를 간소화하십시오. Apidog는 시각적 요청 구성, 자동 문서 생성 및 협업 디버깅 도구를 제공하여 GLM-OCR 배포 워크플로우를 보완합니다.