De parceiros analíticos a parceiros de inferência em tempo actual
Superhuman, a plataforma de produtividade que inclui Superhuman, Coda, Superhuman Mail e Superhuman Go, atende mais de 40 milhões de usuários diários em dezenas de idiomas. A assistência de comunicação de IA do Superhuman fornece sugestões em tempo actual de correção, clareza, tom e estilo em todas as superfícies onde as pessoas escrevem.
Databricks e Superhuman são parceiros há anos. A equipe Superhuman tem usado historicamente a plataforma Databricks Knowledge Intelligence como base para análises. Mas a análise period apenas metade do cenário.
Por trás de muitas das sugestões em tempo actual do Superhuman está um modelo de IA personalizado e altamente sofisticado, servido em grande escala. Superhuman executa esse modelo com tráfego de pico de mais de 200.000 consultas por segundo, com latência ponta a ponta inferior a 1 segundo em P99 e garantias estritas de confiabilidade 4 9. A Superhuman modernizou sua pilha de serviços para grandes modelos de linguagem, aproveitando o serviço de modelos Databricks, o que exigia um novo tipo de parceria, baseada em produtos conjuntos e trabalho de engenharia.
Como Superhuman modernizou sua pilha de serviços
Antes dessa migração, a Superhuman operava uma pilha de serviços DIY construída em vLLM, juntamente com ferramentas internas para treinamento e gerenciamento de modelo. Uma equipe interna de infraestrutura de ML mantinha essa pilha, que suportava uma escala enorme, mas vários pontos problemáticos aumentavam ao servir grandes modelos de linguagem.
O modelo personalizado de linguagem grande permite a correção de erros gramaticais em um quantity enorme, pico de 200 mil+ QPS com aproximadamente 50 tokens de entrada e 50 tokens de saída por solicitação. Ele estava ultrapassando os limites do que a pilha baseada em GPU L40S poderia oferecer. Cada nova iteração do modelo exigia meses de ajuste guide de desempenho integrado. Enquanto isso, a carga operacional crescia, com o planejamento de capacidade, o ajuste de desempenho e o escalonamento automático consumindo tempo de uma equipe enxuta que precisava se concentrar na qualidade do modelo e nas inovações de produtos.
A Superhuman precisava de um parceiro de plataforma que pudesse se comprometer com SLAs de desempenho e latência na pilha de serviços e que co-investisse na engenharia necessária para atendê-los. Ambas as equipes definiram antecipadamente SLOs de latência em tempo actual: latência p99 abaixo de um segundo e regressão de qualidade zero nos equipamentos de avaliação interna da Superhuman.
Cumprindo SLAs em tempo actual na infraestrutura da plataforma
Atingir metas de latência em um único pod é necessário, mas não suficiente. Atender mais de 200 mil QPS de maneira confiável requer infraestrutura que possa equilibrar a carga, escalar dinamicamente e absorver picos. Fazer isso da maneira certa exigiu uma colaboração estreita entre as duas equipes.
Otimizando o balanceamento de carga: opções de potência de dois
O tráfego de endpoint de correção gramatical do Superhuman exibe fortes padrões diurnos com rampas rápidas em determinados períodos, muitas vezes excedendo 200 mil QPS. Embora o balanceador de carga spherical robin padrão do Kubernetes seja suficiente em QPS baixos, nossos testes revelaram que esse desempenho diminui em QPS mais altos, com distribuição desigual de solicitações criando pontos de acesso que aumentam a latência closing.
No centro de nossa abordagem está o Endpoint Discovery Service (EDS) — um plano de controle leve que monitora continuamente a API do Kubernetes em busca de alterações em serviços e EndpointSlices. O EDS conduz um algoritmo de balanceamento de carga personalizado baseado no poder de duas opções (citação). Para cada solicitação, dois pods candidatos são amostrados e o tráfego é roteado para aquele que tiver menos solicitações ativas, evitando os pontos de acesso que o round-robin cria em QPS altos (consulte weblog).
Para manter a plataforma com ótimo custo-benefício para padrões de tráfego variáveis, o sistema é dimensionado automaticamente de acordo com a demanda do cliente. O escalonador automático rastreia request_concurrency média entre pods, com metas de simultaneidade por pod derivadas do benchmarking de RPS máximo sustentável por réplica. A estratégia de dimensionamento é intencionalmente assimétrica: o aumento de escala é agressivo e responsivo, enquanto a redução de escala é conservadora, para evitar oscilações que causam picos de latência. Por meio de testes de sombra conjuntos entre Superhuman e Databricks, detectamos casos extremos e corrigimos problemas ao ajustar parâmetros no escalonador automático, incluindo quando dimensionar agressivamente, quando manter a estabilidade e quão conservador deve ser na redução de escala.
Otimizando a inicialização do contêiner por meio da aceleração de imagem
Quando o tráfego do endpoint Superhuman aumenta de fora de pico para pico, o escalonador automático precisa adicionar dezenas de pods. Se cada pod levar mais de alguns minutos para extrair a imagem do contêiner e iniciar, os usuários experimentarão picos de latência durante a rampa. A redução do tempo de início do pod se traduz diretamente em aumento de escala mais rápido e latência mais suave durante picos de tráfego.
A equipe de atendimento do modelo Databricks adotou o trabalho de aceleração de imagem originalmente criado para computação sem servidor (weblog) para evitar partidas a frio. A abordagem se adapta bem aos modelos relativamente pequenos que servimos para Superhuman.
Ao construir uma imagem de contêiner, adicionamos uma etapa additional para converter o formato de imagem padrão baseado em gzip para o formato baseado em dispositivo de bloco adequado para carregamento lento. Isso permite que a imagem do contêiner seja representada como um dispositivo de bloco pesquisável com setores de 4 MB em produção.
Ao extrair imagens de contêiner, nosso tempo de execução de contêiner personalizado recupera apenas os metadados necessários para configurar o diretório raiz do contêiner, incluindo estrutura de diretório, nomes de arquivos e permissões, e cria um dispositivo de bloco digital de acordo. Em seguida, ele monta o dispositivo de bloco digital no contêiner para que o aplicativo possa começar a ser executado imediatamente.
Quando o aplicativo lê um arquivo pela primeira vez, a solicitação de E/S no dispositivo de bloco digital emitirá um retorno de chamada para o processo de busca de imagens, que recupera o conteúdo actual do bloco do registro do contêiner remoto. O conteúdo do bloco recuperado também é armazenado em cache localmente para evitar repetidas viagens de ida e volta da rede ao registro do contêiner, reduzindo o impacto da latência variável da rede em leituras futuras.
Esse sistema de arquivos de contêiner de carregamento lento elimina a necessidade de baixar toda a imagem do contêiner antes de iniciar o aplicativo, reduzindo o tempo de inicialização do contêiner de vários minutos para apenas alguns segundos.
Otimizações de tempo de execução: 60% mais rendimento por pod
Com a camada de plataforma lidando com a escala no nível da frota, a próxima questão period quantos QPS cada pod poderia suportar e a que custo.
Nesta seção, apresentamos as otimizações que aumentaram o rendimento por pod de 750 QPS para 1.200 QPS em GPUs H100, uma melhoria de 60%, mantendo regressões de qualidade zero.
Quantização FP8
A quantização do FP8 foi a maior melhoria de rendimento, alcançando um aumento de até 30% no QPS por pod.
A equipe de ML da Superhuman pré-quantizou o ponto de verificação para o FP8 usando a biblioteca de quantização on-line do vLLM, produzindo um ponto de verificação em formato tensor compactado que o Databricks carregou para servir. Na configuração closing, as projeções de atenção (Q, Okay, V e saída) e as projeções MLP percorreram o caminho FP8, enquanto a quantização do cache KV foi deixada desativada, uma vez que a quantização de peso period de onde vinham os ganhos de rendimento e a quantização do cache KV introduziu suas próprias compensações de qualidade que não valiam a pena buscar para essa carga de trabalho.
Antes de definir a configuração closing, ambas as equipes iteraram sobre quais camadas quantificar. As projeções MLP foram quantizadas desde o início, e a questão em aberto period se deveria quantizar as camadas de atenção. O serviço de modelo do Databricks projetou o mecanismo de serviço para suportar inferência de precisão híbrida desde o início, de modo que, se algum grupo de camadas se mostrasse muito sensível à qualidade sob quantização, poderíamos mantê-lo com maior precisão sem alterar a arquitetura geral de serviço. Enviamos um sinalizador que nos permitiu ativar e desativar a quantização da atenção, para que ambas as equipes pudessem medir seu impacto diretamente. O experimento caiu de forma limpa, quantizando o Q/Okay/V e as projeções de saída não produziram degradação mensurável da qualidade nas avaliações do Superhuman.
A outra consideração foi a granularidade da quantização. Kernels prontos para uso usavam escala por tensor (um único fator de escala FP8 para um tensor de peso inteiro). Os kernels do Databrick usam escalonamento por canal, calculando um fator de escala separado por canal de saída de cada camada linear. Isso preserva a faixa dinâmica onde é importante e mantém o erro de quantização da camada MLP bem abaixo do limite onde aparece nas avaliações. Combinada com melhorias no nível do kernel, a quantização por canal correspondeu ou excedeu outras linhas de base de código aberto com o mesmo rendimento.
Eliminando gargalos no lado da CPU
Para modelos pequenos e rápidos, o desempenho geralmente é prejudicado pela CPU – e não pela GPU. A equipe do Databricks já havia investigado a eliminação de gargalos de CPU em seu trabalho em serviço PEFT rápido e aqui aplicou otimizações de CPU semelhantes diretamente à carga de trabalho do Superhuman.
Especificamente, a equipe introduziu um servidor de tempo de execução de multiprocessamento. Para a maioria das cargas de trabalho de atendimento de modelo, um único processo é mais do que rápido o suficiente para manter a GPU saturada, já que a GPU é o gargalo, não a CPU. Mas com um modelo pequeno e rápido, a GPU completa seu avanço mais rápido do que um único processo pode preparar o próximo lote, transferindo o gargalo para a CPU.
A equipe resolveu isso executando vários processos de servidor RPC. Ao fazer com que vários processos de CPU preparassem e despachassem trabalho para a GPU em paralelo, eliminamos o gargalo de serialização de processo único. Isso proporcionou mais 20% de rendimento adicional.
Outras otimizações do lado da CPU melhoraram o desempenho em alguns pontos percentuais.
- Sobrecarga reduzida do Python. Substituímos o fatiamento, cópia e preenchimento do tensor no nível Python no início de cada etapa de decodificação do gráfico CUDA por uma única chamada C++. Também exploramos estratégias paralelas (ThreadPool, OpenMP), mas C++ de thread único foi ideally suited devido à sobrecarga de sincronização CUDA. Isso reduziu ligeiramente a inatividade da GPU por passagem direta.
- Agendamento assíncrono para melhor sobreposição de trabalho CPU-GPU. Movemos o pós-processamento do lado da CPU para fora do caminho crítico para que ele seja executado simultaneamente com o próximo avanço da GPU. Em vez de terminar todo o pós-processamento do lote N antes de lançar o lote N+1, o escalonador despacha N+1 imediatamente e trata do pós-processamento de N em paralelo. O pós-processamento também itera apenas no subconjunto relevante de solicitações, e não no lote completo. Isso resultou no próximo passe para frente começando mais cedo.
O que vem a seguir
Este trabalho é a base para uma parceria mais ampla. Superhuman agora está migrando modelos adicionais para Databricks, abrangendo diferentes tamanhos de modelo, tipos de tarefas e requisitos de latência – e adotando a AI Platform de forma mais ampla para fluxos de trabalho de treinamento, rastreamento de experimentos, avaliações (ML clássico, Deep-Studying e AI/Agentes generativos), modelo e (LLM) julga registro e ingestão de rastreamentos de agente em escala.
Construir esta plataforma em grande escala foi um esforço de ambas as partes e uma experiência de aprendizagem extraordinária. Muito obrigado às equipes de ML e infraestrutura da Superhuman pela profunda colaboração, pela disposição de iterar abertamente em compensações difíceis e pelo rigor que trouxeram a cada barra de qualidade e teste de carga. O guide de engenharia que construímos juntos é tanto deles quanto nosso, e estamos entusiasmados em trazer o mesmo nível de parceria para cada carga de trabalho que se segue.
Principais conclusões
Usar um serviço de inferência gerenciado não significa abrir mão do controle. Superhuman mantém whole propriedade do treinamento de modelo, quantização e padrões de qualidade, enquanto Databricks mantém o desempenho do tempo de execução e a confiabilidade da plataforma. Esta divisão de responsabilidades funciona bem com SLOs partilhados, validação conjunta de qualidade e testes de carga progressivos durante a integração na plataforma Databricks.
Pronto para servir seus modelos personalizados em grande escala? Saiba como a API do Databricks Basis Mannequin pode atender aos seus SLAs de inferência mais exigentes — e oferecer à sua equipe um verdadeiro parceiro de engenharia, não apenas um serviço gerenciado. Contate-nos em https://www.databricks.com/firm/contact para integrar seu caso de uso de serviço de modelo de alto QPS.