AWS mira atrasos de inferência no SageMaker com cache de modelos do HyperPod e roteamento por prefixo

A AWS está adicionando duas funcionalidades de infraestrutura voltadas a gargalos distintos, mas relacionados, no serving de grandes modelos de linguagem: cache de modelos para o Amazon SageMaker HyperPod e roteamento sensível a prefixo para o SageMaker Inference. A primeira foi projetada para encurtar o tempo necessário para colocar novos pods de inferência no ar; a segunda pretende reduzir a latência de resposta mantendo o cálculo de prompts frequentemente reutilizado na mesma instância.

As mudanças importam mais para equipes que operam modelos grandes sob tráfego variável. Sem cache, um evento de scale-out pode exigir que novos nós baixem imagens de contêiner e pesos do modelo de vários gigabytes antes de atenderem solicitações. Sem roteamento que considere o conteúdo do prompt, o cache de prefixo de um framework de serving pode ficar subutilizado porque trechos idênticos de prompt são espalhados por toda a frota.

Ambos os anúncios vêm do AWS Machine Learning Blog, portanto os números de desempenho e as afirmações operacionais são relatados pela AWS e não verificados de forma independente. Juntos, eles delineiam uma abordagem mais coordenada para reduzir tanto cold starts de inferência quanto o tempo até o primeiro token em estado estável.

O cache do HyperPod aborda a lacuna de scale-out

A AWS diz que a implantação de modelos no SageMaker HyperPod pode ser atrasada por dois downloads sequenciais. O Kubernetes primeiro puxa uma imagem do servidor de inferência do Amazon Elastic Container Registry, após o que o servidor baixa os pesos do modelo de uma fonte como Amazon S3, Amazon FSx for Lustre, Hugging Face Hub ou JumpStart.

Para modelos menores, esse processo pode levar minutos. A AWS cita o exemplo de um modelo de 145 GB cujo download dos pesos pode levar mais de 20 minutos a partir do Amazon S3, dependendo das condições de rede. Para um modelo como o DeepSeek-R1, que a AWS descreve como pesando mais de 600 GB no cenário citado, o processo pode levar 30 minutos ou mais. Apenas o pull da imagem do contêiner é estimado pela AWS em cinco a sete minutos para imagens de inferência típicas de vários gigabytes.

Esse atraso cria uma defasagem entre o autoscaling e a capacidade real. Um HorizontalPodAutoscaler pode solicitar rapidamente pods adicionais, mas esses pods não conseguem aceitar tráfego até que suas imagens e pesos estejam disponíveis. Um pico repentino de requisições pode, portanto, acionar uma resposta operacional que chega dezenas de minutos tarde demais.

A nova capacidade de cache de modelo pré-carrega os pesos no armazenamento NVMe local nos nós de destino. A AWS diz que o HyperPod Inference Operator baixa os pesos com antecedência, marca os nós como prontos para cache e espera que os nós de destino concluam o processo antes de criar a implantação de inferência. Uma vez que um pod inicia em um nó preparado, ele pode ler localmente a aproximadamente 7 GB por segundo em vez de baixar o modelo pela rede.

A AWS também oferece um cache de imagem independente. Um DaemonSet faz o pré-pull da imagem do contêiner de inferência nos nós, permitindo que pods posteriores pulem o download do Amazon Elastic Container Registry. Várias implantações usando a mesma imagem podem compartilhar esse cache, enquanto o operador gerencia referências e limpeza.

Como os dois sistemas de cache se comportam em produção

Cache de pesos e cache de imagem não têm a mesma semântica de implantação. A AWS diz que o cache de pesos pode atrasar a criação da implantação de inferência até que todos os nós de destino estejam prontos, enquanto o cache de imagem não bloqueia a criação da implantação. Um pod, portanto, pode iniciar antes de um cache de imagem terminar em um nó específico e cair para um pull normal de imagem.

Ambos os mecanismos usam agendamento preferencial em vez de obrigatório. Os pods são direcionados para nós com dados quentes quando possível, mas não são impedidos de rodar em outro lugar. Se um scale-out rápido exceder o número de nós preparados, um pod pode usar a fonte original do modelo e puxar sua imagem normalmente. A troca é um start-up mais lento, não uma implantação falha.

O operador gerencia dois recursos personalizados subjacentes: ModelDataCacheConfig para pesos de modelo e ModelImageCache para imagens de contêiner. Os usuários habilitam o cache por meio de modelCacheConfig em um recurso InferenceEndpointConfig ou JumpStartModel, em vez de gerenciar diretamente esses objetos de ciclo de vida.

A AWS também diz que atualizações de cache são tratadas quando uma fonte de modelo ou imagem muda. O operador cria um novo cache, faz o rollout da implantação atualizada e então remove o cache antigo. Isso visa evitar pesos obsoletos enquanto oferece suporte a transições sem tempo de inatividade, embora o resultado prático ainda dependa do armazenamento disponível nos nós e do tempo necessário para preencher o cache de substituição.

O roteamento sensível a prefixo mantém úteis os caches de prompt de LLM

A segunda mudança no SageMaker atinge outra camada da stack de serving. Muitas solicitações de LLM contêm um prefixo longo e repetido — como instruções de sistema, documentos recuperados, histórico de conversa ou código-fonte — seguido por um sufixo curto específico do usuário. Frameworks como vLLM e TensorRT-LLM podem reutilizar o cache key-value, ou KV, calculado para esse prefixo repetido.

A distribuição aleatória de solicitações enfraquece esse benefício em um endpoint com múltiplas instâncias. Se solicitações sucessivas com o mesmo prefixo caírem em máquinas diferentes, cada instância pode precisar recalcular o contexto compartilhado. A nova estratégia de roteamento sensível a prefixo do SageMaker Inference examina o início de uma solicitação e envia consistentemente prefixos correspondentes para a mesma instância.

A AWS diz que o recurso também pode proteger a frota de um prefixo excessivamente popular. Se a instância preferida atingir seu limite configurado de concorrência, a solicitação pode ser redirecionada para uma instância menos ocupada. Isso pode sacrificar um cache hit para uma solicitação, mas evita concentrar tráfego em uma única máquina. A AWS ainda diz que adicionar ou remover instâncias deve deslocar apenas uma porção limitada do tráfego, ajudando a preservar a localidade do cache durante a escala.

A estratégia é configurada por variante de produção e pode ser alterada pela configuração do endpoint sem redeploy do modelo. A AWS continua oferecendo roteamento aleatório como padrão, além de roteamento por menor número de solicitações pendentes para workloads em que as durações das solicitações variam. O roteamento sensível a prefixo é voltado especificamente a workloads de LLM com contexto inicial compartilhado e cache de prefixo habilitado.

Evidências, benchmarks e limites

A AWS benchmarkou o roteamento sensível a prefixo contra o roteamento aleatório usando Llama 3.1 70B Instruct em sete instâncias ml.p5.48xlarge com vLLM e cache de prefixo habilitados. Em 16 configurações de teste cobrindo diferentes arranjos de endpoint e API, a AWS relata redução de até 77% no tempo mediano até o primeiro token, ganhos de throughput de até 16% e aumento na taxa de acerto do cache KV de cerca de 25% para mais de 80%.

Esses são resultados de benchmark relatados pelo fornecedor, não uma avaliação independente. A AWS diz que o tráfego permaneceu balanceado nos testes, com cada instância recebendo entre 13,3% e 15,4% das solicitações. Também relata um custo adicional de roteamento de 1,3 a 1,9 milissegundos por solicitação, em comparação com resultados de tempo até o primeiro token do modelo variando de 63 a 280 milissegundos nas configurações testadas.

O tamanho do benefício depende fortemente da forma da workload. A AWS diz que prefixos compartilhados mais longos geram ganhos maiores porque mais computação pode ser ignorada. Entre os casos de uso identificados pela AWS estão sistemas RAG que consultam repetidamente o mesmo documento, conversas multi-turno, assistentes baseados em templates e conclusão de código. Workloads com prompts curtos ou majoritariamente únicos devem ver menos valor.

As alegações do HyperPod também dependem de condições que não estão totalmente especificadas na fonte, incluindo disponibilidade de nós, tempo de preenchimento do cache, capacidade de armazenamento, formato do modelo e desempenho de rede durante o pré-carregamento inicial. A transição declarada de dezenas de minutos para segundos se aplica quando um pod cai em um nó que já tem os dados relevantes em cache; um nó não preparado segue o caminho normal de download.

O que as mudanças significam para equipes de infraestrutura de IA

Para builders e equipes de plataforma corporativa, os anúncios separam duas decisões que muitas vezes são tratadas como um único problema de latência. O cache de modelos melhora a elasticidade: ele pode tornar nova capacidade útil mais cedo quando o tráfego aumenta. O roteamento sensível a prefixo melhora a eficiência das requisições: ele pode reduzir o trabalho repetido de prefill depois que a capacidade já está online.

A combinação pode ser útil para aplicações RAG e assistentes que têm tanto tráfego em rajadas quanto grandes contextos repetidos. Uma equipe pode usar o cache do HyperPod para preparar nós para scale-out enquanto usa o roteamento sensível a prefixo para manter documentos ou prefixos de conversa quentes na frota ativa. Isso não elimina a necessidade de dimensionar a capacidade local NVMe, configurar limites de concorrência ou medir taxas de acerto de cache em tráfego real.

Há também questões de custo e confiabilidade que compradores devem testar. Manter pesos em cada nó de destino consome armazenamento local e pode aumentar o tempo de preparação antes que uma implantação esteja pronta. A afinidade por prefixo pode melhorar a latência, mas introduz um comportamento de roteamento dependente de conteúdo que as equipes devem observar junto com profundidade de fila, utilização de instâncias, ocupação do cache e latência de cauda. Revisões de privacidade e governança de dados também podem importar porque as decisões de roteamento inspecionam o início dos payloads das solicitações, mesmo que a AWS trate o roteamento automaticamente.

O que observar a seguir

As equipes que avaliarem os recursos devem procurar resultados reproduzidos independentemente em modelos, hardware e distribuições de prompts além do teste da AWS com Llama 3.1 70B. As métricas mais úteis incluirão p95 e p99 do tempo até o primeiro token, taxas de acerto de cache durante o scale-out e a porcentagem de solicitações que caem em nós não preparados.

Orientações operacionais sobre dimensionamento de NVMe local, orquestração de aquecimento de cache e clusters multi-modelo também serão importantes. Os compradores devem verificar como a preparação do cache afeta rollouts de implantação, substituição de nós, cenários spot ou de interrupção e escala rápida além da frota pré-carregada.

Por fim, os controles de roteamento no nível de endpoint da AWS podem se tornar mais importantes à medida que plataformas de serving hospedadas competem mais por latência previsível do que apenas por acesso ao modelo. O sinal a observar será se os clientes conseguem usar esses controles sem adicionar complexidade substancial de agendamento ou sacrificar utilização equilibrada de GPU.

Perspectiva da Creati.ai

A AWS está abordando duas fraquezas práticas nas operações de LLM em vez de introduzir uma nova capacidade de modelo. O cache de modelo do HyperPod reduz a penalidade de adicionar capacidade, enquanto o roteamento sensível a prefixo torna mais confiável, em várias instâncias, uma otimização de serving já existente — a reutilização do cache KV.

O caso mais forte é para workloads previsíveis, com contexto repetido e tráfego suficiente para justificar o pré-carregamento de modelos grandes. Para equipes com prompts majoritariamente únicos ou implantações pouco frequentes, a sobrecarga de armazenamento e preparação pode superar os ganhos. Os números de benchmark da AWS são encorajadores, mas compradores de infraestrutura devem validá-los contra seu próprio overlap de prompts, padrões de escala e metas de latência antes de tratar o cache como uma melhoria garantida.