Ce qu'est réellement LongCat 2.0
Meituan est le géant chinois de la livraison de repas et des services locaux, et LongCat est son équipe de modèles internes. LongCat 2.0 est arrivé le 30 juin 2026 en successeur de la gamme LongCat-Flash, et Meituan avait retiré six modèles Flash un mois plus tôt pour lui faire de la place.
L'architecture, selon la fiche du modèle, est un mixture of experts de 1,6T de paramètres avec environ 48B activés par token. Elle intègre 135B de paramètres d'embedding N-gram héritées de LongCat-Flash-Lite, que Meituan décrit comme un moyen d'étendre la capacité selon des dimensions parcimonieuses orthogonales au routage du MoE. Le pré-entraînement a porté sur plus de 35 billions de tokens sur « des millions de jours-accélérateur », sans retour en arrière ni pic de perte irrécupérable.
La pièce architecturale phare est LongCat Sparse Attention, que Meituan présente comme une correction de deux problèmes identifiés dans le Lightning Indexer utilisé par DeepSeek V3.2 : la discontinuité de sortie et un goulot d'étranglement quadratique au niveau du scoring. Elle comporte trois volets. Streaming-aware Indexing remodèle le budget de sélection des tokens pour des lectures mémoire contiguës. Cross-Layer Indexing réutilise une même passe d'indexation sur deux couches adjacentes. Hierarchical Indexing effectue un rappel grossier au niveau des blocs avant la sélection fine des tokens.
Ce troisième point mérite une note. Une version antérieure de la documentation de déploiement indiquait que Hierarchical Indexing « n'est pas prise en charge, par souci de simplicité », et le commit 5ced4db a supprimé cette ligne, avec 41 autres lignes d'instructions de lancement concrètes, plutôt que de la corriger. L'article de lancement indique par ailleurs que la fonctionnalité est « activée pour certaines tâches à contexte ultra-long », pas à chaque requête.
Je construis des intégrations et des connexions d'API chez eesel depuis quelques années, et mon réflexe face à ce genre de lancement est de zapper l'annonce et d'aller directement voir les fichiers. Quatre affirmations n'y ont pas résisté.
La fenêtre de contexte de 1M est en réalité de 256K dans la configuration
Le README de Meituan met en avant une fenêtre native de 1M de tokens, et le changelog répète la même chose. Le fichier config.json livré fixe max_position_embeddings à 262 144. YaRN est prévu jusqu'à 983 040 au-delà de cette limite, si bien que le chiffre de 1M décrit ce sur quoi le modèle a été entraîné plutôt que ce que la configuration publiée va réellement servir.
L'API hébergée de Meituan ajoute un second plafond : 128K de tokens de sortie maximum, et max_tokens est compté dans la fenêtre de contexte. Ce n'est pas un scandale, et 256K reste une fenêtre large par n'importe quel étalon. Ce n'est simplement pas le chiffre du marketing.
Le dépôt GitHub, c'est un README
github.com/meituan-longcat/LongCat-2.0 contient README.md, LICENSE et un dossier figures/ avec trois images. C'est tout le dépôt, environ 1 Mo, aucun langage détecté, zéro tag ni release. Les poids se trouvent sur Hugging Face, l'inférence passe par SGLang, et il n'existe nulle part de harnais d'évaluation ni d'implémentation de référence.
Il n'y a pas non plus de papier de recherche. Meituan a publié un billet de blog de lancement et rien d'autre, ce que la communauté a remarqué immédiatement :
"The description of LSA and N-Gram in that blog is imo quite surface-level. Thats why i was asking whether there is/will be a full paper."
Ce fil est ouvert depuis le 5 juillet sans aucune réponse de qui que ce soit chez meituan-longcat. Le lancement jumeau LongCat-Flash-Omni a bien eu droit à un vrai papier, donc c'est un choix plutôt qu'une limite de capacité.
Il n'existe aucun chemin Transformers fonctionnel
Le fichier config.json livré n'a pas de clé model_type, ce qui fait échouer aussi bien AutoConfig que AutoModelForCausalLM. On obtient le tokenizer et rien d'autre. C'est l'issue ouverte n°4, toujours ouverte au moment où j'ai vérifié.
SGLang est le seul moteur pris en charge, et même là c'est rudimentaire : l'entrée du cookbook demande d'installer une version nightly parce que la PR SGLang a été fermée sans être fusionnée. Il n'y a ni chemin vLLM ni chemin TensorRT-LLM.
L'histoire du matériel, confrontée aux propres mots de Meituan
C'est la partie du lancement qui a le plus circulé, et celle où la couverture médiatique et la source primaire divergent le plus.
Le nombre de puces est réel. Meituan l'écrit clairement dans son billet de lancement :
"LongCat-2.0 is pre-trained on over 50K AI ASICs, introducing significant system-level challenges due to both model and cluster scale. We address these challenges through systematic optimizations, achieving over 35% training throughput improvement while also enhancing reliability compared to a naive implementation."
Ce qui ne figure pas dans le billet, c'est le reste de l'histoire telle qu'elle a été racontée ensuite. Les mots « domestic », « China » et « Chinese » n'apparaissent jamais. Aucun fabricant de puces n'est nommé, ni Huawei, ni Cambricon, ni Hygon, et aucune référence interne non plus. Le cadrage propre à Meituan est « plateformes matérielles alternatives ». Nvidia apparaît exactement deux fois, les deux fois comme point de référence plutôt que comme démenti : une fois pour noter que « comparé à l'écosystème mature des GPU Nvidia, la communauté logicielle de support est encore moins développée », et une autre pour observer que « nos accélérateurs ont beaucoup moins de mémoire par appareil qu'un H800 (80 Go) ».
Un matériel non-Nvidia est la lecture naturelle. Cela reste une lecture. L'identification du Ascend 910C qui a ancré le fil Hacker News vient d'un commentateur, pas de Meituan :
"This is the real news story. It looks like they may have used Huawei Ascend 910C chips"
Ce fil a atteint 281 points et 88 commentaires, et le contre-argument le plus tranchant qu'on y trouve porte sur l'échelle plutôt que sur l'authenticité :
"1024 Huawei Ascend superpods = 50K 910C chips.
That is a tiny tiny system. OpenAI uses milions of GPUs for training"
Il y a encore une incohérence dans les propres chiffres de Meituan. Une phrase dit « plus de 50K ASIC IA ». La section suivante parle de « dizaines de milliers de superpods d'ASIC IA », alors que le billet définit un superpod comme « jusqu'à 48 machines chacun ». Les deux ne peuvent pas être littéralement exacts en même temps. Si l'on cite un chiffre, mieux vaut citer la phrase sur le pré-entraînement, qui est la plus précise.
Les deux mois passés sous le nom Owl Alpha
Avant toute annonce, LongCat 2.0 servait discrètement du trafic sur OpenRouter en tant que modèle furtif gratuit appelé owl-alpha, à peu près depuis fin avril 2026 jusqu'à son retrait le 30 juin, jour même où Meituan a publié le billet de lancement. Meituan n'a jamais reconnu ce fait, et ni la fiche du modèle ni le billet de lancement ne mentionnent Owl Alpha.
La communauté a fini par comprendre de toute façon, et les preuves sont toujours sur Reddit. Le premier indice était géopolitique, dans le commentaire le plus voté du fil d'origine sur le modèle furtif :
I think I can confirm Chinese model, it affirmed that Taiwan is part of China.
Puis quelqu'un a testé les deux endpoints côte à côte :
I am ABSOLUTELY certain it's Longcat. I tried both the Longcat 2.0 preview via the Longcat API and the Owl Alfa via Openrouter.
It has the same 10-second response time, the same dialogue, and both has 1M of context
Il y a un petit élément de corroboration caché dans la propre documentation de Meituan, et c'est mon détail préféré de tout le corpus documentaire. L'exemple officiel de reasoning_content sur la page de référence de l'API montre le modèle se désignant lui-même comme « OWL », une trace laissée par un prompt système que personne n'a nettoyé.
Je mentionne cette phase furtive parce qu'elle change la façon de lire les avis. Une bonne partie de l'expérience pratique que les gens ont eue avec ce modèle a été accumulée gratuitement, sur un harnais qu'ils testaient, avant même que quiconque sache ce qu'il évaluait réellement. C'est un retour utilisateur inhabituellement propre, et cela signifie que les témoignages ci-dessous ne sont pas des impressions du jour de lancement.
Ce que disent les benchmarks, et ce qu'ils ne disent pas
Meituan publie dix lignes de benchmarks face à six modèles de comparaison. La réserve figure sur la fiche elle-même : sauf mention d'un astérisque, tous les scores sont mesurés en interne, et la plupart des scores des concurrents sont repris directement des rapports de ces fournisseurs. Ce n'est donc pas un test contrôlé unique.
| Benchmark | LongCat 2.0 | Gemini 3.1 Pro | GPT-5.5 | Claude Opus 4.7 | Claude Opus 4.8 |
|---|---|---|---|---|---|
| Terminal-Bench 2.1 | 70.8 | 70.7 | 73.8 | 71.7 | 78.9 |
| SWE-bench Pro | 59.5 | 54.2 | 58.6 | 64.3 | 69.2 |
| SWE-bench Multilingual | 77.3 | 76.9 | - | 80.5 | 84.8 |
| FORTE | 73.2 | 70.3 | 77.8 | 77.6 | 77.2 |
| BrowseComp | 79.9 | 85.9 | 84.4 | 79.3 | 84.3 |
| RWSearch | 78.8 | 76.3 | 85.3 | 79.3 | 77.3 |
| IFEval | 90.0 | 96.1 | 95.0 | 88.7 | 86.0 |
| Writing Bench | 83.8 | 83.7 | 84.7 | 85.3 | 85.2 |
| IMO-AnswerBench | 81.8 | 90.0 | 79.5 | 81.8 | 75.3 |
| GPQA-diamond | 88.9 | 94.3 | 93.6 | 94.2 | 92.4 |
En lisant les colonnes de haut en bas, la tendance est claire. LongCat 2.0 devance Gemini 3.1 Pro sur les trois lignes liées aux agents de code, et dépasse légèrement GPT-5.5 sur SWE-bench Pro de 0,9 point. Il reste aussi derrière Claude Opus 4.8 sur chaque ligne où 4.8 a un score, avec 9,7 points d'écart sur SWE-bench Pro et 8,1 points sur Terminal-Bench 2.1. Ma lecture : c'est un vrai modèle de codage proche de la frontière, qui bat la génération précédente et ne bat pas l'actuelle.
Deux points de ce tableau méritent d'être signalés avant que quiconque le cite. Meituan indique que SWE-bench a été exécuté avec des « tâches problématiques corrigées », et RWSearch est décrit comme « un benchmark objectif interne », donc deux des dix lignes sont en partie l'instrument propre de Meituan. Et l'ensemble de comparaison ne contient aucun rival à poids ouverts : ni DeepSeek, ni Qwen3.8 Max, ni Kimi K3, ni GLM-5.2. Ce sont pourtant les modèles entre lesquels choisit réellement une équipe qui opte pour des poids ouverts.
Encore une correction tant que j'y suis, car elle circule largement. Anthropic ne publie aucun score SWE-bench pour Claude Opus 5 ni pour Sonnet 5. Le chiffre de 69,2 est celui d'Opus 4.8. Si tu vois 69,2 attribué à Opus 5, c'est une erreur.
Ce que disent les gens qui l'ont vraiment testé
Les verdicts se divisent nettement, et je veux être clair : c'est un vrai désaccord, pas un consensus favorable avec quelques grognements. La tendance générale est que les personnes l'ayant utilisé comme agent dans un harnais l'ont bien noté, et que celles l'ayant jugé comme modèle « intelligent » l'ont mal noté, mais ce schéma ne tient pas parfaitement : au moins un développeur qui l'utilisait uniquement pour du code l'a qualifié de bogué et déconseille de l'utiliser.
Le témoignage le plus substantiel vient de quelqu'un qui y a fait passer 3,6 milliards de tokens pendant la période furtive gratuite :
I used this for over 3.6 billion tokens when it was owl-alpha on Openrouter (with Hermes Agent). It was a very good experience.
It's not as 'smart' as other frontier models when it comes to benchmark style tests (one shots, riddles, etc) but it was very good at (1) following instructions, (2) making a plan, (3) following that plan, and (4) staying coherent at very high contexts. I built a number of apps from start to finish and it performed very well.
Quelqu'un qui a acheté un pack de tokens après le lancement arrive à la même conclusion :
"Not free, but it's so cheap they're basically giving it away. Very impressed too... Not frontier-level intelligence, but a dependable workhorse that can navigate a codebase well and can reliably execute what you tell it to do."
Et la contestation la plus tranchante vient de quelqu'un qui l'utilise en production, s'opposant directement au cadrage donné à ce lancement :
I was using Owl Alpha a lot for my project. Thats not gpt 5.5 level model. it not even close to flash 2.5 model - its not gollowing promts.
Ma lecture d'ensemble : « cheval de trait fiable » est l'étiquette honnête, et elle correspond aussi bien au tableau de benchmarks qu'aux personnes ayant enregistré des milliards de tokens. Le suivi des instructions et la cohérence sur de longs contextes reviennent sans cesse comme des points forts. Le raisonnement brut, non, et la qualité du code reste débattue plutôt que tranchée.
Une autre réaction mérite d'être relevée, car c'est le seul endroit où j'ai vu quelqu'un chiffrer exactement ce à quoi je reviens sans cesse.
Wait, this is Owl Alpha? Now I wish I had tried it when it was available. I stayed away from it back then because of their privacy policy
C'est un développeur qui a lu la politique, tranché, et perdu deux mois d'accès gratuit à un modèle correct à cause de cela. Que ce compromis ait été le bon dépend entièrement de ce qu'il prévoyait d'y envoyer.
Tarification : le vrai tableau
Meituan publie à la fois un prix catalogue et une remise de lancement. La colonne remise est étiquetée « durée limitée » sans qu'aucune date de fin apparaisse nulle part, et la page en chinois qualifie cela d'offre de lancement pour la première sortie de la plateforme. Les deux devises sont des tarifs affichés séparément, pas une conversion de change.
| Item | List USD / 1M | Promo USD / 1M | List CNY / 1M | Promo CNY / 1M |
|---|---|---|---|---|
| Uncached input | $0.75 | $0.30 | ¥5 | ¥2 |
| Cached input (read) | $0.015 | $0.006 | ¥0.10 | ¥0.04 |
| Output | $2.95 | $1.20 | ¥20 | ¥8 |
| Cache write | not published | not published | not published | not published |
| Context tiering | none, flat rate to 1M input | none | none | none |
Deux détails de ce tableau sont plus intéressants que le chiffre en gros titre.
Il n'y a aucun palier tarifaire lié à la longueur de contexte. Tous les autres modèles à fenêtre 1M que j'ai vérifiés facturent davantage au-delà d'un certain seuil : le prix de Gemini 3.1 Pro double au-delà de 200K, GPT-5.6 Sol double au-delà de 272K, et MiniMax-M3 double au-delà de 512K. LongCat 2.0 applique un tarif plat, ce qui rend le travail à contexte long disproportionnellement bon marché sur ce modèle. C'est le fait le moins rapporté de la page tarifaire.
Il vaut aussi la peine de noter ce qu'un tarif plat ne résout pas. Un tarif bon marché sur un modèle qui a besoin de plus de tokens pour arriver à la même réponse n'est pas bon marché, et c'est le piège de toute comparaison de gros titres. La même mise en garde m'a piégé en travaillant sur le prix de GPT-5.6. Elle s'applique tout aussi fort au prix de Gemini 3.6 Flash, et à celui-ci également.
Et les lectures en cache coûtent 1/50e de l'entrée non mise en cache, ce qui semble excellent jusqu'à ce qu'on regarde le corps de la réponse. Il n'y a pas de champ prompt_tokens_details.cached_tokens sur le chemin compatible OpenAI, ni de cache_read_input_tokens sur le chemin compatible Anthropic, et aucun paramètre cache_control pour le piloter. La mise en cache est entièrement implicite et il est impossible de vérifier ce qui a réellement été facturé.
L'avertissement de Meituan mérite d'être cité tel quel : « Prices are subject to change. The prices shown on the LongCat API Platform and your billing records are authoritative. »
Comment il se compare en pratique
C'est ici que le prix promotionnel fait le plus gros du travail. Entre tes propres chiffres.
Fais bouger les chiffres un moment et le tableau devient clair. Au tarif promotionnel, LongCat 2.0 coûte environ un vingtième d'Opus 5 et environ un cinquième du prix de Sonnet 5, ce qui était la comparaison que tout le monde a faite le jour du lancement.
Fais ensuite monter le curseur de cache. Au-delà d'environ 80 % de taux de succès du cache, DeepSeek V4 Pro dépasse LongCat 2.0 même au tarif promotionnel, parce que sa lecture en cache coûte 0,003625 dollar contre 0,006 dollar pour LongCat. Une entrée non mise en cache bon marché n'est pas la même chose qu'un coût bon marché en production, et le travail d'agents à l'échelle d'un dépôt est justement le type de charge où les taux de succès de cache grimpent.
Au prix catalogue, l'image s'inverse. 0,75 dollar en entrée et 2,95 dollars en sortie coûte plus cher que DeepSeek V4 Pro à 0,435 et 0,87 dollar, qui est le jumeau architectural le plus proche de LongCat 2.0 : lui aussi 1,6T de paramètres au total, 49B actifs, contexte de 1M, également sous MIT. Il est aussi battu en entrée par GPT-5.6 Luna à 0,20 dollar, un modèle propriétaire hébergé qu'on peut payer par carte bancaire. Donc la promotion, c'est toute l'histoire du prix, et cette promotion n'a pas de date de fin publiée.
Il existe un second multiplicateur de coût que l'étiquette cache. Le raisonnement est activé par défaut, et les tokens de raisonnement sont facturés au tarif de sortie. Sur le panneau d'usage d'OpenRouter, 2,03M des 2,16M de tokens de complétion pour ce modèle étaient des tokens de raisonnement. Environ 94 % de ce qu'on paie en sortie correspond au modèle qui « réfléchit » plutôt qu'à la réponse qu'on garde vraiment. C'est normal pour un modèle de raisonnement, et c'est tout de même un chiffre qu'on préfère avoir dans son budget plutôt que découvrir sur une facture. Quiconque a déjà fait cet exercice avec Opus 5 face à Sonnet 5 sait déjà à quel point cela fait bouger le coût par tâche.
Ce qui va réellement te freiner
Meituan documente exactement deux canaux de paiement, et les deux n'apparaissent que dans les règles de remboursement : WeChat et Alipay. Pas de carte, pas de PayPal, pas de virement. La facturation en libre-service n'est disponible « que pour les utilisateurs en Chine continentale », et tous les autres doivent envoyer un e-mail à l'équipe.
L'inscription elle-même est ouverte : les utilisateurs hors de Chine continentale peuvent s'inscrire avec une adresse e-mail. Approvisionner le compte est une autre question, et l'API rejette les requêtes dès que le solde atteint zéro. Les Token Packs, l'alternative prépayée, sont vendus en ventes flash chronométrées à 10h00, 16h00, 21h00 et 23h00 heure de Pékin, en stock limité, et expirent après 30 jours calendaires.
La réponse pratique pour la plupart des équipes hors de Chine est donc OpenRouter, une des raisons pour lesquelles le trafic public du modèle passe davantage par des harnais de codage que par la plateforme propre de Meituan. J'y reviens dans un instant sur ce compromis.
L'API : sept paramètres et aucun outil
J'ai lu la documentation de l'API comme je le ferais avant de connecter quoi que ce soit en production, et c'est la section où une opinion façonnée par les benchmarks se transforme en opinion d'ingénieur.
Deux surfaces sont disponibles : un chemin compatible OpenAI et un chemin compatible Anthropic Messages, tous deux sur api.longcat.chat, tous deux acceptant la même clé bearer. Changer l'URL de base de l'un ou l'autre SDK est une modification d'une seule ligne, ce qui est la chose la plus agréable de cette plateforme. Quiconque a déjà comparé les API OpenAI, Anthropic et Gemini sait à quel point c'est rare.
Ensuite, ça se dégrade vite. Sept paramètres au total sont pris en charge : max_tokens, temperature, top_p, stream, tools, tool_choice et thinking. Pas de séquences stop. Pas de seed. Pas de response_format ni de mode JSON. Pas de logprobs, pas de n, pas de pénalités, pas de top_k. temperature va de 0 à 1 au lieu de 0 à 2 chez OpenAI, ce qui fait qu'une configuration transposée directement peut se retrouver hors plage sans avertissement. thinking est binaire, activé ou désactivé, sans budget ni niveau d'effort.
tools et tool_choice figurent dans la liste des paramètres et ne sont documentés nulle part. Pas de schéma, pas de forme de réponse d'appel d'outil, pas d'exemple, malgré le changelog qui vante l'appel d'outils natif. Le jour du lancement, cette lacune s'est manifestée exactement là où on pouvait s'y attendre :
"I can't get any tool calls working. Seems to use a
<longcat_tool_call>wrapper which the current harnesses I'm using don't support"
La fiche du modèle confirme une rupture liée : LongCat attend les arguments d'un appel d'outil sous forme de dictionnaire plutôt que la chaîne JSON que spécifie le schéma OpenAI. Tout ce qui est écrit selon la forme standard a besoin d'une couche d'adaptation.
Les deux couches de compatibilité sont aussi subtilement mal formées, de façon à casser les parseurs stricts. Le raisonnement arrive comme message.reasoning_content sur le chemin OpenAI, qui est un champ de DeepSeek et non d'OpenAI. Sur le chemin Anthropic, il arrive comme une clé thinking à l'intérieur d'un bloc de contenu texte plutôt que comme un vrai bloc de réflexion, et le flux SSE documenté omet content_block_start, content_block_stop et ping.
Il n'y a aucun outil hébergé, de quelque type que ce soit. Pas de recherche web, pas d'interpréteur de code, pas de magasin de récupération, pas de points de terminaison de fichiers, pas d'embeddings, pas d'API par lots. MCP n'est pas mentionné une seule fois, et il n'y a pas de boucle d'agent côté serveur, si bien que le comportement agentique n'est qu'une affirmation sur le modèle, et le faire fonctionner reste entièrement le travail du harnais.
Ce que Meituan documente en revanche, ce sont les intégrations côté client : douze au total, dont Claude Code, Codex, Cline, Kilo Code, OpenCode et Cherry Studio, chacune avec la modification exacte de l'URL de base. Cursor et Roo n'y figurent pas. Si tu vis déjà dans une CLI de codage agentique, c'est la voie de moindre résistance, et c'est là que va réellement le trafic du modèle.
Des limites de débit existent, mais aucun chiffre n'est publié à leur sujet. Le seul chiffre concret dans tout le corpus documentaire est retry_after: 60 dans le corps de la réponse 429. Les requêtes échouées ne sont pas facturées, ce qui est une attention appréciable, et le solde prépayé à l'usage n'expire jamais.
Mon détail préféré de tout le corpus documentaire est petit : l'exemple officiel de reasoning_content montre le modèle se désignant lui-même comme « OWL », un résidu d'un autre prompt système. La documentation est écrite par des humains pressés, et ça se voit.
L'auto-hébergement : le mur
Des poids sous licence MIT pour un modèle à l'échelle de la frontière, c'est un vrai cadeau, et il vient avec une facture matérielle qui décide pour qui ce cadeau est réellement fait.
La version BF16 pèse, selon l'API de blobs Hugging Face, 3,55 To répartis sur 194 shards safetensors. La version FP8 pèse 2,05 To sur 141 shards. Chaque recette SGLang charge du FP8, si bien que le fichier maître de 3,55 To fait plutôt office de source de quantification que de cible de service, et BF16 n'a aucune topologie publiée du tout.
| Hardware | HBM per GPU | GPUs | Nodes | Parallelism |
|---|---|---|---|---|
| NVIDIA B300 | 288 GB | 8 | 1 | TP=8, EP=8 |
| NVIDIA B200 | 192 GB | 16 | 2 | TP=16, EP=16 |
| NVIDIA H200 | 141 GB | 16 | 2 | TP=16, EP=16 |
| NVIDIA H20 | 96 GB | 16 | 2 | TP=16, EP=16 |
| Ascend Atlas A2 | not published | 192 | 12 | 64 prefill, 128 decode |
La ligne 8x B300 est la seule que SGLang marque comme vérifiée, et le calcul explique pourquoi le B200 de 192 Go a tout de même besoin de deux nœuds : 2,05 To de poids FP8 ne rentrent pas dans 8 x 192 Go. La recette H20 est plus étrange encore, car 16 x 96 Go font 1 536 Go contre 2 051 Go de poids, ce qui ne fonctionne que si les tables N-gram et les modules MTP restent hors HBM, et aucun document ne précise que c'est le cas.
Vient ensuite le cache KV. À 43 776 octets par token et avec --mem-fraction-static 0.92 sur 8x B300, il reste environ 69 Go de marge KV une fois les poids chargés. Cela correspond à environ six séquences simultanées sur la fenêtre complète de 256K, ou 64 emplacements avec une moyenne de 24K tokens chacun. La fenêtre de contexte et la concurrence se disputent la même mémoire, et à 1M de contexte, 64 emplacements nécessiteraient 2 802 Go de KV à eux seuls, soit plus que l'ensemble du pool de 2 304 Go.
Les runtimes grand public, c'est non. llama.cpp n'a aucun support fusionné pour LongCat et il n'existe de GGUF pour aucune variante, donc Ollama et LM Studio ne peuvent pas le charger. Les quantifications communautaires qui existent sont réservées à MLX, nécessitent une PR mlx-lm pas encore fusionnée, et la plus petite version avec tous les experts pèse 512 Go, ce qui dépasse un Mac de 512 Go. L'onglet discussion de Hugging Face n'est essentiellement qu'une longue requête répétée :
"GGUF Version please!!!"
r/LocalLLaMA a été plus rapide, et le commentaire le plus voté du fil sur la publication des poids résume le mieux la situation :
Damn, that's a really long Cat!
3.55 TB in all its BF16 glory. 2.05 TB in FP8.
La version plus sobre du même constat, dans le même fil : poids ouverts et accès ouvert ne sont pas la même chose. Pour quiconque possède une 4090, une 5090 ou même une RTX PRO 6000 de 96 Go, cette sortie est plutôt à lire qu'à faire tourner. Ce qu'elle permet en revanche, c'est le travail d'écosystème : inspection, distillation, quantifications communautaires, et à terme une version Lite ou distillée que du matériel ordinaire pourra réellement charger.
Les chiffres de téléchargement racontent la même histoire : 3 240 sur le dernier mois, avec zéro fournisseur d'inférence listé sur Hugging Face et 24 personnes ayant cliqué sur « Ask for provider support ». Pour un modèle qui a dominé la conversation sur les modèles de codage pendant un mois, c'est un chiffre modeste, exactement celui à attendre quand le billet d'entrée est un nœud 8x B300. Des poids gratuits ne rendent pas l'inférence gratuite, et le prix de Hugging Face est un utile rappel à la réalité sur l'endroit où la facture finit par retomber.
Où vont tes données, la vraie question à trancher
C'est la section que je lirais en premier si je dirigeais du support plutôt qu'un dépôt, et c'est la plus courte parce qu'il y a très peu à rapporter.
La FAQ de la plateforme de Meituan n'aborde pas la conservation des données. Elle n'aborde pas la question de savoir si les prompts ou les complétions sont utilisés pour l'entraînement. Le mot « training » n'apparaît pas une seule fois sur la page. Aucun pays d'hébergement des serveurs n'est nommé, et la seule ligne évoquant vaguement la géographie est « charge du serveur et localisation géographique », sous une rubrique sur la latence. Il n'y a ni SLA, ni chiffre de disponibilité, ni crédit de service, ni aucune voie vers un déploiement entreprise ou privé au-delà d'une adresse e-mail.
Rien de tout cela ne signifie qu'il se passe quelque chose de grave. Cela signifie que les questions restent sans réponse, et l'absence de réponse constitue en elle-même une réponse lors d'un audit de sécurité.
Passer par OpenRouter ne résout pas non plus totalement le problème. Un seul fournisseur sert ce modèle, AtlasCloud, qui porte un badge « No training » mais aucun badge de conservation zéro des données, alors que NovitaAI, Tencent Cloud et Fireworks portent tous trois un badge ZDR sur la même page d'annuaire. La propre politique d'AtlasCloud conserve le contenu client, défini comme incluant les prompts, les résultats générés et les charges utiles d'API, pendant jusqu'à sept jours, avec le ZDR réservé à un avenant entreprise séparé. Avec un seul fournisseur, une requête filtrée sur le critère ZDR n'a nulle part où aller.
Je n'ai pas à spéculer sur l'importance commerciale de tout cela, car je le constate chaque semaine dans les appels commerciaux d'eesel. Un acheteur danois de télématique B2B, bloqué par un audit de sécurité interne strict, refusait de démarrer un essai avant d'avoir la garantie que les données de tickets contenant des numéros de carte et des mots de passe restaient dans son propre environnement. Une entreprise média traitant environ 1 000 tickets par semaine a fait de la rédaction des numéros de carte et des données personnelles la première objection de toute l'évaluation, avant même la précision et avant le prix. La réponse que je donne dans ces échanges est précise : aucune donnée client n'est utilisée pour entraîner les modèles, les fournisseurs de modèles sous-jacents conservent les données au maximum 30 jours pour la surveillance des abus, et les données sont cloisonnées par compte. On ne peut pas donner cette réponse à propos d'une page qui ne mentionne jamais l'entraînement.
Ce n'est pas une critique de LongCat 2.0 en tant que modèle de codage. C'est la différence entre un modèle qu'on pointe vers son propre dépôt et un modèle qu'on pointe vers les données personnelles de quelqu'un d'autre. La même barrière apparaît dans chaque évaluation d'IA pour helpdesk que j'ai vue, et une mauvaise réponse contenant le numéro de carte d'un client dans le prompt est un type d'hallucination pire qu'une mauvaise réponse sur un chemin de code.
Qui devrait réellement l'utiliser
Tourne-toi vers LongCat 2.0 si tu fais du travail de codage à gros volume et à long contexte dans un harnais que tu contrôles, que tu peux payer via OpenRouter, et que le code que tu lui donnes n'est pas sensible. Le tarif plat jusqu'à 1M en entrée est un vrai avantage pour les prompts à l'échelle d'un dépôt, la licence MIT n'a ni clause d'usage acceptable ni seuil d'utilisateurs, et « cheval de trait fiable » est une description juste de ce que rapportent les utilisateurs.
Passe ton chemin si tu as besoin du mode JSON, de séquences stop ou d'un contrat d'appel d'outils documenté, si tu prévoyais de l'auto-héberger sur moins qu'un nœud 8x B300, ou si un questionnaire sur le traitement des données fait partie de ton processus d'achat. Si tu veux spécifiquement des poids ouverts, DeepSeek V4 Pro est la comparaison la plus proche à un prix catalogue plus bas, et GLM-5.2 est également sous MIT. Si tu veux spécifiquement des tokens bon marché sans te soucier des poids ouverts, GPT-5.6 Luna est moins cher en entrée et se paie par carte bancaire. Il vaut la peine de lire comment DeepSeek Flash et K3 se comparent en coût par tâche accomplie avant de t'engager, car les tarifs affichés et les factures réelles s'écartent beaucoup dans ce segment.
Et si tu choisis un modèle parce que tu veux que l'IA réponde aux tickets de tes clients, je dirais que le modèle est le mauvais niveau où faire ses courses. Ça méritait sa propre section.
Try eesel
Si tu es arrivé ici en comparant des prix de tokens parce que tu veux que l'IA gère ta file de support, ce que je te dirais, c'est que choisir le modèle est la partie facile, les 5 % de ce projet. La partie difficile, c'est de savoir ce que l'IA va dire à tes clients avant qu'elle ne le dise, et de pouvoir ensuite répondre à ta propre équipe sécurité.
eesel est un coéquipier IA que tu connectes au helpdesk que tu utilises déjà, Zendesk, Freshdesk, Gorgias, Front, Help Scout ou Salesforce, et il apprend à partir de tes tickets existants et de ton centre d'aide au lieu d'exiger une base de connaissances toute neuve. Nous gérons la couche modèle, pour que tu n'aies pas à retarifer ta pile de support chaque fois qu'un billet de lancement promet 60 % de réduction sans date de fin. Avant toute mise en production, tu peux simuler l'agent sur tes tickets historiques réels et voir les réponses qu'il aurait envoyées, une étape que nous avons construite après avoir vu des bots à l'air sûr se tromper discrètement. Et sur les questions que la FAQ de LongCat laisse sans réponse, nous avons des réponses précises : tes données ne servent pas à entraîner des modèles, et elles sont cloisonnées par compte.
Tu peux connecter un helpdesk et voir sa première réponse se rédiger en quelques minutes, sur un plan en libre-service avec un tarif eesel à la tâche et sans frais de licence par siège. Si tu veux voir comment les pièces s'assemblent avant cela, notre analyse du meilleur LLM pour le support couvre les compromis, et le comparatif construire ou acheter met des chiffres réels sur ce que coûte l'exploitation de ta propre pile une fois les GPU incluses. Essaie eesel gratuitement, ou réserve une démo et apporte ton ticket le plus coriace.
Questions fréquentes
Qu'est-ce que LongCat 2.0 ?
Combien coûte LongCat 2.0 par million de tokens ?
LongCat 2.0 est-il vraiment un modèle à 1M de contexte ?
config.json livré plafonne max_position_embeddings à 262 144. La véritable fenêtre de contexte servie est donc de 256K, sauf à configurer soi-même l'extension, ce qui est un écart plus faible qu'il ne semble face à la fenêtre de contexte de Claude Code, mais reste éloigné du chiffre annoncé.Puis-je auto-héberger LongCat 2.0 ?
Devrais-je utiliser LongCat 2.0 pour le service client ?
Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.
