Parece ser mais adequado para Apple Silicon com RAM sobrando ou para a linha de NPUs. Para usar em servidores puramente com GPU, o fato de que até o modelo mínimo em quantização int4 exige uma H100 é...
O React nada mais é do que uma biblioteca de UI baseada em componentes. Simplesmente exibir componentes em HTML é fácil, mas para criar um site ou aplicativo são necessários muitos recursos. Por isso, recomenda-se usar um framework. Isso não acontece apenas por ser React; grande parte da web moderna é construída por meio de frameworks web. Além disso, o React não precisa necessariamente ser usado com um framework baseado em React, já que também pode ser usado junto com frameworks web criados em várias linguagens diferentes, como Go, Rust e Java. Portanto, a escolha é sempre do usuário.
Será que vai ser mais rápido do que wrappers de CUDA já existentes, como CuPy e PyTorch? A vantagem do CuPy e do torch é que a API é quase igual à do NumPy, então dava para migrar o código de teste escrito em NumPy sem muito esforço; quanto a este, acho que vou ter que usar para ver como é.
O que é bem frustrante é isto
Antes: pensamento => código (lento) => depuração
IA: pensamento => escrever um prompt sofisticado => código (instantâneo) => depuração
Mas, em geral, escrever meu pensamento em código costuma ser mais rápido do que transformá-lo em prompt, não é? Exceto quando se trata de algo já muito conhecido... E, nas partes em que a confiabilidade é importante, de qualquer forma é preciso entender a lógica com os próprios olhos depois de escrever, então nem dá para delegar; e, no momento em que você delega, acaba ficando sem consciência profissional.
O código-fonte do BASIC para 6502 fornecido pela Microsoft como OEM (Apple II, Commodore, etc.) foi restaurado(?) a um estado compilável. https://github.com/mist64/msbasic
Eu também, enquanto me preparava para testes de programação, acabei abrindo o Cursor por puro hábito, a ponto de apertar mais Tab do que realmente digitar... hehe. Com carinho, voltei para o VSCode.
Bem... como alguém que também estava estudando React recentemente,
com a descontinuação do CRA, fiquei pensando no que fazer, já que o material de estudo que eu tinha era baseado em CRA, então fui olhando Next, React Router e outros, mas eles vêm com tecnologias próprias adicionadas, então, do ponto de vista de quem está estudando React, não acho que sejam tão adequados... pessoalmente, acho que o Vite talvez seja a melhor opção.
Parece ser mais adequado para Apple Silicon com RAM sobrando ou para a linha de NPUs. Para usar em servidores puramente com GPU, o fato de que até o modelo mínimo em quantização int4 exige uma H100 é...
Na prática, a especificação mínima, mesmo incluindo quantização, é a A100, mas o desempenho fica meio ambíguo mesmo, aff aff
O React nada mais é do que uma biblioteca de UI baseada em componentes. Simplesmente exibir componentes em HTML é fácil, mas para criar um site ou aplicativo são necessários muitos recursos. Por isso, recomenda-se usar um framework. Isso não acontece apenas por ser React; grande parte da web moderna é construída por meio de frameworks web. Além disso, o React não precisa necessariamente ser usado com um framework baseado em React, já que também pode ser usado junto com frameworks web criados em várias linguagens diferentes, como Go, Rust e Java. Portanto, a escolha é sempre do usuário.
Hoje saiu o Llama 4. https://pt.news.hada.io/topic?id=20166
Acho que vou instalar isso para testar.
kkkkkkkkkk
Hahaha, concordo.
Existe algo melhor que o Google Gemma 3?
Será que vai ser mais rápido do que wrappers de CUDA já existentes, como CuPy e PyTorch? A vantagem do CuPy e do torch é que a API é quase igual à do NumPy, então dava para migrar o código de teste escrito em NumPy sem muito esforço; quanto a este, acho que vou ter que usar para ver como é.
Nunca tinha pensado que isso pudesse acontecer... mas acontece mesmo. É realmente uma história de terror.
Muito bom! ^0^
O que é bem frustrante é isto
Antes: pensamento => código (lento) => depuração
IA: pensamento => escrever um prompt sofisticado => código (instantâneo) => depuração
Mas, em geral, escrever meu pensamento em código costuma ser mais rápido do que transformá-lo em prompt, não é? Exceto quando se trata de algo já muito conhecido... E, nas partes em que a confiabilidade é importante, de qualquer forma é preciso entender a lógica com os próprios olhos depois de escrever, então nem dá para delegar; e, no momento em que você delega, acaba ficando sem consciência profissional.
A velocidade do primeiro é mesmo real? Está muito lento...
O código-fonte do BASIC para 6502 fornecido pela Microsoft como OEM (Apple II, Commodore, etc.) foi restaurado(?) a um estado compilável.
https://github.com/mist64/msbasic
Também há bastante gente que monta seu próprio SBC com 6502 e faz o port do MSBASIC para ele.
https://github.com/beneater/msbasic
Só admirar já é legal, mas talvez seja ainda mais divertido colocar a mão na massa… ;)
Uau, isso é impressionante
Eu também, enquanto me preparava para testes de programação, acabei abrindo o Cursor por puro hábito, a ponto de apertar mais
Tabdo que realmente digitar... hehe. Com carinho, voltei para o VSCode.Bem... como alguém que também estava estudando React recentemente,
com a descontinuação do CRA, fiquei pensando no que fazer, já que o material de estudo que eu tinha era baseado em CRA, então fui olhando Next, React Router e outros, mas eles vêm com tecnologias próprias adicionadas, então, do ponto de vista de quem está estudando React, não acho que sejam tão adequados... pessoalmente, acho que o Vite talvez seja a melhor opção.
De repente? Estranho.
Eu também fico pensando se realmente precisa ser assim.
Acho que quem cria ferramentas de IA também conhece bem esse problema. Só estão fazendo silêncio sobre isso.