DeepSeek-V4.1-Flash ローカルデプロイと推論最適化

2026-09-10、DeepSeek は新アーキテクチャファミリーの中で最小サイズのメンバー DeepSeek-V4.1-Flash を発表しました：552B 総パラメータ MoE、まったく新しい Causal-Encoder-Decoder（CED）非対称アーキテクチャ、入力側はわずか 8B を活性化、出力側は 16B を活性化し、さらに 1M tokens コンテキスト、384K tokens 最大出力、ネイティブなマルチモーダル視覚理解を備えています。さらに重要なのは、ローカル展開者に向けたシグナルです：KV Cache は 1 token あたり約 890 bytes で、V4 Flash の約 3514 bytes と比較して、HBM 要件は前世代の 1/4、SSD ストレージは 1/8 に低減し、初代 DeepSeek と比べて約 437 倍 縮小しています。同時に、公式はオープンソースコミュニティと緊密に協力して V4.1-Flash の推論サポートを推進し、より多くの展開オプションを模索すること、2000 GPU + ストレージクラスタを対象とする大規模展開については公式と相談可能であることを明確にしています。重みは Hugging Face の deepseek-ai/DeepSeek-V4.1-Flash で公開され、技術レポートも添付されています。国家超算インターネットも 2026-09-11 に API サービスと重みファイルを公開しました。本記事の第1部では、アーキテクチャ、メモリ会計、KV Cache、長シーケンススケジューリングという4つの「難所」に焦点を当て、公式に公開されたデータを実行可能な展開パラメータとコード骨格に翻訳します。第2部では、高並行サービスオーケストレーションと負荷テスト調整に進みます。

CED 非対称アーキテクチャの分解：入力 8B / 出力 16B 活性化が MoE 推論パスをどう書き換えるか

従来の Decoder-only 大規模モデルは、各層で同じトークン群に対して同じアテンションと MoE ルーティングを行い、入力と出力の計算予算は高度に対称です。DeepSeek-V4.1-Flash の Causal-Encoder-Decoder（CED）非対称アーキテクチャはこの対称性を破ります：入力側（エンコーダの役割）は各トークンで 8B パラメータのみを活性化し、コンテキストを因果的に利用可能な表現に圧縮する役割を担います。出力側（デコーダの役割）は新しく生成される各トークンで 16B パラメータを活性化し、高品質な自己回帰生成を担います。ここでの「エンコーダ」は依然として因果的であることに注意してください。未来のトークンを見ることはできず、巨大なコンテキストを一度に読み込んで KV としてキャッシュするだけなので、検索型の双方向エンコーダとは本質的に異なります。

この分業が推論パスに与える影響は、3点に分解できます：

• 計算グラフの非対称性：Prefill 段階は 8B 活性化パスを通り、計算密度が低くメモリ帯域幅の圧力も比較的小さいため、長い prompt のスループットを高くしやすいです。Decode 段階は 16B 活性化パスを通り、1 token あたりの計算量と重み読み込み量が大きく、レイテンシの主戦場となります。エンジニアリング上は、最適化リソースを Decode に傾けるべきです。たとえば、出力側のエキスパートに対してより積極的な量子化と、より細かいエキスパート並列分割を行うなどです。
• メモリ使用量の分離：入力側の活性化は小さく安定しているため常駐に適し、出力側の活性化は大きく batch の増加に伴って増えるため動的割り当てに適します。両者を同じメモリプールで統一的な並列戦略の下に混在させると、「Prefill が Decode の重みを押し出す」OOM が発生しやすくなります。
• KV 生成のタイミング差：エンコード段階では全シーケンスの KV を一度に生成し、デコード段階では KV を増分的に追加します。出力側の活性化が高いため、Decode 段階では 1 token あたりの KV 書き込み圧力がより大きく、キャッシュチャンク戦略は Decode の KV 永続化帯域を優先的に保証する必要があります。

一言でまとめると：CED は「コンテキストを読む」ことを安く、「答えを書く」ことを高くします。これは後述するすべてのスケジューリング戦略の優先順位を直接決定します。Decode 回数を減らし、入力再利用率を高める最適化は、その効果が増幅されます。

552B 総パラメータ MoE のメモリ会計：単機マルチ GPU におけるエキスパート並列と重みシャーディングの実装

まずよくある誤解を正しましょう：552B 総パラメータは 552B の全量常駐メモリを意味しません。MoE のスパース活性化は、単一トークンが一部のエキスパートのみを通ることを意味しますが、重みはすべてアドレス可能でなければならないため、メモリ会計は「重み」「活性化」「KV」「フレームワークオーバーヘッド」の4つの帳簿に分けて計算する必要があり、公式に公開された 552B と 8B/16B 活性化に基づく比例推測のみを行い、未公開のパラメータは一切導入しません。

重みの帳簿：総パラメータ数は 552B。BF16（2 bytes/param）で見積もると、全量重みは約 1104 GB です。出力側エキスパートを FP8（1 byte/param）にし、残りを BF16 に保つ混合方式なら、約 700～900 GB 程度まで圧縮できます。これが、単機 8 カードで各カード 80GB（合計 640GB）であっても、単純な TP ではなく エキスパート並列（EP）+ テンソル並列（TP） の組み合わせが必要になる理由です。経験的な方法：

1. EP 優先：異なるエキスパートを異なるカードに分割し、All-to-All はルーティングでヒットしたカード間でのみ発生させます。エキスパート数とカード数の整除関係が負荷分散を決定するため、EP 度は単層のエキスパート数の整数倍にして、ホットスポットカードを避けることを推奨します。
2. TP で補完：アテンション重みと共有層を TP で分割し、単カード常駐メモリを削減します。TP が導入する All-Reduce は EP の All-to-All と相互接続帯域を奪い合うため、必ず両者を異なるリンクまたは異なるタイミングでオーバーラップさせてください。
3. 重みシャーディング：非アクティブなエキスパートは pinned host memory や NVMe に置き、プリフェッチを併用できます。ここで SSD 1/8 の効果が現れます。重みと KV の永続化要件が同時に低下します。

以下のコードは、ローカル展開時に最も直接的なメモリ予算プローブを示します。まず deepseek-flash に最小リクエストを送ってサービス到達性を確認し、次に公式の活性化比に基づいてローカルメモリ割り当てを見積もります。

import os
import requests

BASE = "https://api.deepseek.com"
KEY = "your-deepseek-api-key"
HEADERS = {
    "Authorization": f"Bearer {KEY}",
    "Content-Type": "application/json",
}

# 1) 接続性とモデル名の確認：公式 API のモデル名は deepseek-flash
def probe():
    payload = {
        "model": "deepseek-flash",
        "messages": [{"role": "user", "content": "ping"}],
        "max_tokens": 8,
    }
    r = requests.post(f"{BASE}/chat/completions",
                      headers=HEADERS, json=payload, timeout=30)
    r.raise_for_status()
    return r.json()

# 2) 552B 総パラメータのローカル重みメモリ予算
TOTAL_PARAMS = 552_000_000_000  # 公式発表の総パラメータ
BYTES = {"bf16": 2.0, "fp8_mix": 1.4}  # 混合精度の等価バイト係数

def weight_budget(n_gpus, per_gpu_gb, dtype="bf16"):
    total_gb = TOTAL_PARAMS * BYTES[dtype] / (1024 ** 3)
    capacity = n_gpus * per_gpu_gb
    return {
        "weight_requirement_GB": round(total_gb, 1),
        "cluster_capacity_GB": capacity,
        "headroom_GB": round(capacity - total_gb, 1),
        "fully_resident": capacity >= total_gb,
    }

if __name__ == "__main__":
    print(probe()["choices"][0]["message"]["content"])
    print(weight_budget(8, 80))     # 単機 8x80GB BF16
    print(weight_budget(16, 80, "fp8_mix"))  # 2台 16x80GB 混合精度

落とし穴の注意：8B/16B 活性化をメモリ要件と見なさないでください。それらは計算量を決定するもので、常駐重みではありません。MoE の All-to-All は小さい batch ではレイテンシ占有率が極めて高いため、continuous batching を有効にし、EP 通信と計算をオーバーラップさせることを推奨します。そうしないと、Decode 段階の 16B 活性化の利点が通信に食われてしまいます。

KV Cache サイズ実測：890 bytes/token と HBM 1/4、SSD 1/8 のデプロイ上の意味

これは今世代で最も「直感に反する」データであり、ローカル展開者にとって最も歓迎すべきものでもある。公式リリース投稿によると、V4.1-Flash は 1 token あたりの KV Cache が約 890 bytes、V4 Flash は約 3514 bytes である。これに基づくと、KV Cache の HBM 要件は前世代の 1/4 に下がり、SSD ストレージは 1/8 に下がり、初代 DeepSeek と比べると約 437 倍 縮小する。

この 3 つの数字を構成判断に翻訳すると：

実測レベルの意味：1M tokens のコンテキストを例にすると、単一シーケンスの KV は約 890 bytes × 1,000,000 ≈ 890 MB（マルチシーケンス増幅は考慮せず）。32 並列がそれぞれ 100K tokens を占める場合、約 32 × 100,000 × 890 bytes ≈ 2.85 GB となる。これは、KV がもはや VRAM を食い尽くす元凶ではなく、重みこそが第一の制約であることを意味する。したがって、ローカル展開の第一優先は「KV を節約する」から「重みを節約する + 高帯域相互接続」へと変わる。

対応するサーバー側の構成戦略：

• KV ページングブロック（block）はやや大きめに設定し、ページテーブル管理のオーバーヘッドを減らせる。890 bytes/token により単一ブロックのサイズがより穏やかになるため。
• HBM 内の KV プールは 1/4 で見積もればよく、節約した VRAM を出力側の 16B 活性化重みに回せる。
• SSD 側は 1/8 の容量で計画し、「長コンテキストセッションの全量永続化 + ホット/コールド階層化」を大胆に有効化できる。

次のセクションでは、公式 API を使って「token あたりの KV 永続化量を見積もる」検証スクリプトを作り、実際の同時実行曲線と照合しやすくする：

import requests

BASE = "https://api.deepseek.com"
KEY = "your-deepseek-api-key"
HEADERS = {"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"}

KV_BYTES_PER_TOKEN = 890          # 公式：V4.1-Flash 約 890 bytes/token
KV_V4_FLASH = 3514                # 公式：V4 Flash 約 3514 bytes/token

def estimate_kv(text: str, concurrency: int = 1):
    payload = {
        "model": "deepseek-flash",
        "messages": [{"role": "user", "content": text}],
        "max_tokens": 1,
    }
    r = requests.post(f"{BASE}/chat/completions",
                      headers=HEADERS, json=payload, timeout=60)
    r.raise_for_status()
    usage = r.json().get("usage", {})
    pt = usage.get("prompt_tokens", 0)
    kv_new = pt * KV_BYTES_PER_TOKEN / (1024 ** 2)
    kv_old = pt * KV_V4_FLASH / (1024 ** 2)
    return {
        "prompt_tokens": pt,
        "KV_MB_新": round(kv_new * concurrency, 2),
        "KV_MB_旧": round(kv_old * concurrency, 2),
        "压缩比": round(kv_old / kv_new, 2),  # 予想約 4.0
    }

if __name__ == "__main__":
    long_text = "部署测试。" * 2000
    print(estimate_kv(long_text, concurrency=32))

1M コンテキスト + 384K 出力：長シーケンス推論の KV 管理とチャンクスケジューリング戦略

公式には 1M tokens のコンテキスト と 最大 384K tokens の出力 が示されている。この 2 つの数字を組み合わせると、1 回のリクエストが約 1.38M tokens の KV ライフサイクルを担う可能性がある。890 bytes/token で見積もると、ピークは約 1.2 GB/シーケンスとなる。マルチシーケンス同時実行下では、KV の割り当て、再利用、回収がスケジューリングシステムの中核となる。

推奨されるチャンクスケジューリング戦略：

1. プレフィックスチャンクと共有：system prompt、ツール定義、長文ドキュメントを固定ブロックに分割してハッシュを計算し、同一プレフィックスは KV を直接再利用する。ヒットすれば Prefill 全体を節約できる。公式価格では「キャッシュヒット入力」がオフピーク 0.02 元 / ピーク 0.04 元であるのに対し、「キャッシュミス入力」はオフピーク 1 元 / ピーク 2 元で、ヒットとミスの差は 50 倍である。ローカルサービスでも同様に、プレフィックスキャッシュヒット率を第一級指標とすべきである。
2. スライディングウィンドウ + セグメント Checkpoint：超長入力に対して、ブロック単位で KV checkpoint を保存し、切り捨てやロールバック時に直近の checkpoint から復元して全量再計算を避ける。
3. 出力側のセグメントフロー制御：384K 出力を一度に生成することは不可能であり、セグメントごとに停止条件と再試行境界を設定し、単一リクエストが Decode リソースを長時間占有して他の同時実行に影響するのを防ぐ。
4. ホット/コールド階層化：アクティブセッションの KV は HBM に残し、低頻度セッションは SSD に降格（1/8 容量で計画）。プリフェッチで IO レイテンシを隠蔽する。

エンジニアリングの落とし穴：長コンテキストの Prefill は 8B 活性化であり、それ自体は高コストではないが、KV 書き込みとページテーブル保守はブロック数の増加に伴って線形に悪化する。最大ブロック数の上限と LRU 淘汰を必ず設定すること。そうしないとメモリ断片化が有効 VRAM を食い尽くす。もう 1 つの落とし穴は位置エンコーディングの外挿である。1M コンテキスト下で RoPE スケーリングを校正しないと、長距離アテンションが明らかに劣化する。展開構成で目標コンテキスト長を明示的に宣言し、一貫性チェックを行うことを推奨する。

思考強度 low/high/max の 3 段階：非思考モードと思考モードの推論予算配分

公式設定：思考モードがデフォルトで、強度は low / high / max の 3 段階。同時に非思考モードも保持される。この 3 段階は「スイッチ」ではなく推論予算の段階であり、CoT 長と Decode 回数に直接作用する。Decode はまさに 16B 活性化パスの高コスト部分であるため、段階の選択はレイテンシと品質の直接的なトレードオフに等しい。

選定の推奨：非思考モードはすべての「決定論的タスク」——JSON 抽出、意図分類、コード FIM 補完——に使用し、思考ティアは「非決定論的タスク」に残します。サービスオーケストレーションではリクエストごとに動的にルーティングすべきです。ゲートウェイ層で prompt の特徴（「証明/導出/多段」を含むか）または上流の意図分類器の出力に基づいてティアを決定し、max ティアには並行制限をかけます。公式の並行制限は 2500 で、max ティアは単一リクエストの占有時間が長いため、全体の SLA を損なわないよう、別途制限付きキューを用意することを推奨します。注意点として思考モードはデフォルトで有効です。クライアントが明示的に思考を無効化しない場合、短いタスクが不可解に遅くなります——これは接続側で最もよくある性能苦情の原因です。

ネイティブマルチモーダル視覚理解の接続：画像リンク、base64、Files API の3経路

V4.1-Flash はネイティブマルチモーダル視覚理解をサポートし、画像入力には3つの経路があります：画像リンク、base64、Files API。三者はローカルサービスにおける前処理とキャッシュ設計が大きく異なります。

• 画像リンク：サーバーが URL から取得します。利点はリクエストボディが小さく再利用しやすいこと；落とし穴は外部ネットワーク到達性と直リンク防止で、同一 URL の内容が変化する可能性があるため、URL をそのままキャッシュキーにできません。ETag やコンテンツハッシュと組み合わせるべきです。ローカルデプロイで外部ネットワークが制限されている場合、プロキシを自前で構築して取得・ディスク保存し、base64 に変換する必要があります。
• base64：自己完結型で外部依存がなく、イントラネットやオフライン環境に適しています；代償はリクエストボディが約 33% 膨張し、大量の重複画像が繰り返し転送されることです。ゲートウェイ層で画像コンテンツのハッシュによる重複排除を行い、ヒット時は参照 ID に置き換えるべきです。
• Files API：先にアップロードしてから参照する方式で、大きな画像やマルチターンでの再利用に最適です。エンジニアリング上は「アップロード時に登録」するリソーステーブルを実装し、ファイル ID、ハッシュ、TTL を記録し、セッション次元で参照カウントを行い、ファイルリークを防ぐべきです。

キャッシュ設計の要点：画像特徴（生バイトではなく）を再利用可能なオブジェクトとして扱い、同一画像で異なる質問には視覚エンコード結果を優先的にヒットさせます；同時にマルチモーダル入力の KV も 890 bytes/token の台帳に含まれるため、長画像＋長コンテキストの組み合わせは事前に予算を取る必要があります。視覚リクエストは非思考または思考 low ティアを推奨し、タスク自体が深い視覚推論を必要としない限り、max ティアは明らかな遅延の無駄を生みます。

JSON Output、Tool Calls、Responses API：構造化出力のエンジニアリング実装

V4.1-Flash は JSON Output、Tool Calls、Responses API、Anthropic API、および対話プレフィックス継続と FIM（非思考のみ）をサポートします。ローカルサービスオーケストレーションにとって、真の分水嶺は「誰が構造の正しさを保証するか」です。

1. JSON Output：抽出とデータパイプラインに適し、サーバー側で schema 検証と失敗時のリトライを行うべきで、未検証の JSON を直接 DB に書き込んではいけません。自由形式の記述ではなく厳格な schema（必須フィールド＋列挙制約）を使うことを推奨します。
2. Tool Calls：どのツールを呼ぶかはモデルが決定し、サーバーはツールホワイトリスト＋パラメータ schema 検証＋タイムアウト遮断の三点セットを必ず実装し、モデルがツール名やパラメータを捏造するのを防ぎます。多段ツールチェーンは最大ラウンド数を制限し、思考ティアと連動させることを推奨します（複雑なチェーンは high、単純なチェーンは low）。
3. Responses API：従来の chat よりも「1リクエスト1構造化レスポンス」のパラダイムに近く、多段オーケストレーションを単一呼び出しに収束させるのに適しています；ローカルゲートウェイにとってレスポンスオブジェクトの状態機械がより単純で、冪等性とリプレイの実装に有利です。
4. Anthropic API：既存の Anthropic エコシステムのクライアントに互換接続を提供し、ローカルサービスは両方のプロトコルを同時に公開でき、ゲートウェイでプロトコル正規化を行うことで業務側の改造成本を避けられます。

以下に JSON schema 検証とツールホワイトリストを備えた最小実装を示します：

import json
import requests

BASE = "https://api.deepseek.com"
KEY = "your-deepseek-api-key"
HEADERS = {"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"}

ALLOWED_TOOLS = {"get_weather", "search_docs"}
SCHEMA = {"name": str, "score": (int, float)}  # 期待する構造化フィールド

def call_json(prompt: str):
    payload = {
        "model": "deepseek-flash",
        "messages": [{"role": "user", "content": prompt}],
        "response_format": {"type": "json_object"},
        "max_tokens": 1024,
    }
    r = requests.post(f"{BASE}/chat/completions",
                      headers=HEADERS, json=payload, timeout=120)
    r.raise_for_status()
    text = r.json()["choices"][0]["message"]["content"]
    try:
        data = json.loads(text)
    except json.JSONDecodeError:
        return {"ok": False, "reason": "invalid_json"}
    for k, typ in SCHEMA.items():
        if k not in data or not isinstance(data[k], typ):
            return {"ok": False, "reason": f"bad_field:{k}"}
    return {"ok": True, "data": data}

def validate_tool_calls(msg):
    calls = msg.get("tool_calls") or []
    for c in calls:
        name = c.get("function", {}).get("name")
        if name not in ALLOWED_TOOLS:
            raise ValueError(f"tool not allowed: {name}")
    return calls

if __name__ == "__main__":
    print(call_json("name と score フィールドを含む JSON を出力"))

落とし穴：JSON Output と思考モードを重ねると、CoT が構造フィールドを汚染する可能性があるため、必ず公式の能力境界に従ってレスポンス形式を使用し、後検証を行ってください；Tool Calls のパラメータにネストしたオブジェクトが含まれる場合、トップレベルの型だけを見るのではなく層ごとに検証することを推奨します。

対話プレフィックス継続と FIM：非思考モードのみでのコード補完チェーン構築

公式に明確です：対話プレフィックス継続と FIM は非思考モードのみをサポートします（FIM は明確に「非思考のみ」と記載）。これはハード制約であり、コード補完チェーンは思考を明示的に無効化しなければならず、そうでなければリクエストが拒否されるか、期待と異なる動作になります。

ローカルコード補完チェーンの実装要点：

• モード固定：補完サービスのリクエスト構築層で非思考を強制し、上位層から思考パラメータを透過させないようにし、アーキテクチャ上で誤用を排除します。
• コンテキストのトリミング：補完リクエストは「全ファイル」ではなく「前後文のウィンドウ」が重要です。構文ブロック単位でトリミングし、カーソル前の数行とカーソル後の少数行を保持し、prompt 長を制御して遅延を抑えることを推奨します。
• FIM テンプレートの一貫性：FIM は固定の前後綴プレースホルダ規約に依存するため、クライアントとサーバーは同一のテンプレートを使用しなければならず、そうでなければ補完品質が崖のように低下します。
• プレフィックス継続による制約生成：対話プレフィックス継続は「与えられた冒頭を強制的に続ける」のに適し、固定形式のコードスニペットや設定項目の生成に使用できます。
• キャッシュ再利用：同一ファイルの履歴補完 KV はプレフィックスハッシュで再利用でき、キャッシュヒット後は入力コストをアイドル 0.02 元 / ピーク 0.04 元（100万 tokens あたり）の水準まで下げられ、IDE の高頻度トリガー場面では決定的なコスト最適化となります。

遅延予算については、補完体験では最初の token をできるだけ早く返す必要があるため、非思考 + 短い出力で、ストリーミング返却を併用しなければなりません。ここまでで、アーキテクチャ、VRAM、KV、長いシーケンス、思考ティア、マルチモーダル、構造化出力、補完パイプラインが整理されました。次の部分では、高並行サービスのオーケストレーション、並行数上限 2500 における待ち行列とレート制限の設計、価格設定とピーク/アイドル戦略のコスト計算（ピークは月曜から金曜の 9:00-12:00、14:00-18:00、アイドル価格はピークの半額。キャッシュヒット入力はアイドル 0.02 元 / ピーク 0.04 元、キャッシュミス入力はアイドル 1 元 / ピーク 2 元、出力はアイドル 4 元 / ピーク 8 元）、そして API からローカルデプロイへの移行パスと負荷試験方法に入ります。

前半では、DeepSeek-V4.1-Flash の 552B MoE と CED 非対称アーキテクチャ（入力側で 8B を活性化、出力側で 16B を活性化）、1M コンテキストと 384K 最大出力、そして KV Cache のサイズが V4 Flash の約 3514 bytes/token から約 890 bytes/token に削減されたという、ストレージと VRAM の主線を整理しました。続くこのセクションでは、視点をモデル自体からサービス側へ移します。モデル名と並行数、ルーティング切り替え、価格設定とオフピーク、ベンチマークの読み解き、重みのデプロイ、エコシステム連携、そして実際に本番運用して初めて踏む移行の落とし穴です。

import os
import asyncio
import httpx

API_KEY = os.environ.get("DEEPSEEK_API_KEY", "your-deepseek-api-key")
BASE_URL = "https://api.deepseek.com"
MODEL = "deepseek-flash"
MAX_CONCURRENCY = int(os.environ.get("DS_MAX_CONCURRENCY", "2200"))

sem = asyncio.Semaphore(MAX_CONCURRENCY)

async def call_flash(client, messages, thinking="high"):
    body = {
        "model": MODEL,
        "messages": messages,
        "max_tokens": 8192,
        "thinking": {"type": "enabled", "effort": thinking},
        "stream": False,
    }
    async with sem:
        for attempt in range(5):
            try:
                resp = await client.post(
                    f"{BASE_URL}/chat/completions",
                    headers={"Authorization": f"Bearer {API_KEY}"},
                    json=body,
                    timeout=httpx.Timeout(180.0, connect=10.0),
                )
                if resp.status_code == 429:
                    await asyncio.sleep(min(2 ** attempt, 30))
                    continue
                resp.raise_for_status()
                return resp.json()
            except (httpx.ConnectError, httpx.ReadTimeout):
                await asyncio.sleep(min(2 ** attempt, 30))
        raise RuntimeError("deepseek-flash exhausted retries")

async def main():
    limits = httpx.Limits(max_connections=MAX_CONCURRENCY,
                          max_keepalive_connections=MAX_CONCURRENCY // 2)
    async with httpx.AsyncClient(limits=limits, http2=True) as client:
        tasks = [
            call_flash(client, [{"role": "user", "content": f"审计片段 {i}"}])
            for i in range(50)
        ]
        results = await asyncio.gather(*tasks, return_exceptions=True)
        ok = sum(1 for r in results if isinstance(r, dict))
        print(f"ok={ok} failed={len(results) - ok}")

if __name__ == "__main__":
    asyncio.run(main())

{
  "model": "deepseek-flash",
  "base_url": "https://api.deepseek.com",
  "auth": {
    "header": "Authorization",
    "value": "Bearer your-deepseek-api-key"
  },
  "probe_cases": [
    {
      "name": "json_output",
      "request": {
        "model": "deepseek-flash",
        "response_format": { "type": "json_object" },
        "thinking": { "type": "enabled", "effort": "low" },
        "messages": [
          { "role": "user", "content": "JSON を返してください: フィールド ok は true、フィールド tier は flash" }
        ],
        "max_tokens": 128
      },
      "assert": { "json_field": "ok", "equals": true }
    },
    {
      "name": "tool_calls",
      "request": {
        "model": "deepseek-flash",
        "thinking": { "type": "enabled", "effort": "high" },
        "tools": [
          {
            "type": "function",
            "function": {
              "name": "get_storage",
              "description": "SSD キャッシュプールの残り容量を照会する",
              "parameters": {
                "type": "object",
                "properties": { "pool": { "type": "string" } },
                "required": ["pool"]
              }
            }
          }
        ],
        "messages": [
          { "role": "user", "content": "pool=kv-ssd の残り容量を確認してください" }
        ],
        "max_tokens": 256
      },
      "assert": { "has_tool_call": "get_storage" }
    },
    {
      "name": "fim_non_thinking",
      "request": {
        "model": "deepseek-flash",
        "thinking": { "type": "disabled" },
        "fim": { "prompt": "def fib(n):\n    if n < 2:\n        return n\n    ", "suffix": "\n\nprint(fib(10))" },
        "max_tokens": 64
      },
      "assert": { "non_empty_text": true }
    }
  ]
}