نشر GLM-OCR: دليل شامل لفهم المستندات

Ashley Goolam

Ashley Goolam

5 فبراير 2026

نشر GLM-OCR: دليل شامل لفهم المستندات

ماذا لو أمكنك استخراج النص من ملفات PDF المعقدة والجداول والصيغ باستخدام نموذج أصغر من معظم تطبيقات الهواتف الذكية؟ يحقق GLM-OCR فهمًا متطورًا للمستندات بـ 0.9 مليار معلمة فقط. إنه خفيف الوزن بما يكفي للتشغيل على أجهزة متواضعة ولكنه دقيق بما يكفي لتصدر لوحة صدارة OmniDocBench V1.5 بـ 94.62 نقطة.

تواجه أدوات التعرف الضوئي على الحروف التقليدية صعوبة في بنية المستندات. فهي تفقد تنسيق الجداول، وتسيء قراءة الصيغ الرياضية، وتفشل في التخطيطات متعددة الأعمدة. تحل واجهات برمجة التطبيقات السحابية هذه المشكلات ولكنها تفرض رسومًا لكل طلب وترسل مستنداتك الحساسة إلى خوادم تابعة لجهات خارجية. يزيل GLM-OCR كلا المشكلتين: فهو يتعامل مع التخطيطات المعقدة محليًا بدقة على مستوى الإنتاج، وكل ذلك بموجب ترخيص MIT الذي يسمح بالاستخدام التجاري بدون رسوم ترخيص.

💡
عند بناء مسارات معالجة المستندات التي تحتاج إلى اختبار موثوق لواجهة برمجة التطبيقات (API)—سواء كان ذلك لاستخراج البيانات من الفواتير، أو تحليل الوثائق الفنية، أو أتمتة معالجة النماذج—يعمل Apidog على تبسيط سير العمل بأكمله. يوفر أدوات بناء الطلبات المرئية، وتوليد الوثائق الآلي، وأدوات تصحيح الأخطاء التعاونية التي تعمل بسلاسة مع نشر GLM-OCR الخاص بك.
زر

فهم بنية GLM-OCR

يستخدم GLM-OCR بنية مشفر-مفكك تشفير ثلاثية المكونات مُحسّنة لفهم المستندات. يقوم مشفر CogViT المرئي بمعالجة صور المستندات باستخدام أوزان تم تدريبها مسبقًا على مليارات أزواج الصور والنصوص. يستخرج الميزات المرئية مع الحفاظ على العلاقات المكانية الحاسمة لفهم التخطيط.

يوجد موصل خفيف الوزن متعدد الأنماط بين المشفر ومفكك التشفير. يقوم هذا المكون بتقليل حجم الرموز المرئية بكفاءة، مما يقلل من الحمل الحسابي دون التضحية بالدقة. ثم يقوم مفكك تشفير اللغة GLM-0.5B بإنشاء مخرجات نصية منظمة، ويتعامل مع كل شيء بدءًا من الفقرات العادية وحتى الجداول المتداخلة المعقدة.

يستخدم النموذج مسار استنتاج من مرحلتين. أولاً، يحلل PP-DocLayout-V3 بنية المستند - يحدد الرؤوس والفقرات والجداول والأشكال. ثانيًا، تقوم عملية التعرف المتوازي بمعالجة كل منطقة في وقت واحد. يحافظ هذا النهج على التسلسل الهرمي للمستند حيث تقوم أدوات التعرف الضوئي على الحروف التقليدية بتسوية كل شيء إلى نص غير منظم.

تزيد ابتكارات التدريب من الأداء بشكل أكبر. يحسن فقدان التنبؤ متعدد الرموز كفاءة التدريب عن طريق التنبؤ بعدة رموز في وقت واحد. يعزز التعلم المعزز المستقر للمهام الكاملة التعميم عبر أنواع المستندات المتنوعة. والنتيجة: دقة 96.5% في التعرف على الصيغ، و 86.0% في التعرف على الجداول، وأداء رائد في مهام استخراج المعلومات.

عند الاستنتاج، يعالج GLM-OCR 1.86 صفحة PDF في الثانية على وحدة معالجة رسوميات واحدة - أسرع بكثير من النماذج المماثلة. ويعني عدد المعلمات البالغ 0.9 مليار أنك تنشر على أجهزة المستهلك بدلاً من مجموعات المؤسسات.

نموذج GLM-OCR

مواصفات النموذج

يتعامل GLM-OCR مع المستندات بدقة تصل إلى 8K (7680×4320 بكسل). يتعرف على 8 لغات بما في ذلك الإنجليزية والصينية واليابانية والكورية. يعالج النموذج كلاً من الصور النقطية (PNG، JPEG) ومدخلات المتجهات. يستهلك الاستنتاج النموذجي 4-6 جيجابايت من ذاكرة الفيديو (VRAM) بدقة FP16، مما يجعله مناسبًا لوحدات معالجة الرسوميات المخصصة للمستهلكين مثل RTX 3060 أو مثيلات السحابة مثل 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       |

خيارات النشر المحلي

يدعم GLM-OCR أربع طرق نشر حسب البنية التحتية ومتطلبات الأداء لديك. تستخدم كل طريقة نفس أوزان النموذج الأساسية من Hugging Face ولكنها مُحسّنة لسيناريوهات مختلفة.

  1. vLLM يوفر أفضل توازن بين الإنتاجية وزمن الوصول لأعباء العمل الإنتاجية. ينفذ PagedAttention لإدارة الذاكرة بكفاءة ويدعم التجميع المستمر لسيناريوهات التزامن العالية.
  2. SGLang يقدم أقصى أداء من خلال تحسين وقت التشغيل الخاص به. يتفوق في فك التشفير التخميني والتوليد المنظم، مما يجعله مثاليًا عندما تحتاج إلى أسرع استنتاج ممكن.
  3. Ollama يوفر أبسط إعداد. يقوم أمر واحد بتنزيل النموذج وتشغيله محليًا - لا توجد تبعيات Python أو ملفات تهيئة. مثالي للنماذج الأولية والاستخدام الشخصي.
  4. Transformers يتيح التكامل المباشر مع Python. استخدمه للتطوير، تصحيح الأخطاء، أو عندما تحتاج إلى تحكم دقيق في مسار الاستنتاج.

تتطلب جميع الطرق أوزان GLM-OCR من Hugging Face (zai-org/GLM-OCR). يعمل النموذج على وحدات معالجة رسوميات NVIDIA بدعم CUDA. يعمل الاستنتاج المعتمد على وحدة المعالجة المركزية فقط ولكن بسرعة أقل بكثير.

إعداد vLLM للإنتاج

يوفر vLLM استنتاجًا جاهزًا للإنتاج مع نقاط نهاية API متوافقة مع OpenAI. يتيح لك هذا استبدال GLM-OCR في التطبيقات الحالية التي تستخدم نماذج رؤية OpenAI.

التثبيت

ثبت vLLM مع دعم CUDA:

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

تشغيل الخدمة

ابدأ خادم 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 أن حزم تطوير البرمجيات (SDKs) الموجودة تعمل دون تعديل. وجه عميل OpenAI الخاص بك إلى http://localhost:8080 واستخدم zai-org/GLM-OCR كاسم للنموذج.

تكوين الإنتاج

لعمليات النشر عالية الإنتاجية، أضف توازي الموتر عبر وحدات معالجة الرسوميات المتعددة:

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 ليتناسب مع عدد وحدات معالجة الرسوميات لديك. راقب استخدام وحدة معالجة الرسوميات وزد أحجام الدُفعات لزيادة الإنتاجية إلى أقصى حد.

المراقبة والتحجيم

تتبع أداء vLLM من خلال نقطة نهاية المقاييس المضمنة على /metrics. تتضمن البيانات المتوافقة مع Prometheus زمن استجابة الطلب، وعمق قائمة الانتظار، واستخدام وحدة معالجة الرسوميات. قم بإعداد التنبيهات عندما يتجاوز عمق قائمة الانتظار 10 طلبات أو عندما تصل ذاكرة وحدة معالجة الرسوميات إلى 90%. للتحجيم الأفقي، انشر مثيلات vLLM متعددة خلف موازن تحميل مع جلسات ثابتة للحفاظ على السياق عبر الطلبات.

فكر في استخدام ميزات مراقبة 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 عندما تحتاج إلى مخرجات منظمة أو فك تشفير تخميني. يضمن التوليد المقيد بالتعبيرات العادية مخططات JSON صالحة، مما يزيل منطق إعادة المحاولة. يسرع الخوارزمية التخمينية توليد الرموز بنسبة 30-40% على وحدات معالجة الرسوميات ذات الذاكرة الكافية.

> | 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 |

بالنسبة للتعرف الضوئي على الحروف القياسي (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"

# 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" بتوزيع طبقات النموذج تلقائيًا عبر وحدات معالجة الرسوميات المتاحة. لنشر وحدة معالجة رسوميات واحدة، يقوم هذا بتحميل النموذج الكامل على جهاز واحد. للاستنتاج المعتمد على وحدة المعالجة المركزية فقط، قم بالتغيير إلى 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) المحدودة، استخدم التكميم:

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-bit quantization) من استخدام الذاكرة بنسبة 75% مع تأثير ضئيل على الدقة لمهام فهم المستندات.

التعامل مع الحالات الهامشية

تقلل المستندات ذات الكتابة اليدوية الكثيفة أو الزوايا المائلة الشديدة من الدقة. قم بمعالجة الصور مسبقًا باستخدام خوارزميات إزالة الميل قبل إرسالها إلى GLM-OCR. بالنسبة لملفات PDF متعددة الصفحات، استخرج الصفحات كصور منفصلة بدلاً من تمرير الملف بأكمله. يتيح ذلك المعالجة المتوازية ويبسط معالجة الأخطاء عندما تفشل صفحات فردية. تؤدي المستندات ذات العلامات المائية أحيانًا إلى إيجابيات خاطئة في مناطق النص - جرب تعديلات التباين إذا رأيت مخرجات مشوهة في مناطق معينة.

حالات استخدام GLM-OCR في العالم الحقيقي

يتفوق GLM-OCR في عدة سيناريوهات إنتاجية:

معالجة الفواتير

تقوم فرق المالية باستخراج بنود الفواتير والتواريخ والمجاميع من الفواتير الممسوحة ضوئيًا. يحافظ النموذج على بنية الجدول، مما يضمن حساب إجمالي دقيق دون مراجعة يدوية. قم بمعالجة آلاف الفواتير يوميًا باستخدام النشر المحلي وبدون تكاليف API.

الوثائق الفنية

تقوم فرق الهندسة بتحويل أدلة ووثائق PDF الفنية إلى نصوص قابلة للبحث. يحافظ التعرف على الصيغ على المعادلات الرياضية، مما يجعل المحتوى التقني قابلاً للقراءة آليًا. مثالي لمشاريع تحديث الوثائق القديمة.

مثال على GLM-OCR

تحليل المستندات القانونية

يقوم المتخصصون القانونيون بمراجعة العقود والاتفاقيات باستخدام تقنية التعرف الضوئي على الحروف (OCR) التي تحترم التسلسل الهرمي للمستندات. يضمن التعامل مع التخطيط متعدد الأعمدة عدم دمج الفقرات بشكل غير صحيح. يحافظ النهج الذي يركز على الخصوصية على البيانات الحساسة داخل الشركة.

السجلات الصحية

تقوم المكاتب الطبية برقمنة نماذج المرضى والوصفات الطبية. يتعرف على 8 لغات، وهو مفيد لبيئات الرعاية الصحية متعددة اللغات. يلبي النشر المحلي متطلبات الامتثال لقانون HIPAA من خلال الاحتفاظ بالبيانات داخل الشركة.

الخاتمة

يقدم GLM-OCR فهمًا للمستندات على مستوى الإنتاج في حزمة تتكون من 0.9 مليار معلمة. يمكنك نشره محليًا، والحفاظ على خصوصية البيانات، وتحقيق معدلات إنتاجية تنافس واجهات برمجة التطبيقات السحابية — كل ذلك بدون تسعير لكل طلب. تتعامل البنية مع التخطيطات والجداول والصيغ المعقدة التي تفوتها أدوات التعرف الضوئي على الحروف التقليدية، بينما يسمح ترخيص MIT بالاستخدام التجاري غير المقيد.

اختر vLLM لعمليات النشر الإنتاجية التي تتطلب إنتاجية عالية وتوافقًا مع OpenAI. استخدم SGLang عندما تكون سرعة الاستنتاج القصوى مهمة. اختر Transformers للتطوير والمسارات المخصصة. كل خيار يشغل نفس النموذج الأساسي، لذا يمكنك تبديل طرق النشر دون إعادة تدريب أو إعادة ضبط.

عند بناء مسارات معالجة المستندات—سواء كان ذلك لاستخراج البيانات من الفواتير، أو تحليل الوثائق الفنية، أو أتمتة معالجة النماذج—قم بتبسيط اختبار واجهة برمجة التطبيقات (API) الخاص بك باستخدام Apidog. يوفر أدوات بناء الطلبات المرئية، وتوليد الوثائق الآلي، وأدوات تصحيح الأخطاء التعاونية التي تكمل سير عمل نشر GLM-OCR الخاص بك.

زر

ممارسة تصميم API في Apidog

اكتشف طريقة أسهل لبناء واستخدام واجهات برمجة التطبيقات