- Incluso con temperature=0, GPT-4 y GPT-3.5-turbo generan salidas distintas cada vez para la misma entrada, un comportamiento inusual que no ocurre en los modelos densos de decodificador existentes
- Hasta ahora, la causa de la no determinación se ha explicado como inestabilidad de las operaciones de punto flotante en CUDA, pero eso por sí solo no basta para explicarla
- En la estructura de inferencia por lotes de una arquitectura Sparse MoE, la no determinación surge cuando tokens de distintas secuencias dentro del mismo lote compiten por lugares en el búfer de expertos
- En un experimento de 30 llamadas repetidas, GPT-4 generó una cantidad abrumadoramente mayor de salidas únicas que otros modelos, lo que respalda empíricamente la hipótesis
- El punto de que el modelo es determinista solo a nivel de lote, no a nivel de secuencia, es la causa central del problema de confiabilidad de la API de GPT-4
Planteamiento del problema: si temperature=0, ¿por qué la salida cambia cada vez?
- Que GPT-4/GPT-3.5-turbo sean no deterministas incluso con temperature=0.0 ya es un hecho ampliamente conocido
- En modelos densos decoder-only, temp=0 significa greedy sampling, lo que debería llevar a una determinación completa
- Esto se debe a que los logits del siguiente token son una función pura de la secuencia de entrada y de los pesos del modelo
- Respuesta del equipo técnico en una mesa redonda para desarrolladores del OpenAI World Tour
- En esencia: “Francamente, nosotros también estamos confundidos. Podría ser un bug del sistema o no determinación en cálculos optimizados de punto flotante”
- Hay dudas porque este comportamiento se menciona desde hace 2 años y aun así no se ha resuelto
- Como OpenAI enfatiza la reliability, no tendría motivo para mantener deliberadamente la no determinación; por eso, al principio, la explicación más plausible se consideró una limitación de hardware imposible de resolver
Nueva hipótesis: una pista encontrada en el paper de Soft MoE
- En la sección 2.2 del paper de Soft MoE se encontró un vínculo determinante
- Bajo restricciones de capacidad (capacity constraints), todos los enfoques Sparse MoE enrutan tokens en grupos de tamaño fijo y fuerzan o inducen equilibrio dentro del grupo
- Cuando un grupo contiene tokens de distintas secuencias/entradas, esos tokens compiten entre sí por los espacios libres del búfer de expertos
- Como resultado, el modelo es no determinista a nivel de secuencia y determinista solo a nivel de lote, y algunas secuencias de entrada influyen en la predicción final de otras entradas
- Que GPT-4 sea un modelo Mixture of Experts ya es un hecho público
- GPT-4 fue entrenado antes del segundo trimestre de 2022, y Sparse MoE ya existía desde antes
- Hipótesis central planteada
- La API de GPT-4 está alojada en un backend que realiza inferencia por lotes
- Aunque otros factores también pueden influir en parte, la mayor parte de la no determinación de la API proviene de que la arquitectura Sparse MoE no puede imponer determinación por secuencia
Validación: comprobar que no es un problema de hardware
- Para validar la hipótesis, se le pidió directamente a GPT-4 que escribiera un script de prueba
- Llamadas repetidas con el mismo prompt y temperature=0 a modelos de chat (gpt-4, gpt-3.5-turbo) y modelos de completion (text-davinci-003/001, davinci-instruct-beta, davinci), contabilizando la cantidad de salidas únicas
- Problemas surgidos al escribir el script
- Las respuestas de la API de OpenAI eran muy lentas, con casi 10 segundos de demora incluso para llamadas a 3.5 turbo; se agregó logging de timestamps para confirmar que no era un error propio
- Algunos modelos de completion cortaban la respuesta demasiado pronto, por lo que se corrigió aplicando logit bias al token EOS
- No fue posible aplicar un bias equivalente al token
<|im_end|>(100265) de los modelos de chat, ya que la API devolvía un error de clave por superar el valor máximo 100257- Como la mayoría de las completions alcanzaban la longitud max token y los modelos de chat ya eran mucho más no deterministas, se consideró que esta restricción no era un problema central
Resultados empíricos
- Salidas únicas en 3 intentos, con N=30 y max_tokens=128 (promedio/30)
- gpt-4: 12, 11, 12 — promedio 11.67
- gpt-3.5-turbo: 4, 4, 3 — promedio 3.67
- text-davinci-003: 3, 2, 4 — promedio 3.00
- text-davinci-001: 2, 2, 2 — promedio 2.00
- davinci-instruct-beta: 1, 1, 1 — determinista, la salida colapsó en un bucle repetitivo
- davinci: 1, 1, 1 — determinista, la salida colapsó en un bucle repetitivo
- Resultados con max_tokens=256 antes de descubrir el problema de logit_bias
- gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2
Interpretación de los resultados
- La cantidad de salidas únicas de GPT-4 es anormalmente alta; en salidas largas, en la práctica casi siempre es no determinista
- Otros modelos que no colapsaron en bucles repetitivos también presentan cierto nivel de no determinación, lo que coincide con la afirmación pública de que la inestabilidad de las operaciones en GPU es una causa de parte de la aleatoriedad
- Preguntas pendientes
- No hay una explicación clara de por qué la aleatoriedad aumenta gradualmente desde text-davinci-001 hasta gpt-3.5-turbo
- No se puede descartar que la fuerte no determinación de GPT-4 se deba simplemente a la cantidad de parámetros y no a MoE; sin embargo, que Turbo, más rápido, sea más no determinista que davinci contradice esa explicación
Implicaciones
Estamos demasiado atrasados
- Si la no determinación es una característica inherente de la inferencia por lotes de Sparse MoE, debería ser algo obvio para quienes trabajan en el área
- El hecho de que la mayoría de los usuarios de GPT-4 no conozca la causa de la inestabilidad de la API sugiere que la hipótesis es incorrecta, o que hay muy poca gente que entienda los modelos MoE como para que esta explicación se haya vuelto parte del debate público
- Google Deepmind lo sabía y lo trató como algo tan trivial que lo mencionó de pasada en una frase de un paper; esto da motivos para ser más optimistas sobre Deepmind que sobre otras organizaciones que solo trabajan con modelos densos
GPT-3.5-Turbo también podría ser MoE
- Existe el rumor de que 3.5-turbo comparte la misma arquitectura que GPT-4, pero con muchos menos parámetros
- La situación actual, en la que se necesitan 70B parámetros para alcanzar el rendimiento de Turbo, es difícil de explicar con un único modelo denso si se considera la escala de tráfico y la velocidad que maneja OpenAI
- Turbo es el único otro modelo de la API donde logprobs está restringido y no es público
- La explicación existente era impedir un aumento en la precisión de la distillation, pero casos como Orca la vuelven menos convincente
- El hecho de que OpenAI haya anunciado públicamente que está trabajando en integrar logprobs en ChatCompletions da más peso a la interpretación de que “es intrínsecamente demasiado aleatorio y resulta difícil de ingeniar de forma estable”, por encima de “prevenir distillation”
Conclusión
- Es un hecho conocido por todos que los modelos GPT de OpenAI son no deterministas con temperature=0
- Normalmente se señala como causa la imprecisión de las operaciones optimizadas de punto flotante en CUDA
- Otra hipótesis planteada: la inferencia por lotes de los modelos Sparse MoE es la causa raíz de la no determinación de la API de GPT-4, una hipótesis más limpia que la explicación existente
- Se demostró empíricamente que las llamadas a la API de GPT-4 (y algunos modelos 3.5) son mucho más no deterministas que las de otros modelos de OpenAI
- Con base en la velocidad, la no determinación y la eliminación de logprobs, se estima que GPT-3.5-turbo también podría ser MoE
1 comentarios
Comentarios de Hacker News
Los errores de punto flotante por lo general son deterministas, así que si ejecutas el mismo cálculo dos veces, el resultado debería ser idéntico hasta el nivel de bits
Los resultados solo se bifurcan cuando hay otro estado o fuente de entropía, como no inicializar correctamente un búfer en cero, tener una condición de carrera, o no configurar de forma consistente las banderas del modo de redondeo
Viendo la calidad del código improvisado que suele hacerse en el ecosistema de IA/ML, parece probable que estén ocurriendo las tres cosas, y quizá incluso más
En este caso, debido al paralelismo de la GPU, el orden en que se suman los números no es determinista, y por eso el resultado puede variar un poco
Conviene evitar menospreciar el código ajeno cuando fue escrito sobre sistemas que uno no conoce bien
En la CPU también puede pasar por el procesamiento en paralelo, pero mientras que la mayoría de las instrucciones individuales de la CPU son deterministas, CUDA ofrece operaciones primitivas no deterministas
Eso es un diseño intencional porque son más rápidas que sus equivalentes deterministas, y el problema es presentarlo como si fuera un bug causado por mal código
Por ejemplo, algunas operaciones de punto flotante como la suma o la multiplicación no cumplen la propiedad asociativa, así que el resultado cambia según el orden de ejecución con que se complete una reducción (
reduction)En contextos paralelos hay implementaciones que vuelven no determinista el orden de reducción por razones de rendimiento, y por eso el resultado final también se vuelve no determinista
Basta con una llamada a
GetTimeOfDay(), y también puede pasar por el drift en la frecuencia del reloj entre varios procesadoreshttps://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
No estoy seguro de haber entendido bien el extracto del artículo citado
¿Quiere decir que parte de la inferencia más eficiente depende de mezclar tokens de entradas completamente distintas, por ejemplo entradas de otros usuarios? ¿Y que, dependiendo de qué otras entradas entren por casualidad en el mismo lote, cambia la proporción de asignación a los “expertos” y también cambia el resultado final?
Si es así, no solo introduce no determinismo, sino que la calidad de la respuesta también podría verse afectada por la cantidad de solicitudes concurrentes que compiten por la misma asignación de expertos
Por ejemplo, la parte del sistema que traduce o interpreta bien hindi podría dar peores resultados durante las horas pico de India, porque habría más entradas compitiendo al mismo tiempo por esa misma capacidad
Eso también podría explicar por qué da la impresión de que la calidad ha bajado con el tiempo. Antes, ciertas pruebas podían pasar de forma estable porque había menos congestión en los expertos relevantes; ahora, con más uso concurrente, la misma prueba podría no recibir suficiente esfuerzo de ese experto
También puede aparecer un pozo donde, si cierto subexperto destaca al principio en un área específica, más uso se concentra en esa área, y la nueva congestión hace que los usos imitativos ya no reciban la misma asignación de expertos, por lo que ese rendimiento inicialmente impresionante se deteriora
Si el efecto es fuerte y OpenAI lo sabía pero no lo reveló, podría verse como un producto señuelo: atraer usuarios con el rendimiento excepcional pero poco representativo de un sistema Mixture-of-Experts inicialmente sin congestión, para luego entregar resultados de menor calidad de un sistema más congestionado
Probablemente estén agrupando los lotes de forma distinta. Si divides 10 lotes en 2 grupos de 5, la respuesta cambia según si mi prompt cae en el primer grupo o en el segundo, y si está en la misma posición dentro del lote obtienes la misma respuesta
Si el lote completo es el mismo, es decir, la secuencia y el orden coinciden, entonces el lote completo es determinista, pero al mezclar lotes se pierde esa determinación
Incluso ahora, la confiabilidad es uno de los principales obstáculos que impiden una adopción amplia de los LLM en muchos flujos de trabajo críticos para el negocio
Si es cierto el rumor de que GPT-4 es inherentemente no determinista e inestable, la mayoría de las empresas estaría mejor ajustando finamente un LLM de código abierto con rendimiento similar para un dominio específico
Los modelos especializados por dominio siempre rinden mejor que los modelos generales, así que por ese lado también habría una ventaja de desempeño
Si GPT-3.5 es un modelo MoE, ¿no sería una señal bastante esperanzadora para el mundo open source?
Si aparece un buen modelo MoE de código abierto, quizá en forma de una variante de los modelos decodificadores existentes, eso significaría que se puede hacer muchísimo más con muchos menos recursos
No sé si los modelos MoE tienen que entrenarse desde cero
Una forma de bajar la proporción FLOPs:memoria, como Soft MoE, también podría hacer que la inferencia en CPU, o al menos en Apple Silicon, fuera mucho más viable
Si las secuencias dentro de un lote pueden afectar el enrutamiento entre sí, da la impresión de que podrían surgir posibilidades extrañas y difíciles de implementar de ataques por canal lateral
Es un trabajo realmente excelente. Me he opuesto firmemente a MoE por varias razones, y esta es la primera vez que veo evidencia convincente en vez de una publicación de Substack o la repetición de rumores
No tenía idea de que GPT-4 fuera no determinista, y lo uso unas 2 horas al día
Entiendo por qué era difícil notarlo a simple vista. En mi memoria la “sensación” es parecida y usa mucho vocabulario similar, pero el formato es completamente distinto y algunas palabras clave coinciden mientras otras cambian como si fueran frases sinónimas
Si ves el ejemplo del gist enlazado, la salida no determinista es realmente muy parecida: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
Como la aleatoriedad debería estar limitada, esta parte al menos no resulta sorprendente
Parece probable que OpenAI en algún momento encuentre una forma de reducir esta aleatoriedad. También lo hace más plausible su promesa pública de volver a agregar logprobs a ChatCompletions
Si estás desarrollando un programa haciendo llamadas repetidas a la API con la misma entrada, es difícil no notar la no determinación
Me interesa qué conclusiones habrá sacado alguien que lo usa tanto, incluso con el paquete de funciones que salió esta semana
MoE significa Mixture of Experts, es decir, mezcla de expertos
Recién hacia la mitad del texto desarrollan la sigla casi por accidente, así que parece que la audiencia prevista sí era la de mezcla de expertos, y yo no estaba dentro de ella
Los modelos davinci-instruct-beta de GPT-3.0 ya devolvían logprobs no deterministas desde principios de 2021
Esto es una conjetura, pero CUDA también suele tener bugs de no determinación
text-davinci-001ytext-davinci-002fueron entrenados con FeedMe y SFT, ytext-davinci-003con RLHFEl propio modelo también tiene más dispersión a temperaturas altas
davinciycode-davinci-002?Si “estos tokens a menudo compiten entre sí por los espacios disponibles en el búfer de expertos”, ¿será por eso que cuando pido código largo ChatGPT tan seguido solo pone placeholders en lugar de funciones?
Si “estos tokens a menudo compiten entre sí por los espacios disponibles en el búfer de expertos”, ¿entonces eso significa que el resultado cambia cuando la carga es alta?
¿La sensación de que a veces cambia la calidad de la salida también se explica por la alta carga?
MoE significa Mixture of Experts