deepseek.ac日本語で学ぶ、実践する

モデル

DeepInfer が全面オープンソース化 — API 利用者に影響するのか、セルフホスト派は何を見るべきか

· 約9分

リード

2026年10月20日、DeepSeek が内部推論フレームワーク DeepInfer と、トークン編解码组件 deepseek-recipe を全面オープンソース化した。 結論から書くと、api.deepseek.com を叩いているアプリに即時の変更は不要。影響が出るのは「モデルを自前でホストして serving する」側なので、その判断に必要な観点だけ整理する。

前提

本記事は 2026-10-20 時点の公開情報に基づく。機能名・数値は DeepSeek の公式投稿および報道によるもので、リポジトリの実装詳細・ライセンス・対応バージョンは github.com/deepseek-ai/DeepInfer で要確認。

本文

何が公開されたか

発表の骨子は2つ。

対象 内容
DeepInfer 高性能カーネルと最適化済み推論エンジンを統合した推論フレームワーク。分散推論、投機的デコード、SWA Bounded Replay、構造化出力に対応。NVIDIA と昇騰の両プラットフォームをサポート
deepseek-recipe 本番運用中のトークン encode / decode コンポーネント。処理ロジックが公式 API と整合するよう作られている

DeepSeek はこれ以前にモデル群、TileLang コンパイラ、推論オペレータライブラリを順に公開しており、今回はその上に乗る「serving 層」を出した格好になる。V4.1 Flash の大規模推論はこの基盤上で動いており、今後の新モデルの推論コードもここで更新されるという。

まず結論: API 利用者が今日やることはない

DeepInfer は「モデルをどう安く速く捌くか」を担うミドルウェアであって、API のインターフェースを変えるものではない。エンドポイント、リクエスト形式、モデル名、料金はこの発表では変わっていない。

中長期では、serving コストの低下が API 価格やレイテンシに反映される可能性はある。ただしそれは別途アナウンスされる話なので、ここで推測で書かない。「今回の発表＝即時マイグレーション不要」 が実務的な結論。

推論フレームワークは何をしているのか

訓練がモデルの能力上限を決めるのに対し、推論はその能力を実際に届ける工程。サーバ側では、届いたリクエストの順序制御、KV キャッシュの管理、複数 GPU への割り振りを同時に処理している。

同じモデル・同じ GPU 枚数でも、この層の出来でスループットとレイテンシは変わる。だから「モデルだけ取ってきて動かす」と、ベンダの本番構成より高いコストになることが普通にある。DeepInfer の公開は、その差分を埋めるための材料という位置づけ。

公表機能と、自前運用での意味

機能 発表での説明 自前運用での実務的な意味
高性能カーネル / 最適化エンジン 推論エンジンに統合 カーネル実装を自前で書かずに済む。まずはここが動くだけで価値がある
分散推論 複数デバイスで協調 単機に載らないサイズを扱える。並列方式の詳細は未確認
投機的デコード 候補トークンを先に生成して検証 レイテンシ改善が期待できるが、受理率が低いと逆効果。メモリ消費も増える
SWA Bounded Replay 直近の限られた長さを再生し、一部の状態復元コストを削減 長文・マルチターンで効く可能性。適用条件は要確認なので自ワークロードで計測
構造化出力 スキーマ準拠の出力 サーバ側で強制できるため、クライアント側のパース失敗を減らせる
NVIDIA / 昇騰 対応 両プラットフォーム 調達制約がある環境でも選択肢が持てる

投機的デコードと SWA Bounded Replay は、有効化すれば必ず速くなる類のものではない。バッチサイズ、プロンプト長分布、下書きモデルの相性で結果が反転する。導入時は必ず自分のトラフィックで A/B を取る前提で見たほうがいい。

報道されている数字の読み方

一部報道では「単一クラスタで1日155兆トークン」「1カード時間あたり38ドル（谷価格ベース）」といった数字が挙がっている。これは DeepSeek 自身の本番クラスタでの自己申告値であり、自環境の見積もりに直接は使えない。

理由は単純で、コストを決める要素が違うから。

社内稟議に転記するなら、報道値ではなく自前ベンチの数値に置き換える。この種の数字は「上限の目安」として扱うのが安全。

deepseek-recipe の使いどころ

こちらのほうが API 利用者にも関係が深い。トークナイザの挙動が公式 API と揃うため、「API で数えたトークン数」と「自前推論で数えたトークン数」のズレを潰せる。コスト見積もり、コンテキスト長ギリギリの設計、トークン境界に依存するチャンク分割で効いてくる。

まずは突き合わせテストを1本作っておくと、以降の判断がぶれない。

# 骨格のみ。import 周りはリポジトリの README に合わせて差し替える
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)
MODEL = os.environ["DEEPSEEK_MODEL"]  # モデル名は公式ドキュメントで要確認

def api_token_count(text: str) -> int:
    res = client.chat.completions.create(
        model=MODEL,
        messages=[{"role": "user", "content": text}],
        max_tokens=1,
    )
    return res.usage.prompt_tokens

def local_token_count(text: str) -> int:
    # recipe のエンコーダを使う。関数名・モジュール名は README で確認
    ...

def check(text: str) -> None:
    api_n = api_token_count(text)
    local_n = local_token_count(text)
    print(f"api={api_n} local={local_n} diff={api_n - local_n}")

注意点: チャット API の usage.prompt_tokens にはチャットテンプレートや特殊トークンの分が上乗せされる。したがって「絶対値が一致するか」ではなく、複数サンプルでの差分が一定かを見る。差分が固定ならオフセットとして扱える。

セルフホストに踏み込むべきか

判断は要件で分かれる。

自前ホストが効くケース

API 継続が妥当なケース

TCO は「GPU 時間 × 稼働率 + 電力 + 人件費」で見る。API 価格との単純比較は、たいてい自前側を安く見積もりすぎる。

つまずきポイント

症状 対処
リポジトリのビルドが通らない 公開直後は手順が動きやすい。参照した commit を固定し、Issue を確認する
recipe のトークン数が API と一致しない チャットテンプレート分のオフセット。絶対値ではなく差分の安定性で評価する
投機的デコードを有効にして遅くなった 受理率が低いと逆効果。下書きモデルとタスクの相性、バッチサイズを確認する
報道値をそのまま試算に使った 自ワークロードでベンチを取り直す。入力出力比とプロンプト長分布を揃える

まとめ

チェックリスト