AMD adquiere MK1 para aumentar el rendimiento y la eficiencia de la inferencia de IA

• AMD busca impulsar el rendimiento y la eficiencia de la inferencia de IA en toda la pila, desde el hardware hasta el software, mediante la adquisición de MK1
• MK1, con sede en Mountain View, es un equipo que se ha enfocado en la inferencia de alta velocidad para despliegues a gran escala y en tecnologías de IA basadas en reasoning
• Flywheel de MK1 está optimizado para el hardware de AMD y actualmente procesa más de 1 billón de tokens al día
• El equipo de MK1 se suma al AMD Artificial Intelligence Group para reforzar la pila de software de IA empresarial y las capacidades de inferencia
• Flywheel y los comprehension engines se centran en aprovechar la arquitectura de memoria de las GPU AMD Instinct para mejorar la precisión, la eficiencia en costos y la trazabilidad del reasoning a gran escala

---

MK1 se suma a la pila de IA de AMD

• AMD completó la adquisición de MK1 y la considera un hito estratégico para elevar el rendimiento y la eficiencia de la IA en toda la pila
• MK1 es un equipo con sede en Mountain View, California, que ha desarrollado tecnologías de inferencia de alta velocidad y de IA basada en reasoning optimizadas para despliegues a gran escala
• La tecnología Flywheel de MK1 está optimizada para el hardware de AMD y actualmente procesa más de 1 billón de tokens al día
• El equipo de MK1 se integró al AMD Artificial Intelligence Group
  • La tecnología y experiencia de este equipo se usarán para desarrollar las capacidades de inferencia de alta velocidad de AMD y su pila de software de IA empresarial

Flywheel apunta a la IA empresarial

• Flywheel y los comprehension engines de MK1 están diseñados para aprovechar la arquitectura de memoria de las GPU AMD Instinct
• Esta tecnología se enfoca en ofrecer reasoning con precisión, eficiencia en costos y trazabilidad completa en entornos a gran escala
• AMD busca acelerar la próxima etapa de la IA empresarial combinando las innovaciones de software de MK1 con sus propias capacidades de cómputo
  • Ayudar a los clientes a automatizar procesos de negocio complejos
  • Permitirles abrir nuevas oportunidades en aplicaciones de alto valor
• Las declaraciones relacionadas con los efectos esperados de la adquisición constituyen declaraciones prospectivas, y los resultados reales pueden variar según los riesgos e incertidumbres descritos en los documentos presentados por AMD ante la SEC

[GN⁺]

Opiniones de Hacker News

• Es raro que no mencionen ni una sola vez las técnicas de cuantización existentes ni comparen sus resultados con ellas.
  Normalmente intento asumir buena fe, pero es imposible que no conozcan técnicas ampliamente usadas para el mismo objetivo, así que debería haber benchmarks comparativos.
  Para completar lo que falta, llama.cpp ofrece una tabla comparativa por cuantización para Llama 1[0]. No se puede comparar directamente con las métricas de Llama 2, pero viendo solo la velocidad y la variación de perplexity, MK-1 se ve muy parecido a Q5_1. La perplexity empeora poco, pero no de forma despreciable, y la velocidad mejora un poco más de 2 veces.
  Si estas cifras son correctas, uno podría descargar de Hugging Face un modelo Llama 2 ya cuantizado y obtener prácticamente el mismo rendimiento que ofrece MK-1. Los archivos Q5 están aquí: https://huggingface.co/TheBloke/Llama-2-13B-GGML/tree/main
  [0] https://github.com/ggerganov/llama.cpp#quantization
  • Soy uno de los fundadores. La razón por la que decidimos no compararnos con métodos existentes es que nos pareció difícil hacerlo de manera justa.
    Cada técnica tiene muchos trade-offs y casos de uso, y no es una cuestión de que una sea mala y la otra buena, sino de que tienen puntos de diseño objetivo distintos. Por ejemplo, la nube y lo local son diferentes. Estamos publicando cifras y benchmarks, y como estamos buscando socios iniciales que encajen con la propuesta de valor actual, estamos en beta privada.
    Por ejemplo, llama.cpp es un excelente framework para correr modelos localmente en casos de un solo usuario (batch=1). Aunque llama.cpp soporta varios backends como RPi, CPU y GPU, no me parece justo comparar y mostrar que MKML es mejor en GPU para casos multiusuario (batch >> 1) bajo ciertos criterios de perplexity, tasa de compresión y velocidad. Hasta donde sé, ese no es el caso de uso objetivo de llama.cpp. Por ejemplo, MKML logra con Llama-2 7B en una 4090, con batch 32 —es decir, 32 prompts procesados en paralelo— alrededor de 2700 tok/sec, con un uso de memoria de 5.2GB y una perplexity casi al nivel de fp16.
    Además, actualmente no estamos envolviendo herramientas o técnicas open source de cuantización. Todo es tecnología propia y pronto tendremos más novedades para compartir. Si tienen preguntas técnicas concretas, responderé en la medida de lo posible.
  • También me incomoda un poco que usen la palabra “codec”. Da la sensación de que quieren hacerlo parecer un paradigma completamente nuevo y ponerle un nombre llamativo que recuerde a la compresión de video.
  • Este fin de semana estuve experimentando con Llama2 en una AMD 7900 XTX usando llama.cpp y cuantización q5_k_s.
    Comparado con las cifras de MK600 en una RTX 4090 que ellos muestran, estoy midiendo mayor throughput y menor perplexity aun usando una GPU más barata.
  • Q5_1 ya es un método viejo. Las cuantizaciones de la familia K son más rápidas y más eficientes en espacio para la misma pérdida de perplexity.
    https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • Dicen que MKML redujo el tamaño del modelo Llama2-13B de 26GB a 10.5GB. La oferta similar de TheBloke es un modelo Q6_K de 10.7GB.
    Tal vez solo estén empaquetando GGML y llama.cpp de forma agradable mientras hacen que la gente crea que es tecnología propietaria.
• ¿Ni una sola mención a las técnicas de cuantización existentes? Apostaría 10 dólares a que esto probablemente es solo un wrapper alrededor de bitsandbytes o ggml.
• Creo que será difícil usarlo si no es open source.
  Este campo se mueve demasiado rápido, y si no, tampoco ofrece suficiente comodidad.
  Además, el branding recuerda a MK-ultra, y creo que sería mejor evitarlo.
• He trabajado con cuantización de modelos de machine learning. La cuantización open source de 4 u 8 bits no es lo mejor que se puede lograr.
  Hay técnicas mucho más sofisticadas para reducir el tamaño manteniendo el rendimiento predictivo. Algunas, como el entrenamiento consciente de cuantización, implican cambios en el proceso de entrenamiento.
  • Sin duda hay métodos mejores. Pero en este caso, las cifras de MKML no resultan impresionantes cuando se las pone junto a técnicas de cuantización representativas y ya ampliamente usadas.
    Según esta tabla[0], el tamaño es más parecido a la cuantización Q6_K, y la perplexity incluso parece un poco peor.
    Si su técnica fuera mejor, creo que habrían reconocido la existencia de las técnicas open source y las habrían incluido en la tabla comparativa, en vez de hacer parecer que el modelo fp16 crudo es la única alternativa.
    [0] https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • ¿Qué tal el método de cuantización de Unum?
    https://github.com/unum-cloud/usearch
• Parece otro grift de startup de IA. Algo como usar GGML, cerrarlo y luego intentar recibir dinero de VC.
  Parece otra empresa de wrappers de IA haciendo lo mismo, tratando de subirse a la ola antes de que se enfríe la fiebre por los LLM.
  Si no es open source y está cerrado, ya está perdido desde el inicio.
• ¿Esto no es simplemente cuantización?
  • Viendo el video demo, la salida es exactamente igual en ambos casos, así que me parece dudoso que usen cuantización.
  • Eso mismo pensé. Es algo que ya todos están haciendo. Si no están haciendo algo distinto, deberían mostrar por qué es mejor que simplemente cuantizar rápido a 8 bits, 4 bits, etc.
  • Sea lo que sea, es muy probable que pronto se replique o que una función similar llegue a herramientas open source como llama.cpp.
    No parece una ventaja defendible. Parece una funcionalidad más peleando contra alternativas open source que avanzan muy rápido.
• Es una lástima que no sea un esfuerzo open source.
  No me entusiasma para nada meter una dependencia propietaria en mi stack.
  • Soy bastante escéptico sobre hasta dónde puede llegar esto. La comunidad open source ya consiguió mejoras de rendimiento prácticamente equivalentes con cuantización.
    Se siente como si hubieran vuelto a empaquetar bibliotecas existentes para vendérselas a startups de IA poco cuidadosas y mal informadas.
• ¿Cómo se compara con mlc-llm, que usa cuantización de 4 bits? En mi 4090, llama2 13B corre rapidísimo.
  Incluso usando la misma cuantización de 4 bits, es varias veces más rápido que llama.cpp en GPU.
  • Sí, el auto-tuning de TVM Vulkan es impresionante. Creo que ni siquiera usa la extensión Vulkan para matmul.
    La cuantización de 4 bits de MLC es más simple que la de llama.cpp, por lo que tiene peor perplexity, y eso también explica parte de la diferencia de velocidad. Pero la funcionalidad más importante que falta es el offloading a CPU. Con eso, incluso 70B podría correr de forma bastante razonable en una 4090.
    Creo que el santo grial de la inferencia local de LLM es correr Llama 70B con TVM repartiéndolo entre la GPU y la GPU integrada. Se siente que ya estamos muy cerca. Las piezas están todas, pero falta un desarrollador de frontend que conecte los puntos.
• Hoy en día esto también se puede hacer en una MacBook Pro. No entiendo muy bien por qué querría atarme a otro proveedor aquí.
  Si quieres lo mejor, usa OpenAI o Anthropic; si no, ejecútalo tú mismo.
• ¿Este es realmente el efecto de Ultra Instinct^H^H Llama2?
  Facebook está, en la práctica, fortaleciendo al ecosistema, a los creadores de herramientas y a servicios de inferencia más pequeños.
  Esta empresa pudo acceder a un modelo confiable y popular, a un modelo con una licencia open source real y a sus pesos relacionados, así que pudo optimizar encima de eso y venderlo sin preocuparse por la licencia o las restricciones de los propios pesos.