‫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. מודל Hex-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 zero-point. ‫Hex-LLM תומך בגרסאות INT4 של משפחות המודלים Mistral, ‏ Mixtral ו-Llama.

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

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

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

שימוש ב-Playground

‫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.

עוברים לדף של כרטיס המודל ולוחצים על פתיחת מחברת.
בוחרים את מחברת Vertex Serving. המחברת נפתחת ב-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. אתם יכולים להתאים את הארגומנטים כך שיתאימו בצורה הטובה ביותר לתרחיש השימוש ולדרישות שלכם. שימו לב שהארגומנטים מוגדרים מראש לפריסה בלחיצה אחת, כדי לאפשר את חוויית הפריסה הקלה ביותר. כדי להתאים אישית את הארגומנטים, אפשר להשתמש בדוגמאות של מחברות כהפניה ולהגדיר את הארגומנטים בהתאם.

מודל

‫--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: אם הארגומנט הזה מוגדר, הוא מבטל את גודל החלון של המודל עבור sliding window attention. הגדרת הארגומנט הזה לערך גדול יותר גורמת למנגנון תשומת הלב לכלול יותר טוקנים, וההשפעה שלו דומה להשפעה של מנגנון תשומת לב עצמית רגיל. הארגומנט הזה מיועד לשימוש ניסיוני בלבד. במקרים כלליים, מומלץ להשתמש בגודל החלון המקורי של המודל.
‫--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: האם להפעיל prefix caching ב-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. במאמר איך שולחים בקשה לשינוי המכסות מוסבר איך לבקש להגדיל את ערך המכסה.