Raon-1 mini: o MoE de 28,8B da KRAFTON, e o PR do vLLM que durou 184 segundos

Às 06:34:19 UTC de 28 de outubro, um pull request intitulado "[Model] Add Raon-1-mini support" foi aberto contra vllm-project/vllm. Não era um esboço: 27 arquivos, 3.971 linhas adicionadas, 22 removidas, além de uma suíte de testes e uma página de documentação. Às 06:37:23 — três minutos e quatro segundos depois — ele foi fechado, sem merge e ainda sinalizado como rascunho. A KRAFTON, a editora sul-coreana por trás do PUBG, havia proposto colocar seu novo modelo de pesos abertos de 28.8B no mecanismo de inferência mais amplamente implantado do mundo, e então voltou atrás antes que alguém revisse uma linha.

O modelo por trás do pull request é real e está disponível para download desde 21 de outubro. O Raon-1 mini é um modelo de mistura de especialistas com atenção híbrida que ativa cerca de 4,3 bilhões de parâmetros por token, é distribuído sob Apache 2.0 e, até 28 de outubro, tinha 2.208 downloads no mês anterior e 221 curtidas em seu repositório no Hugging Face. O que ainda não existe é o caminho convencional: uma instalação padrão do vLLM que consiga servi-lo sem um wheel forkado. Essa lacuna — entre um checkpoint na internet e um modelo que você pode colocar em um manifesto de implantação — é a história inteira, e a cobertura até agora, em grande parte, a ignorou em favor da tabela de benchmarks.

O que a KRAFTON realmente publicou

Os artefatos foram publicados no Hugging Face em 21 de outubro às 00:14 UTC, que é a data que todas as publicações comerciais coreanas usaram no mesmo dia. O índice safetensors do repositório principal reporta 28.783.218.402 parâmetros em BF16 — o valor "30B-class" nos comunicados de imprensa é arredondamento, e 28,8B é o número a levar para um plano de capacidade.

• Parâmetros totais e ativos — 28,8B no total, ~4,3B ativos por token.

• Licença — Apache 2.0 sobre os pesos, a configuração e os componentes, com uso comercial permitido.

• Acesso — os repositórios são restritos, mas o acesso é concedido mediante solicitação por meio de uma caixa de seleção e não parece ser revisado manualmente na maioria das solicitações.

• Variantes — o checkpoint base MXFP8, uma versão NVFP4, um repositório GGUF, um checkpoint MLX para Apple silicon e um modelo de rascunho DFlash2 separado para decodificação especulativa.

• Hospedagem — a barra lateral do repositório informa que o modelo "não foi implantado por nenhum Provedor de Inferência". O card anuncia um teste gratuito por tempo limitado no playground próprio da KRAFTON; não há preço por token publicado em lugar algum.

• O que a licença não cobre — os conjuntos de dados de treinamento da KRAFTON, sua metodologia de treinamento, software não distribuído, e a API hospedada e o playground, que operam sob termos separados.

É uma prévia, e a KRAFTON a identifica assim na primeira linha do card. A empresa afirma que um lançamento completo está planejado junto com um relatório técnico que cobre "o processo de treinamento e o desempenho final". Nenhuma data foi fornecida, e a contagem de tokens de treinamento não é divulgada em lugar algum do card — o que é a maior lacuna em qualquer alegação sobre a eficiência de treinamento deste modelo.

A perspectiva da KRAFTON é o custo. O Chief AI Officer Kangwook Lee descreveu-o como o produto de “capacidades de P&D em IA acumuladas ao longo de mais de 5 anos” e afirmou que a empresa pretende usar um LLM mais barato para “ampliar o escopo do uso de IA em diversos setores”. O Raon-1 mini é o primeiro modelo de linguagem da marca Raon, que a KRAFTON utiliza desde abril para lançamentos de fala, TTS e codificador de visão.

A arquitetura é onde está a verdadeira aposta.

Uma proporção de 3:1 entre camadas de atenção linear e camadas de atenção completa é o ponto que vale a pena entender, porque todo o restante da economia de serviço do modelo decorre disso.

• Camadas — 25 no total, divididas em 18 camadas Raon Delta Attention (RDA) e 7 camadas MLA com gating.

• Especialistas — 128 no total, 6 roteados mais 1 compartilhado ativo por token, com tamanho intermediário por especialista de 1.088.

• Dimensões — tamanho oculto 2.560, 40 cabeças de atenção em ambos os tipos de camada, dimensão de cabeça RDA 128, MLA com gate em 192 QK / 128 V com rank de LoRA de consulta e KV de 576 / 512.

• Codificação de posição — NoPE, sem nenhum embedding rotativo em qualquer parte da pilha.

• Vocabulário — 259.840 tokens, com uma cabeça LM não compartilhada.

• Ativação e residuais — SiTU-GLU, com conexões residuais Raon-mHC em quatro fluxos.

A RDA é a modificação do Kimi Delta Attention feita pela KRAFTON, e a mudança descrita é específica: desacoplar os gates de apagamento e escrita e aplicar escala independente ao gate de escrita após a convolução, de modo que o histórico bruto da convolução seja preservado em vez de sobrescrito. O Raon-mHC é descrito como uma implementação mais barata do mHC da DeepSeek. Nenhum dos dois é uma invenção do zero, e isso não é uma crítica — "treinado do zero" na ficha refere-se à KRAFTON projetar e pré-treinar o modelo com seus próprios dados, não a reinventar cada bloco nele. Duas das três técnicas de destaque do modelo são versões reprojetadas de técnicas publicadas, e a terceira é um cronograma híbrido 3:1 com o qual outros laboratórios também convergiram.

O retorno é o cache KV. Como apenas as 7 camadas MLA com gating retêm um, a placa estima o custo em cerca de 8 KiB por token em BF16. No contexto completo de 262.144 tokens, isso dá cerca de 2 GiB por sequência — um número que cabe tranquilamente em uma única placa de 32 GB e não caberia de jeito nenhum se todas as 25 camadas fizessem cache. Esta é a verdadeira alegação de produto escondida sob a tabela de benchmark: não que o Raon-1 mini seja mais inteligente que seus pares, mas que a inferência de contexto longo nele é barata o suficiente para rodar em hardware que você talvez já tenha.

A tabela de referência, contada em vez de resumida

Todos os números abaixo são da KRAFTON. Não há entrada do Artificial Analysis para o Raon-1 mini em 28 de outubro — o modelo não aparece de forma alguma na lista de modelos do site — nenhuma colocação em arena e nenhuma reprodução por terceiros. As avaliações da ficha usaram o gpt-5.6-luna como juiz e simulador de usuário o tempo todo, o que é divulgado, mas não é independente. Leia os números como uma alegação do fornecedor com um apêndice excepcionalmente detalhado.

A tabela tem 18 linhas e cinco colunas: a prévia do Raon-1 mini contra Qwen3.6-35B-A3B e Gemma 4 26B-A4B como pares MoE, com Qwen3.8-27B e Muse Glimmer 30B mostrados como referências densas. O destaque em vermelho da KRAFTON marca a melhor pontuação dentro do grupo MoE, o que é uma alegação mais restrita do que "melhor" e é por isso que a frase de imprensa sobre superar "modelos estrangeiros de tamanho semelhante" exige cuidado.

Contado corretamente, o Raon-1 mini é o melhor absoluto de todas as cinco colunas em quatro linhas:

• AA-Omniscience — 3,5, em comparação com −7,2 do Qwen3.6-35B-A3B, −0,5 do Qwen3.8-27B, −34,7 do Muse Glimmer 30B e −46,6 do Gemma 4 26B-A4B. É a única pontuação positiva da coluna, o que diz algo real sobre calibração, embora o número absoluto seja pequeno.

• IFBench — 84,2, contra 82,4 do Qwen3.8-27B e 66,6 do Qwen3.6-35B-A3B. Uma diferença de 17,6 pontos em relação ao seu par MoE mais próximo no seguimento de instruções é o resultado individual mais forte da tabela.

• LiveCodeBench v6 — 81,6, à frente de 81,2, 83,4, 79,3 e 77,4. Margem estreita, e uma vitória por quatro décimos de ponto sobre o Qwen3.6-35B-A3B.

• Chatbot em coreano — 92,9, contra 90,6, 90,1, 87,0 e 74,5. Este é o benchmark interno da própria KRAFTON, explicitamente não divulgado publicamente, portanto é o número menos verificável da página e aquele em que se apoia o posicionamento do modelo.

Ele também lidera o grupo MoE no GPQA Diamond (84,3) e no SWE-Verified (70,8, sua maior margem em agentes de codificação, com 7,6 pontos à frente do Qwen3.6-35B-A3B), embora perca ambos para o Qwen3.8-27B, com 89,7 e 74,6. Esse padrão — supera sua própria categoria de peso, mas perde para o modelo denso uma categoria acima — se repete por toda a tabela.

As perdas não são marginais e se concentram em um único lugar:

• Terminal-Bench Lite — 47,0. Esta é a pior pontuação em sua própria linha de comparação, 16,3 pontos atrás do Qwen3.6-35B-A3B e 23,7 atrás do Muse Glimmer 30B.

• MMLU Pro — 76,5, o último dos cinco, 9,4 pontos atrás do Qwen3.6-35B-A3B.

• BFCL v4 — 59,8, atrás de todos os três rivais MoE e densos, exceto Muse Glimmer, ou seja, chamada de função não é onde este modelo se destaca.

• AutomationBench — 29,7, à frente apenas dos 24,9 do Qwen3.6-35B-A3B e 29 pontos atrás do Qwen3.8-27B.

• GDP.pdf — 5,8, pouco acima do 3,6 do Gemma 4 26B-A4B.

Em suma, o resumo honesto é mais restrito e mais útil do que o comunicado à imprensa: o Raon-1 mini é competitivo em seguir instruções, conversação em coreano, calibração e navegação no estilo de busca, e é fraco em recuperação de conhecimento, trabalho em terminal e chamada de ferramentas. Se sua carga de trabalho for um agente que precisa encadear chamadas de função de forma confiável, a tabela argumenta contra ele. Se for um assistente em coreano de contexto longo que segue instruções com precisão, a tabela argumenta a favor de um teste.

O que o pull request do vLLM propôs, e do que ele voltou atrás

O pull request veio de um fork da KRAFTON — branch feat/raon-public-candidate para vllm-project/vllm:main — e a própria nota do autor explica o encerramento melhor do que qualquer inferência: "Estou trabalhando para deixar o código simples e limpo. Quando estiver pronto, reabrirei este PR." O corpo do PR também revela que o OpenAI Codex auxiliou na implementação e que "a revisão humana linha por linha e a confirmação de validação ponta a ponta ainda estão pendentes."

O que ele continha importa, ainda que não tenha sido aceito, porque é um mapa do que é preciso para levar esta arquitetura para o upstream:

• Registro do modelo e da configuração, além do carregamento de checkpoint para as 18 camadas RDA e as 7 camadas NoPE MLA.

• adaptadores de parser de raciocínio e de chamadas de ferramentas do raon_1 — a peça que torna o modelo utilizável por trás de um endpoint compatível com OpenAI, em vez de uma API de conclusão bruta.

• Reutilização dos caminhos MXFP8/NVFP4 do ModelOpt upstream, de MLA, do tratamento de estado híbrido e das interfaces DFlash2, sem forçar backend de MoE.

• Kernels opcionais raon_fast para RDA e mHC, além de testes de configuração e de parser e documentação.

Aproximadamente metade do trabalho foi validada e a outra metade não foi, e o PR diz isso claramente. Aprovado: 11 testes de configuração de CPU e de parser, hooks do pre-commit, build e instalação de wheel com base exata, importações nativas de modelo, tokenizer e parser, verificações de integridade de checkpoint fixado, pareamento de configuração target/draft e resolução de configuração de precisão mista NVFP4. Pendente, nas palavras do próprio PR: "geração real em GPU, comparações numéricas/de qualidade de modelo, execução de backend/kernel, regressões de KDA compartilhado, correção de DFlash2/cache/grafo e benchmarks de serving." Ele acrescenta: "Nenhuma alegação de ganho de velocidade ou de paridade com produção é feita."

As restrições de kernel são o detalhe com maior probabilidade de prejudicar uma equipe que lê "suporte a vLLM" e assume que ele escala. Os kernels rápidos opcionais exigem SM10x — hardware da classe Blackwell — além de paralelismo tensorial de exatamente um, histórico de convolução em BF16, estado recorrente em FP32 e uma cadeia de ferramentas de compilação CUDA/C++. Paralelismo de pipeline, paralelismo de especialistas e RecoverSSM não são suportados. Na prática, isso significa que o caminho rápido é um caminho de GPU única, o que é consistente com toda a proposta do modelo, mas incompatível com a forma como a maioria das pessoas realmente serve um modelo de 28.8B.

O que você pode correr esta semana

A KRAFTON distribui seu próprio fork do vLLM fixado no ref raon-1-mini-preview, documentado para uma NVIDIA B300 e servido por meio de uma API compatível com OpenAI com chamada de ferramentas. A inicialização documentada usa --max-model-len 262144. Todas as rotas abaixo são da própria KRAFTON, e nenhuma delas é upstream:

• vLLM — instale a partir de github.com/krafton-ai/vllm no ref fixado com VLLM_USE_PRECOMPILED=1. Este é o único caminho para os adaptadores de parser do fork e o suporte ao DFlash2.

• Transformers — 5.16.1 com accelerate 1.15.0, device_map="auto" e offload de CPU viável em uma GPU de 32 GB.

• RTX 5090 — o checkpoint NVFP4, contexto de 32.768 tokens, 2.048 tokens em lote, 8 sequências e um cache KV FP8 de 3 GiB; requer o CUDA Toolkit 13 com o nvcc presente.

• DGX Spark — um contêiner ARM64 em ghcr.io/krafton-ai/raon-vllm-spark:sm121-4e09534, executando contexto de 128K com no máximo 8 sequências.

• llama.cpp — uma branch da KRAFTON e uma build GGUF Q4_K_M, com o suporte upstream listado como pendente.

• MLX — mlx 0.32.4 e mlx-lm 0.32.2 com o checkpoint MLX separado.

O modelo de rascunho de decodificação especulativa merece uma nota porque 2,18× é o número que será citado. A KRAFTON mediu isso em uma única B300 com um modelo alvo MXFP8 e vLLM 0.28.0 com tamanho de bloco 8, e descreve como "até" 2,18× maior vazão de saída do que a decodificação autorregressiva, variando conforme o hardware e a carga de trabalho. Esse é um benchmark de fornecedor em hardware que a maioria dos leitores não tem. É também o tipo de alegação que depende fortemente da taxa de aceitação, que depende da distribuição dos seus prompts.

A amostragem não usa os padrões habituais e vale a pena copiá-la exatamente: temperature 1.0, top_p 0.95, top_k 20, sem penalidade de repetição ou frequência, e penalidade de presença 0 para programação e matemática, contra 1.5 para todo o resto. O modo de pensamento vem ativado por padrão, e o cartão desaconselha desativá-lo. Se errar a penalidade de presença, você vai concluir que o modelo é pior do que realmente é.

Uma ressalva operacional que nada tem a ver com qualidade: um pin de fork é uma decisão de cadeia de suprimentos. Você recebe a build da KRAFTON do vLLM, não o release train upstream — sem CI upstream na sua configuração, sem patches de segurança upstream até alguém fazer rebase, e toda atualização do vLLM se torna um merge em vez de um bump de versão. Para um modelo de prévia em avaliação, esse é um trade-off razoável. Para uma dependência de produção, é a coisa a colocar no registro de riscos ao lado do próprio modelo.

Como testá-lo sem apostar nele

O Raon-1 mini não está no catálogo do OrcaRouter, e nada aqui deve ser interpretado como uma afirmação em contrário — não o disponibilizamos. O que disponibilizamos é o seu conjunto de comparação, que por acaso é o grupo de controlo adequado: Gemma 4 26B-A4B a $0.06 por milhão de tokens de entrada e $0.33 por milhão de tokens de saída, Qwen3.6-35B-A3B a $0.248 e $1.485, e Qwen3.8-27B a $0.33 e $2.40, todos ao preço de tabela do fornecedor, sem acréscimo. Esses são os modelos com os quais foi medido, acessíveis através de uma única chave, o que torna barato o experimento útil: executar os próprios prompts da KRAFTON nas baselines alojadas e executar os mesmos prompts na pré-visualização local, e ver se a tabela do fornecedor resiste aos seus dados.

Isso é um uso melhor de uma semana do que ficar lendo a tabela com mais esforço. A instalação do fork leva uma tarde; a comparação é o que diz se um modelo com 4,3B ativos, com vantagem de 17,6 pontos no IFBench e desvantagem de 16,3 pontos no Terminal-Bench, se encaixa na sua carga de trabalho. Se uma baseline hospedada já está recebendo tráfego, roteá-la ao lado do preview por um único endpoint com failover automático significa que um checkpoint não comprovado nunca fica sozinho no caminho crítico — a avaliação pode rodar no formato de produção sem o risco de produção.

O que mudaria esta avaliação?

Quatro coisas, em ordem aproximada de consequência.

Uma integração upstream no vLLM, porque transforma um pin de fork em um número de versão e leva o modelo para todas as ferramentas downstream de empacotamento, quantização e serving que pressupõem suporte mainline. A KRAFTON disse que reabrirá o PR quando o código estiver pronto; a lista pendente de validação de GPU no PR fechado é uma descrição justa do que "pronto" precisa significar.

Uma avaliação independente, porque dezoito linhas de fornecedores julgadas por um único modelo são a opinião de um autor em escala. O resultado do AA-Omniscience é o número mais interessante da tabela justamente porque é o tipo de coisa que uma estrutura de avaliação independente confirmaria ou destruiria rapidamente.

O lançamento completo e o relatório técnico, porque uma prévia sem a contagem divulgada de tokens de treinamento não pode sustentar nenhuma alegação sobre eficiência de treinamento, e eficiência é todo o argumento. Até isso sair, "treinado do zero" é uma declaração sobre proveniência, não sobre custo.

E um endpoint hospedado com um preço publicado, porque agora a única maneira de usar o Raon-1 mini é executá-lo, e a única maneira de precificá-lo é amortizar suas próprias horas de GPU.

Por enquanto, a descrição precisa é curta. O Raon-1 mini é um modelo real, baixável, Apache-2.0, com 28,8B no total/4,3B ativos, lançado em 21 de outubro, com uma história de KV-cache genuinamente interessante, uma tabela de benchmarks do fornecedor que o favorece em quatro linhas e o embaraça em três, uma stack de serving que existe apenas como um fork da KRAFTON, e um pull request upstream que durou 184 segundos. Isso é mais útil do que "a KRAFTON acabou de lançar um modelo de fronteira de graça" ou "nada para ver até o vLLM fazer o merge".