Điều gì sẽ xảy ra nếu bạn có thể trích xuất văn bản từ các tệp PDF, bảng và công thức phức tạp bằng một mô hình nhỏ hơn hầu hết các ứng dụng trên điện thoại thông minh? GLM-OCR đạt được khả năng hiểu tài liệu tiên tiến với chỉ 0,9 tỷ tham số. Nó đủ nhẹ để chạy trên phần cứng khiêm tốn nhưng đủ chính xác để đứng đầu bảng xếp hạng OmniDocBench V1.5 với 94,62 điểm.
Các công cụ OCR truyền thống gặp khó khăn với cấu trúc tài liệu. Chúng làm mất định dạng bảng, đọc sai các công thức toán học và không xử lý được các bố cục nhiều cột. Các API đám mây giải quyết những vấn đề này nhưng tính phí theo mỗi yêu cầu và gửi tài liệu nhạy cảm của bạn đến các máy chủ của bên thứ ba. GLM-OCR loại bỏ cả hai vấn đề này: nó xử lý các bố cục phức tạp cục bộ với độ chính xác cấp độ sản xuất, tất cả đều theo giấy phép MIT cho phép sử dụng thương mại mà không cần phí cấp phép.
Tìm hiểu Kiến trúc GLM-OCR
GLM-OCR sử dụng kiến trúc mã hóa-giải mã ba thành phần được tối ưu hóa để hiểu tài liệu. Bộ mã hóa hình ảnh CogViT xử lý hình ảnh tài liệu bằng cách sử dụng trọng số được đào tạo trước trên hàng tỷ cặp hình ảnh-văn bản. Nó trích xuất các tính năng hình ảnh trong khi vẫn giữ các mối quan hệ không gian quan trọng để hiểu bố cục.
Một bộ kết nối đa phương thức nhẹ nằm giữa bộ mã hóa và bộ giải mã. Thành phần này lấy mẫu xuống các token hình ảnh một cách hiệu quả, giảm chi phí tính toán mà không làm giảm độ chính xác. Bộ giải mã ngôn ngữ GLM-0.5B sau đó tạo ra đầu ra văn bản có cấu trúc, xử lý mọi thứ từ đoạn văn bản thuần túy đến các bảng lồng ghép phức tạp.
Mô hình sử dụng một pipeline suy luận hai giai đoạn. Đầu tiên, PP-DocLayout-V3 phân tích cấu trúc tài liệu—xác định tiêu đề, đoạn văn, bảng và hình ảnh. Thứ hai, quá trình nhận dạng song song xử lý đồng thời từng vùng. Cách tiếp cận này duy trì hệ thống phân cấp tài liệu, nơi OCR truyền thống làm phẳng mọi thứ thành văn bản không có cấu trúc.
Các đổi mới trong đào tạo tiếp tục nâng cao hiệu suất. Mất mát dự đoán đa token (multi-token prediction loss) cải thiện hiệu quả đào tạo bằng cách dự đoán nhiều token đồng thời. Học tăng cường toàn nhiệm vụ ổn định (stable full-task reinforcement learning) nâng cao khả năng khái quát hóa trên các loại tài liệu đa dạng. Kết quả: độ chính xác 96,5% trong nhận dạng công thức, 86,0% trong nhận dạng bảng và hiệu suất hàng đầu trong các tác vụ trích xuất thông tin.
Khi suy luận, GLM-OCR xử lý 1,86 trang PDF mỗi giây trên một GPU duy nhất—nhanh hơn đáng kể so với các mô hình tương đương. Số lượng tham số 0,9 tỷ có nghĩa là bạn triển khai trên phần cứng tiêu dùng thay vì các cụm doanh nghiệp.
Thông số kỹ thuật mô hình
GLM-OCR xử lý các tài liệu có độ phân giải lên đến 8K (7680×4320 pixel). Nó nhận dạng 8 ngôn ngữ bao gồm tiếng Anh, tiếng Trung, tiếng Nhật và tiếng Hàn. Mô hình xử lý cả hình ảnh raster (PNG, JPEG) và đầu vào vector. Suy luận điển hình tiêu thụ 4-6GB VRAM ở độ chính xác FP16, phù hợp với các GPU tiêu dùng như RTX 3060 hoặc các phiên bản đám mây như AWS g4dn.xlarge.
> | Hardware | VRAM Required | Pages/sec | Use Case |
--------------------------------------------------------------------
> | RTX 3060 | 4-6GB | ~1.5 | Development |
> | RTX 4090 | 4-6GB | ~2.5 | Production |
> | AWS g4dn.xlarge | 16GB | ~1.8 | Cloud deployment |
> | 4x A100 (TPS=4) | 80GB | ~7.0 | Enterprise |Các tùy chọn triển khai cục bộ
GLM-OCR hỗ trợ bốn phương pháp triển khai tùy thuộc vào cơ sở hạ tầng và yêu cầu hiệu suất của bạn. Mỗi phương pháp sử dụng cùng một trọng số mô hình cơ bản từ Hugging Face nhưng được tối ưu hóa cho các kịch bản khác nhau.
- vLLM cung cấp sự cân bằng tốt nhất về thông lượng và độ trễ cho các tác vụ sản xuất. Nó triển khai PagedAttention để quản lý bộ nhớ hiệu quả và hỗ trợ batching liên tục cho các kịch bản đồng thời cao.
- SGLang cung cấp hiệu suất tối đa thông qua tối ưu hóa thời gian chạy của nó. Nó vượt trội trong giải mã suy đoán và tạo có cấu trúc, làm cho nó lý tưởng khi bạn cần suy luận nhanh nhất có thể.
- Ollama mang lại thiết lập đơn giản nhất. Một lệnh duy nhất tải xuống và chạy mô hình cục bộ—không có phụ thuộc Python hay tệp cấu hình. Hoàn hảo cho việc tạo mẫu và sử dụng cá nhân.
- Transformers cho phép tích hợp Python trực tiếp. Sử dụng cái này để phát triển, gỡ lỗi hoặc khi bạn cần kiểm soát chi tiết pipeline suy luận.
Tất cả các phương pháp đều yêu cầu trọng số GLM-OCR từ Hugging Face (zai-org/GLM-OCR). Mô hình chạy trên NVIDIA GPU với hỗ trợ CUDA. Suy luận chỉ bằng CPU vẫn hoạt động nhưng với tốc độ giảm đáng kể.
Thiết lập vLLM cho Sản xuất
vLLM cung cấp suy luận sẵn sàng cho sản xuất với các điểm cuối API tương thích OpenAI. Điều này cho phép bạn hoán đổi GLM-OCR vào các ứng dụng hiện có đang sử dụng các mô hình thị giác của OpenAI.
Cài đặt
Cài đặt vLLM với hỗ trợ CUDA:
pip install -U vllm --extra-index-url https://wheels.vllm.ai/nightly
Đối với triển khai đóng gói (containerized deployment), sử dụng hình ảnh Docker chính thức:
docker pull vllm/vllm-openai:nightly
Cài đặt Transformers tương thích—vLLM yêu cầu phiên bản phát triển mới nhất để hỗ trợ GLM-OCR:
pip install git+https://github.com/huggingface/transformers.git
Khởi chạy Dịch vụ
Khởi động máy chủ vLLM với GLM-OCR:
vllm serve zai-org/GLM-OCR \
--allowed-local-media-path / \
--port 8080 \
--speculative-config '{"method": "mtp", "num_speculative_tokens": 1}'
Cờ --allowed-local-media-path cho phép mô hình truy cập các tệp hình ảnh cục bộ. Đặt giá trị này thành thư mục tài liệu của bạn hoặc / để truy cập không hạn chế (sử dụng thận trọng trong sản xuất).
Cờ --speculative-config cho phép Dự đoán đa token (Multi-Token Prediction), một tính năng của GLM-OCR giúp tăng tốc suy luận bằng cách dự đoán nhiều token đồng thời.
Tích hợp Client
Khi đang chạy, tương tác với GLM-OCR thông qua các yêu cầu HTTP tiêu chuẩn:
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"}
]
}
]
}'
Định dạng phản hồi tương thích OpenAI có nghĩa là các SDK hiện có hoạt động mà không cần sửa đổi. Trỏ client OpenAI của bạn tới http://localhost:8080 và sử dụng zai-org/GLM-OCR làm tên mô hình.
Cấu hình Sản xuất
Đối với các triển khai thông lượng cao, hãy thêm song song tensor trên nhiều 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
Điều chỉnh --tensor-parallel-size để phù hợp với số lượng GPU của bạn. Giám sát việc sử dụng GPU và tăng kích thước lô (batch sizes) để tối đa hóa thông lượng.
Giám sát và Mở rộng
Theo dõi hiệu suất vLLM thông qua điểm cuối đo lường tích hợp của nó tại /metrics. Dữ liệu tương thích Prometheus bao gồm độ trễ yêu cầu, độ sâu hàng đợi và mức sử dụng GPU. Thiết lập cảnh báo khi độ sâu hàng đợi vượt quá 10 yêu cầu hoặc bộ nhớ GPU đạt 90%. Để mở rộng theo chiều ngang (horizontal scaling), triển khai nhiều phiên bản vLLM phía sau bộ cân bằng tải (load balancer) với sticky sessions để duy trì ngữ cảnh giữa các yêu cầu.
Hãy cân nhắc sử dụng các tính năng giám sát API của Apidog để theo dõi các số liệu sản xuất cùng với hiệu suất mô hình của bạn.
Suy luận Hiệu suất cao của SGLang
SGLang cung cấp các tối ưu hóa thời gian chạy nâng cao để đạt tốc độ suy luận tối đa. Nó vượt trội trong giải mã suy đoán (speculative decoding) và tạo có cấu trúc (structured generation), làm cho nó lý tưởng cho các ứng dụng nhạy cảm về độ trễ.
Cài đặt
Cài đặt SGLang thông qua Docker (được khuyến nghị để cô lập phụ thuộc):
docker pull lmsysorg/sglang:dev
Hoặc cài đặt từ mã nguồn:
pip install git+https://github.com/sgl-project/sglang.git#subdirectory=python
Cài đặt Transformers tương thích:
pip install git+https://github.com/huggingface/transformers.git
Khởi chạy Dịch vụ
Khởi động SGLang với giải mã suy đoán được tối ưu hóa:
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
Các tham số giải mã suy đoán tăng tốc suy luận bằng cách phác thảo nhiều token đồng thời và xác minh chúng song song. Điều chỉnh --speculative-num-steps dựa trên phần cứng của bạn—giá trị cao hơn sẽ tăng tốc độ nhưng yêu cầu nhiều bộ nhớ hơn.
Đầu ra có cấu trúc
Tính năng tạo có cấu trúc của SGLang đảm bảo GLM-OCR xuất ra JSON hợp lệ hoặc các lược đồ khác:
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"])
Điều này đảm bảo đầu ra có thể đọc được bằng máy mà không cần xử lý hậu kỳ hoặc logic thử lại. Đối với các điểm cuối API cung cấp phản hồi có cấu trúc, xác thực lược đồ của Apidog có thể tự động xác minh các định dạng đầu ra của bạn khớp với cấu trúc JSON mong đợi.
Khi nào chọn SGLang thay vì vLLM
Chọn SGLang khi bạn cần đầu ra có cấu trúc hoặc giải mã suy đoán. Tính năng tạo bị ràng buộc bằng regex của nó đảm bảo các lược đồ JSON hợp lệ, loại bỏ logic thử lại. Thuật toán suy đoán tăng tốc tạo token lên 30-40% trên các GPU có đủ bộ nhớ.
> | Feature | vLLM | SGLang |
---------------------------------------------------------------
> | Throughput | High | Very High |
> | Latency | Good | Excellent |
> | OpenAI Compatible | Yes | No |
> | Structured Output | Manual | Built-in |
> | Community Support | Excellent | Growing |
> | Setup Complexity | Medium | High |
> | Best For | Production APIs | Speed-critical apps |Đối với OCR tiêu chuẩn không có yêu cầu độ trễ nghiêm ngặt, vLLM cung cấp hiệu suất đủ với cấu hình đơn giản hơn và hỗ trợ cộng đồng tốt hơn.
Tích hợp Trực tiếp với Transformers
Để phát triển, gỡ lỗi hoặc các pipeline tùy chỉnh, hãy sử dụng thư viện Transformers trực tiếp. Điều này cung cấp tính linh hoạt tối đa nhưng với chi phí thông lượng thấp hơn so với vLLM hoặc SGLang.
Cài đặt
Cài đặt phiên bản Transformers mới nhất từ mã nguồn:
pip install git+https://github.com/huggingface/transformers.git
Suy luận Cơ bản
Tải và chạy GLM-OCR trong Python:
from transformers import AutoProcessor, AutoModelForImageTextToText
import torch
MODEL_PATH = "zai-org/GLM-OCR"
# Chuẩn bị đầu vào
messages = [
{
"role": "user",
"content": [
{"type": "image", "url": "document.png"},
{"type": "text", "text": "Text Recognition:"}
],
}
]
# Tải mô hình và bộ xử lý
processor = AutoProcessor.from_pretrained(MODEL_PATH)
model = AutoModelForImageTextToText.from_pretrained(
MODEL_PATH,
torch_dtype="auto",
device_map="auto",
)
# Xử lý đầu vào
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)
# Tạo đầu ra
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" tự động phân phối các lớp mô hình trên các GPU có sẵn. Đối với triển khai GPU đơn, điều này tải toàn bộ mô hình lên một thiết bị. Đối với suy luận chỉ bằng CPU, hãy thay đổi thành device_map="cpu"—hãy mong đợi hiệu suất chậm hơn đáng kể.
Xử lý hàng loạt
Xử lý nhiều tài liệu một cách hiệu quả:
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:
# Chuyển đổi PDF sang hình ảnh nếu cần
if doc_path.suffix == ".pdf":
images = convert_pdf_to_images(doc_path)
else:
images = [doc_path]
for image in images:
text = extract_text(image) # Hàm trích xuất của bạn
results.append({
"file": str(doc_path),
"page": image.page_num if hasattr(image, 'page_num') else 1,
"text": text
})
# Lưu kết quả
with open(output_file, 'w') as f:
json.dump(results, f, indent=2)
# Cách sử dụng
batch_process("./invoices/", "extracted_data.json")
Khi xử lý tài liệu trong sản xuất, quản lý không gian làm việc của Apidog giúp sắp xếp nhiều điểm cuối xử lý tài liệu thành các nhóm logic, giúp việc kiểm tra và giám sát các quy trình làm việc khác nhau dễ dàng hơn.
Tối ưu hóa Bộ nhớ
Đối với các GPU có VRAM hạn chế, hãy sử dụng lượng tử hóa:
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",
)
Lượng tử hóa 4-bit giảm 75% mức sử dụng bộ nhớ với tác động tối thiểu đến độ chính xác cho các tác vụ hiểu tài liệu.
Xử lý các trường hợp ngoại lệ
Các tài liệu có chữ viết tay nhiều hoặc góc nghiêng lớn sẽ làm giảm độ chính xác. Tiền xử lý hình ảnh bằng các thuật toán làm thẳng (deskewing) trước khi gửi đến GLM-OCR. Đối với các tệp PDF nhiều trang, hãy trích xuất các trang dưới dạng hình ảnh riêng biệt thay vì truyền toàn bộ tệp. Điều này cho phép xử lý song song và đơn giản hóa việc xử lý lỗi khi các trang riêng lẻ bị lỗi. Các tài liệu có watermark đôi khi gây ra lỗi nhận dạng sai ở các vùng văn bản—hãy thử nghiệm với điều chỉnh độ tương phản nếu bạn thấy đầu ra bị méo ở các khu vực cụ thể.
Các trường hợp sử dụng GLM-OCR trong thực tế
GLM-OCR vượt trội trong một số kịch bản sản xuất:
Xử lý hóa đơn
Các nhóm tài chính trích xuất các mục hàng, ngày tháng và tổng số tiền từ hóa đơn đã quét. Mô hình duy trì cấu trúc bảng, đảm bảo tính toán tổng số tiền chính xác mà không cần xem xét thủ công. Xử lý hàng nghìn hóa đơn mỗi ngày với triển khai cục bộ và không mất phí API.
Tài liệu Kỹ thuật
Các nhóm kỹ sư chuyển đổi sổ tay hướng dẫn và thông số kỹ thuật PDF thành văn bản có thể tìm kiếm. Nhận dạng công thức bảo toàn các phương trình toán học, giúp nội dung kỹ thuật có thể đọc được bằng máy. Lý tưởng cho các dự án hiện đại hóa tài liệu cũ.
Phân tích Tài liệu Pháp lý
Các chuyên gia pháp lý xem xét các hợp đồng và thỏa thuận bằng OCR tôn trọng hệ thống phân cấp tài liệu. Xử lý bố cục nhiều cột đảm bảo các đoạn văn không bị gộp sai. Cách tiếp cận ưu tiên quyền riêng tư giữ dữ liệu nhạy cảm tại chỗ.
Hồ sơ Y tế
Các phòng khám y tế số hóa các biểu mẫu bệnh nhân và đơn thuốc. Nhận dạng 8 ngôn ngữ, hữu ích cho môi trường chăm sóc sức khỏe đa ngôn ngữ. Triển khai cục bộ đáp ứng các yêu cầu tuân thủ HIPAA bằng cách giữ dữ liệu nội bộ.
Kết luận
GLM-OCR cung cấp khả năng hiểu tài liệu cấp độ sản xuất trong một gói tham số 0,9 tỷ. Bạn triển khai nó cục bộ, duy trì quyền riêng tư dữ liệu và đạt được tốc độ thông lượng cạnh tranh với các API đám mây—tất cả mà không phải trả phí cho mỗi yêu cầu. Kiến trúc xử lý các bố cục, bảng và công thức phức tạp mà OCR truyền thống bỏ qua, trong khi giấy phép MIT cho phép sử dụng thương mại không giới hạn.
Chọn vLLM cho các triển khai sản xuất yêu cầu thông lượng cao và khả năng tương thích OpenAI. Sử dụng SGLang khi tốc độ suy luận tối đa là quan trọng. Chọn Transformers để phát triển và các pipeline tùy chỉnh. Mỗi tùy chọn chạy cùng một mô hình cơ bản, vì vậy bạn có thể chuyển đổi phương pháp triển khai mà không cần đào tạo lại hoặc điều chỉnh lại.
Khi xây dựng các pipeline xử lý tài liệu—cho dù là trích xuất dữ liệu từ hóa đơn, phân tích tài liệu kỹ thuật, hay tự động hóa quá trình xử lý biểu mẫu—hãy hợp lý hóa việc kiểm thử API của bạn với Apidog. Nó cung cấp tính năng xây dựng yêu cầu trực quan, tạo tài liệu tự động và các công cụ gỡ lỗi cộng tác bổ sung cho quy trình làm việc triển khai GLM-OCR của bạn.