מפת ה-Free Compute: מה קיים ומתי להשתמש בכל פלטפורמה

למה צריך מפת Compute לפני שמריצים מודל

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

לפעמים העבודה היא training או fine-tune: צריך להריץ Python, לטעון dataset, לשמור checkpoints, ולתת למודל ללמוד במשך דקות או שעות. במקרה כזה אתה באמת צריך סביבת notebook עם GPU. לפעמים העבודה היא רק inference: לשלוח prompt ולקבל תשובה ממודל שכבר קיים. במקרה כזה GPU שלך בכלל לא מעניין; הרבה יותר הגיוני להשתמש ב-API חינמי כמו Groq, Cerebras, OpenRouter או Google AI Studio. ולפעמים העבודה היא פרטית, חוזרת, קטנה אבל רגישה: מסמכים פנימיים, ניסויים ללא מגבלת requests, או עוזר offline. שם local inference עם Ollama יכול להיות הבחירה הנכונה גם אם הוא איטי יותר.

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

כאן גם מתחיל ההבדל בין vibe coding צעצועי לבין בנייה שמחזיקה. כלי AI יכולים לכתוב לך notebook, סקריפט API או קוד Ollama תוך דקה. הם לא תמיד יודעים להחליט בשבילך שה-Kaggle quota ייגמר באמצע אימון, ש-Colab לא מבטיח GPU היום, ש-ZeroGPU הוא דמו קצר ולא serving רציף, או שהמודל שלך נכנס ל-weights אבל לא ל-runtime בגלל KV cache. ההחלטות האלה הן שלך. הפרק הזה נותן לך את השפה לקבל אותן.

יש גם סיבה כלכלית. המילה "חינם" בענן כמעט אף פעם לא אומרת אותו דבר. לפעמים זה חינם ללא כרטיס אשראי, לפעמים זה קרדיט חודשי שלא מתגלגל, לפעמים זה quota יומי, לפעמים זה queue עם עדיפות נמוכה, ולפעמים זה פשוט trial קטן שמספיק לבדיקה ולא לפרויקט. אם אתה לא מבדיל בין הסוגים, אתה מתכנן על משאב שלא באמת קיים. אם אתה כן מבדיל, אפשר לבנות pipeline שלם שעולה $0 לחודש בלי להרגיש שאתה משחק לוטו.

חשוב להגיד כבר עכשיו: כל מספר בפרק הזה הוא תמונת מצב ל-1 ביוני 2026 או עובדה שהגיעה ממחקר הקורס. Free tiers משתנים. Colab לא מפרסם הבטחה קשיחה לכל GPU או idle timeout. Kaggle משנה ממשקים ומכסות. OpenRouter מוסיף ומסיר מודלים חינמיים. לכן כל מקום שבו המספר רגיש מסומן ככזה, והתרגילים מכריחים אותך לשמור גם מקור ואופן אימות. זה לא כדי להפחיד; זה כדי להפוך אותך למישהו שלא נשבר כשדף pricing משתנה.

איך לקרוא את המפה לאורך הקורס

המפה שנבנה כאן תחזור בכל פרק, אבל בכל פעם מזווית אחרת. בפרק 2 היא תעזור לך לבחור בין ספקי API: אם אתה צריך latency נמוך לצ'אט, בחירה אחת הגיונית; אם אתה צריך לעבד הרבה טקסטים בבוקר, בחירה אחרת הגיונית; אם ספק אחד מחזיר 429, צריך fallback ולא דרמה. בפרק 3 אותה מפה תעבור לעולם ה-notebooks: שם הבחירה כבר לא תהיה "איזה מודל" אלא "איפה אני שומר checkpoints, כמה זמן ה-session חי, ומה קורה אם ה-GPU לא זמין היום". בפרק 4 המפה תיגע במחשב שלך: כמה VRAM יש, איזה quantization סביר, ואיפה local טוב יותר מענן גם אם הוא איטי יותר. בפרק 5 נחבר את הכל ל-pipeline: job אחד על Kaggle, job אחד דרך API, אולי UI במקום שלישי, וכולם צריכים להישאר מתחת למגבלות.

זו הסיבה שהפרק הראשון אינו מתחיל בקוד. קוד בלי מפת compute הוא כמו itinerary בלי לדעת אם יש לך רכב, רכבת או טיסה. אתה יכול להתקדם כמה דקות, אבל ברגע שיש אילוץ אמיתי, כל ההחלטות הקטנות מתנגשות. מי שבונה עם AI מרגיש את זה חזק במיוחד: המודל יציע פתרון שנראה סביר, אבל הוא לא תמיד יודע מה המגבלה החינמית של החשבון שלך, מה ה-quota שכבר ניצלת, או אם המחשב שלך עם 6GB VRAM ולא 24GB. לכן המפה היא שכבת הבקרה האנושית מעל vibe coding.

בכל פעם שתראה כלי חדש, אל תכניס אותו מיד לרשימת "כדאי לנסות". שאל ארבע שאלות. איזו שכבה הוא משרת? מה הוא נותן בחינם באמת? מה המגבלה הראשונה? מה קורה כשהמגבלה מופעלת? אם אין תשובה לאחת מהן, הכלי עדיין יכול להיות מעניין, אבל הוא לא בסיס לתכנון. הגישה הזאת תגרום לך להיראות איטי יותר בחמש הדקות הראשונות ומהיר הרבה יותר בשעתיים שאחר כך.

שלוש השכבות: Notebook GPU, Inference API, Local

אפשר לחלק כמעט כל free compute שתפגוש בקורס לשלוש שכבות. השכבות האלה לא מתחרות על אותו תפקיד. הן עונות על שאלות שונות. ברגע שמבינים את זה, רוב הבלבול נעלם.

Notebook GPU הוא סביבת עבודה זמנית בענן שבה יש Python, Jupyter ולפעמים GPU. Colab, Kaggle ו-SageMaker Studio Lab שייכים לכאן. זו הבחירה כשאתה צריך להריץ קוד שממש משתמש ב-GPU: fine-tune, inference ניסיוני עם ספריות Python, image generation ב-ComfyUI, או אימון קטן. היתרון הוא שאין התקנה מקומית ואין דרייברים. החיסרון הוא שהסביבה זמנית: session נגמר, דיסק נמחק או נשמר חלקית, quota מתכלה, וחומרה לא תמיד זמינה.

Inference API הוא שירות שמריץ מודל עבורך. אתה שולח בקשת HTTP ומקבל תשובה. Groq, Cerebras, OpenRouter, Google AI Studio ו-Hugging Face Inference Providers שייכים לכאן. אתה לא מקבל shell על GPU. אתה לא מתקין CUDA. אתה לא טוען weights. אתה מקבל endpoint. זו הבחירה הנכונה כשרוצים להפעיל מודל גדול בתוך מוצר, סקריפט או כלי vibe coding. בפרק הבא נכתוב קוד כזה בפועל.

Local inference הוא להריץ מודל על המחשב שלך. Ollama ו-LM Studio הם השמות שתראה הכי הרבה, ומאחורי הקלעים הרבה מזה נשען על GGUF ו-llama.cpp. זו הבחירה כשצריך פרטיות, עבודה offline, שליטה מלאה או הרבה ניסויים קטנים בלי quota. החיסרון ברור: אתה מוגבל למה שהחומרה שלך מסוגלת להחזיק. אם יש לך 8GB VRAM, עולם האפשרויות שלך שונה ממישהו עם 24GB. אם אין לך GPU בכלל, CPU inference עדיין אפשרי אבל איטי.

יש גם שכבה רביעית קטנה שאינה קטגוריה ראשית אלא edge case: hosted demo compute. Hugging Face ZeroGPU ו-Modal יכולים להריץ עבודה בענן לתרחישים מסוימים, אבל הם לא מחליפים notebook מלא ולא API יציב בכל מצב. ZeroGPU מתאים לדמו קצר ב-Space, לא ל-serving רציף. Modal מתאים לפונקציות serverless ו-batch עם credits, לא למחברת אינטראקטיבית חופשית. נזכיר אותם במפה, אבל לא נבנה עליהם כעמוד תווך בפרק 1.

טבלת הפלטפורמות החינמיות: מה מקבלים ומה המחיר הנסתר

עכשיו אפשר לדבר על מותגים. אבל שים לב לסדר: קודם שכבה, אחר כך פלטפורמה. הטבלה הבאה אינה רשימת "מי הכי טוב". היא רשימת התאמה. לכל פלטפורמה יש תפקיד, מגבלה, ורגע שבו היא מפסיקה להיות הבחירה הנכונה.

המספרים בטבלה הם תמונת מצב שנבדקה מול מקורות הקורס ומקורות רשמיים ב-1 ביוני 2026, עם תיקונים חשובים: Kaggle docs הנוכחיים מדברים על 12 שעות CPU/GPU notebook execution ו-9 שעות TPU, לא על 9 שעות GPU; SageMaker Studio Lab FAQ מדבר על 4 שעות GPU ל-session ועד 4 GPU-hours ב-24 שעות, לא 8. איפה שהמספרים תלויים בחשבון או dashboard, הטבלה אומרת זאת במפורש.

שים לב למילה שחוזרת בטבלה: verify. לא כי אי אפשר לסמוך על המחקר, אלא כי free tiers הם חוזה חי. אם אתה בונה ניסוי של שעה, מספיק להבין את העיקרון. אם אתה בונה pipeline שצריך לרוץ חודש, פותחים את הדשבורד ובודקים. Kaggle quotas בדשבורד. Groq limits בדף limits של הארגון. Google AI Studio בדף rate limits או pricing העדכני. OpenRouter collection בזמן אמת. זה הרגל קטן שחוסך הרבה כאב.

איך לבחור בין שלוש מחברות GPU שנראות דומות

Colab, Kaggle ו-SageMaker Studio Lab נראות מבחוץ כמו וריאציות של אותו מוצר: Jupyter בדפדפן עם אפשרות GPU. בפועל הן נוחות למצבים שונים. Colab הוא הכי מהיר להתחיל איתו אם כבר יש לך חשבון Google, notebook מוכן, ומשימה קצרה. הוא מצוין לניסוי ראשון, להרצת תא בודד, ולבדיקה אם רעיון בכלל עובד. החיסרון הוא ש-Google מדגישה שהמשאבים אינם מובטחים. אם אתה צריך להתחיל עכשיו ולקבל GPU בוודאות, free Colab אינו חוזה כזה.

Kaggle טוב כאשר חשוב לך לשחזר עבודה ולשמור output מסודר. סביבת Kaggle בנויה סביב versions, datasets ו-notebook outputs. זה מתאים במיוחד ללומד שרוצה להריץ ניסוי, לשמור תוצאה, לחזור אליה, ולהשתמש בה כ-input לניסוי הבא. מצד שני, Kaggle דורש שתחשוב על quotas בחשבון ועל הדרך שבה sessions נשמרים. כשאתה רואה מדריך שאומר "30 שעות GPU בשבוע", אל תהפוך את זה להנחת עבודה בלי לבדוק את מסך החשבון שלך. ה-docs והדשבורד הם המקור, לא הזיכרון של האינטרנט.

SageMaker Studio Lab הוא מקרה מעניין: הוא פחות "ניצחון מהיר" ויותר סביבת לימוד עם persistent storage. העובדה שיש 15GB שנשארים בין sessions היא יתרון אמיתי, אבל יש friction: אישור חשבון, לעיתים phone verification, מגבלת GPU יומית, וזמינות שאינה מובטחת. לכן הוא מתאים כגיבוי יציב ללמידה או לניסוי שמרוויח מ-storage מתמשך, פחות כפתרון הראשון כשאתה רוצה להריץ משהו בעוד חמש דקות. בחירה טובה אינה הפלטפורמה עם הכי הרבה יתרונות; היא הפלטפורמה שהחסרונות שלה מתאימים למשימה שלך.

אותו עיקרון חל גם על APIs. Groq מרגיש כמו קסם כשצריך תגובה מהירה. Cerebras יכול להיות נפלא לעיבוד טקסטים ארוכים בכמות טוקנים גדולה, אבל מגבלת requests per minute נמוכה יכולה לגרום לצ'אט להרגיש מגושם. OpenRouter נוח כשאתה רוצה הרבה מודלים דרך ממשק אחד, אבל המודלים החינמיים מסתובבים. Google AI Studio חזק ב-long-context ובמולטימודליות, אבל דפי pricing/rate limits של Gemini משתנים בין דורות מודלים. לכן אל תבחר "הכי טוב"; בחר התאמה. התאמה טובה היא משפט ברור: "ל-job הזה אני בוחר X כי המגבלה הראשונה שלו פחות מסוכנת מהמגבלה של Y".

Session, Storage ו-Quota: שלושת הקירות שמפסיקים ריצה חינמית

כש-job חינמי נכשל, הוא בדרך כלל לא נכשל כי המודל "לא עובד". הוא נכשל כי פגעת באחד משלושה קירות: session, storage או quota. מי שמבין את שלושת הקירות האלה מתכנן אחרת לגמרי.

Session הוא חלון החיים של runtime. ב-Colab, Google אומרת במפורש שהמשאבים לא מובטחים ושה-notebooks החינמיים יכולים לרוץ לכל היותר 12 שעות בהתאם לזמינות ודפוס שימוש. ב-Kaggle docs הנוכחיים, CPU/GPU notebook execution יכול להגיע ל-12 שעות, ו-TPU ל-9 שעות. ב-SageMaker Studio Lab, GPU runtime מוגבל ל-4 שעות ל-session. המשמעות: אם יש לך job של 7 שעות, אתה לא רק שואל האם יש GPU; אתה שואל מה קורה אם ה-session מת באמצע.

Storage הוא השאלה מה נשאר אחרי ה-session. Colab runtime disk הוא זמני, אבל אפשר למפות Google Drive ולשמור לשם checkpoints. Kaggle שומר output ב-/kaggle/working לפי הדוקומנטציה, ויש גם scratchpad שלא נשמר. SageMaker Studio Lab חזק כאן כי יש לו 15GB persistent storage. Local inference חזק עוד יותר כי הדיסק שלך שלך. אם אתה מוריד weights של כמה GB בכל session, אתה משלם בזמן. אם אתה מאבד checkpoint אחרי fine-tune, אתה משלם בשעות.

Quota הוא הקיר הכי שקט. לפעמים הוא שעות GPU לשבוע, לפעמים tokens/day, לפעמים requests/day, לפעמים credits לחודש. Groq יכול להיות נדיב מאוד למודל 8B אבל מוגבל יותר ל-70B. OpenRouter יכול להציע מודל חינמי היום ולהחליף אותו מחר. Modal נותן credits חודשיים, אבל credits הם תקציב, לא משאב אינסופי. גם כשאתה משלם $0, אתה עדיין מתכנן תקציב.

עכשיו אפשר להבין למה "איזה GPU יש שם" היא שאלה חלקית. נניח שיש לך notebook עם T4. אם אין persistence, fine-tune בלי checkpointing הוא הימור. נניח שיש לך API מהיר. אם הוא מוגבל ל-1,000 requests/day ואתה מריץ batch של 20,000 שורות, הוא לא מתאים לבד. נניח שיש לך local 8B שעובד. אם הלקוח דורש 70B reasoning עם latency נמוך, local לא מתאים, גם אם הוא חינם באמת.

הכלל המעשי: לפני כל run ארוך מ-10 דקות, כתוב שלוש תשובות. כמה זמן ה-session יכול לחיות? איפה נשמרים outputs/checkpoints? מה ה-quota שייגמר ראשון? אם אין לך תשובה לאחת מהשאלות, אתה עדיין בשלב ניסוי, לא בשלב pipeline.

תכנון run: מה כותבים לפני שלוחצים Run All

הדרך הפשוטה ביותר להימנע מכאב היא לכתוב run card קצר לפני עבודה ארוכה. לא מסמך ארכיטקטורה, לא README מפואר, רק שש שורות. שורה ראשונה: מה ה-job עושה בפועל. שורה שנייה: כמה זמן אתה מעריך שהוא ירוץ. שורה שלישית: איפה נשמרים outputs. שורה רביעית: איפה נשמר checkpoint אם יש training או fine-tune. שורה חמישית: מה ה-quota הראשון שיכול להיגמר. שורה שישית: מה תעשה אם ה-run נקטע. אם קשה למלא את שש השורות האלה, הבעיה אינה בכתיבה; הבעיה היא שה-run עדיין לא מתוכנן.

לדוגמה, run card ל-fine-tune קטן על Kaggle יכול להיראות כך: "job: QLoRA adapter על dataset של 3,000 דוגמאות; זמן צפוי: 3-5 שעות; outputs: /kaggle/working ואז push ל-Hugging Face; checkpoints: כל 500 steps; quota ראשון: GPU hours ושעת session; fallback: להקטין dataset או להמשיך מ-checkpoint ב-session הבא". שים לב שאין כאן קוד. יש החלטות. כשהקוד נכשל, ההחלטות האלה אומרות לך מה לעשות.

run card ל-API batch נראה אחרת: "job: סיכום 300 מאמרים; זמן צפוי: 45 דקות; outputs: CSV מקומי; checkpoint: כתיבה אחרי כל מאמר; quota ראשון: requests per minute או tokens per day; fallback: exponential backoff, החלפת ספק, או חלוקה לשני ימים". כאן storage פחות דרמטי, אבל rate limits קריטיים. מי שמשתמש באותו template לכל סוג job מפספס את ההבדלים. מי שממלא run card לפי השכבה שבחר, מתחיל לחשוב כמו operator ולא כמו מי שמריץ ניסוי אקראי.

נוסחת VRAM: למה 7B לא שווה 7GB

כאן הרבה מתחילים מקבלים OOM, כלומר Out Of Memory, ואז חושבים שהמודל שבור. בדרך כלל המודל לא שבור. החישוב היה חסר. השם "7B" אומר בערך 7 מיליארד parameters. הוא לא אומר 7GB VRAM. כמה VRAM צריך תלוי בכמה ביטים שומרים לכל parameter, כמה context מריצים, ומה ה-runtime צריך מעבר ל-weights.

החישוב הפשוט מתחיל ב-weights-only:

VRAM_weights_GB ≈ parameters_in_billions × bits_per_weight / 8

מודל 8B ב-Q4 הוא בערך:

8 × 4 / 8 = 4GB weights-only

אבל זה רק החלק הראשון. בזמן ריצה יש עוד שכבות: KV cache עבור ה-context, activations, buffers, overhead של framework, ולפעמים memory fragmentation. לכן כלל האצבע למתחילים הוא להוסיף 30-50% ל-context קצר, ולהיזהר הרבה יותר ב-context ארוך. לפי מחקר הקורס, 7-8B ב-Q4_K_M הוא בערך 4.1GB weights-only, אבל runtime קצר יכול להגיע בערך ל-5.5-6.2GB. זה עדיין נכנס להרבה כרטיסי 6GB/8GB בתנאים מסוימים, אבל כבר לא "4GB וזהו".

הטבלה הבאה מספיקה לפרק 1. היא לא מחליפה benchmark, אבל היא מונעת את הטעות הכי יקרה:

Quantization משנה את האיזון. Q4_K_M מקטין מאוד את הזיכרון, אבל יש ירידת איכות. Q5_K_M לוקח יותר מקום, אבל שומר איכות טוב יותר. BF16/FP16 לוקחים הרבה יותר VRAM. בפרק 4 ניכנס לזה לעומק ונמדוד Ollama בפועל. כרגע אתה צריך רק כלל בסיסי: אם המשימה דורשת reasoning, math או code באיכות גבוהה, אל תבחר את ה-quantization הכי אגרסיבי רק כי הוא נכנס. אם המשימה היא סיכום, extraction או עוזר קטן, Q4 יכול להספיק.

החלק שנשכח כמעט תמיד הוא context. מודל 8B ב-context קצר יכול לרוץ יפה. אותו מודל עם context ארוך מאוד יכול להוסיף כמה GB רק ל-KV cache. לכן כאשר אתה רואה "1M context" ב-API, זה לא אומר שאתה יכול לעשות אותו דבר local. API מריץ את זה על תשתית של ספק. local עובד בתוך ה-VRAM שלך.

דוגמה מלאה: למה אותו 8B יכול לעבוד או לקרוס

נניח שאתה רוצה להריץ מודל 8B מקומי כדי לבנות עוזר קטן לקבצי Markdown. במחשבון קיבלת בערך 4GB weights-only ב-Q4. אם יש לך כרטיס 6GB, זה נראה אפשרי. עכשיו מגיעה השאלה שהמחשבון הפשוט לא עונה עליה לבד: מה אורך ה-context שאתה באמת צריך? אם אתה שולח prompt קצר, כמה פסקאות, ותשובה קצרה, ייתכן שה-runtime יישאר סביב 5.5-6.2GB ויצליח בקושי. אם אתה מנסה לדחוף 30 קבצים בבת אחת, ה-KV cache גדל, וה-run יכול לקרוס אף שהמודל עצמו "נכנס".

זו הסיבה שבפרויקטים מקומיים טובים כמעט תמיד יש שכבת retrieval או chunking. במקום לשלוח את כל המסמך למודל, מחפשים את החלקים הרלוונטיים ושולחים רק אותם. פתאום אותו מחשב חלש מרגיש חזק יותר, לא בגלל שקנית GPU, אלא בגלל ששינית את job. Free compute הוא לא רק בחירת ספק; הוא גם עיצוב עבודה כך שתתאים למשאב. מי שמבין את זה יכול להוציא תוצאות טובות מציוד בינוני.

דוגמה הפוכה: יש לך T4 של 15GB ב-Colab או Kaggle. מודל 13B ב-Q4 נראה אפשרי מבחינת weights-only, בערך 8GB. אבל אם אתה מעלה batch size, משתמש ב-context ארוך, או עובד עם framework שצורך הרבה overhead, אתה עלול להגיע לקצה. אם ה-run הוא inference קצר, אולי זה יעבוד. אם זה fine-tune, צריך עוד זיכרון לאופטימייזר, gradients או adapters, ולכן QLoRA ו-checkpointing נהיים חשובים. לכן פרק 1 נותן לך רק את הנוסחה הראשונית; בפרקים 3 ו-4 נלמד patterns שמקטינים את הזיכרון בפועל.

למתחילים כדאי לזכור שלוש תשובות אפשריות ל-OOM. הראשונה: הקטן את העבודה, למשל context קצר או batch size קטן. השנייה: הקטן את המודל או עבור ל-quantization צפוף יותר, תוך הבנה שיש מחיר איכות. השלישית: החלף שכבה, למשל API במקום local או notebook במקום laptop. אל תקפוץ ישר לתשובה השלישית. לפעמים שינוי קטן ב-job מחזיר אותך ל-$0 בלי להחליף פלטפורמה.

עץ ההחלטה: איך בוחרים פלטפורמה בלי לנחש

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

1. צריך לאמן, fine-tune או להריץ קוד GPU? אם כן, התחל מ-Notebook GPU: Colab, Kaggle או SageMaker Studio Lab. בחר לפי persistence, session ו-quota.
2. צריך רק תשובת מודל מתוך prompt? אם כן, התחל מ-Inference API. בפרק הבא נשתמש ב-Groq/Cerebras/OpenRouter ונבנה rotation.
3. צריך privacy, offline או ניסויים ללא daily cap? אם כן, בדוק Local inference. רק אחרי בדיקת VRAM, לא לפני.
4. צריך דמו קצר עם UI ציבורי? בדוק ZeroGPU או Modal, אבל אל תבלבל דמו עם production serving.
5. מה ה-fallback? אם Colab לא נותן GPU, אולי Kaggle. אם Groq פוגע ב-429, אולי Cerebras או OpenRouter. אם local לא נכנס ל-VRAM, אולי מודל קטן יותר או API.

שתי נקודות עדינות בעץ הזה. הראשונה: fallback עדיף שיהיה באותה שכבה. אם Groq חסום, החלף API לפני שאתה עובר ל-notebook. אם Colab חסום, בדוק Kaggle לפני שאתה בונה מחדש סביב API. החלפת שכבה משנה ארכיטקטורה, לא רק ספק. השנייה: יש מקרים שבהם שתי שכבות נכונות לשלבים שונים. למשל fine-tune קטן על Kaggle ואחר כך serving דרך Groq. זה בדיוק מה שנעשה בקורס: כל job מקבל שכבה משלו.

כשיש שתי דרישות שמתנגשות

העולם האמיתי אוהב להביא דרישות סותרות. "אני רוצה 70B, אבל שהמידע לא יצא מהמחשב". "אני רוצה fine-tune, אבל בלי session שנופל". "אני רוצה דמו ציבורי, אבל שלא יהיה queue". עץ ההחלטה אינו קסם שמבטל tradeoffs; הוא מכריח אותך לנסח אותם. אם אתה צריך 70B ופרטיות מלאה, התשובה כנראה אינה free tier פשוט. או שמקטינים מודל מקומי, או שמנקים מידע לפני API, או שמודים שצריך תשתית בתשלום. זו תשובה טובה יותר מאשר לבנות משהו שמפר הבטחת privacy בשקט.

כאשר דרישות מתנגשות, סדר העדיפויות הוא חלק מהמפה. Privacy ו-compliance קודמים בדרך כלל לנוחות. Deadline קצר יכול להצדיק API במקום local setup. אימון שחייב לשמור checkpoints יכול להצדיק Kaggle על פני Colab גם אם Colab נפתח מהר יותר. latency אינטראקטיבי יכול להצדיק Groq על פני ספק עם יותר tokens/day. אין כלל אחד שמנצח תמיד. יש רק החלטה מנומקת שאפשר לחזור אליה.

לכן כדאי להוסיף לכל branch בעץ גם "למה לא". למשל: "Inference API כי צריך 70B מהר; לא local כי VRAM לא מספיק; לא notebook כי אין צורך להריץ training loop". משפטי "למה לא" מצילים אותך מפיתוי מאוחר. כשאתה רואה מדריך נוצץ על כלי אחר, אתה יכול לבדוק אם הסיבה המקורית עדיין נכונה. אם כן, נשארים במסלול. אם לא, מעדכנים את המפה באופן מודע.

מקרים נפוצים: איזו שכבה בוחרים לכל משימה אמיתית

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

מקרה 1: להריץ chatbot עם מודל 70B. רוב המתחילים חושבים שזה דורש GPU מפלצתי. בפועל, אם אתה רק צריך תשובות ממודל, זו משימת inference. הבחירה הראשונה היא API. Groq או OpenRouter עשויים לתת גישה למודלים גדולים או מהירים, עם limits. Cerebras טוב יותר כשהעבודה כבדה בטוקנים אבל לא דורשת הרבה requests בדקה. Local 70B לא ריאלי לרוב הלומדים, ו-notebook GPU חינמי אינו הבחירה הפשוטה.

מקרה 2: לאמן LoRA קטן על dataset שלך. זו כבר משימת training/fine-tune. API רגיל לא נותן לך לגעת ב-training loop. Local עשוי להיות אפשרי אם יש לך GPU מתאים, אבל לקורס הזה נניח שאתה רוצה $0 בלי חומרה. לכן Kaggle או Colab. הבחירה ביניהם תלויה ב-persistence, quota וזמינות. Kaggle חזק כשחשוב לשמור output ולשחזר, Colab חזק לפתיחה מהירה ו-Drive mount.

מקרה 3: עוזר פרטי על PDFs של לקוח. כאן השאלה הראשונה היא לא גודל מודל אלא privacy. אם המסמכים לא יכולים לצאת מהמחשב, local inference הוא ברירת המחדל. אולי המודל קטן יותר ואיטי יותר, אבל אין API חיצוני. אם הפרטיות פחות רגישה והמסמכים מסוכמים ללא מידע אישי, API יכול להיות סביר. ההחלטה אינה טכנית בלבד; היא החלטת סיכון.

מקרה 4: ComfyUI ליצירת תמונות. זה בדרך כלל notebook GPU, כי אתה מריץ stack גרפי/פייתוני עם מודלים גדולים וקבצי weights. Colab או Kaggle יכולים לעבוד, אבל חייבים persistence: workflows, nodes ו-models לא צריכים להיעלם בכל disconnect. בפרק 3 נכסה זאת בפועל. ZeroGPU יכול להתאים לדמו קצר ב-Hugging Face Space, אבל לא כתחנת עבודה חופשית.

מקרה 5: סיכום 300 מאמרים פעם ביום. זו משימת batch inference. אם כל מאמר קצר, API עם rate limiting ו-backoff הוא הבחירה הראשונה. אם הטוקנים רבים אבל מספר הבקשות נמוך, Cerebras עשוי להתאים. אם המאמרים פרטיים, local. אם צריך להריץ preprocess כבד עם Python ו-GPU, אז notebook או Modal. שוב: המשימה מתפרקת ל-jobs, וכל job מקבל שכבה.

מלכודות מתחילים: מה גורם ל-$0 להישבר באמצע הלילה

ה-Free Compute לא נשבר בצורה דרמטית. הוא נשבר בשקט. request מקבל 429. notebook מתנתק. checkpoint לא נשמר. מודל נכנס ל-RAM אבל לא ל-VRAM. Space עומד בתור. התוצאה נראית כמו באג בקוד, אבל השורש הוא תכנון compute.

המלכודת הראשונה היא להניח ש-70B מחייב חומרה שלך. זה גורם למתחילים לבזבז ימים על local setup או notebooks, כשכל מה שהם רצו הוא prompt-response. בפרק 2 תראה כמה מהר אפשר לקבל תשובות ממודלים גדולים דרך API חינמי. אבל גם שם יש מגבלות: daily caps, RPM, tokens/day. החוכמה היא לא רק לבחור API; החוכמה היא לבנות סביבו retry ו-provider rotation.

המלכודת השנייה היא לבנות job ארוך בלי checkpointing. Colab ו-Kaggle הם כלים נהדרים, אבל הם לא שרת production. אם session מתנתק אחרי שעות ואין checkpoint, הבעיה אינה Colab. הבעיה היא שתכננת כאילו free notebook הוא VM מובטח. בפרק 3 נלמד pattern ברור: mount, save, reload, resume. בפרק הזה מספיק שתכתוב ליד כל notebook job: איפה נשמר checkpoint?

המלכודת השלישית היא להתבלבל בין demo compute לבין serving. ZeroGPU, Colab tunnel, ngrok על notebook, או Space עם GPU יכולים לגרום למשהו להיראות כאילו הוא online. זה לא אומר שהוא מתאים למשתמשים אמיתיים סביב השעון. דמו הוא דבר נפלא. production הוא חוזה. אל תשתמש באחד כדי להעמיד פנים שיש לך את השני.

המלכודת הרביעית היא לא להקטין את העבודה. לפעמים השאלה אינה "איפה יש עוד compute" אלא "איך אני משנה את job כך שיתאים ל-free tier". במקום להריץ 10,000 prompts ביום, אולי מסכמים קודם chunks. במקום 32K context, אולי retrieval טוב יותר. במקום 13B local, אולי 8B עם prompt טוב. מפת compute טובה לא רק בוחרת ספק; היא משנה את המשימה כך שתיכנס לתקציב.

איך נראה debug של כשל compute

נניח שהרצת batch דרך API וקיבלת 429. תגובה ראשונה של מתחיל היא "הספק לא טוב" או "צריך לעבור לספק אחר". תגובה מקצועית יותר היא לשאול איזה limit פגענו: requests per minute, tokens per minute, requests per day או tokens per day. אם זה RPM, אפשר להאט, להוסיף queue, או לפצל לאורך זמן. אם זה TPD, אולי צריך לסכם chunks לפני שליחה או לעבור לספק עם תקציב טוקנים גבוה יותר. אם זה RPD, rotation בין ספקים יכול לעזור. אותו error, שלוש סיבות שונות, שלוש החלטות שונות.

נניח שה-notebook מתנתק. גם כאן השאלה אינה "Colab גרוע". השאלה היא מה אבד. אם רק runtime אבד אבל checkpoints ב-Drive, זה annoyance. אם weights, dataset ו-checkpoints היו על דיסק זמני, זה disaster. לכן בפרק 3 כל workflow יתחיל בשאלה איפה שומרים דברים. בפרק הזה מספיק שתזהה מראש אם job שלך מייצר state שחשוב לשמור. אם כן, persistence אינו nice-to-have; הוא דרישה.

נניח ש-local inference איטי מדי. אולי הבעיה היא מודל גדול מדי, אולי quantization איכותי מדי, אולי CPU offload, ואולי פשוט expectation לא נכון. local הוא נפלא לפרטיות ולשליטה, אבל הוא לא בהכרח מהיר. אם אתה בונה כלי אישי שעונה תוך 8 שניות, זה אולי סביר. אם אתה בונה UX אינטראקטיבי שמרגיש כמו chat מודרני, זה יכול להיות לא מספיק. שוב, המפה אינה רק "אפשר" או "אי אפשר"; היא מחברת משאב לחוויית משתמש.

בונים את מפת ה-Compute האישית שלך

עד עכשיו בנינו ידע. עכשיו בונים artifact. המפה האישית שלך היא קובץ קטן שמלווה אותך לאורך הקורס. בכל פרק נוסיף לו שכבה: בפרק 2 APIs, בפרק 3 notebooks, בפרק 4 local, ובפרק 5 pipeline שלם. אם תשמור את המפה מעודכנת, לא תצטרך להחליט מחדש בכל פעם.

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

דוגמה לפרויקט הקורס: אתה רוצה לבנות כלי קטן שמקבל מסמכים, מסכם אותם, מאפשר לשאול שאלות, ואולי בסוף עושה fine-tune קטן על סגנון תשובות. זה לא job אחד. זה כמה jobs. סיכום המסמכים יכול להיות API. שאילת שאלות פרטיות יכולות להיות local. fine-tune קטן הוא notebook GPU. UI ציבורי אולי HF Spaces CPU או Vercel/Cloudflare, אבל זה מחוץ לפרק הזה. ברגע שמפרקים כך, הבחירות נהיות פחות דרמטיות.

דוגמה ממולאת: פרויקט מסמכים אישי

נמלא שורה אחת יחד. Job ראשון: ingest documents. זה כמעט תמיד CPU/storage, לא GPU. אם מדובר רק בהמרת PDF לטקסט וחלוקה ל-chunks, אין סיבה לבזבז GPU. השכבה יכולה להיות local או סביבת Python רגילה. first limit יהיה privacy וגודל קבצים, לא VRAM. Job שני: summarize chunks. אם המסמכים לא רגישים, Inference API מתאים; אם הם רגישים, local. first limit ב-API הוא tokens/day או RPM; first limit ב-local הוא latency ו-context.

Job שלישי: answer questions. כאן יש tradeoff. אם רוצים איכות גבוהה ומהירות, API. אם רוצים פרטיות, local עם מודל קטן יותר ו-RAG טוב. Job רביעי: fine-tune style adapter. זה כבר Notebook GPU, כנראה Kaggle או Colab, עם checkpointing. Job חמישי: public demo. אם זה רק demo פנימי, אולי HF Space CPU שמדבר עם API. אם זה serving רציף, צריך לתכנן אחרת. עכשיו אפשר לראות למה "איזו פלטפורמה הכי טובה" היא שאלה לא מדויקת. לאותו פרויקט יש כמה תשובות נכונות, אחת לכל job.

הדוגמה הזאת חשובה כי היא מונעת overengineering. מתחילים רבים מנסים לבחור פלטפורמה אחת לכל הפרויקט. זה גורם להם לעוות משימות כדי שיתאימו לכלי. מפת compute טובה עושה ההפך: היא מפרקת את הפרויקט למשימות, ואז בוחרת לכל אחת כלי קטן ומתאים. בסוף אפשר לחבר אותן ל-pipeline, אבל ההחלטות נשארות נקיות.

שגרת עבודה: איך שומרים את המפה עדכנית

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

יומן freshness: לא לזכור, לרשום

אל תנסה לזכור בעל פה אילו מגבלות השתנו. פתח טאב קטן במפת ה-compute בשם freshness-log. בכל פעם שאתה מאמת מספר, כתוב תאריך, מקור, claim ומה החלטת לעשות איתו. לדוגמה: "2026-06-01, Kaggle docs, CPU/GPU sessions 12h, לא להשתמש יותר ב-9h כטענה כללית". או: "2026-06-01, SageMaker Studio Lab FAQ, GPU max 4h/24h, מתאים רק לגיבוי קצר". פעולה כזאת נראית בירוקרטית בפעם הראשונה, אבל היא מונעת מצב שבו אתה מתווכח עם עצמך חודש אחר כך מאיפה הגיע מספר.

יומן freshness גם עוזר כשאתה עובד עם AI. במקום לבקש מהמודל "מה ה-free tier של Kaggle", אתה נותן לו את הטבלה שלך ואומר: "המספרים האלה אומתו בתאריך הזה; אם אתה מציע workflow שסותר אותם, הסבר למה". פתאום ה-AI הופך מעוד מקור שעלול להזות לשותף שבודק החלטות מול constraints שלך. זה אחד ההרגלים הכי חשובים בבנייה עם כלי קוד חכמים: לא לתת למודל להמציא תשתית, אלא לתת לו constraints טובים לעבוד בתוכם.

היומן גם נותן לך דרך לשתף פרויקט. אם חבר או לקוח שואל למה בחרת API במקום notebook, אתה יכול להראות: "כי job type הוא inference, כי 70B local לא נכנס ל-VRAM שלנו, וכי Groq/OpenRouter היו ה-fallbacks שנבדקו בתאריך X". זו תשובה מקצועית יותר מ"נראה לי שזה הכי טוב". בהמשך הקורס, כשנבנה pipeline של $0, היומן הזה יהפוך לרשימת assumptions. אם assumption נשבר, יודעים בדיוק איזו החלטה לעדכן.