PAN 2 vs LFM2.5-2.6B-Base: Dois tipos de checkpoint feitos para você fazer fine-tuning

A primeira coisa que se nota em LFM2.5-2.6B-Base é a palavra Base. O checkpoint de 2,69 bilhões de parâmetros da Liquid AI não é um modelo com o qual você conversa; é o substrato pré-treinado a partir do qual as variantes pós-treinadas do LFM2.5-2.6B são feitas, publicado para que outras pessoas possam criar as suas. O PAN 2 é o mesmo tipo de objeto em trinta vezes a escala: um transformer de difusão de 29 bilhões de parâmetros do Institute of Foundation Models da MBZUAI, publicado sob Apache-2.0 com configurações de treinamento no repositório, feito para ser adaptado, e não apenas consumido. Lado a lado, eles parecem absurdos — um é um modelo de linguagem que você pode rodar em um laptop, o outro é um modelo de mundo de vídeo que exige quatro B300s. Mas ambos são artefatos base com uma licença atrelada e, para qualquer pessoa cujo trabalho de fato seja pegar um checkpoint e fazê-lo fazer algo para o que ele não foi treinado, a comparação interessante não é a capacidade em absoluto. É o que cada um oferece para você trabalhar, e quanto custa manter a coisa enquanto você descobre.

Comece pela licença, porque é a única diferença difícil.

O código e os pesos do próprio PAN 2 são Apache-2.0. As peças de terceiros — Qwen3.5-9B como codificador de texto, Wan 2.2 como VAE, Diffusers — são usadas sob seus próprios termos e não são redistribuídas pela MBZUAI; você as baixa dos autores. Esse é um arranjo limpo, sem surpresas e amigável para o jurídico corporativo, e é o principal motivo pelo qual uma empresa com processo de revisão consegue adotar o PAN 2.

O LFM2.5-2.6B-Base é lançado sob a licença LFM1.0, que o Hugging Face registra como outra com um link para o arquivo LICENSE em vez de um identificador SPDX. Isso não é uma crítica — a licença da Liquid permite uso comercial até um limite de receita, o que é um formato comum e razoável para um lançamento de pesos abertos — mas é um formato diferente do Apache-2.0, e a diferença não é um detalhe que você descobre depois do ajuste fino. Se sua equipe jurídica tem uma lista de licenças pré-aprovadas, um desses dois modelos está nela e o outro precisa de uma conversa.

Essa assimetria segue na direção oposta à das contagens de parâmetros, e vale a pena refletir sobre isso. O modelo minúsculo é o que tem amarras; o enorme é o que você pode distribuir sem pedir nada a ninguém.

O que um checkpoint base realmente lhe entrega

LFM2.5-2.6B-Base é uma arquitetura híbrida: trinta camadas, das quais vinte e duas são blocos de convolução curta com duplo gate e oito são atenção com consultas agrupadas. Essa mistura é o ponto central da linha LFM — blocos de convolução são baratos em comprimentos de sequência longos e blocos de atenção preservam a capacidade de recuperação — e é por isso que o modelo consegue suportar um contexto de 131.072 tokens com 2,69 bilhões de parâmetros. O treinamento foi até 34 trilhões de tokens com um vocabulário de 128.000 tokens, com cobertura para dezesseis idiomas, incluindo árabe, japonês, coreano, tailandês e vietnamita.

O que ele não tem é qualquer pós-treinamento. Nenhum ajuste por instruções, nenhum template de chat que mereça o nome, nenhum alinhamento de segurança. Um modelo base prevê o próximo token e é só isso que ele faz, o que o torna a coisa errada para avaliar em um benchmark de seguimento de instruções e a coisa certa para avaliar quão rapidamente um LoRA converge no seu domínio. A Liquid publica a versão irmã pós-treinada separadamente, e a existência de builds GGUF e ONNX dessa versão irmã é a declaração de intenção mais clara: esta família é para rodar em dispositivos que você possui.

O PAN 2 oferece bem mais estrutura pronta e, de uma forma específica, menos liberdade. O repositório traz configs de treinamento tanto para pré-treinamento quanto para ajuste fino supervisionado — config/pretrain_29B_720p.yaml e config/sft_29B_720p.yaml — e a documentação orienta você a apontar os caminhos de dados delas para seus próprios latentes. Então o caminho de ajuste fino existe. Mas os dados que ele espera não são texto. São latentes de vídeo anotados em um formato específico de legenda estruturada: eventos em ordem, ações vinculadas a atores, movimento de câmera, dentro de um orçamento de 1.536 tokens do codificador de texto. Se você quiser ajustar o PAN 2 de forma fina no seu domínio, seu primeiro projeto não é uma execução de treinamento. É um pipeline de dados que transforma suas filmagens nesse formato, e o repositório fornece um validador, mas não o anotador.

• Computação para o ajuste fino — LFM2.5-2.6B-Base: uma única GPU, LoRA em uma estação de trabalho, horas e não semanas. PAN 2: um transformer de 67,37 GB em BF16 antes do estado do otimizador, além de um encoder congelado de 15,87 GB e um VAE, em latentes de vídeo. Multinó, e ninguém publicou uma receita.

• Dados que você deve fornecer — LFM2.5-2.6B-Base: texto, em qualquer formato que sua tarefa utilize. PAN 2: vídeo mais legendas estruturadas de estado do mundo no esquema do repositório.

• O que você obtém — LFM2.5-2.6B-Base: um gerador de texto e, após pós-treinamento, um assistente ou uma política de agente. PAN 2: um vídeo de até 20 segundos em 704×1248 e 24 fps, mostrando a consequência de uma ação.

• Licença — LFM2.5-2.6B-Base: LFM1.0, outra, leia-a. PAN 2: Apache-2.0 nos seus próprios pesos.

No único benchmark em que eles quase se igualam

Há uma sobreposição genuína, e ela é pequena o suficiente para ser interessante. O model card do MiniCPM5-2B da OpenBMB compara o LFM2.5-2.6B com seu próprio modelo 2B e com um conjunto de outros, e uma das linhas é contexto longo. No AA-LCR, a OpenBMB reporta 5,3 para o LFM2.5-2.6B contra 59,0 para o MiniCPM5-2B. No NoLiMa, 0,7 contra 68,1. No LongBench v2, 30,3 contra 43,7.

Esses são números relatados por um concorrente em um harness de um concorrente, e o model card que os publica tem um interesse óbvio na comparação. Mas a magnitude da diferença nas duas sondas de contexto longo mais difíceis não é o tipo de coisa que a escolha de um harness explique, e é um corretivo útil para não ler "contexto de 131.072 tokens" como uma alegação de capacidade. Uma janela de contexto é uma capacidade; a recuperação em comprimento é um comportamento. O checkpoint Base tem a primeira e, com base em evidências de terceiros, não tem muito da segunda — o que é precisamente por isso que um fine-tune é o uso pretendido, e não um assistente para documentos longos pronto para uso imediato.

O PAN 2 não tem verificação cruzada equivalente. Ninguém fora da MBZUAI o avaliou como benchmark, e os números do próprio model card são os únicos que existem. Essa é uma posição probatória mais fraca do que a do LFM2.5-2.6B-Base, mesmo que o modelo seja cem vezes mais caro de executar — um lembrete de que a avaliação independente acompanha a adoção, e a adoção acompanha a capacidade de simplesmente executar o modelo.

O custo de manter cada checkpoint

O LFM2.5-2.6B-Base tem cerca de 2,7 bilhões de parâmetros. Em BF16, isso fica confortavelmente abaixo de 6 GB de pesos, e as builds GGUF da versão irmã pós-treinada o deixam bem abaixo disso. Você pode mantê-lo residente na mesma máquina que o resto da sua stack, ajustá-lo durante a noite e esquecer que ele está lá.

PAN 2 tem 86,17 GB distribuídos em sessenta arquivos, e o número que importa não é o total, mas a forma. O transformer tem 67,37 GB e cada worker de inferência mantém uma cópia completa — o próprio script de inferência do repositório executa um worker por GPU, cada um pegando cada N-ésimo prompt, porque não há sharding de tensor-parallel nesse caminho. A receita do vLLM é a opção com sharding, e seu destaque é treze segundos de vídeo 704×1248 em cerca de 119 segundos em quatro B300s, com paralelismo de classifier-free-guidance em dois ranks e paralelismo de sequência Ulysses em dois. O padrão é oito H200s. Um sampler de cinquenta passos com guidance a cada passo significa cem passagens forward por clipe, e essa é a aritmética por trás de cada escolha de configuração na receita.

Portanto, a comparação honesta de custos não é "6 GB versus 86 GB". É "custo marginal zero por inferência versus um nó multi-GPU por dois minutos de saída". Um modelo de 2.6B com ajuste fino respondendo a uma consulta não custa nada mensurável. Um PAN 2 com ajuste fino renderizando um clipe de vinte segundos custa um nó de GPU por três minutos, e você o executará centenas de vezes antes de saber se o ajuste fino funcionou.

Onde um roteador toca qualquer um destes

Nenhum dos dois modelos é algo que uma camada de roteamento possa atender. O LFM2.5-2.6B-Base é um checkpoint base sem endpoint hospedado que valha a pena rotear — é um arquivo que você baixa. O PAN 2 não tem endpoint hospedado nenhum, da MBZUAI ou de qualquer outro. Se seu plano envolve um deles, seu plano envolve GPUs.

O motivo de mencionar o roteamento de qualquer forma é que quase ninguém implanta um modelo base isoladamente. Um LFM2.5 com fine-tuning é um componente de uma aplicação que também precisa de um raciocinador geral, e uma simulação PAN 2 é uma etapa de um pipeline cuja primeira etapa é um modelo de linguagem escrevendo legendas estruturadas. É nessa camada ao redor que uma API única para mais de 200 modelos vale a pena: você mantém o checkpoint ajustado no seu próprio hardware, roteia as chamadas de uso comum pelo OrcaRouter ao preço de tabela do provedor com 0% de markup repassado, e conta com failover automático quando um provedor está tendo um momento ruim. Especificamente para um pipeline PAN 2, a etapa de legendas é a parte elástica — o relatório classifica Claude Opus 5.5, GPT-6 Astra, Kimi K3 e Qwen3.8-Flash por conclusão de plano completo, e o Qwen3.8-Flash está no OrcaRouter, então você pode testar qual planejador realmente conclui seus planos sem provisionar quatro modelos.

O que o OrcaRouter não fará é hospedar qualquer um dos dois checkpoints. Dizer o contrário seria o tipo de afirmação que soa como um recurso e se comporta como um bug.

O que o enquadramento do modelo-base esconde

Ambos os lançamentos são, em sentido estrito, inacabados. O LFM2.5-2.6B-Base não tem ajuste de instruções por design; o PAN 2 tem uma seção de limitações que afirma que cerca de dois em cada três planos simulados contêm pelo menos uma etapa que não é executada. Nenhum dos dois é um produto. A diferença está no que “inacabado” significa em cada caso.

Para o LFM2.5-2.6B-Base, “inacabado” é uma etapa de um pipeline que o fornecedor já concluiu a jusante — o modelo pós-treinado existe, as versões quantizadas existem, e o checkpoint base é publicado para quem quiser divergir. A lacuna é intencional e documentada.

Para o PAN 2, o inacabado é o estado do lançamento inteiro. Os pesos estão disponíveis, o suporte ao framework chegou em 10 de novembro, e a única coisa que alguém disse publicamente sobre ele é uma publicação de dois parágrafos na conta X do próprio laboratório na mesma tarde. Suas limitações não são uma escolha de design repassada aos usuários downstream; são problemas em aberto que a equipe está nomeando publicamente. Se você fizer fine-tuning do PAN 2, herdará esses problemas junto com os pesos.

Essa é a comparação real, e ela não resulta em uma recomendação entre os dois modelos porque eles não são substitutos. Ela resulta em uma pergunta sobre o seu projeto: você está adaptando um componente de qualidade comprovada ou está construindo sobre um artefato de pesquisa cujos modos de falha ainda estão sendo medidos? O LFM2.5-2.6B-Base é o primeiro. O PAN 2 é o segundo, e a licença Apache-2.0 é o único motivo pelo qual o segundo é sequer uma opção.