كيف تحقق تحسينات NIM لكامل المكدس مستخدمين أكثر بمقدار 2.5 ضعف على Nemotron 3 Ultra

كيف تحقق تحسينات NIM متكاملة Stack زيادة 2.5x في المستخدمين على Nemotron 3 Ultra

تشير مدونة NVIDIA للذكاء الاصطناعي إلى أن تحسينات NIM متكاملة Stack تحقق زيادة 2.5x في المستخدمين على Nemotron 3 Ultra. تحتوي هذه الجملة الواحدة على ثلاث ادعاءات يسهل الخلط بينها: نطاق التحسين ("متكامل Stack")، ونتيجة السعة ("2.5x المزيد من المستخدمين")، وهدف محدد (Nemotron 3 Ultra المُقدَّم عبر NIM). تعتمد قيمة النتيجة بالكامل على إبقاء هذه الثلاثة منفصلة.

تشرح هذه المقالة ما يعنيه ادعاء التحسين "متكامل Stack" لنشر خدمة استنتاج، وتستعرض الطبقات العملية التي تقوم بتهيئتها فعليًا، وتقدم خطوات التثبيت والتهيئة والقياس التي يمكنك تشغيلها على عتادك الخاص. الرقم الرئيسي مُبلَّغ من قبل المورّد من مصدر أساسي واحد؛ والهدف هنا هو مساعدتك على فهم الآلية بما يكفي لاختبارها مقابل عبء العمل الخاص بك.

ما الذي يقيسه رقم 2.5x فعليًا

عبارة "المزيد من المستخدمين" هي مقياس سعة، وليست مقياس جودة. لا شيء في الادعاء يشير إلى أن Nemotron 3 Ultra ينتج إجابات أفضل بعد التحسين. الادعاء هو أن نفس البصمة العتادية يمكنها خدمة ما يقارب 2.5 ضعف عدد المستخدمين المتزامنين — بافتراض الحفاظ على زمن الاستجابة والإنتاجية ضمن حدود مستوى الخدمة المقبولة.

هذا التمييز مهم عمليًا. يحتوي نظام الاستنتاج على ثلاثة متغيرات متنافسة على الأقل:

• التزامن (Concurrency): عدد الطلبات قيد التنفيذ في وقت واحد.
• زمن الاستجابة (Latency): المدة التي يستغرقها كل طلب، ويُقاس عادةً عند p50 و p95/p99.
• التكلفة لكل رمز (Cost per token): مقدار وقت GPU الذي يستهلكه كل رمز مُولَّد.

يمكنك دائمًا زيادة التزامن عبر إضعاف زمن الاستجابة. ويمكنك دائمًا تقليل زمن الاستجابة برفض التزامن. ادعاء سعة 2.5x لا يكون ذا معنى إلا عندما يحدد القيد الذي بقي ثابتًا. في منشور مدونة مورّد، القيد الثابت الأرجح هو هدف زمن الاستجابة أو تهيئة عتادية؛ وإذا اختلف SLO الخاص بك، فسيختلف مضاعفك أيضًا.

تفسير، وليس حقيقة مُتحقَّقًا منها: يجب التعامل مع رقم 2.5x كنتيجة مُبلَّغة من المورّد قيست في ظروف موصوفة في المنشور الأصلي. تعميمه على عنقودك يتطلب إعادة إنتاج تلك الظروف، ولهذا فإن قسم القياس أدناه لا يقل أهمية عن قسم التثبيت.

لماذا "متكامل Stack" هي الكلمة المحورية

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

يشير تأطير "متكامل Stack" في منشور NVIDIA إلى ذلك التأثير التراكمي: تغييرات على مستوى النموذج، ومستوى وقت التشغيل، ومستوى الاستنتاج، ومستوى البنية التحتية تُطبَّق معًا بدلًا من تطبيقها بمعزل عن بعضها. عند تطبيق كل تغيير على حدة، قد يبدو غير ملحوظ. وعند تطبيقها معًا، يمكنها تحويل نقطة تشغيل النظام بأكمله.

النموذج الذهني المفيد هو سلسلة من الأنابيب. تُحدَّد إنتاجية السلسلة بأضيق أنبوب. التحسين المتكامل Stack يعني توسيع كل أنبوب بالتناسب تقريبًا، بحيث لا يهيمن أي أنبوب بمفرده.

الطبقات في Stack استنتاج NIM

تُغلِّف NIM (NVIDIA Inference Microservices) نموذجًا مع وقت تشغيل وواجهة HTTP داخل حاوية. عندما يتحدث الناس عن تحسين "الـ Stack"، فإنهم عادةً يقصدون مجموعة فرعية من هذه الطبقات:

1. طبقة النموذج ونقطة الحفظ (Checkpoint). دقة الأوزان، وتنسيق التكميم (Quantization)، وأي kernels خاصة بالمعمارية. التغييرات هنا تُغيّر كلًا من البصمة الذاكرية والإنتاجية الحسابية.

2. طبقة وقت التشغيل والـ Kernel. محرك الاستنتاج، والـ kernels المدمجة، وتطبيقات الانتباه، ومخصصات الذاكرة. هنا عادةً يُكسَب أو يُخسَر زمن الاستجابة لكل رمز.

3. طبقة الاستنتاج (Serving). التجميع المستمر (Continuous batching)، وجدولة الطلبات، وإدارة وترقيم صفحات KV cache، والتخزين المؤقت للبادئات (Prefix caching)، والتحكم في القبول. هنا عادةً يُكسَب أو يُخسَر التزامن.

4. طبقة البنية التحتية. طوبولوجيا GPU، والتوازي الموترِي (Tensor parallelism) عبر الأجهزة، وعرض نطاق الربط البيني، ومسارات النقل بين CPU و GPU، وتحجيم ذاكرة المضيف.

5. طبقة العميل والتطبيق. المهلات (Timeouts)، وسلوك إعادة المحاولة، وتجميع الاتصالات (Connection pooling)، والبث (Streaming)، وأحجام الحمولات. العميل الذي يفتح اتصال TLS جديدًا لكل طلب يمكنه محو المكاسب من جانب الخادم.

تقع نتيجة 2.5x عند تقاطع الطبقات 2 حتى 4. الطبقة 5 هي الأكثر تجاهلًا من قبل الفرق التي تفشل بعد ذلك في إعادة إنتاج أرقام المورّد.

المتطلبات

قبل تشغيل أي شيء، تأكد من وجود خط أساسي عامل. ستحتاج إلى:

• عتاد NVIDIA GPU بذاكرة إجمالية كافية لاستيعاب النموذج بالإضافة إلى هامش KV cache.
• برنامج تشغيل NVIDIA متوافق مثبَّت على المضيف.
• Docker (أو وقت تشغيل حاويات متوافق) مثبَّت وقيد التشغيل.
• NVIDIA Container Toolkit، حتى تتمكن الحاويات من الوصول إلى وحدات GPU.
• مفتاح NGC API، إذا كانت حاوية النموذج تُسحَب من سجل NVIDIA.
• Python 3.9+ مع requests (أو عميل متوافق مع OpenAI) للاختبار.
• SLO محدد لزمن الاستجابة — بدونه، تكون عبارة "2.5x المزيد من المستخدمين" غير قابلة للتكذيب.

لاحظ أن مسار سجل الحاويات، ووسم النموذج، ومعاملات الضبط المتاحة خاصة بكل نموذج. تستخدم الأوامر أدناه عناصر نائبة حيث تنتمي قيمة خاصة بالنموذج، ويجب عليك ملؤها من وثائق الحاوية نفسها وليس من هذه المقالة.

التثبيت خطوة بخطوة

1. التحقق من GPU وبرنامج التشغيل

ابدأ بتأكيد أن المضيف يرى وحدات GPU ويُبلّغ عن إصدار برنامج التشغيل.

nvidia-smi

إذا فشل هذا، فحل مشكلة تثبيت برنامج التشغيل قبل المتابعة. لن يعمل أي شيء لاحق.

2. التحقق من Docker

تحقق من تثبيت Docker وإمكانية الوصول إلى الخفي (Daemon).

docker --version && docker info | head -n 20

3. تثبيت NVIDIA Container Toolkit

ثبّت الـ toolkit الذي يسمح لـ Docker بكشف وحدات GPU للحاويات. على Debian/Ubuntu اسم الحزمة هو nvidia-container-toolkit؛ اتبع وثائق toolkit الخاصة بـ NVIDIA لإعداد المستودع الدقيق لتوزيعتك.

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

4. تهيئة Docker لاستخدام وقت تشغيل NVIDIA

وجّه خفي Docker إلى وقت تشغيل NVIDIA، ثم أعد تشغيله.

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

5. تأكيد الوصول إلى GPU من داخل حاوية

شغّل حاوية بسيطة وتحقق من عمل nvidia-smi في سياق الحاوية. اختر وسم قاعدة CUDA متوافقًا مع برنامج التشغيل الخاص بك.

docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

<!-- -->

export NGC_API_KEY="<your-ngc-api-key>"

6. المصادقة على سجل الحاويات

سجّل الدخول إلى سجل NVIDIA باستخدام مفتاح API الخاص بك. اسم المستخدم الحرفي $oauthtoken هو الاصطلاح الموثَّق.

echo "$NGC_API_KEY" | docker login nvcr.io --username '$oauthtoken' --password-stdin

7. تجهيز ذاكرة تخزين مؤقت دائمة للنموذج

عادةً ما تخزّن حاويات NIM الأوزان المُنزَّلة مؤقتًا على وحدة تخزين مُثبَّتة (Volume) بحيث لا تُعاد عملية التنزيل عند إعادة التشغيل. أنشئ الدليل وصدّر مساره.

export LOCAL_NIM_CACHE="$HOME/.cache/nim"
mkdir -p "$LOCAL_NIM_CACHE"

8. تشغيل حاوية NIM

شغّل الحاوية مع ذاكرة تخزين مؤقت مُثبَّتة، ومفتاح API المُمرَّر من البيئة، ومنفذ منشور، وذاكرة مشتركة بحجم كافٍ لوقت التشغيل. استبدل مرجع الصورة بمرجع نموذجك.

docker run --rm --runtime=nvidia --gpus all \
  --shm-size=16g \
  -e NGC_API_KEY \
  -v "$LOCAL_NIM_CACHE:/opt/nim/.cache" \
  -p 8000:8000 \
  nvcr.io/nim/<org>/<model>:<tag>

سيؤدي التشغيل الأول إلى تنزيل الأوزان وقد يستغرق عدة دقائق. تعيد عمليات التشغيل اللاحقة استخدام الذاكرة المؤقتة.

التهيئة لتزامن أعلى

توجد معظم المقابض ذات الصلة بالتزامن في طبقتي وقت التشغيل والاستنتاج. عادةً ما تكشفها الحاوية كمتغيرات بيئية أو كإعداد ملف تعريف (Profile). الأسماء الدقيقة موثَّقة لكل نموذج، لكن الفئات متسقة:

• الحد الأقصى لطول التسلسل. تحديد طول السياق يقلل البصمة الذاكرية لـ KV cache لكل طلب، مما يزيد مباشرةً عدد الطلبات التي تتسع في الذاكرة. غالبًا ما يكون هذا الإعداد الأعلى تأثيرًا للتزامن.
• ميزانية ذاكرة KV cache. حجز جزء من ذاكرة GPU صراحةً لـ KV cache يمنع المخصص من التجزؤ أو الفيضان تحت الحمل.
• حدود حجم الدفعة (Batch size). يتيح التجميع المستمر للطلبات الجديدة الانضمام إلى دفعة قيد التنفيذ. رفع السقف يساعد الإنتاجية لكنه قد يضر بزمن الاستجابة الطرفي؛ وخفضه يفعل العكس.
• درجة التوازي الموترِي (Tensor parallel degree). بالنسبة للنماذج التي لا تتسع على جهاز واحد، فإن تقسيمها عبر وحدات GPU يغيّر كلاً من هامش الذاكرة والحساسية للربط البيني.
• اختيار GPU. التثبيت على أجهزة محددة يمنع تأثيرات الجار الصاخب على المضيفين المشتركين.

النمط العملي هو تمرير هذه كمتغيرات بيئية عند التشغيل والاحتفاظ بها في ملف مُدار بنظام التحكم في الإصدارات بدلًا من سجل الأوامر (Shell history):

docker run --rm --runtime=nvidia --gpus '"device=0,1"' \
  --shm-size=32g \
  -e NGC_API_KEY \
  -e MAX_SEQUENCE_LENGTH=8192 \
  -e KV_CACHE_FRACTION=0.85 \
  -v "$LOCAL_NIM_CACHE:/opt/nim/.cache" \
  -p 8000:8000 \
  nvcr.io/nim/<org>/<model>:<tag>

غيّر متغيرًا واحدًا في كل مرة، وسجّل توزيع زمن الاستجابة عند كل خطوة. ضبط التزامن دون قياس هو تخمين.

أمثلة الاستخدام

التحقق من أن الخدمة تعمل

اعرض قائمة النماذج المُقدَّمة لتأكيد صحة الحاوية وتحميل النموذج.

curl -s http://localhost:8000/v1/models | python -m json.tool

إرسال طلب إكمال واحد

أرسل طلب إكمال محادثة متوافقًا مع OpenAI وافحص استجابة JSON الخام.

curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
        "model": "nemotron",
        "messages": [{"role": "user", "content": "Explain prefix caching in one paragraph."}],
        "max_tokens": 128
      }' | python -m json.tool

يجب أن تتطابق قيمة model مع المعرّف الذي يُرجعه endpoint الخاص بـ /v1/models.

استدعاء endpoint من Python

لتكامل التطبيق، استخدم عميلًا مع إعادة استخدام الاتصال بدلًا من إنشاء جلسة جديدة لكل استدعاء.

import requests

session = requests.Session()
response = session.post(
    "http://localhost:8000/v1/chat/completions",
    json={
        "model": "nemotron",
        "messages": [{"role": "user", "content": "Summarize KV cache paging."}],
        "max_tokens": 128,
    },
    timeout=120,
)
response.raise_for_status()
print(response.json()["choices"][0]["message"]["content"])

قياس منحنى التزامن

الاختبار الأكثر فائدة هو المسح (Sweep): أبقِ حمولة الطلب ثابتة وزد التزامن، مع تسجيل معدل النجاح ومئينات زمن الاستجابة عند كل خطوة. النقطة التي يتجاوز فيها زمن الاستجابة p95 مستوى SLO الخاص بك هي سعتك الفعلية.

import concurrent.futures
import time
import requests

URL = "http://localhost:8000/v1/chat/completions"
PAYLOAD = {
    "model": "nemotron",
    "messages": [{"role": "user", "content": "Write two sentences about batching."}],
    "max_tokens": 128,
}

def one_call(_):
    start = time.perf_counter()
    try:
        r = requests.post(URL, json=PAYLOAD, timeout=180)
        return r.status_code, time.perf_counter() - start
    except requests.RequestException:
        return 0, time.perf_counter() - start

def sweep(concurrency, total=64):
    with concurrent.futures.ThreadPoolExecutor(max_workers=concurrency) as pool:
        results = list(pool.map(one_call, range(total)))
    latencies = sorted(d for s, d in results if s == 200)
    if not latencies:
        print(f"concurrency={concurrency}: all requests failed")
        return
    p50 = latencies[len(latencies) // 2]
    p95 = latencies[int(len(latencies) * 0.95) - 1]
    print(f"concurrency={concurrency:>3} ok={len(latencies):>3}/{total} "
          f"p50={p50:.2f}s p95={p95:.2f}s")

for c in (1, 2, 4, 8, 16, 32):
    sweep(c)

شغّل هذا مقابل تهيئة غير محسَّنة أولًا، ثم مقابل تهيئة مضبوطة. النسبة بين مستويي التزامن عند سقف زمن الاستجابة الخاص بك هي مضاعفك الخاص — والذي قد يشبه 2.5x أو قد لا يشبهه.

كيفية التحقق من المكسب على عبء العمل الخاص بك

تُشغَّل معايير المورّد عادةً على عتاد مُتحكَّم فيه مع توزيعات طلبات مُتحكَّم فيها. من غير المرجح أن تطابق حركة المرور الخاصة بك ذلك. للحصول على رقم قابل للدفاع عنه:

1. جمّد توزيع الطلبات. خذ عينات من مطالبات حقيقية من الإنتاج وأعد تشغيلها، بدلًا من استخدام مطالبات تركيبية من جملة واحدة.
2. ثبّت سقف زمن الاستجابة. حدد p95 الذي يمكنك تحمله قبل بدء الاختبار.
3. غيّر طبقة واحدة في كل مرة. أنشئ خط الأساس، ثم طبّق تغييرات النموذج ووقت التشغيل والاستنتاج والبنية التحتية بالتسلسل، مع تسجيل السعة بعد كل تغيير.
4. راقب تحرك السقف. إذا توقفت السعة عن التحسن، فقد وصلت إلى اختناق جديد — غالبًا CPU المضيف أو الشبكة أو حدود اتصال جانب العميل بدلًا من GPU.
5. كرر التشغيلات. معايير الاستنتاج حساسة للإحماء (Warmup) وحالة الذاكرة المؤقتة وسلوك الساعة.

الحفاظ على توزيع الطلبات وسقف زمن الاستجابة ثابتين هو ما يحوّل رقمًا تسويقيًا إلى نتيجة هندسية.

الحدود والأسئلة المفتوحة

بعض التحفظات الصادقة حول هذا الموضوع:

• دليل من مصدر واحد. يأتي رقم 2.5x من منشور مدونة مورّد واحد. لم يُكرَّر بشكل مستقل هنا، وظروف المعيار الأساسية غير معاد ذكرها في هذه المقالة.
• الخصوصية العتادية. المضاعفات من هذا النوع مرتبطة بتهيئة GPU محددة وحجم نموذج ومزيج طلبات محدد. عند تطبيقها على نشر مختلف، من المرجح أن يتحرك الرقم في أي من الاتجاهين.
• تعريف "المستخدمين". المصطلح غير موحَّد. قد يعني جلسات متزامنة، أو طلبات في الثانية، أو عملاء مميزين خلال فترة زمنية. كل منها يستلزم قياسًا مختلفًا.
• متانة التحسين. الضبط المتكامل Stack يعتمد على التهيئة. تحديث حاوية، أو تغيير برنامج تشغيل، أو تحول في شكل حركة المرور يمكن أن يُبطل معاملات مضبوطة بعناية.
• لا غداء مجاني في زمن الاستجابة. زيادة السعة تعني عادةً قبول زمن استجابة أعلى قليلًا لكل طلب. يجب اختيار المقايضة بشكل متعمد، لا اكتشافها في الإنتاج.

لا يجعل أي من هذه التحفظات النتيجة غير مثيرة للاهتمام. إنها ببساطة تحدد الحدود التي يكون فيها الادعاء قابلًا للاستخدام.

الخاتمة

من الأفضل قراءة عنوان 2.5x من منشور NVIDIA كنتيجة أنظمة، وليس نتيجة نموذج. Nemotron 3 Ultra هو عبء العمل المستهدف؛ وNIM هي آلية التسليم؛ و"متكامل Stack" تصف نطاق الضبط؛ و"المزيد من المستخدمين" تصف السعة تحت قيد يحدده المنشور الأصلي.

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

ثبّت الـ toolkit، وأقم الحاوية، وامسح التزامن، واعثر على سقفك الخاص. المضاعف الذي تقيسه على عتادك تحت حركة المرور الخاصة بك هو الوحيد المهم لتخطيط سعتك.