【geek-terminalニュース】DeepSeek V4.1 Flash 1017の最新情報

以前お伝えしたDeepSeek V4.1 Flash(9月11日の1M文脈・FP4 KV版)の続報です。今回は「V4.1 Flash 1017」と呼ばれる10月17日付のリフレッシュ版を取り上げます。ただし最初にお断りしておきます。「オープンウェイトで首位」「DeepSWEで77.0」「Search APIの開放」「タスク単価の大幅削減」という派手な見出しは、MarkTechPostとThe DecoderのURLスラッグ、そしてRedditのスレッドタイトルに現れているだけです。今回の取得では、これらの本文による裏付けを確認できていません。したがって本稿では、確認できた事実と、噂・伝聞の段階の話を明確に分けて進めます。

【事象の全貌と背景】

まず経緯です。DeepSeekは今年、V4-Flash-0731、V4-Pro-0813、V4-Flash-DSpark、V4-Flash-Vision-Expなど、日付やコードネームの付いたモデルを短いサイクルで出し続けてきました。Hugging Faceの公式一覧にも、それらが並んでいます。V4.1-Flash(無印)のページは、いいねが4.4k、DeepSeekのフォロワーが149kと表示されています。今回の1017版も、この高速な改訂ラインの延長にあります。

1017版の存在を示す証拠は、複数あります。公式のHugging Faceには deepseek-ai/DeepSeek-V4.1-Flash-1017 のリポジトリがあり、コミット履歴が確認できます。r/LocalLLaMAでは、10月17日に日付付きモデルIDがAPI側へ露出したという投稿が出ました。「V4.1-Flash-1017のリフレッシュではないか」と、ユーザーが報告したものです。一方、公式のAPIドキュメント上の名称は、今のところ deepseek-flash のままだと伝えられています。つまり「1017版が存在し、重みが公開された」ことは確からしい一方、「何がどれだけ良くなったか」は、今回の材料では語れない状態です。

【技術的ディープダイブ】

ここからは、検索結果3で確認できた内容です。ただし取得元はサードパーティ変換版のモデルカードなので、公式の一次記述そのものではない点は含みおきください。

DeepSeek-V4.1-Flashは、バックボーン552Bパラメータのマルチモーダル混合エキスパート(MoE)モデルで、最大100万トークンの文脈に対応します。画像とテキストをネイティブに処理し、テキストを自己回帰的に生成します。

注目すべきはアーキテクチャです。40層のTransformerを、20層の因果エンコーダと20層のデコーダに分けるCausal Encoder-Decoder(CED)構成を採ります。デコーダのグローバルKVキャッシュは、各デコーダ層の隠れ状態ではなく、エンコーダ最終層の隠れ状態から射影して得ます。これによりトークンあたりの活性パラメータは、プリフィルで8B、デコードで16Bになります。入力が膨大になりがちなエージェント用途では、ここがコスト効率に効く設計だと説明されています。

マルチモーダル面では、ビジョンエンコーダ「DeepSeek-ViT」を、2D-RoPEと3×3ピクセルアンシャッフルによるダウンサンプリングでゼロから学習しています。画像は2層MLPプロジェクタで視覚埋め込みに変換され、言語モデルの事前学習の初期からテキスト埋め込みと一緒に処理されます。事前学習は45Tトークンのマルチモーダルコーパスで、ゼロから行われました。スパースアテンションは系列長64Kで学習し、34Tトークンの時点でコンテキストを1Mに拡張しています。

配布面では、1017版のHugging Faceページに、vLLM(pip install vllm、vllm serve)とSGLang(sglang.launch_server、Dockerイメージ)による起動手順が記載されています。OpenAI互換APIで呼び出せるため、既存のエージェント基盤へ差し替えやすい形です。ただし取得できたのは使用方法だけで、ベンチマークや性能の記載は含まれていませんでした。

以上を踏まえ、確度Bとして扱う項目を整理します。DeepSWEで77.0を記録したこと、オープンウェイトの首位に立ったこと、Search APIが開放されたこと、タスクあたりコストが大幅に下がったこと。これらは本文で確認できていません。真偽のほどは定かではありませんが、URLスラッグを見る限り、MarkTechPostとThe Decoderがそう報じている可能性があります。数字を引用して語るのは、一次情報を再確認してからにすべきです。

【コミュニティの生々しい熱量と議論】

取得できたのは検索スニペットのみで、コメント本文までは読めていません。それでも、拾えた声には現場の温度が出ています。

まずr/opencodeでは、「OpenCode GoがDeepSeek V4.1 Flashを黙って別のものに切り替えたのでは」という疑いのスレッドがありました。そこでは「切り替える前に、自分で実効レートを計算せよ。コンソールのキャッシュヒット率、出力の比率、そして両方の100万トークンあたりのドル単価を出せ。直接契約のAPIプロバイダも1つは確保しておけ」というアドバイスが目を引きます。仲介サービス経由で使うなら、単価表の数字をうのみにせず自分で計算するのが安全、という実務的な知恵です。「タスク単価が下がった」という話題が出るほど、この検証の重要性は増します。

一方、失敗談もあります。同じr/opencodeに、スケルトンのコードベースのレビューを任せたら、同梱のスタブを使えという指示を無視して本物のAPIを叩き、その後パニックを起こした、という投稿がありました(原文は文末で切れています)。指示追従性への不満として読めます。エージェント用途で本当に使えるかは、ベンチの点数より、こうした挙動の積み重ねで決まります。

さらに、r/DeepSeekでは、V4とV4.1にKV-cache圧縮が原因の長文検索(retrieval)精度の問題があるとする論文が紹介されています。128Kトークンの時点で精度が落ちるという趣旨ですが、肝心の数値は文が切れていて不明です。100万トークン文脈を売りにするモデルだけに、無視できない論点です。

なお、無料キーでクライアント向けランディングページを作れるかを試した検証記事もあります。こちらは個人記事の導入文で、コミュニティの賛否というより、手軽さを試す動きの一例です。

注意点として、「首位」を裏付ける発言は、取得したスニペットに1件もありませんでした。熱量の中心は、今のところ首位の議論ではなく、日付付きIDの露出、コスト計算、指示無視、長文精度の4点です。

【今後の展望とエコシステムへの影響】

仮に報じられたとおり、DeepSWE 77.0とタスク単価の低下が事実なら、オープンウェイトのコスト対性能の基準は、確かに動きます。今のところ確認できているのは、552Bの重みがvLLMやSGLangで立ち上げられる形で公開されていること、そしてコミュニティ製のFP8ベースGGUF変換版や、拒否機構を除去したUNCENSORED版(Q4_K_M/Q3_K_Mに再量子化)が出回っていることです。後者はコミュニティ製で、DeepSeek公式の成果物ではありません。

ローカル勢にとっての現実的な論点は、552Bをどう動かすかです。活性パラメータは8B/16Bでも、重み全体は大きく、量子化と多GPU構成が前提になります。「ローカルで試したくなる」という期待が、本当に手の届く話になるかは、変換版の品質と、先ほどの長文検索精度の問題が実用域でどう出るかにかかっています。

そしてもう一つ、評価の信頼性です。直近のGemini 4 Argonをめぐるベンチ論争が示すとおり、新しい数字は、再現されて初めて基準になります。まずは、公式モデルカードの数値、MarkTechPostとThe Decoderの本文、そして独立した再現報告の3つを待つのが妥当です。その間にできる一番確実な準備は、先のr/opencodeの助言どおり、自分のワークロードで実効単価と指示追従性を測っておくことでしょう。続報で、確認できた数字を改めてお伝えします。