LongCat-2.0 जारी - Nvidia के बिना प्रशिक्षित 1.6 ट्रिलियन पैरामीटर का ओपन सोर्स मॉडल

 (longcat.chat)
3 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुल 1.6 ट्रिलियन (1.6T) पैरामीटर और प्रति टोकन लगभग 48 बिलियन सक्रिय पैरामीटर वाले बड़े MoE भाषा मॉडल के रूप में, इसे ओपन सोर्स किया गया है और साथ में कई आर्किटेक्चरल सुधार भी किए गए हैं
  • पूरा प्रशिक्षण और बड़े पैमाने की डिप्लॉयमेंट पूरी तरह AI ASIC superpod पर की गई, और 35 ट्रिलियन से अधिक टोकनों पर pretraining बिना rollback या irrecoverable loss spike के पूरा किया गया
  • LongCat Sparse Attention(LSA) की शुरुआत और सैकड़ों अरब टोकनों के 1M context डेटा पर प्रशिक्षण से long-context कार्यों का प्रदर्शन बेहतर किया गया
  • Claude Code, OpenClaw, Hermes जैसे मुख्यधारा harnesses के साथ गहरा integration, जिससे code understanding, repository-स्तरीय संशोधन, automated task execution और agent workflow में मजबूत प्रदर्शन मिलता है
  • यह साबित करता है कि Nvidia GPU ecosystem की तुलना में कम परिपक्व वैकल्पिक hardware पर भी frontier-grade training संभव है, और infrastructure व post-training optimization वास्तव में कार्य-निष्पादन क्षमता में बदलते हैं

मॉडल अवलोकन

  • 1.6 ट्रिलियन पैरामीटर वाला बड़ा MoE भाषा मॉडल, जिसमें प्रति टोकन लगभग 48 बिलियन पैरामीटर ही सक्रिय होते हैं, और यह पिछले LongCat मॉडल की तुलना में बड़ा सुधार दिखाता है
  • पूरा training run और large-scale deployment दोनों AI ASIC superpod पर आधारित हैं
    • pretraining कई मिलियन accelerator-day के पैमाने पर 35 ट्रिलियन से अधिक टोकनों पर की गई, और इसे rollback या irrecoverable loss spike के बिना पूरा किया गया
    • इससे वैकल्पिक hardware platform पर frontier-grade training करने की क्षमता साबित हुई
  • long-context कार्यों को मजबूत करने के लिए LongCat Sparse Attention जोड़ा गया, और सैकड़ों अरब टोकनों के 1M context डेटा पर training की गई
  • Claude Code, OpenClaw, Hermes जैसे मुख्यधारा harnesses के साथ गहरा integration, जिससे code understanding, repository-स्तरीय editing, automated task execution और agent workflow में स्थिर व कुशल सहयोग अनुभव मिलता है

आर्किटेक्चर

  • LongCat-Flash के आधार पर parameter efficiency को और आगे बढ़ाया गया और long-context training व inference speed बेहतर की गई
  • attention में LongCat Sparse Attention(LSA) जोड़ा गया
    • यह DeepSeek Sparse Attention का विकसित रूप है, जो हल्के indexer के साथ मॉडल गुणवत्ता घटाए बिना long-context processing तेज करता है
  • N-gram Embedding मॉड्यूल जोड़ा गया
    • N-gram token combinations के जरिए embedding space को लगभग 100 गुना बढ़ाया गया, जिससे अधिक समृद्ध local context capture और token-level representation मजबूत होती है

LongCat Sparse Attention

  • agent-आधारित applications के फैलाव के साथ LLM अब लंबे inputs को कुशलता से संभालने की दिशा में बढ़ रहे हैं
    • DSA इसमें fine-grained sparse attention से जवाब देता है, लेकिन profiling के अनुसार DSA का Lightning Indexer output discontinuity और quadratic scoring cost के कारण प्रमुख bottleneck बना रहता है
  • LSA indexer में तीन परस्पर स्वतंत्र(orthogonal) efficiency improvements लाता है
    • Streaming-aware Indexing(SI): token selection budget को इस तरह पुनर्गठित किया जाता है कि hardware-aligned sequential access और dynamic random selection साथ काम करें, जिससे fragmented memory access को predictable sequential reads में बदला जा सके और coalesced HBM access तथा ऊंची effective bandwidth हासिल हो
    • Cross-Layer Indexing(CLI): पड़ोसी layers के बीच attention saliency की empirical stability का उपयोग कर indexing cost को फैलाया जाता है; inference में एक indexing pass कई लगातार layers के लिए इस्तेमाल होता है, और training के दौरान cross-layer distillation इसे संभव बनाती है
    • Hierarchical Indexing(HI): coarse-to-fine दो-चरणीय scoring, जिसमें पहले block-level approximate scoring से rough recall किया जाता है और फिर candidates के भीतर fine-grained token selection की जाती है; LongCat-2.0 में इसे training-free तरीके से लागू किया गया है और चुने हुए ultra-long-context tasks पर सक्रिय किया जाता है
  • ये तीनों components डिज़ाइन के अनुसार स्वतंत्र हैं, इसलिए इन्हें अलग-अलग enable या disable किया जा सकता है
  • इन तीनों रणनीतियों को 3-stage Multi-Token Prediction(MTP) मॉड्यूल तक बढ़ाया गया है ताकि speculative decoding तेज हो सके
    • Cross-Layer Indexing draft और target model में अलग तरीके से लागू होता है; target model में लगातार 2 layers एक single indexing pass साझा करती हैं
    • multi-stage MTP में 3 draft steps एक ही pass साझा करते हैं, और step 2 व 3, step 1 द्वारा बनाए गए index set का पुन: उपयोग करते हैं

N-gram Embedding

  • यह LongCat-Flash-Lite से लिया गया है, और MoE के orthogonal sparse dimension के रूप में parameters बढ़ाकर parameter utilization efficiency बेहतर करता है
    • n-gram size 5 रखी गई है, और मॉडल में 135B N-gram Embedding parameters शामिल हैं
  • यह निम्न scaling principles का पालन करता है
    • MoE की sparsity sweet spot से आगे निकल चुकी है: N-gram Embedding के बिना भी sparsity लगभग 97% तक पहुंच जाती है, इसलिए experts में 135B की वृद्धि से प्रदर्शन लाभ बहुत कम मिलता है, जबकि समान parameter scale का N-gram Embedding standard expert की तुलना में कहीं बड़ा लाभ देता है
    • N-gram Embedding का हिस्सा optimal range में सीमित रखा गया है: scaling experiments के अनुसार यदि n-gram embedding parameters कुल budget का बहुत बड़ा हिस्सा (50% से अधिक) ले लें, तो expert expansion की तुलना में उसका लाभ घट जाता है; LongCat-2.0 में इस हिस्से को सख्ती से 10% से नीचे रखा गया है
  • inference के समय experts से N-gram Embedding की ओर parameters शिफ्ट करने से large-batch decoding में memory I/O घटता है और generation तेज होती है

AI ASIC superpod आधारित scalable infrastructure

  • training और deployment, दसियों हज़ार AI ASIC superpods वाले large-scale cluster पर आधारित हैं
  • परिपक्व Nvidia GPU ecosystem की तुलना में support software community अभी कम विकसित है, इसलिए स्थिर, सुरक्षित और scalable infrastructure बनाने में काफी प्रयास किया गया

प्रशिक्षण(Training)

  • 50,000 से अधिक AI ASIC पर pretraining की गई, और मॉडल व cluster scale के कारण system-level चुनौतियां सामने आईं

    • व्यवस्थित optimization के जरिए naive implementation की तुलना में training throughput 35% से अधिक बेहतर किया गया, साथ ही reliability भी मजबूत हुई

  • Determinism & Reliability

    • reproducibility सुनिश्चित करने के लिए communication और computation path में determinism लागू किया गया, और Embedding, FA, LSA, MoE layers तक फैले अपने deterministic operators व modules दिए गए
    • numerical reliability के लिए base operators को फिर से बनाया गया; उदाहरण के लिए, सभी reduction operations में binary-tree split accumulation strategy अपनाई गई ताकि floating-point error accumulation कम हो
      • वास्तविक LLM workloads में accelerator computation precision को सख्त high-precision baseline के मुकाबले सत्यापित किया गया, जिससे arithmetic integrity और production readiness की पुष्टि हुई
      • कुछ computation-intensive operators में bit-flip detection जोड़ी गई ताकि hardware bit flip anomalies तुरंत पकड़ी जा सकें
    • fault recovery के लिए end-to-end monitoring से fault identification, traffic switchover और recovery बिना manual intervention के की जाती है; defective links को isolate करने पर training पर कोई महसूस होने वाला असर नहीं पड़ता, और recover हुई links stress test पास करने के बाद फिर शामिल की जाती हैं

  • बड़े पैमाने पर प्रशिक्षण(Training at Scale)

    • accelerator की प्रति-device memory, H800(80GB) से काफी कम होने के कारण memory scale-out का मुख्य bottleneck बनती है; इसे parallelization strategy और memory management के दो स्तरों पर हल किया गया
    • 6D parallelism: standard TP/CP/EP/DP/PP से आगे बढ़कर N-gram Embeddings को parallelize और accelerate करने के लिए EMBP जोड़ा गया
    • superpod: अधिकतम 48 machines वाले physical superpods में training की जाती है; अंदर all-to-all high-bandwidth interconnect और pods के बीच RoCE fabric के जरिए, high-bandwidth communication domains को सैकड़ों devices तक बढ़ाया जाता है ताकि bandwidth-heavy parallelism(TP/CP/EP) संभाली जा सके
      • समान scale और environment में इससे pretraining throughput में लगभग 30% अतिरिक्त लाभ मिला
      • logical superpod, affinity scheduling unit के रूप में काम करता है, जो communication locality और schedulability के बीच संतुलन रखता है
    • memory optimization: ZeRO-1, selective recomputation, allocator-level OOM-aware offloading, और padding tokens को zero-expert की ओर route करना लागू किया गया
    • Muon optimizer: accelerator पर बड़े पैमाने पर deploy किया गया, जिसमें TP parallelization, DP state duplication हटाने और efficient symmetric matrix multiplication kernels पर targeted optimization की गई

  • Long Context Training

    • large-scale long-context training की चुनौतियों को तीन कोणों से संभाला गया
    • LSA operator & forward optimization: dense-warmup, sparse stage और KL-loss operators के लिए अपने deterministic attention operators लागू किए गए, और forward-only dense-warmup strategy से KL loss और gradient को एक single forward pass में compute कर efficiency बढ़ाई गई
    • 1M context scaling: CP को 512 से आगे scale करने वाली all-gather आधारित CP parallelization से native 1M-length training संभव हुई, और get-batch चरण में data reshuffle व balanced CP strategy से workload balance बनाए रखा गया
    • compute-communication overlap: उदाहरण के लिए shortcut-layer architecture में MoE communication को parallel branch computation के साथ overlap किया जाता है, और LSA top-k index computation को KV all-gather के साथ overlap करके synchronization overhead घटाया जाता है

inference

  • 1M token context पर 1.6T parameter model को serve करना HBM capacity, HBM I/O bandwidth और inter-node interconnect bandwidth की कड़ी सीमाओं के कारण बड़ी चुनौती है; इसे model, device और deployment स्तर की optimization stack से हल किया गया

  • मॉडल-विशिष्ट optimization

    • Attention: ultra-long-context के I/O, compute और memory bottlenecks को तीन स्तरों पर optimize किया गया
      • (1) prefill और decode दोनों चरणों में absorb operation mode अपनाया गया
      • (2) indexer को MLA prolog के साथ concurrent stream में pipeline किया गया ताकि indexer overhead छिप सके
      • (3) KV-cache parallelism(KVP) से KV-cache को devices के बीच shard किया गया
    • ScMoE: LongCat-Flash के compute-communication overlap पर आगे बढ़ते हुए schedule को और विकसित किया गया, और accelerator के explicit per-core control का उपयोग कर dense और MoE branches को पूरी तरह parallel चलाया गया, जो सिर्फ overlap से आगे जाता है

  • Accelerator-उन्मुख optimization

    • Super Kernel: graph mode में kernels के बीच का gap हट जाता है, लेकिन kernel के अंदर launch overhead बचता है; super kernel से यह intra-kernel launch cost घटाई गई
    • Weight Prefetch: device में HBM bandwidth सीमित है लेकिन तुलनात्मक रूप से बड़ा L2 cache मौजूद है; इसी बड़े L2 cache में weights को prefetch करके पिछले operators की computation के दौरान I/O delay छिपाया जाता है
    • Scale Up and Scale Out: P और D nodes के बीच KV-cache transfer accelerator के built-in 200Gbps network adapter से किया जाता है; KV-cache layer basis पर भेजी जाती है, KV-cache store host RDMA network adapter से बना है, और TP/SP/KVP scale-up interconnection domain के भीतर किए जाते हैं

  • deployment & serving

    • optimal parallelization: TTFT और TPOT के संतुलन के लिए prefill–decode(PD) separated deployment अपनाया गया
      • Prefill nodes: लंबे sequences की processing inter-node communication bandwidth से बंधी होती है और MoE dispatch/combine traffic runtime पर हावी रहता है; multi-node chunked pipeline parallelism(CPP) से expert-parallel(EP) domain घटाया गया, और प्रत्येक pipeline stage में Attention Sequence Parallelism(SP) से long-sequence computation pressure कम किया गया
      • Decode nodes: मुख्य सीमाएं device memory और KV-cache I/O हैं; KVP से KV-cache sharding कर प्रति-device memory footprint घटाया गया, और बड़े EP degree(EP128) से प्रति-device weight memory और expert I/O दोनों कम किए गए
      • दोनों चरणों में parallelization schemes(CPP/SP·KVP) को constrained decoding, multi-step scheduling और MTP जैसी inference-time optimizations के साथ साफ़ तौर पर संयोजित होने के लिए डिज़ाइन किया गया
    • Expert-Parallel Load Balancing(EPLB): decode nodes में बड़े EP degree के कारण experts के बीच load imbalance की संभावना बढ़ती है; इसे EPLB से संभाला गया, और serving overhead कम रखने के लिए statistics collection व batch computation को forward critical path के बाहर asynchronous तरीके से चलाया गया

अनेक शिक्षकों से सीखना(Learning from Multiple Teachers)

  • overall performance बढ़ाने और capability boundaries को फैलाने के लिए post-training pipeline में specialized expert-group design लाई गई, जो तीन categories में बंटी है
  • Agent Experts: जटिल real-world scenarios में autonomous task execution बेहतर करते हैं, और code, business, search जैसे सूक्ष्म vertical domains में SOTA-स्तरीय प्रदर्शन देते हैं
    • end-to-end task success rate के साथ-साथ agent robustness को सहारा देने वाली atomic capabilities भी optimize की गईं, जिनमें precise tool calling, multi-turn API interaction में reliable parameter parsing, और infinite loop व repeated calls को कम करने वाले self-correction mechanisms शामिल हैं
  • Reasoning Experts: logical reasoning depth बढ़ाते हैं और problem difficulty के आधार पर adaptive compute activation देते हैं; math, STEM problem solving और multi-hop reasoning में मजबूत प्रदर्शन देकर complex analytical scenarios को संभालने की क्षमता बढ़ाते हैं
  • Interaction Experts: human alignment और user experience optimization पर केंद्रित हैं, विभिन्न applications में nuanced instruction following सुधारते हैं, advanced alignment techniques से factual hallucination दबाते हैं, और उपयोगिता घटाए बिना स्पष्ट सीमाओं वाले safety mechanisms स्थापित करते हैं
  • अंततः MOPD architecture के जरिए इन तीन expert groups की सबसे मजबूत क्षमताओं को एकीकृत किया गया, जिससे मजबूत agent execution, गहरा reasoning और उच्च-गुणवत्ता interaction मिलकर जटिल user requirements को सही समझते हैं और कठिन real-world tasks को भरोसेमंद तरीके से पूरा करते हैं

मॉडल क्षमताओं का प्रदर्शन

  • long-context reasoning और dedicated post-training के कारण वास्तविक कार्यों के निष्पादन में इसकी खास ताकत दिखती है

  • Codebase Migration

    • पूरे codebase और migration documentation को साथ पढ़कर architecture map किया गया, और पूरे plugin को नए SDK में फिर से लिखा गया
    • सभी मौजूदा features को सुरक्षित रखा गया, संभावित bugs पकड़े गए, और पहली build में clean compile हासिल हुआ

मूल्यांकन(Evaluations)

  • code, general agent और foundational capabilities में प्रमुख commercial models से तुलना की गई; * से चिह्नित स्कोर को छोड़कर बाकी सभी स्कोर unified harness से आंतरिक रूप से मापे गए हैं (0–100 normalized)

  • 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

  • मूल्यांकन शर्तें

    • Terminal-Bench 2.1: Claude Code से मूल्यांकन, प्रति sandbox instance 8c16g, inference parameters temperature=1.0/top_k=-1/top_p=0.95, agent timeout 6 घंटे
    • SWE-Bench series: Claude Code से मूल्यांकन, प्रति sandbox instance 4c8g, temperature=1.0/top_k=-1/top_p=1, problematic tasks को संशोधित किया गया
    • FORTE: 15 corporate job roles की daily office productivity पर AI agents का मूल्यांकन करने वाला general agent benchmark, OpenClaw/Hermes/Claude Code framework support, सभी tasks के लिए 45 मिनट timeout, 2 CPU/4GB RAM, single-round API call timeout 500s, अधिकतम 10 retries († चिह्नित)
    • RW-Search: search agents के लिए internal objective benchmark, जिसमें केवल basic Search और Browse tools के साथ bare-model evaluation किया गया, context management strategy लागू नहीं की गई
    • Foundational: IMO-AnswerBench जैसे math reasoning tasks में temperature=1.0/top_k=-1/top_p=0.95, बाकी में temperature=0.7/top_k=-1/top_p=0.95

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय

  • “LongCat-2.0 की training और deployment दसियों हज़ार AI ASIC superpods से बने बड़े cluster पर तैयार की गई… Nvidia GPU ecosystem की तुलना में supporting software community अभी उतनी mature नहीं है…” वाला हिस्सा असल मुख्य खबर लगता है
    Huawei Ascend 910C chip इस्तेमाल हुई हो सकती है: https://nitter.net/teortaxesTex/status/2071708141037781407#m

    • अगर उन्होंने सच में NVIDIA के बिना 1.6 trillion parameter model को pretraining से post-training तक पूरा कर लिया है, तो वही हुआ जिसकी Dwarkesh Patel उम्मीद कर रहे थे
    • असल में क्या किया गया, यह कोई नहीं जानता। इसका audit भी नहीं हुआ है, और यह ऐसा भी लग सकता है कि DeepSeek v4 pro से शुरू करके उस पर कई मनमाने बदलाव जोड़े गए और फिर अलग-अलग हिस्सों को अलग नाम दे दिए गए

  • इसे थोड़े मुश्किल सवाल से test किया: “अगर U-235 या Pu-241 को fuel बनाकर, दोनों को 95% U-238 के साथ mixed state में रखकर reactor चला सकते हों, तो आप क्या चुनेंगे और क्यों?”
    इंसानों के लिए यह बिल्कुल मुश्किल नहीं है, लेकिन large language models के लिए कठिन हो सकता है। वजह यह है कि Pu-241 pure form में मौजूद नहीं होता, reactor-grade plutonium में सिर्फ छोटी मात्रा में component के रूप में होता है, और आमतौर पर Pu-239 सबसे ज़्यादा, Pu-240 अगला, और Pu-241 तीसरे नंबर पर होता है
    LongCat-2.0 ने Pu-241 बेहतर है जैसा plausible लेकिन गलत जवाब दिया, जबकि Qwen 3.7 Plus ने delayed neutron fraction कहीं ज़्यादा होने की वजह से U-235 बेहतर है कहकर सही जवाब दिया। Gemini Flash ने भी वही जवाब ज़्यादा confidence, मज़बूत reasoning और कहीं तेज़ी से दिया
    कुल मिलाकर मेरे हिसाब से Gemini Flash सबसे अच्छा, Qwen 3.7 Plus ठीक-ठाक दूसरे नंबर पर, और LongCat-2.0 ऐसा तीसरा विकल्प है जिसे तब ही इस्तेमाल करें जब कोई और option न हो

    • मैं physicist नहीं हूँ, लेकिन सवाल शायद उम्मीद से ज़्यादा leading रहा हो। सवाल को ऐसे समझा जा सकता है कि refinement की practicality को ignore करते हुए मान लिया गया है कि वह material पर्याप्त मात्रा में उपलब्ध है
      अगर सच में pure Pu-241 उपलब्ध हो, तो क्या वह U-235 से बेहतर fuel होगा? तुलना के लिए, “अगर generator को gasoline या aviation fuel से चला सकते हों, तो क्या चुनेंगे?” जैसे सवाल में कोई aviation fuel चुन सकता है क्योंकि energy density और purity थोड़ी ज़्यादा होने से उसके ज़्यादा साफ़ जलने की संभावना है, लेकिन इससे यह real-world बात ignore हो जाती है कि aviation fuel gasoline से कई गुना महंगा होता है
    • “इंसानों के लिए यह बिल्कुल मुश्किल नहीं है” — आखिर आप किन लोगों के साथ उठते-बैठते हैं? मैं computer science PhD हूँ और दशकों से software engineering कर रहा हूँ, लेकिन मुझे सवाल ही बिल्कुल समझ नहीं आया
    • ज़्यादा fair और useful comparison यह होगा कि दोनों models को context में ऐसी niche knowledge वाली document दे दी जाए और फिर सवाल पूछा जाए
    • उत्सुक हूँ कि क्या आपने नए chat context में कई बार पूछकर यह भी देखा कि कभी-कभी सही जवाब देता है या नहीं
    • तुलना के लिए ChatGPT 5.5 का जवाब जोड़ें तो वह कुछ ऐसा था: “अगर लक्ष्य safe, boring और practical power production है तो U-235 चुनें; और अगर reactor खास तौर पर plutonium consume/recycle करने के लिए design और licensed है तो Pu-241 चुनें”
      मोटे तौर पर जवाब यह है कि Pu-241 nuclear physics के लिहाज़ से बेहतर “fissile isotope” हो सकता है, लेकिन real-world reactor fuel के तौर पर U-235 कहीं बेहतर है। मुझे reactors की गहरी जानकारी नहीं है, लेकिन यह जवाब भी सही लगता है

  • “Chairman Mao ने ‘Great Revolution’ में कितने लोगों को मारा माना जाता है?” पूछने पर जवाब आया: “नमस्ते, अभी मैं इस सवाल का जवाब नहीं दे सकता। चलिए किसी और विषय पर बात करते हैं”

    • सही उदाहरण है। Chinese models जिन political question areas का जवाब नहीं देते, वे काफी हैं

  • Huawei Ascend superpods 1024 होने का मतलब 50,000 910C chips है। यह बहुत छोटा system है, और OpenAI training में लाखों GPUs इस्तेमाल करता है
    हालांकि ऐसा काफी संभव लगता है कि उन्होंने मौजूदा DeepSeek v4 architecture और weights reuse किए हों। तब शायद इतनी ज़्यादा compute की ज़रूरत नहीं पड़ी होगी

    • सही यही है कि open source release होने तक इंतज़ार करें। ऐसी company DeepSeek के काम को बस copy-paste कर देगी, ऐसा नहीं लगता। ऊपर से LongCat का preview version DeepSeek v4 pro के साथ उसी दिन release हुआ था
    • frontier तक पहुँचने की तुलना में frontier से ideas को distill और उठा लेना निश्चित रूप से कम compute लेता है। यह भी संयोग नहीं है कि बार-बार वही कुछ labs frontier के आसपास बारी-बारी से जगह बनाते हैं

  • पहले यह speculation था कि यह model पिछले एक महीने से free रहे, चुपचाप release किए गए openrouter/owl-alpha के पीछे वाला model है

    • speculation नहीं, उन्होंने खुद ऐसा कहा था

  • Hugging Face से कुछ भी download नहीं किया जा सकता, और इस company के consistent track record को देखते हुए इसे लगभग scam मानना ठीक लगता है

    • Meituan ने पिछले साल LongCat Flash release किया था: https://huggingface.co/meituan-longcat/LongCat-Flash-Chat
      इसलिए अब तक का track record scam जैसा नहीं दिखता। अगर आप food delivery company के तौर पर उनके track record की बात कर रहे हैं, तो शायद आपका ordered food न आने का बुरा experience रहा होगा

  • यह Chinese food delivery company Meituan से आया लगता है

    • शायद आपका इरादा यह नहीं था, लेकिन business में आम भ्रम से जुड़ा है, इसलिए जोड़ दूँ: Uber लोगों की delivery company है, लेकिन सालों तक उसके पास infrastructure और software में बेहतरीन engineers रहे, और उनका काम पूरे industry में फैला
      Amazon भी VMware की भाषा में “किताबें बेचने वाली company” थी, और VMware leadership यह स्वीकार नहीं कर पा रही थी कि वे पीछे रह रहे हैं; वे कहते थे, “enterprise में VMware की brand reputation देखते हुए, यह मानना मुश्किल है कि हम मिलकर किताबें बेचने वाली company को नहीं हरा सकते”
    • आजकल Meituan लगभग conglomerate जैसी है। Wikipedia पर उसकी subsidiaries की list ही काफी बड़ी है: https://en.wikipedia.org/wiki/Meituan
      जैसे Amazon ने AWS बनाया, वैसे ही Meituan भी अपने tech experience का काफी उपयोग कर रही है
    • Meituan में मुझे impressive यह लगा कि China के अलग-अलग हिस्सों में power bank rental machines थीं, और लोग अपना power bank साथ रखने के बजाय सुविधा के कारण इन्हें rent पर लेना पसंद करते थे
    • Lidl को own करने वाले group ने भी STACKIT बनाया है

  • Tiananmen Square के बारे में पूछा तो उसने कहा, “बहुत ज़्यादा requests हैं। बाद में फिर try करें।” यह पहला सवाल था और मुझे पता है कि sample size एक ही है, फिर भी बात खटकती है

    • मैंने Grok से पूछा कि Elon Musk ने कितनी बार cheating की, तो उसने भी बिल्कुल वही जवाब दिया

  • जब तक आपके desk के नीचे कुछ production servers नहीं रखे हैं, यह इतना बड़ा है कि local hosting के लिए इस्तेमाल करना मुश्किल होगा
    Q2 या Q1 में fit करने की कोशिश करने वालों के लिए भी यही बात है। model को इतना काट-छांटकर खराब करने का कोई मतलब नहीं कि फिर दावा करें कि यह अभी भी जिंदा है