BitDelta: تقديم 14 نموذج Zen من عنقود معالج رسومي واحد

اقتصاديات تقديم متغيرات النماذج المضبوطة ضبطًا دقيقًا قاسية افتراضيًا.

يحتاج نموذج بمعاملات 70B بصيغة BF16 إلى 140GB من ذاكرة معالج الرسوم. إذا كان لديك 14 متغيرًا مضبوطًا من ذلك النموذج — كل واحد يمثل ملف قدرات مختلفًا، أو تخصصًا مجاليًا، أو ضبطًا سلوكيًا — فإن معمارية التقديم البسيطة تتطلب 14 تحميلًا منفصلًا للنموذج: 1.96TB من ذاكرة معالج الرسوم، و14 عملية استدلال منفصلة، وكلفة بنية تحتية قدرها 14x. مقابل كل متغير بعد الأول، تدفع السعر الكامل مقابل معرفة أساس تكاد تكون مكررة بالكامل.

يكسر BitDelta (arXiv:2402.10193) هذا الاقتصاد. الفكرة أنيقة والرياضيات بسيطة.

الأساس الرياضي

ليكن W_base مصفوفة أوزان النموذج الأساس و W_ft مصفوفة الأوزان المقابلة في متغير مضبوط. دلتا السلوك هي:

Δ = W_ft - W_base

يضغط BitDelta هذه الدلتا إلى دقة 1 بت:

W_ft ≈ W_base + α · sign(Δ)

حيث α عامل مقياس لكل مصفوفة، يُحسب كمتوسط القيمة المطلقة لـ Δ:

α = (1/n) · ||Δ||_1 = mean(|Δ_ij|)

تختزل عملية الإشارة كل دلتا عددية إلى بت واحد — موجب أو سالب. يعيد عامل المقياس α المقدار. ومعًا، يلتقط التقريب المعلومات الاتجاهية لتحديث الضبط الدقيق بكلفة تخزين تبلغ 1/32 من دلتا كاملة الدقة (1 بت مقابل 32 بتًا لكل عنصر معامل).

لماذا ينجح هذا؟ ينتج الضبط الدقيق على نموذج كبير مدرب مسبقًا دلتا تكون، في التوقع، صغيرة نسبة إلى الأوزان الأساس. يلتقط النموذج الأساس البنية الغالبة للغة؛ ويلتقط الضبط الدقيق التعديلات السلوكية فوق تلك البنية. عندما تكون الدلتا صغيرة، تكون إشارة كل عنصر أعلى تمثيل معلوماتًا لذلك العنصر — المقدار شبه منتظم عبر مصفوفة الدلتا، لذا فإن α · sign(Δ) ترميز كفء.

يمكن صياغة ذلك بصورة أكثر صورية. إذا نمذجنا Δ_ij كمتغير عشوائي لابلاسي بموضع 0 ومقياس b:

Δ_ij ~ Laplace(0, b)
|E[sign(Δ) | |Δ|]| = 1 for all nonzero Δ

تحفظ الإشارة المعلومات الاتجاهية حفظًا تامًا. فقدان المعلومات محض تباين في المقدار، يستعيد عامل المقياس الوحيد α جزءًا منه. بالنسبة لدلتا الضبط الدقيق حيث تباين المقدار منخفض (تعديل سلوك لا نقل معرفة)، يكون التقريب محكمًا.

خفض الذاكرة: لنموذج 70B بصيغة BF16، تشغل الأوزان الأساس 140GB. دلتا كل متغير مضبوط، بصيغة BF16 الكاملة، ستضيف 140GB أخرى. بصيغة BitDelta، تشغل كل دلتا نحو 8.75GB (70B بت = 8.75GB، إضافة إلى مقادير α العددية وهي مهملة). ينتقل عنقود المتغيرات الـ14 من 14 × 140GB = 1.96TB إلى 140GB + 14 × 8.75GB ≈ 262GB — خفض بنسبة 87%.

معمارية التقديم

┌─────────────────────────────────────────────────────────────────┐
│                    GPU CLUSTER (8x H100, 80GB each)             │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              BASE WEIGHTS (140GB, HBM resident)          │   │
│  │  W_base for zen4-70b: attention, FFN, embeddings, norms  │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │ shared read                    │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │           DELTA CACHE (≈8.75GB per variant)              │   │
│  │  zen4-coder:    α_coder,    sign(Δ_coder)    [8.75GB]    │   │
│  │  zen4-ultra:    α_ultra,    sign(Δ_ultra)    [8.75GB]    │   │
│  │  zen4-math:     α_math,     sign(Δ_math)     [8.75GB]    │   │
│  │  zen4-writer:   α_writer,   sign(Δ_writer)   [8.75GB]    │   │
│  │  zen4-legal:    α_legal,    sign(Δ_legal)    [8.75GB]    │   │
│  │  zen4-medical:  α_medical,  sign(Δ_medical)  [8.75GB]    │   │
│  │  ...14 total...                                           │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │                                │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │              REQUEST ROUTER                               │   │
│  │  model_id → delta_load → reconstruct W_ft → inference    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

في وقت الاستدلال، يكون خط التقديم كما يلي:

1. يصل الطلب ومعه model: "zen4-coder"
2. يحدد الموجّه مدخل ذاكرة الدلتا المؤقتة لـ zen4-coder
3. تُعاد بناء الوزن الفعال أثناء التنفيذ: W_eff = W_base + α_coder · sign(Δ_coder)
4. تشغيل التمريرة الأمامية بالأوزان المعاد بناؤها
5. إرجاع الاستجابة

الخطوة 3 هي المسار الحرج. إعادة البناء نواة CUDA مدمجة تقرأ الأوزان الأساس وبتات الدلتا معًا، وتعيد بناء الوزن الفعال في المسجلات أو الذاكرة المشتركة دون تجسيد W_eff الكامل في HBM. يمكن دمج إعادة البناء وضرب المصفوفات في تمريرة نواة واحدة — الوزن المعاد بناؤه لا يوجد أبدًا بصورة كاملة كموتّر مستقل.

# Simplified reconstruction kernel (conceptual)
def fused_bitdelta_linear(
    x: torch.Tensor,          # input activations [batch, seq, d_in]
    w_base: torch.Tensor,     # base weight [d_out, d_in] in HBM
    delta_sign: torch.Tensor, # 1-bit delta [d_out, d_in] packed as int8
    alpha: torch.Tensor,      # scale factor [d_out] or scalar
) -> torch.Tensor:
    # In practice: single CUDA kernel, no intermediate w_eff allocation
    # Conceptually equivalent to:
    delta_unpacked = unpack_bits(delta_sign).to(w_base.dtype)  # {-1, +1}
    w_eff = w_base + alpha.unsqueeze(1) * delta_unpacked
    return torch.nn.functional.linear(x, w_eff)

يبقي نهج النواة المدمجة ذروة استهلاك عرض نطاق HBM عند نحو 1.5x أوزان النموذج الأساس — لا عند 2x، لأن الدلتا تُقرأ بصيغة بتات معبأة وتُفك في SRAM السريعة أثناء العملية المدمجة.

مظهر الكمون

عمليًا، عبر عنقود تقديم Zen ذي 14 متغيرًا:

المتغير	P50 زمن أول رمز	P99 زمن أول رمز	مقابل خط الأساس
zen4 (الأساس)	18ms	42ms	1.0x
zen4-coder	21ms	48ms	1.17x
zen4-ultra	22ms	51ms	1.22x
zen4-math	21ms	47ms	1.17x
zen4-writer	20ms	45ms	1.11x

عبء زمن أول رمز الناتج عن إعادة بناء BitDelta هو 2-4ms — مهمل نسبة إلى كلفة التعبئة المسبقة لأطوال الموجّه المعتادة. نواة إعادة البناء مقيدة بالحساب لا بالذاكرة، لذا تتوسع جيدًا مع أجيال معالج الرسوم.

إنتاجية التوليد (رمز/ثانية) متطابقة بين النموذج الأساس وأي متغير BitDelta، لأن إعادة البناء تحدث فقط أثناء مرحلة التعبئة المسبقة. بعد امتلاء ذاكرة KV المؤقتة، تستخدم خطوة التوليد ذاتية الانحدار مسارات ضرب المصفوفات القياسية.

الجودة: ما الذي يُفقد في ضغط 1 بت؟

الجواب الصادق: مقدار صغير، محدود بعناية.

تدهور جودة BitDelta يعتمد على المهمة. في المهام الممثلة جيدًا في بيانات الضبط الدقيق، تكون دلتا السلوك قوية — تلتقط الإشارة اتجاه التدرج الغالب بثقة. في المهام على هامش توزيع الضبط الدقيق، تكون الدلتا أضعف — يُدخل التقريب ضوضاء أكثر نسبة إلى الإشارة.

تجريبيًا، عبر نماذج Zen المقيّمة على مجموعات مهامها المستهدفة:

النموذج	كامل الدقة	BitDelta	الفرق
zen4-coder (HumanEval)	72.4%	71.1%	-1.3%
zen4-math (MATH-500)	68.9%	67.8%	-1.1%
zen4-writer (WritingBench)	84.2%	83.7%	-0.5%
zen4-legal (LegalBench)	61.3%	60.1%	-1.2%

تدهور 1-1.3% على مجموعات المهام الأساسية هو ثمن خفض الذاكرة بنسبة 87%. لكل متغيرات Zen، هذه المقايضة مقبولة — فرق الجودة دون عتبة التغير السلوكي الذي يدركه المستخدم في حالات الاستخدام المعتادة.

MonoSoup: مكمّل نقطة التحقق الواحدة عبر SVD

MonoSoup (arXiv:2602.09689) يعالج مشكلة مكملة: عندما توجد نقاط تحقق مضبوطة متعددة للنموذج الأساس نفسه، كيف تدمجها في نقطة تحقق واحدة دون تحميلها كلها في وقت واحد؟

يطبق MonoSoup تحليل SVD على متجه المهمة (Δ = W_ft - W_base) لتحديد المركبات منخفضة الرتبة التي تلتقط أكبر قدر من المعلومات السلوكية، ثم يجمّعها عبر نقاط التحقق:

For checkpoints {W_1, W_2, ..., W_k}:
  Δ_i = W_i - W_base
  [U_i, S_i, Vh_i] = truncated_SVD(Δ_i, rank=r)
  τ_i = U_i · diag(S_i) · Vh_i  # rank-r approximation

MonoSoup merge:
  W_merged = W_base + (1/k) · Σ τ_i

يعمل بتر SVD عند الرتبة r كخطوة إزالة ضوضاء: يميل الضبط الدقيق إلى تعديل النموذج على عدد صغير من اتجاهات التباين العالي في فضاء الأوزان. التقاط تلك الاتجاهات عبر SVD مبتور ودمجها يلتقط جوهر سلوك كل نقطة تحقق دون ضوضاء اتجاهات القيم الشاذة الأدنى.

نستخدم MonoSoup أثناء تشغيلات تدريب Zen كخطوة متوسط لنقاط التحقق: كل 1000 خطوة تدرج، ندمج نقطة التحقق الحالية مع أفضل سابقة عبر MonoSoup بدل المتوسط الساذج. هذا يقلل ضوضاء التدريب وينتج منحنيات خسارة أنعم بجودة نهائية أفضل.

K-Merge: إدارة محولات LoRA على الخط للحافة

K-Merge (arXiv:2510.13537) يحل صورة أخرى من مشكلة التقديم: على الحافة، حيث التخزين مقيد بميزانية ثابتة B GB، كيف تقدم K محول LoRA بكفاءة؟

يبقي K-Merge مجمعًا من المحولات المدمجة تحت قيد ألا يتجاوز التخزين الإجمالي B. عندما يُطلب محول جديد غير موجود في المجمع:

1. احسب التشابه الزوجي بين المحول الجديد وكل أعضاء المجمع الحاليين (تشابه جيب التمام على متجهات المهمة)
2. حدد المحول الحالي الأكثر شبهًا
3. ادمج المحول الجديد في الأكثر شبهًا عبر OPCM (دمج الإسقاط المتعامد)
4. إذا تجاوزت جودة المحول المدمج على كلتا المهمتين العتبة، أخرج الأصل واحفظ النسخة المدمجة

تضمن السياسة أن المجمع يحوي على الأكثر K محولًا تستهلك الميزانية B، مع تعظيم التغطية عبر كل المحولات المطلوبة عبر دمج مبدئي.

لنشر Zen على الحافة (Hanzo Desktop، والجوال)، يتيح K-Merge عائلات نماذج تُقدَّم محليًا كانت لتجاوز حدود تخزين الجهاز. جهاز بتخزين نماذج متاح قدره 16GB يستطيع تقديم 8 ملفات سلوكية متميزة عبر مجمع K-Merge يدمج المحولات المتشابهة عند الطلب.

تفاصيل البنية التحتية

صيغة تخزين الدلتا: مصفوفات إشارة بدقة 1 بت مخزنة كموتّرات int8 معبأة (8 بتات لكل بايت، لذا طبقة بمعاملات 70B بوزن 4096×4096 تُحزم إلى 4096×512 int8). تُخزَّن عوامل المقياس α بصيغة float32، واحد لكل بعد إخراج، بما مجموعه نحو 0.1% من تخزين الدلتا.

سلوك البدء البارد: عندما لا تكون دلتا متغير مخزنة مؤقتًا في SRAM الخاص بمعالج الرسوم (مثلًا، لم يُطلب المتغير منذ 10 دقائق)، يدفع الطلب الأول غرامة كمون تحميل الدلتا بنحو 200ms لنموذج 70B — زمن نقل 8.75GB من NVMe إلى HBM بسرعات القراءة التسلسلية لـ NVMe. بعد الطلب الأول، تبقى الدلتا في ذاكرة الدلتا المؤقتة على SRAM حتى تخرجها سياسة LRU.

سياسة إخراج الذاكرة المؤقتة: LRU مع ترجيح بمعدل الطلبات. المتغيرات عالية معدل الطلب تُثبَّت؛ والمتغيرات ضعيفة الحركة مؤهلة للإخراج. عمليًا، أعلى 6 متغيرات حسب حجم الحركة مقيمة دائمًا في الذاكرة المؤقتة؛ والـ8 المتبقية تتشارك المساحة المتبقية مع إخراج LRU.

توجيه الطلبات: يتتبع موجّه التقديم الطلبات الجارية لكل متغير ويمنع انسداد رأس الخط: إذا كانت دلتا zen4-coder قيد التحميل، تصطف طلبات zen4-coder الواردة بدل أن يطلق كل منها تحميلًا مستقلًا.

النتيجة: 14 متغيرًا من نماذج Zen تُقدَّم من عقد 8x H100 كانت لتتطلب سابقًا عقد 112x H100 للقدرة المكافئة. خفض كلفة البنية التحتية ليس تدريجيًا. يجعل BitDelta عائلة النماذج متعددة المستأجرين مجدية اقتصاديًا.

---

نماذج Zen متاحة على zenlm.org. الوصول إلى الواجهة على hanzo.ai.