Diese Seite wurde von der Cloud Translation API übersetzt.

Offene Modelle mit Hex-LLM-Premium-Container in Cloud TPU bereitstellen

Hex-LLM, eine hocheffizientes LLM-Bereitstellung (Large Language Model) mit XLA, ist das Vertex AI LLM-Bereitstellungs-Framework, das für Cloud TPU-Hardware entwickelt und optimiert wurde. Hex-LLM kombiniert LLM-Bereitstellungstechnologien wie die kontinuierliche Batchverarbeitung und PagedAttention mit Vertex AI-Optimierungen, die auf XLA und Cloud TPU zugeschnitten sind. Dies ist eine hocheffiziente und kostengünstige LLM-Bereitstellungsoption für Cloud TPUs für Open-Source-Modellen.

Hex-LLM ist in Model Garden per Modell-Playground, Bereitstellung mit einem Klick und Notebook verfügbar.

Features

Hex-LLM basiert auf Open-Source-Projekten mit Googles eigenen Optimierungen für XLA und Cloud TPU. Hex-LLM erreicht bei der Bereitstellung häufig verwendeter LLMs einen hohen Durchsatz und eine niedrige Latenz.

Hex-LLM umfasst die folgenden Optimierungen:

Tokenbasierter Algorithmus für kontinuierliches Batching, um sicherzustellen, dass Modelle die Hardware bei einer großen Anzahl gleichzeitiger Anfragen optimal nutzen.
Eine vollständige Neuschreibung der Aufmerksamkeitskerne, die für XLA optimiert sind.
Flexible und zusammensetzbare Strategien für Datenparallelität und Tensor-Parallelität die hochoptimierte Methoden zur Gewichtungsfragmentierung nutzen, um LLMs effizient auf mehreren Cloud TPU-Chips auszuführen.

Hex-LLM unterstützt eine breite Palette von dichten und spärlichen LLMs:

Gemma 2B und 7B
Gemma 2 9B und 27B
Llama 2 7B, 13B und 70B
Llama 3 8B und 70B
Llama 3.1 8B und 70B
Llama 3.2 1B und 3B
Llama Guard 3 1B und 8B
Mistral 7B
Mixtral 8x7B und 8x22B
Phi-3 mini und medium
Qwen2 0,5 B, 1,5 B und 7 B
Qwen2.5 0,5 Mrd., 1,5 Mrd., 7 Mrd., 14 Mrd. und 32 Mrd. AWQ

Hex-LLM bietet außerdem eine Vielzahl von Features, z. B.:

Hex-LLM ist in einem einzelnen Container enthalten. Hex-LLM verpackt den API-Server, die Inferenz-Engine und die unterstützten Modelle in einem einzigen, bereitzustellenden Docker-Image.
Kompatibel mit dem Format für Hugging Face-Modelle. Hex-LLM kann ein Hugging Face-Modell von einem lokalen Laufwerk, dem Hugging Face Hub oder einem Cloud Storage-Bucket laden.
Quantisierung mit bitsandbytes und AWQ
Dynamisches LoRA-Laden. Hex-LLM kann die LoRA-Gewichte laden, indem das Anfrageargument während der Bereitstellung gelesen wird.

Erweiterte Features

Hex-LLM unterstützt die folgenden erweiterten Funktionen:

Bereitstellung über mehrere Hosts
Aufschlüsselte Auslieferung [experimentell]
Präfix-Caching
Unterstützung für 4-Bit-Quantisierung

Bereitstellung über mehrere Hosts

Hex-LLM unterstützt jetzt die Bereitstellung von Modellen mit einem TPU-Slice mit mehreren Hosts. Mit dieser Funktion können Sie große Modelle bereitstellen, die nicht in eine einzelne Host-TPU-VM geladen werden können, die maximal acht v5e-Kerne enthält.

Wenn Sie diese Funktion aktivieren möchten, legen Sie --num_hosts in den Hex-LLM-Containerargumenten und --tpu_topology in der Vertex AI SDK-Modelluploadanfrage fest. Das folgende Beispiel zeigt, wie Sie den Hex-LLM-Container mit einer TPU 4x4 v5e-Topologie bereitstellen, die das Llama 3.1 70B-bfloat16-Modell ausliefert:

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,
)

Eine End-to-End-Anleitung zum Bereitstellen des Hex-LLM-Containers mit einer TPU-Topologie mit mehreren Hosts finden Sie im Vertex AI Model Garden – Llama 3.1 (Deployment) Notebook.

Im Allgemeinen sind nur die folgenden Änderungen erforderlich, um die Auslieferung an mehrere Hosts zu aktivieren:

Legen Sie das Argument --tensor_parallel_size auf die Gesamtzahl der Kerne in der TPU-Topologie fest.
Legen Sie für das Argument --num_hosts die Anzahl der Hosts in der TPU-Topologie fest.
Legen Sie --tpu_topology mit der Vertex AI SDK-Modellupload-API fest.

Aufschlüsselte Auslieferung [experimentell]

Hex-LLM unterstützt jetzt die deaggregierte Auslieferung als experimentelle Funktion. Sie kann nur bei der Einrichtung mit einem einzelnen Host aktiviert werden und die Leistung wird derzeit optimiert.

Die deaggregierte Auslieferung ist eine effektive Methode, um die Zeit bis zum ersten Token (TTFT) und die Zeit pro Ausgabetoken (TPOT) für jede Anfrage sowie den Gesamtdurchsatz der Auslieferung auszugleichen. Dabei werden die Prefill-Phase und die Dekodierungsphase in verschiedene Arbeitslasten unterteilt, damit sie sich nicht gegenseitig behindern. Diese Methode ist besonders nützlich für Szenarien mit strengen Latenzvoraussetzungen.

Wenn Sie diese Funktion aktivieren möchten, geben Sie --disagg_topo in den Hex-LLM-Containerargumenten an. Im folgenden Beispiel wird gezeigt, wie der Hex-LLM-Container auf einer TPU v5e-8 bereitgestellt wird, die das Llama 3.1-Modell mit 8 B bfloat16 ausliefert:

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,
)

Das Argument --disagg_topo akzeptiert einen String im Format "number_of_prefill_workers,number_of_decode_workers". Im vorherigen Beispiel ist es auf "3,1" festgelegt, um drei Prefill-Worker und einen Dekodierungs-Worker zu konfigurieren. Jeder Worker verwendet zwei TPU v5e-Kerne.

Präfix-Caching

Durch das Präfix-Caching wird die Zeit bis zum ersten Token (TTFT) für Prompts reduziert, die zu Beginn identische Inhalte haben, z. B. unternehmensweite Präambeln, gängige Systemanweisungen und Konversationsverläufe mit mehreren Zügen. Anstatt dieselben Eingabetokens wiederholt zu verarbeiten, kann Hex-LLM einen temporären Cache der verarbeiteten Eingabetoken-Berechnungen beibehalten, um die TTFT zu verbessern.

Wenn Sie diese Funktion aktivieren möchten, legen Sie in den Hex-LLM-Containerargumenten --enable_prefix_cache_hbm fest. Im folgenden Beispiel wird gezeigt, wie der Hex-LLM-Container auf einer TPU v5e-8 bereitgestellt wird, die das Llama 3.1-Modell mit 8 B bfloat16 ausliefert:

hexllm_args = [
    "--host=0.0.0.0",
    "--port=7080",
    "--model=meta-llama/Llama-3.1-8B",
    "--data_parallel_size=1",
    "--tensor_parallel_size=2",
    "--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 verwendet das Präfix-Caching, um die Leistung für Prompts zu optimieren, die eine bestimmte Länge überschreiten (standardmäßig 512 Token, konfigurierbar mit prefill_len_padding). Cachetreffer erfolgen in Schritten dieses Werts, sodass die Anzahl der im Cache gespeicherten Tokens immer ein Vielfaches von prefill_len_padding ist. Das Feld cached_tokens von usage.prompt_tokens_details in der API-Antwort für die Chat-Ergänzung gibt an, wie viele der Prompt-Tokens einen Cache-Treffer waren.

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

Unterstützung für 4-Bit-Quantisierung

Die Quantisierung ist ein Verfahren, mit dem die Rechen- und Speicherkosten für die Ausführung von Inferenzen reduziert werden, indem die Gewichte oder Aktivierungen mit Datentypen mit niedriger Genauigkeit wie INT8 oder INT4 anstelle der üblichen BF16 oder FP32 dargestellt werden.

Hex-LLM unterstützt die Quantisierung nur mit INT8-Gewichten. Der erweiterte Support umfasst Modelle mit INT4-Gewichten, die mit der AWQ-Nullpunktquantisierung quantisiert wurden. Hex-LLM unterstützt INT4-Varianten der Modellfamilien Mistral, Mixtral und Llama.

Für das Bereitstellen quantisierter Modelle ist kein zusätzliches Flag erforderlich.

Erste Schritte mit Model Garden

Der Hex-LLM-Cloud TPU-Bereitstellungscontainer ist in Model Garden integriert. Sie können auf diese Bereitstellungstechnologie über die Playground-, die Ein-Klick-Bereitstellung und die Colab Enterprise-Notebook-Beispiele für eine Vielzahl von Modellen zugreifen.

Playground verwenden

Model Garden Playground ist ein vorab bereitgestellter Vertex AI-Endpunkt, der durch das Senden von Anfragen auf der Modellkarte erreichbar ist.

Geben Sie einen Prompt ein und fügen Sie optional Argumente für Ihre Anfrage hinzu.
Klicken Sie auf SENDEN, um schnell eine Antwort vom Modell zu erhalten.

Probieren Sie es mit Gemma aus.

Bereitstellung mit nur einem Klick verwenden

Sie können einen benutzerdefinierten Vertex AI-Endpunkt mit Hex-LLM mithilfe einer Modellkarte bereitstellen.

Rufen Sie die Seite „Modellkarte“ auf und klicken Sie auf Bereitstellen.
Wählen Sie für die zu verwendende Modellvariante den Cloud TPU v5e-Maschinentyp zur Bereitstellung aus.
Klicken Sie unten auf Bereitstellen, um den Bereitstellungsprozess zu starten. Sie erhalten zwei E-Mail-Benachrichtigungen: eine, wenn das Modell hochgeladen wird, und eine weitere, wenn der Endpunkt bereit ist.

Colab Enterprise-Notebook verwenden

Für mehr Flexibilität und Anpassungsmöglichkeiten können Sie Colab Enterprise-Notebook-Beispiele verwenden, um einen Vertex AI-Endpunkt mit Hex-LLM mithilfe des Vertex AI SDK für Python bereitzustellen.

Rufen Sie die Seite „Modellkarte“ auf und klicken Sie auf Notebook öffnen.
Wählen Sie das Vertex Serving-Notebook aus. Das Notebook wird in Colab Enterprise geladen.
Führen Sie das Notebook aus, um ein Modell mit Hex-LLM bereitzustellen und Vorhersageanfragen an den Endpunkt zu senden. Das Code-Snippet für die Bereitstellung sieht so aus:

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,
)

Beispiele für Colab Enterprise-Notebooks:

Serverargumente und Umgebungsvariablen konfigurieren

Sie können die folgenden Argumente festlegen, um den Hex-LLM-Server zu starten. Sie können die Argumente an Ihren beabsichtigten Anwendungsfall und Ihre Anforderungen anpassen. Die Argumente sind für die Bereitstellung mit nur einem Klick vordefiniert, um die Bereitstellung so einfach wie möglich zu gestalten. Wenn Sie die Argumente anpassen möchten, können Sie die Notebook-Beispiele als Referenz verwenden und die Argumente entsprechend festlegen.

Modell

--model: Das zu ladende Modell. Sie können eine Hugging Face-Modell-ID, einen Cloud Storage-Bucket-Pfad (gs://my-bucket/my-model) oder einen lokalen Pfad angeben. Die Modellartefakte müssen dem Hugging Face-Format entsprechen und SafeTensors-Dateien für die Modellgewichte verwenden. Quantisierte Modellartefakte von BitsAndBytes mit int8 und AWQ werden für Llama, Gemma 2 und Mistral/Mixtral unterstützt.
--tokenizer: Der zu ladende Tokenizer. Dies kann eine Hugging Face-Modell-ID, ein Cloud Storage-Bucket-Pfad (gs://my-bucket/my-model) oder ein lokaler Pfad sein. Wenn dieses Argument nicht festgelegt ist, wird standardmäßig der Wert für --model verwendet.
--tokenizer_mode: Der Tokenizer-Modus. Mögliche Optionen sind ["auto", "slow"]. Der Standardwert ist "auto". Wenn diese Option auf "auto" gesetzt ist, wird der schnelle Tokenisierer verwendet, sofern verfügbar. Die langsamen Tokenisierer sind in Python geschrieben und in der Transformers-Bibliothek verfügbar. Die schnellen Tokenisierer, die eine Leistungssteigerung bieten, sind in Rust geschrieben und in der Tokenizers-Bibliothek verfügbar. Weitere Informationen finden Sie in der Hugging Face-Dokumentation.
--trust_remote_code: Gibt an, ob Remote-Codedateien zulässig sind, die in den Hugging Face-Modell-Repositories definiert sind. Der Standardwert ist False.
--load_format: Format der zu ladenden Modell-Checkpunkte. Mögliche Optionen sind ["auto", "dummy"]. Der Standardwert ist "auto". Wenn diese Option auf "auto" festgelegt ist, werden die Modellgewichte im Safetensors-Format geladen. Wenn dieser Wert auf "dummy" festgelegt ist, werden die Modellgewichte zufällig initialisiert. Wenn Sie diesen Wert auf "dummy" festlegen, ist das für Tests nützlich.
--max_model_len: Die maximale Kontextlänge (Eingabelänge plus Ausgabelänge), die für das Modell verwendet werden soll. Der Standardwert wird aus der Modellkonfigurationsdatei im Hugging Face-Format gelesen: config.json. Eine größere maximale Kontextlänge erfordert mehr TPU-Arbeitsspeicher.
--sliding_window: Wenn dieses Argument festgelegt ist, wird die Fenstergröße des Modells für die Aufmerksamkeit mit gleitendem Fenster überschrieben. Wenn Sie für dieses Argument einen höheren Wert festlegen, umfasst der Aufmerksamkeitsmechanismus mehr Tokens und nähert sich der Wirkung der standardmäßigen Aufmerksamkeitssteuerung. Dieses Argument ist nur für experimentelle Zwecke vorgesehen. Für allgemeine Anwendungsfälle empfehlen wir, die ursprüngliche Fenstergröße des Modells zu verwenden.
--seed: Der Startwert für die Initialisierung aller Zufallszahlengeneratoren. Wenn Sie dieses Argument ändern, kann sich das auf die generierte Ausgabe für denselben Prompt auswirken, da sich die Tokens ändern, die als nächstes Token ausgewählt werden. Der Standardwert ist 0.

Inferenzmaschine

--num_hosts: Die Anzahl der Hosts, die ausgeführt werden sollen. Der Standardwert ist 1. Weitere Informationen finden Sie in der Dokumentation zur Konfiguration von TPU v5e.
--disagg_topo: Definiert die Anzahl der Prefill- und Dekodierungs-Worker mit der experimentellen Funktion „Aufschlüsselung der Anzeigenbereitstellung“. Der Standardwert ist None. Das Argument hat folgendes Format: "number_of_prefill_workers,number_of_decode_workers".
--data_parallel_size: Die Anzahl der datenbasiert parallelen Replikate. Der Standardwert ist 1. Wenn Sie diesen Wert von 1 auf N festlegen, wird der Durchsatz bei gleicher Latenz ungefähr um N erhöht.
--tensor_parallel_size: Die Anzahl der tensorparallelen Replikate. Der Standardwert ist 1. Durch eine Erhöhung der Anzahl der tensorparallelen Replikate wird die Latenz in der Regel verbessert, da die Matrixmultiplikation durch Verringerung der Matrixgröße beschleunigt wird.
--worker_distributed_method: Die verteilte Methode zum Starten des Workers. Verwenden Sie mp für das multiprocessing-Modul oder ray für die Ray-Bibliothek. Der Standardwert ist mp
--enable_jit: Gibt an, ob der JIT-Modus (Just-in-Time-Kompilierung) aktiviert werden soll. Der Standardwert ist True. Wenn Sie --no-enable_jit festlegen, wird sie deaktiviert. Wenn Sie den JIT-Modus aktivieren, wird die Inferenzleistung verbessert. Allerdings ist für die anfängliche Kompilierung mehr Zeit erforderlich. Im Allgemeinen überwiegen die Vorteile bei der Inferenzleistung den Overhead.
--warmup: Gibt an, ob der Server während der Initialisierung mit Beispielanfragen vorgewärmt werden soll. Der Standardwert ist True. Wenn Sie --no-warmup festlegen, wird sie deaktiviert. Wir empfehlen das Aufwärmen, da anfängliche Anfragen eine stärkere Kompilierung auslösen und daher langsamer sind.
--max_prefill_seqs: Die maximale Anzahl von Sequenzen, die pro Iteration für das Prefilling geplant werden können. Der Standardwert ist 1. Je höher dieser Wert ist, desto höher ist der Durchsatz, den der Server erreichen kann, allerdings mit möglichen negativen Auswirkungen auf die Latenz.
--prefill_seqs_padding: Der Server rundet die Größe des Prefill-Batches auf ein Vielfaches dieses Werts auf. Der Standardwert ist 8. Wenn Sie diesen Wert erhöhen, verkürzt sich die Zeit für die Neukompilierung des Modells. Allerdings steigt der Zeitaufwand für die Berechnung und Inferenz. Die optimale Einstellung hängt vom Anfragetraffic ab.
--prefill_len_padding: Der Server erhöht die Sequenzlänge auf ein Vielfaches dieses Werts. Der Standardwert ist 512. Wenn Sie diesen Wert erhöhen, verkürzt sich die Zeit für die Modellneukompilierung, aber der Overhead für Berechnungen und Inferenzen steigt. Die optimale Einstellung hängt von der Datenverteilung der Anfragen ab.
--max_decode_seqs/--max_running_seqs: Die maximale Anzahl von Sequenzen, die pro Iteration für die Dekodierung geplant werden können. Der Standardwert ist 256. Je höher dieser Wert ist, desto höher ist der Durchsatz, den der Server erreichen kann, allerdings mit möglichen negativen Auswirkungen auf die Latenz.
--decode_seqs_padding: Der Server erhöht die Größe des Dekodierungs-Batches auf ein Vielfaches dieses Werts. Der Standardwert ist 8. Durch Erhöhen dieses Werts wird die Zeit für die Neukompilierung des Modells verkürzt, aber der ineffiziente Rechenaufwand und der Inferenz-Overhead erhöht. Die optimale Einstellung hängt vom Anfragetraffic ab.
--decode_blocks_padding: Der Server erhöht die Anzahl der Arbeitsspeicherblöcke, die für den Schlüssel/Wert-Cache (KV-Cache) einer Sequenz verwendet werden, während der Dekodierung auf ein Vielfaches dieses Werts. Der Standardwert ist 128. Wenn Sie diesen Wert erhöhen, verkürzt sich die Zeit für die Modellneukompilierung, aber der Overhead für Berechnungen und Inferenzen steigt. Die optimale Einstellung hängt von der Datenverteilung der Anfragen ab.
--enable_prefix_cache_hbm: Gibt an, ob das Präfix-Caching in HBM aktiviert werden soll. Der Standardwert ist False. Wenn Sie dieses Argument festlegen, kann sich die Leistung verbessern, da die Berechnungen für gemeinsame Präfixe früherer Anfragen wiederverwendet werden.

Arbeitsspeicherverwaltung

--hbm_utilization_factor: Der Prozentsatz des freien Cloud TPU High Bandwidth Memory (HBM), der nach dem Laden der Modellgewichte für den KV-Cache zugewiesen werden kann. Der Standardwert ist 0.9. Wenn Sie für dieses Argument einen höheren Wert festlegen, erhöht sich die KV-Cache-Größe und der Durchsatz kann verbessert werden. Das Risiko, dass während der Initialisierung und zur Laufzeit der Cloud TPU-HBM aufgebraucht wird, steigt jedoch.
--num_blocks: Anzahl der Geräteblöcke, die für den KV-Cache zugewiesen werden sollen. Wenn dieses Argument festgelegt ist, ignoriert der Server --hbm_utilization_factor. Wenn dieses Argument nicht festgelegt ist, wird die HBM-Nutzung vom Serverprofil erfasst und die Anzahl der zuzuweisenden Geräteblöcke anhand von --hbm_utilization_factor berechnet. Wenn Sie für dieses Argument einen höheren Wert festlegen, wird die KV-Cache-Größe erhöht und der Durchsatz kann verbessert werden. Das Risiko, dass während der Initialisierung und zur Laufzeit der Cloud TPU-HBM aufgebraucht wird, steigt jedoch.
--block_size: Anzahl der in einem Block gespeicherten Tokens. Mögliche Optionen sind [8, 16, 32, 2048, 8192]. Der Standardwert ist 32. Wenn Sie für dieses Argument einen höheren Wert festlegen, wird der Overhead bei der Blockverwaltung reduziert, was jedoch zu einer höheren Speicherverschwendung führt. Die genaue Leistungsauswirkung muss empirisch ermittelt werden.

Dynamisches LoRA

--enable_lora: Ob das dynamische Laden von LoRA-Adaptern aus Cloud Storage aktiviert werden soll. Der Standardwert ist False. Dies wird für die Llama-Modellfamilie unterstützt.
--max_lora_rank: Der maximale LoRA-Rang, der für LoRA-Adapter unterstützt wird, in Anfragen definiert. Der Standardwert ist 16. Wenn Sie dieses Argument auf einen höheren Wert setzen, können Sie die LoRa-Adapter, die mit dem Server verwendet werden können, flexibler einsetzen. Allerdings wird dadurch der für LoRa-Gewichte zugewiesene Cloud TPU HBM-Speicher erhöht und der Durchsatz verringert.
--enable_lora_cache: Gibt an, ob das Caching dynamischer LoRA-Adapter aktiviert werden soll. Der Standardwert ist True. Wenn Sie --no-enable_lora_cache festlegen, wird sie deaktiviert. Durch das Caching wird die Leistung verbessert, da zuvor verwendete LoRA-Adapterdateien nicht noch einmal heruntergeladen werden müssen.
--max_num_mem_cached_lora: Die maximale Anzahl von LoRA-Adaptern, die im TPU-Speichercache gespeichert werden.Der Standardwert ist 16. Wenn Sie dieses Argument auf einen höheren Wert setzen, erhöht sich die Wahrscheinlichkeit eines Cache-Hits, aber auch die HBM-Nutzung von Cloud TPU.

Sie können den Server auch mit den folgenden Umgebungsvariablen konfigurieren:

HEX_LLM_LOG_LEVEL: Hiermit wird festgelegt, wie viele Logging-Informationen generiert werden. Der Standardwert ist INFO. Legen Sie hier eine der standardmäßigen Python-Logging-Ebenen fest, die im Logging-Modul definiert sind.
HEX_LLM_VERBOSE_LOG: Gibt an, ob eine detaillierte Logging-Ausgabe aktiviert werden soll. Zulässige Werte sind true und false. Der Standardwert ist false.

Serverargumente optimieren

Die Serverargumente sind miteinander verknüpft und wirken sich gemeinsam auf die Auslieferungsleistung aus. Eine größere Einstellung von --max_model_len=4096 führt beispielsweise zu einer höheren TPU-Speichernutzung und erfordert daher eine größere Speicherzuweisung und weniger Batches. Außerdem werden einige Argumente vom Anwendungsfall bestimmt, während andere angepasst werden können. Hier ist ein Workflow zum Konfigurieren des Hex-LLM-Servers.

Legen Sie die gewünschte Modellfamilie und Modellvariante fest. Beispiel: Llama 3.1 8B Instruct.
Schätzen Sie die Untergrenze des erforderlichen TPU-Speichers basierend auf der Modellgröße und -präzision ab: model_size * (num_bits / 8). Für ein 8‑B-Modell und eine Genauigkeit von bfloat16 ist ein TPU-Speicher mit mindestens 8 * (16 / 8) = 16 GB GiB erforderlich.
Schätzen Sie die Anzahl der benötigten TPU v5e-Chips, wobei jeder v5e-Chip 16 GB bietet: tpu_memory / 16. Für ein 8‑Bit-Modell und die Genauigkeit bfloat16 benötigen Sie mehr als einen Chip. Von den 1‑Chip-, 4‑Chip- und 8‑Chip-Konfigurationen ist die 4‑Chip-Konfiguration die kleinste Konfiguration, die mehr als einen Chip bietet: ct5lp-hightpu-4t. Sie können --tensor_parallel_size=4 später festlegen.
Legen Sie die maximale Kontextlänge (Eingabelänge + Ausgabelänge) für den beabsichtigten Anwendungsfall fest. Beispiel: 4096. Sie können --max_model_len=4096 später festlegen.
Passen Sie die Menge des freien TPU-Speichers, der dem KV-Cache zugewiesen ist, auf den maximalen Wert an, der unter Berücksichtigung des Modells, der Hardware und der Serverkonfigurationen möglich ist (--hbm_utilization_factor). Beginnen Sie mit 0.95. Stellen Sie den Hex-LLM-Server bereit und testen Sie ihn mit langen Prompts und hoher Parallelität. Wenn der Server nicht genügend Arbeitsspeicher hat, reduzieren Sie den Auslastungsfaktor entsprechend.

Hier ein Beispiel für Argumente zum Bereitstellen von 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

Hier ein Beispiel für Argumente zur Bereitstellung von Llama 3.1 70B Instruct AWQ auf 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-Kontingent anfordern

In Model Garden beträgt Ihr Standardkontingent 4 Cloud TPU v5e-Chips in der Region us-west1. Diese Kontingente gelten für Bereitstellungen mit nur einem Klick und Colab Enterprise-Notebook-Bereitstellungen. Informationen zum Anfordern zusätzlicher Kontingente finden Sie unter Höheres Kontingent anfordern.