‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הצגת מודלים פתוחים באמצעות קונטיינר פרימיום של Hex-LLM ב-Cloud TPU

‫Hex-LLM, מודל שפה גדול (LLM) יעיל במיוחד שמופעל באמצעות XLA, הוא framework של מודל שפה גדול של Gemini Enterprise Agent Platform, שתוכנן ועבר אופטימיזציה לשימוש בחומרה של Cloud TPU. ‫Hex-LLM משלב טכנולוגיות להפעלת מודלים גדולים של שפה (LLM), כמו PagedAttention ועיבוד רציף של קבוצות נתונים, עם אופטימיזציות של Gemini Enterprise Agent Platform שמותאמות ל-XLA ול-Cloud TPU. זהו כלי יעיל וזול להפעלת מודלים גדולים של שפה (LLM) ב-Cloud TPU עבור מודלים בקוד פתוח.

‫Hex-LLM זמין ב-Model Garden דרך סביבת ארגז חול של מודלים, פריסה בלחיצה אחת ונוטבוק.

תכונות

‫Hex-LLM מבוסס על פרויקטים בקוד פתוח עם אופטימיזציות של Google ל-XLA ול-Cloud TPU. המודל הזה מאפשר תפוקה גבוהה וזמן אחזור נמוך כשממלאים בקשות למודלים גדולים של שפה (LLM) שנמצאים בשימוש תדיר.

‫Hex-LLM כולל את האופטימיזציות הבאות:

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

‫Hex-LLM תומך במגוון רחב של מודלים גדולים של שפה (LLM) צפופים ודלילים:

‫Gemma 2B ו-7B
‫Gemma-2 9B ו-27B
‫Llama-2 7B, ‏ 13B ו-70B
‫Llama-3 8B ו-70B
‫Llama-3.1 8B ו-70B
‫Llama-3.2 1B ו-3B
Llama-3.3 70B
‫Llama-Guard-3 1B ו-8B
Llama-4 Scout-17B-16E
Mistral 7B
‫Mixtral 8x7B ו-8x22B
‫Phi-3 mini ו-Phi-3 medium
‫Phi-4, ‏ Phi-4 reasoning ו-reasoning plus
‫Qwen-2 0.5B, ‏ 1.5B ו-7B
‫Qwen-2.5 0.5B, 1.5B, 7B, 14B and 32B

‫Hex-LLM כולל גם מגוון תכונות, כמו:

‫Hex-LLM כלול בקונטיינר יחיד. חבילת Hex-LLM כוללת את שרת ה-API, מנוע ההסקה והמודלים הנתמכים בקובץ אימג' יחיד של Docker שניתן לפריסה.
תואם לפורמט של מודלים של Hugging Face. ‫Hex-LLM יכול לטעון מודל של Hugging Face מדיסק מקומי, מ-Hugging Face Hub ומקטגוריה של Cloud Storage.
קוונטיזציה באמצעות bitsandbytes ו-AWQ.
טעינה של LoRA דינמי. ‫Hex-LLM יכול לטעון את משקלי LoRA באמצעות קריאת ארגומנט הבקשה במהלך ההפעלה.

תכונות מתקדמות

‫Hex-LLM תומך בתכונות המתקדמות הבאות:

הצגה במספר מארחים
הצגה מפורקת [ניסוי]
שמירה במטמון של קידומות
תמיכה בקוונטיזציה של 4 ביט

הצגה במספר מארחים

‫Hex-LLM תומך עכשיו בהצגת מודלים עם פרוסת TPU מרובת מארחים. התכונה הזו מאפשרת להכניס לשימוש בסביבת הייצור מודלים גדולים שלא ניתן לטעון אותם במכונת TPU וירטואלית אחת בצד המארח, שמכילה לכל היותר שמונה ליבות v5e.

כדי להפעיל את התכונה הזו, צריך להגדיר את --num_hosts בארגומנטים של מאגר Hex-LLM ולהגדיר את --tpu_topology בבקשת ההעלאה של מודל Vertex AI SDK. בדוגמה הבאה מוצג איך לפרוס את מאגר Hex-LLM עם טופולוגיה של TPU 4x4 v5e שמשרתת את מודל Llama 3.1 70B bfloat16:

hexllm_args = [
    "--host=0.0.0.0",
    "--port=7080",
    "--model=meta-llama/Meta-Llama-3.1-70B",
    "--data_parallel_size=1",
    "--tensor_parallel_size=16",
    "--num_hosts=4",
    "--hbm_utilization_factor=0.9",
]

model = aiplatform.Model.upload(
    display_name=model_name,
    serving_container_image_uri=HEXLLM_DOCKER_URI,
    serving_container_command=["python", "-m", "hex_llm.server.api_server"],
    serving_container_args=hexllm_args,
    serving_container_ports=[7080],
    serving_container_predict_route="/generate",
    serving_container_health_route="/ping",
    serving_container_environment_variables=env_vars,
    serving_container_shared_memory_size_mb=(16 * 1024),  # 16 GB
    serving_container_deployment_timeout=7200,
    location=TPU_DEPLOYMENT_REGION,
)

model.deploy(
    endpoint=endpoint,
    machine_type=machine_type,
    tpu_topology="4x4",
    deploy_request_timeout=1800,
    service_account=service_account,
    min_replica_count=min_replica_count,
    max_replica_count=max_replica_count,
)

במחברת Agent Platform Model Garden - Llama 3.1 (Deployment) יש הדרכה מקיפה לפריסת מאגר Hex-LLM עם טופולוגיית TPU מרובת מארחים.

באופן כללי, השינויים היחידים שצריך לבצע כדי להפעיל הצגה בכמה מארחים הם:

מגדירים את הארגומנט --tensor_parallel_size למספר הכולל של ליבות בטופולוגיית ה-TPU.
מגדירים את הארגומנט --num_hosts למספר המארחים בטופולוגיית ה-TPU.
מגדירים את --tpu_topology באמצעות Vertex AI SDK model upload API.

הצגה מפורקת [ניסוי]

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

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

כדי להפעיל את התכונה הזו, צריך להגדיר את --disagg_topo בארגומנטים של מאגר התגים Hex-LLM. בדוגמה הבאה מוצג איך לפרוס את קונטיינר Hex-LLM ב-TPU v5e-8 שמשרת את מודל Llama 3.1 8B bfloat16:

hexllm_args = [
    "--host=0.0.0.0",
    "--port=7080",
    "--model=meta-llama/Llama-3.1-8B",
    "--data_parallel_size=1",
    "--tensor_parallel_size=2",
    "--disagg_topo=3,1",
    "--hbm_utilization_factor=0.9",
]

model = aiplatform.Model.upload(
    display_name=model_name,
    serving_container_image_uri=HEXLLM_DOCKER_URI,
    serving_container_command=["python", "-m", "hex_llm.server.api_server"],
    serving_container_args=hexllm_args,
    serving_container_ports=[7080],
    serving_container_predict_route="/generate",
    serving_container_health_route="/ping",
    serving_container_environment_variables=env_vars,
    serving_container_shared_memory_size_mb=(16 * 1024),  # 16 GB
    serving_container_deployment_timeout=7200,
    location=TPU_DEPLOYMENT_REGION,
)

model.deploy(
    endpoint=endpoint,
    machine_type=machine_type,
    deploy_request_timeout=1800,
    service_account=service_account,
    min_replica_count=min_replica_count,
    max_replica_count=max_replica_count,
)

הארגומנט --disagg_topo מקבל מחרוזת בפורמט "number_of_prefill_workers,number_of_decode_workers". בדוגמה הקודמת, הערך מוגדר כ-"3,1" כדי להגדיר שלושה עובדים למילוי מראש ועובד אחד לפענוח. כל עובד משתמש בשתי ליבות TPU v5e.

שמירה במטמון של קידומות

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

כדי להפעיל את התכונה הזו, צריך להגדיר את --enable_prefix_cache_hbm בארגומנטים של מאגר Hex-LLM. בדוגמה הבאה אפשר לראות איך פורסים את קונטיינר Hex-LLM ב-TPU v5e-8 שמשרת את מודל Llama 3.1 8B bfloat16:

hexllm_args = [
    "--host=0.0.0.0",
    "--port=7080",
    "--model=meta-llama/Llama-3.1-8B",
    "--data_parallel_size=1",
    "--tensor_parallel_size=4",
    "--hbm_utilization_factor=0.9",
    "--enable_prefix_cache_hbm",
]

model = aiplatform.Model.upload(
    display_name=model_name,
    serving_container_image_uri=HEXLLM_DOCKER_URI,
    serving_container_command=["python", "-m", "hex_llm.server.api_server"],
    serving_container_args=hexllm_args,
    serving_container_ports=[7080],
    serving_container_predict_route="/generate",
    serving_container_health_route="/ping",
    serving_container_environment_variables=env_vars,
    serving_container_shared_memory_size_mb=(16 * 1024),  # 16 GB
    serving_container_deployment_timeout=7200,
    location=TPU_DEPLOYMENT_REGION,
)

model.deploy(
    endpoint=endpoint,
    machine_type=machine_type,
    deploy_request_timeout=1800,
    service_account=service_account,
    min_replica_count=min_replica_count,
    max_replica_count=max_replica_count,
)

‫Hex-LLM משתמשת באחסון במטמון של קידומות כדי לבצע אופטימיזציה של הביצועים להנחיות שאורכן חורג מאורך מסוים (512 טוקנים כברירת מחדל, אפשר להגדיר את האורך באמצעות prefill_len_padding). פגיעות במטמון מתרחשות במרווחים של הערך הזה, וכך מובטח שמספר הטוקנים במטמון תמיד יהיה כפולה של prefill_len_padding. השדה cached_tokens של usage.prompt_tokens_details בתגובת ה-API של השלמת הצ'אט מציין כמה מהטוקנים של ההנחיה היו פגיעה במטמון.

"usage": {
  "prompt_tokens": 643,
  "total_tokens": 743,
  "completion_tokens": 100,
  "prompt_tokens_details": {
    "cached_tokens": 512
  }
}

מילוי מראש של נתונים בחלקים

מילוי מראש של נתונים במנות מחלק את המילוי מראש של הבקשה למנות קטנות יותר, ומשלב את המילוי מראש עם הפענוח בשלב אחד של אצווה. ב-Hex-LLM מיושם מילוי מראש של נתונים במנות כדי לאזן בין הזמן עד לטוקן הראשון (TTFT) לבין הזמן לכל טוקן פלט (TPOT), וכדי לשפר את קצב העברת הנתונים.

כדי להפעיל את התכונה הזו, צריך להגדיר את --enable_chunked_prefill בארגומנטים של מאגר Hex-LLM. בדוגמה הבאה מוצג אופן הפריסה של קונטיינר Hex-LLM ב-TPU v5e-8 שמפעיל את מודל Llama 3.1 8B:

hexllm_args = [
    "--host=0.0.0.0",
    "--port=7080",
    "--model=meta-llama/Llama-3.1-8B",
    "--data_parallel_size=1",
    "--tensor_parallel_size=4",
    "--hbm_utilization_factor=0.9",
    "--enable_chunked_prefill",
]

model = aiplatform.Model.upload(
    display_name=model_name,
    serving_container_image_uri=HEXLLM_DOCKER_URI,
    serving_container_command=["python", "-m", "hex_llm.server.api_server"],
    serving_container_args=hexllm_args,
    serving_container_ports=[7080],
    serving_container_predict_route="/generate",
    serving_container_health_route="/ping",
    serving_container_environment_variables=env_vars,
    serving_container_shared_memory_size_mb=(16 * 1024),  # 16 GB
    serving_container_deployment_timeout=7200,
    location=TPU_DEPLOYMENT_REGION,
)

model.deploy(
    endpoint=endpoint,
    machine_type=machine_type,
    deploy_request_timeout=1800,
    service_account=service_account,
    min_replica_count=min_replica_count,
    max_replica_count=max_replica_count,
)

תמיכה בקוונטיזציה של 4 ביט

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

‫Hex-LLM תומך בכימות INT8 של משקלים בלבד. התמיכה המורחבת כוללת מודלים עם משקלים מסוג INT4 שעברו כימות באמצעות כימות נקודת אפס של AWQ. ‫ Hex-LLM תומך בגרסאות INT4 של משפחות המודלים Mistral, ‏ Mixtral ו-Llama.

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

תחילת העבודה ב-Model Garden

קונטיינר ההצגה של Hex-LLM Cloud TPU משולב ב-Model Garden. אפשר לגשת לטכנולוגיית ההצגה הזו דרך סביבת הניסויים, פריסה בלחיצה אחת ודוגמאות של מחברות Colab Enterprise למגוון מודלים.

שימוש במגרש משחקים

‫Model Garden playground הוא נקודת קצה (endpoint) של Agent Platform שנפרסה מראש ואפשר להגיע אליה על ידי שליחת בקשות בכרטיס המודל.

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

רוצים לנסות את Gemma?

שימוש בפריסה בלחיצה אחת

אפשר לפרוס נקודת קצה של Agent Platform בהתאמה אישית באמצעות Hex-LLM באמצעות כרטיס מודל.

מנווטים אל דף כרטיס המודל ולוחצים על Deploy (פריסה).
בוחרים את סוג המכונה Cloud TPU v5e לפריסה של וריאציית המודל שרוצים להשתמש בה.
כדי להתחיל בתהליך הפריסה, לוחצים על Deploy (פריסה) בתחתית. תקבלו שני אימיילים עם התראות: אחד כשהמודל יועלה ואחד כשהנקודה הסופית תהיה מוכנה.

שימוש ב-notebook של Colab Enterprise

כדי ליהנות מגמישות ומאפשרויות התאמה אישית, אתם יכולים להשתמש בדוגמאות של מחברות Colab Enterprise כדי לפרוס נקודת קצה של Agent Platform עם Hex-LLM באמצעות Agent Platform SDK ל-Python.

עוברים לדף של כרטיס המודל ולוחצים על פתיחת מחברת.
בוחרים את מסמך ה-notebook של Vertex Serving. מסמך ה-notebook ייפתח ב-Colab Enterprise.
מריצים את ה-notebook כדי לפרוס מודל באמצעות Hex-LLM ושולחים בקשות לחיזוי לנקודת הקצה. קטע הקוד של הפריסה הוא:

hexllm_args = [
    f"--model=google/gemma-2-9b-it",
    f"--tensor_parallel_size=4",
    f"--hbm_utilization_factor=0.8",
    f"--max_running_seqs=512",
]
hexllm_envs = {
    "PJRT_DEVICE": "TPU",
    "MODEL_ID": "google/gemma-2-9b-it",
    "DEPLOY_SOURCE": "notebook",
}
model = aiplatform.Model.upload(
    display_name="gemma-2-9b-it",
    serving_container_image_uri=HEXLLM_DOCKER_URI,
    serving_container_command=[
        "python", "-m", "hex_llm.server.api_server"
    ],
    serving_container_args=hexllm_args,
    serving_container_ports=[7080],
    serving_container_predict_route="/generate",
    serving_container_health_route="/ping",
    serving_container_environment_variables=hexllm_envs,
    serving_container_shared_memory_size_mb=(16 * 1024),
    serving_container_deployment_timeout=7200,
)

endpoint = aiplatform.Endpoint.create(display_name="gemma-2-9b-it-endpoint")
model.deploy(
    endpoint=endpoint,
    machine_type="ct5lp-hightpu-4t",
    deploy_request_timeout=1800,
    service_account="<your-service-account>",
    min_replica_count=1,
    max_replica_count=1,
)

דוגמאות לקובצי notebook של Colab Enterprise:

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

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

מודל

‫--model: המודל לטעינה. אפשר לציין מזהה של מודל Hugging Face, נתיב לקטגוריה של Cloud Storage‏ (gs://my-bucket/my-model) או נתיב מקומי. הארטיפקטים של המודל צריכים להיות בפורמט של Hugging Face ולהשתמש בקובצי safetensors למשקלי המודל. יש תמיכה בארטיפקטים של מודלים שעברו קוונטיזציה של BitsAndBytes int8 ו-AWQ ב-Llama, ‏ Gemma 2 ו-Mistral/Mixtral.
‫--tokenizer: הטוקנייזר לטעינה. יכול להיות שזה מזהה של מודל Hugging Face, נתיב של קטגוריה ב-Cloud Storage (gs://my-bucket/my-model) או נתיב מקומי. אם הארגומנט הזה לא מוגדר, ברירת המחדל היא הערך של --model.
--tokenizer_mode: מצב הטוקנייזר. האפשרויות הן ["auto", "slow"]. ערך ברירת המחדל הוא "auto". אם ההגדרה היא "auto", נעשה שימוש בטוקנייזר המהיר, אם הוא זמין. הטוקנייזרים האיטיים כתובים ב-Python ומסופקים בספריית Transformers, ואילו הטוקנייזרים המהירים כתובים ב-Rust ומסופקים בספריית Tokenizers. מידע נוסף זמין במאמרי העזרה של Hugging Face.
‫--trust_remote_code: האם לאפשר קבצי קוד מרחוק שמוגדרים במאגרי המודלים של Hugging Face. ערך ברירת המחדל הוא False.
‫--load_format: פורמט של נקודות ביקורת של המודל לטעינה. האפשרויות הן ["auto", "dummy"]. ערך ברירת המחדל הוא "auto". אם הערך הוא "auto", המשקלים של המודל נטענים בפורמט safetensors. אם הערך הוא "dummy", המשקלים של המודל מאותחלים באופן אקראי. הגדרה של "dummy" שימושית לניסויים.
‫--max_model_len: אורך ההקשר המקסימלי (אורך הקלט פלוס אורך הפלט) שהמודל יכול לשרת. ערך ברירת המחדל נקרא מקובץ הגדרות המודל בפורמט Hugging Face: ‏ config.json. אורך הקשר מקסימלי גדול יותר דורש יותר זיכרון TPU.
‫--sliding_window: אם מציינים את הארגומנט הזה, הוא מבטל את גודל החלון של המודל עבור מנגנון תשומת הלב של חלון נע. אם מגדירים את הארגומנט הזה לערך גדול יותר, מנגנון תשומת הלב כולל יותר טוקנים ומתקרב להשפעה של מנגנון תשומת לב עצמית רגיל. הארגומנט הזה מיועד לשימוש ניסיוני בלבד. בתרחישי שימוש כלליים, מומלץ להשתמש בגודל החלון המקורי של המודל.
‫--seed: ערך ה-seed לאתחול של כל מחוללי המספרים האקראיים. שינוי הארגומנט הזה עשוי להשפיע על הפלט שנוצר לאותה הנחיה, באמצעות שינוי הטוקנים שנדגמים כטוקנים הבאים. ערך ברירת המחדל הוא 0.

מנוע הסקת מסקנות

‫--num_hosts: מספר המארחים להרצה. ערך ברירת המחדל הוא 1. פרטים נוספים זמינים במאמר בנושא הגדרת TPU v5e.
‫--disagg_topo: הגדרה של מספר העובדים למילוי מראש ומספר העובדים לפענוח באמצעות התכונה הניסיונית 'הצגת מודעות מפורקות'. ערך ברירת המחדל הוא None. הארגומנט צריך להיות בפורמט: "number_of_prefill_workers,number_of_decode_workers".
--data_parallel_size: מספר העותקים המשוכפלים של נתונים מקבילים. ערך ברירת המחדל הוא 1. הגדרה של הערך הזה ל-N במקום 1 משפרת את קצב העברת הנתונים בערך ב-N, בלי להשפיע על זמן האחזור.
‫--tensor_parallel_size: מספר העותקים המשוכפלים של טנסור מקבילי. ערך ברירת המחדל הוא 1. הגדלת מספר העותקים המקבילים של טנסור בדרך כלל משפרת את זמן האחזור, כי היא מאיצה את הכפלת המטריצה על ידי הקטנת הגודל שלה.
‫--worker_distributed_method: השיטה המבוזרת להפעלת העובד. משתמשים ב-mp עבור המודול multiprocessing או ב-ray עבור הספרייה Ray. ערך ברירת המחדל הוא mp.
‫--enable_jit: האם להפעיל את מצב JIT (הידור בזמן אמת). ערך ברירת המחדל הוא True. ההגדרה --no-enable_jit משביתה את התכונה. הפעלת מצב JIT משפרת את ביצועי ההסקה, אבל היא דורשת יותר זמן לקימפול הראשוני. באופן כללי, היתרונות של ביצועי ההסקה עולים על התקורה.
‫--warmup: האם להפעיל את השרת עם בקשות לדוגמה במהלך ההפעלה. ערך ברירת המחדל הוא True. הגדרה של --no-warmup משביתה את האפשרות. מומלץ לבצע חימום, כי בקשות ראשוניות מפעילות קומפילציה כבדה יותר ולכן הן יהיו איטיות יותר.
‫--max_prefill_seqs: המספר המקסימלי של רצפים שאפשר לתזמן למילוי מראש בכל איטרציה. ערך ברירת המחדל הוא 1. ככל שהערך הזה גדול יותר, כך השרת יכול להשיג תפוקה גבוהה יותר, אבל עם השפעות שליליות פוטנציאליות על זמן האחזור.
‫--prefill_seqs_padding: השרת מוסיף ריפוד לגודל אצווה למילוי מראש כך שיהיה כפולה של הערך הזה. ערך ברירת המחדל הוא 8. הגדלת הערך הזה מקצרת את הזמן של הידור מחדש של המודל, אבל מגדילה את כמות החישובים המיותרים ואת התקורה של ההסקה. ההגדרה האופטימלית תלויה בתנועת הבקשות.
‫--prefill_len_padding: השרת מוסיף ריפוד לאורך הרצף כך שיהיה כפולה של הערך הזה. ערך ברירת המחדל הוא 512. הגדלת הערך הזה מקצרת את הזמן שלוקח לקומפילציה מחדש של המודל, אבל מגדילה את העומס של חישובים מיותרים והסקת מסקנות. ההגדרה האופטימלית תלויה בפיזור הנתונים של הבקשות.
‫--max_decode_seqs/--max_running_seqs: המספר המקסימלי של רצפים שאפשר לתזמן לפענוח בכל איטרציה. ערך ברירת המחדל הוא 256. ככל שהערך הזה גבוה יותר, כך השרת יכול להשיג תפוקה גבוהה יותר, אבל יכולות להיות לכך השפעות שליליות על זמן האחזור.
‫--decode_seqs_padding: השרת מוסיף ריפוד לגודל אצווה של הפענוח כך שיהיה כפולה של הערך הזה. ערך ברירת המחדל הוא 8. הגדלת הערך הזה מקצרת את הזמן של הידור מחדש של המודל, אבל מגדילה את החישוב המבוזבז ואת התקורה של ההסקה. ההגדרה האופטימלית תלויה בתנועת הבקשות.
‫--decode_blocks_padding: השרת מוסיף ריפוד למספר בלוקי הזיכרון שמשמשים למטמון של צמד מפתח/ערך (KV) של רצף, כך שיהיה כפולה של הערך הזה במהלך הפענוח. ערך ברירת המחדל הוא 128. הגדלת הערך הזה מקצרת את הזמן שלוקח לקומפילציה מחדש של המודל, אבל מגדילה את העומס של חישובים מיותרים והסקת מסקנות. ההגדרה האופטימלית תלויה בפיזור הנתונים של הבקשות.
‫--enable_prefix_cache_hbm: האם להפעיל שמירת מטמון של קידומות ב-HBM. ערך ברירת המחדל הוא False. הגדרת הארגומנט הזה יכולה לשפר את הביצועים על ידי שימוש חוזר בחישובים של קידומות משותפות של בקשות קודמות.
‫--enable_chunked_prefill: קובע אם להפעיל מילוי מראש של נתונים בחלקים. ערך ברירת המחדל הוא False. הגדרת הארגומנט הזה יכולה לתמוך בחלון ההקשר הארוך יותר ולשפר את הביצועים.

ניהול הזיכרון

‫--hbm_utilization_factor: אחוז הזיכרון של Cloud TPU High Bandwidth Memory‏ (HBM) הפנוי שאפשר להקצות למטמון KV אחרי טעינת משקלי המודל. ערך ברירת המחדל הוא 0.9. הגדרת ערך גבוה יותר לארגומנט הזה מגדילה את גודל מטמון ה-KV ויכולה לשפר את קצב העברת הנתונים, אבל היא מגדילה את הסיכון לאזילת הזיכרון של Cloud TPU HBM במהלך האתחול ובזמן הריצה.
‫--num_blocks: מספר חסימות המכשיר להקצאה למטמון KV. אם הארגומנט הזה מוגדר, השרת מתעלם מ---hbm_utilization_factor. אם הארגומנט הזה לא מוגדר, פרופילי השרת משתמשים ב-HBM ומחשבים את מספר בלוקי המכשירים להקצאה על סמך --hbm_utilization_factor. הגדרת הארגומנט הזה לערך גבוה יותר מגדילה את גודל המטמון של KV ויכולה לשפר את קצב העברת הנתונים, אבל היא מגדילה את הסיכון לחוסר ב-HBM של Cloud TPU במהלך האתחול ובזמן הריצה.
‫--block_size: מספר הטוקנים שמאוחסנים בבלוק. האפשרויות הן [8, 16, 32, 2048, 8192]. ערך ברירת המחדל הוא 32. הגדרה של הארגומנט הזה לערך גדול יותר מצמצמת את התקורה בניהול הבלוקים, אבל גורמת לבזבוז יותר זיכרון. כדי לקבוע את ההשפעה המדויקת על הביצועים, צריך לבצע בדיקה אמפירית.

Dynamic LoRA

‫--enable_lora: קובע אם להפעיל טעינה דינמית של מתאמי LoRA מ-Cloud Storage. ערך ברירת המחדל הוא False. האפשרות הזו נתמכת במשפחת מודלים Llama.
‫--max_lora_rank: הדירוג המקסימלי של LoRA שנתמך במתאמי LoRA שמוגדרים בבקשות. ערך ברירת המחדל הוא 16. הגדרת הארגומנט הזה לערך גבוה יותר מאפשרת גמישות רבה יותר במתאמי LoRA שאפשר להשתמש בהם עם השרת, אבל מגדילה את כמות ה-HBM של Cloud TPU שהוקצתה למשקלי LoRA ומקטינה את התפוקה.
‫--enable_lora_cache: האם להפעיל שמירה במטמון של מתאמי LoRA דינמיים. ערך ברירת המחדל הוא True. ההגדרה --no-enable_lora_cache משביתה את התכונה. השמירה במטמון משפרת את הביצועים כי היא מבטלת את הצורך להוריד מחדש קבצים של מתאמי LoRA שהיו בשימוש בעבר.
‫--max_num_mem_cached_lora: המספר המקסימלי של מתאמי LoRA שמאוחסנים במטמון של זיכרון TPU.ערך ברירת המחדל הוא 16. הגדרת הארגומנט הזה לערך גדול יותר מגדילה את הסיכוי לפגיעה במטמון, אבל היא מגדילה את כמות השימוש ב-HBM של Cloud TPU.

אפשר גם להגדיר את השרת באמצעות משתני הסביבה הבאים:

HEX_LLM_LOG_LEVEL: קובע את כמות המידע שיירשם ביומן. ערך ברירת המחדל הוא INFO. מגדירים את הערך הזה לאחת מרמות הרישום ביומן הרגילות של Python שמוגדרות במודול הרישום ביומן.
‫HEX_LLM_VERBOSE_LOG: האם להפעיל פלט מפורט של רישום ביומן. הערכים המותרים הם true או false. ערך ברירת המחדל הוא false.

שינוי ארגומנטים של השרת

הארגומנטים של השרת קשורים זה לזה ויש להם השפעה משותפת על ביצועי ההצגה. לדוגמה, הגדרה גדולה יותר של --max_model_len=4096 מובילה לשימוש רב יותר בזיכרון TPU, ולכן נדרשת הקצאת זיכרון גדולה יותר ופחות אצווה. בנוסף, חלק מהארגומנטים נקבעים לפי מקרה השימוש, ואחרים ניתנים להתאמה. זהו תהליך עבודה להגדרת שרת Hex-LLM.

קובעים את משפחת המודלים ואת וריאציית המודל שמעניינים אתכם. לדוגמה, Llama 3.1 8B Instruct.
הערכת הגבול התחתון של זיכרון ה-TPU שנדרש על סמך גודל המודל והדיוק: model_size * (num_bits / 8). עבור מודל של 8B ודיוק bfloat16, הגבול התחתון של זיכרון ה-TPU שנדרש יהיה 8 * (16 / 8) = 16 GB.
תנו הערכה למספר שבבי TPU v5e שצריך, כשכל שבב v5e מציע 16GB: tpu_memory / 16. כדי להשתמש במודל 8B ובדיוק bfloat16, צריך יותר משבב אחד. בין ההגדרות של צ'יפ אחד, 4 צ'יפים ו-8 צ'יפים, ההגדרה הקטנה ביותר שמציעה יותר מצ'יפ אחד היא ההגדרה של 4 צ'יפים: ct5lp-hightpu-4t. אפשר להגדיר את --tensor_parallel_size=4 בהמשך.
קובעים את אורך חלון ההקשר המקסימלי (אורך הקלט + אורך הפלט) לתרחיש השימוש הרצוי. לדוגמה, 4096. לאחר מכן אפשר להגדיר את --max_model_len=4096.
מכווננים את כמות הזיכרון הפנוי של TPU שהוקצה למטמון KV למקסימום האפשרי בהתחשב במודל, בחומרה ובהגדרות השרת (--hbm_utilization_factor). מתחילים עם 0.95. פורסים את שרת Hex-LLM ובודקים את השרת באמצעות הנחיות ארוכות וריבוי משימות בו-זמנית. אם השרת לא מצליח להקצות זיכרון, צריך להקטין את מקדם הניצול בהתאם.

קבוצת ארגומנטים לדוגמה לפריסת Llama 3.1 8B Instruct:

python -m hex_llm.server.api_server \
    --model=meta-llama/Llama-3.1-8B-Instruct \
    --tensor_parallel_size=4 \
    --max_model_len=4096
    --hbm_utilization_factor=0.95

דוגמה לארגומנטים לפריסת Llama 3.1 70B Instruct AWQ ב-ct5lp-hightpu-4t:

python -m hex_llm.server.api_server \
    --model=hugging-quants/Meta-Llama-3.1-70B-Instruct-AWQ-INT4 \
    --tensor_parallel_size=4 \
    --max_model_len=4096
    --hbm_utilization_factor=0.45

בקשה למכסת Cloud TPU

ב-Model Garden, מכסת ברירת המחדל היא 32 שבבי Cloud TPU v5e באזור us-west1. המכסות האלה חלות על פריסות בלחיצה אחת ועל פריסות של מחברות Colab Enterprise. במאמר איך שולחים בקשה לשינוי המכסות מוסבר איך לבקש להגדיל את ערך המכסה.