O que mudou quando dividimos as piscinas
Fizemos uma prova de conceito de duas semanas. Dividi o cluster em dois swimming pools: oito GPUs dedicadas ao processamento imediato e as GPUs restantes que lidam com a geração de tokens. Nenhum novo {hardware}, nenhum novo cluster – apenas uma mudança de configuração na camada de serviço e uma política de roteamento que enviava cada solicitação ao pool certo com base em sua fase de inferência. O pool de processamento de immediate atingiu de 90 a 95% de utilização de computação de forma consistente porque foi tudo o que fez. Nenhuma geração de token competindo por slots de agendamento. Nenhuma solicitação de decodificação ficou ociosa enquanto uma explosão de pré-preenchimento sobrecarregava os núcleos.
O pool de geração de tokens foi a maior surpresa. Ao agrupar centenas de solicitações de decodificação simultâneas, as leituras de memória foram amortizadas em mais trabalho. A utilização da largura de banda subiu acima de 70% – muito melhor do que os 30% que víamos quando as solicitações de decodificação eram intercaladas com pré-preenchimento na mesma GPU. A eficiência geral da computação praticamente dobrou.
A matemática do custo seguiu. O cliente estava gastando cerca de US$ 2 milhões anualmente em horas de GPU de inferência. Após a desagregação, eles estavam no caminho certo para reduzir esse valor em US$ 600 a 800 mil, ao mesmo tempo em que atendiam ao mesmo quantity de solicitações com as mesmas metas de latência. Nenhum novo {hardware} adquirido. Mesmas GPUs, mesmo cluster, mesmos pesos de modelo – arquitetura diferente.