AMD adquire a MK1 para aumentar o desempenho e a eficiência da inferência em IA

• A AMD pretende elevar o desempenho e a eficiência da inferência em IA em toda a stack, do hardware ao software, por meio da aquisição da MK1
• A MK1, sediada em Mountain View, é uma equipe focada em inferência de alta velocidade voltada para implantações em larga escala e em tecnologias de IA baseadas em reasoning
• O Flywheel da MK1 é otimizado para hardware da AMD e atualmente processa mais de 1 trilhão de tokens por dia
• A equipe da MK1 se junta ao AMD Artificial Intelligence Group para reforçar a stack de software de IA corporativa e as capacidades de inferência
• O Flywheel e os comprehension engines se concentram em usar a arquitetura de memória das GPUs AMD Instinct para aumentar a precisão, a eficiência de custos e a rastreabilidade em reasoning em larga escala

---

MK1 se junta à stack de IA da AMD

• A AMD concluiu a aquisição da MK1 e a trata como um marco estratégico para aumentar o desempenho e a eficiência em IA em toda a stack
• A MK1 é uma equipe sediada em Mountain View, Califórnia, que vem desenvolvendo inferência de alta velocidade otimizada para implantações em larga escala e tecnologias de IA baseadas em reasoning
• A tecnologia Flywheel da MK1 é otimizada para hardware da AMD e atualmente processa mais de 1 trilhão de tokens por dia
• A equipe da MK1 se junta ao AMD Artificial Intelligence Group
  • A tecnologia e a expertise da equipe serão usadas para avançar as capacidades de inferência de alta velocidade da AMD e sua stack de software de IA corporativa

O Flywheel mira a IA corporativa

• O Flywheel e os comprehension engines da MK1 foram projetados para aproveitar a arquitetura de memória das GPUs AMD Instinct
• A tecnologia se concentra em oferecer reasoning com precisão, eficiência de custos e rastreabilidade completa em ambientes de grande escala
• A AMD pretende acelerar a próxima etapa da IA corporativa ao combinar as inovações de software da MK1 com suas próprias capacidades de computação
  • ajudando clientes a automatizar processos de negócios complexos
  • ajudando a abrir novas oportunidades em aplicações de alto valor
• As declarações sobre os efeitos esperados da aquisição constituem declarações prospectivas, e os resultados reais podem variar de acordo com os riscos e incertezas descritos nos documentos enviados pela AMD à SEC

[GN⁺]

Opiniões no Hacker News

• Acho estranho que eles não mencionem nenhuma vez as técnicas de quantização já existentes nem comparem com os resultados delas
  Normalmente tento interpretar de boa-fé, mas não é possível que eles não conheçam técnicas amplamente usadas para o mesmo objetivo, então deveria haver benchmarks comparativos
  Para preencher a lacuna, há uma tabela comparativa por quantização oferecida pelo llama.cpp[0] para o Llama 1. Não dá para comparar diretamente com as métricas do Llama 2, mas olhando apenas para a velocidade e a variação de perplexidade, o MK-1 parece muito parecido com Q5_1. A perplexidade piora de forma pequena, mas não desprezível, e a velocidade fica um pouco mais de 2 vezes maior
  Se esses números estiverem certos, dá para baixar do Hugging Face um modelo Llama 2 já quantizado e obter praticamente o mesmo desempenho que o MK-1 oferece. Os arquivos Q5 estão aqui: https://huggingface.co/TheBloke/Llama-2-13B-GGML/tree/main
  [0] https://github.com/ggerganov/llama.cpp#quantization
  • Sou um dos fundadores. O motivo de não termos comparado com métodos existentes é que achamos difícil fazer uma comparação justa
    Cada técnica tem muitos trade-offs e casos de uso, e não é uma questão de uma ser ruim e outra boa, mas de pontos de projeto-alvo diferentes. Por exemplo, nuvem e local são coisas diferentes. Estamos divulgando números e benchmarks, e estamos em beta fechado porque estamos procurando parceiros iniciais alinhados com a proposta de valor atual
    Por exemplo, o llama.cpp é um ótimo framework para rodar modelos localmente em casos de usuário único (batch=1). Embora o llama.cpp suporte vários backends, como RPi, CPU e GPU, não acho justo apresentar o MKML como melhor no GPU para casos multiusuário (batch >> 1), sob certos critérios de perplexidade, taxa de compressão e velocidade. Pelo que sei, esse não é o caso de uso-alvo do llama.cpp. Por exemplo, o MKML roda o Llama-2 7B em uma 4090 com batch 32, ou seja, 32 prompts processados em paralelo, a cerca de 2700 tok/sec, com uso de memória de 5,2 GB e perplexidade quase no nível de fp16
    Além disso, atualmente não estamos envolvendo ferramentas ou técnicas open source de quantização. É tudo tecnologia própria, e em breve teremos mais novidades para divulgar. Se houver perguntas técnicas específicas, responderei na medida do possível
  • O uso da palavra “codec” também me incomoda um pouco. Parece uma tentativa de fazer parecer que inventaram um paradigma completamente novo, usando um nome elegante que remete a compressão de vídeo
  • Neste fim de semana, fiz vários experimentos com Llama2 em uma AMD 7900 XTX usando llama.cpp e quantização q5_k_s
    Comparando com os números de MK600 em RTX 4090 que eles apresentaram, mesmo usando uma GPU mais barata medi throughput maior e perplexidade menor
  • Q5_1 também já é um método antigo. As quantizações da família K são mais rápidas e mais eficientes em espaço para a mesma perda de perplexidade
    https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • Eles dizem que o MKML reduziu o tamanho do modelo Llama2-13B de 26 GB para 10,5 GB. A oferta parecida da TheBloke é um modelo Q6_K de 10,7 GB
    Talvez estejam apenas empacotando GGML e llama.cpp de um jeito conveniente, fazendo as pessoas acreditarem que é uma tecnologia proprietária
• Nenhuma menção às técnicas de quantização existentes? Aposto 10 dólares que isso é só um wrapper em cima de bitsandbytes ou ggml
• Acho que vai ser difícil usar se não for open source
  Esta área se move rápido demais e, caso contrário, a conveniência também não será suficiente
  Além disso, a marca lembra MK-ultra, e acho que seria melhor evitar isso
• Já trabalhei com quantização de modelos de machine learning. A quantização open source de 4 ou 8 bits não é o melhor que se pode conseguir
  Existem técnicas muito mais sofisticadas para reduzir o tamanho mantendo o desempenho preditivo. Algumas técnicas, como treinamento ciente de quantização, envolvem mudanças no processo de treinamento
  • Com certeza existem métodos melhores. Mas, neste caso, os números do MKML não impressionam quando colocados lado a lado com técnicas de quantização representativas e já amplamente usadas
    Segundo esta tabela[0], o tamanho é mais parecido com a quantização Q6_K, e a perplexidade parece até um pouco pior
    Se a técnica deles fosse melhor, acho que eles teriam reconhecido a existência das técnicas open source e as incluído na tabela comparativa, em vez de fazer parecer que o modelo fp16 bruto é a única alternativa
    [0] https://old.reddit.com/r/LocalLLaMA/comments/142q5k5/updated...
  • E quanto ao método de quantização da Unum?
    https://github.com/unum-cloud/usearch
• Parece mais um grift de startup de IA. Algo no estilo usar GGML, fechar tudo e tentar captar dinheiro de VC
  Parece mais uma empresa de wrapper de IA fazendo a mesma coisa, tentando pegar carona antes que a febre dos LLMs esfrie
  Se não for open source e for fechado, já começa condenado
• Isso não é só quantização?
  • Pelo vídeo de demonstração, as saídas nos dois casos são exatamente iguais, então fico em dúvida se usam quantização
  • Foi exatamente o que pensei. Todo mundo já está fazendo isso. Se não estiverem fazendo algo diferente, precisam mostrar por que isso é melhor do que simplesmente quantizar rapidamente para 8 bits, 4 bits etc.
  • Seja o que for, provavelmente em breve será replicado ou algo semelhante será adicionado a ferramentas open source como llama.cpp
    Não parece uma vantagem defensável. Parece um único recurso lutando contra alternativas open source que se movem rápido
• É uma pena que não seja um esforço open source
  Não tenho nenhuma preferência por colocar uma dependência proprietária na minha stack
  • Sou bastante cético sobre até onde isso vai. A comunidade open source já conseguiu melhorias de desempenho praticamente iguais com quantização
    Parece que estão reembalando bibliotecas existentes para vender a startups de IA descuidadas e mal informadas
• Como isso se compara ao mlc-llm, que usa quantização de 4 bits? Na minha 4090, o llama2 13B roda absurdamente rápido
  Mesmo usando a mesma quantização de 4 bits, é várias vezes mais rápido que o llama.cpp na GPU
  • Sim, o auto-tuning TVM Vulkan é impressionante. Acho que ele nem usa a extensão Vulkan de matmul
    A quantização de 4 bits do MLC é mais simples que a do llama.cpp, o que reduz a perplexidade e também explica parte da diferença de velocidade. Mas o recurso que mais faz falta é offloading para CPU. Com isso, daria para rodar 70B de forma bem plausível em uma 4090
    Acho que o cálice sagrado da inferência local de LLMs é rodar o Llama 70B com TVM dividindo a carga entre a GPU e a GPU integrada. Parece que estamos quase lá. As peças estão todas lá, mas falta um desenvolvedor de frontend para ligar os pontos
• Hoje em dia dá para fazer esse tipo de coisa até em um MacBook Pro. Não entendo muito por que eu iria querer ficar preso a mais um fornecedor
  Se quiser o melhor, use OpenAI ou Anthropic; caso contrário, rode você mesmo
• Esse é o verdadeiro efeito Ultra Instinct^H^H do Llama2?
  O Facebook está, na prática, fortalecendo o ecossistema, os criadores de ferramentas e serviços menores de inferência
  Esta empresa teve acesso a um modelo confiável e popular, com licença realmente open source, e aos pesos relacionados; por isso pôde criar e vender otimizações em cima dele sem se preocupar com a licença ou restrições dos próprios pesos