Model Registry: המקור האמיתי היחיד לאילו מודלי AI רצים בארגון

מאת צוות מדיה דיל · 03.08.2026 · Enterprise AI · 7 דק׳

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

ארגון טיפוסי שמאמץ AI ברצינות מוצא את עצמו תוך שנה עם עשרות מודלים בשימוש בו-זמנית: כמה גרסאות של מודלים סגורים דרך API (Claude Sonnet, Claude Opus לכל אחד עם snapshot משלו), מודלים פתוחים שעברו fine-tuning פנימי, ומודלים קטנים ייעודיים למשימות ספציפיות כמו סיווג או embedding. בלי מקום מרכזי אחד שמתעד מי המודלים האלה, מי אחראי עליהם, כמה הם עולים ואיך הם מתפקדים - כל צוות בוחר מודל בעצמו, לפי טעם אישי או נוחות רגעית, והתוצאה היא בלגן תפעולי: אי אפשר לדעת אילו מודלים בכלל רצים בפרודקשן, אי אפשר למדוד עלות כוללת, ואי אפשר להגיב מהר כשספק מודלים מכריז על deprecation. Model Registry הוא התשובה התשתיתית לבלגן הזה - קטלוג מרכזי, חי ומחייב, של כל מודל שמורשה לרוץ בסביבת הארגון.

מה בדיוק נכנס לתוך Model Registry

Model Registry איכותי אינו רק רשימת שמות. עבור כל מודל הוא שומר: מזהה snapshot מדויק (לא alias שמתעדכן לבד), ה-provider והאזור הגאוגרפי שבו הוא רץ (רלוונטי לעמידה בדרישות residency), מגבלות context window ו-rate limits, מחיר לטוקן קלט ופלט, תאריך expected end-of-life שהספק פרסם, ורמת האישור הביטחוני-משפטי שהמודל עבר (למשל אישור DPA, בדיקת אבטחת מידע). מעבר לזה, Registry רציני שומר גם metadata תפעולי: אילו Agents וצוותים משתמשים בכל מודל, מה נפח הקריאות החודשי בפועל, ומה הביצועים הנמדדים שלו על סוללות ה-Evaluation הפנימיות של הארגון - כי שני מודלים עם אותה מפרט טכני יכולים להתנהג אחרת לגמרי במשימה ספציפית.

Model Registry מול Model Catalog של הספק

חשוב להבחין בין הקטלוג שהספק (Anthropic, OpenAI וכו') מפרסם, לבין ה-Registry הפנימי של הארגון. הקטלוג הציבורי אומר מה קיים בעולם; ה-Registry הפנימי אומר מה מותר להשתמש בו כאן, בפועל, היום. ההבדל קריטי: ארגון עשוי להחליט שמודל מסוים לא עומד בדרישות הפרטיות שלו, או שהוא עדיין בתהליך אישור אבטחת מידע ולכן חסום לשימוש בפרודקשן אף שהוא זמין טכנית. ה-Registry הפנימי הוא שכבת ה-policy שמתווכת בין מה שהעולם מציע למה שהארגון מרשה, ואוכפת את זה ברמת הקוד - קריאה למודל שלא רשום ומאושר ב-Registry נכשלת אוטומטית, במקום להסתמך על כך שכל מפתח יזכור את הכללים בעל פה.

מעקב עלויות ברמת מודל

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

{
  "model_id": "claude-sonnet-4-5-20250929",
  "provider": "anthropic",
  "region": "eu-west-1",
  "context_window": 200000,
  "price_per_1m_input": 3.0,
  "price_per_1m_output": 15.0,
  "approved_for": ["production", "staging"],
  "eol_date": null,
  "monthly_calls": 4823110,
  "consumers": ["support-triage", "doc-summarizer"]
}

ניהול End-of-Life ומעברים בין דגמים

ספקי מודלים מכריזים מעת לעת על deprecation לגרסאות ישנות, לרוב עם חלון של חודשים ספורים. בלי Registry מרכזי, הודעת deprecation כזו מגיעה כמייל שרק חלק מהצוות רואה, ולעיתים מתגלה רק כשה-API כבר מפסיק לענות. Registry שמתעד תאריך EOL לכל מודל, ומחובר להתראות אוטומטיות, הופך את המעבר לתהליך מתוכנן: 90 יום לפני ה-EOL נפתחת אוטומטית משימה לכל צוות שצורך את המודל, עם דוח ביצועים משווה מול המודל המחליף המומלץ. זה הופך אירוע שיכול היה להיות תקרית production דחופה לפרויקט מתוכנן עם זמן תגובה סביר.

Multi-Provider Strategy וחוסן

ארגונים שמסתמכים על ספק מודלים יחיד חשופים לסיכון תפעולי אמיתי - השבתה זמנית של ה-API, שינוי מחירים חד-צדדי, או שינוי מדיניות יכולים לפגוע בכל המערכת בבת אחת. Model Registry שתומך במפורש בכמה ספקים לצד השוואת ביצועים בין מודלים שונים מאפשר אסטרטגיית fallback: אם מודל ראשי לא זמין, בקשה עוברת אוטומטית למודל חלופי מספק אחר שהוגדר מראש כתחליף מאושר. חשוב להדגיש שזו לא החלטה טכנית בלבד - היא דורשת שהתחליף כבר עבר את אותם שערי Evaluation ואישור אבטחת מידע כמו המודל הראשי, אחרת ה-fallback עצמו הופך למקור סיכון חדש.

אבטחת מידע ותאימות רגולטורית

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

טעויות נפוצות בפרודקשן

הטעות השכיחה ביותר היא שימוש ב-alias דינמי ("latest", "default") במקום snapshot מוצמד - זה מנוגד את כל הרעיון של Registry, כי המודל בפועל יכול להשתנות בלי שום רישום. טעות שנייה היא לתעד את המודל אבל לא לאכוף: Registry שהוא רק תיעוד ולא שער חובה שכל קריאה עוברת דרכו, מאבד את הערך שלו תוך חודשים, כי מפתחים ממשיכים לקרוא ישירות ל-API של הספק ועוקפים את השכבה המנוהלת. טעות שלישית היא להזניח את מעקב העלות בזמן אמת - ארגונים רבים מגלים חריגת תקציב חודשית רק כשהחשבונית מגיעה, במקום שה-Registry יתריע כשקצב הצריכה חורג מהצפוי.

מתי כדאי, ומתי זה מוקדם מדי

אם בארגון פועלים יותר משני מודלים או יותר משני צוותים שמשתמשים ב-AI, Model Registry הופך משמעותי ומחזיר את עצמו במהירות - הן בחיסכון בעלויות שמתגלה, והן במניעת תקריות deprecation. עבור סטארטאפ קטן עם Agent יחיד ומודל יחיד, גיליון אלקטרוני פשוט עם המפרטים הבסיסיים מספיק לחלוטין, ואין טעם להשקיע בבניית Registry מלא לפני שיש בכלל מגוון לנהל. נקודת המעבר הטבעית היא בדרך כלל כשמתחילים לשמוע את המשפט "רגע, מי בכלל אחראי על המודל הזה" בפעם השלישית באותו רבעון - זה הסימן הברור ביותר שהזמן הגיע.

אינטגרציה עם CI/CD ועם Agent Registry

Model Registry לא אמור לחיות כמסמך נפרד מהקוד - הערך האמיתי שלו מתממש כשהוא מתחבר ישירות לצינור ה-CI/CD. כל הגדרת Agent חדשה, כפי שנדון במאמר על Agent Versioning, צריכה לעבור בדיקת תקינות מול ה-Registry לפני שהיא מתקבלת: האם ה-model_id שהוגדר קיים ברשימת המודלים המאושרים, האם הוא מאושר לסביבת ה-production הרלוונטית, והאם הוא לא נמצא בתוך חלון ה-deprecation. בדיקה כזו, שרצה אוטומטית כחלק מה-pipeline, תופסת טעויות אנוש נפוצות כמו הפניה למודל שכבר הוצא משימוש, או שימוש בשם מודל עם typo קטן שבמקרה עדיין "עובד" כי הוא מפנה בטעות לגרסה אחרת לגמרי.

ניהול Quotas ו-Rate Limits ברמת ארגון

כשכמה צוותים חולקים אותו חוזה עם אותו ספק מודלים, יש צורך אמיתי בניהול מרכזי של מכסות: כמה קריאות בדקה מוקצות לכל צוות או Agent, כדי שאף אחד לא "יגנוב" את כל תקציב ה-rate limit ויגרום לצוותים אחרים לקבל שגיאות 429 בלתי צפויות. Model Registry שמנהל את ההקצאה הזו במפורש, כולל alerting כשצוות מתקרב למכסה שלו, הופך בעיה שבדרך כלל מתגלה רק בזמן תקרית לכזו שמנוהלת מראש בצורה שקופה. זה חשוב במיוחד סביב אירועים כמו השקות מוצר גדולות, כשכל הצוותים מגדילים תעבורה בו-זמנית והתחרות על אותו rate limit משותף יכולה ליצור כשל מדורג בכמה מערכות בו-זמנית.

ביצועים משתנים: אותו מודל, תוצאות שונות באזורים שונים

נקודה שמפתיעה צוותים רבים היא שאותו מזהה מודל, כשהוא נפרס באזורים גאוגרפיים שונים או דרך ספקי infrastructure שונים (למשל ישירות מול הספק לעומת דרך פלטפורמת ענן כמו Bedrock או Vertex), יכול להציג zman תגובה שונה, ולעיתים אפילו zמינות שונה מעט בהתנהגות בגלל הבדלים בתשתית ההרצה. Registry שמתעד לא רק את שם המודל אלא גם את נתיב הגישה הספציפי אליו - כולל האזור, הפלטפורמה, וגרסת ה-API - מאפשר להשוות ביצועים בפועל ולא להסתמך על הנחה ש"מודל X הוא תמיד מודל X" בלי קשר לאיך ניגשים אליו. זה רלוונטי במיוחד לארגונים גלובליים שצריכים לשרת משתמשים ממספר אזורים תוך עמידה בדרישות residency שונות בכל אזור.

שילוב עם דירוג ביצועים פנימי

מעבר למפרט הטכני והעלות שמפרסם הספק, לכל ארגון יש למעשה "טבלת ליגה" פנימית משלו - דירוג של המודלים הזמינים לפי ביצועים על המשימות הספציפיות שהארגון אכפת לו מהן, שנמדד דרך ה-Evaluation Registry. Model Registry שמציג את הדירוג הזה לצד כל מודל, ומתעדכן אוטומטית בכל פעם שרצה סוללת בדיקה חדשה, הופך את בחירת המודל למשימה חדשה מתבססת נתונים ולא על תחושת בטן או על מוניטין כללי של הספק. צוות שרוצה להוסיף Agent חדש יכול פשוט לשאול את ה-Registry "איזה מודל הכי מתאים למשימת סיווג טקסט בעברית בתקציב נתון" ולקבל תשובה מבוססת מדידה אמיתית, במקום לבחור את המודל הפופולרי ביותר בטוויטר של אותו שבוע.

סיכום

Model Registry הוא שכבת האמת היחידה על "אילו מודלים בכלל רצים אצלנו" - שאלה שנשמעת טריוויאלית עד שמנסים לענות עליה בפועל בארגון עם עשרות Agents, כמה ספקים, וכמה סביבות. הוא נותן נראות עלות בזמן אמת, מסלול deprecation מסודר במקום תקריות דחופות, תשתית לאכיפת מדיניות אבטחת מידע, ובסיס נתונים אמיתי לבחירת מודל לפי ביצועים ולא לפי תחושת בטן. ארגון שמגיע לשלב שבו יש בו יותר מצוות אחד שמפעיל AI, וטרם בנה Registry כזה, כנראה כבר מפסיד כסף בלי לדעת זאת - וזו בדיוק הסיבה שבמדיה דיל אנחנו ממליצים לבנות אותו מוקדם, לפני שהבלגן מצטבר לכדי פרויקט ניקוי גדול.

תגיות: Model Registry · MLOps · Enterprise AI · Model Deprecation · Multi-Provider · AI Governance · Cost Tracking

← חזרה לבלוג · צור קשר