إصدار ما قبل الإطلاق / بناء مستمر: هذا بناء تجريبي، وليس إصداراً مستقراً.
llama : إصلاح إعادة تخصيص غير متوقعة للرسم البياني في نماذج k-pool (#29958) * llama : إصلاح إعادة تخصيص غير متوقعة للرسم البياني في نماذج k-pool بنى كلا نموذجي k-pool شكلاً للرسم البياني يعتمد على حالة لا يمكن لحجز السياق الكامل معرفتها: - qwen4exp تفرّع بناءً على inp->cache_safe، والتي تصبح خاطئة بمجرد أن يشارك llama_memory_seq_cp الخلايا (مثل batched-bench -pps): طبقات QSA استبدلت scatter+gather بـ fill+concat وأسقطت الورقة new_pool_rep، فأصبح رسم decode يفتقد 12 عقدة مقارنة بالرسم المحجوز - glm5-next تفرّع بناءً على gather = n_tokens <= 16 && n_kv > n_sel، فبنى decode الخاص بـ TG شكل gather (7564 عقدة) بينما كان الحجز الأخير، وهو حجز PP، ذا شكل كثيف (7762 عقدة) أي عدم تطابق من هذا النوع يفرض إعادة حجز وقت decode تُسقط الحجم الأسوأ وتثبّت الحالة الحالية، بحيث تحتاج الزيادة التالية في الحالة (n_pool, n_kv, n_new) مساحة أكبر عند حجم رسم بياني غير متغير وتتوقف تحت GGML_SCHED_DEBUG_REALLOC=1. أعِد إنتاج ذلك مثلاً بـ: GGML_SCHED_DEBUG_REALLOC=1 ./bin/llama-batched-bench \ -hf ggml-org/GLM-5.3-Flash-GGUF:Q2_K -npp 2500 -ntg 32 -npl 1,2 \ -c 32768 -pps -kvu استخدم دائماً scatter+gather للمفاتيح المجمّعة، واختر gather من ثوابت السياق فقط: n_ubatch يحدّ كل ubatch، وtop_k + kpool - 1 يحدّ n_sel. وبذلك يشترك كل رسم بياني لسياق ما في شكل واحد يغطيه الحجز، وكان المسار الكثيف أسرع قياساً من مسار gather عند سياق 2.5k و16k. بمساعدة: pi:llama.cpp/MiMo-V2.6-Flash-MOPD * llama : إسقاط واجهة cache_safe غير المستخدمة لرسوم k-pool لم تعد رسوم k-pool تتفرع بناءً على cache_safe، فلم يعد هناك ما يقرأ get_kpool_cache_safe() أو new_pool_rep الشرطية: كلا النموذجين يمرّر دائماً هدف scatter، وهو ما يتطلبه set_input_kpool الآن بدلاً من مجرد تفضيله. كما أُسقطت نسخة cache_safe في kpool_build_sizes()، وهي دالة مساعد لأحجام فقط. يبقى التخطيط وعلم الحالة نفسه، فهو ما يزال يحدد أي المجمّعات يجب على تخطيط ذي خلايا مشتركة إعادة تجميعها. بمساعدة: pi:llama.cpp/MiMo-V2.6-Flash-MOPD * tests : إضافة اختبار انحدار لحجز رسم بياني بتسلسل مشترك فك تشفير موجه في seq 0، ثم شارك خلاياه مع seq 1 عبر llama_memory_seq_cp (ما يفعله llama-batched-bench لـ -pps)، ثم واصل فك تشفير كلا التسلسلين. بالنسبة لنماذج k-pool فإن المشاركة تمسح cache_safe، مما يغيّر طوبولوجيا الرسم البياني بينما تستمر المجمّعات في النمو، لذا فإن أي مجدول يعيد الحجز بالحالة الحالية بدلاً من الحالة الأسوأ يتوقف تحت GGML_SCHED_DEBUG_REALLOC=1. وتضبط تسجيلات الاختبار ذلك العلم، وكان الاختبار يتوقف على كلا نموذجي k-pool قبل 2220411ec1. تم تخطي kimi-linear وminimax-01: فهما يحجزان رسم pp النهائي بـ n_seqs = 1 (انظر [TAG_RESERVE_DIAG_DECAY] في llama-context.cpp)، لذا فكل رسم متعدد التسلسلات له تخطيط مختلف ويعيد الحجز بالتصميم. بمساعدة: pi:llama.cpp/MiMo-V2.6-Flash-MOPD * cont : إضافة TODOs * cont : إصلاح تعليق * cuda: مطابقة اختزال moe الموزون على ubatches فارغة كان ggml_cuda_match_moe_weighted_reduction يرفض الموترات ذات الصفوف الصفرية. إن ubatch بلا مخارج يقلّص الطبقة الأخيرة إلى صفوف صفرية عبر inp_out_ids، فأسقط graph_optimize تبعية التخصيص لها هناك وفقد رسم المجدول عقدة واحدة مقارنة بالرسم المحجوز. ثم أعاد المجدول الحجز بحجم ذلك ubatch، وكان ubatch التالي بالعدد نفسه من العقد لكن بموترات أكبر يتوقف تحت GGML_SCHED_DEBUG_REALLOC=1. فإن حلقة الحساب تتخطى العقد الفارغة أصلاً قبل محاولة أي دمج، فالشرط لم يجعل تبعيات التخصيص تعتمد إلا على عدد الصفوف. * tests: بناء اختبار التراجع فقط حيث تُربط الرموز الداخلية تستدعي حالة التسلسل المشترك llm_arch_from_string، التي لا تصدّرها libllama عبر LLAMA_API، فيفشل ربط test-recurrent-state-rollback على Windows مع المكتبات المشتركة. أصبح بناؤه الآن في كتلة NOT WIN32 OR NOT BUILD_SHARED_LIBS، بجوار test-llama-archs وتسجيل الاختبار الموجود تحته أصلاً. * tests: تخطي المعماريات بالاسم في اختبار الحجز بالتسلسل المشترك كان تخطي kimi-linear وminimax-01 يمر عبر llm_arch_from_string، التي لا تصدّرها libllama عبر LLAMA_API، فلم يكن الاختبار يُربط على Windows مع المكتبات المشتركة. يقارن الآن سلسلة general.architecture مباشرة، فيُبنى الاختبار على كل المنصات مجدداً. --------- مساهمة مشتركة من: Pascalالموقع الإلكتروني: - https://llama.app
الشهادات: - https://github.com/ggml-org/llama.cpp/attestations/52789660
macOS/iOS: - macOS Apple Silicon (arm64) - macOS Apple Silicon (arm64، مع تفعيل KleidiAI) معطّل - macOS Intel (x64) - XCFramework لنظام iOS
لينكس: - أوبونتو x64 (معالج) - أوبونتو arm64 (معالج) - أوبونتو s390x (معالج) - أوبونتو x64 (Vulkan) - أوبونتو arm64 (Vulkan) - أوبونتو x64 (CUDA 12) - مكتبات CUDA 12.8 - أوبونتو x64 (CUDA 13) - مكتبات CUDA 13.4 - أوبونتو arm64 (CUDA 13) - مكتبات CUDA 13.4 - أوبونتو x64 (ROCm 10.0) - أوبونتو x64 (OpenVINO) - أوبونتو x64 (SYCL FP32) - أوبونتو x64 (SYCL FP16) - لينكس arm64 (Snapdragon: معالج، Adreno GPU، Hexagon NPU) - دليل الإعداد
أندرويد: - أندرويد arm64 (معالج) - أندرويد arm64 (Snapdragon: معالج، Adreno GPU، Hexagon NPU) - دليل الإعداد
ويندوز: - ويندوز x64 (CPU) - ويندوز arm64 (CPU) - ويندوز arm64 (OpenCL Adreno) - ويندوز x64 (CUDA 12) - ملفات CUDA 12.4 DLLs - ويندوز x64 (CUDA 13) - ملفات CUDA 13.4 DLLs - ويندوز arm64 (CUDA 13) - ملفات CUDA 13.4 DLLs - ويندوز x64 (Vulkan) - ويندوز arm64 (Vulkan) - ويندوز x64 (OpenVINO) - ويندوز x64 (SYCL) - ويندوز x64 (ROCm 10.0)
openEuler: - معطّل - نظام openEuler على معمارية x86 (310p) - نظام openEuler على معمارية x86 (910b، ACL Graph) - نظام openEuler على معمارية aarch64 (310p) - نظام openEuler على معمارية aarch64 (910b، ACL Graph)
واجهة المستخدم: - واجهة المستخدم