Esta página foi traduzida pela API Cloud Translation.

Disponibilize modelos abertos usando o contêiner premium Hex-LLM no Cloud TPU

O Hex-LLM, um modelo de linguagem grande (LLM) de alta eficiência que veicula com XLA, é a Framework de disponibilização de LLMs da Vertex AI projetado e otimizado para hardware do Cloud TPU. O Hex-LLM combina tecnologias de veiculação de LLM como lotes contínuos e PagedAttentioncom as otimizações da Vertex AI personalizados para XLA e Cloud TPU. É um LLM de alta eficiência e baixo custo que é veiculado no Cloud TPU para os modelos de origem.

O Hex-LLM está disponível no Model Garden por meio de modelo Playground, implantação com um clique e notebook.

Recursos

O Hex-LLM é baseado em projetos de código aberto com as otimizações do próprio Google para XLA e o Cloud TPU. O Hex-LLM atinge alta capacidade de processamento e baixa latência na disponibilização os LLMs usados com frequência.

O Hex-LLM inclui as seguintes otimizações:

Algoritmo de lote contínuo baseado em token para ajudar a garantir que os modelos sejam totalmente utilizando o hardware com um grande número de solicitações simultâneas.
Uma reescrita completa dos kernels de atenção otimizados para XLA.
Estratégias de paralelismo de dados flexíveis e combináveis e de paralelismo de tensores com métodos de fragmentação de peso altamente otimizados para executar LLMs com eficiência vários chips do Cloud TPU.

O Hex-LLM oferece suporte a uma ampla gama de LLMs densos e esparsos:

Gemma 2B e 7B
Gemma 2 9B e 27B
Llama 2 7B, 13B e 70B
Llama 3 8B e 70B
Llama 3.1 8B e 70B
Llama 3.2 1B e 3B
Llama Guard 3 1B e 8B
Mistral 7B
Mixtral 8x7B e 8x22B
Phi-3 mini e médio
Qwen2 0,5B, 1,5B e 7B
Qwen2.5 0.5B, 1.5B, 7B, 14B e 32B AWQ

O Hex-LLM também oferece vários recursos, entre eles:

Hex-LLM está incluído em um único contêiner. O Hex-LLM empacota o servidor da API, mecanismo de inferência e modelos com suporte em uma única imagem Docker para ser implantados.
Compatível com os modelos Hugging Face . O Hex-LLM pode carregar um modelo Hugging Face do disco local, o Hugging o Face Hub e um bucket do Cloud Storage.
Quantização usando bitsandbytes e AWQ:
Carregamento dinâmico LoRA (em inglês). O Hex-LLM é capaz de carregar os pesos LoRA lendo o argumento da solicitação durante a disponibilização.

Recursos avançados

O Hex-LLM oferece suporte aos seguintes recursos avançados:

Disponibilização de vários hosts
Exibição desagregada [experimental]
Armazenamento em cache de prefixo
Suporte a quantização de 4 bits

Disponibilização de vários hosts

O Hex-LLM agora oferece suporte à veiculação de modelos com uma fração de TPU de vários hosts. Esse recurso permite veicular modelos grandes que não podem ser carregados em uma única VM de TPU do host, que contém no máximo oito núcleos v5e.

Para ativar esse recurso, defina --num_hosts nos argumentos do contêiner Hex-LLM e defina --tpu_topology na solicitação de upload de modelo do SDK da Vertex AI. O exemplo a seguir mostra como implantar o contêiner Hex-LLM com uma topologia TPU 4x4 v5e que serve o modelo 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,
)

Para um tutorial completo sobre como implantar o contêiner Hex-LLM com uma topologia de TPU multihost, consulte o notebook Vertex AI Model Garden - Llama 3.1 (Deployment).

Em geral, as únicas mudanças necessárias para ativar a veiculação em vários hosts são:

Defina o argumento --tensor_parallel_size como o número total de cores na topologia de TPU.
Defina o argumento --num_hosts como o número de hosts na topologia da TPU.
Defina --tpu_topology com a API de upload de modelos do SDK da Vertex AI.

Exibição desagregada [experimental]

O Hex-LLM agora oferece suporte à veiculação desagregada como um recurso experimental. Ele só pode ser ativado na configuração de host único, e a performance está sendo ajustada.

A veiculação desagregada é um método eficaz para equilibrar o tempo para o primeiro token (TTFT, na sigla em inglês) e o tempo por token de saída (TPOT, na sigla em inglês) para cada solicitação e o throughput de veiculação geral. Ele separa a fase de pré-preenchimento e a fase de decodificação em cargas de trabalho diferentes para que elas não interfiram uma na outra. Esse método é especialmente útil para cenários que definem requisitos de latência rígidos.

Para ativar esse recurso, defina --disagg_topo nos argumentos do contêiner Hex-LLM. Confira a seguir um exemplo que mostra como implantar o contêiner Hex-LLM no TPU v5e-8 que atende o modelo 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,
)

O argumento --disagg_topo aceita uma string no formato "number_of_prefill_workers,number_of_decode_workers". No exemplo anterior, ele está definido como "3,1" para configurar três workers de preenchimento prévio e um worker de decodificação. Cada worker usa dois núcleos de TPU v5e.

Armazenamento em cache de prefixo

O armazenamento em cache de prefixo reduz o tempo para o primeiro token (TTFT, na sigla em inglês) para comandos que têm conteúdo idêntico no início, como preâmbulos em toda a empresa, instruções comuns do sistema e histórico de conversas com várias interações. Em vez de processar os mesmos tokens de entrada repetidamente, o Hex-LLM pode reter um cache temporário das computações de token de entrada processadas para melhorar o TTFT.

Para ativar esse recurso, defina --enable_prefix_cache_hbm nos argumentos do contêiner Hex-LLM. Confira a seguir um exemplo que mostra como implantar o contêiner Hex-LLM na TPU v5e-8 que atende o modelo bfloat16 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=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,
)

O Hex-LLM usa o armazenamento em cache de prefixo para otimizar o desempenho de comandos que excedem um determinado comprimento (512 tokens por padrão, configurável usando prefill_len_padding). Os acertos de cache ocorrem em incrementos desse valor, garantindo que a contagem de tokens em cache seja sempre um múltiplo de prefill_len_padding. O campo cached_tokens de usage.prompt_tokens_details na resposta da API de conclusão de chat indica quantos dos tokens de comando foram um acerto de cache.

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

Suporte a quantização de 4 bits

A quantização é uma técnica para reduzir os custos computacionais e de memória da execução de inferência, representando os pesos ou ativações com tipos de dados de baixa precisão, como INT8 ou INT4, em vez do BF16 ou FP32.

O Hex-LLM oferece suporte à quantização somente de peso INT8. O suporte estendido inclui modelos com pesos INT4 quantizados usando a quantização de ponto zero da AWQ. O Hex-LLM oferece suporte a variantes INT4 das famílias de modelos Mistral, Mixtral e Llama.

Não é necessário ter uma flag adicional para veicular modelos quantizados.

Introdução ao Model Garden

O contêiner de veiculação Hex-LLM do Cloud TPU está integrado o Grupo de modelos. Você pode acessar essa tecnologia de veiculação por meio do Playground, implantação com um clique e bloco do Colab Enterprise exemplos de uma variedade de modelos.

Usar o playground

O Model Garden Playground é uma solução pré-implantada endpoint acessível enviando solicitações no card de modelo.

Insira um comando e, se quiser, inclua argumentos para sua solicitação.
Clique em ENVIAR para receber a resposta do modelo rapidamente.

Faça um teste com Gemma!

Usar a implantação com um clique

É possível implantar um endpoint personalizado da Vertex AI com o Hex-LLM usando um card de modelo.

Navegue até o card de modelo. página e clique em Implantar.
Para a variação de modelo que você quer usar, selecione a Cloud TPU Tipo de máquina v5e para implantação.
Clique em Implantar na parte de baixo para iniciar o processo. Você recebe duas notificações por e-mail: um quando o modelo é carregado e outro quando endpoint esteja pronto.

Usar o bloco do Colab Enterprise

Para flexibilidade e personalização, use o Colab Enterprise exemplos de notebook para implantar um endpoint da Vertex AI com o Hex-LLM usando o SDK da Vertex AI para Python.

Acesse a página do card de modelo e clique em Abrir notebook.
Selecione o notebook da Vertex Serving. O notebook está aberto no Colab Enterprise
Executar pelo notebook para implantar um modelo usando o Hex-LLM e enviar solicitações de previsão ao endpoint. O snippet de código da implantação é da seguinte forma:

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

Confira alguns exemplos de notebooks do Colab Enterprise:

Configurar argumentos do servidor e variáveis de ambiente

É possível definir os seguintes argumentos para iniciar o servidor Hex-LLM. É possível adaptar os argumentos para melhor se adequar ao caso de uso e aos requisitos pretendidos. Os argumentos são predefinidos para implantação com um clique para facilitar a experiência de implantação. Para personalizar os argumentos, você pode usar os exemplos de notebook como referência e definir os argumentos de acordo.

Modelo

--model: o modelo a ser carregado. É possível especificar um ID de modelo do Hugging Face, um caminho de bucket do Cloud Storage (gs://my-bucket/my-model) ou um caminho local. Os artefatos do modelo precisam seguir o formato do Hugging Face e usar arquivos safetensors para os pesos do modelo. Os artefatos de modelo quantizados BitsAndBytes int8 e AWQ são compatíveis com Llama, Gemma 2 e Mistral/Mixtral.
--tokenizer: o tokenizador a ser carregado. Pode ser um ID de modelo do Hugging Face, um caminho de bucket do Cloud Storage (gs://my-bucket/my-model) ou um caminho local. Se esse argumento não for definido, o padrão será o valor de --model.
--tokenizer_mode: o modo do tokenizador. As opções possíveis são ["auto", "slow"]. O valor padrão é "auto". Se esse valor for definido como "auto", o tokenizer rápido será usado, se disponível. Os tokenizers lentos são programados em Python e fornecidos na biblioteca Transformers. Já os tokenizers rápidos que oferecem melhoria de desempenho são programados em Rust e fornecidos na biblioteca Tokenizers. Para mais informações, consulte a documentação do abraço.
--trust_remote_code: permite arquivos de código remotos definidos nos repositórios de modelos do Hugging Face. O valor padrão é False.
--load_format: formato dos checkpoints do modelo a serem carregados. As opções possíveis são ["auto", "dummy"]. O valor padrão é "auto". Se esse valor for definido como "auto", os pesos do modelo serão carregados no formato safetensors. Se esse valor for definido como "dummy", os pesos do modelo serão inicializados aleatoriamente. Definir esse valor como "dummy" é útil para experimentação.
--max_model_len: o comprimento máximo do contexto (comprimento de entrada mais o comprimento de saída) para veiculação do modelo. O valor padrão é lido do arquivo de configuração do modelo no formato Hugging Face: config.json. Um comprimento máximo maior de contexto requer mais memória de TPU.
--sliding_window: se definido, esse argumento substitui o tamanho da janela do modelo para atenção de janela deslizante. Definir esse argumento para um valor maior faz com que o mecanismo de atenção inclua mais tokens e se aproxime do efeito de autoatenção padrão. Esse argumento é destinado apenas ao uso experimental. Em casos de uso geral, recomendamos usar o tamanho de janela original do modelo.
--seed: a sugestão para inicializar todos os geradores de números aleatórios. Mudar esse argumento pode afetar a saída gerada para o mesmo comando, mudando os tokens que são amostrados como os próximos. O valor padrão é 0.

Mecanismo de inferência

--num_hosts: o número de hosts a serem executados. O valor padrão é 1. Para mais detalhes, consulte a documentação sobre a configuração da TPU v5e.
--disagg_topo: define o número de workers de pré-preenchimento e decodificação com a veiculação desagregada do recurso experimental. O valor padrão é None. O argumento segue o formato: "number_of_prefill_workers,number_of_decode_workers".
--data_parallel_size: o número de réplicas paralelas de dados. O valor padrão é 1. A configuração desse valor em N em vez de 1 melhora a taxa de transferência em aproximadamente N, mantendo a mesma latência.
--tensor_parallel_size: o número de réplicas paralelas do tensor. O valor padrão é 1. O aumento do número de réplicas paralelas de tensor geralmente melhora a latência, porque acelera a multiplicação de matrizes reduzindo o tamanho da matriz.
--worker_distributed_method: o método distribuído para iniciar o worker. Use mp para o módulo de processamento múltiplo ou ray para a biblioteca Ray. O valor padrão é mp.
--enable_jit: se o modo JIT (Just-in-Time Compilation) será ativado. O valor padrão é True. Se definir --no-enable_jit, ela será desativada. Ativar o modo JIT melhora o desempenho da inferência, mas exige mais tempo na compilação inicial. Em geral, os benefícios de desempenho da inferência superam a sobrecarga.
--warmup: se o servidor será aquecido com solicitações de amostra durante a inicialização. O valor padrão é True. A configuração --no-warmup desativa ela. O aquecimento é recomendado porque as solicitações iniciais acionam uma compilação mais pesada e, portanto, serão mais lentas.
--max_prefill_seqs: o número máximo de sequências que podem ser programadas para pré-preenchimento por iteração. O valor padrão é 1. Quanto maior esse valor, maior será a capacidade de processamento que o servidor pode alcançar, mas com possíveis efeitos adversos na latência.
--prefill_seqs_padding: o servidor aumenta o tamanho do lote de preenchimento prévio para um múltiplo desse valor. O valor padrão é 8. Aumentar esse valor reduz os tempos de recompilação do modelo, mas aumenta a computação desperdiçada e a sobrecarga de inferência. A configuração ideal depende do tráfego de solicitação.
--prefill_len_padding: o servidor aumenta o tamanho da sequência para um múltiplo deste valor. O valor padrão é 512. Aumentar esse valor reduz os tempos de recompilação do modelo, mas aumenta o overhead de computação e inferência desperdiçado. A configuração ideal depende da distribuição de dados das solicitações.
--max_decode_seqs/--max_running_seqs: o número máximo de sequências que pode ser programado para decodificação por iteração. O valor padrão é 256. Quanto maior for esse valor, maior será a capacidade de processamento que o servidor pode alcançar, mas com possíveis efeitos adversos na latência.
--decode_seqs_padding: o servidor preenche o tamanho do lote de decodificação com um múltiplo deste valor. O valor padrão é 8. Aumentar esse valor reduz os tempos de recompilação do modelo, mas aumenta o desperdício de computação e a sobrecarga de inferência. A configuração ideal depende do tráfego de solicitação.
--decode_blocks_padding: o servidor preenche o número de blocos de memória usados para o cache de chave-valor (KV) de uma sequência em um múltiplo desse valor durante a decodificação. O valor padrão é 128. Aumentar esse valor reduz os tempos de recompilação do modelo, mas aumenta o overhead de computação e inferência desperdiçado. A configuração ideal depende da distribuição de dados das solicitações.
--enable_prefix_cache_hbm: se o armazenamento em cache de prefixo será ativado no HBM. O valor padrão é False. A configuração desse argumento pode melhorar o desempenho reutilizando as computações de prefixos compartilhados de solicitações anteriores.

Gerenciamento de memória

--hbm_utilization_factor: a porcentagem de memória de alta largura de banda (HBM) do Cloud TPU disponível para o cache KV após o carregamento dos pesos do modelo. O valor padrão é 0.9. Definir esse argumento como um valor maior aumenta o tamanho do cache KV e pode melhorar a taxa de transferência, mas aumenta o risco de ficar sem o HBM do Cloud TPU durante a inicialização e no momento da execução.
--num_blocks: número de blocos de dispositivos a serem alocados para o cache KV. Se esse argumento for definido, o servidor vai ignorar --hbm_utilization_factor. Se esse argumento não for definido, os perfis do servidor vão usar o HBM e calcular o número de blocos de dispositivos a serem alocados com base em --hbm_utilization_factor. Definir esse argumento como um valor maior aumenta o tamanho do cache KV e pode melhorar a capacidade de processamento, mas aumenta o risco de esgotar o HBM do Cloud TPU durante a inicialização e no momento da execução.
--block_size: número de tokens armazenados em um bloco. As opções possíveis são [8, 16, 32, 2048, 8192]. O valor padrão é 32. Definir esse argumento para um valor maior reduz a sobrecarga no gerenciamento de blocos, à custa de mais desperdício de memória. O impacto exato no desempenho precisa ser determinado empiricamente.

LoRA dinâmico

--enable_lora: se o carregamento dinâmico de adaptadores LoRA (em inglês) será ativado no Cloud Storage. O valor padrão é False. Isso é compatível com a família de modelos Llama.
--max_lora_rank: a classificação máxima de LoRA aceita para adaptadores LoRA definidos nas solicitações. O valor padrão é 16. Definir esse argumento com um valor mais alto permite maior flexibilidade nos adaptadores LoRA que podem ser usados com o servidor, mas aumenta a quantidade de HBM do Cloud TPU alocada para pesos LoRA e diminui a capacidade de processamento.
--enable_lora_cache: se o armazenamento em cache de adaptadores LoRA dinâmicos será ativado. O valor padrão é True. Se definir --no-enable_lora_cache, ela será desativada. O armazenamento em cache melhora a performance porque elimina a necessidade de fazer o download novamente de arquivos de adaptador LoRA usados anteriormente.
--max_num_mem_cached_lora: o número máximo de adaptadores LoRA armazenados no cache de memória da TPU.O valor padrão é 16. Definir esse argumento como um valor maior aumenta a chance de um acerto no cache, mas aumenta a quantidade de uso do HBM do Cloud TPU.

Também é possível configurar o servidor usando as seguintes variáveis de ambiente:

HEX_LLM_LOG_LEVEL: controla a quantidade de informações de registro geradas. O valor padrão é INFO. Defina esse valor como um dos níveis de registro padrão do Python definidos no módulo de registro.
HEX_LLM_VERBOSE_LOG: ativa a saída de registro detalhada. Os valores permitidos são true ou false. O valor padrão é false.

Ajustar argumentos do servidor

Os argumentos do servidor estão relacionados e têm um efeito coletivo no desempenho da veiculação. Por exemplo, uma configuração maior de --max_model_len=4096 leva a um uso maior da memória de TPU e, portanto, requer uma alocação maior de memória e menos lotes. Além disso, alguns argumentos são determinados pelo caso de uso, enquanto outros podem ser ajustados. Este é um fluxo de trabalho para configurar o servidor Hex-LLM.

Determine a família e a variante do modelo de interesse. Por exemplo, o Llama 3.1 8B Instruct.
Estimar o limite inferior da memória da TPU necessária com base no tamanho e na precisão do modelo: model_size * (num_bits / 8). Para um modelo de 8B e precisão bfloat16, o limite inferior de memória da TPU necessário seria 8 * (16 / 8) = 16 GB.
Estimar o número de chips TPU v5e necessários, em que cada chip v5e oferece 16 GB: tpu_memory / 16. Para um modelo de 8B e precisão bfloat16, você precisa de mais de um chip. Entre as configurações de 1, 4 e 8 chips, a menor que oferece mais de um chip é a de 4 chips: ct5lp-hightpu-4t. Você pode definir --tensor_parallel_size=4 posteriormente.
Determine o comprimento máximo do contexto (comprimento de entrada + comprimento de saída) para o caso de uso pretendido. Por exemplo, 4096. Você pode definir --max_model_len=4096 posteriormente.
Ajuste a quantidade de memória TPU livre alocada para o cache KV para o valor máximo alcançável considerando o modelo, o hardware e as configurações do servidor (--hbm_utilization_factor). Comece com 0.95. Implante o servidor Hex-LLM e teste-o com comandos longos e alta simultaneidade. Se o servidor ficar sem memória, reduza o fator de utilização de acordo.

Um conjunto de argumentos de exemplo para implantar o 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

Um conjunto de argumentos de exemplo para implantar o AWQ Instruct 70B do Llama 3.1 em 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

Solicitar cota do Cloud TPU

No Model Garden, sua cota padrão é de quatro chips do Cloud TPU v5e na região us-west1. Essas cotas se aplicam a implantações com um clique e Implantações de notebooks do Colab Enterprise. Para solicitar mais cotas, consulte Solicitar uma a cota.