אירוח אינפרנס ל-AI: איך להשוות ספקי הרצה ופריסה עצמית
Together AI, Fireworks AI, Hugging Face ו-vLLM: מדריך לבחירת תשתית לפי אזורי אירוח, פרטיות, זמני תגובה, מגבלות קצב ואמינות תחת עומס זהה — בלי להסתפק במחיר לטוקן.
כדי לבחור אירוח אינפרנס AI, התחילו מדרישות האפליקציה: היכן מותר לעבד נתונים, כמה זמן המשתמש יכול להמתין ומהו עומס השיא. סננו מסלולים שאינם עומדים בדרישות, ואז השוו את הנותרים באותו מודל ובאותו עומס. Serverless, קיבולת ייעודית ופריסה עצמית אינם אותה הבטחת שירות, גם כשה-API דומה.
העמוד מבוסס על תיעוד ומקורות רשמיים שנבדקו ב־3 בנובמבר 2026. לא נערך מבחן ביצועים עצמאי במסגרת הכנת העמוד. הדוגמאות הן תרחישים להמחשה, ולא תוצאות של מבחן ביצועים עצמאי. רוב דפי התיעוד חיים ואינם מציגים תאריך עדכון; אין כאן בסיס לקבוע מי הספק המהיר או האמין ביותר.
מה משווים לפני שמבקשים הצעה
ההשוואה כאן עוסקת בפריסה ובאיכות שירות, לא במחיר למיליון טוקנים. קיבולת ייעודית יכולה להימדד בזמן משאבים, ולפריסה עצמית מתווספת עבודת תפעול. את חישוב העלויות הרחב השלימו בעזרת המדריך לחישוב עלות API אמיתית, אך אל תשתמשו במחיר כתחליף לבדיקת התאמה.
הטבלה אינה דירוג. היא משווה גבולות אחריות על בסיס התיעוד המפורט בהמשך. אם השאלה עדיין היא איזה סוג ספק דרוש לעסק, מיפוי חברות AI לפי הצורך העסקי מסייע בשלב הקודם; כאן ההחלטה היא על שכבת ההרצה.
Together AI: להפריד בין קיבולת משותפת לייעודית
דף Dedicated של Together מבדיל בין Serverless משותף במתכונת best-effort לבין GPUs מבודדים ללקוח. מתועדת גם פריסת מודלים מותאמים מ-Hugging Face או מ-S3. תאימות ל-OpenAI API מקלה על אינטגרציה, אך אינה מבטיחה אותה קיבולת או אותם זמני תגובה.
התיעוד הגאוגרפי מציג endpoint לעיבוד Serverless בארה״ב עבור רשימת מודלים מוגדרת, לא לכל הקטלוג. אל תניחו שאזור במסלול אחד זמין גם במסלול אחר: בקשו אישור למודל, למסלול ולאזור המבוקשים, ובנפרד למיקום האחסון.
לפי מדיניות הפרטיות, פרומפטים ותשובות נשמרים כברירת מחדל ועשויים לשמש לשיפור המוצר; אימון דורש opt-in נפרד. כיבוי `Prompt storage` מפעיל Zero Data Retention, מכבה מודלי passthrough וחל רק על בקשות עתידיות. הוא אינו מוחק אוטומטית מידע שנשמר קודם.
אל תעתיקו טבלת RPM ישנה כתקרה אחידה. דף Build Tiers שעודכן בנובמבר 2025 ותיעוד Serverless שנמצא בתחקיר אינם מציגים אותה מסגרת. בקשו מגבלות עדכניות לחשבון ולמודל, והבהרה לגבי תגובות 429 ו-503 והתחייבויות קיבולת.
Fireworks AI: הרחבה אוטומטית אינה קיבולת מיידית
תיעוד autoscaling מאפשר להגדיר מינימום ומקסימום replicas, מעבר לאפס וחלונות הרחבה וצמצום. יעדי העומס יכולים להתבסס על בקשות, מקביליות או טוקנים לשנייה. חלון scale-up הוא פרמטר החלטה, לא הבטחה שהמודל יהיה מוכן בתוך אותו זמן.
לפי תיעוד האזורים, פריסות הן רב־אזוריות כברירת מחדל, בקבוצות כגון GLOBAL, US ו-EUROPE. פריסה עשויה לנוע או להתפזר בתוך קבוצה. בקרת Data Residency הארגונית המתועדת להגבלת US היא מנגנון אחר: היא דוחה בקשות לא תואמות, ולא מעבירה אוטומטית פריסות קיימות.
מגבלות Serverless כוללות מכסות נפרדות לטוקני קלט, לקלט שאינו cached ולפלט, לכל חשבון ומודל. המכסות אדפטיביות ומשתנות עם השימוש. בנוסף, דף האבטחה מתעד אי־שמירת פרומפטים ופלטים באינפרנס של מודלים פתוחים ללא opt-in; אין להרחיב זאת אוטומטית לכל תכונה שומרת־מצב.
Hugging Face: תצורה מפורשת, אך לא כל צירוף זמין
ב-Inference Endpoints אפשר לבחור ענן, אזור, מאיץ וסוג instance, ולקבע את מאגר המודל באמצעות commit hash. לפי מדריך התצורה, אפשרויות לא זמינות או לא מתאימות אינן ניתנות לבחירה. זו נקודת פתיחה להשוואה שחוזרת על אותה תצורה, לא הבטחת מלאי.
ה-FAQ הרשמי מונה אזורים בארה״ב ובאירלנד, אך הרשימה אינה מבטיחה כל GPU בכל אזור. דף האבטחה מציין שאין שמירת payloads או טוקנים המועברים ל-endpoint, ולצדה שמירת לוגים ל-30 יום. בקונטיינר מותאם יש לברר גם מה הקוד שלכם כותב ללוגים.
PrivateLink מספק חיבור פרטי, אך אינו אומר שה-instance נמצא בחשבון ה-VPC שלכם. בתחקיר נמצאה גם אי־התאמה בין דפי autoscaling לגבי זמן המעבר לאפס והתנהגות האתחול; אמתו זאת בתצורת ה-endpoint בפועל לפני הסתמכות תפעולית.
vLLM: מגדירים חלופת אירוח מלאה, לא רק מנוע
vLLM מתעד שרת API ואפשרויות הרצה, אבל אינו ספק עם אזורים ו-SLA מובנים. חלופה עצמית צריכה לכלול גרסה, חומרה, אתר אירוח, שכבת כניסה וצוות תפעול. בלי אלה, השוואת ״Together מול vLLM״ אינה השוואת תשתיות מוגדרת.
בתכנון כללו בידוד רשת, אימות, הגבלת קצב, ניטור, עדכונים והתאוששות מכשל. אל תסיקו פרטיות מעצם הפריסה העצמית: לוגים, גיבויים והרשאות תמיכה עדיין עלולים לחשוף תוכן. היתרון האפשרי הוא שליטה; האחריות לממש אותה נשארת אצל המפעיל.
איך להשוות latency ואמינות תחת אותו עומס
קבעו מראש יעדי שירות, ואז מדדו את שיעור הבקשות שעומדות בהם — לא רק tokens/sec. TTFT הוא הזמן עד הטוקן הראשון; זמן ההשלמה מתאר את ההמתנה לתשובה כולה. להשלמת מונחים אפשר להיעזר במילון מושגי ה-AI.
- קבעו מודל וגרסה, נתוני בדיקה ואורכי קלט ופלט. תעדו precision, caching ומנוע ככל שהם חשופים; סמנו פערים שלא ניתן להשוות.
- הריצו מאותו מיקום לקוח ובכמה מדרגות עומס. הפרידו קצב הגעת בקשות ממספר הבקשות המקבילות, ודווחו את הקצב שנשלח בפועל.
- דווחו p50, p95 ו-p99 לזמן הטוקן הראשון ולזמן ההשלמה, לצד שגיאות, timeouts ובקשות שלא הושלמו.
- הפרידו מצב חם מהתעוררות מאפס. כללו ניסיונות חוזרים בזמן שחווה המשתמש, ובחנו התאוששות מכשל בסביבה מורשית ומבוקרת.
מגבלת מקביליות נמוכה יכולה להקטין את העומס שנשלח וליצור השוואה מטעה. גם autoscaling שונה או cache חם אצל חלופה אחת משנים את התוצאה. אם אין אפשרות להשוות תצורות זהות, הציגו את ההבדלים במקום לייחס הכול לספק.
המחשה: עוזר שירות עם התפרצות תעבורה
נניח שעוזר שירות בעברית מקבל מעט בקשות בדרך כלל ועומס מרוכז אחרי הודעה ללקוחות. השוו מסלול שנשאר חם למסלול שמתעורר מאפס, עם אותו מאגר שיחות סינתטי ואותה התפלגות אורכים. תעדו בנפרד המתנה ראשונית, שגיאות והצטברות תור. זו המחשת תכנון בלבד: אין כאן תוצאה או קביעה שאחת החלופות עדיפה.
לפני התקשרות: אזור, פרטיות והתחייבות שירות
לא אומתו כאן זמינות מסחרית ללקוחות בישראל, latency מרשת ישראלית או איכות בעברית. אזור אירופי אינו אירוח בישראל, ו-API תואם אינו הוכחה לתמיכה טובה בעברית. דרישות אלה מצריכות אישור ובדיקה נפרדים.
שאלות נפוצות
האם GPU ייעודי מבטיח latency נמוך יותר?
לא. בידוד משאבים שונה מקיבולת משותפת, אך זמן התגובה תלוי גם במודל, בחומרה, בתור, ברשת ובעומס. נדרשת מדידה בתצורה הנבחרת.
האם Zero Data Retention פותר את כל שאלות הפרטיות?
לא. צריך לבדוק את היקף ההגדרה לפי API ותכונה, לצד לוגים, גיבויים, גישת תמיכה ומידע שנשמר לפני הפעלת המדיניות.
מתי כדאי לשקול vLLM בפריסה עצמית?
כאשר נדרשת שליטה בתשתית ויש יכולת להפעיל אותה. יש לכלול בהחלטה אבטחה, כוננות וקיבולת חלופית, ולא רק התקנת מנוע הרצה.
האם אפשר לבחור ספק לפי benchmark פומבי?
הוא עשוי לעזור בסינון, אך לא להחליף בדיקה של המודל, אורכי הבקשות, מיקום הלקוח והעומס שלכם. חשוב לבדוק גם שגיאות והתאוששות, ולא רק קצב טוקנים.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות