Think Before You Grid-Search: Floor-First Triage for LLM Serving

Resumo Técnico: Triagem de Prioridade de Piso (Floor-First Triage) para Servimento de LLM

Declaração do Problema
Equipes de produção que otimizam o servimento de Grandes Modelos de Linguagem (LLMs) enfrentam um vasto espaço de configuração envolvendo layouts de paralelismo (TP, EP, DP), batching, quantização e trabalho em nível de kernel. A resposta operacional predominante para metas de latência não atingidas é realizar benchmarks de inúmeras configurações e implantar profilers pesados (ex: Nsight Systems) indiscriminadamente. Essa abordagem frequentemente degenera em uma busca em grade (grid search) ineficiente, onde os números de desempenho medidos são ambíguos: um TPOT (Tempo por Token de Saída) lento pode decorrer de limites fundamentais de largura de banda, lacunas de implementação, comunicação exposta, overhead de host ou kernels subperformantes. O artigo argumenta que a comunidade de engenharia carece de um procedimento de decisão sistemático para determinar quando a profilagem é justificada e onde olhar primeiro, levando a escolhas de implantação imprevisíveis (ex: estratégias de paralelismo conflitantes para modelos DeepSeek em hardware idêntico) baseadas em folclore em vez de contabilidade explícita de recursos.

Metodologia: Triagem de Prioridade de Piso (Floor-First Triage)
O artigo propõe o "Floor First", um fluxo de trabalho de triagem baseado em resíduos que trata a estimativa analítica como a camada primária de profilagem. A metodologia consiste em quatro estágios distintos:

1. Construção do Piso Analítico: Antes de qualquer benchmark, o sistema computa um "piso de dois lados" para uma determinada configuração. Este modelo trata cada etapa de decodificação como um vetor de recursos de cinco dimensões: bytes de HBM, FLOPs, bytes de rede, mensagens de rede e capacidade de KV.

   • Piso Otimista ($t_{opt}$): Calculado como o máximo de tempos de recursos independentes ($max(t_{HBM}, t_{compute}, t_{network})$), assumindo sobreposição perfeita.
   • Piso Pessimista ($t_{sum}$): Calculado como a soma de todos os tempos de recursos ($t_{HBM} + t_{compute} + t_{network}$), assumindo nenhuma sobreposição.
   • Intervalo Diagnóstico: A posição de um benchmark medido dentro do intervalo $[t_{opt}, t_{sum}]$ serve como um diagnóstico de custo zero para a sobreposição do sistema. Se a medição estiver próxima de $t_{opt}$, a sobreposição é boa; se estiver próxima de $t_{sum}$, o escalonamento/sobreposição é o gargalo; se estiver acima de $t_{sum}$, o tempo está vazando para custos não modelados (gaps de host, stragglers).

2. Disciplina de Benchmark: Os benchmarks devem ser conduzidos sob regras estritas: geração de carga de loop aberto (para evitar viés de auto-estrangulamento), distribuições de comprimento realistas, operação em estado estacionário e reporte de percentil de cauda (P99).

3. Reconciliação e Triagem: O tempo medido é comparado com o piso.

   • Resíduo Pequeno (< 1.3× o piso): A investigação para. O sistema está próximo do limite teórico para aquele eixo; otimizações adicionais exigem a mudança da arquitetura (ex: atenção esparsa, quantização) em vez de ajuste de kernels.
   • Resíduo Grande: A profilagem é escalonada. O Nsight Systems é usado apenas para responder a três perguntas específicas: Existem lacunas entre os kernels? A comunicação está exposta? Qual classe de kernel excede seu orçamento analítico? O Nsight Compute é reservado estritamente para classes de kernel que excedem seu orçamento após outras causas serem excluídas.

4. Ordenação de Parede (Wall Ordering): Em vez de comparar a latência de lote único, as implantações são avaliadas pela "ordenação de parede" — determinando qual restrição de recurso (capacidade de KV, largura de banda de KV, largura de banda de peso ou computação) vincula primeiro conforme a carga aumenta. A capacidade é tratada como uma dimensão de recurso de primeira classe, não como uma verificação de memória post-hoc.

Principais Contribuições

1. Fluxo de Trabalho de Triagem Baseado em Resíduos: Um loop de decisão que separa a definição de alvo, construção do piso e escalonamento de profiler, com regras de parada explícitas que direcionam os esforços de otimização para trabalho de pipeline (layout/escalonamento) ou trabalho de kernel.
2. Modelo de Piso de Dois Lados: Um modelo analítico que fornece limites otimistas e pessimistas, usando a lacuna entre eles para diagnosticar a eficiência de sobreposição sem executar um profiler.
3. Ordenação de Parede como Saída: Um método para comparar alternativas de implantação baseando-se em qual "parede" de recurso vincula primeiro conforme a concorrência cresce, revelando que um layout com pior latência de lote único pode dominar a fronteira de goodput se tiver uma parede de capacidade mais alta.
4. Disciplina de Métrica: Uma sistematização das métricas de utilização (MFU vs. MBU) baseada na "identidade da crista" ($MFU/MBU = I_{work}/I_{ridge}$), garantindo que a métrica correta seja reportada para o recurso que está vinculando.
5. Artefato e Habilidade de Agente: Um artefato Python sem dependências (floor.py) e uma habilidade legível por agentes (SKILL.md) que impõem essa disciplina em loops de otimização agênticos, evitando que agentes recorram reflexivamente a profilers.

Resultados do Estudo de Caso
O artigo aplica esta metodologia a um modelo MoE do tipo DeepSeek-V3.2 de 671B em 16 GPUs NVIDIA H20.

• Caracterização de Hardware: A GPU H20 é identificada como tendo um ponto de crista de ~74 FLOP/byte (vs. ~590 para H100), tornando-a uma peça extrema "orientada para decodificação", onde a região limitada por memória é 8× mais larga.
• Julgamento de Layout:
  • TP16: Com tamanho de lote 64 e contexto de 8K, o TP16 é limitado pela capacidade de KV a ~70 requisições simultâneas. O termo de largura de banda de KV é significativo, e a parede de computação é inalcançável dentro da região viável.
  • EP16 + DP Attention: Este layout troca um tráfego de peso ligeiramente pior por uma parede de capacidade de ~644 requisições (um fator de ordem de magnitude maior). Embora o TP16 tenha menor latência de fluxo único (2.4× mais rápido em B=1), o EP16+DP domina a fronteira de goodput de alta concorrência.
  • Atenção Esparsa (DSA): Remove a parede de largura de banda de KV, mas não a parede de capacidade, pois o KV completo deve permanecer endereçável.
• Resolução de Desacordo: O estudo explica por que diferentes equipes implantaram layouts opostos (TP vs. DP) no mesmo hardware: a escolha ideal é uma função computável do ponto de operação (concorrência). Alta concorrência favorece DP; baixa concorrência favorece TP.

Significância e Alegações
O artigo afirma que os desacordos de produção em servimento de LLM são frequentemente previsíveis a partir de uma pequena contabilidade de recursos (cinco números por GPU mais as dimensões do modelo), em vez de exigir experimentação extensiva. Ao tornar essa contabilidade sistemática, o fluxo de trabalho fornece um procedimento de triagem geral que:

• Evita esforço de profilagem desperdiçado quando as medições estão próximas do piso analítico.
• Identifica o eixo de otimização correto (pipeline vs. kernel) antes que ferramentas caras sejam engajadas.
• Explica escolhas de implantação através de "ordenação de parede" em vez de benchmarks pontuais.
• Oferece um método robusto para hardware com características extremas (como a H20) onde heurísticas padrão falham.

Os autores observam modestamente que o rascunho atual depende de pisos analíticos e constantes calibradas, com uma campanha de medição planejada (Seção 8) necessária para validar empiricamente os limiares de resíduo e as regras de escalonamento. O método é apresentado como um procedimento de decisão para engenharia, não como um substituto para simuladores ou profilers, que permanecem essenciais para resíduos que sobrevivem à verificação do piso.