DeepSeek V4.1 Flash 1017、Terminal Benchを31.2から42.3へ伸ばす

DeepSeekはV4.1 Flash 1017 checkpointを公開し、既存のdeepseek-flash識別子でweb、app、APIへ展開した。weightsもMIT licenseで公開されている。1017は10月17日の公開日を示し、新しいmodel familyを意味しない。

10月checkpointはagent benchmarkで大きく伸びた

DeepSeekの表では、Terminal Bench 4.0が31.2から42.3へ上昇した。DeepSWE v1.1は74.2から77.0、ProgramBenchは20.3から29.1となった。同社は、API価格を変えずにtask完了が速くなり、出力も短くなったと説明する。

V4.1 Flash 1017はtextとimageを扱える。ただし、この能力は10月版で初めて加わったものではない。native visionは9月のV4.1 Flashに既にあり、今回新しいのは更新されたweightsと報告上の性能向上だ。

短い出力は高いscore以上の価値を持ち得る

agent taskの費用は1回のpromptだけでは決まらない。modelは状態を何度も読み、toolを呼び、次のstepを生成する。少ないtokenと短い時間で完了すれば、100万token当たりの価格が同じでも全体費用は下がる。

Open weightsはprivate deploymentと改変も可能にする。ただし、これは非常に大きいMoE checkpointで、一般的なGPU 1枚向けではない。多くの企業では、自社clusterよりhosted APIの方が安いだろう。

GLM 5.3との比較はまだ条件が揃っていない

Nathan Lambertは、visionを備えたままGLM 5.3を上回る可能性を示した。現時点では推測であり、独立検証済みの結果ではない。agent benchmarkはharness、tool、reasoning effort、task budgetに大きく左右される。

ベンダー表だけでは、特定のrepositoryやinterfaceでの挙動も分からない。高いscoreは試験候補に入れる理由にはなるが、production routingの根拠には足りない。

自社taskが時間と費用の節約を判定する

独立evalでは、DeepSeek、GLM、ほかのopen-weight modelを同じharnessと予算で比べる必要がある。end-to-endの成功率、token数、実行時間、人間の介入を測るべきだ。

DeepSeek API外での運用も重要になる。vLLMとSGLangの対応、memory要件、tool useの安定性が、open checkpointとして導入先を広げるのか、安価なhosted serviceを支えるだけなのかを決める。

Lilithの判定

DeepSeekは速い走者を連れてきたが、stopwatchの大半も自分で握っている。productionのバトンを渡す前に、自社のtrackで計るべきだ。