Um modelo brasileiro de 70 bilhões de parâmetros, treinado do zero em poucos meses, em hardware AMD, sem CUDA e sem rodada de investimento. Essa é a promessa do Genesys PI, da LUA Vision.

O post do Akita testou o que dava pra testar de fora. A parte do treino ficou em aberto, e foi ela que me fez abrir uma planilha.

O que é o Genesys PI e qual é a promessa

O Genesys PI é o modelo da LUA Vision, uma empresa brasileira. Segundo o Akita, a LUA diz que o modelo:

• foi treinado do zero, em hardware AMD e ARM64 (MacBook incluso), sem CUDA;
• levou poucos meses;
• não teve rodada de investimento;
• tem 70 bilhões de parâmetros;
• usa uma arquitetura própria chamada NCAS, descrita como “pós-transformer”, com detalhes sob NDA.

O Akita não aceitou nada disso na fé. Ele mediu o que dava pra medir de fora:

• o tokenizador é o o200k_base, da OpenAI. Isso descarta um rebrand de Qwen, DeepSeek, Llama ou Mistral;
• não é o gpt-oss “de prateleira” e não é um proxy fino em cima de outro modelo;
• na bateria de sabotagem dele, o tier House fez 83,5. Depois que a LUA corrigiu a API, fez 95,5. Uma rodada só tem ruído grande (ele estima uns ±9 pontos), então o salto não prova nada;
• separar “treinado do zero” de “destilado de outro modelo” ele diz que não consegue fazer de fora.

O modelo existe, responde e completa um benchmark difícil. A parte do treino o Akita não consegue verificar, e ele diz isso com todas as letras.

Por que isso importa

Se um grupo pequeno treinou um modelo desse nível em meses, sem CUDA e sem rodada de investimento, cai a ideia de que modelo de fronteira exige dezenas ou centenas de milhões de dólares em GPU NVIDIA.

Eu não consigo verificar se é verdade. Mas dá pra fazer outra pergunta: com a tecnologia de treino que a gente conhece hoje, o que seria preciso pra isso ser possível?

A conta não é uma auditoria e não prova nada. Ela monta faixas de plausibilidade e mostra onde a promessa fica apertada.

A régua: o nanochat do Karpathy

A régua é o nanochat, do Andrej Karpathy. O repositório treina do zero um modelo de nível GPT-2 e publica o passo a passo inteiro, inclusive tempo e custo.

Ele mantém uma leaderboard de “quanto tempo pra chegar no nível do GPT-2”. O run mais recente que li:

• 8 GPUs NVIDIA H100, num único nó;
• 1,65 hora de treino;
• a US$3 por GPU-hora, que é o preço que o README usa, sai na casa de US$40 a US$48;
• o primeiro run da leaderboard levou 3,04 horas, então o repositório já ficou ~2× mais eficiente.

Em H100-horas (uma GPU H100 ligada por uma hora), isso dá 8 × 1,65 = 13,2 H100-horas.

Pra saber o que entrou nessas horas, instanciei o modelo do run (profundidade 24, commit a825e63) e contei direto no código:

• 730 milhões de parâmetros nas matrizes que fazem conta (as camadas do transformer e a de saída).

  O total passa de 1,3 bilhão porque o modelo tem tabelas de embedding grandes. Só que elas são consulta, não conta, e não entram no custo;

• 5,8 bilhões de tokens de treino, uns 8 por parâmetro;
• 2,8e19 FLOPs no total. É esse número que eu vou escalar.

E o hardware? O nanochat é feito pra CUDA, e o próprio repositório trata AMD como não testado.

Antes da conta: o que é FLOP e TFLOP

FLOP (floating point operation) é uma operação aritmética com números decimais: uma soma ou uma multiplicação. Treinar uma rede neural é fazer uma quantidade absurda dessas contas.

O termo aparece de dois jeitos, e a conta depende dos dois:

• FLOPs, no plural, é o total de operações que o treino exige. Quanto maior o modelo e mais dados ele lê, mais FLOPs;
• FLOP/s é a capacidade do chip: quantas operações ele faz por segundo. É o que o fabricante anuncia como “pico”.

1 TFLOP/s (tera) são 10¹² operações por segundo, um trilhão. Um chip de 1.000 TFLOPs faz um quatrilhão de contas por segundo.

O tempo de treino é um dividido pelo outro: FLOPs totais ÷ FLOP/s do chip.

Nas tabelas vai aparecer notação científica. 2,4e23 é 2,4 × 10²³, ou seja, 24 seguido de 22 zeros.

A conta em duas peças

Pra estimar o custo de treino de qualquer modelo, eu uso duas fórmulas.

FLOPs de treino ≈ 6 × N × D, onde N é o número de parâmetros (os ativos, no caso de MoE) e D é o número de tokens de treino.

O 6 sai de como o treino funciona. Pra cada token, o modelo passa por dois passos.

No forward, ele faz a previsão. Cada parâmetro é um peso que multiplica um valor de entrada, e o resultado é somado aos outros. Uma multiplicação e uma soma: 2 FLOPs por parâmetro.

No backward, ele confere a previsão com a resposta certa e calcula o quanto cada peso tem que mudar pra errar menos. Cada camada faz duas contas do tamanho da do forward: uma passa o erro pra camada anterior, a outra calcula o ajuste dos próprios pesos. São 4 FLOPs por parâmetro.

Somando, dá 6 por parâmetro, por token. A fórmula vem do paper de scaling laws da OpenAI (Kaplan et al., 2020). Ela é aproximada porque deixa de fora o custo da atenção, que em modelo grande é pequeno perto das multiplicações de matriz.

A segunda é o MFU (Model FLOPs Utilization): a fração do pico teórico do chip que vira trabalho útil de verdade. O custo é inversamente proporcional a ele. Dobrou o MFU, caiu o custo pela metade.

E tem uma terceira peça, do paper do Chinchilla (Hoffmann et al., 2022): com um orçamento fixo de computação, N e D devem crescer juntos, na casa de ~20 tokens por parâmetro.

“Tokens por parâmetro” é a quantidade de dados de treino (texto já convertido em tokens) que o modelo lê, dividida pelo tamanho dele. E o 20 não é lei. O próprio nanochat mede um ótimo de ~10,5, e o run mais recente usa 8. A razão muda conforme o que cada um conta como “parâmetro”.

Se o Genesys fosse um transformer denso de 70B

Duas premissas valem daqui até o fim do post.

• Prazo: 90 dias. A LUA fala em “poucos meses”. Pros cálculos, eu assumi três.

  O prazo só mexe na quantidade de GPUs. O total de H100-horas e o custo não mudam: com seis meses, o número de GPUs cai pela metade e a conta fica igual;

• Custo: US$3 por GPU-hora. É o preço que o README do nanochat usa: ~US$3 por GPU-hora, ~US$24 por hora pro nó de 8 H100, ~US$48 pelo run de 2 horas. O custo das tabelas é H100-horas × US$3.

  Pra conferir, olhei o catálogo da RunPod em 04/10/2026. O H100 SXM sai a US$2,69 por hora no Community Cloud e a US$3,49 no Secure Cloud, então os US$3 ficam no meio.

  É preço de aluguel e cobre só as horas de GPU. Compra de hardware, salário e dados ficam de fora.

Com N = 70 bilhões, a única variável é quantos tokens ele leu. A tabela escala o run do nanochat e compara com os 20 tokens por parâmetro do Chinchilla e com os modelos abertos de hoje:

Tokens de treino	FLOPs	× o run do nanochat	H100-horas	Custo (US$3/h)
560B (8 tok/param)	2,4e23	~8.400×	111 mil a 236 mil	US$330 mil a US$710 mil
735B (10,5 tok/param)	3,1e23	~11.100×	146 mil a 310 mil	US$440 mil a US$930 mil
1,4T (20 tok/param)	5,9e23	~21.100×	278 mil a 590 mil	US$0,8 a US$1,8 milhão
15T (como os 70B abertos de hoje)	6,3e24	~226.000×	3,0 a 6,3 milhões	US$8,9 a US$19 milhões

O intervalo de H100-horas tem duas pontas.

• A menor assume a mesma eficiência do nanochat. 2,8e19 FLOPs em 13,2 H100-horas dá ~587 TFLOPs por GPU, uns 59% do pico em bf16 do H100.

  Isso num nó só, sem rede entre máquinas, e em FP8 (volto nisso mais abaixo);

• A maior assume ~28% de MFU, que é o que sai das GPU-horas que a Meta publicou pro Llama 3 70B. Cluster grande perde eficiência com a comunicação entre nós.

Na faixa de 560B a 1,4T tokens, a conta vai de algumas centenas de milhares de dólares a uns dois milhões. Com 15T, passa dos US$9 milhões.

Traduzindo pra chips AMD

O Akita cita AMD, e o nanochat usa H100, então eu precisava de um chip AMD equivalente. Escolhi o MI300X: 192 GB de memória e pico de ~1.300 TFLOPs em bf16, contra ~990 do H100.

No papel, o MI300X tem mais pico. Pra empatar com o que o nanochat tira do H100 (~587 TFLOPs por GPU), ele precisaria de uns 45% de MFU em bf16. Não é impossível.

O problema é o software. O ROCm, da AMD, é bem menos rodado que o CUDA, então 25% a 40% é uma faixa mais razoável.

Quantos MI300X pra terminar em 90 dias:

Tokens	MFU 40%	MFU 30%	MFU 25%	Custo (US$2,39/h, MFU 40% a 25%)
560B	~58	~77	~93	US$300 mil a US$480 mil
735B	~76	~101	~121	US$390 mil a US$630 mil
1,4T	~145	~193	~231	US$0,75 a US$1,2 milhão
15T	~1.550	~2.070	~2.480	US$8 a US$12,8 milhões

O custo usa o preço do MI300X na RunPod em 04/10/2026: US$2,39 por hora, mais barato que o H100. Com mais pico e hora mais barata, o teto em AMD fica abaixo do teto em H100.

É preço de lista, e a RunPod aluga no máximo 8 GPUs por máquina. Ninguém aluga centenas de MI300X por três meses assim: nessa escala, o preço sai de contrato negociado e costuma ser menor.

No cenário enxuto (560B a 1,4T tokens), bastam de algumas dezenas a umas duas centenas de GPUs de datacenter por três meses. É plausível pra uma empresa pequena que alugue ou compre esse hardware.

No cenário de 15T, são milhares de GPUs. Aí fica difícil sustentar o “sem rodada de investimento”.

E o FP8?

Essa tabela usa o pico em bf16, um formato de número de 16 bits. Os chips de hoje também fazem conta em FP8, com 8 bits, e no papel o pico dobra: o MI300X anuncia ~2.600 TFLOPs em FP8.

Se o Genesys foi treinado em FP8, os números de GPU caem. Mas não pela metade.

O próprio nanochat mostra isso. O primeiro run da leaderboard foi em bf16 e tirou ~494 TFLOPs por GPU. O run atual liga o FP8 e tira ~587, uns 20% a mais (e no meio do caminho entraram outras mudanças também).

O ganho fica longe de 2× porque nem todas as contas do treino vão pra FP8, e as que vão ainda pagam a conversão de formato.

Então FP8 encolhe a tabela em algo entre 15% e 50%, provavelmente perto da ponta de baixo. A ordem de grandeza não muda: o cenário de 15T continua pedindo perto de mil GPUs ou mais.

E se for MoE?

A arquitetura do Genesys é nova e não é pública. Tudo acima usa um transformer denso como régua.

O próprio Akita nota uma contradição aqui. A issue que a LUA abriu no LiveBench descreve o modelo como transformer. Na conversa com ele, a descrição é “pós-transformer”.

Não dá pra calcular o custo de uma arquitetura desconhecida. Mas dá pra testar duas hipóteses.

Hipótese 1: denso. Todos os 70B de parâmetros trabalham em cada token. É a tabela acima.

Hipótese 2: MoE (mixture of experts). O “70B” seria o total de parâmetros, e só uma fração fica ativa por token. O custo de treino acompanha os parâmetros ativos, não os totais.

Pra ilustrar, imagine um MoE de 70B totais com ~10B ativos. Esse número é um exemplo meu, ninguém da LUA falou em MoE:

Cenário	FLOPs	H100-horas	Custo (US$3/h)	MI300X em 90 dias (MFU 25 a 40%)
MoE ~10B ativos, 735B tokens	4,4e22	21 mil a 44 mil	US$60 mil a US$130 mil	~11 a 17
MoE ~10B ativos, 1,4T tokens	8,4e22	40 mil a 84 mil	US$120 mil a US$250 mil	~21 a 33
MoE ~10B ativos, 15T tokens	9,0e23	430 mil a 900 mil	US$1,3 a US$2,7 milhões	~220 a 350

A diferença é enorme. Se o Genesys for MoE com poucos parâmetros ativos, até o cenário “moderno” de 15T tokens cabe em algumas centenas de GPUs.

Mas essa tabela é otimista em dois pontos:

• MoE costuma render menos MFU, porque os experts trocam muita informação entre GPUs. Os números reais tendem a ser piores;
• a memória precisa guardar todos os parâmetros, não só os ativos. Então o número de GPUs não cai tanto quanto o FLOP sugere.

Um MoE público pra comparar: o DeepSeek-V3 tem 671B totais e 37B ativos, foi treinado em 14,8T tokens e gastou 2,79 milhões de GPU-horas H800. Isso dá ~1.290 GPUs por 90 dias.

Onde a conta aperta

A conta não diz que é impossível.

Em compute, o cenário enxuto cabe. Um transformer denso de 70B lendo de 560B a 1,4T tokens custa entre US$0,3 e US$1,8 milhão no run final, e cabe em 60 a 230 GPUs AMD por três meses (menos, se for FP8). Não é trocado, mas também não exige rodada bilionária.

O que aperta é a qualidade. Os 70B abertos de hoje foram treinados com muito mais dados:

• Llama 3 70B: mais de 15T tokens;
• Qwen2.5-72B: 18T;
• Chinchilla 70B: 1,4T (o ótimo de 2022).

Um 70B denso com 560B a 1,4T tokens seria bem menos treinado que esses. Pra chegar na qualidade que o Akita mediu treinando com 15T, o custo sobe pra US$9 a US$19 milhões, com perto de mil GPUs ou mais.

Então, pra história fechar, pelo menos uma destas coisas tem que ser verdade:

• o modelo é MoE, e o “70B” é o total;
• a arquitetura é bem mais eficiente em dados que um transformer. É exatamente a promessa do NCAS, e não dá pra calcular de fora;
• boa parte da qualidade vem de pós-treino (SFT, RL agêntico), que não está nesta conta;
• parte do treino partiu de pesos ou dados de outros modelos, o que o Akita diz não conseguir separar de fora;
• o investimento foi maior do que o descrito.

Nenhuma dessas hipóteses é absurda. Mas cada uma é uma afirmação diferente, e a que a LUA faz em público é a mais simples e a mais forte.

O que resolveria a dúvida

Se a LUA publicar a ficha técnica, quatro números fecham a conta em minutos:

1. os chips: tipo e quantidade (MI300X? MI325X? quantos?);
2. o MFU medido, que é a eficiência real do treino;
3. os tokens de treino: quantos, e de onde;
4. denso ou MoE, e quantos parâmetros ativos por token.

E sobra a pergunta que a conta não responde: do zero, ou partindo de pesos existentes?

Segundo a LUA, a política de preços sai em 7 de outubro de 2026. Vale acompanhar.

Limites desta conta

A margem de erro é grande, e vem destes lugares:

• extrapolo de um modelo de 0,73B parâmetros pra um de 70B, uma distância de ~100×. É a maior fonte de incerteza;
• a eficiência do nanochat é o limite otimista (um nó, 8 GPUs). Em cluster grande, o MFU tende a ser menor;
• as tabelas de GPU usam o pico em bf16. Treino em FP8 reduz o número de GPUs, mas no nanochat o ganho real ficou perto de 20%, não de 2×;
• a conta cobre só o run final de pré-treino. Experimentos, runs que falham e pós-treino somam por cima. Minha regra de bolso é 2× a 3×;
• os preços (US$3 do README do nanochat, US$2,39 do MI300X na RunPod) são de lista. Aluguel varia bastante, e em escala de centenas de GPUs sai por contrato;
• os números de pico (H100 e MI300X) vêm de datasheet, os mesmos que o nanochat usa pra calcular MFU;
• nada disso mede qualidade. Quem mediu foi o Akita, e ele mesmo avisa que é um benchmark só.

Conclusão

Tudo isso foi um exercício. A conta usa um transformer como régua porque é o que a gente sabe medir, e cada número aqui é uma conjectura em cima do que é público.

Só que a LUA não se vende como um transformer barato. Ela se vende como algo revolucionário: arquitetura própria, “pós-transformer”, treinada fora do ecossistema da NVIDIA.

Se for isso mesmo, a régua deste post não serve. Uma arquitetura diferente, com um método de treino diferente de tudo que a gente já viu, não tem obrigação de seguir o 6 × N × D nem os 20 tokens por parâmetro do Chinchilla. Aí as tabelas lá de cima viram outra coisa: a medida do salto que ela teria dado.

Eu estou curioso pelas novidades sobre o modelo.

Por hoje é só.

Agradecimento ao Akita pelo post e pela conversa que originou esta curiosidade.