本文へ移動

コード性能だけなら、MITで配られた763Bが頂に並んだ──DeepSeek V4.1-Flash-1017が、SWEベンチでOpus 5とGPT-5.6 Solを抜いた

DeepSeek が10月17日、MIT ライセンスのオープンウェイトモデル V4.1-Flash-1017 を公開。コーディングを測る DeepSWE v1.1 で77.0を出し、Opus 5 と GPT-5.6 Sol をこの一点で上回った。自前運用も安価な API も選べる反面、HLE など総合推論ではまだ差があり、“黙って差し替わる”更新の死角も。

コード性能だけなら、MITで配られた763Bが頂に並んだ──DeepSeek V4.1-Flash-1017が、SWEベンチでOpus 5とGPT-5.6 Solを抜いた

中国 DeepSeek が10月17日、オープンウェイトのモデル「DeepSeek-V4.1-Flash-1017」を Hugging Face で公開しました。ライセンスは MIT、位置づけは前版 V4.1-Flash の「マイナーアップデート」です。ところが、ソフトウェア開発の実力を測るベンチマーク DeepSWE v1.1 で77.0 を記録し、クローズドのフロンティアモデルである Claude Opus 5(74.0)と GPT-5.6 Sol(73.0)を、この一点で上回りました。重みが誰でもダウンロードでき、手元やオンプレで動かせる点が、開発者にとっての最大の論点になります。

「マイナー更新」が、コードの一点でフロンティアを追い抜いた

公開されたモデルは総パラメータ約763B、コンテキストは最大100万トークン、1回の出力は最大38万4千トークンまでという構成です。DeepSeek は、公開した11個のベンチマークすべてで前版を2.0〜11.1ポイント改善したとしています。主要な数値を整理します。

ベンチマーク測る内容V4.1-Flash-1017前版比較(クローズド)
DeepSWE v1.1ソフトウェア開発77.074.2Opus 5: 74.0 / GPT-5.6 Sol: 73.0
Terminal-Bench 4.0ターミナル操作42.331.2Opus 5 が上位とされる
Apex複合推論72.1——
HLE難問推論42.6—Opus 5: 56.3

DeepSeek は今回の更新で、タスクの実行時間と出力トークン量を削り、「同じ仕事をより速く・より安く」仕上げる方向に振ったとも説明しています。コーディングエージェントのように何十手もツールを呼ぶ用途では、出力が短いほどレイテンシと課金が積み上がりにくく、ここは地味に効いてきます。

得意はSWE寄り、総合の推論力にはまだ差がある

一方で、「Opus 5 を抜いた」のは、あくまで DeepSWE というコーディング指標での話です。難問推論を測る HLE では Opus 5 が56.3で、本モデルの42.6を大きく引き離しており、Terminal-Bench 4.0 でも Opus 5 が上位にあると報じられています。得意分野は明確にソフトウェア開発寄りで、あらゆるタスクでフロンティアを置き換える段階ではありません。導入を検討するなら、自分の用途に近いベンチマークに絞って評価するのが現実的です。

「開くか、閉じるか」の二択を外した──MITで配り、API代も据え置く

このモデルのいちばんの意味は、スコアそのものより重みが MIT で降りてくることにあります。社外にコードを出せない組織でも、自前の GPU サーバや自社クラウドに載せてコーディング支援を内製でき、クローズド API への依存やデータの越境を避けられます。763B という規模は個人の PC には重く、量子化や複数 GPU が前提になりますが、オンプレのサーバなら射程に入ります。あわせて提供される API の料金は次のとおりです。

項目料金(通常・オフピーク時)
入力(キャッシュミス)$0.15 / 100万トークン
入力(キャッシュヒット)$0.003 / 100万トークン
出力$0.60 / 100万トークン
Search / Fetch API成功1,000件あたり $0.75(10月31日まで無料)

平日のピーク時間帯はトークン単価がおよそ2倍になります。Search / Fetch API は1アカウントあたり毎秒5リクエストの上限が設けられています。「自前で動かす」「安い API で回す」の両にらみができる点が、クローズド一択だった選択肢を一つ広げます。

同じ名前のまま、中身が入れ替わる──“黙ってデプロイ”の死角

報道によれば、今回の更新は既存の API 識別子のまま、changelog も出さずに差し替えられたとされます。つまり API を呼んでいた既存の利用者は、ドキュメントが整う前に挙動の変化を受け取っていたことになります。これは、AI の API を「固定バージョンの依存先」ではなく「継続的に中身が変わるパイプライン」として扱う流れの一例と言えます。

利便性の裏で、こうしたサイレント更新には再現性の面でリスクも指摘されています。出力の癖やトークン量が黙って変われば、評価結果やコスト見積もり、下流の自動化が静かにズレる恐れがあります。対策はシンプルです。

  • バージョンを固定できるなら固定する。日付付きのタグやオープンウェイト版をピン留めし、「動く既知の状態」を手元に確保する。
  • 重要な処理は更新のたびに回帰評価をかける。品質とコストの両方を小さなテストセットで監視する。
  • オープンウェイトを保管しておく。クラウド側の挙動が変わっても、同じ重みで再現・検証できる逃げ道を持つ。

オープンウェイトのモデルが特定のベンチで最前線に並ぶ事例が続くほど、「クローズドの最強モデルに一本化する」以外の選択肢が開発者の手に増えていきます。今回の V4.1-Flash-1017 は、コーディングという一点に限れば、その選択肢が実用の射程まで来たことを示す一例と言えそうです。もっとも、得意分野の見極めとバージョン管理という宿題も、同時に差し出してきています。

参照: DeepSeek 公式ニュース / MarkTechPost: Scores 77.0 on DeepSWE / AI Weekly: Opens weights and $0.75 Search API / SmartScope: Benchmarks & price / Hugging Face モデルカード