LongCat-2.0 dévoilé : un modèle open source de 1,6 billion de paramètres entraîné sans Nvidia

 (longcat.chat)
3 points par GN⁺ 6 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Grand modèle de langage MoE de 1,6 billion (1.6T) de paramètres avec environ 48 milliards de paramètres activés par token, accompagné de plusieurs améliorations architecturales avec son passage en open source
  • Entraînement complet et déploiement à grande échelle réalisés entièrement sur un superpod AI ASIC, avec plus de 35 billions de tokens de préentraînement achevés sans rollback ni pic de perte irréversible
  • Introduction de LongCat Sparse Attention (LSA) et entraînement sur des données à contexte 1M de plusieurs centaines de milliards de tokens pour renforcer les performances sur les tâches longues
  • Intégration étroite avec des harnais grand public comme Claude Code, OpenClaw et Hermes, offrant de solides performances en compréhension de code, modifications à l’échelle du dépôt, exécution automatique de tâches et workflows d’agents
  • Démonstration qu’un entraînement de niveau frontier est possible sur un matériel alternatif encore moins mature que l’écosystème GPU Nvidia, avec des optimisations d’infrastructure et de post-entraînement qui se traduisent en performances concrètes sur des tâches réelles

Présentation du modèle

  • Grand modèle de langage MoE de 1,6 billion de paramètres, n’activant qu’environ 48 milliards de paramètres par token, marquant une avancée majeure par rapport aux précédents modèles LongCat
  • L’exécution complète de l’entraînement comme du déploiement à grande échelle repose sur des superpods AI ASIC
    • Le préentraînement s’est étendu sur des millions d’accelerator-days et plus de 35 billions de tokens, sans rollback ni loss spike irréversible
    • Cela démontre la capacité à réaliser un entraînement de niveau frontier sur une plateforme matérielle alternative
  • Pour renforcer les tâches longues, LongCat Sparse Attention a été introduit et entraîné sur des centaines de milliards de tokens de données à contexte 1M
  • Intégration poussée avec des harnais grand public comme Claude Code, OpenClaw et Hermes, offrant une expérience de collaboration stable et efficace en compréhension de code, édition à l’échelle du dépôt, exécution automatisée de tâches et workflows d’agents

Architecture

  • Basé sur LongCat-Flash, avec une efficacité des paramètres encore accrue et de meilleures performances en apprentissage comme en inférence sur long contexte
  • Adoption de LongCat Sparse Attention (LSA) pour l’attention
    • Évolution de DeepSeek Sparse Attention, avec un indexer plus léger qui accélère le traitement des longs contextes sans dégrader la qualité du modèle
  • Ajout d’un module N-gram Embedding
    • Les combinaisons de tokens en N-gram étendent l’espace d’embedding d’environ 100x, capturent un contexte local plus riche et renforcent les représentations au niveau token

LongCat Sparse Attention

  • Avec la diffusion des applications agentiques, les LLM évoluent vers un traitement plus efficace des longues entrées
    • DSA y répond avec une sparse attention fine, mais le profiling montre que le Lightning Indexer de DSA reste un goulot d’étranglement majeur en raison de la discontinuité de sortie et du coût de scoring quadratique
  • LSA introduit trois améliorations d’efficacité orthogonales au niveau de l’indexer
    • Streaming-aware Indexing (SI) : recompose le budget de sélection de tokens pour combiner accès séquentiels alignés matériellement et sélection aléatoire dynamique, transformant des accès mémoire fragmentés en lectures séquentielles prévisibles afin d’obtenir des accès HBM coalescés et une bande passante effective élevée
    • Cross-Layer Indexing (CLI) : exploite la stabilité empirique de la saillance d’attention entre couches adjacentes pour amortir le coût d’indexation ; en inférence, un seul passage d’indexation est utilisé sur plusieurs couches consécutives, rendu possible pendant l’entraînement par une distillation cross-layer
    • Hierarchical Indexing (HI) : scoring en deux étapes coarse-to-fine, avec d’abord un scoring approximatif au niveau bloc pour un rappel global, puis une sélection fine des tokens parmi les candidats ; dans LongCat-2.0, cette technique est appliquée sans entraînement supplémentaire et activée sur certaines tâches à contexte ultra-long
  • Les trois composants sont indépendants par conception et peuvent donc être activés ou désactivés séparément
  • Ces trois stratégies sont étendues à un module Multi-Token Prediction (MTP) en 3 étapes pour accélérer le speculative decoding
    • Cross-Layer Indexing est appliqué différemment entre les modèles draft et target, le modèle target partageant un seul passage d’indexation entre deux couches consécutives
    • Dans le MTP multi-étapes, trois draft steps partagent un même passage, et les steps 2 et 3 réutilisent l’ensemble d’index généré au step 1

N-gram Embedding

  • Hérité de LongCat-Flash-Lite, ce module étend les paramètres sur une dimension sparse orthogonale au MoE afin d’améliorer l’efficacité d’utilisation des paramètres
    • La taille des n-gram est fixée à 5, et le modèle comprend 135B de paramètres N-gram Embedding
  • Le modèle suit les principes de scaling suivants
    • La sparsité du MoE a dépassé son sweet spot : même sans N-gram Embedding, la sparsité atteint déjà environ 97 %, si bien qu’ajouter 135B d’experts apporte peu de gain, alors qu’un N-gram Embedding de taille équivalente apporte un bénéfice bien supérieur à celui d’experts standards
    • La part du N-gram Embedding est maintenue dans une plage optimale : les expériences de scaling montrent que si les paramètres d’embedding n-gram représentent une part excessive du budget total (plus de 50 %), leur avantage par rapport à l’extension des experts diminue ; dans LongCat-2.0, cette part reste strictement sous les 10 %
  • En inférence, déplacer des paramètres des experts vers le N-gram Embedding réduit les E/S mémoire du décodage en grands batchs et accélère la génération

Infrastructure extensible basée sur des superpods AI ASIC

  • Entraînement et déploiement reposent sur un cluster à grande échelle de dizaines de milliers d’AI ASIC répartis en superpods
  • Par rapport à l’écosystème GPU Nvidia plus mature, la communauté logicielle de support est encore moins développée ; d’importants efforts ont donc été consacrés à la construction d’une infrastructure stable, sûre et extensible

Entraînement (Training)

  • Le préentraînement a été mené sur plus de 50 000 AI ASIC, ce qui a fait émerger des défis système liés à l’échelle du modèle et du cluster

    • Des optimisations systématiques ont permis une amélioration de plus de 35 % du throughput d’entraînement par rapport à une implémentation naïve, tout en renforçant la fiabilité

  • Déterminisme & fiabilité (Determinism & Reliability)

    • Pour garantir la reproductibilité, le déterminisme a été imposé sur l’ensemble des chemins de communication et de calcul, avec des opérateurs et modules déterministes maison couvrant les couches Embedding, FA, LSA et MoE
    • Pour la fiabilité numérique, les opérateurs fondamentaux ont été retravaillés ; par exemple, toutes les opérations de type reduction utilisent une stratégie d’accumulation par partition en arbre binaire afin de réduire l’accumulation d’erreurs en virgule flottante
      • Les précisions de calcul de l’accelerator ont été rigoureusement validées sur des charges LLM réelles face à une baseline haute précision stricte, confirmant l’intégrité arithmétique et la préparation pour la production
      • Une détection de bit-flip a été ajoutée à certains opérateurs intensifs en calcul afin de repérer immédiatement les anomalies matérielles de retournement de bit
    • La reprise après panne s’appuie sur une supervision end-to-end pour identifier les incidents, basculer le trafic et restaurer le service sans intervention manuelle ; l’isolation de liens défectueux n’a pas d’impact perceptible sur l’entraînement, et les liens restaurés ne sont réintégrés qu’après avoir passé des stress tests

  • Entraînement à grande échelle (Training at Scale)

    • La mémoire par accelerator étant nettement inférieure à celle d’un H800 (80GB), la mémoire est devenue le principal goulot d’étranglement du passage à l’échelle ; la réponse s’est faite sur deux axes : stratégie de parallélisation et gestion mémoire
    • Parallélisation 6D : au-delà des standards TP/CP/EP/DP/PP, introduction d’EMBP pour paralléliser et accélérer les N-gram Embeddings
    • Superpod : entraînement sur des superpods physiques de jusqu’à 48 machines chacun, avec une interconnexion interne all-to-all à haute bande passante et un tissu RoCE entre pods, afin d’étendre à plusieurs centaines de dispositifs le domaine de communication haute bande passante nécessaire aux parallélismes gourmands en bande passante (TP/CP/EP)
      • Cela apporte environ 30 % de throughput de préentraînement supplémentaire à échelle et environnement équivalents
      • Les superpods logiques servent d’unités d’ordonnancement par affinité pour équilibrer localité des communications et planifiabilité
    • Optimisation mémoire : ZeRO-1, recomputation sélective, offloading aware de l’OOM au niveau de l’allocateur, et routage des tokens de padding vers un zero-expert
    • Optimiseur Muon : déployé à grande échelle sur accelerator, avec des optimisations ciblées sur la parallélisation TP, l’élimination de la redondance d’état DP et des kernels efficaces de multiplication de matrices symétriques

  • Entraînement long contexte (Long Context Training)

    • Les défis du long contexte à grande échelle ont été traités sous trois angles
    • Opérateurs LSA & optimisation forward : implémentation d’opérateurs d’attention déterministes maison pour les phases dense-warmup, sparse et l’opérateur de KL-loss, avec une stratégie dense-warmup forward-only permettant de calculer KL loss et gradients en un seul passage forward pour plus d’efficacité
    • Passage à l’échelle du contexte 1M : un parallélisme CP basé sur all-gather extensible au-delà de 512 a permis un entraînement natif en longueur 1M, tandis qu’une stratégie de reshuffle des données et de CP équilibré au niveau du get-batch maintient l’équilibrage de charge
    • Chevauchement calcul-communication : par exemple, l’architecture shortcut-layer chevauche la communication MoE avec le calcul des branches parallèles, et le calcul d’indices top-k du LSA chevauche le KV all-gather afin de réduire les surcoûts de synchronisation

Inférence (Inference)

  • Servir un modèle de 1.6T de paramètres avec un contexte de 1M tokens reste un défi majeur sous les fortes contraintes de capacité HBM, de bande passante HBM I/O et de bande passante d’interconnexion inter-nœuds ; la réponse passe par une pile d’optimisations aux niveaux modèle, matériel et déploiement

  • Optimisations spécifiques au modèle

    • Attention : les goulots d’étranglement en I/O, calcul et mémoire sur les contextes ultra-longs sont optimisés sous trois angles
      • (1) adoption d’un mode de calcul absorb aussi bien en prefill qu’en decode
      • (2) pipeline de l’indexer avec le prologue MLA sur des streams simultanés afin de masquer son surcoût
      • (3) KV-cache parallelism (KVP) pour répartir le KV-cache entre les dispositifs
    • ScMoE : à partir du chevauchement calcul-communication de LongCat-Flash, le scheduling a été encore poussé en exploitant le contrôle explicite par cœur de l’accelerator pour exécuter de façon pleinement parallèle les branches dense et MoE, au-delà d’un simple chevauchement

  • Optimisations orientées accelerator

    • Super Kernel : si le mode graph élimine les interstices entre kernels, il reste un coût de lancement à l’intérieur des kernels ; le super kernel réduit donc ce coût intra-kernel
    • Weight Prefetch : l’appareil est limité en bande passante HBM mais dispose d’un cache L2 relativement large ; ce grand cache L2 est utilisé pour prefetcher les poids et masquer la latence d’E/S pendant le calcul des opérateurs précédents
    • Scale Up and Scale Out : le transfert du KV-cache entre nœuds P et D utilise l’adaptateur réseau 200Gbps intégré à l’accelerator ; le KV-cache est transféré couche par couche, le stockage du KV-cache est assuré par un adaptateur réseau RDMA hôte, et TP/SP/KVP s’exécutent dans le domaine d’interconnexion scale-up

  • Déploiement & serving

    • Parallélisation optimale : pour équilibrer TTFT et TPOT, un déploiement séparé prefill–decode (PD) a été adopté
      • Nœuds prefill : le traitement des longues séquences est limité par la bande passante de communication inter-nœuds, et le trafic de dispatch/combine MoE domine l’exécution ; un chunked pipeline parallelism (CPP) multi-nœuds réduit le domaine expert-parallel (EP), tandis qu’un Attention Sequence Parallelism (SP) au sein de chaque stage de pipeline allège la pression de calcul sur les longues séquences
      • Nœuds decode : les principales contraintes sont la mémoire des dispositifs et les E/S du KV-cache ; le KVP répartit le KV-cache pour réduire l’empreinte mémoire par dispositif, et un grand degré d’EP (EP128) réduit à la fois la mémoire des poids par dispositif et les E/S liées aux experts
      • Dans les deux étapes, les schémas de parallélisation (CPP/SP·KVP) sont conçus pour se combiner proprement avec les optimisations d’inférence comme constrained decoding, le multi-step scheduling et le MTP
    • Expert-Parallel Load Balancing (EPLB) : le grand degré d’EP sur les nœuds decode augmente le risque de déséquilibre de charge entre experts ; EPLB y répond, et pour minimiser le surcoût en serving, la collecte de statistiques et les opérations batch sont effectuées de façon asynchrone en dehors du forward critical path

Apprentissage à partir de plusieurs enseignants (Learning from Multiple Teachers)

  • Pour améliorer les performances globales et étendre les frontières de capacité, le pipeline de post-entraînement introduit une conception spécialisée en groupes d’experts, organisée en trois catégories
  • Agent Experts : améliorent l’exécution autonome de tâches dans des scénarios réels complexes et atteignent des performances de niveau SOTA dans des domaines verticaux fins comme le code, le travail de bureau et la recherche
    • Optimisation non seulement du taux de réussite de bout en bout, mais aussi des capacités atomiques qui sous-tendent la robustesse des agents, notamment l’appel précis d’outils, le parsing fiable des paramètres dans les interactions API multi-tours, et des mécanismes d’auto-correction pour limiter les boucles infinies et les appels répétitifs
  • Reasoning Experts : étendent la profondeur du raisonnement logique et activent un calcul adaptatif selon la difficulté du problème, avec de solides performances en mathématiques, résolution de problèmes STEM et raisonnement multi-hop, renforçant la capacité à gérer des scénarios d’analyse complexes
  • Interaction Experts : se concentrent sur l’alignement humain et l’optimisation de l’expérience utilisateur, améliorent le suivi fin des instructions dans diverses applications et, grâce à des techniques d’alignement avancées, réduisent les hallucinations factuelles tout en établissant des mécanismes de sécurité clairs sans dégrader l’utilité
  • Au final, l’architecture MOPD intègre les capacités les plus fortes de ces trois groupes d’experts, en combinant exécution agentique robuste, raisonnement profond et interaction de haute qualité pour comprendre précisément des besoins utilisateurs complexes et accomplir de façon fiable des tâches réelles difficiles

Démonstration des capacités du modèle

  • Grâce au raisonnement sur long contexte et à un post-entraînement dédié, le modèle se montre performant sur les tâches réelles

  • Codebase Migration

    • Lecture conjointe de l’ensemble du codebase et de la documentation de migration pour cartographier l’architecture, puis réécriture complète du plugin vers le nouveau SDK
    • Toutes les fonctionnalités existantes sont préservées, des bugs potentiels sont détectés, et la première compilation est propre

Évaluations (Evaluations)

  • Comparaison avec les principaux modèles commerciaux sur les agents de code, les agents généralistes et les capacités fondamentales ; sauf indication *, tous les scores ont été mesurés en interne avec un harnais unifié (normalisation 0–100)

  • Code Agent

    • Terminal-Bench 2.1: LongCat-2.0 70.8, Gemini 3.1 Pro 70.7*, GPT-5.5 73.8*, Claude Opus 4.7 71.7*, Opus 4.8 78.9*
    • SWE-bench Pro: LongCat-2.0 59.5, Gemini 3.1 Pro 54.2*, GPT-5.5 58.6*, Opus 4.6 57.3*, Opus 4.7 64.3*, Opus 4.8 69.2*
    • SWE-bench Multilingual: LongCat-2.0 77.3, Gemini 3.1 Pro 76.9*, Opus 4.6 77.8*, Opus 4.7 80.5*, Opus 4.8 84.8*

  • General Agent

    • FORTE†: LongCat-2.0 73.2, Gemini 3.1 Pro 70.3, GPT-5.5 77.8, Opus 4.6 73.2, Opus 4.7 77.6, Opus 4.8 77.2
    • BrowseComp: LongCat-2.0 79.9, Gemini 3.1 Pro 85.9*, GPT-5.5 84.4*, Opus 4.6 84.0*, Opus 4.7 79.3*, Opus 4.8 84.3*
    • RWSearch: LongCat-2.0 78.8, Gemini 3.1 Pro 76.3, GPT-5.5 85.3, Opus 4.6 81.3, Opus 4.7 79.3, Opus 4.8 77.3

  • Foundational

    • IFEval: LongCat-2.0 90.0, Gemini 3.1 Pro 96.1, GPT-5.5 95.0, Opus 4.6 92.2, Opus 4.7 88.7, Opus 4.8 86.0
    • Writing Bench: LongCat-2.0 83.8, Gemini 3.1 Pro 83.7, GPT-5.5 84.7, Opus 4.7 85.3, Opus 4.8 85.2
    • IMO-AnswerBench: LongCat-2.0 81.8, Gemini 3.1 Pro 90.0, GPT-5.5 79.5, Opus 4.6 75.3*, Opus 4.7 81.8, Opus 4.8 75.3
    • GPQA-diamond: LongCat-2.0 88.9, Gemini 3.1 Pro 94.3*, GPT-5.5 93.6*, Opus 4.6 91.3*, Opus 4.7 94.2*, Opus 4.8 92.4

  • Conditions d’évaluation

    • Terminal-Bench 2.1 : évalué avec Claude Code, 8c16g par instance sandbox, paramètres d’inférence temperature=1.0/top_k=-1/top_p=0.95, timeout agent de 6 heures
    • Série SWE-Bench : évaluée avec Claude Code, 4c8g par instance sandbox, temperature=1.0/top_k=-1/top_p=1, avec correction des tâches problématiques
    • FORTE : benchmark d’agent généraliste évaluant des agents IA sur la productivité bureautique quotidienne dans 15 métiers d’entreprise, compatible avec les frameworks OpenClaw/Hermes/Claude Code ; timeout de 45 minutes pour toutes les tâches, 2 CPU/4GB RAM, timeout de 500s par appel API en tour unique, jusqu’à 10 tentatives (marquées †)
    • RW-Search : benchmark objectif propriétaire pour agents de recherche, évalué en bare-model avec seulement les outils Search et Browse par défaut, sans stratégie de gestion du contexte
    • Foundational : pour les tâches de raisonnement mathématique comme IMO-AnswerBench, temperature=1.0/top_k=-1/top_p=0.95 ; pour les autres, temperature=0.7/top_k=-1/top_p=0.95

À lire aussi

1 commentaires

 
GN⁺ 6 시간 전
Avis sur Hacker News

  • Le passage « L’entraînement et le déploiement de LongCat-2.0 reposent sur un cluster à grande échelle composé de dizaines de milliers de superpods AI ASIC… La communauté logicielle de support est encore moins mature que l’écosystème GPU de Nvidia… » semble être la vraie info clé
    Il est possible qu’ils aient utilisé des puces Huawei Ascend 910C : https://nitter.net/teortaxesTex/status/2071708141037781407#m

    • S’ils ont vraiment réussi à préentraîner puis post-entraîner un modèle de 1,6 billion de paramètres sans NVIDIA, c’est exactement ce qu’espérait Dwarkesh Patel
    • Personne ne sait ce qu’ils ont réellement fait. Ce n’est pas audité, et on pourrait aussi avoir l’impression qu’ils sont partis de DeepSeek v4 pro, ont ajouté diverses modifications arbitraires, puis ont donné un nom différent à chaque partie

  • Je l’ai testé avec une question un peu piégeuse : « Si vous pouviez faire fonctionner un réacteur avec de l’U-235 ou du Pu-241 comme combustible, tous deux mélangés à 95 % d’U-238, lequel choisiriez-vous et pourquoi ? »
    Pour un humain, ce n’est pas du tout piégeux, mais cela peut être difficile pour un grand modèle de langage. Le Pu-241 n’existe pas sous forme pure ; il n’est présent qu’en faible proportion dans le plutonium de qualité réacteur, où le Pu-239 est généralement le plus abondant, suivi du Pu-240, puis du Pu-241
    LongCat-2.0 a donné la réponse plausible mais fausse selon laquelle le Pu-241 est préférable, tandis que Qwen 3.7 Plus a correctement répondu que l’U-235 est préférable, au motif que sa fraction de neutrons retardés est bien plus élevée. Gemini Flash a donné la même réponse, avec plus d’assurance, des arguments plus solides et beaucoup plus rapidement
    Globalement, je dirais que Gemini Flash est le meilleur, Qwen 3.7 Plus un bon deuxième, et LongCat-2.0 un troisième choix utilisable seulement quand on n’a pas d’autre option

    • Je ne suis pas physicien, mais la question était peut-être plus orientée que prévu. On peut comprendre la question comme faisant abstraction de la faisabilité du raffinage et supposant que l’on dispose d’une quantité suffisante de la matière en question
      S’il existait vraiment du Pu-241 pur, serait-ce un meilleur combustible que l’U-235 ? Par analogie, à la question « si vous pouviez faire tourner un générateur à l’essence ou au kérosène aviation, que choisiriez-vous ? », on pourrait choisir le kérosène au motif qu’il a une densité énergétique et une pureté légèrement supérieures et qu’il pourrait brûler plus proprement, tout en ignorant le fait réel que le kérosène coûte plusieurs fois plus cher que l’essence
    • « Pour un humain, ce n’est pas du tout piégeux » : je me demande vraiment quelles personnes vous fréquentez. J’ai un doctorat en informatique et des décennies d’ingénierie logicielle derrière moi, mais je n’ai absolument pas compris la question
    • Une comparaison plus équitable et plus utile serait sans doute de fournir aux deux modèles, en contexte, ce genre de document de connaissances de niche, puis de leur poser la question
    • Je me demande si la personne a posé la question plusieurs fois dans de nouveaux contextes de conversation pour vérifier s’il répond parfois correctement
    • Pour comparaison, la réponse de ChatGPT 5.5 disait en substance : « si l’objectif est une production d’électricité sûre, ennuyeuse et pratique, choisissez l’U-235 ; si le réacteur est spécifiquement conçu et autorisé pour consommer ou recycler du plutonium, choisissez le Pu-241 »
      En résumé grossier, le Pu-241 peut être un meilleur « isotope fissile » du point de vue de la physique nucléaire, mais comme combustible de réacteur dans le monde réel, l’U-235 est de loin préférable. Je ne connais pas bien les réacteurs, mais cette réponse me semble aussi correcte

  • Quand on lui demande « combien de personnes le président Mao est-il considéré avoir tuées pendant la “Grande Révolution” ? », il répond : « Bonjour, je ne peux pas répondre à cette question pour le moment. Changeons de sujet. »

    • C’est un bon exemple. Il existe pas mal de questions politiques auxquelles les modèles chinois ne répondent pas

  • 1 024 superpods Huawei Ascend, cela veut dire 50 000 puces 910C. C’est un système très petit, et OpenAI utilise des millions de GPU pour l’entraînement
    Cela dit, il semble très probable qu’ils aient réutilisé l’architecture et les poids de DeepSeek v4. Dans ce cas, ils n’ont peut-être pas eu besoin d’autant de calcul

    • Il vaut mieux attendre que ce soit publié en open source. Je ne pense pas qu’une entreprise comme celle-là ait simplement copié-collé le travail de DeepSeek. De plus, la version d’aperçu de LongCat est sortie le même jour que DeepSeek v4 pro
    • Il est clair aussi qu’atteindre la frontière demande plus de calcul que distiller et reprendre des idées issues de cette frontière. Ce n’est pas un hasard si ce sont toujours les mêmes quelques labos qui se relaient près de la pointe

  • Il y avait déjà eu l’hypothèse que ce soit le modèle derrière openrouter/owl-alpha, publié discrètement et gratuit depuis un mois

    • Ce n’est pas une hypothèse : ils l’ont dit eux-mêmes

  • On ne peut rien télécharger sur Hugging Face et, vu l’historique constant de cette entreprise, on peut pratiquement considérer cela comme une arnaque

    • Meituan a publié LongCat Flash l’an dernier : https://huggingface.co/meituan-longcat/LongCat-Flash-Chat
      Donc, jusqu’ici, leur historique ne ressemble pas à une arnaque. Si vous parlez de leur historique en tant qu’entreprise de livraison de repas, vous avez peut-être eu une mauvaise expérience avec une commande qui n’est jamais arrivée

  • Cela semble venir de Meituan, l’entreprise chinoise de livraison de repas

    • Ce n’est sans doute pas ce que vous vouliez dire, mais cela touche à une idée reçue fréquente dans le business : Uber est une entreprise de livraison de personnes, mais pendant des années elle a eu beaucoup d’excellents ingénieurs en infrastructure et en logiciel, et leur travail s’est diffusé dans tout le secteur
      Amazon aussi était, selon la formule de VMware, « une entreprise qui vend des livres », et la direction de VMware n’arrivait pas à accepter de se faire distancer, au point de dire : « vu la réputation de marque de VMware dans l’entreprise, il est difficile de croire que nous ne puissions pas battre ensemble une entreprise qui vend des livres »
    • Aujourd’hui, Meituan ressemble presque à un conglomérat. Il suffit de voir la liste de ses filiales sur Wikipedia : https://en.wikipedia.org/wiki/Meituan
      Comme Amazon avec AWS, Meituan exploite assez largement son expérience technologique
    • Ce qui m’a frappé chez Meituan, c’est qu’il y avait partout en Chine des bornes de location de batteries externes, et que les gens préféraient les louer parce que c’était pratique plutôt que de transporter leur propre batterie externe
    • Le groupe propriétaire de Lidl a aussi créé STACKIT

  • Je lui ai demandé à propos de Tiananmen Square et il a répondu : « Trop de requêtes. Réessayez plus tard. » C’était ma première question, et je sais que ce n’est qu’un seul échantillon, mais c’est quand même troublant

    • J’ai demandé à Grok combien de fois Elon Musk avait trompé ses partenaires, et il m’a répondu exactement la même chose

  • À moins d’avoir plusieurs serveurs de production sous son bureau, il est trop gros pour être utilisé en hébergement local
    Même chose pour ceux qui voudraient le faire tenir en Q2 ou Q1. Ça ne vaut pas la peine de mutiler le modèle juste pour pouvoir prétendre qu’il est encore vivant