איך להריץ Ollama על שרת VPS בצורה מאובטחת

מה אתם בונים

מודל שפה בעל משקולות פתוחות הרץ על שרת בבעלותכם, הנגיש דרך API מסוג HTTP, ואם תרצו, גם דרך דף צ'אט בדפדפן. Ollama הוא הרכיב שמוריד את המודל, טוען אותו לזיכרון ומגיש בקשות ב-http://127.0.0.1:11434. ההתקנה מתבצעת באמצעות פקודה אחת. החלקים המורכבים נמצאים במקומות אחרים: בחירת מודל שה-VPS שלכם מסוגל להחזיק ב-RAM, והימנעות מחשיפה לא מכוונת של שרת הסקה (inference) ללא אימות לכל רחבי האינטרנט.

שתי אזהרות כנות לפני שמתחילים. שרת VPS מבוסס CPU בלבד יריץ מודלים קטנים באיטיות, וב-API אין אימות מובנה כלל. שני הנושאים הללו מפורטים בהמשך, שכן בשניהם טמונים הסיכונים העיקריים למשתמשים.

בדיקת מציאות של דרישות זיכרון, במספרים פשוטים

טביעת הרגל של מודל בזיכרון היא בערך גודל הקובץ שלו, בתוספת כגיגה-בייט אחד של תקורה בזמן ריצה, ועוד מעט יותר עבור חלון ההקשר (context window). המודלים המוגדרים כברירת מחדל ב-Ollama הם בקוונטיזציה של 4-bit (מסומנים כ-Q4), מה שדורש כחצי גיגה-בייט של RAM עבור כל מיליארד פרמטרים. לכן החישוב פשוט, והוא קובע הכל.

מודל 3B כגון llama3.2:3b הוא הורדה של כ-2 GB ודורש כ-4 GB של RAM פנוי כדי לרוץ. מודל 7B או 8B כגון mistral:7b או llama3.1:8b הוא כ-5 GB על הדיסק ודורש כ-8 GB של RAM, כאשר 16 GB יספקו עבודה נוחה. מודל 13B או 14B דורש בערך 16 GB. כל מודל בטווח שבין 30B ל-70B דורש שרת עם כמות גדולה של RAM או, באופן ריאלי, GPU; על שרת VPS מבוסס CPU הוא או לא ייכנס לזיכרון, או יענה לאט כל כך עד שיהיה חסר תועלת.

כעת לגבי המהירות, שכן זהו החלק שאנשים נוטים להמעיט בערכו. הסקת מסקנות (inference) על גבי CPU מוגבלת על ידי רוחב הפס של הזיכרון, לא על ידי מהירות השעון, ולשרת VPS עם vCPU משותף יש רוחב פס צנוע. צפו לקצב של ספרה אחת עד שתי ספרות נמוכות של טוקנים לשנייה: מודל 7-8B ב-Q4 עשוי להגיע ל-4 עד 10 טוקנים לשנייה, ומודל 3B ל-10 עד 25. כרטיס GPU מהיר בערך בסדר גודל אחד. אלו מספרים גסים במכוון; הצעד הכנה הוא למדוד את השרת שלכם, כפי שמוצג בשלב ההרצה להלן. סמכו על ה-eval rate שלכם, לא על מספר במאמר כלשהו, כולל זה.

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

כדי לשקול מודל ספציפי מול שרת ספציפי, העריכו את טביעת הרגל של הזיכרון שלו כאן:

התקנת Ollama

קיימות שתי דרכים נקיות לביצוע הפעולה. הסקריפט הרשמי הוא הדרך הפשוטה ביותר בשרת VPS חשוף:

curl -fsSL https://ollama.com/install.sh | sh

פעולה זו יוצרת משתמש מערכת בשם ollama, מתקינה את הקובץ הבינארי ב-/usr/local/bin/ollama, ורושמת שירות systemd בשם ollama.service שמופעל בעת עליית המערכת ומאזין ב-127.0.0.1:11434. ודאו שהשירות פעיל:

systemctl status ollama
ollama --version

אם אתם כבר מריצים Docker, השתמשו במכולה במקום זאת:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

שימו לב לקידומת 127.0.0.1: במיפוי הפורט. היא מגבילה את האזנה לפורט ל-localhost בלבד. כתיבת -p 11434:11434 במקום זאת תחשוף את השירות לכל ממשקי הרשת, וזו הטעות שעליה מזהיר סעיף האבטחה. בחרו בשיטת התקנה אחת; אל תריצו את הסקריפט ואת המכולה בו-זמנית, שכן שני תהליכים יתנגשו על אותו הפורט.

משיכה והרצה של המודל הראשון שלכם

ollama pull llama3.2:3b
ollama run llama3.2:3b

הפקודה pull מורידה את שכבות המודל לדיסק (כ-2 GB עבור מודל זה). הפקודה run טוענת אותן לזיכרון ומעבירה אתכם לממשק שורת פקודה מסוג >>>. הקלידו שאלה. יצירת ה-token הראשון עשויה להימשך מספר שניות בזמן שהמשקלים נטענים מהדיסק ל-RAM, ולאחר מכן התשובה תוזרם למסך. הקלידו /bye כדי לצאת מהצ'אט; Ollama ימשיך לרוץ ברקע.

בדקו מה טעון וכיצד המודל משתלב במשאבי המערכת:

ollama ps

העמודה PROCESSOR מציגה את המצב לאשורו. הערך 100% CPU מציין שלא נעשה שימוש ב-GPU, וזהו המקור לאיטיות. מדדו את המהירות בפועל באמצעות דגל הפירוט:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

השורה eval rate שנדפסת בסיום מציגה את כמות ה-tokens לשנייה בחומרה זו. זהו הנתון לפיו יש לתכנן את העבודה.

היכן מודלים מאוחסנים, וכמה שטח דיסק לרכוש

לאחר התקנה באמצעות הסקריפט והרצה כשירות, המודלים נשמרים בתיקיית הבית של המשתמש ollama:

sudo du -sh /usr/share/ollama/.ollama/models

בהרצה אינטראקטיבית כמשתמש שלכם, הם נמצאים ב-~/.ollama/models. בתוך ה-container הם מאוחסנים ב-volume ששמו ollama. זה משמעותי מכיוון שמשקלים קוונטיים (quantized weights) מצטברים במהירות: מודל 3B תופס כ-2 GB, מודל 7-8B תופס כ-5 GB, ומודל 14B תופס כ-9 GB. אם תורידו ארבעה מודלים לצורך השוואה, תנצלו 20 GB מבלי להרגיש. תכננו את נפח הדיסק בהתאם למודלים שאתם מתכוונים לשמור, ומחקו את השאר באמצעות ollama rm <model>. אם אותו שרת VPS מריץ כבר שירות בעל צריכת משאבים גבוהה, כגון PhotoPrism או Immich המאחסנים ספריית תמונות, הפחיתו זאת מהשטח הפנוי תחילה והתייחסו למה שנותר כאל תקציב המודלים האמיתי שלכם.

הרצת השירות תחת שליטתך

סקריפט ההתקנה כבר רשם את ollama.service, לכן הוא יופעל מחדש בעת עליית המערכת ללא צורך בפעולות נוספות. ההגדרה שכדאי לשנות היא משך הזמן שבו מודל נשאר בזיכרון, ובחלק מההגדרות גם כתובת ה-bind; את שתיהן יש להוסיף לקובץ drop-in של systemd כדי ששדרוג של Ollama לא ידרוס אותן:

sudo systemctl edit ollama.service

הוסף את התוכן הבא תחת הכותרת [Service] שמוצגת בעורך:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE קובע כמה זמן מודל נשאר בזיכרון לאחר הבקשה האחרונה (ברירת המחדל היא 5 דקות). הגדל ערך זה בשרת שבו אתה מבצע שאילתות לאורך כל היום כדי להימנע מטענת המשקלים מחדש בכל פעם; הגדר אותו ל-0 בשרת עם משאבים מוגבלים כדי לפנות RAM מיד עם סיום הבקשה. systemctl edit טוען מחדש את קובצי ה-unit עבורך, לכן בצע restart כדי להחיל את השינוי:

sudo systemctl restart ollama

נקודת האבטחה החשובה ביותר

כברירת מחדל, Ollama מאזין ל-127.0.0.1:11434, כך שרק תהליכים על ה-VPS עצמו יכולים לגשת אליו. ברירת מחדל זו היא הנכונה. שמרו עליה.

ל-API אין מנגנון אימות. כלל. אין מפתח API, אין התחברות, אין הגבלת קצב (rate limit) ואין רשימת מורשים. כל מי שיכול להגיע לפורט 11434 יכול להריץ כל מודל שהורדתם, להוריד מודלים חדשים, למחוק אותם, ולהעמיס את ה-CPU או ה-GPU שלכם בעומס מלא ללא הגבלת זמן. סורקים כגון Shodan מאנדקסים אלפי מופעי Ollama פתוחים, ומופע חשוף מתגלה ומנוצל לרעה בתוך שעות.

לכן הנה הטעות האחת שאסור לעשות: אל תגדירו את OLLAMA_HOST=0.0.0.0 ואל תפתחו את 11434 ב־firewall. פעולה זו חושפת שרת inference ללא אימות לכל האינטרנט. שום תצורה לא תהפוך את 11434-on-0.0.0.0`` הגולמי לבטוח, משום שאין ב־Ollama אפשרות להגדיר אימות; מנגנון האימות פשוט אינו קיים. זהו כלל הנוגע לשירות המסוים הזה, ולא איסור לפתוח פורט כלשהו אי־פעם: relay של RustDesk המופעל באירוח עצמי לשולחן עבודה מרוחק חייב לקבל תעבורת רשת ציבורית כדי לפעול, והוא מצדיק זאת באמצעות אימות מבוסס מפתח משלו ורשימה קצרה ומתועדת של פורטים — בדיוק הדברים שחסרים ב־Ollama.

ישנן שלוש דרכים בטוחות לגשת למודל ממקום שאינו השרת עצמו:

• השאירו אותו מקומי. אם הקורא היחיד הוא תוכנית אחרת על אותו ה-VPS, סקריפט cron, בוט, או שרת MCP המגשר בין הכלים שלכם למודל, השאירו את ה-bind על 127.0.0.1 ותנו לאותה תוכנית לפנות ל-http://127.0.0.1:11434. שום דבר לא חשוף ושום דבר אחר אינו נדרש.
• גשו אליו דרך מנהרה פרטית. הציבו את ה-VPS על רשת WireGuard VPN שאתם מארחים בעצמכם, הגדירו את OLLAMA_HOST לכתובת המנהרה (למשל 10.8.0.1, ולא 0.0.0.0), ורק עמיתי ה-VPN יוכלו להתחבר. האינטרנט הציבורי עדיין לא יראה דבר בפורט 11434.
• הציבו reverse proxy עם אימות לפני השירות. בצעו TLS termination ודרשו סיסמה או אסימון (token) ב-nginx, Traefik או Caddy, ולאחר מכן בצעו proxy ל-127.0.0.1:11434. Ollama שומר על ה-bind ל-localhost שלו; ה-proxy הוא הדבר היחיד שמאזין בפורט הציבורי. זהו אותו מבנה כמו הצבת תעודת Let's Encrypt על nginx לפני כל שירות מקומי.

אפשרות ה-reverse proxy היא בדיוק מה שממשק הצ'אט יציע לכם בהמשך, עם התחברות אמיתית מצורפת.

הוספת ממשק צ'אט עם Open WebUI, מאחורי TLS

Open WebUI הוא ממשק צ'אט לאירוח עצמי. הריצו אותו בתוך Docker והפנו אותו ל-Ollama המקומי:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

הדגל --network=host הוא הפרט החשוב ביותר בשרת Linux VPS. הוא מציב את ה-container במרחב הרשת (network namespace) של המארח, כך ש-127.0.0.1 בתוך ה-container הוא ה-loopback של המארח עצמו, וה-container מגיע ל-Ollama בכתובת 127.0.0.1:11434 מבלי ש-Ollama יצטרך להאזין בממשק אחר כלשהו. המתכון של רשת bridge שתראו במקומות אחרים, --add-host=host.docker.internal:host-gateway עם OLLAMA_BASE_URL=http://host.docker.internal:11434, אינו עובד כאן: שם זה מתרגם ל-gateway של ה-bridge של Docker, ושירות שמאזין ל-127.0.0.1 במארח אינו נגיש דרך ה-bridge, לכן Open WebUI פשוט נשאר במצב המתנה ומדווח שאינו יכול להתחבר ל-Ollama.

הפשרה בשימוש ב-host networking היא ש-Open WebUI מאזין כעת בפורט 8080 של המארח בכל הממשקים; כל מיפוי -p מתבטל, ו-Docker מדפיס אזהרה על כך. לכן, סגרו את 8080 גם ברמת המארח וגם ב-firewall של ספק הענן, ותנו ל-reverse proxy עם TLS להיות הדלת הציבורית היחידה. בביקור הראשון, Open WebUI יבקש מכם ליצור חשבון מנהל; חשבון זה מהווה את שכבת האימות שלכם, לכן בחרו סיסמה חזקה.

כדי לפתוח את הצ'אט מהמחשב הנייד שלכם דרך HTTPS, הציבו reverse proxy עם TLS לפני 127.0.0.1:8080. אם אתם כבר מנתבים כמה יישומי Docker על השרת, Traefik עם TLS אוטומטי עבור יישומים רבים הוא הפתרון הנקי ביותר: בלוק labels אחד מנפיק את התעודה ומנתב את chat.example.com ל-Open WebUI. הכלל מסעיף האבטחה עדיין תקף: ה-proxy מחזיק בפורט הציבורי ובאימות, בעוד Ollama נשאר ב-localhost והפורט 8080 של Open WebUI נשאר חסום ב-firewall.

שימוש בנקודת הקצה התואמת ל-OpenAI מהקוד שלכם

Ollama תומכת בתת-קבוצה של ה-API לצ'אט של OpenAI בכתובת /v1, לכן רוב ספריות הלקוח של OpenAI יעבדו לאחר שינוי שני דברים: כתובת ה-base URL ומפתח זמני.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

הערך api_key נדרש על ידי ספריית הלקוח אך Ollama מתעלמת ממנו, לכן כל מחרוזת תעבוד. הערך model חייב להיות שם של מודל שכבר הורדתם; שם לא מוכר יחזיר שגיאת model "x" not found, try pulling it first. קריאת curl פשוטה פועלת על אותו עיקרון:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

כך גם מחברים את המודל לכלי סוכנים (agents) ועורכי קוד. אם אתם כבר מפתחים על השרת, מודל מקומי יכול להריץ סקריפטים ותוספים לצד הרצת Claude Code על ה-VPS בתוך tmux, ובכך לשמור על עבודת טיוטה זולה ופרטית מחוץ ל-API בתשלום, בעוד שהסקה מורכבת נשארת אצל מודל מאוחסן.

מצבי כשל והודעות שגיאה מדויקות

התהליך "Killed" באמצע יצירת הפלט. אתם מפעילים מודל גדול, והטרמינל מציג Killed, או שיומן השרת מציג llama runner process has terminated: signal: killed. מנגנון OOM killer של Linux עצר את התהליך, משום שהמודל דרש יותר זיכרון RAM מכמות הזיכרון הזמינה בשרת. אשרו את הסיבה באמצעות sudo dmesg | grep -i oom, שבו תופיע שורה כגון Out of memory: Killed process ... (ollama). הפתרון הוא להשתמש במודל קטן יותר או במודל שעבר quantization אגרסיבי יותר, ב־llama3.2:3b במקום במודל 13B, או להוסיף swap כדי שהעמסה שחורגת מעט בלבד מהזיכרון הפיזי תצליח להסתיים באיטיות במקום להיכשל. swap הופך קריסה מיידית לתשובה איטית; הוא אינו הופך מודל 70B למעשי על 4 GB. התהליך מופסק בשקט, אלא אם כן אתם צופים בטרמינל באותו רגע. לכן, בשרת שאתם שולחים אליו שאילתות ממקום אחר, צירוף יחידת OnFailure= ל־ollama.service, ששולחת עדכון ל־שרת ntfy שאתם מארחים לקבלת התראות push, מאפשר לכם לדעת ברגע שהתהליך מסתיים בכפייה, במקום לגלות זאת רק בבקשה הבאה.

"Error: model requires more system memory". התוכנה Ollama מסרבת להפעיל את המודל ומציגה Error: model requires more system memory (X GiB) than is available (Y GiB). זו הגרסה המנומסת לקריסה שתוארה לעיל: Ollama ביצעה את החישוב ועצרה מראש במקום לתת ל-OOM killer לעשות זאת. היא אף מציגה לכם את שני המספרים הרלוונטיים. בחרו מודל שדרישות הזיכרון שלו נמוכות מכמות ה-RAM הפנוי שלכם (בדקו זאת עם free -h), צמצמו את אורך ההקשר (context length), או עברו לשרת VPS חזק יותר. אין דגל (flag) שיגרום למודל להיכנס לזיכרון אם הוא אינו מתאים; מגבלת הזיכרון היא פיזית.

הטוקן הראשון מתקבל באיחור רב, ולאחר מכן הכול תקין. מודל קר אינו מדפיס דבר במשך חמש עד שלושים שניות, ולאחר מכן מזרים את הפלט כרגיל. בזמן הזה המשקולות נטענות מהדיסק אל ה־RAM בפעם הראשונה, ואחסון איטי מאריך את התהליך. לאחר הטעינה, המודל נשאר בזיכרון למשך OLLAMA_KEEP_ALIVE, ולכן הפרומפט השני מקבל תשובה מיד. אם הטעינה הראשונה נמשכת מעבר ל־timeout כלשהו בנתיב הקריאה, מתקבלת שגיאה במקום תשובה איטית, ובדיקה של איזו שכבה דיווחה על חריגה של context deadline מראה אם ה־client, ה־proxy או הטעינה עצמה הפסיקו להמתין. הגדילו את הערך הזה אם ההמתנות מפריעות לכם, והשתמשו ב־ollama ps כדי לבדוק אם מודל טעון כעת.

הכל פשוט איטי. עשרה טוקנים לשנייה או פחות, ללא הודעת שגיאה. זהו ביצוע הסקה (inference) על גבי ה-CPU, וזהו אופן הפעולה הצפוי. הפקודה ollama ps מציגה 100% CPU, מה שמעיד על היעדר GPU. זה אינו באג ושום הגדרה לא תתקן זאת, כיוון שהמגבלה היא רוחב הפס של הזיכרון, לא הגדרה שגויה. השתמשו במודל קטן יותר, השלימו עם המהירות, או עברו למופע (instance) עם GPU, ומדדו את קצב העבודה האמיתי שלכם עם --verbose לפני שתחליטו שמשהו מקולקל.

שגיאת Connection refused ממכונה אחרת. מהמחשב הנייד שלכם אתם מקבלים curl: (7) Failed to connect to <ip> port 11434: Connection refused. זהו אופן הפעולה המתוכנן: Ollama מאזינה ל-localhost בלבד. אל "תתקנו" זאת על ידי האזנה ל-0.0.0.0, שכן זו בדיוק טעות החשיפה שתוארה לעיל. גשו למודל דרך ה-VPN או דרך proxy מאומת.

חשפתם את פורט 11434 לאינטרנט. אם הגדרתם OLLAMA_HOST=0.0.0.0, פתחתם את ה-firewall, וכעת אתם רואים משיכות מודלים שלא יזמתם או שה-CPU מנוצל ב-100% על ידי לקוחות לא מוכרים, סימן שאתם חשופים. זוהי טעות קריטית, לא מקרה קצה. הגדירו מחדש האזנה ל-127.0.0.1 או לכתובת ה-VPN, סגרו את פורט 11434 ב-firewall, והוסיפו שכבת אימות. הניחו שכל מי שיכול היה להגיע לכתובת הזו בזמן שהייתה פתוחה, ביצע שאילתות למודל.

גיבויים ושדרוגים

כמעט ואין מידע שניתן לאבד. ניתן להוריד מחדש את המודלים, לכן הדברים היחידים שראוי לגבות הם נפח הנתונים (data volume) של Open WebUI, חשבונות משתמשים, היסטוריית צ'אטים, הגדרות, וכל קובץ drop-in של systemd שיצרתם. גבו את הנפח באמצעות מכולה זמנית:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

שדרגו את Ollama על ידי הרצה מחדש של סקריפט ההתקנה; שדרגו את Open WebUI באמצעות docker pull ghcr.io/open-webui/open-webui:main ולאחריו יצירה מחדש של המכולה. אל תקבעו גרסאות לטווח ארוך: איכות המודלים וסביבת הריצה מתקדמים במהירות, לכן קראו את הערות השחרור (release notes) ובצעו בדיקות ביצועים (benchmarking) על השרת שלכם במקום להסתמך על נתונים מהרבעון הקודם.

FAQ

האם באמת ניתן להריץ LLM על שרת VPS ללא GPU?

כן, תחת מגבלות מסוימות. מודלים קטנים ומקוונטטים (quantized) בטווח של 3B עד 8B רצים על CPU ושימושיים מאוד לניסוח, סיכום וסיווג, אם כי באיטיות – בקצב של ספרה אחת עד שתי ספרות של tokens לשנייה על vCPU משותף. כל מודל מ-13B ומעלה יהיה איטי בצורה קיצונית או שלא ייכנס כלל ל-RAM. למהירות עבודה אמיתית או עבור מודלים גדולים יותר, נדרש שרת עם GPU.

כמה RAM דורש כל מודל?

כלל אצבע למודלים מקוונטטים ב-4-bit: כ-0.5 GB של RAM לכל מיליארד פרמטרים עבור המשקולות, בתוספת של כ-1 GB עבור תקורה (overhead) ועוד מעט עבור ה-context. לכן, מודל 3B דורש כ-4 GB פנויים, מודל 7-8B דורש כ-8 GB, ומודל 14B דורש כ-16 GB. בדקו את המשאבים הפנויים שלכם באמצעות free -h והשאירו מרווח נשימה למערכת ההפעלה ולכל תהליך אחר שרץ על השרת.

האם ה-API של Ollama מאובטח באמצעות אימות?

לא. ל-Ollama אין מנגנון אימות מובנה, מפתחות API או הגבלת קצב (rate limit); לכל מי שיכול להגיע לפורט 11434 יש שליטה מלאה עליו. זו בדיוק הסיבה שהוא מאזין ל-127.0.0.1 כברירת מחדל, וזו הסיבה שאסור לכם לחשוף את 11434 ב-0.0.0.0 לאינטרנט. גשו אליו מקומית, דרך VPN פרטי, או דרך reverse proxy שמוסיף שכבת התחברות.

איך מוסיפים ממשק צ'אט מבוסס דפדפן?

הריצו את Open WebUI בתוך Docker עם --network=host כדי שישתף את ה-loopback של המארח ויגיע ל-Ollama המקומי ב-http://127.0.0.1:11434, ולאחר מכן הציבו reverse proxy עם TLS לפני פורט 8080 שלו לצורך גישה מהמחשב האישי. השאירו את 8080 סגור ב-firewall כך שה-proxy יהיה השער הציבורי היחיד. חשבון הניהול של Open WebUI מספק את מנגנון ההתחברות, ואת הסיסמה מגדירים בהפעלה הראשונה.

איך קוראים למודל מתוך יישום משלי?

השתמשו ב-endpoint התואם ל-OpenAI בכתובת http://127.0.0.1:11434/v1. הפנו כל SDK של OpenAI ל-base URL הזה, העבירו כל מחרוזת שהיא בתור מפתח API (מכיוון שהוא מתעלם ממנו), והגדירו את model לשם של מודל שכבר הורדתם. קוד קיים של OpenAI רץ בדרך כלל ללא שינויים, מלבד ה-base URL והמפתח.