จะเป็นอย่างไรถ้าคุณสามารถแยกข้อความจากเอกสาร PDF ที่ซับซ้อน ตาราง และสูตรต่างๆ ได้ด้วยโมเดลที่มีขนาดเล็กกว่าแอปพลิเคชันบนสมาร์ทโฟนส่วนใหญ่? GLM-OCR บรรลุความเข้าใจเอกสารระดับแนวหน้าด้วยพารามิเตอร์เพียง 0.9 พันล้านตัว มันมีน้ำหนักเบาพอที่จะทำงานบนฮาร์ดแวร์พื้นฐาน แต่แม่นยำพอที่จะขึ้นอันดับหนึ่งของ OmniDocBench V1.5 ด้วยคะแนน 94.62 คะแนน
เครื่องมือ OCR แบบดั้งเดิมประสบปัญหาเกี่ยวกับโครงสร้างเอกสาร พวกเขาสูญเสียการจัดรูปแบบตาราง, อ่านสูตรทางคณิตศาสตร์ผิดพลาด และทำงานไม่ได้กับเลย์เอาต์หลายคอลัมน์ API บนคลาวด์ช่วยแก้ปัญหาเหล่านี้ได้แต่คิดค่าบริการตามคำขอและส่งเอกสารที่ละเอียดอ่อนของคุณไปยังเซิร์ฟเวอร์ของบุคคลที่สาม GLM-OCR ขจัดปัญหาทั้งสองประการ: จัดการกับเลย์เอาต์ที่ซับซ้อนภายในเครื่องด้วยความแม่นยำระดับการผลิต ทั้งหมดภายใต้ใบอนุญาต MIT ที่อนุญาตให้ใช้งานเชิงพาณิชย์โดยไม่มีค่าธรรมเนียมใบอนุญาต
ทำความเข้าใจสถาปัตยกรรม GLM-OCR
GLM-OCR ใช้สถาปัตยกรรมตัวเข้ารหัส-ตัวถอดรหัสสามส่วนที่ได้รับการปรับแต่งเพื่อความเข้าใจเอกสาร ตัวเข้ารหัสภาพ CogViT ประมวลผลรูปภาพเอกสารโดยใช้น้ำหนักที่ฝึกไว้ล่วงหน้าจากคู่รูปภาพ-ข้อความนับพันล้านคู่ มันแยกคุณลักษณะทางภาพในขณะที่รักษาความสัมพันธ์เชิงพื้นที่ที่สำคัญสำหรับการทำความเข้าใจเลย์เอาต์
ตัวเชื่อมต่อข้ามโมดอลที่มีน้ำหนักเบาจะอยู่ระหว่างตัวเข้ารหัสและตัวถอดรหัส คอมโพเนนต์นี้จะทำการสุ่มตัวอย่างโทเค็นภาพลงอย่างมีประสิทธิภาพ ลดภาระการคำนวณโดยไม่ลดทอนความแม่นยำ จากนั้นตัวถอดรหัสภาษา GLM-0.5B จะสร้างเอาต์พุตข้อความที่มีโครงสร้าง จัดการทุกอย่างตั้งแต่ย่อหน้าธรรมดาไปจนถึงตารางซ้อนที่ซับซ้อน
โมเดลนี้ใช้ไปป์ไลน์การอนุมานสองขั้นตอน ขั้นแรก PP-DocLayout-V3 วิเคราะห์โครงสร้างเอกสาร—ระบุหัวเรื่อง ย่อหน้า ตาราง และรูปภาพ ประการที่สอง การรับรู้แบบขนานจะประมวลผลแต่ละส่วนพร้อมกัน วิธีการนี้รักษาลำดับชั้นของเอกสารในขณะที่ OCR แบบดั้งเดิมจะทำให้ทุกอย่างแบนราบเป็นข้อความที่ไม่มีโครงสร้าง
นวัตกรรมการฝึกอบรมยังช่วยเพิ่มประสิทธิภาพอีกด้วย การสูญเสียการคาดการณ์หลายโทเค็นช่วยเพิ่มประสิทธิภาพการฝึกอบรมโดยการคาดการณ์หลายโทเค็นพร้อมกัน การเรียนรู้แบบเสริมแรงแบบเต็มงานที่เสถียรช่วยเพิ่มความสามารถในการนำไปใช้กับเอกสารประเภทต่างๆ ผลลัพธ์: ความแม่นยำ 96.5% ในการรับรู้สูตร 86.0% ในการรับรู้ตาราง และประสิทธิภาพชั้นนำในงานดึงข้อมูล
ในการอนุมาน GLM-OCR ประมวลผลเอกสาร PDF ได้ 1.86 หน้าต่อวินาทีบน GPU ตัวเดียว—เร็วกว่าโมเดลที่เทียบเคียงได้อย่างมาก จำนวนพารามิเตอร์ 0.9B หมายความว่าคุณสามารถใช้งานบนฮาร์ดแวร์ทั่วไปแทนที่จะเป็นคลัสเตอร์ระดับองค์กร
ข้อมูลจำเพาะของโมเดล
GLM-OCR รองรับเอกสารที่มีความละเอียดสูงสุด 8K (7680×4320 พิกเซล) สามารถจดจำ 8 ภาษา รวมถึงอังกฤษ จีน ญี่ปุ่น และเกาหลี โมเดลนี้ประมวลผลทั้งรูปภาพแรสเตอร์ (PNG, JPEG) และอินพุตเวกเตอร์ การอนุมานโดยทั่วไปใช้ VRAM 4-6GB ที่ความแม่นยำ FP16 ซึ่งสามารถทำงานได้บน GPU สำหรับผู้บริโภค เช่น RTX 3060 หรืออินสแตนซ์คลาวด์ เช่น 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 โดยตรง ใช้สิ่งนี้สำหรับการพัฒนา การดีบัก หรือเมื่อคุณต้องการการควบคุมที่ละเอียดอ่อนเหนือไปป์ไลน์การอนุมาน
ทุกวิธีต้องใช้ GLM-OCR weights จาก Hugging Face (zai-org/GLM-OCR) โมเดลทำงานบน NVIDIA GPUs ที่รองรับ CUDA การอนุมานแบบ CPU เท่านั้นก็สามารถทำได้แต่จะลดความเร็วลงอย่างมาก
การตั้งค่า vLLM สำหรับการผลิต
vLLM ให้การอนุมานพร้อมใช้งานสำหรับการผลิตด้วย API ที่เข้ากันได้กับ OpenAI สิ่งนี้ช่วยให้คุณสามารถเปลี่ยน GLM-OCR เข้าไปในแอปพลิเคชันที่มีอยู่ซึ่งปัจจุบันใช้โมเดลวิชันของ OpenAI ได้
การติดตั้ง
ติดตั้ง vLLM พร้อมรองรับ CUDA:
pip install -U vllm --extra-index-url https://wheels.vllm.ai/nightly
สำหรับการติดตั้งแบบคอนเทนเนอร์ ให้ใช้ Docker image อย่างเป็นทางการ:
docker pull vllm/vllm-openai:nightly
ติดตั้ง Transformers ที่เข้ากันได้—vLLM ต้องการเวอร์ชันการพัฒนาล่าสุดสำหรับการรองรับ GLM-OCR:
pip install git+https://github.com/huggingface/transformers.git
การเปิดใช้งานบริการ
เริ่มเซิร์ฟเวอร์ vLLM ด้วย GLM-OCR:
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 เปิดใช้งาน Multi-Token Prediction ซึ่งเป็นคุณสมบัติของ GLM-OCR ที่ช่วยเร่งการอนุมานโดยการคาดการณ์หลายโทเค็นพร้อมกัน
การผสานรวมกับไคลเอ็นต์
เมื่อทำงานแล้ว คุณสามารถโต้ตอบกับ GLM-OCR ได้ผ่านคำขอ HTTP มาตรฐาน:
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 เป็นชื่อโมเดล
การกำหนดค่าสำหรับการผลิต
สำหรับการติดตั้งใช้งานที่มีปริมาณงานสูง ให้เพิ่ม Tensor Parallelism ใน 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 หลายอินสแตนซ์หลัง Load Balancer ที่มี Sticky Sessions เพื่อรักษาสภาพแวดล้อมข้ามคำขอ
พิจารณาใช้ คุณสมบัติการตรวจสอบ API ของ Apidog เพื่อติดตามเมตริกการผลิตควบคู่ไปกับประสิทธิภาพของโมเดลของคุณ
SGLang การอนุมานประสิทธิภาพสูง
SGLang ให้การปรับแต่งรันไทม์ขั้นสูงเพื่อความเร็วในการอนุมานสูงสุด มันเก่งในการถอดรหัสแบบคาดเดาและการสร้างที่มีโครงสร้าง ทำให้เหมาะอย่างยิ่งสำหรับแอปพลิเคชันที่อ่อนไหวต่อเวลาแฝง
การติดตั้ง
ติดตั้ง SGLang ผ่าน Docker (แนะนำสำหรับการแยกส่วนที่ต้องพึ่งพา):
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 ที่คาดหวังหรือไม่
เมื่อใดควรเลือก SGLang แทน vLLM
เลือก SGLang เมื่อคุณต้องการเอาต์พุตที่มีโครงสร้างหรือการถอดรหัสแบบคาดเดา การสร้างแบบจำกัดด้วย regex รับประกันสคีมา JSON ที่ถูกต้อง ทำให้ไม่จำเป็นต้องใช้ตรรกะการลองใหม่ อัลกอริทึมการคาดเดาช่วยเร่งการสร้างโทเค็นได้ 30-40% บน GPU ที่มีหน่วยความจำเพียงพอ
> | คุณสมบัติ | vLLM | SGLang |
---------------------------------------------------------------
> | ปริมาณงาน | สูง | สูงมาก |
> | เวลาแฝง | ดี | ยอดเยี่ยม |
> | เข้ากันได้กับ OpenAI | ใช่ | ไม่ |
> | เอาต์พุตที่มีโครงสร้าง | กำหนดเอง | ในตัว |
> | การสนับสนุนชุมชน | ยอดเยี่ยม | กำลังเติบโต |
> | ความซับซ้อนในการตั้งค่า | ปานกลาง | สูง |
> | เหมาะสำหรับ | API สำหรับการผลิต | แอปพลิเคชันที่ต้องการความเร็วสูง |สำหรับ OCR มาตรฐานที่ไม่มีข้อกำหนดด้านเวลาแฝงที่เข้มงวด vLLM ให้ประสิทธิภาพที่เพียงพอพร้อมการกำหนดค่าที่ง่ายกว่าและการสนับสนุนชุมชนที่ดีกว่า
การผสานรวม Transformers โดยตรง
สำหรับการพัฒนา การดีบัก หรือไปป์ไลน์ที่กำหนดเอง ให้ใช้ไลบรารี Transformers โดยตรง วิธีนี้ให้ความยืดหยุ่นสูงสุดโดยแลกกับปริมาณงานที่ต่ำกว่าเมื่อเทียบกับ vLLM หรือ SGLang
การติดตั้ง
ติดตั้ง Transformers เวอร์ชันล่าสุดจากแหล่งที่มา:
pip install git+https://github.com/huggingface/transformers.git
การอนุมานพื้นฐาน
โหลดและรัน GLM-OCR ใน Python:
from transformers import AutoProcessor, AutoModelForImageTextToText
import torch
MODEL_PATH = "zai-org/GLM-OCR"
# เตรียมอินพุต
messages = [
{
"role": "user",
"content": [
{"type": "image", "url": "document.png"},
{"type": "text", "text": "Text Recognition:"}
],
}
]
# โหลดโมเดลและโปรเซสเซอร์
processor = AutoProcessor.from_pretrained(MODEL_PATH)
model = AutoModelForImageTextToText.from_pretrained(
MODEL_PATH,
torch_dtype="auto",
device_map="auto",
)
# ประมวลผลอินพุต
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)
# สร้างเอาต์พุต
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:
# แปลง PDF เป็นรูปภาพหากจำเป็น
if doc_path.suffix == ".pdf":
images = convert_pdf_to_images(doc_path)
else:
images = [doc_path]
for image in images:
text = extract_text(image) # ฟังก์ชันการแยกข้อมูลของคุณ
results.append({
"file": str(doc_path),
"page": image.page_num if hasattr(image, 'page_num') else 1,
"text": text
})
# บันทึกผลลัพธ์
with open(output_file, 'w') as f:
json.dump(results, f, indent=2)
# การใช้งาน
batch_process("./invoices/", "extracted_data.json")
เมื่อประมวลผลเอกสารในการผลิต การจัดการพื้นที่ทำงานของ Apidog ช่วยจัดระเบียบปลายทางประมวลผลเอกสารหลายรายการให้เป็นกลุ่มเชิงตรรกะ ทำให้ง่ายต่อการทดสอบและตรวจสอบเวิร์กโฟลว์ที่แตกต่างกัน
การเพิ่มประสิทธิภาพหน่วยความจำ
สำหรับ GPU ที่มี VRAM จำกัด ให้ใช้ Quantization:
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",
)
การ Quantization 4 บิตช่วยลดการใช้หน่วยความจำได้ 75% โดยมีผลกระทบต่อความแม่นยำน้อยที่สุดสำหรับงานความเข้าใจเอกสาร
การจัดการกรณีพิเศษ
เอกสารที่มีลายมือเขียนมากหรือมีมุมเอียงมากจะลดความแม่นยำลง ควรประมวลผลรูปภาพด้วยอัลกอริทึมการปรับเอียง (deskewing) ก่อนส่งไปยัง GLM-OCR สำหรับ PDF หลายหน้า ให้แยกแต่ละหน้าเป็นรูปภาพแยกกัน แทนที่จะส่งไฟล์ทั้งหมด วิธีนี้ช่วยให้สามารถประมวลผลแบบขนานและลดความซับซ้อนในการจัดการข้อผิดพลาดเมื่อแต่ละหน้าล้มเหลว เอกสารที่มีลายน้ำบางครั้งอาจทำให้เกิดผลบวกปลอมในบริเวณข้อความ—ลองปรับคอนทราสต์หากพบเอาต์พุตที่บิดเบี้ยวในบางพื้นที่
กรณีการใช้งาน GLM-OCR ในโลกจริง
GLM-OCR โดดเด่นในสถานการณ์การผลิตหลายประการ:
การประมวลผลใบแจ้งหนี้
ทีมการเงินจะแยกรายการบรรทัด วันที่ และยอดรวมจากใบแจ้งหนี้ที่สแกน โมเดลยังคงรักษาโครงสร้างตาราง เพื่อให้มั่นใจว่าการคำนวณยอดรวมที่แม่นยำโดยไม่ต้องมีการตรวจสอบด้วยตนเอง ประมวลผลใบแจ้งหนี้ได้หลายพันรายการต่อวันด้วยการติดตั้งในเครื่องและไม่มีค่าใช้จ่าย API
เอกสารทางเทคนิค
ทีมวิศวกรรมแปลงคู่มือและข้อกำหนดทางเทคนิคที่เป็น PDF ให้เป็นข้อความที่สามารถค้นหาได้ การจดจำสูตรจะรักษาสมการทางคณิตศาสตร์ ทำให้เนื้อหาทางเทคนิคสามารถอ่านได้ด้วยเครื่อง เหมาะสำหรับโครงการปรับปรุงเอกสารเก่าให้ทันสมัย
การวิเคราะห์เอกสารทางกฎหมาย
ผู้เชี่ยวชาญด้านกฎหมายตรวจสอบสัญญาและข้อตกลงด้วย OCR ที่เคารพลําดับชั้นของเอกสาร การจัดการเลย์เอาต์หลายคอลัมน์ช่วยให้มั่นใจว่าย่อหน้าจะไม่ถูกรวมเข้าด้วยกันอย่างไม่ถูกต้อง วิธีการที่ให้ความสำคัญกับความเป็นส่วนตัวช่วยให้ข้อมูลที่ละเอียดอ่อนอยู่ภายในองค์กร
เวชระเบียน
สำนักงานแพทย์แปลงแบบฟอร์มผู้ป่วยและใบสั่งยาให้เป็นดิจิทัล จดจำได้ 8 ภาษา ซึ่งมีประโยชน์สำหรับสภาพแวดล้อมการดูแลสุขภาพหลายภาษา การติดตั้งในเครื่องเป็นไปตามข้อกำหนด HIPAA โดยเก็บข้อมูลไว้ภายใน
สรุป
GLM-OCR นำเสนอการทำความเข้าใจเอกสารระดับการผลิตในแพ็กเกจพารามิเตอร์ขนาด 0.9B คุณสามารถติดตั้งในเครื่อง รักษาความเป็นส่วนตัวของข้อมูล และบรรลุอัตราปริมาณงานที่เทียบเท่ากับ API บนคลาวด์—ทั้งหมดนี้โดยไม่มีค่าใช้จ่ายต่อคำขอ สถาปัตยกรรมนี้จัดการกับเลย์เอาต์ที่ซับซ้อน ตาราง และสูตรที่ OCR แบบดั้งเดิมพลาดไป ขณะที่ใบอนุญาต MIT อนุญาตให้ใช้เชิงพาณิชย์ได้อย่างไม่จำกัด
เลือก vLLM สำหรับการติดตั้งใช้งานในการผลิตที่ต้องการปริมาณงานสูงและเข้ากันได้กับ OpenAI ใช้ SGLang เมื่อความเร็วในการอนุมานสูงสุดมีความสำคัญ เลือก Transformers สำหรับการพัฒนาและไปป์ไลน์ที่กำหนดเอง ตัวเลือกแต่ละตัวรันโมเดลพื้นฐานเดียวกัน ดังนั้นคุณจึงสามารถเปลี่ยนวิธีการติดตั้งใช้งานได้โดยไม่ต้องฝึกใหม่หรือปรับแต่งใหม่
เมื่อสร้างไปป์ไลน์การประมวลผลเอกสาร—ไม่ว่าจะเป็นการดึงข้อมูลจากใบแจ้งหนี้ การแยกวิเคราะห์เอกสารทางเทคนิค หรือการดำเนินการประมวลผลแบบฟอร์มอัตโนมัติ—ให้ปรับปรุงการทดสอบ API ของคุณด้วย Apidog มันให้การสร้างคำขอด้วยภาพ, การสร้างเอกสารอัตโนมัติ และเครื่องมือดีบักแบบร่วมมือกันที่เติมเต็มเวิร์กโฟลว์การติดตั้ง GLM-OCR ของคุณ