Modelos K2 Horizon: Apache 2.0, MoVA e custos de auto-hospedagem

Uma família com seis modelos, de 0.9B a 375B, parece cobrir todos os degraus de implantação. Na prática, a conta é menos simples. A licença Apache 2.0 do K2 Horizon elimina a cobrança de licença do modelo; a MoVA reduz a computação ativa; mas nenhuma das duas elimina os custos de armazenamento, cache KV, runtime ou hardware.

O que vem no lançamento de seis modelos sob Apache 2.0

A IFM anunciou o K2 Horizon em 3 de setembro de 2026 como uma família integrada de seis modelos: 375B-A23B, 36B-A4B, 32B, 7B, 3.7B e 0.9B. Segundo o anúncio, os modelos e o código são disponibilizados sob Apache 2.0, enquanto os datasets seguem suas licenças aplicáveis (anúncio da IFM).

Uma família de seis modelos, mas com estágios de lançamento diferentes

Os seis integrantes da família são:

A família compartilha arquitetura e ferramentas de implantação, com exceção do modelo 0.9B, que usa um vocabulário menor. Essa base comum foi pensada para simplificar a migração ou o roteamento entre os diferentes tamanhos (comunicado da IFM).

Há uma ressalva importante sobre a maturidade dos lançamentos: o card oficial do K2-Horizon-32B identifica o checkpoint visível como Stage1 e informa que o checkpoint final ainda será lançado. Já os cards do MoVA 36B-A4B e do 375B-A23B descrevem seus checkpoints finais como disponibilizados. Portanto, é correto dizer que há “seis modelos anunciados”, mas não que existam “seis checkpoints finais, em igualdade de condições para produção” (card do modelo 32B, card do modelo 375B).

O que a Apache 2.0 resolve — e o que ela não resolve — para quem hospeda o próprio modelo

A Apache 2.0 permite modificar, redistribuir e integrar comercialmente o modelo e seu código sem cobrança por token. A IFM informa que os datasets seguem seus próprios termos, como ODC-BY, e que fontes restritas talvez não possam ser redistribuídas diretamente (anúncio da IFM).

A Apache 2.0 tira da equação a licença, não a conta operacional. Aluguel ou depreciação de GPUs, armazenamento dos pesos, capacidade de cache KV, engenharia de runtime, monitoramento e revisão de segurança continuam custando dinheiro. Além disso, a receita de serving do 36B e o card do 375B usam trust_remote_code=True nos exemplos.

Os seis tamanhos sob a ótica da memória

Os números de parâmetros ajudam a comparar a capacidade dos modelos, mas o armazenamento bruto dos pesos é a primeira limitação de uma implantação própria. As estimativas abaixo consideram dois bytes por parâmetro em BF16 e meio byte por parâmetro em uma representação idealizada de 4 bits. Elas não incluem metadados, buffers do runtime, cache KV, arquivos do tokenizer nem memória do sistema operacional.

\*O card do 7B chama o modelo de “7B-core”, enquanto os metadados do Hugging Face exibem 9B parâmetros. Para planejar capacidade, use os arquivos reais do repositório, e não apenas o rótulo da família (card do modelo 7B).

Os repositórios concretos mostram por que esses valores são pisos, e não promessas. O GGUF BF16 do 0.9B aparece listado com 2.16 GB; o do 3.7B, com 10.1 GB; o GGUF BF16 Stage1 do 32B, com 69.6 GB; e o GGUF BF16 do MoVA 36B, com 74.9 GB (GGUF do 0.9B, GGUF do 3.7B, GGUF do 32B, GGUF do 36B).

Modelos de edge: 0.9B, 3.7B e 7B

Os modelos 0.9B e 3.7B reduzem ao máximo o armazenamento e servem melhor a cargas de trabalho restritas e bem definidas do que a agentes que exigem muitas tentativas de recuperação (card do modelo 0.9B, card do GGUF 3.7B).

Para um primeiro experimento local, o 7B é a opção mais bem documentada da família: seu card cobre parsers de raciocínio e chamadas de ferramentas, uma configuração de paralelismo de tensor em dispositivo único e variantes quantizadas. A tabela de benchmarks exibida informa 70.6% no SWE-bench Verified, 39.1% no Terminal-Bench 2.1 e 25.8% no tau3-Banking, mas todos os resultados usam alto esforço de raciocínio, e o card alerta que os detalhes do protocolo podem variar (card do modelo 7B).

O card do 7B recomenda alto esforço de raciocínio e pelo menos 32,768 tokens de saída. Um raciocínio mais longo aumenta o tempo de geração e pode tornar caro, em tempo de execução, um modelo que cabe na memória.

Para workstation e servidor: 32B e 36B-A4B

O 32B é totalmente denso e mais simples de avaliar, mas seu status Stage1 e o GGUF oficial de 69.6 GB são as restrições reais para o planejamento (GGUF Stage1 do 32B).

O MoVA 36B-A4B propõe outra questão: um modelo com computação ativa muito menor consegue se aproximar da capacidade de um modelo denso enquanto preserva uma capacidade total maior? A tabela de benchmarks no GGUF da IFM aponta 26.8% no tau3-Banking e 58.6% no Terminal-Bench 2.1, no qual ele lidera o conjunto de comparação listado. Ainda assim, não lidera todas as métricas de ciência, factualidade ou contexto longo (card de benchmarks do GGUF 36B).

Depois que os pesos já estão residentes, o menor número de parâmetros ativos pode melhorar o throughput sustentado. O resultado, porém, depende de backend, batching, interconexão e quantização.

O modelo de ponta: 375B-A23B

O card oficial documenta uma configuração validada no SGLang para o K2 Horizon 375B-A23B com oito GPUs H200, paralelismo de tensor de 8, paralelismo de especialistas de 8, BF16 e FlashAttention-3 (card do modelo 375B).

A relação entre parâmetros totais e ativos pode reduzir a computação em comparação com um modelo denso de 375B, mas o piso aproximado de planejamento de 750GB em BF16 ainda define o limite de infraestrutura. A Artificial Analysis lista 47 pontos no Intelligence Index e a posição #11 de 112 na classe exibida, mas não informa velocidade de saída nem custo por tarefa para o modelo (perfil na Artificial Analysis).

Com base no perfil validado atualmente documentado com oito H200, trate-o como uma implantação em escala de cluster.

MoVA muda a economia da computação, não o piso de armazenamento

MoVA significa Mixture-of-Value Attention. Arquiteturas convencionais de mixture-of-experts normalmente aplicam roteamento esparso nas camadas feed-forward. A IFM descreve a MoVA como uma extensão do roteamento de especialistas ao componente de valor da atenção, mantendo compatibilidade com técnicas como FlashAttention e grouped-query attention (explicação de arquitetura da IFM).

O que o nome 36B-A4B realmente indica

O nome “36B-A4B” comunica duas quantidades distintas: há aproximadamente 36B de parâmetros totais disponíveis, enquanto cerca de 4B são ativados para cada token. Isso pode reduzir o trabalho de multiplicação e acumulação e o tráfego de memória no caminho ativo, especialmente em cargas com geração sustentada.

Isso não significa que os especialistas não usados deixam de existir. O arquivo GGUF oficial tem 74.9 GB em BF16, e a receita do vLLM descreve um modelo com 37.44B de parâmetros armazenados, incluindo embeddings, e 5.95B de parâmetros ativos por token. Esses números são formas de empacotar e contabilizar a mesma arquitetura, não evidência de um modelo separado de 37B (receita do vLLM).

Um modelo mental útil é:

1. Capacidade residente: o armazenamento e a memória precisam comportar os pesos que podem ser selecionados.
2. Computação ativa: cada token aciona apenas um subconjunto roteado.
3. Estado de runtime: cache KV, buffers temporários, batching e overhead do framework continuam existindo.
4. Custo do sistema: interconexão, energia, RAM do host e tempo operacional determinam a conta.

Por que o destaque de 512K de contexto não é um orçamento

Os cards do K2 Horizon anunciam contexto nativo de 524,288 tokens nos modelos maiores. Ainda assim, as receitas publicadas do vLLM para o MoVA 36B-A4B e o 375B-A23B configuram --max-model-len 131072, um quarto desse máximo anunciado (receita vLLM do 36B, card do modelo 375B).

As receitas de 131K deixam claro que servir contexto nativo de 512K não é uma configuração gratuita: contextos mais longos consomem cache KV, reduzem a concorrência e aumentam a latência do prompt.

Cenários de auto-hospedagem com custos

O K2 Horizon não tem um preço de API universal e transparente que sirva como referência. A página oficial do GGUF MoVA informa que nenhum provedor de inferência disponibiliza o modelo no momento, enquanto a Artificial Analysis mostra preços de entrada e saída de $0.00 para o perfil 375B, mas marca velocidade e custo por tarefa como indisponíveis. Isso não é evidência de um endpoint de produção gratuito (card do GGUF MoVA, Artificial Analysis).

Um experimento em GPU de 24GB

O piso idealizado em 4 bits para um modelo de 36B é de cerca de 18GB, restando menos de 6GB em uma placa de 24GB para metadados de quantização, buffers de runtime e cache KV. Essa conta torna plausível um teste em GPU da classe de 24GB com contexto moderado, mas não estabelece um mínimo universal: a quantização exata, o backend, a política de offload e o tamanho do prompt ainda definem se a execução será utilizável.

O artefato oficial GGUF MoVA citado é BF16, e não uma quantização pequena para consumidor. A coleção no Hugging Face lista variantes GGUF e FP8 em toda a família, mas o trabalho de conversão e compatibilidade no dia do lançamento continua fazendo parte do orçamento de implantação (coleção K2 Horizon).

“I assume they are still uploading other GGUFs--all I see is a BF16 GGUF so far” — u/apoptosist em r/LocalLLaMA.

Duas H200 para o caminho 36B documentado

A receita MoVA da IFM para vLLM usa paralelismo de tensor de 2, paralelismo de especialistas, BF16 e limite de serving de 131,072 tokens. A documentação do SGLang informa que a configuração foi validada em 2× H200, um sinal de hardware mais relevante que o nome do modelo isoladamente (receita do vLLM, card oficial do GGUF).

As tarifas publicadas por provedores mostram por que a utilização importa. A DigitalOcean lista uma NVIDIA H200 dedicada por $4.47 por GPU-hora e uma configuração com 8× H200 por $35.78 por hora. O Google Cloud lista uma máquina A3 Ultra com 8× H200 por $84.806908493 por hora, com vCPUs, memória e SSD conectados incluídos no preço do tipo de máquina (preços da DigitalOcean, preços do Google Cloud).

Na tarifa listada por GPU, duas H200 equivalem a cerca de $8.94 por hora ou $6,526 por mês de 730 horas, antes dos custos de host e armazenamento. Use isso apenas como referência sensível à utilização, não como cotação para duas GPUs.

Oito H200 para o 375B-A23B

A receita oficial de serving do modelo de ponta usa oito H200, TP=8, EP=8 e BF16. Essa configuração condiz com o piso aproximado de planejamento de 750GB em BF16 do modelo e deixa explícito o limite de entrada para uso empresarial (card do modelo 375B).

O preço listado pelo Google para uma máquina com 8× H200, de $84.81 por hora, corresponde a cerca de $61,909 por 730 horas, antes de impostos, transferência de dados, armazenamento persistente e operação da aplicação. É uma referência de infraestrutura, não um preço do K2 Horizon nem uma garantia de que a receita publicada alcance determinada taxa de tokens por segundo.

O que as primeiras evidências de auto-hospedagem provam — e o que não provam

Os primeiros relatos mostram que o K2 Horizon pode ser executado, mas quantizações e runtimes variados ainda não estabelecem uma curva universal de custo versus desempenho.

Um relato detalhado no X ilustra bem o quanto o backend pode mudar o resultado:

“36B-A4B MoVA does 131-142 tok/s on 2x 5090 with llama.cpp (IFM's fork, Q8_0, 131K ctx) vs 52 on vLLM...” — @abtraore_.

Esse relato útil, mas não controlado, mostra por que dizer apenas que “a MoVA é mais rápida” é insuficiente sem informar backend e configuração.

Discussões no Reddit apontam dúvidas em aberto sobre quantização, pouca VRAM, comparações e chamadas de ferramentas, e não desempenho validado (thread no r/LocalLLaMA).

Para tomar uma decisão séria de compra, ainda faltam medições de memória residente por quantização, crescimento do cache KV por contexto, velocidade de prompt e geração, confiabilidade nas chamadas de ferramentas, consumo de energia e custo por tarefa concluída sob uma mesma carga de trabalho controlada.

Escolha pelo nível de utilização, não pelo marketing de parâmetros ativos

O modelo K2 Horizon certo depende de com que frequência ele vai rodar, de quanto contexto precisa e de a qualidade de sua saída justificar a infraestrutura. Um piloto curto deve priorizar a reversibilidade; um serviço privado sempre ativo deve priorizar utilização e estabilidade operacional.

Antes de trocar de modelo em um primeiro piloto, registre cinco valores: pico de VRAM/RAM, tamanho do prompt, tempo até o primeiro token, tokens gerados por segundo e custo por tarefa concluída. Mantenha o limite de contexto nos 131,072 tokens documentados até que a carga de trabalho prove que ir além vale o custo de cache e latência.

Se a dúvida é qual integrante da família cabe em determinada máquina, o guia de dimensionamento dos modelos K2 Horizon aborda esse problema mais específico de seleção. Esta página prioriza utilização e custo medido por tarefa, em vez de rótulos de parâmetros ativos.

Perguntas frequentes sobre os modelos K2 Horizon

Apache 2.0 significa que todos os datasets do K2 Horizon também são Apache 2.0?

Não. A IFM informa que os modelos e o código usam Apache 2.0, enquanto os datasets seguem as licenças aplicáveis, como ODC-BY. Verifique cada repositório e dataset antes de redistribuir ou usar em treinamento comercial (anúncio da IFM).

Ter 4B ativos significa que o K2 Horizon MoVA 36B-A4B precisa da memória de um modelo 4B?

Não. O modelo ativa aproximadamente 4B de parâmetros por token, mas seu GGUF oficial em BF16 tem cerca de 74.9GB. Armazenamento dos pesos, cache KV, buffers de runtime, overhead de quantização e concorrência determinam a exigência real de memória.

Uma única GPU de 24GB pode rodar o K2 Horizon MoVA 36B-A4B?

Uma quantização adequada em 4 bits pode tornar plausível um experimento com contexto moderado, porque o piso idealizado de pesos para 36B é de aproximadamente 18GB. O artefato oficial em BF16 e o caminho de serving validado com duas H200 exigem bem mais margem, portanto um resultado em 24GB deve ser tratado como configuração de piloto, e não como garantia geral para produção.

É econômico servir os 512K de contexto anunciados?

Não automaticamente. Os cards dos modelos indicam contexto nativo de 524,288 tokens, enquanto os exemplos documentados no vLLM usam 131,072 tokens. Contextos mais longos aumentam a demanda por cache KV e a latência, além de frequentemente reduzirem a concorrência.

O K2 Horizon 375B-A23B é um modelo normal para auto-hospedagem?

Não. A IFM documenta uma configuração SGLang com oito H200, e o piso de planejamento em BF16 bruto é de aproximadamente 750GB antes do overhead de runtime. Trate-o como uma implantação empresarial ou em cluster, salvo se um provedor publicar uma configuração menor validada.

O preço de $0.00 exibido para o K2 Horizon 375B representa uma API gratuita de verdade?

Não há base para essa conclusão. A Artificial Analysis mostra preços de entrada e saída de $0.00, mas lista velocidade e custo por tarefa como indisponíveis, enquanto a página oficial do modelo não tem um provedor de inferência no Hugging Face. Antes de usar esse número no orçamento, verifique o contrato e a tabela de preços de um provedor identificado.