PAN 2 vs LFM2.5-2.6B-Base : deux types de checkpoints que vous êtes censé affiner

La première chose à remarquer à propos de LFM2.5-2.6B-Base, c’est le mot Base. Le checkpoint de 2,69 milliards de paramètres de Liquid AI n’est pas un modèle avec lequel on discute ; c’est le substrat pré-entraîné à partir duquel sont fabriquées les variantes post-entraînées LFM2.5-2.6B, publié pour que d’autres puissent fabriquer les leurs. PAN 2 est le même type d’objet à trente fois l’échelle : un transformateur de diffusion de 29 milliards de paramètres de l’Institute of Foundation Models de MBZUAI, publié sous Apache-2.0 avec les configurations d’entraînement dans le dépôt, destiné à être adapté plutôt que simplement consommé. Côte à côte, ils semblent absurdes — l’un est un modèle de langage que l’on peut exécuter sur un ordinateur portable, l’autre un modèle du monde vidéo qui réclame quatre B300. Mais les deux sont des artefacts de base avec une licence attachée, et pour quiconque a pour métier réel de prendre un checkpoint et de le faire faire quelque chose pour quoi il n’a pas été entraîné, la comparaison intéressante n’est pas du tout celle des capacités. C’est ce que chacun vous donne pour travailler, et ce qu’il en coûte de garder la chose pendant que vous le découvrez.

Commencez par la licence, car c'est la seule différence vraiment indiscutable.

Le code et les poids propres à PAN 2 sont sous Apache-2.0. Les composants tiers — Qwen3.5-9B comme encodeur de texte, Wan 2.2 comme VAE, Diffusers — sont utilisés selon leurs propres conditions et ne sont pas redistribués par MBZUAI ; vous les téléchargez auprès de leurs auteurs. Il s’agit d’un arrangement net, sans surprise et adapté aux exigences juridiques des entreprises, et c’est la principale raison pour laquelle une entreprise disposant d’un processus de revue peut adopter PAN 2.

LFM2.5-2.6B-Base est publié sous licence LFM1.0, que Hugging Face répertorie comme other avec un lien vers le fichier LICENSE plutôt qu'un identifiant SPDX. Ce n'est pas une critique — la licence de Liquid autorise l'usage commercial jusqu'à un seuil de chiffre d'affaires, ce qui est une forme courante et raisonnable pour une publication à poids ouverts — mais c'est une forme différente d'Apache-2.0, et la différence n'est pas un détail que l'on découvre après le fine-tuning. Si votre équipe juridique dispose d'une liste de licences préapprouvées, l'un de ces deux modèles y figure et l'autre nécessite une discussion.

Cette asymétrie va dans le sens inverse de celui du nombre de paramètres, et cela mérite qu’on s’y attarde. Le minuscule modèle est celui qui a des ficelles ; l’énorme est celui qu’on peut livrer sans demander la permission à quiconque.

Ce qu’un checkpoint de base vous fournit réellement

LFM2.5-2.6B-Base est une architecture hybride : trente couches, dont vingt-deux sont des blocs de convolution courte à double porte et huit sont de l’attention à requêtes groupées. Ce mélange est tout l’intérêt de la gamme LFM — les blocs de convolution sont peu coûteux sur de longues longueurs de séquence et les blocs d’attention préservent la capacité de rappel — et c’est pourquoi le modèle peut prendre en charge un contexte de 131 072 jetons avec 2,69 milliards de paramètres. L’entraînement a porté sur 34 000 milliards de jetons sur un vocabulaire de 128 000 jetons, avec une couverture de seize langues, dont l’arabe, le japonais, le coréen, le thaï et le vietnamien.

Ce qui lui manque, c’est tout post-entraînement. Pas de réglage par instructions, pas de gabarit de conversation digne de ce nom, pas d’alignement de sécurité. Un modèle de base prédit le token suivant et ne fait que cela, ce qui en fait le mauvais choix pour une évaluation sur un benchmark de suivi d’instructions et le bon pour évaluer la vitesse à laquelle un LoRA converge sur votre domaine. Liquid publie séparément la version sœur post-entraînée, et l’existence de builds GGUF et ONNX de cette version sœur est la déclaration d’intention la plus claire : cette famille est faite pour tourner sur des appareils que vous possédez.

PAN 2 vous fournit nettement plus d’échafaudage, et moins de liberté d’une manière bien précise. Le dépôt fournit des configurations d’entraînement pour le pré-entraînement et le fine-tuning supervisé — config/pretrain_29B_720p.yaml et config/sft_29B_720p.yaml — et la documentation vous indique de pointer leurs chemins de données vers vos propres latents. La voie du fine-tuning existe donc. Mais les données qu’elle attend ne sont pas du texte. Ce sont des latents vidéo annotés dans un format de légende structuré spécifique : événements dans l’ordre, actions liées à des acteurs, mouvement de caméra, dans une limite de 1 536 tokens pour l’encodeur de texte. Si vous voulez fine-tuner PAN 2 sur votre domaine, votre premier projet n’est pas une exécution d’entraînement. C’est un pipeline de données qui transforme vos séquences vidéo en ce format, et le dépôt vous fournit un validateur mais pas l’annotateur.

• Puissance de calcul pour l’affinage — LFM2.5-2.6B-Base : un seul GPU, LoRA sur une station de travail, en heures plutôt qu’en semaines. PAN 2 : un transformeur de 67,37 GB en BF16 avant l’état de l’optimiseur, plus un encodeur gelé de 15,87 GB et un VAE, sur des latents vidéo. Multi-nœuds, et personne n’a publié de recette.

• Données que vous devez fournir — LFM2.5-2.6B-Base : du texte, dans le format utilisé par votre tâche. PAN 2 : vidéo et légendes structurées de l’état du monde selon le schéma du dépôt.

• Ce que vous obtenez en sortie — LFM2.5-2.6B-Base : un générateur de texte et, après post-entraînement, un assistant ou une politique d’agent. PAN 2 : une vidéo allant jusqu’à 20 secondes en 704×1248 et à 24 fps, montrant la conséquence d’une action.

• Licence — LFM2.5-2.6B-Base : LFM1.0, autre, à lire. PAN 2 : Apache-2.0 sur ses propres poids.

Sur le seul benchmark où ils se rejoignent presque

Il existe un véritable chevauchement, et il est assez petit pour être intéressant. La fiche modèle MiniCPM5-2B d’OpenBMB compare LFM2.5-2.6B à son propre modèle 2B et à plusieurs autres, et l’une des lignes concerne le contexte long. Sur AA-LCR, OpenBMB rapporte 5,3 pour LFM2.5-2.6B contre 59,0 pour MiniCPM5-2B. Sur NoLiMa, 0,7 contre 68,1. Sur LongBench v2, 30,3 contre 43,7.

Ce sont des chiffres rapportés par un concurrent, sur le harnais d’évaluation d’un concurrent, et la fiche modèle qui les publie a un intérêt évident dans la comparaison. Mais l’ampleur de l’écart sur les deux sondes de contexte long les plus difficiles n’est pas le genre de chose qu’un choix de harnais suffit à expliquer, et c’est un correctif utile à la lecture de « contexte de 131 072 tokens » comme revendication de capacité. Une fenêtre de contexte est une capacité ; le rappel sur longue distance est un comportement. Le checkpoint Base possède la première et, selon des éléments tiers, pas beaucoup du second — c’est précisément pourquoi un fine-tune est l’usage prévu, plutôt qu’un assistant pour documents longs directement prêt à l’emploi.

PAN 2 n’a pas de contre-vérification équivalente. Personne en dehors de MBZUAI ne l’a évalué sur des benchmarks, et les chiffres de sa propre fiche modèle sont les seuls qui existent. C’est une position probante plus faible que celle de LFM2.5-2.6B-Base, même si le modèle est cent fois plus cher à exécuter — un rappel que l’évaluation indépendante suit l’adoption, et que l’adoption suit la capacité à pouvoir l’exécuter tout court.

Le coût de conservation de chaque point de contrôle

LFM2.5-2.6B-Base compte environ 2,7 milliards de paramètres. En BF16, cela représente confortablement moins de 6 Go de poids, et les versions GGUF de son homologue post-entraîné le ramènent bien en dessous. Vous pouvez le garder résident sur la même machine que le reste de votre stack, le fine-tuner pendant la nuit et oublier qu’il est là.

PAN 2 fait 86,17 Go répartis sur soixante fichiers, et le nombre qui compte n’est pas le total mais la forme. Le transformateur fait 67,37 Go et chaque worker d’inférence en détient une copie complète — le script d’inférence du dépôt exécute un worker par GPU, chacun prenant chaque Nième prompt, car il n’y a pas de partitionnement tensor-parallel dans ce chemin. La recette vLLM est l’option partitionnée, et son argument phare est treize secondes de vidéo 704×1248 en environ 119 secondes sur quatre B300s avec un parallélisme du classifier-free guidance sur deux rangs et un parallélisme de séquence Ulysses sur deux. La configuration par défaut est de huit H200s. Un échantillonneur à cinquante étapes avec guidage à chaque étape implique cent passes avant par clip, et c’est l’arithmétique derrière chaque choix de configuration dans la recette.

Ainsi, la comparaison honnête des coûts n’est pas « 6 Go contre 86 Go ». C’est « un coût marginal nul par inférence contre un nœud multi-GPU pour deux minutes de sortie ». Un modèle 2,6B affiné qui répond à une requête ne coûte rien de mesurable. Un PAN 2 affiné qui génère un clip de vingt secondes coûte un nœud GPU pendant trois minutes, et vous devrez l’exécuter des centaines de fois avant de savoir si l’affinage a fonctionné.

Là où un routeur touche l'un ou l'autre de ces éléments

Aucun des deux modèles ne peut être servi par une couche de routage. LFM2.5-2.6B-Base est un checkpoint de base sans point de terminaison hébergé qui vaille la peine d’y router — c’est un fichier que vous téléchargez. PAN 2 n’a aucun point de terminaison hébergé, ni de MBZUAI ni de qui que ce soit d’autre. Si votre plan implique l’un ou l’autre, votre plan implique des GPU.

La raison de mentionner le routage malgré tout, c'est que presque personne ne déploie un modèle de base isolément. Un LFM2.5 affiné n'est qu'un composant d'une application qui a aussi besoin d'un raisonneur général, et une simulation PAN 2 n'est qu'une étape d'un pipeline dont la première étape est un modèle de langage qui rédige des légendes structurées. C'est cette couche environnante qui rend utile une API unique pour plus de 200 modèles : vous conservez le checkpoint affiné sur votre propre matériel, vous acheminez les appels courants via OrcaRouter au prix catalogue du fournisseur avec 0 % de marge, répercutée telle quelle, et vous obtenez un basculement automatique lorsqu'un fournisseur traverse un mauvais moment. Pour un pipeline PAN 2 en particulier, l'étape de légendage est la partie élastique — le rapport classe Claude Opus 5.5, GPT-6 Astra, Kimi K3 et Qwen3.8-Flash selon l'achèvement complet des plans, et Qwen3.8-Flash est disponible sur OrcaRouter, vous pouvez donc tester quel planificateur termine réellement vos plans sans provisionner quatre modèles.

Ce qu’OrcaRouter ne fera pas, c’est héberger l’un ou l’autre des checkpoints. Prétendre le contraire serait le genre d’affirmation qui ressemble à une fonctionnalité et se comporte comme un bug.

Ce que le cadrage « modèle de base » dissimule

Ces deux versions publiées sont, au sens strict, inachevées. LFM2.5-2.6B-Base n’a pas été ajusté sur instructions, par conception ; PAN 2 comporte une section sur les limites qui indique qu’environ deux plans simulés sur trois contiennent au moins une étape qui n’est pas exécutée. Ni l’un ni l’autre n’est un produit. La différence tient à ce que « inachevé » signifie dans chaque cas.

Pour LFM2.5-2.6B-Base, « inachevé » désigne une étape d’un pipeline dont le fournisseur a déjà mené à terme les étapes en aval — le modèle post-entraîné existe, les versions quantifiées existent, et le checkpoint de base est publié pour ceux qui souhaitent prendre une autre direction. Cet écart est délibéré et documenté.

Pour PAN 2, l'inachèvement est l'état de toute la version. Les poids sont disponibles, la prise en charge du framework a été livrée le 10 novembre, et la seule chose qui ait été dite publiquement à son sujet est une publication de deux paragraphes sur le compte X du laboratoire lui-même, l'après-midi même. Ses limites ne sont pas un choix de conception transmis aux utilisateurs en aval ; ce sont des problèmes ouverts que l'équipe nomme en public. Si vous fine-tunez PAN 2, vous héritez de ces problèmes en même temps que les poids.

C’est là la vraie comparaison, et elle ne débouche pas sur une recommandation entre les deux modèles, car ils ne sont pas interchangeables. Elle débouche sur une question concernant votre projet : adaptez-vous un composant éprouvé, ou construisez-vous sur un artefact de recherche dont les modes de défaillance sont encore en cours de mesure ? LFM2.5-2.6B-Base correspond au premier. PAN 2 correspond au second, et la licence Apache-2.0 est la seule raison pour laquelle le second est même une option.