תצורת הגשה של Tensorflow

במדריך זה, נעבור על נקודות התצורה הרבות עבור Tensorflow Serving.

סקירה כללית

בעוד שרוב התצורות מתייחסות לשרת המודל, ישנן דרכים רבות לציין את ההתנהגות של Tensorflow Serving:

• תצורת שרת דגם : ציין שמות דגמים, נתיבים, מדיניות גרסה ותוויות, תצורת רישום ועוד
• תצורת ניטור : אפשר והגדר ניטור Prometheus
• תצורת אצווה : הפעל אצווה והגדר את הפרמטרים שלו
• שונות דגלים : מספר שונות. דגלים שניתן לספק כדי לכוונן את ההתנהגות של פריסת Tensorflow Serving

תצורת שרת דגם

הדרך הקלה ביותר לשרת מודל היא לספק את הדגלים --model_name ו --model_base_path (או הגדרת משתנה הסביבה MODEL_NAME אם משתמשים ב-Docker). עם זאת, אם תרצה לשרת מספר דגמים, או להגדיר אפשרויות כמו תדירות סקר עבור גרסאות חדשות, תוכל לעשות זאת על ידי כתיבת קובץ תצורה של Model Server.

אתה יכול לספק קובץ תצורה זה באמצעות דגל --model_config_file ולהורות ל- Tensorflow Serving לבצע סקר מעת לעת עבור גירסאות מעודכנות של קובץ תצורה זה בנתיב שצוין על ידי הגדרת הדגל --model_config_file_poll_wait_seconds .

דוגמה לשימוש ב-Docker:

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

טוען מחדש את תצורת שרת הדגם

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

• על ידי הגדרת הדגל --model_config_file_poll_wait_seconds כדי להורות לשרת לבדוק מעת לעת קובץ תצורה חדש ב-- --model_config_file filepath.

• על ידי הוצאת HandleReloadConfigRequest קריאות RPC לשרת ואספקת תצורה חדשה של Model Server באופן פרוגרמטי.

שים לב שבכל פעם שהשרת טוען את קובץ התצורה החדש, הוא יפעל למימוש התוכן של התצורה החדשה שצוינה ורק את התצורה החדשה שצוינה. המשמעות היא שאם דגם A היה קיים בקובץ התצורה הראשון, אשר מוחלף בקובץ המכיל רק דגם B, השרת יטען דגם B ויפרוק דגם A.

פרטי תצורת שרת דגם

קובץ התצורה של Model Server שסופק חייב להיות מאגר פרוטוקול ModelServerConfig .

עבור כל מקרי השימוש מלבד המתקדמים ביותר, תרצה להשתמש באפשרות ModelConfigList, שהיא רשימה של מאגרי פרוטוקול ModelConfig . הנה דוגמה בסיסית, לפני שנצלול לאפשרויות מתקדמות למטה.

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

הגדרת דגם אחד

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

הגשת גרסה ספציפית של דגם

כדי להגיש גרסה ספציפית של המודל, במקום לעבור תמיד לגרסה עם מספר הגרסה הגדול ביותר, הגדר את model_version_policy ל"ספציפי" וציין את מספר הגרסה שברצונך להציג. לדוגמה, כדי להצמיד את גרסה 42 כזו שתשרת:

model_version_policy {
  specific {
    versions: 42
  }
}

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

מגיש גרסאות מרובות של דגם

כדי להגיש גרסאות מרובות של המודל בו-זמנית, למשל כדי לאפשר קנרית גרסה חדשה טנטטיבית עם נתח של תעבורה, הגדר את model_version_policy ל"ספציפי" וספק מספרי גרסאות מרובים. לדוגמה, כדי להגיש גרסאות 42 ו-43:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

הקצאת תוויות מחרוזות לגרסאות דגם, כדי לפשט את הקנרי והחזרה

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

אתה יכול להגדיר את כינויי גרסאות הדגם האלה, או תוויות, כך:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

בדוגמה שלמעלה, אתה משרת את גרסאות 42 ו-43, ומשייך את התווית "יציב" לגרסה 42 ואת התווית "קנרית" לגרסה 43. תוכל לבקש מהלקוחות שלך להפנות שאילתות לאחת של "יציב" או "כנרית" (אולי מבוסס על hashing של מזהה המשתמש) באמצעות השדה version_label של מאגר הפרוטוקול ModelSpec , ולהעביר את התווית קדימה בשרת מבלי להודיע ​​ללקוחות. לאחר שתסיים להשתמש בגרסה 43 ותהיה מוכן לקדם אותה ליציבה, תוכל לעדכן את התצורה ל:

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

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

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

אם ברצונך להקצות תווית לגרסה שעדיין לא נטענה (למשל על ידי אספקת גרסת הדגם וגם התווית בזמן ההפעלה), עליך להגדיר את הדגל --allow_version_labels_for_unavailable_models ל-true, מה שמאפשר לתוויות חדשות יוקצה לגרסאות דגם שעדיין לא נטענו.

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

על מנת לעמוד בבדיקת בטיחות זו, אם מקצה מחדש תווית גרסה שכבר נמצאת בשימוש, עליך להקצות אותה רק לגרסאות שכבר טענו. לדוגמה, אם תרצה להעביר תווית מהצבעה לגרסה N לגרסה N+1, תחילה תוכל לשלוח תצורה המכילה את גרסה N ו-N+1, ולאחר מכן לשלוח תצורה המכילה את גרסה N+1, התווית מצביע על N+1 וללא גרסה N.

שימוש במנוחה

אם אתה משתמש במשטח REST API כדי לבצע בקשות להסיק, במקום להשתמש

/v1/models/<model name>/versions/<version number>

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

/v1/models/<model name>/labels/<version label> .

שימו לב שתווית הגרסה מוגבלת לרצף של תווי Word, המורכב מתווים אלפא-מספריים וקווים תחתונים (כלומר [a-zA-Z0-9_]+ ).

תצורת ניטור

אתה יכול לספק תצורת ניטור לשרת על ידי שימוש בדגל --monitoring_config_file כדי לציין קובץ המכיל מאגר פרוטוקול MonitoringConfig . הנה דוגמה:

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

כדי לקרוא מדדים מכתובת האתר לניטור לעיל, תחילה עליך להפעיל את שרת ה-HTTP על ידי הגדרת הדגל --rest_api_port . לאחר מכן תוכל להגדיר את שרת Prometheus שלך למשוך מדדים משרת המודל על ידי העברת הערכים של --rest_api_port ו- path .

Tensorflow Serving אוסף את כל המדדים שנלכדים על ידי Serving וכן Tensorflow הליבה.

תצורת אצווה

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

קובץ פרמטרי אצווה לדוגמה:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

אנא עיין במדריך האצווה לדיון מעמיק ועיין בסעיף על פרמטרים כדי להבין כיצד להגדיר את הפרמטרים.

דגלים שונים

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

• --port : יציאה להאזנה עבור gRPC API
• --rest_api_port : יציאה להאזנה עבור HTTP/REST API
• --rest_api_timeout_in_ms : זמן קצוב לקריאות HTTP/REST API
• --file_system_poll_wait_seconds : התקופה שבה השרת סוקר את מערכת הקבצים עבור גרסאות מודל חדשות ב-model_base_path של כל דגם.
• --enable_model_warmup : מאפשר חימום מודל באמצעות PredictionLogs שסופקו על ידי המשתמש בספריית assets.extra/
• --mixed_precision=bfloat16 : מאפשר BF16 דיוק מעורב אוטומטי