LongCat-2.0 vorgestellt – Open-Source-Modell mit 1,6 Billionen Parametern ohne Nvidia trainiert
(longcat.chat)- Großes MoE-Sprachmodell mit insgesamt 1,6 Billionen (1.6T) Parametern und rund 48 Milliarden aktivierten Parametern pro Token, begleitet von mehreren Architekturverbesserungen im Zuge der Open-Sourcing-Veröffentlichung
- Das komplette Training und der großflächige Deployment-Betrieb wurden vollständig auf einem AI-ASIC-Superpod durchgeführt; das Pretraining über mehr als 35 Billionen Token wurde ohne Rollbacks oder irreparable Loss-Spikes abgeschlossen
- Einführung von LongCat Sparse Attention (LSA) sowie Training auf 1M-Kontext-Daten im Umfang von mehreren hundert Milliarden Token zur Stärkung der Leistung bei Langkontext-Aufgaben
- Eng integriert mit gängigen Harnesses wie Claude Code, OpenClaw und Hermes und dadurch starke Leistung bei Codeverständnis, repository-weiten Änderungen, automatisierter Aufgabenausführung und agentischen Workflows
- Belegt, dass Frontier-Training auch auf alternativer Hardware möglich ist, die im Vergleich zum Nvidia-GPU-Ökosystem noch unreifer ist; Optimierungen über Infrastruktur und Post-Training hinweg schlagen sich in realer Aufgabenleistung nieder
Modellüberblick
- Großes MoE-Sprachmodell mit 1,6 Billionen Parametern, von denen pro Token nur etwa 48 Milliarden aktiviert werden; ein deutlicher Fortschritt gegenüber früheren LongCat-Modellen
- Sowohl der gesamte Trainingslauf als auch das großflächige Deployment wurden auf Basis eines AI-ASIC-Superpods aufgebaut
- Das Pretraining lief über mehrere Millionen Accelerator-Days und mehr als 35 Billionen Token und wurde ohne Rollbacks oder nicht behebbaren Loss-Spike abgeschlossen
- Demonstriert die Fähigkeit, Frontier-Training auf alternativen Hardwareplattformen durchzuführen
- Zur Stärkung von Langzeitaufgaben wurde LongCat Sparse Attention eingeführt und mit 1M-Kontext-Daten über mehrere hundert Milliarden Token trainiert
- Tief in gängige Harnesses wie Claude Code, OpenClaw und Hermes integriert und bietet eine stabile und effiziente Zusammenarbeit beim Codeverständnis, repository-weitem Editieren, automatisierter Aufgabenausführung und in agentischen Workflows
Architektur
- Baut auf LongCat-Flash auf, treibt die Parametereffizienz weiter voran und verbessert Geschwindigkeit bei Langkontext-Training und -Inferenz
- Für Attention wird LongCat Sparse Attention (LSA) eingeführt
- Eine weiterentwickelte Form von DeepSeek Sparse Attention, die mit einem leichteren Indexer die Verarbeitung langer Kontexte beschleunigt, ohne die Modellqualität zu beeinträchtigen
- Hinzu kommt ein N-gram Embedding-Modul
- Erweitert den Embedding-Raum durch N-Gramm-Tokenkombinationen um etwa das 100-Fache und erfasst reichhaltigeren lokalen Kontext sowie stärkere tokenweise Repräsentationen
LongCat Sparse Attention
- Mit der Verbreitung agentischer Anwendungen bewegen sich LLMs in Richtung effizienter Verarbeitung langer Eingaben
- DSA begegnet dem mit feingranularer Sparse Attention, Profiling zeigt jedoch, dass der Lightning Indexer von DSA wegen diskontinuierlicher Ausgaben und quadratischer Scoring-Kosten ein zentraler Flaschenhals bleibt
- LSA führt drei voneinander unabhängige (orthogonale) Effizienzverbesserungen im Indexer ein
- Streaming-aware Indexing (SI): Rekonstruiert das Budget für die Tokenauswahl so, dass hardware-ausgerichtete sequentielle Zugriffe mit dynamischer Zufallsauswahl kombiniert werden; fragmentierte Speicherzugriffe werden in vorhersagbare sequenzielle Reads umgewandelt, was koaleszierte HBM-Zugriffe und hohe effektive Bandbreite ermöglicht
- Cross-Layer Indexing (CLI): Nutzt die empirische Stabilität der Attention-Salienz über benachbarte Layer hinweg, um die Indexing-Kosten zu verteilen; bei der Inferenz wird ein einzelner Indexing-Pass für mehrere aufeinanderfolgende Layer verwendet, ermöglicht durch Cross-Layer-Distillation im Training
- Hierarchical Indexing (HI): Zweistufiges coarse-to-fine-Scoring; zunächst grobe Recall über approximatives Block-Scoring, danach feine Tokenselektion innerhalb der Kandidaten. In LongCat-2.0 wird dies training-free angewendet und bei ausgewählten Ultra-Langkontext-Aufgaben aktiviert
- Die drei Komponenten sind im Design unabhängig und können jeweils separat aktiviert oder deaktiviert werden
- Die drei Strategien werden auf ein dreistufiges Multi-Token Prediction (MTP)-Modul ausgeweitet, um Speculative Decoding zu beschleunigen
- Cross-Layer Indexing wird im Draft- und im Target-Modell unterschiedlich angewendet; im Target-Modell teilen sich zwei aufeinanderfolgende Layer einen einzelnen Indexing-Pass
- In mehrstufigem MTP teilen sich drei Draft-Schritte einen Pass; Schritt 2 und 3 verwenden die in Schritt 1 erzeugte Indexmenge wieder
N-gram Embedding
- Aus LongCat-Flash-Lite übernommen; erweitert Parameter in einer zur MoE orthogonalen Sparse-Dimension und verbessert so die Effizienz der Parameternutzung
- Die N-Gramm-Größe ist auf 5 gesetzt, das Modell enthält 135B N-gram Embedding-Parameter
- Hält sich an die folgenden Skalierungsprinzipien
- Die Sparsity von MoE liegt über dem Sweet Spot: Auch ohne N-gram Embedding erreicht die Sparsity bereits rund 97 %, sodass selbst 135B zusätzliche Experts nur geringe Leistungsgewinne bringen; N-gram Embeddings mit derselben Parametergröße liefern deutlich mehr Nutzen als Standard-Experts
- Der Anteil der N-gram Embeddings bleibt im optimalen Bereich begrenzt: Skalierungsexperimente zeigen, dass der Vorteil gegenüber einer Erweiterung der Experts sinkt, wenn N-Gramm-Embedding-Parameter einen zu großen Anteil am Gesamtbudget einnehmen (über 50 %); in LongCat-2.0 wird dieser Anteil strikt unter 10 % gehalten
- Werden bei der Inferenz Parameter von Experts in N-gram Embeddings verlagert, sinkt der Memory-I/O bei großem Batch-Decoding, was die Generierung beschleunigt
Skalierbare Infrastruktur auf Basis von AI-ASIC-Superpods
- Training und Deployment basieren auf einem groß angelegten Cluster aus zehntausenden AI-ASICs in Superpods
- Im Vergleich zum ausgereiften Nvidia-GPU-Ökosystem ist die unterstützende Software-Community noch weniger entwickelt; entsprechend wurde erheblicher Aufwand in den Aufbau einer stabilen, sicheren und skalierbaren Infrastruktur investiert
Training
-
Pretraining auf mehr als 50.000 AI-ASICs, wodurch durch Modell- und Clustergröße systemseitige Herausforderungen entstanden
- Durch systematische Optimierungen wurde der Trainingsdurchsatz gegenüber einer naiven Implementierung um über 35 % verbessert, bei gleichzeitig höherer Zuverlässigkeit
-
Determinismus & Zuverlässigkeit
- Um Reproduzierbarkeit sicherzustellen, wurde Determinismus entlang des gesamten Kommunikations- und Rechenpfads erzwungen; eigene deterministische Operatoren und Module decken Embedding-, FA-, LSA- und MoE-Layer ab
- Für numerische Zuverlässigkeit wurden Basisoperatoren überarbeitet; etwa verwenden alle Reduktionsoperationen eine binäre Baumstruktur bei der Partitionierung und Akkumulation, um die Anhäufung von Floating-Point-Fehlern zu verringern
- Bei realen LLM-Workloads wurde die Rechengenauigkeit der Acceleratoren gegen eine strenge hochpräzise Baseline validiert, um arithmetische Integrität und Produktionsreife zu bestätigen
- Für einige rechenintensive Operatoren wurde Bit-Flip-Erkennung eingeführt, um Hardware-Bitflips sofort zu erfassen
- Die Fehlerbehebung erfolgt über End-to-End-Monitoring, das Fehler erkennt, Traffic umleitet und Wiederherstellung ohne manuellen Eingriff ausführt; bei Isolierung defekter Links gibt es keinen spürbaren Einfluss auf das Training, wiederhergestellte Links werden nach bestandenem Stresstest wieder aufgenommen
-
Training im großen Maßstab
- Der Speicher pro Accelerator-Gerät liegt deutlich unter dem eines H800 (80GB), weshalb Memory zum Hauptflaschenhals für die Skalierung wurde; adressiert über Parallelisierungsstrategie und Memory-Management
- 6D-Parallelisierung: Zusätzlich zu TP/CP/EP/DP/PP wird EMBP eingeführt, um N-gram Embeddings zu parallelisieren und zu beschleunigen
- Superpod: Training erfolgt in physischen Superpods mit jeweils bis zu 48 Maschinen; intern besteht all-to-all-Hochbandbreite, zwischen Pods verbindet ein RoCE-Fabric. So wird die Hochbandbreiten-Kommunikationsdomäne für bandbreitenintensive Parallelisierung (TP/CP/EP) auf Hunderte Geräte erweitert
- Liefert bei gleicher Größenordnung und Umgebung einen zusätzlichen Pretraining-Durchsatzgewinn von rund 30 %
- Logische Superpods dienen als Affinitäts-Scheduling-Einheit und balancieren Kommunikationslokalität gegen Planbarkeit aus
- Memory-Optimierung: ZeRO-1, selektive Recomputation, OOM-aware Offloading auf Allocator-Ebene und Routing von Padding-Token zu einem Zero-Expert
- Muon-Optimizer: Im großen Maßstab auf den Acceleratoren eingesetzt, mit gezielten Optimierungen für TP-Parallelisierung, Beseitigung redundanter DP-States und effiziente Kernel für symmetrische Matrixmultiplikation
-
Langkontext-Training
- Die Herausforderungen großskaligen Langkontext-Trainings werden aus drei Blickwinkeln adressiert
- LSA-Operatoren & Forward-Optimierung: Eigene deterministische Attention-Operatoren für Dense-Warmup-, Sparse-Phasen und KL-Loss-Operatoren; eine Forward-only-Dense-Warmup-Strategie berechnet KL-Loss und Gradienten in einem einzigen Forward-Pass und steigert so die Effizienz
- 1M-Kontext-Skalierung: Native 1M-Längen-Trainings werden durch all-gather-basierte CP-Parallelisierung ermöglicht, die sich auf CP 512 und mehr ausdehnen lässt; durch Daten-Reshuffling in der Get-Batch-Phase und eine balancierte CP-Strategie bleibt die Workload ausgeglichen
- Überlappung von Berechnung und Kommunikation: Beispielsweise überlappt die Shortcut-Layer-Architektur die MoE-Kommunikation mit Berechnungen in parallelen Zweigen, während LSA-Top-k-Indexberechnung mit KV-All-Gather überlappt, um Synchronisations-Overhead zu verringern
Inferenz
-
Das Serving eines 1,6T-Parameter-Modells mit 1M-Token-Kontext ist unter strengen Beschränkungen bei HBM-Kapazität, HBM-I/O-Bandbreite und Node-übergreifender Interconnect-Bandbreite eine große Herausforderung; begegnet wird dem mit einem Optimierungsstack auf Modell-, Geräte- und Deployment-Ebene
-
Modellspezifische Optimierungen
- Attention: I/O-, Rechen- und Memory-Flaschenhälse bei Ultra-Langkontexten werden aus drei Perspektiven optimiert
- (1) Sowohl in Prefill- als auch Decode-Phase wird der Absorb-Operationsmodus verwendet
- (2) Der Indexer wird mit dem MLA-Prolog über einen gleichzeitigen Stream pipelined, um den Indexer-Overhead zu verstecken
- (3) KV-cache parallelism (KVP) shardet den KV-Cache über Geräte hinweg
- ScMoE: Aufbauend auf der Overlap-Strategie von LongCat-Flash wurde das Scheduling weiterentwickelt; mithilfe expliziter Per-Core-Steuerung des Accelerators laufen Dense- und MoE-Zweig vollständig parallel und gehen damit über bloße Überlappung hinaus
- Attention: I/O-, Rechen- und Memory-Flaschenhälse bei Ultra-Langkontexten werden aus drei Perspektiven optimiert
-
Accelerator-orientierte Optimierungen
- Super Kernel: Im Graph-Modus verschwinden zwar Lücken zwischen Kerneln, aber interner Launch-Overhead bleibt bestehen; ein Super Kernel reduziert diese Intra-Kernel-Launch-Kosten
- Weight Prefetch: Das Gerät hat begrenzte HBM-Bandbreite, aber einen relativ großen L2-Cache; dieser große L2-Cache wird genutzt, um Gewichte vorab zu laden und I/O-Latenz während der Berechnung vorheriger Operatoren zu verdecken
- Scale Up and Scale Out: Die Übertragung des KV-Cache zwischen P- und D-Nodes nutzt den eingebauten 200Gbps-Netzwerkadapter des Accelerators; der KV-Cache wird layerweise übertragen, der KV-Cache-Store basiert auf Host-RDMA-Netzwerkadaptern, und TP/SP/KVP laufen innerhalb der Scale-up-Interconnect-Domäne
-
Deployment & Serving
- Optimale Parallelisierung: Um TTFT und TPOT auszubalancieren, wird ein getrenntes Prefill–Decode-(PD)-Deployment verwendet
- Prefill-Nodes: Die Verarbeitung langer Sequenzen ist durch Node-übergreifende Kommunikationsbandbreite begrenzt, und MoE-Dispatch-/Combine-Traffic dominiert die Laufzeit; mit Multi-Node Chunked Pipeline Parallelism (CPP) wird die Expert-Parallel-(EP)-Domäne verkleinert, und Attention Sequence Parallelism (SP) innerhalb jeder Pipeline-Stufe verringert den Rechendruck langer Sequenzen
- Decode-Nodes: Hauptbeschränkungen sind Gerätespeicher und KV-Cache-I/O; durch KVP wird der KV-Cache geshardet und so der Memory-Footprint pro Gerät reduziert, während eine große EP-Ordnung (EP128) gleichzeitig Gewichts-Memory und Expert-I/O pro Gerät senkt
- In beiden Stufen ist die Parallelisierungsform (CPP/SP bzw. KVP) so ausgelegt, dass sie sich sauber mit Inferenzoptimierungen wie Constrained Decoding, Multi-Step Scheduling und MTP kombinieren lässt
- Expert-Parallel Load Balancing (EPLB): Die hohe EP-Ordnung auf Decode-Nodes erhöht das Risiko von Lastungleichgewichten zwischen Experts; EPLB begegnet dem, wobei Statistiksammlung und Batch-Operationen zur Minimierung des Serving-Overheads asynchron außerhalb des Forward-Critical-Path ausgeführt werden
- Optimale Parallelisierung: Um TTFT und TPOT auszubalancieren, wird ein getrenntes Prefill–Decode-(PD)-Deployment verwendet
Lernen von mehreren Lehrern
- Zur Verbesserung der Gesamtleistung und zur Erweiterung der Fähigkeitsgrenzen wurde im Post-Training-Pipeline-Design ein spezialisiertes Expert-Group-Konzept eingeführt, bestehend aus drei Kategorien
- Agent Experts: Verbessern die autonome Aufgabenausführung in komplexen realen Szenarien und erreichen SOTA-Leistung in feingranularen vertikalen Domänen wie Code, Arbeit und Suche
- Optimiert werden nicht nur End-to-End-Erfolgsraten, sondern auch atomare Fähigkeiten, die die Robustheit des Agenten stützen, darunter präzise Tool-Aufrufe, zuverlässiges Parameter-Parsing in Multi-Turn-API-Interaktionen und Selbstkorrekturmechanismen zur Minderung von Endlosschleifen und Wiederholungsaufrufen
- Reasoning Experts: Erweitern die Tiefe logischer Schlussfolgerung und aktivieren adaptive Rechenleistung abhängig von der Schwierigkeit eines Problems; starke Leistung bei Mathematik, STEM-Problemlösung und Multi-Hop-Reasoning verbessert die Bewältigung komplexer Analyseszenarien
- Interaction Experts: Fokussieren sich auf Human Alignment und Optimierung der User Experience, verbessern feingranulares Befolgen von Anweisungen in vielfältigen Anwendungen, unterdrücken faktische Halluzinationen mit fortgeschrittenen Alignment-Techniken und etablieren klar abgegrenzte Sicherheitsmechanismen ohne Einbußen bei der Nützlichkeit
- Abschließend integriert die MOPD-Architektur die stärksten Fähigkeiten der drei Expert-Gruppen und kombiniert starke agentische Ausführung, tiefes Reasoning und hochwertige Interaktion, um komplexe Nutzeranforderungen präzise zu verstehen und schwierige reale Aufgaben zuverlässig zu lösen
Demonstration der Modellfähigkeiten
-
Dank Langkontext-Reasoning und spezialisiertem Post-Training ist das Modell besonders stark bei realen Aufgaben
-
Codebase Migration
- Liest die gesamte Codebasis zusammen mit der Migrationsdokumentation, bildet die Architektur ab und schreibt das gesamte Plugin für das neue SDK neu
- Erhält alle bestehenden Funktionen vollständig, erkennt potenzielle Bugs und kompiliert beim ersten Build sauber
Evaluierungen
-
Vergleich mit führenden kommerziellen Modellen über Code, allgemeine Agentenfähigkeiten und grundlegende Kompetenzen hinweg; alle Werte ohne
*wurden intern mit einem integrierten Harness gemessen (auf 0–100 normiert) -
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
-
Evaluierungsbedingungen
- Terminal-Bench 2.1: Bewertet mit Claude Code, pro Sandbox-Instanz 8c16g, Inferenzparameter temperature=1.0/top_k=-1/top_p=0.95, Agent-Timeout 6 Stunden
- SWE-Bench-Serie: Bewertet mit Claude Code, pro Sandbox-Instanz 4c8g, temperature=1.0/top_k=-1/top_p=1, fehlerhafte Tasks wurden korrigiert
- FORTE: General-Agent-Benchmark zur Bewertung von KI-Agenten anhand alltäglicher Office-Produktivität in 15 Unternehmensrollen, unterstützt OpenClaw/Hermes/Claude Code-Frameworks, alle Tasks mit 45 Minuten Timeout, 2 CPU/4GB RAM, Timeout pro einzelner API-Anfrage 500s, maximal 10 Wiederholungen (mit † gekennzeichnet)
- RW-Search: Eigenentwickelter objektiver Benchmark für Suchagenten mit Evaluation des Bare Models nur mit den Standard-Tools Search und Browse, ohne Strategien für Kontextmanagement
- Foundational: Mathematik-Reasoning wie IMO-AnswerBench mit temperature=1.0/top_k=-1/top_p=0.95, alles andere mit temperature=0.7/top_k=-1/top_p=0.95
1 Kommentare
Hacker-News-Kommentare
Der Abschnitt, dass „Training und Deployment von LongCat-2.0 auf einem großen Cluster aufgebaut wurden, der aus zehntausenden AI-ASIC-Superpods besteht … die unterstützende Software-Community ist noch weniger ausgereift als das Nvidia-GPU-Ökosystem …“, wirkt wie die eigentliche Kernnachricht
Es sieht so aus, als könnten Huawei-Ascend-910C-Chips verwendet worden sein: https://nitter.net/teortaxesTex/status/2071708141037781407#m
Ich habe es mit einer etwas kniffligen Frage getestet: „Wenn man einen Reaktor entweder mit U-235 oder Pu-241 als Brennstoff betreiben könnte, jeweils gemischt mit 95 % U-238, was würdest du wählen und warum?“
Für Menschen ist das überhaupt nicht knifflig, aber für große Sprachmodelle könnte es schwierig sein. Pu-241 kommt nicht in reiner Form vor, sondern nur als kleiner Bestandteil von Reaktorplutonium; normalerweise ist Pu-239 am häufigsten, dann Pu-240 und Pu-241 an dritter Stelle
LongCat-2.0 gab die plausibel klingende, aber falsche Antwort Pu-241 ist besser, während Qwen 3.7 Plus korrekt U-235 ist besser antwortete, mit der Begründung, dass der Anteil verzögerter Neutronen deutlich höher sei. Gemini Flash gab dieselbe Antwort noch selbstsicherer, mit stärkeren Argumenten und viel schneller
Insgesamt war Gemini Flash am besten, Qwen 3.7 Plus ein ordentlicher zweiter Platz und LongCat-2.0 eher ein dritter Platz, den man nur nutzen würde, wenn es keine Alternative gibt
Wenn man tatsächlich reines Pu-241 hätte, wäre es dann ein besserer Brennstoff als U-235? Bildlich wäre das wie die Frage: „Wenn man einen Generator mit Benzin oder Kerosin betreiben könnte, was würdest du wählen?“ Dann könnte man Kerosin wählen, weil die Energiedichte und Reinheit etwas höher sind und es möglicherweise sauberer verbrennt, während die Realität, dass Kerosin ein Mehrfaches von Benzin kostet, ausgeblendet wird
Grob zusammengefasst: Pu-241 mag kernphysikalisch das bessere „spaltbare Isotop“ sein, aber als Reaktorbrennstoff in der realen Welt ist U-235 deutlich besser. Ich kenne mich mit Reaktoren nicht gut aus, aber auch diese Antwort klingt richtig
Auf die Frage „Wie viele Menschen hat Vorsitzender Mao in der ‘Großen Revolution’ nach allgemeiner Einschätzung getötet?“ kam die Antwort: „Hallo, ich kann diese Frage im Moment nicht beantworten. Lass uns über ein anderes Thema sprechen“
1024 Huawei-Ascend-Superpods bedeuten 50.000 910C-Chips. Das ist ein sehr kleines System, und OpenAI verwendet für Training Hunderttausende GPUs
Allerdings scheint es gut möglich, dass vorhandene DeepSeek-v4-Architektur und -Gewichte wiederverwendet wurden. Dann wäre vielleicht gar nicht so viel Rechenleistung nötig gewesen
Früher gab es die Vermutung, dass dieses Modell hinter dem still und leise veröffentlichten openrouter/owl-alpha steckt, das im letzten Monat kostenlos war
Auf Hugging Face lässt sich nichts herunterladen, und wenn man sich die bisherige Historie der Firma ansieht, wirkt das praktisch wie Betrug
Daher wirkt die bisherige Historie nicht wie Betrug. Falls die Historie als Essenslieferfirma gemeint war, hattest du vielleicht einfach mal die schlechte Erfahrung, dass bestelltes Essen nicht ankam
Das scheint von Meituan, einer chinesischen Essenslieferfirma, zu kommen
Amazon war in der VMware-Rhetorik auch „eine Firma, die Bücher verkauft“, und VMware-Manager konnten sich offenbar nicht damit abfinden, dass sie zurücklagen, obwohl „man angesichts des Markenrufs von VMware im Enterprise-Bereich kaum glauben kann, dass wir gegen eine Firma, die Bücher verkauft, nicht gemeinsam gewinnen können“
So wie Amazon AWS hervorgebracht hat, nutzt auch Meituan seine technischen Erfahrungen ziemlich stark
Als ich nach dem Tiananmen Square fragte, kam die Antwort: „Zu viele Anfragen. Bitte versuchen Sie es später erneut.“ Es war die erste Frage, und ich weiß, dass es nur eine einzelne Stichprobe ist, aber es hinterlässt trotzdem ein komisches Gefühl
Sofern man nicht ein paar Produktionsserver unter dem Schreibtisch stehen hat, ist das für lokales Hosting zu groß und damit schwer sinnvoll nutzbar
Dasselbe gilt für Leute, die es auf Q2 oder Q1 herunterquetschen wollen. Es lohnt sich nicht, das Modell zu ruinieren, nur um zu behaupten, es lebe noch, nachdem man ihm Arme und Beine abgeschnitten hat