2 ポイント 投稿者 GN⁺ 2026-04-30 | 1件のコメント | WhatsAppで共有
  • 128B Denseモデルで、命令実行・推論・コーディングを単一の重みで統合し、256kコンテキストウィンドウをサポート
  • リクエストごとに 推論努力 を調整でき、簡単なチャットから複雑な エージェント型タスク まで1つのモデルで対応
  • SWE-Bench Verified 77.6%、τ³-Telecom 91.4点で Devstral 2 および Qwen3.5 397B A17B を上回る
  • ビジョンエンコーダを新たに訓練し、可変の画像サイズとアスペクト比 の処理が可能
  • Vibeリモートエージェント により、コーディングセッションをクラウドで非同期実行し、複数セッションを並列で回して完了時に通知を受信
  • CLI または Le Chat から開始でき、ローカルセッションをクラウドに テレポート すると履歴・状態・承認履歴をそのまま移行
  • 各セッションは 分離されたサンドボックス で実行され、完了時に GitHub PR を自動生成
  • GitHub、LinearJiraSentry、Slack、Teams など既存の開発ツールと統合
  • モジュールのリファクタリング、テスト生成、依存関係のアップグレード、CI 調査、バグ修正など、反復的で明確に定義されたタスク に適する
  • Le Chat の Workモード(プレビュー)は、メール・カレンダー・メッセージなど複数のツールを同時に活用し、マルチステップ作業を完了まで自動実行
    • コネクタはデフォルトで有効化され、すべてのツール呼び出しと推論根拠を表示し、機密性の高い作業では明示的な承認を要求
  • API 料金は入力 100万トークンあたり $1.5、出力 100万トークンあたり $7.5
  • オープンウェイトを修正版 MIT ライセンスで公開し、最小 4基のGPUでセルフホスティング 可能

1件のコメント

 
GN⁺ 2026-04-30
Hacker Newsの反応
  • コメント欄のみんなが何を見ているのかわからない。このモデルは他のモデルに勝てはしないが、サイズ対比の競争力は間違いなくある。
    GLM 5.1は素晴らしいが、Q4でも約400GBが必要で、Kimi K2.5も良いが、Q4量子化基準でほぼ600GBが必要だ。
    このモデルはQ4で70GB VRAMで動かせるので、消費者向けの領域に近づいている。128GB RAMのMac Studioが約3500ドルで買えるレベルだ。
    Claudeに夢中な人たちはOpusしか使っていないのかもしれないが、ProプランのSonnetもすでにかなり有能だった。このモデルはローカルで動かしつつ最新のSonnetに勝ち、repoにHERMES.mdがあるからといって追加課金したり、アカウントを恣意的に凍結したりもしない。
    Mistralがfrontierで競争力を持ったことはなかったが、もしかするとそれは私たちがMistralに期待すべき役割ではないのかもしれない。コスト/サイズの20%でfrontierの80%を出すパレートモデルなら十分に良さそうだ。

    • ローカルLLMに関心がある人なら、モデルを「動かせる」ことと「速く動かせる」ことはまったく別の基準だと知っておくべきだ。
      128GB Macでこういうモデルを実行することはできるが、まずQ4が品質を十分保てるかを見る必要がある。モデルごとに量子化感度は異なり、実際の速度も重要だ。
      非同期作業やバックグラウンド作業では、プロンプト処理やトークン生成速度の重要性は下がるが、多くのMac Studio購入者は、クラウドのまともなハードウェア上でホストされるモデルほどの応答性がないことを痛感してきた。
      オンプレミス処理の要求が強くない大半の人にとっては、このモデルをOpenRouterのホスティング提供者の1つとして使い、トークン単位で支払うのが最善の使い方かもしれない。
      今年出たほぼすべてのオープンウェイトモデルがSonnetと同等かそれ以上だと言われてきたが、ベンチマークで明確に上回っていても、実際にそう感じたことはまだない。
    • HERMES.mdを知らなかったが、気になる人はここで情報を見つけられる https://github.com/anthropics/claude-code/issues/53262
    • 2月以前はMaxプランでOpus Highを問題なく使い続けられたが、今はSonnet Highしか使っておらず、それでもかなり有能だ。
      Claude Pilledという表現は気に入った。
    • 「ローカルで動かしつつ最新のSonnetに勝つ」というのは事実ではない。
      ベンチマークはF8_E4M3基準で、それをどのMacでも動かせるわけではない。
      Sonnetには1Mトークンコンテキストがあるが、このモデルは256kで、ローカルではそれすらまともに使えない可能性が高い。
      Sonnetはネットワーク越しでも速いが、このモデルははるかに遅いはずだ。
    • Qwen 35B A3B MoEも忘れてはいけない。このモデルよりすべての指標で性能が高く、メモリ/計算コストもはるかに小さい。
      中国以外のオープンソースモデルが最低でも1世代遅れて見えるのは残念だ。
  • いつでもMistralを応援している。モデルと国家の多様性は重要だ。
    今回のモデルはその上に積み上げるのに適した堅実な土台のように見え、3.6/3.7でさらに多くの改善が入ることを期待したい。computer useベンチマークを見ると、vision pipelineには改善の余地がありそうだが、これは推測にすぎない。
    いくつかのベンチマーク結果が異なるのを見ると、frontierのログを抜いてきたのではなく、本当に独立して学習したモデルという感じがする。これも非常に重要だ。
    特定のモデルの中に別のweight architectureが存在することは、グローバルなシステムアーキテクチャの観点から、それ自体が利点のように見える。

  • Mistralが引き続き信頼できるモデルを出しているのは市場にとって良いことだ。
    買い手が価格や導入に関する交渉力を持つには、2社のうちどちらか1つを選ぶだけの構造を超える必要がある。

  • テストした他のホスト型LLMと比べると、Mistralだけがかなり厳格なCSPヘッダーを使っているようだ。
    JavaScriptライブラリ入りのWebサイトを作ってくれと頼むと、Le Chatにcanvas modeがあってもプレビューできない。
    新しいリリースが出たとき、ときどきWeb上で少し試したいだけなのに、課金するかagent harnessを使わないと難しい。
    SVG描画は本当に苦手だ https://chat.mistral.ai/chat/23214adb-5530-4af9-bb47-90f5219...

    • SVGが最高のベンチマークとは限らないが、以前のMistralモデルをMistral Vibeで使った体験とは一致している。
      VibeでMCPサーバー設定を手伝ってくれと頼んだら、MCPをMineCraft Protocolだと自信満々に説明し、その後コンピュータ上のMinecraftバイナリを探し始めた。
    • LLMにSVGを描かせたいと思ったことも、必要だと思ったことも、期待したこともない。
      どのモデルもこれには弱く、いくつかのモデルがただより面白く失敗するだけだ。
  • mistral-medium-2508をテキスト変換作業に使っているが、自分の用途ではmistral-largeより良い結果を出してくれる。
    新モデルも試してみたいが、ずっと高価で、coding/agenticモデルとして提示されているので、以前のmediumモデルを置き換えるつもりなのかはよくわからない。
    mistral-medium-2508は100万トークンあたり$0.4/$2だったが、mistral-medium-3.5は**$1.5/$7.5**だ。

    • 本番環境で大きなテキストの塊を処理するのにMistral Largeを使っている。
      Sonnetとほぼ同等の結果を出しつつ90%安い。コーディングには絶対使わないが、このテキスト分析作業には非常に良かった。最新の中国モデルよりもずっと良かった。
      だから今回のリリースを待っていたのだが、最新のMistral Largeより5倍高い。安価なLargeをこのリリースへの切り替えに合わせて終了させるのではないかと心配している。
  • このモデルの問題は、DeepSeek v4 Flashが2ビット量子化でもかなりうまく動くことだ https://github.com/antirez/llama.cpp-deepseek-v4-flash
    M3 Ultraでは生成30 t/s、prefill 400 t/sが出て、128GB MacBook Pro M3 Maxでもそれほど遅くない。
    opencode/piと組み合わせると優れたcoding agentとして機能し、tool callingも非常に安定している。この速度は120B denseモデルでは絶対に達成できない。
    つまり、同サイズの4ビット量子化モデルだけでなく、86GBのGGUFファイルであるDeepSeek v4 Flashとも競わなければならず、ローカル推論の実戦的な観点では勝つのが簡単ではない。
    まだコミットしていない速度改善もさらにあり、近いうちにpushする予定だ。現在のtreeも少し遅いかもしれないが、それでも十分実用的だ。
    ヨーロッパにいるMistralファンとしても理解できない点がある。MistralはMixtralでオープンウェイトMoEの流れを切り開いたのに、なぜ今かなり大きなdenseモデルを出すのかわからない。
    このやり方では、ローカル推論でもリモート推論でも安定して競争するのは難しい。モデルはSOTAから距離があり、サービングコストも安くないからだ。
    denseモデルにはQwen 3.6 27Bのような数十Bパラメータ帯なら居場所があるが、その5倍に行くなら、同じVRAMを要求する他モデルを能力で圧倒しない限り合わない。

    • GitHubリンクには「この方法で量子化したモデルはチャットでは非常によく動作し、frontier-model vibesがあるが、広範にはテストされていない」とあるだけだ。
      これはagentic workflowでどう動くかとはほとんど関係がない。Q2量子化で品質が大きく低下することが多いのはすでにわかっている。
      この量子化されたFlashが、より大きなコンテキスト長でも適切な品質と性能を維持できるなら、V4シリーズの中核機能と思われる部分まで保ちながら、Qwen 3 Coder-Next 80Bのような同じweight classのモデルに対してかなり妥当な競合相手になり得る。
  • 今回のMistralリリースは、frontier labとそれ以外のプレイヤーとの格差をあらためて感じさせる。
    agent以前は、モデル間の差は常に明確だったわけではなく、それぞれのモデルにそれなりの魅力があった。
    今ではfrontierモデルより劣るものは使いたくない。能力差が大きく、劣るモデルを選ぶと生産性に実際のコストが生じる。
    Mistralや、とくにCohereのような小さなlabは好きだったが、両社のリリースで興奮したのはかなり前だ。
    それでもmistral voxtral realtimeは毎日使っていて、素晴らしい。

    • まったく同意できない。わずか1年前のほうが、frontierモデルとnon-frontierモデルの生産性ギャップははるかに大きかった。
      2年前ならなおさらだ。
    • non-agenticな作業では、Gemini、ChatGPT、Claudeの間に全体として明確な勝者はいない。単純なchatbotインターフェース基準では apples to oranges だ。
      しかしClaude CodeはCodexよりかなり良く、CodexはGemini-cliより明らかに良い。
      この文脈で、Claude Codeがagentic codingにおいてnon-frontierモデルよりはるかに優れているのは驚くことではない。特化したagentic作業では、他のfrontierモデルよりもかなり良い。
    • frontierモデルより劣るものは使いたくないというのは、かなりナイーブで誤った判断だ。
      複雑なコーディング作業を含むほとんどの作業では、frontierモデルとGPT-4.1のようなモデルの差をほとんど見分けられない。
      差を見るには、context window、tool calling、reasoning stepの特定の側面のような領域に本当に集中する必要がある。
      しかもfrontierモデルは、結果を出すために brute force 的なアプローチを取り、その分実行コストがずっと高くなる。請求額として見えるコストだけでなく、何らかの出力が出るまで待たされる時間も長くなる。
      ローカルモデルの話は持ち出さないでおく。
  • Mistralはここで長期戦をしているようだ。より小さいモデル、より低いコスト、全体として十分に良い性能だ。

  • 悪くはないが特別でもない。それでも米国でも中国でもないモデルの話は、やはり良いニュースだ。

    • これがヨーロッパの基準線なのだろう。
  • 128Bが今やMediumと見なされるのは笑ってしまう。
    昔はGPT-2で355Mパラメータがmediumと見なされていた時代があった。

    • GPT-2 1.5Bは公開するには危険すぎると考えられていた。
      もしかすると、その判断は正しかったのかもしれない。