שיטות עבודה מומלצות לאימון האצה של TensorFlow 1.x ב-Amazon SageMaker

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

אמזון SageMaker היא פלטפורמת למידת מכונה מנוהלת במלואה (ML) שיכולה לעזור למדעני נתונים להתמקד במודלים במקום בתשתית, עם תמיכה מקורית באלגוריתמים ומסגרות הבאות משלך כגון TensorFlow ו-PyTorch. SageMaker מציע אפשרויות אימון מבוזרות גמישות המותאמות לזרימות העבודה הספציפיות שלך. מכיוון שלמדעני נתונים רבים עשויים להיות חסרי ניסיון בתהליך אימון האצה, בפוסט זה אנו מראים לך את הגורמים החשובים לאימון מודל למידה עמוקה מהירה ואת השיטות המומלצות של אימון האצה עבור TensorFlow 1.x ב- SageMaker. יש לנו גם קוד לדוגמה של DeepFM הפצת הדרכה על SageMaker על GitHub ריפו.

ישנם גורמים רבים שאתה צריך לשקול כדי למקסם את ניצול ה-CPU/GPU כאשר אתה מפעיל את הסקריפט של TensorFlow ב- SageMaker, כגון תשתית, סוג המאיץ, שיטת אימון מבוזרת, שיטת טעינת נתונים, אימון דיוק מעורב ועוד.

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

• האץ את האימון במופע בודד
• האץ את האימון במספר מקרים
• צינורות נתונים
• אימון דיוק מעורב אוטומטי

האץ את האימון במופע בודד

בעת הפעלת סקריפט TensorFlow על מופע בודד, תוכל לבחור סדרה מותאמת למחשב כגון ענן מחשוב אלסטי של אמזון (Amazon EC2) סדרת C5, או סדרת מחשוב מואצת עם מספר GPU במופע בודד כגון p3.8xlarge, p3.16xlarge, p3dn.24xlarge ו-p4d.24xlarge.

בסעיף זה, אנו דנים באסטרטגיות למעבדים מרובים במופע בודד, והדרכה מבוזרת עם מספר מעבדי GPU במופע בודד.

מעבדים מרובים במופע אחד

בסעיף זה, אנו דנים בהגדרה ידנית של מקביליות של מפעילים בהתקני מעבד, שיטת המגדל, TensorFlow MirroredStrategy ו- Horovod.

הגדרה ידנית של מקביליות של מפעילים בהתקני CPU

TensorFlow בוחר אוטומטית את המספר המתאים של חוטים כדי להקביל את חישוב הפעולה בתהליך האימון. עם זאת, אתה יכול להגדיר את intra_op חוטים בריכת ו inter_op הגדרות מקביליות שסופקו על ידי TensorFlow ושימוש במשתני סביבה של MKL-DNN כדי להגדיר כריכה עבור שרשור מערכת ההפעלה. ראה את הקוד הבא:

# Set parallelism of intra_op and inter_op
num_cpus = int(os.environ['SM_NUM_CPUS'])
config = tf.ConfigProto(allow_soft_placement=True, device_count={'CPU': num_cpus}, intra_op_parallelism_threads=num_cpus, inter_op_parallelism_threads=num_cpus)
run_config = tf.estimator.RunConfig().replace(session_config = config)

# Use Intel MKL-DNN Setting to accelerate training speed
os.environ["KMP_AFFINITY"]= "verbose,disabled"
os.environ['OMP_NUM_THREADS'] = str(num_cpus)
os.environ['KMP_SETTINGS'] = '1'

משתנה הסביבה KMP_AFFINITY של MKL-DNN מוגדר ל granularity=fine,compact,1,0 כברירת מחדל. לאחר הגדרת התוך והאינטרנט של TensorFlow למספר המרבי של vCPUs של המופע הנוכחי, הגבול העליון של השימוש במעבד כמעט זהה למספר הליבות הפיזיות של מופע האימון.

אם אתה מגדיר os.environ["KMP_AFFINITY"]= "verbose,disabled", שרשור מערכת ההפעלה אינו קשור ל-hyper thread של החומרה, ושימוש במעבד עלול לעלות על מספר הליבות הפיזיות.

לגבי ההגדרות של TensorFlow תוך מקביליות, TensorFlow inter parallelism ומספר חוטי MKL-DNN, שילובים שונים של שלושת הפרמטרים הללו מביאים למהירויות אימון שונות. לכן, אתה צריך לבדוק כל מקרה כדי למצוא את השילוב הטוב ביותר. מצב נפוץ הוא להגדיר את שלושת הפרמטרים (intra_op_parallelism_threads ו inter_op_parallelism_threads עבור TensorFlow, os.environ['OMP_NUM_THREADS'] עבור MKL-DNN) למחצית ממספר ה-vCPUs (הליבה הפיזית) או המספר הכולל של vCPUs.

שיטת מגדל

כדי לשכפל מודל על פני GPUs, כל GPU מקבל מופע משלו של העברה קדימה. המופע של העברה קדימה נקרא a מגדל. שיטת המגדל משמשת כמעט תמיד עבור התקני GPU. כדי להשוות את מהירות האימון לשיטות אחרות, כאן אנו משתמשים גם בשיטת המגדל עבור מכשיר המעבד שלנו.

אם לא תגדיר את התקן ה-CPU ידנית, TensorFlow אל תשתמש בשיטת המגדל לממוצע ההדרגות, כך שלא תצטרך לשנות את גודל האצווה במקרים כאלה.

1. הגדר את התקן המעבד באופן ידני:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))

2. השתמש replicate_model_fn לעטוף model_fn:

DeepFM = tf.estimator.Estimator(model_fn=tf.contrib.estimator.replicate_model_fn(model_fn, devices=device_list), model_dir=FLAGS.model_dir, params=model_params, config=config)

3. השתמש TowerOptimizer לעטוף optimizer:

optimizer = tf.contrib.estimator.TowerOptimizer(optimizer)

4. עטוף את שלך model_fn:

with tf.variable_scope(‘deepfm_model’, reuse=tf.AUTO_REUSE)

5. שנה את גודל האצווה ל-(NUM_CPU – 1).

בואו נסתכל על ההבדל בשימוש במעבד עם מצב מגדל מופעל. האיור הבא מציג את ניצול המעבד של ml.c5.18xlarge עם התצורה הבאה:

אין מגדל + נתוני LibSVM + מצב צינור + MKL-DNN השבתת כריכה + הגדרת מקביליות תוך/אינטראופית של TensorFlow למספר המרבי של מעבדי vCPU של מופע

האיור הבא מציג את ניצול המעבד של המופע ml.c5.18xlarge עם התצורה הבאה:

מגדל עם התקן CPU מוגדר + נתוני LibSVM + מצב צינור + MKL-DNN השבתת כריכה + הגדרת מקביליות תוך/אינטראופית של TensorFlow למספר מקסימלי של מעבדי vCPU של מופע

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

TensorFlow Mirrored Strategy

TensorFlow MirroredStrategy פירושה אימון סינכרוני על פני מספר העתקים במכונה אחת. אסטרטגיה זו משמשת בדרך כלל לאימון במכונה אחת עם מספר GPUs. כדי להשוות את מהירות האימון לשיטה אחרת, אנו משתמשים ב-MirroredStrategy עבור מכשיר ה-CPU שלנו.

בעת שימוש ב-TensorFlow MirroredStrategy, אם לא תגדיר את התקן המעבד, TensorFlow פשוט משתמש במעבד אחד כעובד יחיד, וזה בזבוז משאבים. אנו ממליצים להגדיר ידנית את התקן המעבד, מכיוון שהוא יבצע פעולת הפחתה מופעלת /CPU:0, כך /CPU:0 המכשיר אינו משמש כאן כעותק. ראה את הקוד הבא:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))
mirrored_strategy = tf.distribute.MirroredStrategy(devices=devices_list)
	else:
mirrored_strategy = tf.distribute.MirroredStrategy()

# Set strategy to config:
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
eval_distribute=mirrored_strategy,
session_config = config)

אתה צריך לשנות את גודל האצווה בעת שימוש ב-MirroredStrategy; לדוגמה, שנה את גודל האצווה לכפולה של מספר התקני ה-GPU.

עבור אסטרטגיית המשנה בעת הגדרת התקן CPU, אם לא תגדיר את cross_device_ops פרמטר tf.distribute.MirroredStrategy(), TensorFlow משתמש ב- ReductionToOneDevice אסטרטגיית משנה כברירת מחדל. עם זאת, אם אתה מגדיר HierarchicalCopyAllReduce בתור אסטרטגיית המשנה, TensorFlow רק עושה את העבודה לצמצום /CPU:0. כאשר אתה משתמש בממשק ה-API של הנתונים של TensorFlow ומפיץ את האסטרטגיה יחד, יש להחזיר את אובייקט הנתונים במקום תכונות ותוויות בפונקציה input_fn.

בדרך כלל, TensorFlow MirroredStrategy איטית יותר משיטת המגדל באימוני מעבד, ולכן איננו ממליצים להשתמש ב-MirroredStrategy על מארח יחיד מרובה מעבדים.

הורובוד

הורובוד היא מסגרת אימון למידה עמוקה מבוזרת עבור TensorFlow, Keras, PyTorch ו- Apache MXNet. המטרה של Horovod היא להפוך את הלמידה העמוקה מבוזרת למהירה וקלה לשימוש.

יש פרמטר של distribution ב- SageMaker Python SDK Estimator API, שבו תוכל להשתמש כדי לציין את ההדרכה המבוזרת של Horovod. SageMaker מספקת את התשתית ומריצה את הסקריפט שלך עם MPI. ראה את הקוד הבא:

hvd_processes_per_host = 4
distribution = {'mpi': { 
'enabled': True, 
'processes_per_host': hvd_processes_per_host,
'custom_mpi_options': '-verbose --NCCL_DEBUG=INFO -x OMPI_MCA_btl_vader_single_copy_mechanism=none' 
} 
}

בעת בחירת מופע GPU כגון ml.p3.8xlarge, עליך להצמיד כל GPU עבור כל עובד:

config = tf.ConfigProto()
config.gpu_options.visible_device_list = str(hvd.local_rank())

כדי להאיץ את התכנסות המודל, הגדל את קצב הלמידה לפי מספר העובדים על פי התיעוד הרשמי של הורובוד. עם זאת, בפרויקטים בעולם האמיתי, עליך להתאים את קצב הלמידה במידה מסוימת, אך לא לפי מספר העובדים, מה שמביא לביצועי מודל גרועים. לדוגמה, אם קצב הלמידה המקורי הוא 0.001, אנו מדרגים את קצב הלמידה ל-0.0015, גם אם מספר העובדים הוא ארבעה או יותר.

בדרך כלל, רק הראשוני (דרגת הורובוד 0) שומר את המחסום והמודל וכן את פעולת ההערכה. אתה לא צריך להתאים את גודל האצווה בעת שימוש בהרובוד. SageMaker מציעה מצב צינור כדי להזרים מהם נתונים שירות אחסון פשוט של אמזון (Amazon S3) לתוך מקרי אימון. כאשר אתה מפעיל מצב Pipe, שים לב שעובדים שונים באותו מארח צריכים להשתמש בערוצים שונים כדי למנוע שגיאות. הסיבה לכך היא שתהליך העבודה הראשון קורא את נתוני ה-FIFO/ערוץ, ותהליכי עבודה אחרים באותו מופע יתקעו מכיוון שהם לא יכולים לקרוא נתונים מאותו FIFO/ערוץ, כך שהורובוד לא עובד כמו שצריך. כדי למנוע בעיה זו, הגדר את הערוצים בהתאם למספר העובדים בכל מופע. לפחות ודא שעובדים שונים באותו מארח צורכים ערוצים שונים; אותו ערוץ יכול להיות נצרך על ידי עובדים במארח אחר.

בעת שימוש ב- Horovod, אתה עלול להיתקל בשגיאה הבאה:

“One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.”

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

פיצול נתונים הוא אחד הדברים החשובים ביותר שיש לקחת בחשבון בעת ​​שימוש באימון מבוזר. אתה יכול להשתמש ב- TensorFlow dataset.shard() בתסריט שלך. SageMaker מציעה גם תכונת רסיסי נתונים ב- ערוץ קלט על פי הגדרה distribution=S3shardbykey בערוץ הנתונים. ראה את הקוד הבא:

dataset = PipeModeDataset(channel, record_format='TFRecord')

number_host = len(FLAGS.hosts)

if FLAGS.enable_data_multi_path : # If there are multi channels mapping with different S3 path
    if FLAGS.enable_s3_shard == False :
        if number_host > 1:
            index = hvd.rank() // FLAGS.worker_per_host
            dataset = dataset.shard(number_host, index)
else :
    if FLAGS.enable_s3_shard :
        dataset = dataset.shard(FLAGS.worker_per_host, hvd.local_rank())
    else :
        dataset = dataset.shard(hvd.size(), hvd.rank())

האיור הבא מציג את התוצאה בעת שימוש ב- Horovod (ml.c5.18xlarge, Horovod + LibSVM + הגדרת ברירת מחדל של intra op ו-inter op), אותה ניתן להשוות לשיטת המגדל.

אימון מבוזר עם מספר GPUs במופע אחד

זה נורמלי להתחיל אימון מבוזר עם מספר GPUs במופע אחד, מכיוון שמדעני נתונים צריכים לנהל רק מופע אחד ולנצל את הקישור המהיר בין GPUs. עבודות הדרכה של SageMaker תומכות במספר סוגי מופעים שיש להם מספר GPUs במופע בודד, כגון ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge ו-ml.p4d.24xlarge. השיטה זהה למעבדים מרובים במופע בודד, אך עם כמה שינויים בסקריפט.

שיטת מגדל

שיטת המגדלים כאן כמעט זהה לאימון מרובי מעבדים. עליך לשנות את גודל האצווה בהתאם למספר ה-GPUs בשימוש.

TensorFlow Mirrored Strategy

תת-אסטרטגיית ברירת המחדל של MirroredStrategy is NcclAllReduce. עליך לשנות את גודל האצווה בהתאם למספר ה-GPUs בשימוש. ראה את הקוד הבא:

mirrored_strategy = tf.distribute.MirroredStrategy()
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
				eval_distribute=mirrored_strategy)

האץ את האימון במספר מקרים

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

מעבדים מרובים עם מספר מופעים

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

• • שרת פרמטרים ללא הגדרה ידנית של מקביליות של מפעילים במכשירי CPU
  • שרת פרמטרים עם הגדרה ידנית של מקביליות של מפעילים במכשירי CPU
  • שרת פרמטרים עם מגדל (הגדרת התקני מעבד באופן ידני, ומוגדר allow_soft_placement=True in tf.ConfigProto)
  • הורובוד

בעת שימוש בשרת פרמטרים ב- tf.estimator API, הנתיב של המחסום חייב להיות נתיב שניתן לשיתוף כגון Amazon S3 או הנתיב המקומי של שירות קבצים אלסטי של אמזון (Amazon EFS) מיפוי למיכל. עבור שרת פרמטרים ב tf.keras, ניתן להגדיר את נתיב המחסום לנתיב המקומי. עבור Horovod, ניתן להגדיר את נתיב המחסום לנתיב מקומי של מופע האימון.

בעת שימוש בשרת פרמטרים וב- tf.estimator API עם נתיב המחסום לאמזון S3, אם המודל די גדול, אתה עלול להיתקל בשגיאה של נקודת הבידוק הראשית תקועה בשמירת המחסום ל-S3. אתה יכול להשתמש במיכל המובנה של SageMaker TensorFlow 1.15 או TensorFlow 1.15.2 או להשתמש ב- Amazon EFS כנתיב המחסום של השיתוף.

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

with tf.variable_scope('deepfm_model', reuse=tf.AUTO_REUSE, partitioner = tf.fixed_size_partitioner(num_shards=len(FLAGS.hosts))):

GPU יחיד עם מספר מופעים

משרות הדרכה של SageMaker תומכות במופעים שיש להם רק GPU אחד, כמו סדרת ml.p3.xlarge, ml.g4dn ו-ml.g5. ישנן שתי שיטות עיקריות המשמשות בתרחיש זה: שרתי פרמטרים ו- Horovod.

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

להורובוד, פשוט הגדר processes_per_host=1 בפרמטר ההפצה של SageMaker Python Estimator API.

מספר GPUs עם מספר מופעים

עבור שרתי פרמטרים ושיטת המגדל, שינויי הקוד זהים בעצם לשיטת המגדל עבור מופע בודד עם מספר GPUs, ואין צורך להגדיר ידנית את התקני ה-GPU.

עבור Horovod, הגדר processes_per_host בפרמטר ההפצה למספר GPUs של כל מופע אימון. אם אתה משתמש במצב Pipe, מספר העובדים בכל מופע צריך להתאים למספר הערוצים.

צינורות נתונים

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

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

בואו נסתכל על האינטראקציה בין GPU ו-CPU במהלך האימון. האיורים הבאים משווים אינטראקציות עם ובלי צינור.

צינור טוב יותר יכול להפחית את זמן השבתה של ה-GPU. שקול את העצות הבאות:

• השתמש בלוגיקה פשוטה של ​​פונקציות בחילוץ תכונות ותוויות
• שלף מראש דוגמאות לזיכרון
• צמצם קלט/פלט דיסק מיותרים וקלט/פלט רשת
• שמור את התכונות והתוויות המעובדות בזיכרון
• צמצם את מספר זמני השכפול בין המעבד ל-GPU
• בקש מהעובדים השונים להתמודד עם חלקים שונים של מערך ההדרכה
• צמצם את זמני הקריאה ל-API של הנתונים של TensorFlow

TensorFlow מספק ממשק API לטרנספורמציה הקשור לפורמטים של מערך נתונים, והסדר של ממשק ה-API לשינוי ב-TensorFlow משפיע רבות על מהירות האימון. יש לבדוק את הסדר הטוב ביותר של קריאה ל-API של הנתונים של TensorFlow. להלן כמה עקרונות בסיסיים:

• השתמש במפה וקטורית. משמעות הדבר היא לקרוא תחילה לממשק ה-API של מערך הנתונים של TensorFlow, ולאחר מכן ל-API של מפת הנתונים. פונקציית הניתוח המותאם אישית הניתנת בפונקציית המפה, כגון decode_tfrecord בקוד לדוגמה, מנתח מיני אצווה של נתונים. להיפך, מפה תחילה ואחר כך אצווה היא מפה סקלרית, והפונקציה המנתח המותאם אישית מעבדת רק דוגמה אחת.
• השתמש בממשק API של מטמון הנתונים של TensorFlow כדי לשמור תכונות ותוויות במטמון. שים את ה-API של מטמון הנתונים של TensorFlow לפני ה-API של החזרה של מערך הנתונים של TensorFlow, אחרת ניצול ה-RAM גדל באופן ליניארי תקופה אחר תקופה. אם מערך הנתונים גדול כמו זיכרון RAM, אל תשתמש בממשק API של מטמון הנתונים של TensorFlow. אם אתה צריך להשתמש במטמון ה-API של הנתונים של TensorFlow וב-SHuffle API, שקול להשתמש בסדר הבא: צור אובייקט מערך נתונים של TensorFlow -> מטמון API -> shuffle API -> אצווה API -> מפה API -> API חוזר -> ממשק API.
• השתמש tfrecord פורמט מערך הנתונים יותר מפורמט LibSVM.
• מצב קובץ או מצב Pipe תלוי בפורמט מערך הנתונים ובכמות הקבצים. ה tfrecorddataset API יכול להגדיר num_parallel_reads לקרוא מספר קבצים במקביל ולהגדיר buffer_size כדי לייעל את קריאת הנתונים, בעוד שה pipemodedataset ל-API אין הגדרות כאלה. מצב Pipe מתאים יותר למצבים שבהם קובץ בודד גדול ומספר הקבצים הכולל קטן. אנו ממליצים להשתמש בעבודת עיבוד של SageMaker כדי לבצע את עבודת העיבוד המקדים, כגון צירוף קבצים מרובים לקובץ גדול יותר לפי תוויות, שימוש בשיטת דגימה כדי להפוך את מערך הנתונים למאוזן יותר, וערבוב מערך הנתונים המאוזן.

ראה את דוגמת הקוד הבאה:

def decode_tfrecord(batch_examples):
        # The feature definition here should BE consistent with LibSVM TO TFRecord process.
        features = tf.parse_example(batch_examples,
                                           features={
                                               "label": tf.FixedLenFeature([], tf.float32),
                                               "ids": tf.FixedLenFeature(dtype=tf.int64, shape=[FLAGS.field_size]),
                                               "values": tf.FixedLenFeature(dtype=tf.float32, shape=[FLAGS.field_size]) 
                                           })
        
        batch_label = features["label"]
        batch_ids = features["ids"]
        batch_values = features["values"]
        
        return {"feat_ids": batch_ids, "feat_vals": batch_values}, batch_label


    def decode_libsvm(line):
        columns = tf.string_split([line], ' ')
        labels = tf.string_to_number(columns.values[0], out_type=tf.float32)
        splits = tf.string_split(columns.values[1:], ':')
        id_vals = tf.reshape(splits.values,splits.dense_shape)
        feat_ids, feat_vals = tf.split(id_vals,num_or_size_splits=2,axis=1)
        feat_ids = tf.string_to_number(feat_ids, out_type=tf.int32)
        feat_vals = tf.string_to_number(feat_vals, out_type=tf.float32)
        return {"feat_ids": feat_ids, "feat_vals": feat_vals}, labels

if FLAGS.pipe_mode == 0:
        dataset = tf.data.TFRecordDataset(filenames)
    else :
        # Enter Pipe mode
        dataset = PipeModeDataset(channel, record_format='TFRecord')
        
    if FLAGS.enable_s3_shard == False:
        host_rank = FLAGS.hosts.index(FLAGS.current_host)
        number_host = len(FLAGS.hosts)
        dataset = dataset.shard(number_host, host_rank)
    
    dataset = dataset.batch(batch_size, drop_remainder=True) # Batch size to use
    dataset = dataset.map(decode_tfrecord,
                          num_parallel_calls=tf.data.experimental.AUTOTUNE) 

    if num_epochs > 1:
        dataset = dataset.repeat(num_epochs)
    dataset = dataset.prefetch(buffer_size=tf.data.experimental.AUTOTUNE)

להדרכה על מופעי CPU, הגדרת מקביליות של intra op, inter op, ומשתנה הסביבה של MKL-DNN הוא נקודת התחלה טובה.

אימון דיוק מעורב אוטומטי

הדבר האחרון שאנו דנים בו הוא אימון דיוק מעורב אוטומטי, שיכול להאיץ מהירות ולגרום לביצועי המודל. נכון לכתיבת שורות אלה, Nvidia V100 GPU (מופע P3) ו-A100 (מופע P4dn) תומכים בליבת Tensor. אתה יכול לאפשר אימון דיוק מעורב ב-TensorFlow בעת שימוש בסוגים אלה של מופעים. החל מגרסה 1.14, TensorFlow תמך באימון דיוק מעורב אוטומטי. אתה יכול להשתמש בהצהרה הבאה כדי לעטוף את כלי האופטימיזציה המקורי שלך:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

אם הדגם קטן והניצול של GPU נמוך, אין יתרון לאימון דיוק מעורב אוטומטי. אם הדגם גדול, אימון דיוק מעורב אוטומטי יכול להאיץ את מהירות האימון.

סיכום

כאשר אתה מתחיל את אימון מודל הלמידה העמוק שלך ב- SageMaker, שקול את העצות הבאות כדי להשיג מהירות אימון מהירה יותר:

• נסה תחילה את שיטת ריבוי המעבדים, מופע יחיד או שיטת GPU יחידה, מופע יחיד. אם ניצול ה-CPU/GPU גבוה מאוד (לדוגמה יותר מ-90%), עבור לשלב הבא.
• נסה יותר CPUs במארח יחיד או יותר GPUs במארח יחיד. אם הניצול קרוב לניצול המקסימלי של CPUs או GPUs, עבור לשלב הבא.
• נסה מספר CPUs או מספר GPUs עם מספר מארחים.
• אתה צריך לשנות קודים בעת שימוש בשרתי פרמטרים או Horovod. שינוי הקוד אינו זהה עבור ה-API מבוסס-ההפעלה של TensorFlow, tf.estimator API, ו tf.keras ממשק API. שרת פרמטרים או Horovod עשויים להראות מהירויות אימון שונות במקרים ומשימות אימון שונות, אז נסה את שתי השיטות אם יש לך זמן ותקציב כדי לקבוע מהי הטובה ביותר.

זכור את העצה הבאה:

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

יש לנו גם דגימת קוד ב- GitHub ריפו, שם אנו מציגים שתי דוגמאות של אימונים מבוזרים DeepFM ב- SageMaker. האחד הוא שרת פרמטרים של TensorFlow במופעי CPU, השני הוא Horovod במופעי GPU.

על הכותבים

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

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