كيف تستضيف Kimi K3 ذاتياً؟ متطلبات الذاكرة والعتاد

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

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

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

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

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

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

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

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

لذلك تكون تكلفة تشغيله منخفضة، بينما تكون تكلفة تخزينه مرتفعة. حدّد مواصفات العتاد على أساس 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 النظيفة.

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

كم عدد وحدات 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 طبقة و896 خبيراً.

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

ذاكرة 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، ثم ارفع الحد حتى يفشل التخصيص.

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

المستوى 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، وتكون السعة المحجوزة أرخص. استخدم السعر الفعلي لدى مزودك وأعد إجراء العملية الحسابية: عدد وحدات GPU مضروباً في عدد الساعات مضروباً في السعر. الغرض من المخطط هو توضيح النسبة. تشغيل عقدة تضم 8 GPU لمدة أربع ساعات يومياً يكلّف 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 للتوازي الخبير، ويجب أن يساوي حاصل ضربهما عدد وحدات GPU المتاحة فعلياً لديك.

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

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

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

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

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

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

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

قاعدة الملاءمة هي الصيغة نفسها ولكن على نطاق أصغر: يجب أن يبقى حاصل ضرب عدد المعلمات في عدد البايتات لكل وزن، مضافاً إليه مخزن KV المؤقت ونحو 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

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

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

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

يوفّر 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. حاصل ضرب إجمالي عدد المعلمات في عدد البايتات لكل وزن يحدد الحد الأدنى للذاكرة. لا يمكن تشغيل النموذج بأقل منه، ولا يغيّر أي أسلوب تكميم هذا الحد كثيراً عندما يكون الإصدار مضبوطاً مسبقاً إلى 4-bit.
2. تحدد المعلمات النشطة فئة معدل المعالجة. ينفّذ نموذج MoE بحجم 2.8T ومعلمات نشطة بحجم 104B حسابات مماثلة لنموذج بحجم 104B.
3. تمثل ذاكرة KV cache لكل رمز، مضروبة في طول السياق ثم في عدد الطلبات المتزامنة، التكلفة التي تستمر في الارتفاع بعد تخصيص ذاكرة الأوزان.
4. يمثل عدد الرموز في الثانية لكل دولار الرقم الوحيد الذي يحدد الفئة المناسبة. وكل ما سبق يدخل في حسابه.

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

FAQ

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

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

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

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

هل تجعل quantisation تشغيل Kimi K3 على عقدة واحدة ممكناً؟

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

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

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

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

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