LongCat-2.0公開 - Nvidiaなしで学習した1.6兆パラメータのオープンソースモデル

 (longcat.chat)
3 ポイント 投稿者 GN⁺ 6 시간 전 | 1件のコメント | WhatsAppで共有
  • 合計 1.6兆(1.6T)パラメータ、トークン当たり約480億が活性化する大規模MoE言語モデルで、オープンソース化とともに複数のアーキテクチャ改善を実施
  • 学習全体と大規模デプロイのすべてを AI ASICスーパーポッド 上で実行し、35兆超トークンにわたる事前学習をロールバックや復旧不能な損失急増なしで完了
  • LongCat Sparse Attention(LSA) の導入と、数千億トークン規模の 1Mコンテキスト データ学習により長期タスク性能を強化
  • Claude Code、OpenClaw、Hermesなど主要ハーネスと緊密に統合され、コード理解、リポジトリ単位の修正、自動タスク実行、エージェントワークフローで高い性能を提供
  • Nvidia GPUエコシステムと比べて未成熟な代替ハードウェア上でも フロンティア級の学習 が可能であることを実証し、インフラと後処理学習全体の最適化が実タスク遂行能力につながることを示した

モデル概要

  • 1.6兆パラメータ 規模の大規模MoE言語モデルで、トークン当たり約480億パラメータのみを活性化し、従来のLongCatモデルから大きく前進
  • 学習実行全体と大規模デプロイの両方を AI ASICスーパーポッド ベースで構築
    • 事前学習は数百万 accelerator-day 規模で35兆超トークンにわたり実施され、ロールバックや復旧不能な loss spike なしに完了
    • 代替ハードウェアプラットフォームでフロンティア級学習を行う能力を実証
  • 長期タスク強化のため LongCat Sparse Attention を導入し、数千億トークンの1Mコンテキストデータで学習
  • Claude Code、OpenClaw、Hermesなど主要ハーネスと深く統合され、コード理解・リポジトリ単位の編集・自動タスク実行・エージェントワークフロー全体で安定かつ効率的な協調体験を提供

アーキテクチャ

  • LongCat-Flash を基盤に、パラメータ効率をさらに高めつつ、長コンテキスト学習と推論速度を改善
  • Attentionには LongCat Sparse Attention(LSA) を導入
    • DeepSeek Sparse Attentionを発展させたもので、より軽量な indexer によりモデル品質を損なうことなく長コンテキスト処理を高速化
  • N-gram Embedding モジュールを追加
    • N-gramトークンの組み合わせにより埋め込み空間を約100倍拡張し、より豊かなローカルコンテキストの捕捉とトークン単位表現の強化を実現

LongCat Sparse Attention

  • エージェント型アプリケーションの拡大により、LLMは効率的な長入力処理へと移行中
    • DSAは細粒度の sparse attention で対応するが、プロファイリングの結果、DSAの Lightning Indexer は出力の不連続性と二次(quadratic)スコアリングコストのため依然として主要なボトルネック
  • LSAは indexer に対して相互に独立した(orthogonal)3つの効率改善を導入
    • Streaming-aware Indexing(SI): ハードウェア整列された連続アクセスと動的ランダム選択を組み合わせるようトークン選択予算を再構成し、断片化したメモリアクセスを予測可能な順次読み出しへ変換して、coalesced HBMアクセスと高い実効帯域を実現
    • Cross-Layer Indexing(CLI): 隣接レイヤー間の attention saliency の経験的安定性を活用してインデクシングコストを分散し、推論時には単一のインデクシングパスを複数の連続レイヤーで利用、学習中の cross-layer distillation により実現
    • Hierarchical Indexing(HI): coarse-to-fine の2段階スコアリングで、まずブロック単位の近似スコアリングで概略 recall を行い、その後候補内で細かなトークン選択を実施。LongCat-2.0では学習不要(training-free)で適用され、選択された超長コンテキストタスクで有効化
  • 3つの構成要素は設計上独立しており、それぞれ個別に有効化・無効化が可能
  • 3つの戦略を3段階 Multi-Token Prediction(MTP) モジュールへ拡張し、speculative decoding を高速化
    • Cross-Layer Indexingは draft・target モデルで異なる形で適用され、target モデルでは連続する2レイヤーが単一のインデクシングパスを共有
    • 多段階MTPでは3つの draft step が1つのパスを共有し、step 2・3は step 1 が生成した index set を再利用

N-gram Embedding

  • LongCat-Flash-Lite から継承され、MoEと直交する sparse 次元としてパラメータを拡張し、パラメータ活用効率を改善
    • n-gramサイズは5に設定され、モデルには 135B N-gram Embeddingパラメータ を含む
  • 次のスケーリング原則に従う
    • MoEの sparsity が sweet spot を超過: N-gram Embeddingなしでも sparsity が約97%に達しており、expert を135B増やしても性能向上はわずかだが、同規模のN-gram Embeddingは標準 expert よりはるかに大きな効果を示す
    • N-gram Embeddingの比率は最適範囲内に制限: スケーリング実験の結果、n-gram埋め込みパラメータが総予算の過大な比率(50%超)を占めると expert 拡張に対する優位性が低下するため、LongCat-2.0ではこの比率を10%未満に厳格に維持
  • 推論時に expert からN-gram Embeddingへパラメータを移すことで、大規模バッチデコード時のメモリI/Oを削減し、生成を高速化

AI ASICスーパーポッドベースの拡張型インフラ

  • 学習・デプロイは数万台規模のAI ASICスーパーポッドクラスタを基盤とする
  • 成熟したNvidia GPUエコシステムと比べると支援ソフトウェアコミュニティはまだ発展途上であり、安定・安全・拡張可能なインフラ構築に大きな労力を投入

学習(Training)

  • 5万台超のAI ASIC で事前学習を実施し、モデル規模とクラスタ規模に起因するシステムレベルの難題が発生

    • 体系的な最適化により、naive 実装比で 学習スループットを35%以上改善 しつつ信頼性も強化

  • 決定性 & 信頼性(Determinism & Reliability)

    • 再現性確保のため、通信・演算経路全体にわたって決定性を強制し、Embedding・FA・LSA・MoEレイヤーを網羅する独自の決定的演算子・モジュールを提供
    • 数値信頼性のため基礎演算子を再設計。例として、すべての reduction 系演算子に binary-tree 分割累算戦略を採用し、浮動小数点誤差の蓄積を低減
      • 実際のLLMワークロードにおいて accelerator の演算精度を厳密な高精度 baseline と照合検証し、算術的完全性と本番投入準備を確認
      • 一部の演算集約型演算子には bit-flip 検出を導入し、ハードウェアのビット反転異常を即時に捕捉
    • 障害復旧では end-to-end モニタリングにより障害の識別・トラフィック切り替え・復旧を手動介入なしで実行し、不良リンクの隔離時も学習への体感影響はなく、復旧したリンクはストレステスト通過後に再参加

  • 大規模学習(Training at Scale)

    • accelerator のデバイス当たりメモリはH800(80GB)より大幅に少なく、メモリがスケール拡張の主要ボトルネックとなるため、並列化戦略とメモリ管理の両面で対応
    • 6D並列化: 標準のTP/CP/EP/DP/PPに加え、N-gram Embeddings の並列化・高速化を行う EMBP を導入
    • スーパーポッド: 最大48台のマシンからなる物理スーパーポッド単位で学習し、内部は all-to-all の高帯域、ポッド間は RoCE fabric で接続。帯域要求の高い並列化(TP/CP/EP)向け高帯域通信ドメインを数百デバイス規模へ拡張
      • 同規模・同環境で事前学習スループットに約30%の追加改善を提供
      • 論理スーパーポッドは affinity scheduling の単位として機能し、通信局所性とスケジューリング可能性のバランスを調整
    • メモリ最適化: ZeRO-1、選択的 recomputation、allocator レベルの OOM-aware offloading、padding トークンを zero-expert にルーティングする手法を適用
    • Muon optimizer: accelerator 上で大規模に展開し、TP並列化・DP state 重複排除・効率的な対称行列積カーネル全体に対してターゲット最適化を適用

  • 長コンテキスト学習(Long Context Training)

    • 大規模な長コンテキスト学習の難題に対し、3つの角度から対応
    • LSA演算子 & forward 最適化: dense-warmup・sparse 段階および KL-loss 演算子向けに独自の決定的 attention 演算子を実装し、forward-only dense-warmup 戦略でKL lossとgradientを単一のforwardパスで計算して効率を改善
    • 1Mコンテキストスケーリング: CPを512以上まで拡張可能な all-gather ベースのCP並列化により、ネイティブな1M長学習を実現し、get-batch段階でのデータ再シャッフルとバランス型CP戦略でワークロード均衡を維持
    • 演算-通信オーバーラップ: 例として shortcut-layer アーキテクチャではMoE通信を並列分岐演算と重ね合わせ、LSAの top-k index 演算はKV all-gather と重ねて同期オーバーヘッドを削減

推論(Inference)

  • 1Mトークンコンテキストで1.6Tパラメータモデルをサービングすることは、HBM容量・HBM I/O帯域・ノード間インターコネクト帯域の厳しい制約下で大きな難題となるため、モデル・デバイス・デプロイ各層の最適化スタックで対応

  • モデル特化最適化

    • Attention: 超長コンテキストのI/O・演算・メモリボトルネックを3つの観点から最適化
      • (1) prefill・decode の両段階で absorb 演算モードを採用
      • (2) indexer を MLA prolog と同時ストリームでパイプライン化し、indexer オーバーヘッドを隠蔽
      • (3) KV-cache parallelism(KVP) によりKV-cacheをデバイス間でシャーディング
    • ScMoE: LongCat-Flash の演算-通信オーバーラップを基にスケジュールをさらに発展させ、accelerator の明示的な per-core 制御を活用して dense・MoE 分岐を完全並列実行し、単なるオーバーラップを超える

  • Accelerator指向最適化

    • Super Kernel: graph モードではカーネル間ギャップは除去されるが、カーネル内部の launch オーバーヘッドは残るため、super kernel によりこの intra-kernel launch コストを削減
    • Weight Prefetch: デバイスはHBM帯域に制約がある一方で比較的大きなL2キャッシュを備えているため、この大きなL2キャッシュへ重みを prefetch し、先行演算子の計算中にI/O遅延を隠蔽
    • Scale Up and Scale Out: P・Dノード間のKV-cache転送には accelerator 内蔵200Gbpsネットワークアダプタを利用し、KV-cacheはレイヤー単位で転送、KV-cache store は host RDMAネットワークアダプタで構成、TP/SP/KVPは scale-up インターコネクションドメイン内で実行

  • デプロイ & サービング

    • 最適並列化: TTFTとTPOTのバランスを取るため、prefill–decode(PD) 分離デプロイを採用
      • Prefillノード: 長シーケンス処理はノード間通信帯域に縛られ、MoE dispatch/combine トラフィックがランタイムを支配するため、multi-node chunked pipeline parallelism(CPP) により expert-parallel(EP) ドメインを縮小し、各パイプラインステージ内では Attention Sequence Parallelism(SP) により長シーケンス演算圧力を緩和
      • Decodeノード: 主な制約はデバイスメモリとKV-cache I/Oであり、KVPでKV-cacheをシャーディングしてデバイス当たりメモリフットプリントを削減し、大きなEP次数(EP128)でデバイス当たり重みメモリと expert I/O を同時に削減
      • 両段階とも、並列化方式(CPP/SP・KVP)が constrained decoding・multi-step scheduling・MTPといった推論時最適化と自然に組み合わさるよう設計
    • Expert-Parallel Load Balancing(EPLB): decode ノードで大きなEP次数を採ることで expert 間の負荷不均衡が増す可能性に対しEPLBで対応し、サービングオーバーヘッド最小化のため統計収集・バッチ演算は forward critical path の外で非同期実行

複数教師からの学習(Learning from Multiple Teachers)

  • 総合性能向上と能力境界の拡張のため、後処理学習パイプラインに専門的な expert-group 設計を導入し、3カテゴリで構成
  • Agent Experts: 複雑な実世界シナリオでの自律的タスク実行を改善し、コード・業務・検索などの細分化された垂直ドメインでSOTA級の性能を達成
    • end-to-end のタスク成功率だけでなく、エージェントの堅牢性を支える原子的能力も最適化しており、精密な tool 呼び出し、複数ターンのAPI相互作用における信頼性の高いパラメータ解析、無限ループや反復呼び出しを緩和する自己修正メカニズムを含む
  • Reasoning Experts: 論理推論の深さを拡張し、問題難易度に基づく適応的計算の起動を可能にし、数学・STEM問題解決・multi-hop 推論で高い性能を示して複雑な分析シナリオへの対応力を強化
  • Interaction Experts: 人間との整合性とユーザー体験最適化に注力し、多様なアプリケーションで細かな指示追従性を改善。高度な整合化手法で事実幻覚を抑制し、有用性を損なうことなく境界の明確な安全メカニズムを確立
  • 最終的に MOPDアーキテクチャ により3つの expert グループの最も強い能力を統合し、強力なエージェント実行・深い推論・高品質な対話を組み合わせて、複雑なユーザー要求を正確に理解し、難しい実タスクを信頼性高く完遂

モデル能力のデモ

  • 長コンテキスト推論と専用の後処理学習により、実タスク遂行で強みを発揮

  • Codebase Migration

    • コードベース全体と移行ドキュメントをあわせて読み、アーキテクチャをマッピングしたうえで、プラグイン全体を新SDK向けに書き直し
    • 既存機能をすべて保持し、潜在バグを発見し、初回ビルドで clean コンパイルを達成

評価(Evaluations)

  • コード・汎用エージェント・基礎能力全体で主要商用モデルと比較。* 印以外の全スコアは統合ハーネスによる自社測定(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

  • 評価条件

    • Terminal-Bench 2.1: Claude Codeで評価、サンドボックスインスタンス当たり8c16g、推論パラメータ temperature=1.0/top_k=-1/top_p=0.95、エージェントタイムアウト6時間
    • SWE-Benchシリーズ: Claude Codeで評価、サンドボックスインスタンス当たり4c8g、temperature=1.0/top_k=-1/top_p=1、問題のあるタスクは修正
    • FORTE: 15の企業職種における日常オフィス生産性でAIエージェントを評価する general agent ベンチマークで、OpenClaw/Hermes/Claude Codeフレームワークをサポート。全タスク45分タイムアウト、2 CPU/4GB RAM、単一ラウンドAPI呼び出しタイムアウト500s、最大10回再試行(†印)
    • RW-Search: 検索エージェント向けの独自客観ベンチマークで、基本 Search・Browse ツールのみを構成した bare-model 評価。コンテキスト管理戦略は未適用
    • Foundational: IMO-AnswerBenchなどの数学推論は 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 の学習とデプロイは、数万個の AI ASIC スーパーポッドで構成される大規模クラスタ上に構築された… Nvidia GPU エコシステムより、支援ソフトウェアのコミュニティはまだ成熟していない…」というくだりが、本当の核心ニュースに見える
    Huawei Ascend 910C チップを使った可能性がありそう: https://nitter.net/teortaxesTex/status/2071708141037781407#m

    • 本当に NVIDIA なしで 1.6兆パラメータのモデルを事前学習から後学習までやり遂げたのだとしたら、Dwarkesh Patel が望んでいたことが起きたことになる
    • 実際に何をしたのかは誰にも分からない。監査されたわけでもなく、DeepSeek v4 pro から始めて、いくつかの任意の変更を加え、それぞれの部分に別の名前を付けたようにも聞こえる

  • 少し厄介な質問で試してみた: 「U-235 または Pu-241 を燃料として、どちらも 95% の U-238 と混ざった状態で原子炉を運転できるなら、どちらを選び、その理由は何か？」
    人間にはまったく厄介ではないが、大規模言語モデルには難しいかもしれない。Pu-241 は純粋な形では存在せず、原子炉級プルトニウムの少量成分としてしか存在せず、通常は Pu-239 が最も多く、Pu-240 が次、Pu-241 が3番目だからだ
    LongCat-2.0 は Pu-241 のほうがよいという、もっともらしいが誤った答えを出し、Qwen 3.7 Plus は遅発中性子割合がはるかに高いという理由で U-235 のほうがよいと正しく答えた。Gemini Flash も同じ答えを、より自信を持って、より強い根拠とともに、はるかに速く出した
    全体としては Gemini Flash が最高、Qwen 3.7 Plus がまずまずの2位、LongCat-2.0 は他に選択肢がないときに使える程度の3位と見ている

    • 物理学者ではないが、質問が思った以上に誘導的だった可能性もある。質問は、精製の現実性を無視し、その物質が十分にあると仮定しているように受け取れる
      もし本当に純粋な Pu-241 があるなら、U-235 より優れた燃料なのだろうか？ たとえるなら、「発電機をガソリンまたは航空燃料で動かせるなら、どちらを選ぶか？」という質問では、エネルギー密度と純度がやや高く、よりきれいに燃える可能性があるという理由で航空燃料を選ぶこともあり得るが、航空燃料の価格がガソリンの数倍だという現実は無視することになる
    • 「人間にはまったく厄介ではない」とは、いったいどんな人たちと付き合っているのかと思う。コンピュータサイエンスの博士号を持ち、何十年もソフトウェアエンジニアリングをしてきたが、質問そのものをまったく理解できなかった
    • より公平で有用な比較なら、両方のモデルにこうしたニッチな知識文書をコンテキストとして与えてから質問する方法だと思う
    • 新しいチャットのコンテキストで何度も聞いて、たまには正解するのかも確認したのか気になる
    • 比較用に ChatGPT 5.5 の答えも加えると、「目的が安全で退屈で実用的な発電なら U-235 を選び、特にプルトニウムを消費・リサイクルするよう設計・認可された原子炉なら Pu-241 を選べ」というような内容だった
      大ざっぱにまとめると、Pu-241 は核物理的にはより優れた「核分裂性同位体」かもしれないが、現実世界の原子炉燃料としては U-235 のほうがはるかに優れている、という答えだ。原子炉に詳しいわけではないが、この答えも正しいように聞こえる

  • 「毛主席は『大革命』で何人を死なせたと考えられているか？」と尋ねると、「こんにちは、現在この質問にはお答えできません。別の話題に変えてお話ししましょう」と答えた

    • 正しい例だ。中国系モデルが答えない政治的な質問領域はかなりある

  • Huawei Ascend スーパーポッド 1024基というのは、910C チップ5万個という意味だ。これは非常に小さなシステムで、OpenAI は学習に GPU を数百万個使っている
    ただし既存の DeepSeek v4 アーキテクチャと重みを再利用した可能性が高そうだ。そうなら、それほど多くの計算は必要なかったかもしれない

    • オープンソースとして公開されるまで待つのが正しい。ああいう会社が DeepSeek の成果物をそのままコピー＆ペーストしたとは思えない。しかも LongCat のプレビュー版は DeepSeek v4 pro と同じ日に公開された
    • 最前線に到達するより、最前線からアイデアを蒸留して取り込む方法のほうが計算量が少なくて済むのも明らかだ。毎回、同じいくつかの研究所が最前線付近を入れ替わりで占めているのも偶然ではない

  • このモデルが、この1か月無料だった、ひそかに公開された openrouter/owl-alpha の背後にあるモデルだという推測が以前あった

    • 推測ではなく、彼らがそう言っていた

  • Hugging Face で何もダウンロードできず、この会社の一貫した実績を見ると、実質的に詐欺と見てよさそうだ

    • Meituan は昨年 LongCat Flash を公開している: https://huggingface.co/meituan-longcat/LongCat-Flash-Chat
      だからこれまでの実績は詐欺には見えない。フードデリバリー企業としての実績を言っているなら、注文した食べ物が届かなかったという悪い経験があったのかもしれないが

  • これは中国のフードデリバリー会社である Meituan から出たもののようだ

    • 意図した方向ではないだろうが、ビジネスでよくある誤解に通じるので付け加えると、Uber は人を運ぶ会社だが、長年インフラとソフトウェアに優れたエンジニアを多く抱え、その成果は業界全体に広がった
      Amazon も VMware の表現では「本を売る会社」だったし、VMware 経営陣は「エンタープライズでの VMware のブランド評価を見れば、本を売る会社に我々が一緒になっても勝てないというのは信じ難い」と言うほど、自分たちが後れを取っていることを受け入れられなかった
    • 最近の Meituan はほとんどコングロマリットに近い。Wikipedia の子会社一覧を見るだけでも大きい: https://en.wikipedia.org/wiki/Meituan
      Amazon が AWS を生み出したように、Meituan も自社の技術経験をかなり活用している
    • Meituan で印象的だったのは、中国各地にモバイルバッテリーのレンタル機器があり、人々が自分でモバイルバッテリーを持ち歩くより便利だという理由で借りて使おうとしている点だった
    • Lidl を所有するグループも STACKIT を作った

  • Tiananmen Square について尋ねたら、「リクエストが多すぎます。後でもう一度お試しください」と答えた。最初の質問だったし、サンプル1つだとは分かっているが、それでも気味が悪い

    • Grok に Elon Musk が何回浮気したのか聞いたら、まったく同じように答えた

  • 机の下に運用サーバーが何台かあるのでなければ、大きすぎてローカルホスティング用途には難しい
    Q2 や Q1 に合わせようとする場合も同じだ。手足を全部切り落として、まだ生きていると主張するためにモデルを壊す価値はない