הגדלת מודלי שפה גדולים לייצור: מדריך מעשי

מודלי שפה גדולים (LLMs) התפתחו במהירות, ועברו מסקרנות מחקרית לכלי רב עוצמה ליישומים שונים. בעוד שהקמת צ’אטבוט פשוט באמצעות כלים כמו Llama.cpp או Ollama היא יחסית פשוטה, פריסת LLMs בסביבת ייצור כדי להתמודד עם עומסי עבודה בעולם האמיתי מציגה מערכת שונה של אתגרים. אתגרים אלה כוללים ניהול של משתמשים מקבילים מרובים, הבטחת ערבויות זמן פעולה ארוכות ואופטימיזציה של ניצול משאבי GPU כדי להימנע מחריגה ממגבלות התקציב.

המשאבים הנדרשים להגשת LLM בקנה מידה גדול שונים באופן משמעותי מאלה הנדרשים להפעלתו על מחשב אישי. מודל הפועל ביעילות עם פחות מ-4 ג’יגה-בתים של זיכרון במחשב יכול לדרוש 40 ג’יגה-בתים או יותר של זיכרון GPU כאשר הוא נפרס בהגדרת ייצור כדי להתמודד עם בקשות סימולטניות רבות.

מדריך זה בוחן את השדרות להרחבת עומסי עבודה של AI מהוכחות קונספט ראשוניות לפריסות מוכנות לייצור. נדריך אותך בתהליך של פריסת מודלים כמו Gemma 3 או Llama 3 בקנה מידה גדול.

מינוף ממשקי API לשילוב LLM

שילוב LLMs לתוך בסיס קוד ניתן להשגה באמצעות שיטות שונות, אך מומלץ מאוד להשתמש בממשק API תואם OpenAI לפריסות ייצור. גישה זו מספקת את הגמישות להסתגל לנוף המודלים המתפתח במהירות. מודלים שנחשבו לחוד החנית רק לפני חודשים יכולים להתיישן במהירות.

מאז תנופת ה-AI שהחלה עם ChatGPT בשנת 2022, ממשק ה-API של OpenAI הפך לתקן דה פקטו לחיבור יישומים ל-LLMs. תקן זה מאפשר למפתחים לבנות יישומים באמצעות משאבים זמינים, כגון התחלה עם Mistral 7B ב-Llama.cpp במחשב נייד ומעבר חלק לשרתי ה-API של Mistral AI לפריסת ייצור. זה מבטל את הנעילה למודל יחיד, מנוע הסקה או ספק API.

שירותי הסקה מבוססי ענן מספקים אמצעי ידידותי להוצאות הוניות (capex) להרחבת פריסות AI. שירותים אלה מבטלים את הצורך בניהול חומרה ותצורת מודל, במקום זאת מספקים API לשילוב יישומים.

בנוסף להצעות ה-API מבונות מודלים גדולות, מספר גדל והולך של סטארט-אפים בתחום תשתית ה-AI מציעים הסקה כשירות עבור מודלים עם משקלים פתוחים. ספקים אלה משתנים בגישות שלהם. חלקם, כמו SambaNova, Cerebras ו-Groq, ממנפים חומרה מיוחדת או טכניקות כמו פענוח ספקולטיבי כדי להאיץ הסקה, אך מציעים מבחר קטן יותר של מודלים. אחרים, כמו Fireworks AI, תומכים בפריסה של מודלים מותאמים אישית באמצעות מתאמי Low Rank Adaptation (LoRA). מגוון המערכת האקולוגית של ה-AI מחייב מחקר יסודי לפני התחייבות לספק ספציפי.

שיקולים לפריסת LLM מקומית

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

• בחירת מודל: המודל המתאים תלוי במקרה השימוש הספציפי. מודל המיועד לצ’אטבוט שירות לקוחות יהיו לו דרישות שונות ממודל המשמש ליצירת אחזור מוגברת או כעוזר קוד. מומלץ להשקיע זמן עם ספקי API כדי לזהות מודל העונה על הצרכים.
• דרישות חומרה: קביעת החומרה הדרושה היא קריטית, מכיוון ש-GPUs יקרים וקשה לרכוש אותם. המודל עצמו יכול לספק תובנות לגבי החומרה הנדרשת להפעלתו. מודלים גדולים יותר דורשים יותר חומרה. ניתן לחשב אומדן גס של זיכרון ה-GPU המינימלי על ידי הכפלת ספירת הפרמטרים (במיליארדים) ב-2 ג’יגה-בתים עבור מודלים שאומנו בדיוק של 16 ביט. עבור מודלים של 8 ביט, נדרש 1 ג’יגה-בתים למיליארד פרמטרים. טכניקות דחיסת מודלים כמו כימות יכולות לצמצם זאת ל-512 מגה-בתים למיליארד פרמטרים. זוהי מגבלה תחתונה. יש צורך בזיכרון נוסף כדי לשרת את המודל למשתמשים מרובים בו זמנית עקב מטמון מפתח-ערך, המשמש כזיכרון לטווח קצר של המודל. מטריצת התמיכה של Nvidia מציעה הדרכה לגבי ה-GPUs הנדרשים להפעלת מודלים שונים.
• יתירות: בנוסף להתאמת חומרה למודל, יש לקחת בחשבון יתירות. צומת GPU בודדת פגיעה לכשל, ולכן חשוב לפרוס שני מערכות או יותר עבור מעבר לגיבוי בעת כשל ואיזון עומסים.
• שיטות פריסה: ניתן לפרוס ולשרת LLMs בייצור באמצעות שיטות שונות: מתכת חשופה עם מאזני עומסים, מכונות וירטואליות או מכולות בדוקר או בקובנטיס. קובנטיס מפשטת פריסות בקנה מידה גדול על ידי אוטומציה של יצירת מכולות, רשתות ואיזון עומסים.

קובנטיס לפריסת LLM

קובנטיס מפשטת את רוב המורכבות הקשורה לפריסות בקנה מידה גדול על ידי אוטומציה של יצירת מכולות, רשתות ואיזון עומסים. ארגונים רבים כבר אימצו ומבינים את קובנטיס. Nvidia, Hugging Face ואחרים מעדיפים סביבות מכולות עם Nvidia Inference Microservices (NIMs) ו-Hugging Face Generative AI Services (HUGS), המוגדרים מראש עבור עומסי עבודה ופריסות נפוצים.

מנועי הסקה

מנועי הסקה שונים זמינים להפעלת מודלים, כולל Ollama ו-Llama.cpp, התואמים למגוון רחב של חומרה. עבור הגדלת מודלים, ספריות כמו vLLM, TensorRT LLM, SGLang ו-PyTorch משמשות לעתים קרובות. מדריך זה מתמקד בפריסת מודלים באמצעותvLLM,מכיוון שהוא תומך במבחר רחב של מודלים פופולריים ומציע תמיכה ותאימות רחבה בין Nvidia, AMD וחומרה אחרת.

הכנת סביבת קובנטיס

הגדרת סביבת קובנטיס לעבודה עם GPUs דורשת מנהלי התקנים ותלות נוספים בהשוואה להגדרת קובנטיס טיפוסית. תהליך ההתקנה יהיה שונה עבור חומרת AMD ו-Nvidia.

מדריך זה משתמש ב-K3S בתצורה של צומת בודד. השלבים הבסיסיים דומים לסביבות מרובות צמתים, אך יש לעמוד בתלות בכל צומת עובד GPU, וייתכן שתצורת האחסון תדרוש התאמות.

המטרה היא לספק בסיס איתן לפריסת עומסי עבודה של הסקה באופן ידידותי לייצור. הדרישות המוקדמות הבאות נדרשות:

• שרת או תחנת עבודה עם לפחות לוח GPU אחד נתמך של AMD או Nvidia
• התקנה חדשה של Ubuntu 24.04 LTS

תלות Nvidia

הגדרת סביבת K3S מואצת Nvidia דורשת התקנת מנהלי התקנים של CUDA Fabric Manager ומנהלי התקנים של שרת Headless. התקן את כלי השירות של השרת של Nvidia לפתרון בעיות במנהלי התקנים.

התקנת K3S

K3S היא הפצה קלת משקל של קובנטיס, המתאימה ליישומי קצה ולהגדרות משאבים מוגבלים. כדי להתקין K3S עם תמיכה ב-GPU, בצע את השלבים הבאים:

1. התקן את K3S:

   1	curl -sfL https://get.k3s.io | sh -s – –disable traefik –disable servicelb

2. אמת את ההתקנה:

   1	kubectl get nodes

3. התקן את מנהל ההתקן של Nvidia:

לפני שתוכל להשתמש ב-GPUs בקובנטיס, עליך להתקין את מנהל ההתקן של Nvidia.

בדוק את גרסת הליבה שלך לפני התקנת מנהלי התקנים:

1

uname -r

עדכן והתקן תלויות:

1
2

sudo apt update
sudo apt install -y dkms build-essential linux-headers-$(uname -r)

הוסף את מאגר ה-Nvidia PPA:

1
2

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update

התקן את מנהלי ההתקן האחרונים של Nvidia:

1

sudo apt install -y nvidia-driver-550

אמת את התקנת מנהלי ההתקנים:

1

nvidia-smi

4. התקן את סביבת זמן הריצה של מכולות Nvidia (Container Runtime Environment) (CRT):

עליך להתקין את סביבת זמן הריצה של מכולות Nvidia כדי לאפשר לקובנטיס להשתמש ב-GPUs.

1
2
3

distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
&& curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
&& echo "deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://nvidia.github.io/libnvidia-container/$distribution /" | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

1
2

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

1

sudo systemctl restart docker

5. התקן את מנהל ההתקנים של Nvidia:

מנהל ההתקנים של Nvidia מאפשר לקובנטיס לגלות ולנהל את ה-GPUs הזמינים.

1

kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.1/deployments/daemonset.yaml

6. אמת את מנהל ההתקנים:

1

kubectl describe node | grep nvidia.com/gpu

אם הכל פועל כהלכה, אתה אמור לראות את ה-GPU שלך מופיע כמשאב זמין.

פריסת vLLM בקובנטיס

לאחר שהגדרת את סביבת קובנטיס עם תמיכה ב-GPU, אתה יכול לפרוס את vLLM. vLLM הוא מנוע הסקה מהיר ויעיל עבור LLMs.

1. צור מרחב שמות עבור vLLM:

מומלץ ליצור מרחב שמות נפרד עבור פריסות vLLM שלך.

1

kubectl create namespace vllm

2. צור תצורת פריסה:

צור קובץ פריסה (לדוגמה, vllm-deployment.yaml) עם ההגדרה הבאה:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
  namespace: vllm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      runtimeClassName: nvidia
      containers:
      - name: vllm
        image: vllm/vllm:latest
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 1 # Specify the number of GPUs to use
        command: ["python", "-m", "vllm.entrypoints.kubernetes.main"]
        args: ["--model", "mistralai/Mistral-7B-v0.1", "--host", "0.0.0.0", "--port", "8000"]

הסבר:

• apiVersion, kind, metadata: מציינים את גרסת ה-API, הסוג והמטא-נתונים של הפריסה.
• spec.replicas: מציין את מספר הרפליקות של vLLM שיש להפעיל.
• spec.selector: מציין את ה-label selector עבור הפודים שיוגדרו על ידי פריסה זו.
• spec.template.metadata: מציין את המטא-נתונים עבור הפודים, כולל התוויות.
• spec.template.spec.runtimeClassName: מציין את שם מחלקת זמן הריצה עבור הפוד. במקרה זה, אנו משתמשים ב-nvidia כדי לציין שהפוד צריך לפעול עם תמיכה ב-GPU.
• spec.template.spec.containers: מציין את רשימת המכולות להפעלת הפוד. במקרה זה, אנו מפעילים מכולה יחידה בשם vllm.
• spec.template.spec.containers[0].image: מציין את תמונת המכולה לשימוש. במקרה זה, אנו משתמשים בתמונת vllm/vllm:latest.
• spec.template.spec.containers[0].ports: מציין את רשימת היציאות שהמכולה חושפת. במקרה זה, אנו חושפים את יציאה 8000.
• spec.template.spec.containers[0].resources: מציין את בקשות המשאבים והמגבלות עבור המכולה. במקרה זה, אנו מבקשים מגבלה של GPU אחד.
• spec.template.spec.containers[0].command: מציין את הפקודה להפעלת המכולה.
• spec.template.spec.containers[0].args: מציין את הארגומנטים לפקודה.

3. החל את הפריסה:

1

kubectl apply -f vllm-deployment.yaml

4. בדוק את הסטטוס של הפריסה:

1

kubectl get pods -n vllm

ודא שהפוד vLLM נמצא במצב Running.

5. צור שירות כדי לחשוף את vLLM:

כדי לגשת ל-vLLM מחוץ לאשכול קובנטיס, עליך ליצור שירות. צור קובץ שירות (לדוגמה, vllm-service.yaml) עם ההגדרה הבאה:

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: vllm-service
  namespace: vllm
spec:
  selector:
    app: vllm
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
  type: LoadBalancer

הסבר:

• apiVersion, kind, metadata: מציינים את גרסת ה-API, הסוג והמטא-נתונים של השירות.
• spec.selector: מציין את ה-label selector עבור הפודים שאליהם השירות צריך לנתב תעבורה.
• spec.ports: מציין את רשימת היציאות שהשירות חושף. במקרה זה, אנו חושפים את יציאה 80 ואת יציאה 8000, הפונה ליציאה 8000 בפודים.
• spec.type: מציין את סוג השירות. במקרה זה, אנו משתמשים ב-LoadBalancer כדי לחשוף את השירות באופן חיצוני באמצעות מאזן עומסים.

6. החל את השירות:

1

kubectl apply -f vllm-service.yaml

7. בדוק את הסטטוס של השירות:

1

kubectl get service -n vllm

חפש את כתובת ה-External-IP כדי לגשת ל-vLLM.

אינטראקציה עם vLLM

עכשיו כש-vLLM שלך פועל בקובנטיס, תוכל ליצור איתו אינטראקציה.

1. העבר יציאה באופן מקומי:

אם אתה לא משתמש ב-LoadBalancer או בספק ענן, אתה יכול להעביר יציאה באופן מקומי ליציאה 8000 של הפוד vLLM:

1

kubectl port-forward service/vllm-service 8000:80 -n vllm

2. שלח בקשת הסקה:

השתמש בכלי כמו curl כדי לשלוח בקשת הסקה ל-vLLM. החלף את localhost:8000 בכתובת ה-External-IP של השירות שלך אם אתה משתמש ב-LoadBalancer.

1

curl -X POST http://localhost:8000/generate -H "Content-Type: application/json" -d '{"prompt": "The capital of France is", "max_tokens": 20}'

תגובת ה-API תכיל את הטקסט שנוצר.

שיקולים נוספים

• ניטור: הגדר ניטור עבור תשתית קובנטיס שלך ולפריסות vLLM שלך. השתמש במדדים ורישומים כדי לעקוב אחר השימוש במשאבים, ביצועים ושגיאות.
• קנה מידה אוטומטי: יישם קנה מידה אוטומטי כדי להתאים באופן דינמי את מספר הרפליקות של vLLM על סמך עומס התעבורה. השתמש במדדים כמו ניצול GPU ותפוקה כדי להפעיל אירועי קנה מידה.
• אבטחה: אבטח את אשכול קובנטיס ואת נקודות הקצה של ה-API של vLLM. השתמש באימות ובאישור כדי להגביל את הגישה. שקול להשתמש ברשת שירות לניהול תעבורה ויישום מדיניות אבטחה.
• אופטימיזציה: כוונן את התצורה של vLLM ואת פרמטרי ההסקה כדי לייעל את הביצועים. נסה עם גדלים שונים של אצוות, טכניקות קדם-אחזור ושיטות אופטימיזציה של מודלים.

הגדרת תלות AMD

הגדרת סביבת K3S מואצת AMD דורשת התקנת מנהלי התקנים של AMD ROCm ואת סביבת זמן הריצה של מכולות AMD. בצע את השלבים הבאים:

1. התקן את מנהלי התקנים של AMD ROCm:

1
2

wget https://repo.radeon.com/amdgpu-install/latest/amdgpu-install_5.7.1.50701-1_all.deb
sudo apt install ./amdgpu-install_5.7.1.50701-1_all.deb

1

sudo amdgpu-install --usecase=graphics,opencl --rocmrelease=5.7

2. התקן את סביבת זמן הריצה של מכולות AMD:

1
2

sudo apt update
sudo apt install -y rocm-docker

3. הפעל מחדש את שירות הדוקר:

1

sudo systemctl restart docker

4. התקן את מנהל ההתקנים של AMD:

1

kubectl apply -f https://raw.githubusercontent.com/ROCm/k8s-device-plugin/main/rocm-device-plugin.yaml

5. אמת את מנהל ההתקנים:

1

kubectl describe node | grep amd.com/gpu

לאחר מכן, תוכל להמשיך באותם שלבים כמו פריסת Nvidia עבור פריסת vLLM בקובנטיס. הקפד לציין את המשאבים amd.com/gpu בפריסת קובנטיס שלך.

סיכום

פריסת מודלי שפה גדולים לייצור דורשת תכנון מדוקדק ותשומת לב לפרטים. באמצעות מינוף של ממשקי API, התחשבות בשיקולי פריסה מקומיים ומינוף טכנולוגיות כמו קובנטיס ו-vLLM, ארגונים יכולים להרחיב את עומסי העבודה שלהם ב-AI ולהשיג תובנות וערך חדשים. בין אם בחרת להשתמש בשירותי הסקה מבוססי ענן או לפרוס באופן מקומי, המפתח הוא להבין את הצרכים הספציפיים שלך ולבחור את הגישה המתאימה ביותר.