أصدرت Zhipu AI نموذج GLM-5.3 في 14 أغسطس 2026. وأهم تفصيل لفرق البنية التحتية هو أن الأوزان المفتوحة يُتوقع وصولها بعد نحو أسبوعين، أي قرابة 28 أغسطس، عبر منظمة Zhipu على Hugging Face. استغل هذه النافذة لتقدير احتياجات العتاد، وتجهيز حزمة التقديم، وبناء خط أساس تقارن به الاستضافة الذاتية مع واجهة API المستضافة.
تستحق هذه التحضيرات وقتها. تشير تقييمات Zhipu الداخلية إلى تحسن قدرات البرمجة بنسبة 50% مقارنةً بـ GLM-5.2، وقفزة Terminal-Bench 3.0 من 4.6 إلى 28.3، مع أداء وكلاء «يقترب من Claude Fable 5»، وفق تغطية الإطلاق. راجع شرح GLM-5.3 لمزيد من تفاصيل المعايير؛ أما هنا، فالتركيز على تجهيز بيئة تقديم النموذج في يوم الإطلاق.
تنبيه: الأوزان ليست متاحة للتنزيل الآن. أي تفاصيل لم تؤكدها Zhipu مُشار إليها كتوقعات. ما يمكنك تنفيذه اليوم هو إنشاء خط أساس من API المستضافة، ثم إعادة تشغيل الاختبارات نفسها على خادمك المحلي لاحقًا.
ملخص سريع
- أُطلق GLM-5.3 في 14 أغسطس 2026، ومن المتوقع نشر الأوزان قرابة 28 أغسطس في huggingface.co/zai-org.
- عائلة GLM-5، وفق وثائق Z.ai، تستخدم بنية Mixture of Experts (MoE): إجمالي 744 مليار معلمة، ونحو 40 مليار معلمة نشطة لكل تمريرة، وسياق حتى 200 ألف رمز.
- أوزان BF16 وحدها تستهلك حسابيًا نحو 1.5 تيرابايت؛ بينما FP8 تستهلك قرابة 744 جيجابايت، قبل ذاكرة KV cache.
- النمط المتوقع للإصدار هو مستودع BF16 وآخر FP8، مثل الإصدارات السابقة.
- الخياران العمليان للتقديم في اليوم الأول هما vLLM وSGLang، وكلاهما يقدم API متوافقة مع OpenAI.
- أنشئ مجموعة اختبارات في Apidog الآن، ثم بدّل بين بيئتي
hostedوlocalعند توفر الأوزان.
ما الذي ستصدره Zhipu ومتى؟
أطلقت Zhipu، تحت العلامة الدولية Z.ai، واجهة API لـ GLM-5.3 مع وعد بإتاحة الأوزان المفتوحة بعد أسبوعين تقريبًا. تؤكد الشركة أن التأخير مرتبط بمراجعة مخاطر موسعة، وهو أمر مهم مع نتيجة النموذج البالغة 84.5% في CyberGym، وهي أعلى قليلًا من Claude Mythos 5 وGPT-5.6 Sol.
تصف Seeking Alpha الإطلاق بأنه محاولة للحفاظ على ريادة Zhipu في مجال النماذج المفتوحة.
بالنسبة للاستضافة الذاتية، ركز على نقطتين:
النموذج الأساسي لم يتغير.
GLM-5.3 هو GLM-5 مع تدريب لاحق موسع. لذلك من المتوقع أن تستمر حزم مثل vLLM وSGLang في العمل مع البنية نفسها، دون نوع انتباه جديد أو تغييرات متوقعة في الـ tokenizer.-
نمط النشر معروف.
نشرت Zhipu إصدارات GLM-5 وGLM-5.1 وGLM-5.2 على Hugging Face، مع مستودع FP8 مرافق لكل إصدار. لذلك من المنطقي توقع مستودعين مشابهين:GLM-5.3GLM-5.3-FP8
لم تُؤكد شروط ترخيص 5.3 في تغطية الإطلاق. اقرأ بطاقة النموذج قبل إدماجه في منتج تجاري.
احسب احتياجات الذاكرة قبل تنزيل الأوزان
عائلة GLM-5 مبنية على MoE: يوجد إجمالي ضخم من المعلمات، لكن لا يُفعّل إلا جزء منها لكل رمز. هذا يحسن الحساب، لكنه لا يلغي متطلبات تخزين جميع الخبراء في الذاكرة.
الحساب يشبه نموذجًا كثيفًا بحجم 40B تقريبًا.
تُفعّل الخبراء الموجّهة فقط لكل رمز، لذلك قد تكون الإنتاجية أفضل بكثير من نموذج كثيف بحجم 744B.الذاكرة تشبه نموذجًا بحجم 744B.
يجب أن تكون جميع الأوزان قابلة للوصول. عند 2 بايت لكل معلمة في BF16، تحتاج الأوزان إلى نحو 1.5 تيرابايت. وعند 1 بايت لكل معلمة في FP8، تحتاج إلى قرابة 744 جيجابايت. لا يشمل ذلك KV cache.
| الدقة | حجم الأوزان التقريبي | بيئة التشغيل الواقعية |
|---|---|---|
| BF16 | ~1.5 تيرابايت | عنقود متعدد العقد أو أكبر خوادم GPU |
| FP8 الرسمي | ~745 جيجابايت | خادم قوي متعدد وحدات GPU |
| تحويلات INT4 المجتمعية | ~370–400 جيجابايت | عدة وحدات GPU أصغر، مع ضرورة اختبار الجودة |
إذا كانت لديك وحدة GPU استهلاكية واحدة، فلا تجعل تشغيل الأوزان الكاملة هدفك. استخدم API المستضافة للتطبيقات الثقيلة، أو استأجر عتادًا للتقييم، أو انتظر تحويلات كمية موثوقة. راجع دليل أفضل نماذج اللغة المحلية في 2026 لمعرفة الخيارات الأنسب لمحطات العمل الفردية.
كذلك، لا تتعامل مع سياق 200 ألف رمز كإعداد افتراضي. تنمو KV cache مع طول السياق وحجم الدفعة، لذا حدّد max_model_len لكل طبقة نشر قبل الإطلاق.
جهّز حزمة التقديم قبل وصول الأوزان
الخيار الأول: vLLM
يُعد vLLM الخيار الافتراضي العملي لهذه الفئة من النماذج، لأنه يدعم عائلة GLM-5، وتوجيه MoE، والتوازي عبر GPUs والعقد، ويقدم واجهة متوافقة مع OpenAI.
مثال قالب للإطلاق بعد توفر المستودع:
vllm serve zai-org/GLM-5.3-FP8 \
--tensor-parallel-size 8 \
--max-model-len 65536 \
--served-model-name glm-5.3
عدّل القيم التالية وفقًا لبيئتك:
- اسم المستودع الفعلي عند النشر.
-
--tensor-parallel-sizeحسب عدد وحدات GPU. -
--max-model-lenوفق ميزانية KV cache. - اسم النموذج المعلن لتبقى تطبيقاتك متوافقة.
الخيار الثاني: SGLang
استخدم SGLang إذا كان حملك يعتمد على وكلاء يعيدون إرسال بادئات طويلة ومشتركة. يوفّر تخزينًا مؤقتًا للبادئات باستخدام radix tree، ويعرض أيضًا API متوافقة مع OpenAI.
llama.cpp وOllama وLM Studio
تحتاج هذه الأدوات عادةً إلى تحويلات GGUF، والتي قد تظهر بعد أيام أو أسابيع من إصدار Safetensors. لا تعتمد عليها في اليوم الأول، ولا تفترض جودة التحويلات: اختبرها مقابل خط الأساس الذي سجلته من API المستضافة.
إجراء عملي اليوم: شغّل vLLM أو SGLang مع GLM-5.2 أو نموذج MoE أصغر. معالجة مشكلات CUDA وتعريفات GPU قبل يوم الإطلاق أفضل بكثير من اكتشافها عند وصول الأوزان.
أنشئ خط أساس من API المستضافة
قبل تشغيل أي نموذج محلي، سجّل سلوك المرجع المستضاف. بهذه الطريقة، عندما تختلف استجابتك المحلية، تستطيع تحديد ما إذا كان السبب:
- تحويل كمي منخفض الدقة.
- إعدادًا خاطئًا في حزمة التقديم.
- اختلافًا طبيعيًا في أخذ العينات.
- اختلافًا في سلوك استدعاء الأدوات أو التنسيق.
نقاط النهاية المستضافة المتوافقة مع OpenAI هي:
- دوليًا:
https://api.z.ai/api/paas/v4/chat/completions - للصين القارية:
https://open.bigmodel.cn/api/paas/v4/chat/completions
استخدم الترويسة:
Authorization: Bearer <key>
تسرد وثائق Z.ai حاليًا glm-5. أكّد سلسلة نموذج glm-5.3 النهائية من الوثائق الرسمية. ولإعداد API في المنطقتين، راجع دليل البدء السريع لـ GLM-5.3 API.
ابدأ باستجابات حرارة صفر ومطالبات ثابتة:
curl https://api.z.ai/api/paas/v4/chat/completions \
-H "Authorization: Bearer $GLM_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm-5.3",
"temperature": 0,
"messages": [
{
"role": "user",
"content": "Write a Python function that parses RFC 3339 timestamps and returns UTC datetimes. Include error handling for invalid input."
}
]
}' > baseline-rfc3339.json
أنشئ بين 20 و50 حالة اختبار حقيقية تشمل:
- توليد التعليمات البرمجية.
- إصلاح الأخطاء وإعادة الهيكلة.
- استدعاء الأدوات في الوكلاء.
- JSON mode.
- تلخيص سياق طويل.
- تعليمات النظام الطويلة والمشتركة.
لن تجعل temperature: 0 النتائج متطابقة تمامًا، لكنها تقلّص التباين بما يكفي لتظهر آثار التحويل الكمي أو أخطاء التقديم.
ابنِ مجموعة انحدار في Apidog
ملفات curl مفيدة في البداية، لكنها تصبح غير عملية مع وجود عدة نقاط نهاية، أو أكثر من مستوى كمي، أو إعدادات متعددة للخادم. استخدم Apidog لإنشاء مجموعة قابلة لإعادة التشغيل. ولمنهجية اختبار APIs العامة، راجع دليل اختبار واجهة برمجة التطبيقات لمهندسي ضمان الجودة.
1. أنشئ مجموعة واحدة لكل حالات الخط الأساس
أنشئ طلبًا لكل مطالبة على مسار chat completions. بما أن واجهة Z.ai وvLLM وSGLang تتبع نمط OpenAI، يبقى شكل الطلب ثابتًا تقريبًا.
2. عرّف بيئتين: hosted وlocal
إعداد بيئة hosted:
base_url = https://api.z.ai/api/paas/v4
api_key = <GLM_API_KEY>
إعداد بيئة local:
base_url = http://localhost:8000/v1
api_key = local-serving
استخدم المتغير نفسه في جميع الطلبات:
{{base_url}}/chat/completions
بهذا، يصبح التبديل بين API المستضافة وخادمك المحلي مجرد اختيار بيئة.
3. أضف تأكيدات على الشكل ثم المحتوى
ابدأ بتأكيدات عامة لا تتأثر بصياغة الإجابة:
HTTP status = 200
choices[0].message.content غير فارغ
وجود usage
ثم أضف تأكيدات مرتبطة بمهمة الاختبار. في اختبار توليد كود Python، تحقق مثلًا من وجود:
def
datetime
try
4. احفظ استجابات API المستضافة كأمثلة
هذه الاستجابات هي مرجعك الثابت. بعد نشر النموذج محليًا، شغّل المجموعة نفسها على بيئة local وقارن النتائج.
5. شغّل المجموعة من سطر الأوامر
استخدم مشغّل Apidog لتشغيل المجموعة دون واجهة رسومية. هذا يجعل المقارنة قابلة للأتمتة في CI أو عند اختبار:
- دقة FP8 مقابل تحويل كمي آخر.
- vLLM مقابل SGLang.
- إعدادات التوازي المختلفة.
- حدود السياق.
- تغييرات التخزين المؤقت للبادئات.
الهدف بحلول 28 أغسطس هو أمر واحد يجيب عن السؤال: هل يعمل نشري المحلي مثل النموذج المستضاف؟
لا تغيّر رمز العميل: بدّل base_url فقط
بما أن الخادم المحلي وAPI المستضافة متوافقان مع OpenAI، يمكن لتطبيقك الحفاظ على البنية نفسها:
import os
from openai import OpenAI
# مستضاف:
# GLM_BASE_URL=https://api.z.ai/api/paas/v4
# محلي:
# GLM_BASE_URL=http://localhost:8000/v1
client = OpenAI(
base_url=os.environ["GLM_BASE_URL"],
api_key=os.environ.get("GLM_API_KEY", "local-serving"),
)
response = client.chat.completions.create(
model="glm-5.3",
temperature=0,
messages=[
{
"role": "user",
"content": "Refactor this function to remove the nested loops: ..."
}
],
)
print(response.choices[0].message.content)
يمكن لـ vLLM وSGLang تقديم أي اسم نموذج تسجله وقت التشغيل. استخدم:
--served-model-name glm-5.3
للحفاظ على تطابق معرف النموذج بين البيئة المستضافة والمحلية.
اختبر بشكل منفصل:
streaming- استدعاء الأدوات
- JSON mode
- استخدام أدوات متعددة في المحادثة
- الأخطاء وحدود المهلات
هذه هي المناطق التي قد تختلف فيها الحزم المحلية عن السلوك المستضاف.
كيف تقارن التكلفة؟
لم تنشر Zhipu تسعير API لـ GLM-5.3 عند الإطلاق. راجع صفحة التسعير الرسمية قبل بناء تقديرات التكلفة.
عمليًا، تكون الاستضافة الذاتية مبررة غالبًا في الحالات التالية:
- لديك استخدام مستمر وكثيف يجعل تكلفة GPU أقل من سعر الرموز.
- لديك متطلبات حوكمة بيانات تمنع خروج المطالبات من شبكتك.
- تحتاج تحكمًا أكبر في زمن الوصول أو التوافر.
- تريد تخفيف مخاطر تغير الأسعار لدى مزود API.
أما في الاستخدام المتقطع أو غير المؤكد، فعادةً ما تكون API المستضافة أو استئجار ساعات GPU للتقييم أقل مخاطرة من شراء عتاد ضخم. يوضح تحليل زيادة أسعار DeepSeek API سبب أهمية وجود بديل استضافة ذاتية تم اختباره مسبقًا.
قائمة مراجعة يوم الإطلاق
نفّذ هذه الخطوات الآن
- حدّد مستوى الدقة المستهدف: BF16 أو FP8 أو تحويل كمي لاحق.
- راجع حجم VRAM المتاح، وأدرج KV cache في الحساب.
- ثبّت vLLM أو SGLang وشغّله مع GLM-5.2 أو نموذج MoE بديل.
- أنشئ مفتاح API من Z.ai.
- أكّد معرف نموذج 5.3 النهائي في الوثائق الحية.
- التقط 20–50 استجابة مرجعية بدرجة حرارة صفر.
- جهّز مجموعة Apidog ببيئتي
hostedوlocal. - حدّد طول السياق الأقصى لكل طبقة نشر.
عند إصدار الأوزان
- راقب منظمة Zhipu على Hugging Face بحثًا عن
GLM-5.3وGLM-5.3-FP8. - اقرأ بطاقة النموذج والترخيص قبل النشر التجاري.
- نزّل الأوزان وشغّل خادم التقديم.
- وجّه بيئة
localإلى نقطة النهاية الجديدة. - شغّل مجموعة الانحدار كاملة.
- راجع حالات فشل المحتوى قبل توجيه أي حركة إنتاجية.
- بعد نجاح المقارنة، ابدأ ضبط الدقة والتوازي والتخزين المؤقت وحدود السياق.
الأسئلة الشائعة
هل يمكنني تنزيل أوزان GLM-5.3 الآن؟
لا. اعتبارًا من 14 أغسطس 2026، المتاح هو API المستضافة. من المتوقع وصول الأوزان بعد نحو أسبوعين، قرابة 28 أغسطس، على صفحة zai-org في Hugging Face.
هل سيعمل GLM-5.3 على وحدة GPU استهلاكية واحدة؟
ليس بالأوزان الكاملة. تحتاج أوزان FP8 وحدها إلى قرابة 744 جيجابايت قبل KV cache، حتى قبل احتساب الذاكرة المطلوبة للتشغيل. استخدم نموذجًا أصغر محليًا، واحتفظ بـ GLM-5.3 على API المستضافة، أو انتظر تحويلات كمية مناسبة. راجع مراجعة النماذج المحلية للخيارات العملية.
ما إطار العمل المناسب لخدمة GLM-5.3؟
ابدأ بـ vLLM إذا كنت تريد الخيار الأكثر أمانًا: دعم لعائلة GLM-5، وتوازي مناسب لـ MoE، وواجهة متوافقة مع OpenAI. اختر SGLang إذا كانت أحمالك تعتمد على بادئات مشتركة طويلة، خصوصًا في الوكلاء. انتظر تحويلات GGUF إذا كان هدفك llama.cpp أو Ollama أو LM Studio.
هل سيعمل OpenAI SDK الحالي مع الخادم المحلي؟
نعم. غيّر base_url من:
https://api.z.ai/api/paas/v4
إلى:
http://localhost:8000/v1
ثم حافظ على شكل الطلب. اختبر البث واستدعاء الأدوات بشكل صريح.
لماذا أحتاج API المستضافة إذا كنت سأستضيف النموذج ذاتيًا؟
لأنها مرجع المقارنة. من دون استجابات مرجعية، لن تعرف هل الإجابة المحلية الضعيفة ناتجة عن تحويل كمي، أو إعداد خادم، أو سلوك النموذج نفسه. التقط هذه الاستجابات الآن عبر دليل البدء السريع لـ GLM-5.3 API.
الخلاصة
لن تكون أفضل الفرق تجهيزًا في الأسبوع الأول هي التي تملك أكبر عدد من وحدات GPU، بل الفرق التي جهزت العملية كاملة مسبقًا:
- حزمة تقديم مثبتة ومختبرة.
- مستوى دقة محدد بناءً على الذاكرة المتاحة.
- خط أساس من API المستضافة.
- مجموعة انحدار قابلة للتشغيل آليًا.
- تبديل واضح بين
hostedوlocal.
ابدأ بقائمة المراجعة، وسجّل خطوط الأساس هذا الأسبوع، ثم نزّل Apidog لتنظيم المقارنة: مجموعة واحدة، بيئتان، وتأكيدات تحول سؤال «هل يعمل نشري؟» إلى تقرير نجاح أو فشل قابل لإعادة التشغيل.
Top comments (0)