ما الذي تحتاجه لتشغيل Kimi K3 ذاتياً؟

ما يتطلبه الاستضافة الذاتية لـ Kimi K3

تعني الاستضافة الذاتية لـ Kimi K3 توفير مساحة لـ 2.8 تريليون معامل. نشرت Moonshot الأوزان المفتوحة بتنسيق MXFP4، الذي يحتاج إلى نحو نصف بايت لكل وزن، لذلك تبلغ الأوزان وحدها نحو 1.4 TB قبل تخصيص أي جزء من الذاكرة المؤقتة للرموز. لا يوجد حالياً أي مسرّع متاح للبيع يمكنه استيعاب ذلك بمفرده. K3 نموذج متعدد العقد، ولذلك فالإجابة بالنسبة إلى خادم واحد هي: لا.

هذا هو الحكم. يوضّح كل ما يلي الحسابات التي يستند إليها، لأن الحسابات هي الجزء الذي يمكنك إعادة استخدامه مع الإصدار التالي. نشرت عدة جهات مورّدة للبنية التحتية أدلة لنشر K3 خلال الأسابيع التي تلت الإعلان في 17 July 2026، وافترضت كل واحدة منها أنك تملك عنقوداً مسبقاً. تبدأ هذه الصفحة من الطرف الآخر: ما التكلفة، وما الذي يمكنك تشغيله بدلاً منه، وكيف تحدد أيّاً من هذين الوضعين ينطبق عليك.

إجمالي المعاملات والمعاملات النشطة ليسا العدد نفسه

K3 نموذج من نوع مزيج الخبراء. يقسم MoE (مزيج الخبراء) الشبكة إلى عدة شبكات فرعية، ويتيح لوحدة توجيه اختيار عدد قليل منها لكل رمز. تذكر بطاقة النموذج 2.8T من إجمالي المعاملات و104B من المعاملات النشطة لكل رمز، من أصل 896 خبيراً موجهاً، يُفعَّل 16 منها لأي رمز معيّن، عبر 93 طبقة.

يجيب هذان العددان عن المعاملات عن سؤالين مختلفين، والخلط بينهما هو الخطأ الأكثر شيوعاً في كل نقاش من نوع «هل يمكنني تشغيل هذا؟».

تحدد المعاملات النشطة تكلفة الحوسبة. يمر الرمز عبر نحو 104B من المعاملات، لذلك يُتوقع أن يشبه معدل النقل معدل نموذج كثيف حجمه 104B، لا نموذجاً حجمه 2.8T. وهذا هو السبب الأساسي لبناء نموذج MoE.

يحدد إجمالي المعاملات تكلفة الذاكرة. قد تختار وحدة التوجيه أي خبير لأي رمز، لذلك يجب أن يكون كل خبير مقيماً في الذاكرة قبل وصول الطلب الأول. لا يمكنك الاحتفاظ بـ104B في VRAM وجلب الباقي عند الطلب، لأن عملية الجلب يجب أن تكتمل خلال ميكروثوانٍ، بينما ينقل رابط PCIe عشرات الغيغابايتات في الثانية. يحاول بعض المستخدمين ذلك فعلاً. يؤدي بث الخبراء من NVMe إلى تحويل نموذج يُفترض أن يُخرج عشرات الرموز في الثانية إلى نموذج يُخرج رمزاً واحداً كل بضع ثوانٍ.

لذلك تكون تكلفة حسابه منخفضة، بينما تكون تكلفة تخزينه مرتفعة. حدّد مواصفات العتاد على أساس 2.8T. وحدّد توقعات السرعة على أساس 104B.

عدد البايتات لكل وزن، ومن أين تأتي التيرابايتات

عدد المعاملات مضروباً في عدد البايتات لكل وزن. بالنسبة إلى الأوزان، هذه هي الصيغة كاملة.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

دُرِّب K3 مع مراعاة التكميم، وأُصدر بأوزان MXFP4 وتفعيلات MXFP8، لذلك فإن صف 4 بت هو الصف الفعلي. أما الصفوف التي تسبقه فموجودة للمقارنة: عند استخدام bf16، سيحتاج النموذج نفسه إلى 5.6 TB من الأوزان. يخزّن MXFP4 أيضاً مقياساً مشتركاً بحجم 8 بت لكل كتلة تتكون من 32 وزناً، ما يضيف نحو 6 بالمئة. لذلك يقترب حجم المستودع المنشور من 1.5 TB بدلاً من 1.4 TB من دون هذه الزيادة.

وهذا يلغي المخرج المعتاد. لا يفيد قول «طبّقه بالتكميم» هنا، لأن checkpoint المُصدر مكمّم أصلاً إلى 4 بت. سيؤدي الانتقال إلى 2 بت إلى خفض حجم الأوزان إلى 0.7 TB، لكنه سيكلف دقة لم يقسها أحد على هذا checkpoint. وستظل بحاجة إلى موارد تتجاوز قدرة أي بطاقة واحدة بكثير.

كم عدد وحدات GPU التي يحتاج إليها Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

اعتبر هذه الأرقام حداً أدنى، لا هدفاً. فهي تحسب الأوزان فقط: ولا تشمل ذاكرة KV cache، أو مخازن التنشيط، أو تجزؤ مخصِّص الذاكرة، أو السعة اللازمة لمعالجة طلب ثانٍ بالتزامن. كما تفترض تقسيم العمل بالتوازي إلى أجزاء متساوية، وهو أمر لا تسمح به دائماً الطبقات البالغ عددها 93 وخبراء Mixture of Experts البالغ عددهم 896.

تتجاوز التوصيات المنشورة هذا الحد الأدنى بكثير. اعتباراً من August 2026، توصي Moonshot بعقدة فائقة تحتوي على 64 مسرّعاً أو أكثر. كما يتضمن SGLang cookbook إعداداً لـH100 يتكون من 4 عقد، في كل منها 8 وحدات GPU، أي 32 وحدة GPU و2,560 GB من الذاكرة الإجمالية، مقابل حد أدنى يبلغ 18 بطاقات. لا تمثل هذه الفجوة هدراً. فهي توفر مساحة لذاكرة KV cache وذاكرة التنشيط، إضافة إلى هامش يسمح للخادم بمعالجة طلبات كثيرة على دفعات في الوقت نفسه. وحتى الصف الأكثر ملاءمة، الذي يضم 5 بطاقات من فئة GB300 بسعة GB، يصف جهازاً لا يؤجره معظم موفري الخدمات كمنتج واحد.

ذاكرة KV المؤقتة هي الجزء الذي يفاجئ المستخدمين

الأوزان تكلفة ثابتة. أما ذاكرة KV المؤقتة (key value) فليست كذلك؛ فهي تزداد مع طول السياق، وتزداد مجدداً مع كل مستخدم متزامن. في آلية الانتباه العادية، تكون الصيغة هي bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element، ثم تضرب الناتج في طول السياق وفي عدد المستخدمين المتزامنين.

إليك مثالاً حسابياً، وهو مجرد مثال: 64 طبقة، و8 رؤوس KV، وبُعد للرأس مقداره 128، وfp8. ينتج عن ذلك 2 64 8 128 1 = 131,072 بايت، أي 128 KiB لكل رمز.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

تستهلك جلسة مستخدم واحدة بسياق حجمه 128k مقدار 16 GiB. أما جلسة مستخدم واحدة بالحجم الكامل، أي مليون رمز، فتستهلك 128 GiB، وهو مقدار يفوق سعة أي بطاقة واحدة، وذلك لمحادثة واحدة.

لا يستخدم K3 آلية الانتباه العادية، وهذا هو سبب أهمية الرقم الأخير. تتكون طبقاته البالغ عددها 93 من 69 طبقة KDA (Kimi Delta Attention) و24 طبقة Gated MLA (multi-head latent attention). تحتفظ KDA بحالة متكررة ثابتة الحجم بدلاً من ذاكرة مؤقتة تزداد مع كل رمز، بينما تضغط MLA المفتاح والقيمة في متجه كامن واحد منخفض الرتبة؛ لذلك تنخفض التكلفة الفعلية لكل رمز كثيراً عن المثال الحسابي. لم تنشر Moonshot أبعاد المتجه الكامن، لذلك لن أضع رقماً لكل مستخدم خاصاً بـK3. قِس ذلك في بيئتك بدلاً من ذلك: شغّل الخادم باستخدام --max-model-len صغير، وراقب الذاكرة باستخدام nvidia-smi، ثم ارفع الحد حتى تفشل عملية التخصيص.

يبقى منطق التحليل نفسه في الإصدار التالي. إذا أعلن نموذج عن سياق حجمه مليون رمز ولم يذكر شيئاً عن تصميم آلية الانتباه لديه، فافترض أن الذاكرة المؤقتة هي العامل المقيِّد حتى يثبت أحد خلاف ذلك.

المستوى 1: استئجار العنقود بالساعة

هذا هو المستوى الوحيد الذي يشغّل K3 نفسه. لا تشتري العتاد. تستأجره للساعات التي تحتاج إليها، ثم توقفه بعد ذلك.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

السعر افتراض وليس عرضاً رسمياً. تراوحت أسعار القائمة عند الطلب لمسرّعات مراكز البيانات تقريباً بين 2 و5 USD لكل ساعة GPU حتى عام 2026، وتكون السعة المحجوزة أرخص. استخدم السعر الفعلي لدى موفّر الخدمة وأعد إجراء الضرب: عدد GPUs مضروباً في عدد الساعات ثم في السعر. الغرض من المخطط هو توضيح النسبة. تشغيل عقدة تضم 8 GPUs لمدة أربع ساعات يومياً يكلّف 2,400 USD شهرياً، بينما يكلّف إبقاء إعداد SGLang بحجم 32 GPU قيد التشغيل 57,600 USD.

ينشر كلا الخادمين الشائعين أمر تشغيل في بطاقة النموذج.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

لا تستخدم أيّاً من الأمرين المجردين في عنقود حقيقي. أضف أعلام التوازي التي تطابق عتادك: يستخدم SGLang --tp-size للتوازي الموترِي و--ep-size للتوازي الخبيرِي، ويجب أن يساوي حاصل ضربهما عدد GPUs المتاحة فعلياً لديك.

تحقق من بدء الخادم قبل إرسال حركة مرور فعلية إليه:

curl http://127.0.0.1:30000/v1/models

يرد الخادم السليم بكائن JSON يسرد معرّف النموذج. يعني Connection refused أن العملية ما زالت تحمّل الأوزان أو أنها خرجت بالفعل، لذلك اقرأ سجل الخادم قبل إعادة المحاولة.

العطل الشائع في اليوم الأول هو استخدام runtime أقدم من النموذج. صدر K3 مع KDA وطبقة MoE جديدة لم تكن إصدارات vLLM وSGLang المستقرة تدعمها عند الإطلاق، وتظهر المشكلة بخروج الخادم أثناء بدء التشغيل مع سطر من الشكل Model architectures [...] are not supported for now. لا يصلح أي تغيير في الإعدادات ذلك، لأن الكود اللازم لتشغيل تلك الطبقات غير موجود في الإصدار الذي بنيته. ثبّت إصدار nightly الذي تحدده بطاقة النموذج، أو انتظر الإصدار الذي يتضمنه.

هناك ملاحظة مهمة بشأن التكلفة. يبدأ احتساب التكلفة عند بدء instance، وليس عند جاهزية النموذج. يستغرق تنزيل بحجم 1.5 TB بسرعة 1 GB/s نحو 25 دقيقة من وقت العنقود قبل ظهور أول token. جهّز الأوزان على volume يستمر بعد إيقاف instance، حتى يبدأ التشغيل الثاني خلال دقائق.

المستوى 2: تشغيل نموذج أصغر على مسرّع واحد

لن تشغّل K3 في هذا المستوى. صرّح بذلك بوضوح قبل أن تبدأ، لأن معظم النقاشات حول «تشغيل K3 محلياً» تنتهي هنا من دون الاعتراف بذلك.

قاعدة الملاءمة هي الصيغة نفسها ولكن على نطاق أصغر: يجب أن تكون قيمة عدد المعاملات مضروبة في عدد البايتات لكل وزن، مضافاً إليها ذاكرة KV cache وحوالي 2 GB من الحمل الزائد لوقت التشغيل، أقل من VRAM المتاحة لديك. عند 4-bit، يعادل ذلك تقريباً نصف بايت لكل معامل، ما يوفّر التوافقات المريحة التالية:

• بطاقة بسعة 16 GB: نموذج 7B بدقة 4-bit مع مساحة لسياق طويل
• بطاقة بسعة 24 GB: نموذج 14B بدقة 4-bit
• بطاقة بسعة 48 GB: نموذج 32B بدقة 4-bit
• بطاقة بسعة 80 GB: نموذج 70B بدقة 4-bit، أو نموذج MoE من فئة 30B بدقة 8-bit

يفترض كل توافق أعلاه معالجة طلب واحد في كل مرة. وبمجرد أن يرسل شخص ثانٍ طلباً، تحتاج كل خانة متزامنة إلى ذاكرة KV cache خاصة بها. وهذا هو المقابل الذي تحدده لك إعدادات NUM_PARALLEL وMAX_QUEUE في Ollama بين الخانات المتوازية والطلبات الموضوعة في قائمة الانتظار وVRAM المتبقية لديك.

يمثل Ollama أقصر طريق إلى خادم يعمل على VPS متصل بمسرّع GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ينزّل ollama run النموذج عند الاستخدام الأول، ثم يفتح لك موجه الأوامر. إذا لم تكن العلامة موجودة، يعرض Error: model "..." not found. لذلك انسخ العلامات من صفحة المكتبة بدلاً من كتابتها من الذاكرة. يشرح تشغيل Ollama على VPS المسار الكامل، بما في ذلك وحدة systemd والوصول عن بُعد.

يوفّر llama.cpp تحكماً أكبر في quantisation وoffload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

يطلب -ngl 99 تحميل كل طبقة على GPU. اقرأ سجل التحميل؛ فهو يطبع عدد الطبقات التي جرى تحميلها إلى GPU. تعمل الطبقات التي تنتقل إلى ذاكرة RAM النظامية بسرعة نطاق RAM بدلاً من سرعة نطاق HBM، لذلك تنخفض سرعة التوليد بمقدار رتبة عشرية فور توقف النموذج عن الملاءمة. يشرح Ollama وllama.cpp جنباً إلى جنب المفاضلات بين الأداتين.

المستوى 3: واجهة API مستضافة، وتنسيق مستضاف ذاتياً

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

نقطة النهاية متوافقة مع OpenAI، لذلك يعمل العميل الحالي بعد تغيير عنوان URL الأساسي.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

يعيد المفتاح العامل كائن JSON يتضمن مصفوفة choices. يشير 401 إلى أن المفتاح غير صحيح أو أن البادئة Bearer مفقودة. يعني خطأ عدم العثور على النموذج عادةً أن المعرّف تغيّر، لأن موفري الخدمة يوقفون المعرّفات بين نقاط التحقق.

نقطة التعادل هنا محسوبة باستخدام معدل الاستئجار المفترض أعلاه. تكلّف عقدة تضم 8 وحدات GPU وتعمل باستمرار 14,400 USD شهرياً، وبسعر 15.00 USD لكل مليون رمز إخراج، يشتري المبلغ نفسه نحو 960 مليون رمز إخراج من واجهة API. لكي تحقق وفراً في التكلفة، يجب أن تنتج ما يقارب مليار رمز إخراج شهرياً، أي نحو 30 مليوناً يومياً، وأن تُبقي العنقود مشغّلاً بكامل طاقته طوال الوقت، لأن وحدات GPU الخاملة تُحاسَب بالمعدل نفسه المطبّق على الوحدات المشغّلة. وتدفع أعباء عمل الوكلاء التي تعتمد بكثافة على المطالبات نقطة التعادل إلى مسافة أبعد: إذ تُحاسَب السياقات المتكررة وفق معدل إصابة الذاكرة المؤقتة البالغ 0.30 USD لكل مليون، بدلاً من معدل عدم الإصابة البالغ 3.00 USD.

ما تستضيفه ذاتياً في هذا المستوى هو كل ما يحيط بالنموذج: بوابة تحتفظ بمفتاح API بحيث لا يصل أبداً إلى العميل، وسجلات للطلبات والاستجابات، وإعادات المحاولة، وحدود المعدل، وميزانيات لكل مستخدم. يعمل ذلك على VPS صغيرة من دون أي وحدة GPU. وينطبق التقسيم نفسه على الأوزان المغلقة، إذ إن الاستضافة الذاتية لـ Claude غير ممكنة على مستوى النموذج، ويكون التنسيق هو الجزء الوحيد الذي تملكه.

أي حزمة تقديم تنتمي إلى أي مستوى

تنتمي خوادم vLLM وSGLang إلى المستوى 1. وهي مصممة لتقديم الخدمة لطلبات كثيرة في الوقت نفسه، باستخدام التجميع المستمر وذاكرة KV مؤرشفة بالصفحات، إضافة إلى التوازي على مستوى الموترات والخبراء الموزَّع عبر عدة عقد. وهي تفترض وجود مسرّعات في مركز بيانات واتصال سريع بينها. أما على بطاقة استهلاكية واحدة، فتكون أثقل في التثبيت، ولا تمنحك سوى فوائد محدودة يمكن ملاحظتها.

ينتمي llama.cpp وOllama إلى المستوى 2. وهما يستهدفان جهازاً واحداً، وتكميم GGUF، وتفريغاً إلى CPU عندما لا يتسع النموذج، وتزامناً منخفضاً. يستطيع llama.cpp من الناحية التقنية تحميل نموذج MoE ضخماً جداً عبر إبقاء معظم الطبقات في ذاكرة RAM للنظام، لكن مسار تشغيل نموذج بحجم 2.8T يستغرق ثواني لكل token. وهذا يثبت أن الملف قابل للتحليل. لكنه ليس خدمة يمكنك إتاحة استخدامها للمستخدمين. ترد المقارنة الكاملة في Ollama مقابل vLLM، ولا تتغير هذه المقارنة بتغير النموذج: السؤال دائماً هو ما إذا كنت تقدّم الخدمة لعدة مستخدمين على عتاد مشترك، أم لمستخدم واحد على جهازك.

الأرقام الأربعة التي تبقى صالحة بعد هذه المرحلة

1. يحدد ضرب إجمالي المعاملات في عدد البايتات لكل وزن الحد الأدنى للذاكرة. لا يمكن تشغيل النموذج بأقل منه، ولا تغيّر حيلة quantisation هذا الحد كثيراً عندما يكون الإصدار قد أصبح يعمل بـ4-bit.
2. تحدد المعاملات النشطة فئة معدل المعالجة. يحسب نموذج MoE بحجم 2.8T ومعاملات نشطة بحجم 104B مثل نموذج بحجم 104B.
3. إنّ حاصل ضرب ذاكرة KV cache لكل token في طول السياق وفي عدد الاتصالات المتزامنة هو التكلفة التي تواصل الارتفاع بعد دفع تكلفة الأوزان.
4. تمثل tokens per second per dollar الرقم الوحيد الذي يحدد الفئة المناسبة. وكل ما سبق يدخل في حسابه.

طبّق هذه الأرقام الأربعة على أي إصدار، وستصل إلى الإجابة الصحيحة قبل فتح دليل المورّد. ثم حدّد تاريخ كل رقم تكتبه. تغيّرت الأسعار وقوائم البنى المدعومة خلال الأسبوعين التاليين لإطلاق K3، وكل رقم في هذه الصفحة نُشر في July 2026.

FAQ

هل يمكنني تشغيل Kimi K3 على GPU واحد؟

لا. يبلغ حجم الأوزان نحو 1.4 TB عند استخدام دقة MXFP4 التي تطلقها Moonshot، بينما تبلغ سعة أكبر accelerator واحد متاح للبيع 288 GB. لا يستطيع نموذج MoE تحميل الخبراء غير النشطين من القرص بالسرعة اللازمة، لأن router قد يختار أي خبير مع أي token، كما أن جلب البيانات عبر PCIe يستغرق وقتاً أطول بكثير من الميزانية الزمنية المتاحة للـtoken. الحد الأدنى العملي لنشر K3 هو node متعدد الـGPU، وتستخدم الوصفات المنشورة 32 accelerator أو أكثر.

ما مقدار VRAM الذي يحتاج إليه Kimi K3؟

ابدأ بـ1.4 TB للأوزان وحدها، أي ما يعادل 18 بطاقة H100 بسعة 80GB أو 5 بطاقة من فئة GB300. ثم أضف ذاكرة KV cache وذاكرة activations. اعتباراً من August 2026، توصي Moonshot باستخدام 64 accelerator أو أكثر، كما ينشر SGLang cookbook إعداداً يضم 32 GPU من نوع H100 بإجمالي 2,560 GB، لذلك اعتبر حجم الأوزان حداً أدنى لا متطلباً كافياً.

هل تجعل quantisation نموذج Kimi K3 مناسباً لـnode واحد؟

ليس بشكل مفيد. فالـcheckpoint المنشور يستخدم quantisation بواقع 4-bit مع quantisation-aware training، ولذلك استُنفد التوفير السهل. يؤدي خفضها مرة أخرى إلى 2-bit إلى جعل حجم الأوزان 0.7 TB، وهو ما يزال أكثر من ضعف سعة أكبر بطاقة، كما لم تُقَس تكلفة 2-bit على مستوى الدقة في هذا النموذج.

هل استئجار GPU أرخص من استخدام Kimi K3 API؟

فقط عند وجود حجم استخدام كبير ومستقر. بافتراض تكلفة قدرها 2.50 USD لكل GPU hour، تبلغ تكلفة node يضم 8 GPU ويعمل دائماً 14,400 USD شهرياً، ويتيح المبلغ نفسه شراء نحو 960 million output tokens بالسعر المنشور البالغ 15.00 USD لكل million. وستدفع أيضاً مقابل الساعات الخاملة وتنزيل الأوزان والشخص المسؤول عن إبقاء cluster قيد التشغيل. استأجر GPU بالساعة للأحمال المتقطعة، وقارن التكلفة بحجم الـtoken الذي تقيسه فعلياً بدلاً من الاعتماد على تقدير.

ماذا تعني عبارة 104B active parameters من حيث السرعة؟

تعني أن العمليات الحسابية لكل token تعادل عمليات نموذج بحجم 104B، لذلك يقع معدل المعالجة ضمن هذه الفئة لا فئة 2.8T. ولا تقول العبارة شيئاً عن الذاكرة، إذ تبقى جميع المعاملات البالغ عددها 2.8T محمّلة في الذاكرة، لأن router يستطيع استدعاء أي expert مع أي token. استخدم عدد المعاملات النشطة لتقدير عدد الـtokens في الثانية، واستخدم العدد الإجمالي لتحديد حجم VRAM المطلوب.