שירות LLM מוכן לייצור על חומרת GPU ייעודית: פתרון מפתח

צוות סטארטאפ של שלושה אנשים פרס Llama-3-70B על A100 80GB בודד — והמודל קרס עם CUDA OOM בכל בקשה שנייה. הבעיה לא הייתה ב-GPU, אלא בתצורה: vLLM הקצה 0.95 מזיכרון ה-GPU ל-KV-cache, ולא הותיר מרווח לשינויים באורך הקונטקסט. עברנו ל-gpu-memory-utilization של 0.85 והפעלנו swapping דרך CPU — הקריסות פסקו. מצבים כאלה הם העבודה היומיומית שלנו. בשנים האחרונות פרסנו יותר מ-30 מערכות אינפרנס production של Large language model על שרתי GPU ייעודיים (on-premise או bare metal) ואנחנו מבטיחים עבודה יציבה גם בעומסי שיא.

שרת ייעודי נותן ביצועים צפויים, ללא cold start ושליטה מלאה על הנתונים. זה הבחירה האופטימלית לתרחישים בעלי עומס גבוה עם דרישות ל-data residency או pipelines מותאמים אישית.

בעיות שאנחנו פותרים

שגיאה בחישוב VRAM. לדוגמה, Llama-3-70B ב-BF16 דורש 140 GB — לא כל שרת יכול לעמוד בזה. אנחנו משתמשים ב-quantization (AWQ/GPTQ) ו-tensor parallelism כדי לנצל משאבים בצורה אופטימלית. Mixtral-8x7B (MoE) מפעיל רק 13B פרמטרים, אבל דורש 90 GB VRAM — נכנס בקלות על 2×A100 80GB אחרי קוונטיזציה של 4 ביט.

קריסת שירות ב-OOM. על קונטקסטים ארוכים (>16k טוקנים) vLLM עלול לקרוס. הפתרון — הגדרת max-model-len ו-gpu-memory-utilization יחד עם שירות systemd שמאתחל את התהליך אוטומטית במקרה של כשל. בנוסף, אנו מתקינים סקריפט watchdog שבודק את ה-health endpoint.

השבתה בעדכון מודל. ללא blue-green deployment כל עדכון הוא downtime. אנחנו מריצים גרסה חדשה על פורט אחר, בודקים, ואז מעבירים את nginx upstream — אין downtime.

איך לבחור GPU למודל שלך?

בחירת ה-GPU תלויה בגודל המודל וב-latency הנדרש. הנה טבלת המלצות למודלים פופולריים:

קוונטיזציה ל-INT4/INT8 מפחיתה את דרישות ה-VRAM פי 3-4, מה שמאפשר להכניס מודל 70B על 2×A100.

למה vLLM נבחר יותר לרוב ל-production?

vLLM משתמש ב-PagedAttention — ניהול יעיל של KV-cache, מה שנותן 20-50% יותר throughput בגדלי batch קטנים. בבenchmark שלנו על Llama-3-8B עם קוונטיזציית AWQ: vLLM נתן 1200 טוקנים/שנייה לעומת 800 ב-TGI (batch=32). עם זאת, TGI מתמודד טוב יותר עם קונטקסט ארוך (≥32k טוקנים) בזכות tensor parallelism אגרסיבי יותר.

אם התרחיש שלך הוא צ'אט מקוון עם בקשות קצרות, בחר ב-vLLM. אם צריך לעבד מסמכים רב-עמודיים — TGI.

מה לעשות במקרה של OOM?

ב-OOM קודם כל בדוק את gpu-memory-utilization — לעתים קרובות הוא מוגדר גבוה מדי. הערך המומלץ הוא 0.85-0.90, והשאר ל-CPU swap. כמו כן, הגדר את max-model-len באופן יחסי לאורך הקונטקסט הממוצע. ב-systemd הוסף Restart=always וסקריפט health-check — השירות יופעל מחדש אוטומטית.

תהליך הפריסה והעדכון

שלבים

1. אנליטיקה — הערכת מודל, RPS צפוי ו-SLA ל-latency. בחירת GPU וקוונטיזציה.
2. תכנון — תצורת tensor parallel, batch size, quantization, בחירת framework.
3. מימוש — התקנת CUDA, דרייברים, פריסת vLLM/TGI כשירות systemd עם watchdog.
4. בדיקות — בדיקות עומס (locust/vegeta), מדידת p99 latency, בדיקת long-tail.
5. פריסה — nginx reverse proxy עם rate limiting, SSL, ניטור Prometheus + Grafana.
6. תיעוד — תיאור endpoints, קונפיגים, נוהל עדכון.

עדכון ללא downtime

blue-green קלאסי: מריצים גרסה חדשה על פורט 8001, בודקים אותה, מעבירים את nginx upstream מפורט 8000 ל-8001, ואז עוצרים את השירות הישן. כל התהליך אורך כ-30 שניות, ועם הגדרת keepalive נכונה המשתמשים לא שמים לב למעבר.

מה כוללת העבודה

• בחירת GPU ותצורת שרת.
• התקנת CUDA, דרייברים (אם צריך — Docker).
• פריסת vLLM/TGI עם systemd + watchdog.
• Nginx reverse proxy עם rate limiting ו-SSL.
• ניטור (Prometheus + Grafana — דשבורדים ל-GPU, latency, throughput).
• עדכון מודל ללא downtime.
• תיעוד והדרכת צוות.
• תמיכה 30 יום לאחר מסירה.

לוחות זמנים: בין 2 ל-7 ימים תלוי במורכבות (זמינות GPU, מספר מודלים, HA). המחיר מחושב באופן אישי — צור קשר להערכת הפרויקט שלך, זה ייקח יום עבודה אחד.

הגדרת שרת ותשתית

תצורת שרת

לפני ההתחלה בדוק את זמינות ה-GPU ואת גרסת הדרייברים:

nvidia-smi nvcc --version 

התקן CUDA 12.1 ו-cuDNN. על Ubuntu 22.04:

apt-get install -y nvidia-driver-545 apt-get install -y cuda-toolkit-12-1 

בדוק את PyTorch: python3 -c "import torch; print(torch.cuda.get_device_name(0))"

פריסת vLLM כשירות systemd

# /etc/systemd/system/vllm-llama.service
[Unit]
Description=vLLM LLaMA-3-8B Inference Server
After=network.target

[Service]
Type=simple
User=mlserving
WorkingDirectory=/opt/vllm
Environment="CUDA_VISIBLE_DEVICES=0,1"
Environment="HF_TOKEN=hf_xxx"
ExecStart=/opt/vllm/venv/bin/python -m vllm.entrypoints.openai.api_server \
    --model /data/models/llama-3-8b-instruct \
    --tensor-parallel-size 2 \
    --max-model-len 8192 \
    --max-num-seqs 128 \
    --gpu-memory-utilization 0.92 \
    --host 127.0.0.1 \
    --port 8000 \
    --log-level info
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Nginx reverse proxy

# /etc/nginx/sites-available/vllm
upstream vllm_backend {
  server 127.0.0.1:8000;
  keepalive 100;
}

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=60r/m;

server {
  listen 443 ssl http2;
  server_name llm.company.internal;

  ssl_certificate /etc/nginx/ssl/cert.pem;
  ssl_certificate_key /etc/nginx/ssl/key.pem;

  location /v1/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://vllm_backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_read_timeout 300s;
    proxy_buffering off;
    chunked_transfer_encoding on;
  }

  location /health {
    proxy_pass http://vllm_backend/health;
  }
}

ניטור והפעלה מחדש אוטומטית

אנו משתמשים ב-Prometheus ו-Grafana עם nvidia_gpu_exporter למעקב אחר טמפרטורת GPU, ניצול VRAM ו-throughput. התראות: טמפרטורה > 85°C, VRAM > 95%, שירות לא זמין > 30 שניות.

systemd Restart=always + סקריפט watchdog שבודק את ה-health endpoint כל 30 שניות. בשלוש ניסיונות כושלים — הפעלה מחדש של השירות.

#!/bin/bash
while true; do
  if ! curl -sf http://127.0.0.1:8000/health > /dev/null; then
    systemctl restart vllm-llama
    echo "$(date) - vLLM restarted" >> /var/log/vllm-watchdog.log
  fi
  sleep 30
done

הניסיון של המהנדסים שלנו — יותר מ-5 שנים ב-ML/infra, יותר מ-30 מערכות אינפרנס שנפרסו. אנו מלווים כל פרויקט עם אחריות על התצורה ותמיכה לאחר הפריסה. אם צריך אינטגרציה עם RAG-pipeline, fine-tuning או MLOps-CI/CD — נדון בייעוץ. קבל הערכה מוקדמת של הפרויקט שלך — צור קשר, נשיב תוך יום.