ホーム
AI・テック動向
DeepSeek-V4-Flash-0731 は実費20分の1、それでも要約モデルは据え置いた — 5回ずつ測った結果

2026.08.7 最終更新 2026.08.11

DeepSeek-V4-Flash-0731 は実費20分の1、それでも要約モデルは据え置いた — 5回ずつ測った結果

同じプロンプトを5回ずつ投げて実費を比べたら、DeepSeek-V4-Flash-0731 は Claude Sonnet 5 の20分の1から25分の1だった。それでも週次ジョブの要約モデルは Sonnet 5 に据え置くことにした。決め手になったのは、1回の応答が21.95秒から261.14秒まで振れたことだ。

7月31日に何が更新されたか
呼び名が同じまま中身が入れ替わる
単価の差はどこに効くか
筆者の要約処理だと混合比はどのあたりか
入力を固定してから差し替える
測った結果
日本語の要約品質は点数が付けにくい
先に置いたしきい値に当てはめる
1. 金額より先に、時間のほうで引っかかった
2. 結論
切り戻しの経路は3つに分かれる
効いてくるのは要約より先かもしれない
参考

7月31日に何が更新されたか

DeepSeek が deepseek-v4-flash を DeepSeek-V4-Flash-0731 へ更新した。要点は次のようになっている。

アーキテクチャとサイズは DeepSeek-V4-Flash-Preview から据え置きで、再度の post-training だけを行ったと説明されている
強化されたのはエージェント・コーディング・ツール呼び出し。公式はエージェント系のベンチマーク（Terminal Bench・DSBench-FullStack）のスコアを挙げている
Responses API 形式に対応し、Codex 系のエージェントに合わせた調整が入った
価格は入力 $0.14 / 出力 $0.28 per 1M トークンで据え置き
モデル名の呼び出し方は変わらない

収集時の要約には「284B の MoE・コンテキスト100万トークン」という規模も付いていた。DeepSeek 公式のニュースにも更新履歴にも規模の記載は無い。OpenRouter のモデルページが「13B active / 284B total の疎な MoE」としているので、規模はそちらを出典として扱う。コンテキストも同じく OpenRouter のモデル定義値（1,048,576 トークン）を使う。

呼び名が同じまま中身が入れ替わる

引っかかったのは最後の1行だ。モデル ID を固定して使っている側からは、中身が入れ替わったことが見えない。要約の出力が少し変わっても、いつ変わったのかを後から特定できなくなる。

この問題には手当てがある。OpenRouter の公開モデル一覧（https://openrouter.ai/api/v1/models）に出ている ID は deepseek/deepseek-v4-flash-0731 と ~deepseek/deepseek-v4-flash-latest の2つだ。~ で始まるほうはエイリアス側の表記で、ブラウザで見るモデルページには出てこない。日付が入っているほうを選べば、少なくとも自分の実行がどの版だったかは残る。-latest のほうは同じ問題を持ち込む。無人ジョブに入れるなら日付ピン留めのほうだ。

差し替えを検討する前にもう1つやることがある。同じ入力に対する現行モデルの出力を保存しておくことだ。比較の基準が手元に無いと、替えたあとで「前より悪くなった気がする」以上のことが言えない。

単価の差はどこに効くか

筆者の週次ジョブが使っている Claude Sonnet 5 と並べる。Sonnet 5 側は導入価格の値で、こちらは8月31日に終了して $3 / $15 になると告知されている。

1Mトークンあたりの単価。OpenRouter の行は 2026-08-03 時点の表示
モデル / 経路	入力	出力
DeepSeek-V4-Flash-0731（DeepSeek 公式）今回	$0.14	$0.28
同・OpenRouter の表示	$0.09	$0.18
Claude Sonnet 5（導入価格・8/31まで）	$2.00	$10.00

表の入力はキャッシュミス時の単価だ。DeepSeek 公式はキャッシュヒット時の $0.0028/1M を別に出している。筆者の用途は毎週プロンプトの中身が入れ替わるのでキャッシュは効かない前提で見るが、同じプロンプトを繰り返し投げる用途なら、ここの読み方が変わる。

公式の価格表と経由先の表示が一致しないことは珍しくない。Kimi K3 の実費を調べたときも、公式の価格表と OpenRouter の表示が揃っていなくて、比較するなら出典を統一する必要があった（Kimi K3 の実費を見た記事）。実費に効くのは自分が通す経路の単価なので、差し替えの直前にモデルページで見直す。プロバイダと時期で動く値だ。

公式単価どうしで割ると、入力側が約1/14、出力側が約1/36になる。ここで出力側の倍率だけを見ると、削減幅を大きく見積もることになる。実際の請求は入力と出力の混合で決まり、必ず1/14と1/36の間に落ちる。

筆者の要約処理だと混合比はどのあたりか

この用途のトークン構成は、スクリプトの定数から見当がつく。要約に渡すのは上位30ポスト（POSTS_FOR_LLM）で、1ポストあたり180字で切る（POST_CHARS）。返させるのは5項目（ITEMS_PER_CATEGORY）で、項目あたりの字数上限はプロンプトに書いてある。

入力の字数には、本文の前に付く接頭辞も入れておく。スクリプトは1件ごとに「いいね数・RT数・アカウント名」を頭に付けてから本文を並べるので、1件あたり30字ほどが上乗せされる。

入力 ≒ 30件 ×（180字 + 接頭辞 約30字）+ 指示文 約300字 ≒ 6,600字
出力 ≒ 5件 × 160字 + JSON の記号 ≒ 900字

[A] 公式単価どうし（$2/$10 対 $0.14/$0.28）
Sonnet 5   入力 6,600/1e6 × $2.00  = $0.0132
           出力   900/1e6 × $10.00 = $0.0090   合計 $0.0222
V4-Flash   入力 6,600/1e6 × $0.14  = $0.000924
           出力   900/1e6 × $0.28  = $0.000252  合計 $0.001176
比 = 0.0222 ÷ 0.001176 ≒ 19

[B] 筆者が実際に通す OpenRouter 経由（$2/$10 対 $0.09/$0.18）
V4-Flash   入力 6,600/1e6 × $0.09  = $0.000594
           出力   900/1e6 × $0.18  = $0.000162  合計 $0.000756
比 = 0.0222 ÷ 0.000756 ≒ 29

日本語1字をおよそ1トークンと置いた概算で、実測ではない。トークナイザによってずれるし、Sonnet 5 は同じ文章でおよそ30%多いトークンになる新しいトークナイザを使っているという記述も公式に出ている。それでも構成は分かる。出力は全体の文字数の1割強でしかないのに、Sonnet 側では単価が5倍なので請求の4割ほどを占める。混合比が二桁で止まるのはそのためだ。

[A] と [B] を分けたのは、単価の出どころが違うからだ。公式単価どうしなら約1/19、実際に通す OpenRouter 経由なら約1/29になる。実費に効くのは後者で、記事の見当として使うのもこちらにする。OpenRouter 経由は出力側だけなら1/56まで開くが、その数字を期待して差し替えると届かない。実費を測る前に、この程度の見当は付けておく。

この見当は、後で測った中央値どうしの25倍とそこそこ近い場所に落ちた。ただし当たったのは偶然に近い。字数からトークンを読む部分も、出力量を900字ぶんと置いた部分も、実測とは外れていた。どこがどう外れたかは実測の節で並べる。

入力を固定してから差し替える

筆者の週次ネタ帳収集は、収集と要約を分けてある。検索 API からポストを集めるのが前半、集めたものを LLM に投げて要約させるのが後半だ。要約に使うモデルは環境変数 OPENROUTER_TEXT_MODEL で決まり、既定値が anthropic/claude-sonnet-5 になっている。コマンドライン引数の --model があればそちらが優先される。

手で1回試すだけなら、引数を足すだけで通る。

python scripts/collect_neta.py --model deepseek/deepseek-v4-flash-0731 --only claude --force

--force が要る。その週のノートが既にあると、スクリプトは「既に存在」と1行出して何もせずに終わる。週次バッチが月曜に作っているので、後から手で回すときはほぼ必ずこの分岐に入る。--only と併用すれば他カテゴリの既存セクションは保たれる。

比較のためにこのコマンドを何回も回すのは筋が悪い。実行のたびに検索をやり直すので、入力のポストが毎回変わってしまう。出力の差がモデルの差なのか素材の差なのか分けられなくなるし、検索 API にもそのぶん課金される。収集を1回だけ回して、同じプロンプトを両モデルへ投げる形にする。

ここで最初の当てが外れた。実費は OpenRouter のアクティビティ画面で見るつもりでいたのに、API から取ろうとすると /api/v1/activity は管理用のキーでないと通らない。手元の推論キーで叩くと Only management keys can fetch activity for an account という403が返る。

逃げ道はリクエスト本体にあった。"usage": {"include": true} を付けて投げると、応答にそのリクエストのコストとトークン数が入って返ってくる。画面を見に行かなくても、1回ごとの実費がその場で手に入る。

そうすると既存の openrouter_chat() は使えない。あの関数は応答から本文だけを抜いて返す作りで、usage もリクエストの id も捨ててしまう。後からアクティビティ画面で該当リクエストを探そうにも、id が手元に無い。測定用には自前で POST を書いた。

import json, sys, time, urllib.request
sys.path.insert(0, "scripts")
import collect_neta as n
import collect_x_articles as sd

def or_call(key, model, prompt):
    """usage 込みで叩く。openrouter_chat() は usage と id を捨てるので測定には使えない"""
    body = json.dumps({
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "usage": {"include": True},
    }).encode("utf-8")
    req = urllib.request.Request(n.OR_URL, data=body, method="POST", headers={
        "Authorization": f"Bearer {key}", "Content-Type": "application/json", **n.OR_HEADERS})
    with urllib.request.urlopen(req, timeout=120) as r:
        res = json.loads(r.read().decode("utf-8"))
    return (res["choices"][0]["message"]["content"], res.get("usage"), res.get("id"))

cat = [c for c in n.load_categories() if c["key"] == "claude"][0]
since, until = n.since_until(7)
posts, returned = n.collect_posts(
    sd.load_api_key(), n.build_search_query(cat["x_query"], since, until))

# 測定に使った入力を残す。これが無いと後から検算できない
with open("scratchpad/neta_input.json", "w", encoding="utf-8") as f:
    json.dump(posts, f, ensure_ascii=False, indent=2)

prompt = n.build_analysis_prompt(cat["theme"], posts)
key = sd.load_api_key("OPENROUTER_API_KEY", n.OPENROUTER_HINT)
run_id = time.strftime("%Y%m%d-%H%M%S")   # 実験ごとに分ける（追記で前回と混ざらないように）
with open(f"scratchpad/neta_runs_{run_id}.jsonl", "w", encoding="utf-8") as out:
    for model in ("anthropic/claude-sonnet-5", "deepseek/deepseek-v4-flash-0731"):
        for i in range(5):
            t = time.perf_counter()
            text, usage, rid = or_call(key, model, prompt)
            elapsed = time.perf_counter() - t
            out.write(json.dumps(
                {"model": model, "i": i, "elapsed": elapsed,
                 "usage": usage, "id": rid, "text": text},
                ensure_ascii=False) + "\n")
            print(model, i, round(elapsed, 2), usage.get("cost"))

収集スクリプトは標準ライブラリだけで動かしているので、この形でも新しい依存は要らない。要約フェーズだけを回すことになるため、所要時間も収集を含まない値で取れる。応答は JSONL に残す。ターミナルへ流すだけだと、10回ぶんの出力を後から拾い直すことになって、項目の脱落や長さの安定を検算できない。

測った結果

2026年8月4日に実行した。収集は1回だけ回して30ポスト（API 返却40件）を取り、そこから組んだ5,729字のプロンプトを両モデルへ5回ずつ投げている。入力は10回とも同一だ。

同一プロンプトを5回ずつ投げた実測（2026-08-04・OpenRouter 経由・入力は30ポスト/5,729字で固定）
項目	Sonnet 5	V4-Flash-0731
1回あたりの実費（中央値）キャッシュ割引を外した値	$0.02137 最小 $0.02085 / 最大 $0.02595	$0.000867〜$0.001042 最大はどちらも $0.004877
同・請求どおりの値下記のとおり比較には使えない	$0.02137（同じ）	$0.000628 最小 $0.000376 / 最大 $0.004877
キャッシュ済みの入力トークン	5回とも 0	0 / 64 / 3,328 / 3,328 / 3,328
項目の脱落	入力にあった版番号・価格は要約に残らない	同じ（差は出なかった）
出力の形式崩れ	5/5 で JSON を取得	5/5 で JSON を取得
要約フェーズの実時間（中央値）	19.20秒最小 18.27 / 最大 25.82	63.72秒最小 21.95 / 最大 261.14
入力トークン	4,870（5回とも同じ）	3,502（初回のみ 3,581）
出力トークン（中央値）	1,163 最小 1,111 / 最大 1,621	3,067 最小 1,669 / 最大 15,628
出力の文字数（中央値）	822字	1,064字

実費の比は、中央値どうしなら20.5倍から24.6倍、平均どうしなら12.8倍から13.8倍になる。倍率が1つに定まらないこと自体が、この比較でいちばん学べた部分だった。

5回投げる設計が、安いほうに下駄を履かせていた

表に2種類の実費が並んでいるのは、最初の集計が間違っていたからだ。請求どおりの数字をそのまま使うと、中央値の比は34.0倍になる。この記事は当初その34倍を結論に載せていた。

応答の prompt_tokens_details を見て気づいた。V4-Flash の3回目以降は、入力3,502トークンのうち3,328トークンが cached_tokens として記録されている。同じプロンプトを繰り返し投げたので、プロンプトキャッシュが効いていた。

実測では未キャッシュ分が $0.09 / 1M、キャッシュ分が $0.018 / 1M で課金されていた。入力の95%が5分の1の単価になる。Sonnet 5 のほうは5回とも cached_tokens: 0 だった。

ここが噛み合っていない。この記事の前半で、毎週プロンプトの中身が入れ替わるからキャッシュは効かない、と筆者が書いている。その前提で見積もるのに、キャッシュが効いた測定値を使っていた。安いほうにだけ下駄を履かせた比較になる。

入力を固定するのは、モデル以外の条件を揃えるための設計だった。その設計自体が、キャッシュを持つモデルを有利にする。揃えたつもりの条件が片側だけに効く、という形の失敗だ。

引き直し方は難しくない。出力側はキャッシュの影響を受けないので実測のまま使い、入力側だけ全トークンを未キャッシュ単価で払ったことにして足し直す。それが表の1行目で、比は24.6倍まで落ちる。

引き直すのはキャッシュが効いた回だけにする。ここも一度間違えた。5回とも同じ単価で計算し直したら、キャッシュが1トークンも効いていない初回まで書き換えてしまい、実費が $0.004877 から $0.004698 へ下がった。キャッシュが0の回は、請求額がそのまま未キャッシュの実費になる。触ってはいけない。

単価が1つに決まらなかった

初回の入力単価を請求から割り出すと $0.14 / 1M。2回目は $0.09 / 1M だった。同じモデル ID を同じ夜に叩いているのに、単価が違う。OpenRouter は実行ごとに別のプロバイダへ流すので、キャッシュとは無関係に単価が動く。

ここで手が止まった。3回目以降のキャッシュが効いた回は、どちらの経路に載ったのか。$0.09 の経路なら比は24.6倍、$0.14 の経路なら20.5倍になる。

決められなかった。応答には provider というフィールドがあるのに、測定スクリプトで拾っていなかった。手元の記録には残っていない。

キャッシュが効いた回は、請求額の中で未キャッシュ分とキャッシュ分の単価が1本に畳まれている。1回ぶんのデータからその2つは分離できない。初回のようにキャッシュが0の回だけが、単価をそのまま読める。

片方を選んで1つの数字にすることもできた。選ばずに20.5倍から24.6倍という幅で書くことにした。選んだ根拠が無いのに数字を1つに丸めると、読者はその精度を信じてしまう。

測定スクリプトには provider の記録を足した。次に測るときは幅が消える。

同じ入力を繰り返してモデルを比べるときは、応答の cached_tokens を必ず見る。片方だけキャッシュが効いていたら、その比較は成立していない。

字数からトークンを読む見当は外れた

測る前は日本語1字をおよそ1トークンと置いて、入力6,600字ぶんを見込んでいた。実際のプロンプトは5,729字で、Sonnet 5 が数えると4,870トークン、V4-Flash が数えると3,502トークンだった。同じ文字列で1.39倍の開きがある。

リリースノートにも「Sonnet 5 は同じ文章でおよそ30%多いトークンになる」という記述がある。あちらが比べているのは Claude の旧モデルとの差で、今回の1.39倍は別の相手との比較になる。数字の近さは偶然として、トークナイザが違えば同じ文字列でも請求が動く、という話は同じだ。

出力側の外し方はもっと大きい。900字ぶんと見込んだところに、Sonnet 5 は822字の返答で1,163トークンを使い、V4-Flash は1,064字の返答に3,067トークンを使った。

極端だったのは V4-Flash の初回で、画面に返ってきた文章は903字なのに、出力トークンは15,628と記録されている。推論に使ったぶんが出力トークンとして数えられるためで、この回は課金の大半が目に見えない部分に消えた。

ばらつきの出どころは推論トークン

Sonnet 5 は5回とも似た値に収まった。実費は $0.02085 から $0.02595 で最重回が最軽回の1.24倍、所要時間は18.27秒から25.82秒で1.41倍。無人ジョブに置く分には読みやすい相手だ。

V4-Flash は同じ入力で12倍振れた。21.95秒で返る回もあれば、261.14秒かかる回もある。実費も最小 $0.000616 に対して最大 $0.004877 で、8倍近く動く。中央値と平均で倍率が24.6倍と13.8倍に割れたのは、この長い尻尾が平均だけを引っ張るからだ。

1回だけ測って「25倍安い」と書いていたら、当たりの回を引いたか外れの回を引いたかで結論が変わっていた。5回まわす設計にしておいてよかった箇所になる。

日本語の要約品質は点数が付けにくい

コストは数字で出る。品質のほうは自動で採点する手段が見当たらないので、10回ぶんの出力を筆者が読んで判定した。

いちばん心配していたのは固有名詞と数字の脱落だった。入力の30ポストに含まれていた版番号は2種、価格の表記は1種。要約に残っていたのはどちらのモデルでも0だ。

脱落の出どころはこちらのプロンプトの設計にある。「個々のポストの要約ではなく、複数のポストにまたがる『話題』の単位でまとめること」と書いてあるので、個別の版番号は落ちて当然だった。判定の観点として置いたのに、2つのモデルを区別しない観点だったことになる。

次に見た推測の混入は、両モデルとも0件だった。出力に現れた固有名詞と概念（OpenAI・3D ワールド・AIバブル・財務DD・投資家・回収・寿命）を入力の本文へ全文検索すると、すべて元のポストに存在する。「一覧に無い事実を足さないこと」という指示は、安いほうでも守られていた。

整理された5件の話題も、ほぼ重なった。元アイドルが Claude Code で配信システムを自作した件、コードを書かない開発の広がり、Skill やフォルダ構成のノウハウ共有、Opus 5 と Fable 5 の使い分け、DeepSeek の低価格に対するバブル懸念。順番まで一致している。

差が出たのは長さの安定だった。Sonnet 5 は753字から841字の幅88字に収まり、V4-Flash は903字から1,278字で幅375字。要約を後段の処理へ渡す立場では、この幅の狭さに値段が付く。

読み比べた印象では、V4-Flash のほうが1件あたりの説明は詳しい。「元アイドルがClaude Codeで自作」の項に「コードを読まない開発法も注目」まで足してくるあたりは、こちらのほうが記事の種として使いやすかった。

先に置いたしきい値に当てはめる

測る前に、切り替えの基準を書いてから走らせた。順に当てはめていく。

5回のうち日付・価格・バージョン番号の脱落が1回でも出たら、要約用途では採用しない。読み直しのコストが単価差を食い潰す
脱落が無く、5回とも JSON が取り出せたなら、要約フェーズだけ差し替えて2週間並走させる
実費の差が月あたり数十円の規模で収まるなら、そもそも切り替えない。手を入れた分だけ壊れる余地が増える
不採用の判定になった場合は、DeepSeek 公式 API（api.deepseek.com）で1回だけ測り直してから結論を書く
ツール呼び出しを含む処理では別に測り直す。要約の結果をそのまま持ち込まない

1つ目は判定に使えなかった。脱落は両モデルで同じだけ起きていて、この基準をそのまま適用すると現行の Sonnet 5 も不採用になる。基準を書いた時点で、筆者のプロンプトが話題の単位でまとめる指示になっていることを勘定に入れていなかった。

2つ目は通った。JSON は10回とも取り出せている。

3つ目で止まった。週5カテゴリなので月におよそ21.7回。中央値で置くと Sonnet 5 が月 $0.463、V4-Flash が月 $0.019 から $0.023。差は月 $0.44 になる。為替を1ドル150円と置けば約66円だ。

筆者が書いた「月あたり数十円の規模で収まるなら切り替えない」に、正面から当たった。20倍という倍率は目を引くが、元の額が小さいので浮くのは月に66円になる。

ここまでの数字の直しは、どれもこの判定を動かさなかった。キャッシュを含んだ最初の集計でも差は月 $0.449、経路の幅を取っても $0.440 から $0.444。1ドル150円なら1円ほどの開きしかない。倍率が34倍か20倍かで結論が変わる領域には、そもそも入っていなかった。

金額より先に、時間のほうで引っかかった

止める理由がもう1つ出てきた。週次ネタ帳の収集は5カテゴリを順に回して、実行全体に12分の上限を置いてある（DEADLINE_MIN）。

中央値で計算すると、Sonnet 5 は5カテゴリで1.6分、V4-Flash は5.3分。ここまでは両方とも収まる。最悪値で計算すると景色が変わる。Sonnet 5 は2.2分のままだが、V4-Flash は21.8分で上限を10分近く超える。

261秒かかった回には、もう1つ気になる点がある。この呼び出しには timeout=120 を指定していたのに、例外は上がらなかった。urllib のタイムアウトは1回のソケット操作にかかる待ち時間で、応答が細切れに届き続けるかぎり全体の時間を縛れない。

本番の openrouter_chat() は timeout=90 で動いている。90秒で打ち切ってくれる、と読んでいた箇所が読み違いだった。上限を守っているのは --deadline-min 側だけになる。

推論トークンを出すモデルを無人ジョブへ入れるなら、単価表より先にこの尻尾の長さを見る。上限に当たって途中で落ちた週は、翌朝ログを見るまで気づけない。

結論

週次ジョブの要約モデルは Claude Sonnet 5 に据え置く。浮く額が月66円で、引き換えに所要時間の上限リスクを持ち込むことになるからだ。

4つ目の歯止めに従って、不採用の理由も書き分けておく。今回測ったのは OpenRouter 経由の deepseek/deepseek-v4-flash-0731 であって、DeepSeek 公式 API を直接叩いた場合と同じ条件とは限らない。量子化や既定パラメータの扱いが揃っている保証は無い。不採用の判定はこの経路とこの用途に対するもので、モデルそのものの評価ではない。品質の面では、むしろ現行と互角の出力が返ってきていた。

切り戻しの経路は3つに分かれる

試す経路と本番を替える経路は別なので、分けて書いておく。手で試すのは --model。無人ジョブに入れるときは .env の OPENROUTER_TEXT_MODEL を1行足す。無人実行のラッパーは引数なしでスクリプトを叩くので、引数側を書き換えても本番は変わらない。戻すのは .env のその行を消すだけだ。

ログの整備はどうかと筆者のスクリプトを見に行ったら、既に入っていた。起動時に要約モデル名を出していて、生成したノートの frontmatter にも日付とモデル ID が残る。

f"source: SocialData API (X/Twitter) + OpenRouter ({model})\n"

同じモデル ID のまま中身が更新される今回のようなケースでは、日付とモデル名の両方が要る。出力が変になったとき、どのモデルでいつ走ったのかが記録に無いと切り分けができない。無ければ足す、あれば確かめる。取り返しがつくと分かっている変更は試しやすい。

効いてくるのは要約より先かもしれない

今回の更新で強化されたのはエージェント・コーディング・ツール呼び出しだと公式にある。要約は、その強化がいちばん効きにくい用途だと筆者は見ていた。原文を読んで短くまとめる処理に、ツール呼び出しの改善はほとんど関係しないはずだ。

実測はこの見立てを否定しなかった。品質は互角で、差が出たのは値段と時間のばらつきだけになる。要約という土俵では、強化された部分が働く場面が来ない。

ツールを何度も呼ぶ処理を安いモデルへ寄せられるなら、削減の幅は要約より大きくなる。呼び出し回数のぶんだけトークンが積み上がるからだ。筆者の環境だと収集フェーズの後処理や、リンク切れの確認あたりが候補になる。

ただし、そこでも同じ尻尾が付いてくる。1回の呼び出しで12倍振れるモデルを、何度も呼ぶ処理に置いたらどうなるか。次に測るのはそこになる。

安いモデルの使いどころは、単価表を眺めていても出てこない。

参考

実測は 2026-08-04 に OpenRouter 経由で実行した。入力は同一プロンプト（30ポスト・5,729字）を固定し、各モデル5回ずつ。トークン数と実時間は応答の usage と呼び出し前後の経過時間をそのまま採っている。実費だけは引き直した値で、キャッシュが効いた回についてのみ、入力トークンを全数未キャッシュ単価で払ったものとして計算し直した（キャッシュが0の回は請求額のまま。請求どおりの値も表に併記した）。未キャッシュ単価は請求から割り出した $0.09 / 1M と $0.14 / 1M の2つが観測され、どちらの経路だったか特定できないため範囲で示している。出力側は実測のまま。品質の3項目は10回ぶんの出力を通読して判定した。月額は中央値に月21.7回を掛けた計算値で、円換算は1ドル150円と置いた仮定を含む。DeepSeek 公式 API を直接叩いた場合は未測定。混合比の試算（約1/19・約1/29）は測定前にスクリプトの定数から引いた計算値で、実測ではない。価格・スペック・モデル ID は上記の一次ソースで原文と突き合わせた。測定と集計のスクリプト、10回ぶんの応答は手元に保存してある。