O desequilíbrio entre prefill e decode
A arquitetura de serving de modelos de linguagem (LLMs) tem evoluído para separar as fases de prefill e decode. Essa dissociação, conhecida como prefill-decode disaggregation, permite otimizar cada fase de forma independente, pois elas apresentam padrões de execução e objetivos de nível de serviço (SLO) distintos.
As cargas de trabalho reais, porém, não são estáticas. Picos breves e mudanças prolongadas na proporção de demanda entre prefill e decode podem desequilibrar rapidamente uma configuração que estava bem dimensionada. Esse descompasso pode causar violações dos SLOs de latência mesmo quando há capacidade ociosa em outras partes do sistema.
Os mecanismos de elasticidade in-place do FluidPD
FluidPD é um sistema de serving com prefill e decode desagregados que propõe dois mecanismos complementares para lidar com esse desequilíbrio. O primeiro, FluidToken, trata desajustes transitórios transferindo uma parcela limitada do cálculo de prefill para workers de decode quando há capacidade ociosa nesse lado.
O segundo mecanismo, FluidRole, trata desequilíbrios prolongados ao reatribuir workers em execução entre as funções de prefill e decode. A reatribuição ocorre in-place, sem recarregar o modelo nem reiniciar o mecanismo de inferência, o que, segundo os autores, permite adaptar o sistema às mudanças de carga sem recorrer à inicialização de workers novos.
Comparação entre mecanismos de elasticidade
Diferenças descritas entre os mecanismos do FluidPD e o autoscaling convencional.
| Característica | FluidToken | FluidRole | Autoscaling convencional |
|---|---|---|---|
| Tipo de desequilíbrio | Transitório | Prolongado | Prolongado |
| Ação principal | Transferência de parte do cálculo | Reatribuição de funções | Adicionar ou remover GPUs |
| Exige GPUs de reserva | Não, de acordo com a proposta | Não, de acordo com a proposta | Pode exigir |
| Recarrega o modelo | Não, conforme a descrição do mecanismo | Não, conforme a descrição do mecanismo | A descrição do preprint não detalha todos os casos |
Métricas e condições de avaliação
Os autores do preprint relatam que o FluidPD aumenta em até 94,6 pontos percentuais o cumprimento geral de SLO em comparação com o SGLang estático. O resumo informa que a avaliação usa cargas de trabalho de produção representadas por traces do Azure.
Esse resultado é uma afirmação dos autores no resumo do preprint, não uma verificação independente. O material disponível não detalha aqui a configuração completa de serving, as métricas específicas de latência, os limites dos SLOs, os comparadores adicionais ou todos os cenários testados. Por isso, o número não deve ser interpretado como uma estimativa geral do ganho esperado em qualquer ambiente de produção.
Custos operacionais e dependências
A estratégia depende de workers de decode com capacidade disponível para absorver parte da carga de prefill por meio do FluidToken. Também depende de a plataforma permitir a mudança de função dos workers em execução sem reinicializar o mecanismo de inferência, como propõe o FluidRole.
Os autores afirmam que a elasticidade in-place melhora o serviço sem provisionar workers adicionais nos cenários estudados. Isso não significa que a estratégia dispense capacidade computacional: é necessário haver folga em algum lugar do sistema para absorver o desequilíbrio, ou ser possível redistribuir a capacidade já existente. O resumo não especifica os limites de elasticidade, o custo da reatribuição nem quanto tempo ela leva. Esses fatores importam, pois uma reação insuficientemente rápida pode deixar o descompasso persistir e prejudicar os SLOs.
Fluxo simplificado do FluidRole
A sequência abaixo resume a ideia de reatribuição descrita no resumo do preprint. Os detalhes operacionais e os critérios de cada etapa não estão especificados no material disponível.
- 01Detectar a pressão sobre prefill e decode por meio de índices de pressão leves.
- 02Identificar um desequilíbrio prolongado que justifique mudar a distribuição de funções.
- 03Reatribuir workers em execução entre as funções de prefill e decode, sem recarregar o modelo nem reiniciar o mecanismo.
- 04Redistribuir o trabalho conforme a nova configuração de funções.
O que falta verificar antes de um uso em produção
O resumo do preprint diz que o FluidPD foi avaliado com traces de cargas de produção do Azure, mas isso não equivale a uma avaliação externa em ambientes independentes nem demonstra que os mesmos resultados se reproduzam em outras cargas. Para avaliar a utilidade operacional, seria importante conhecer os modelos, a plataforma de serving, os padrões de tráfego, as definições de SLO e as condições de comparação usados nos testes completos.
Também é necessário verificar se há código e configurações reproduzíveis, quais são os limites de elasticidade e quais custos acompanham a transferência de cálculo ou a reatribuição de funções. A referência disponível identifica o trabalho como um preprint submetido em 2 de outubro de 2026. O material consultado não confirma revisão por pares nem replicação independente; portanto, os resultados devem ser tratados como afirmações dos autores, e não como conclusões já estabelecidas para produção em geral.
Questões em aberto
- A melhoria de até 94,6 pontos percentuais é um resultado relatado pelos autores no resumo do preprint e não foi verificada independentemente.
- O material disponível não permite confirmar em detalhe a arquitetura e a plataforma de serving avaliadas, nem as métricas de latência, os limites de SLO e todos os comparadores.
- Não estão especificados os limites de elasticidade, o tempo e o custo da reatribuição, nem a disponibilidade de código e configurações reproduzíveis.
- O trabalho é identificado como preprint submetido em 2 de outubro de 2026; o material consultado não confirma revisão por pares ou replicação independente.
Continue a explorar
Fontes consultadas
Correções e transparência
Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.
Propor uma correção