Esta página mostra como realizar operações de lançamento incremental, que implantam gradualmente novas versões da sua infraestrutura de inferência, para o gateway de inferência do GKE. Esse gateway permite que você realize atualizações seguras e controladas na sua infraestrutura de inferência. É possível atualizar nós, modelos básicos e adaptadores LoRA com a interrupção mínima do serviço. Esta página também oferece orientações sobre a divisão de tráfego e as revisões para garantir implantações confiáveis.
Esta página é destinada a administradores de identidade e conta do GKE e desenvolvedores que querem realizar operações de lançamento do Gateway de inferência do GKE.
Os seguintes casos de uso são compatíveis:
- Lançamento da atualização de nós (compute, acelerador)
- Lançamento da atualização do modelo base
- Implantação da atualização do adaptador LoRA
Atualizar um lançamento de nó
As implantações de atualização de nós migram com segurança as cargas de trabalho de inferência para novos hardwares de nó ou configurações de acelerador. Esse processo ocorre de maneira controlada sem interromper o serviço do modelo. Use as implantações de atualização de nós para minimizar a interrupção do serviço durante upgrades de hardware, atualizações de driver ou resolução de problemas de segurança.
Criar uma
InferencePool
: implantar umaInferencePool
configurada com as especificações atualizadas do nó ou do hardware.Dividir o tráfego usando um
HTTPRoute
: configure umHTTPRoute
para distribuir o tráfego entre os recursosInferencePool
atuais e novos. Use o campoweight
embackendRefs
para gerenciar a porcentagem de tráfego direcionada aos novos nós.Manter um
InferenceModel
consistente: mantenha a configuraçãoInferenceModel
atual para garantir o comportamento uniforme do modelo nas duas configurações de nó.Manter os recursos originais: mantenha o
InferencePool
e os nós originais ativos durante o lançamento para permitir rollbacks, se necessário.
Por exemplo, você pode criar um novo InferencePool
chamado llm-new
. Configure
esse pool com a mesma configuração de modelo do llm
InferencePool
atual. Implante o pool em um novo conjunto de nós no cluster. Use
um objeto HTTPRoute
para dividir o tráfego entre o llm
original e o novo
InferencePool
llm-new
. Essa técnica permite atualizar de forma incremental os nós do modelo.
O diagrama a seguir ilustra como o GKE Inference Gateway realiza um lançamento de atualização de nó.

Para realizar um lançamento de atualização de nó, siga estas etapas:
Salve o seguinte manifesto de amostra como
routes-to-llm.yaml
:apiVersion: gateway.networking.k8s.io/v1 kind: `HTTPRoute` metadata: name: routes-to-llm spec: parentRefs: - name: my-inference-gateway rules: backendRefs: - name: llm kind: InferencePool weight: 90 - name: llm-new kind: InferencePool weight: 10
Aplique o manifesto de exemplo ao cluster:
kubectl apply -f routes-to-llm.yaml
O InferencePool
llm
original recebe a maior parte do tráfego, enquanto o
InferencePool
llm-new
recebe o restante. Aumente gradualmente o peso do tráfego para o InferencePool
llm-new
para concluir o lançamento da atualização do nó.
Implantar um modelo base
As atualizações do modelo de referência são lançadas em fases para um novo LLM de referência, mantendo a compatibilidade com os adaptadores LoRa atuais. Você pode usar as atualizações de modelos básicos para fazer upgrade para arquiteturas de modelos aprimoradas ou resolver problemas específicos do modelo.
Para lançar uma atualização de modelo básico:
- Implantar nova infraestrutura: crie novos nós e um novo
InferencePool
configurado com o novo modelo base escolhido. - Configurar a distribuição de tráfego: use um
HTTPRoute
para dividir o tráfego entre oInferencePool
atual (que usa o modelo de base antigo) e o novoInferencePool
(que usa o novo modelo de base). O campobackendRefs weight
controla a porcentagem de tráfego alocada para cada pool. - Manter a integridade do
InferenceModel
: mantenha a configuração doInferenceModel
inalterada. Isso garante que o sistema aplique os mesmos adaptadores LoRa de forma consistente nas duas versões do modelo básico. - Preserve o recurso de reversão: mantenha os nós originais e
InferencePool
durante o lançamento para facilitar uma reversão, se necessário.
Você cria um novo InferencePool
com o nome llm-pool-version-2
. Esse pool implanta
uma nova versão do modelo base em um novo conjunto de nós. Ao
configurar um HTTPRoute
, conforme mostrado no exemplo fornecido, você pode
dividir o tráfego de forma incremental entre o llm-pool
original e o
llm-pool-version-2
. Isso permite controlar as atualizações do modelo base no
cluster.
Para realizar um lançamento de atualização de modelo básico, siga estas etapas:
Salve o seguinte manifesto de amostra como
routes-to-llm.yaml
:apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: routes-to-llm spec: parentRefs: - name: my-inference-gateway rules: backendRefs: - name: llm-pool kind: InferencePool weight: 90 - name: llm-pool-version-2 kind: InferencePool weight: 10
Aplique o manifesto de exemplo ao cluster:
kubectl apply -f routes-to-llm.yaml
O InferencePool
llm-pool
original recebe a maior parte do tráfego, enquanto o
InferencePool
llm-pool-version-2
recebe o restante. Aumente gradualmente o peso do tráfego para o llm-pool-version-2
InferencePool
para concluir o lançamento da atualização do modelo básico.
Lançar atualizações do adaptador LoRA
Os lançamentos de atualização do adaptador LoRa permitem implantar novas versões de modelos ajustados em fases, sem alterar o modelo de base ou a infraestrutura subjacente. Use as atualizações de adaptadores LoRA para testar melhorias, correções de bugs ou novos recursos nos adaptadores LoRA.
Para atualizar um adaptador LoRa, siga estas etapas:
Disponibilizar adaptadores: verifique se as novas versões do adaptador LoRA estão disponíveis nos servidores de modelo. Para mais informações, consulte Lançamento do adaptador.
Modificar a configuração
InferenceModel
: na configuraçãoInferenceModel
atual, defina várias versões do adaptador LoRA. Atribua ummodelName
exclusivo a cada versão (por exemplo,llm-v1
,llm-v2
).Distribuir tráfego: use o campo
weight
na especificaçãoInferenceModel
para controlar a distribuição de tráfego entre as diferentes versões do adaptador LoRa.Manter um
poolRef
consistente: verifique se todas as versões do adaptador LoRA fazem referência ao mesmoInferencePool
. Isso evita reimplantações de nó ouInferencePool
. Mantenha as versões anteriores do adaptador LoRa na configuraçãoInferenceModel
para ativar reversões.
O exemplo a seguir mostra duas versões do adaptador LoRA, llm-v1
e llm-v2
.
As duas versões usam o mesmo modelo básico. Você define llm-v1
e llm-v2
na
mesma InferenceModel
. Você atribui pesos para mudar gradualmente o tráfego
de llm-v1
para llm-v2
. Esse controle permite um lançamento controlado sem
requerer nenhuma mudança nos nós ou na configuração InferencePool
.
Para lançar atualizações do adaptador LoRA, execute o seguinte comando:
Salve o seguinte manifesto de amostra como
inferencemodel-sample.yaml
:apiVersion: inference.networking.x-k8s.io/v1alpha2 kind: InferenceModel metadata: name: inferencemodel-sample spec: versions: - modelName: llm-v1 criticality: Critical weight: 90 poolRef: name: llm-pool - modelName: llm-v2 criticality: Critical weight: 10 poolRef: name: llm-pool
Aplique o manifesto de exemplo ao cluster:
kubectl apply -f inferencemodel-sample.yaml
A versão llm-v1
recebe a maior parte do tráfego, enquanto a versão llm-v2
recebe o restante. Aumente gradualmente o peso do tráfego para a versão llm-v2
para concluir o lançamento da atualização do adaptador LoRA.
A seguir
- Personalizar a configuração do gateway de inferência do GKE
- Disponibilizar um LLM com o GKE Inference Gateway