A não determinismo do GPT-4 se deve ao Sparse MoE
(152334H.github.io)- Mesmo com temperature=0, GPT-4 e GPT-3.5-turbo produzem saídas diferentes a cada vez para a mesma entrada, um comportamento incomum que não ocorre em modelos decodificadores densos tradicionais
- Até agora, a causa do não determinismo vinha sendo explicada pela instabilidade das operações de ponto flutuante em CUDA, mas isso, por si só, não explica tudo
- Na estrutura de inferência em lote da arquitetura Sparse MoE, o não determinismo surge quando tokens de sequências diferentes dentro do mesmo lote competem por vagas no buffer dos experts
- Em um experimento com 30 chamadas repetidas, o GPT-4 gerou muito mais saídas únicas do que outros modelos, dando suporte empírico à hipótese
- O ponto central do problema de confiabilidade da API do GPT-4 é que o modelo é determinístico apenas no nível do lote, não no nível da sequência
Formulação do problema — se temperature=0, por que a saída muda a cada vez?
- Já é amplamente sabido que GPT-4/GPT-3.5-turbo são não determinísticos mesmo com temperature=0.0
- Em modelos dense decoder-only, temp=0 significa greedy sampling, o que deveria levar a determinismo total
- Isso porque os logits do próximo token são uma função pura apenas da sequência de entrada e dos pesos do modelo
- Resposta da equipe técnica em uma mesa-redonda de desenvolvedores no OpenAI World Tour
- Em essência: "Sinceramente, nós também estamos confusos. Pode ser um bug do sistema ou o não determinismo dos cálculos otimizados de ponto flutuante"
- Há uma dúvida porque esse comportamento é mencionado desde dois anos atrás e ainda não foi resolvido
- Como a OpenAI, que enfatiza reliability, não teria motivo para manter o não determinismo de propósito, no início a explicação mais plausível era uma limitação de hardware insolúvel
Nova hipótese — uma pista encontrada no artigo sobre Soft MoE
- Uma conexão decisiva foi encontrada na seção 2.2 do artigo Soft MoE
- Sob restrições de capacidade (capacity constraints), todos os métodos Sparse MoE roteiam tokens em grupos de tamanho fixo e forçam ou induzem balanceamento dentro do grupo
- Quando um grupo contém tokens de sequências/entradas diferentes, esses tokens competem entre si por espaços vazios no buffer dos experts
- Como resultado, o modelo é não determinístico no nível da sequência e determinístico apenas no nível do lote, e algumas sequências de entrada influenciam a previsão final de outras entradas
- Já é público que o GPT-4 é um modelo Mixture of Experts
- O GPT-4 foi treinado antes do 2º trimestre de 2022, e Sparse MoE já existia antes disso
- Hipótese central apresentada
- A API do GPT-4 é hospedada em um backend que executa batched inference
- Embora outros fatores também possam ter algum efeito, a maior parte do não determinismo da API decorre do fato de a arquitetura Sparse MoE não conseguir impor determinismo por sequência
Verificação — confirmando que não é um problema de hardware
- Para testar a hipótese, foi solicitado ao próprio GPT-4 que escrevesse um script de teste
- Foram feitas chamadas repetidas com o mesmo prompt e temperature=0 para modelos de chat (gpt-4, gpt-3.5-turbo) e modelos de completion (text-davinci-003/001, davinci-instruct-beta, davinci), contabilizando a quantidade de saídas únicas
- Problemas ocorridos durante a escrita do script
- As respostas da API da OpenAI estavam muito lentas, com quase 10 segundos de atraso até para chamadas ao 3.5 turbo; foi adicionado logging de timestamps para confirmar que não era erro próprio
- Alguns modelos de completion cortavam a resposta cedo demais, então foi aplicado logit bias ao token EOS para corrigir isso
- Não foi possível aplicar um bias equivalente ao token
<|im_end|>(100265) dos modelos de chat; a API retornava erro de chave acima do valor máximo 100257- Como a maioria das completions chegou ao tamanho máximo de tokens e os modelos de chat já eram muito mais não determinísticos, essa limitação foi considerada um problema não essencial
Resultados empíricos
- Saídas únicas (média/30) em 3 tentativas, com N=30 e max_tokens=128
- gpt-4: 12, 11, 12 — média 11,67
- gpt-3.5-turbo: 4, 4, 3 — média 3,67
- text-davinci-003: 3, 2, 4 — média 3,00
- text-davinci-001: 2, 2, 2 — média 2,00
- davinci-instruct-beta: 1, 1, 1 — determinístico, a saída colapsou em um loop repetitivo
- davinci: 1, 1, 1 — determinístico, a saída colapsou em um loop repetitivo
- Resultados com max_tokens=256 antes de descobrir o problema de logit_bias
- gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2
Interpretação dos resultados
- O número de saídas únicas do GPT-4 é anormalmente alto; em saídas longas, ele é praticamente sempre não determinístico
- Outros modelos que não colapsaram em loops repetitivos também apresentaram algum grau de não determinismo, o que é compatível com a alegação pública de que a instabilidade das operações em GPU é uma das causas da aleatoriedade
- Questões em aberto
- Não há uma explicação clara para o motivo de a aleatoriedade aumentar gradualmente de text-davinci-001 para gpt-3.5-turbo
- Não se pode descartar a possibilidade de que o forte não determinismo do GPT-4 se deva simplesmente ao número de parâmetros, e não ao MoE; no entanto, o fato de o Turbo, mais rápido, ser mais não determinístico que o davinci contraria essa explicação
Implicações
Estamos muito atrasados
- Se o não determinismo é uma característica inerente à batched inference do Sparse MoE, isso deveria parecer óbvio para quem trabalha na área
- O fato de a maioria dos usuários do GPT-4 não saber a causa da instabilidade da API sugere que a hipótese está errada, ou que há tão poucas pessoas que entendem modelos MoE que essa explicação não se tornou pública
- A Google Deepmind sabia disso e tratou o tema como algo trivial a ponto de mencioná-lo em uma frase de passagem no artigo, o que dá mais motivos para otimismo em relação à Deepmind do que a outras organizações que lidam apenas com modelos densos
O GPT-3.5-Turbo também pode ser MoE
- Há rumores de que o 3.5-turbo compartilha a mesma arquitetura do GPT-4, mas com muito menos parâmetros
- A situação atual, em que são necessários 70B parâmetros para atingir o desempenho do Turbo, é difícil de explicar com um único modelo denso, considerando a escala de tráfego e a velocidade que a OpenAI processa
- O Turbo é o único outro modelo da API em que logprobs é limitado e não público
- A explicação existente era impedir o aumento da precisão em distillation, mas casos como Orca enfraquecem essa justificativa
- O fato de a OpenAI ter anunciado publicamente que está trabalhando na integração de logprobs ao ChatCompletions dá mais peso à interpretação de que o problema é "inerentemente aleatório demais, tornando a engenharia estável difícil", em vez de "impedir distillation"
Conclusão
- É fato conhecido que os modelos GPT da OpenAI são não determinísticos com temperature=0
- A causa geralmente apontada é a imprecisão das operações otimizadas de ponto flutuante em CUDA
- Hipótese alternativa apresentada: a batched inference em modelos Sparse MoE é a causa fundamental do não determinismo da API do GPT-4, uma hipótese mais elegante que a explicação existente
- Foi demonstrado empiricamente que chamadas à API do GPT-4 (e de alguns modelos 3.5) são muito mais não determinísticas do que outros modelos da OpenAI
- Com base em velocidade, não determinismo e remoção de logprobs, estima-se que o GPT-3.5-turbo também possa ser MoE
1 comentários
Opiniões do Hacker News
Erros de ponto flutuante normalmente são determinísticos, então, se você rodar o mesmo cálculo duas vezes, o resultado deveria ser idêntico até o nível de bits
Os resultados só divergem quando há algum outro estado ou fonte de entropia, como buffers que não foram inicializados corretamente com zero, condições de corrida ou flags de modo de arredondamento que não foram definidos de forma consistente
Vendo a qualidade do código feito às pressas no ecossistema de AI/ML, parece provável que todas essas três coisas — e talvez mais — estejam acontecendo
Nesse caso, por causa do paralelismo da GPU, a ordem em que os números são somados é não determinística, e o resultado pode variar um pouco
É melhor evitar desmerecer o código dos outros quando se trata de código escrito sobre sistemas que você não conhece bem
CPUs também podem passar por isso por causa do processamento paralelo, mas a maioria das instruções individuais de CPU é determinística, enquanto CUDA oferece operações primitivas não determinísticas
Isso é um projeto intencional, porque elas são mais rápidas que suas equivalentes determinísticas; o problema é ter apresentado isso como se fosse um bug causado por código ruim
Por exemplo, algumas operações de ponto flutuante, como adição ou multiplicação, não obedecem à propriedade associativa; por isso, o resultado muda conforme a ordem de execução que conclui uma redução (reduction)
Em situações paralelas, algumas implementações tornam a ordem de redução não determinística por motivos de desempenho, e assim o resultado final também se torna não determinístico
Uma simples chamada a
GetTimeOfDay()já basta, e o drift da frequência de clock entre vários processadores também pode causar issohttps://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
Não sei se entendi corretamente o trecho do artigo citado
Isso quer dizer que parte da inferência mais eficiente depende de misturar tokens de entradas totalmente separadas, por exemplo entradas de outros usuários? E que a proporção de alocação dos “especialistas” muda conforme as outras entradas que, por acaso, caíram no mesmo lote, alterando também a conclusão final?
Se for isso, além de simplesmente introduzir não determinismo, a qualidade da resposta também pode depender do número de requisições simultâneas competindo pela mesma alocação de especialistas
Por exemplo, a parte do sistema que é boa em tradução/interpretação de hindi pode produzir resultados piores durante o horário de pico na Índia, quando há mais entradas competindo simultaneamente pela mesma capacidade
Isso também poderia ser outra explicação para a sensação de que a qualidade caiu com o tempo. Antes, um determinado teste podia passar de forma estável porque havia pouca congestão nos especialistas relevantes; agora, com mais uso simultâneo, o mesmo teste talvez não consiga obter esforço suficiente daquele especialista
Também pode surgir uma armadilha em que, se um subespecialista se mostra inicialmente impressionante em uma área específica, o uso nessa área aumenta, e, por causa da nova congestão, os usos imitativos deixam de receber a mesma alocação de especialistas, reduzindo aquele desempenho inicialmente impressionante
Se o efeito for forte e a OpenAI souber disso sem divulgar, isso poderia ser visto como um tipo de isca: atrair usuários com a excelência não representativa de um sistema Mixture-of-Experts inicialmente sem congestão e depois entregar resultados de qualidade inferior em um sistema mais congestionado
Talvez os lotes estejam sendo agrupados de formas diferentes. Ao dividir um lote de 10 em 2 grupos de 5, a resposta muda dependendo de meu prompt cair no primeiro ou no segundo grupo; se ele estiver na mesma posição dentro do lote, você obtém a mesma resposta
Com o mesmo lote, isto é, com as mesmas sequências e a mesma ordem, o lote inteiro é determinístico; mas, ao embaralhar o lote, essa determinismo se perde
Mesmo hoje, a confiabilidade é um dos principais obstáculos à adoção ampla de LLMs em muitos fluxos de trabalho críticos
Se o rumor de que o GPT-4 é intrinsecamente não determinístico e instável for verdadeiro, para a maioria das empresas é melhor fazer fine-tuning de um LLM open source com desempenho semelhante para um domínio específico
Modelos especializados por domínio sempre terão desempenho melhor que modelos de uso geral, então essa alternativa também traz mais ganho de desempenho
Se o GPT-3.5 for um modelo MoE, isso não é um sinal bastante esperançoso para o campo open source?
Se surgir um bom modelo MoE open source, talvez na forma de uma variação dos modelos decodificadores existentes, isso significaria que dá para fazer muito mais com muito menos recursos
Não sei se modelos MoE precisam ser treinados do zero
Formas de reduzir a proporção FLOPs:memória, como Soft MoE, também podem tornar a inferência em CPUs, ou pelo menos em Apple Silicon, mais relevante
Se as sequências dentro de um lote podem afetar o roteamento umas das outras, isso dá a impressão de abrir a possibilidade de ataques por canal lateral estranhos e difíceis de implementar
Trabalho realmente excelente. Eu vinha sendo fortemente contra MoE por vários motivos, mas é a primeira vez que vejo evidências convincentes, em vez de posts no Substack ou repetição de boatos
Eu não fazia a menor ideia de que o GPT-4 era não determinístico, e o uso cerca de 2 horas por dia
Dá para entender por que é difícil perceber com uma olhada superficial. Na memória, a “sensação” é parecida e ele usa muito vocabulário semelhante, mas o formato é completamente diferente, e algumas palavras-chave são iguais enquanto outras mudam como se fossem expressões sinônimas
Nos exemplos do gist linkado, as saídas não determinísticas são realmente parecidas: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
Como a aleatoriedade deveria ser limitada, essa parte ao menos não surpreende
Acho que a OpenAI um dia vai encontrar uma forma de reduzir essa aleatoriedade. Ainda mais porque há uma promessa pública de adicionar logprobs de volta ao ChatCompletions
Se for desenvolvendo um programa fazendo chamadas repetidas à API com a mesma entrada, é difícil deixar passar a não determinismo
Tenho interesse em saber quais insights alguém que usa tanto assim teve, incluindo o pacote de recursos lançado esta semana
MoE significa Mixture of Experts, ou seja, mistura de especialistas
Lá pelo meio do texto eles quase por acaso expandem a sigla, mas o público pretendido parece ser quem conhece mistura de especialistas, e eu não estava nesse grupo
Os modelos davinci-instruct-beta do GPT-3.0 já retornavam logprobs não determinísticos desde o início de 2021
Isso é especulação, e o próprio CUDA também tem bugs frequentes de não determinismo
text-davinci-001etext-davinci-002foram treinados com FeedMe e SFT, etext-davinci-003foi com RLHFO próprio modelo também tem variância maior em temperaturas altas
davinciecode-davinci-002?Se “esses tokens muitas vezes competem entre si pelos lugares disponíveis no buffer de especialistas”, será que é por isso também que, quando peço código longo, o ChatGPT frequentemente coloca apenas placeholders no lugar das funções?
“Esses tokens muitas vezes competem entre si pelos lugares disponíveis no buffer de especialistas”; então isso significa que os resultados mudam quando a carga está alta?
Será que a sensação de que a qualidade da saída varia às vezes também pode ser explicada por carga alta?
MoE significa Mixture of Experts