MOSS-Image vs Krea 3: Um Cobra por Imagem, o Outro Cobra por Hora

Os dois modelos nesta comparação têm preços em moedas diferentes, e é por isso que a comparação óbvia — seis centavos contra zero — é a errada. K​rea 3, lançado em 15 de outubro de 2026, é um modelo de edição hospedado com uma tarifa publicada: $0,06 por imagem em 2K nativo, menos de oito segundos de ponta a ponta segundo a medição do próprio fornecedor. M​OSS-Image, lançado pela OpenMOSS em 16 de outubro de 2026 como os checkpoints Apache 2.0 M​OSS-Image-Base e M​OSS-Image-SFT, não tem tarifa nenhuma. Você aluga uma GPU e paga por hora, não importa se gera uma imagem nela ou quatrocentas.

A verdadeira questão não é qual deles é mais barato. É como sua carga de trabalho se comporta ao longo de um mês, porque uma taxa fixa por imagem e uma tarifa por hora se cruzam em um volume que depende inteiramente da sua própria utilização. Abaixo desse ponto de cruzamento, K​rea é melhor em custo e enormemente melhor em latência. Acima dele, o custo marginal por imagem do M​OSS-Image se aproxima do custo da eletricidade. Quase ninguém faz as contas, e é isso que define a decisão inteira.

Os dois querem uma caixa, e querem em unidades diferentes.

Comece pela parte que os torna minimamente comparáveis, porque é fácil passar despercebido. Nenhum deles é um gerador de 'prompt and pray'. O ferramental de edição do Krea 3 inclui caixas delimitadoras para posicionar novos elementos e edições multiturno que mantêm o contexto entre turnos. O formato de layout do MOSS-Image usa um objeto JSON como prompt — um summary bloco mais um items array em que cada elemento carrega um rótulo de text, character ou object, uma legenda, uma caixa delimitadora e, para elementos de texto, a string literal a renderizar.

• De onde vem a caixa — MOSS-Image: um campo JSON em cada item do prompt de layout, usando bbox_format: "yxyx" em bbox_coord_space: "abs_centralized", ou seja, pixels absolutos medidos a partir do centro da tela. Krea 3: um controle de caixa delimitadora em sua interface de edição para posicionar novos elementos.

• {{1}}Resolução de saída{{/1}} — M​OSS-Image: treinado em 256px, 512px e aproximadamente 1024², com o orçamento de tokens passando de 576 → 3.072 → 8.192. K​rea 3: 2K nativo, com exemplos citados em 2736 × 1536 px, e 1K pela metade do preço.

• Imagens de referência — M​OSS-Image: os elementos são descritos estruturalmente no prompt de layout, em vez de serem fornecidos como imagens de referência. K​rea 3: até seis por edição no post de lançamento, oito na página do produto — o material do próprio fornecedor apresenta dois números e nenhum deles foi retirado.

• O que você está construindo — M​OSS-Image: uma composição, a partir de uma especificação, em grande parte do nada. K​rea 3: uma edição em uma imagem que você já tem, com a região fora da edição deixada intacta.

Essa última linha é a que decide a maioria das cargas de trabalho reais. Se o seu trabalho é "pegar esta foto de produto e trocar o fundo", o MOSS-Image é a ferramenta errada — ele não é um editor in-place, e seu fornecedor classifica o comportamento de edição como experimental. Se o seu trabalho é "produzir quatrocentos pôsteres únicos com textos específicos em locais específicos", o Krea 3 é a ferramenta errada, e seu próprio material é fraco em textos longos — seus exemplos de lançamento são em inglês, seus pontos fortes documentados são mudanças de cena de produto, remoção de objetos e limpeza de fotos.

Velocidade, em que apenas um lado publicou algo

O número de destaque da K​rea 3 fica abaixo de oito segundos por edição, de ponta a ponta, em 2K. É um dado de fornecedor, e o fornecedor é incomumente aberto sobre de onde ele veio: os tempos são o tempo mediano entre solicitação e resultado do lote de doze imagens de cada modelo, incluindo o tempo de fila, medidos na própria plataforma da K​rea entre 24 de setembro e 1º de outubro de 2026. Uma metodologia impressa no benchmark vale mais do que um número isolado, e este a tem. Ainda é a K​rea medindo a K​rea.

MOSS-Image não tem nenhum valor de latência publicado, e vale a pena perceber porquê antes de encarar isso como uma omissão. As predefinições de amostragem são flow-matching Euler com 50 passos, CFG 3,0, shift 5,0 e orientação por salto de camadas no ramo negativo na camada 22. O percurso de orientação predefinido precisa de dois forwards do transformer por passo. A latência do MOSS-Image não é, portanto, uma propriedade do modelo como acontece com um endpoint alojado — é uma propriedade da GPU que lhe colocamos por baixo, do número de passos que escolhemos e de optarmos por dispensar a orientação ou por correr destilação. A comunidade disponibilizou quantizações INT8 e INT4, um LoRA DMD de 4 passos e uma variante destilada de 8 passos cerca de um dia após o lançamento, o que mostra que as pessoas acharam o padrão de 50 passos demasiado lento para trabalho interativo e trataram do assunto por conta própria.

Então, a comparação honesta em termos de velocidade é: K​rea 3 informa um número que depende da K​rea, e M​OSS-Image não tem número porque depende de você. Uma configuração padrão de 50 passos com duas passagens diretas por passo não é rápida. Uma versão destilada de 8 passos em uma placa de vídeo alugada pode ser. Nenhuma dessas afirmações é verificável na página de qualquer fornecedor, e a segunda pode ser verificada por você em uma tarde.

A aritmética da revisão, que é onde os seis centavos deixam de importar

Aqui está o cálculo que muda a decisão, e ele parte do próprio enquadramento da Krea.

A US$ 0,06 por edição, rodar cinco passagens e escolher a melhor custa trinta centavos e nenhuma reunião. Essa é a proposta implícita da K​rea, e é boa, porque a alternativa a uma nova tentativa barata é uma hora de designer. Cem mil edições por mês em 2K custam US$ 6.000 — e a K​rea deixa explícito que o preço de lançamento é o preço de tabela e que espera que o preço caia, em vez de subir, o que faz dos US$ 6.000 um teto, e não um piso.

O lado da MOSS-Image da mesma aritmética não é uma taxa, é um problema de utilização. A licença é Apache 2.0 sem limiar de receita, e existe, para referência, um modelo de pesos abertos a $0,008 por imagem na vizinhança desta comparação, de um fornecedor diferente — mas não é assim que o caminho aberto funciona. O download é de cerca de 27,2 GB, dos quais aproximadamente 16,8 GB distribuídos por quatro shards correspondem ao codificador de texto Qwen3.5-9B congelado e cerca de 10,2 GB distribuídos por três correspondem ao transformer. O selo 5B descreve apenas o gerador de difusão e o codificador é a metade maior da pegada em disco.

Se isso supera seis cêntimos depende de três números que você já conhece: sua tarifa por hora de GPU, suas imagens por hora no número de passos que decidir e que fração do mês a placa fica realmente ocupada. Uma equipe que mantém uma linha de produção constante terá um baixo custo efetivo por imagem e deve hospedar. Uma equipe que precisa de quarenta imagens na tarde de terça-feira não deve alugar uma GPU para isso, e não deve fingir que o preço da licença é o preço da imagem.

A alegação de ajuste fino, que ambos os lados fazem e nenhum dos dois provou

Esta é a seção que uma comparação de especificações geralmente deixa passar, e é a coisa mais interessante que esses dois modelos têm em comum.

A alegação da Krea é que o Krea 3 é o primeiro modelo de edição que você pode ajustar para um produto específico, uma pessoa ou um estilo, de modo que o packshot de uma marca ou um personagem recorrente permaneça o mesmo ao longo de uma campanha. O mecanismo é verificável — a referência da API traz um endpoint "Train a custom style (LoRA)" — e se o "primeiro" se sustenta é uma afirmação sobre o setor, e não uma medição. É uma alegação da Krea. Mas o mecanismo existe, está documentado e é o único caminho publicado do lado da Krea para fixar um sujeito.

O equivalente da OpenMOSS é estrutural, e não comercial. O Base é o checkpoint pré-treinado, deliberadamente deixado sem destilação — a ficha do modelo declara explicitamente que nenhum pós-treinamento ou destilação de parâmetros de inferência como o CFG foi aplicado, a fim de preservar as informações de treinamento e manter o treinamento com LoRA viável. Isso é um fornecedor optando por entregar uma configuração padrão pior em troca de um substrato de treinamento melhor, e é o sinal mais claro em todo o lançamento sobre para quem se destina o checkpoint Base.

As duas alegações apontam para o mesmo comprador: alguém com um sujeito recorrente que não pode sofrer drift. Nenhum dos fornecedores publicou uma medição de drift, e os builds da comunidade em torno do M​OSS-Image — o empacotamento para ComfyUI, as quantizações, as LoRAs destiladas — chegaram em cerca de um dia, o que indica que o caminho de treinamento é real, embora nenhum resultado de treinamento tenha sido publicado pelo fornecedor.

• Onde o LoRA fica — K​rea 3: um endpoint hospedado na plataforma da K​rea, treinado sobre o modelo da K​rea na infraestrutura da K​rea. M​OSS-Image: seus próprios pesos, sua própria execução de treinamento, sua própria GPU, com um checkpoint que o fornecedor deixou deliberadamente em um estado treinável.

• O que isso te custa — K​rea 3: a conversa sobre treinamento é uma conversa sobre licença. M​OSS-Image: a conversa sobre treinamento é a sua conta de luz e a semana de alguém.

• O que isso te devolve — K​rea 3: um estilo que você pode chamar, na disponibilidade de outra pessoa. M​OSS-Image: um checkpoint que é seu, que continua funcionando se o fornecedor for embora.

Acesso, e onde um roteador se encaixa em um pipeline de duas ferramentas

O K​rea 3 é fechado. A K​rea já lançou pesos abertos antes — K​rea 2 RAW e Turbo estão no Hub — mas o K​rea 3 não está entre eles, e o FAQ da K​rea coloca a auto-hospedagem sob planos empresariais, nas suas próprias GPUs, com termos de licença e dimensionamento de hardware a serem discutidos. Portanto, é uma decisão. M​OSS-Image é um download, e o download é o produto inteiro.

Nenhum dos dois está no catálogo da OrcaRouter — servimos mais de 200 modelos e nenhum desses dois está entre eles — portanto, ambos implicam recorrer à fonte: para K​rea 3, a API própria da K​rea e várias plataformas de terceiros; para M​OSS-Image, os repositórios e o seu próprio hardware.

O que o roteador tem de útil em um pipeline como este é a parte que não é nenhum dos dois modelos. Colocar um elemento em um frame costuma ser uma etapa de um trabalho que também precisa de um gerador hospedado para a imagem base, de um modelo separado para upscaling e de uma passada de geração de legendas ou avaliação — e é aí que um endpoint para algumas centenas de modelos com failover automático e preços de tabela dos provedores repassados com 0% de markup eliminam o trabalho de integração, em vez do trabalho com o modelo. A DSL de roteamento importa pelo mesmo motivo: se a etapa da imagem base e a etapa de edição são dois modelos diferentes, fixar cada uma por requisição em uma única configuração é melhor do que manter dois SDKs de fornecedores. É a infraestrutura de base, e a arquitetura do próprio M​OSS-Image é um lembrete do quanto essa infraestrutura vale em relação ao modelo — o resultado de layout ponta a ponta mais forte do fornecedor foi produzido por um pipeline cuja metade de especificação de prompt roda inteiramente em um modelo de terceiros.

Qual deles, e o crossover que decide isso

Opte pelo Krea 3 se o entregável for uma edição de uma imagem existente, se a sua equipe mede a própria latência em minutos e se o seu volume for irregular o suficiente para que uma GPU alugada fique ociosa na maior parte do mês. Seis centavos com um tempo de ida e volta inferior a oito segundos, uma história de precisão documentada e um endpoint LoRA na própria infraestrutura do fornecedor é um produto coerente para essa tarefa, e o fato de o preço de lançamento ser declarado como o preço de tabela significa que a economia dificilmente vai piorar. Entre sabendo que todos os números de desempenho associados a ele são do próprio Krea, que a contagem de referências é documentada de duas maneiras e que ele não carrega nenhuma pontuação independente de qualquer tipo — o que é toda a explicação para a sua ausência dos rankings, já que foi lançado no dia anterior à coleta da pesquisa deste artigo.

Escolha o MOSS-Image se você estiver produzindo imagens compostas a partir de uma especificação em volume constante, se uma bounding box em um prompt JSON for mais adequada ao seu pipeline do que uma caixa na UI de outra pessoa, ou se possuir o checkpoint for um requisito e não uma preferência. Apache 2.0 sem limite de receita torna a revisão jurídica curta, o checkpoint Base é deliberadamente treinável, e o esquema de layout é uma especificação de verdade. Vá sabendo que a latência depende de você, que o encoder é a maior parte do download, que as quantizações da comunidade existem porque o padrão de 50 passos é lento, e que nenhum dos benchmarks do fornecedor foi reproduzido por ninguém.

O ponto de virada não é um mistério. Divida o custo mensal da sua GPU pela quantidade de imagens por mês e compare o resultado com seis centavos. Se você não consegue estimar imagens por hora com confiança, essa incerteza é a resposta: alugue K​rea por um mês, gere o volume que você realmente espera e deixe a fatura dizer se vale a pena construir o caminho aberto. É um experimento mais barato do que alugar uma placa por um mês para descobrir.

As falhas documentadas de IA e os incidentes com agentes por trás de lançamentos como este estão reunidos em o OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, gravidade, grau de confiança e sinalização de contestação.