🎲 拡散LLMのDiffusionGemmaでJev互換の型付き判断APIを自己ホストするdjevの構造と使い方

DiffusionGemma-as-Jev（以下 djev）は、Google DeepMind の拡散 LLM「DiffusionGemma」を、TypeSafe AI の決定モデル Jev と同じ HTTP 契約で動かすオープンソースのスタックです。
この記事では、djev の仕組み・データ形・構築手順・運用値を、実装者が手元で再現できる粒度で整理します。
数値と仕様は 2026-09-19 時点の公開資料に基づきます。

この記事の全体像。以下、順に解説します。

DiffusionGemma-as-Jev とは

djev は、DiffusionGemma（26B A4B の離散拡散 LLM）を、Jev と同じ POST /v1/systemone 契約で動かす実装です。
ソフトウェアが分岐に使える型付き決定（noul / choice / score）を、オープン重みの 1-step canvas 読み取りで返します。

主要な公開物は次の 3 つです。

• エンジン変更: Matt Mastracci による vLLM PR #57250（2026-09-19 時点で Open）
• DGX Spark / GB10 向けの容器化レシピ: djev-spark
• コミュニティによる別実装: OpenJev

全体は 4 つの層で構成されます。

TypeSafe Jev は、RLCD（Reinforcement Learning for Calibrated Decisions）で訓練された商用の System One モデルです。
djev は同じ HTTP 形を、既存の DiffusionGemma 重みの canvas 読み取りで実装します。
実行時に TypeSafe の API は呼びません。

vLLM の native dLLM serving（2026-06-10 ブログ）は、DiffusionGemma を通常のテキスト生成としてバッチ実行する経路です。
djev はその上に、canvas をテンプレートで固定して 1 回だけ読む経路を足します。

自己回帰 LLM と拡散 LLM の生成単位の違い（出典: Diffusion in Text Generation Explained）

公式の生成ループと djev が使う部分

DiffusionGemma の本来の用途は文章生成です。
explained と model card の用語で、生成ループは次の 3 点から成ります。

1. Uniform State Diffusion
   明示的な [MASK] ではなく、語彙からのランダムトークンで canvas を初期化します。確信度が落ちた位置は再ノイズします。吸収型の MASK 拡散とはここが違います。
2. canvas 256
   双方向デコーダが 256 トークンを並列に denoise します。生成時の上限は 48 step、典型は 12〜16 step です。temperature 0.8→0.4、entropy bound 0.1、adaptive stop 0.005 はこの生成サンプラーの設定です。
3. block-autoregressive（multi-canvas sampling）
   完成した 256 トークンを因果エンコーダが KV に commit し、次の空 canvas を開きます。長文は拡散とブロック単位の自己回帰の組み合わせで作ります。

djev はこのループを回しません。
テンプレートで固定した seed canvas を read-only 1-step で読み、commit も KV 位置の前進もしません。
steps > 1 にすると canvas がテンプレートから drift します。

返せる型は Jev と同じ 3 種類です。

• 同一リクエストの複数質問は、同じ state に対して 1 つの canvas で読めます。
• 同一 canvas に並べたスロットは互いに影響します。独立させたい質問には alone を付けます。
• ラベルは単一トークンに置く前提です。複数トークンの選択肢は、呼び出し側が 1 トークンの記号へ写像します。

公開されている決定速度の実測値は次のとおりです（ハードウェアが違うため参考値です）。

TypeSafe の公表値は、E2E 70〜500 ms、入力 $0.042 / MTok、出力無料です。
資料ごとの定義差は「注意点」にまとめます。

特徴

• TypeSafe Jev と同じ POST /v1/systemone 形で、オープン重みの DiffusionGemma を決定器にします。
• 出力は型付き値です。呼び出し側がパースするのは JSON の answers です。
• 1 回の read-only denoise で、固定スロットのラベル分布を温度 1 の logprobs として読みます。
• 複数の質問を 1 つの canvas に並べ、同じ prompt / KV で同時に答えます。
• 不確かさの信号はスロットの entropy です。samples=auto は初回の分布が荒いときだけ再読みします。
• DiffusionGemma の vision encoder（約 550M）を使い、画像についての質問ができます。Jev 本体の入力はテキストだけです。
• NVFP4 量子化版（nvidia/diffusiongemma-26B-A4B-it-NVFP4）で DGX Spark やハイエンド GPU に載ります。checkpoint は約 18 GB、起動時の重みは約 19 GB です。
• モデルのライセンスは Apache 2.0 です。NVIDIA の NVFP4 配布は、Gemma Terms of Use / Prohibited Use Policy も Governing Terms に含めます。
• OpenJev は TypeSafe SDK の TYPESAFE_BASE_URL を差し替えるだけで呼べます。
• エンジンの初期化は djev-spark イメージで 88〜93 秒です（FlashInfer カーネルキャッシュ付き nightly、GX10、2026-09-18）。
• djev-spark は depends_on / ask_if / alone で質問間の段階を組めます。
• 同一プロセスで OpenAI 形の生成も提供します（djev の /v1/raw/chat/completions、OpenJev の /v1/chat/completions）。

類似ツールとの比較

数値は各公式資料・README の値です。ハードウェアが違うため、req/s は参考値として読んでください。

ユースケース別の選び方

構造

djev は公式の System One ベンダーではなく、その契約を seeded canvas + read-only 1-step で再現する OSS スタックです。
C4 モデルの粒度で、外側から順に分解します。

システムコンテキスト図

アクター、djev、外部システムの関係です。ノードは役割名で書きます。

コンテナ図

djev をプロセス境界で分解します。

データ経路は常に クライアント → API サーバ → 推論エンジン → ランタイム / 視覚エンコーダ → 重みと KV です。

コンポーネント図

API サーバ、推論エンジン、モデル実行をドリルダウンします。ここでは具体的なファイル名・クラス名を使います。

意思決定フロントの要素です。

推論エンジンの要素です。

モデル実行の要素です。

read-only 経路では、Sampler が KV 位置を止め、canvas 幅分のプレースホルダだけをスケジュールします。
ラベルは生成された文ではなく、指定位置の分布として読みます。

1 リクエストの流れは次のとおりです。

vLLM の公式ブログ（2026-06-10）の時点では、拡散は投機的デコードの経路に載せ、スケジューラは無改変でした。
PR #57250 は DiffusionAsyncScheduler サブクラスを追加します。
非同期スケジュールは 1 ステップ先読みします。denoise はトークンを返さないため、既存の max_tokens ガードが発火せず、read-only が余分な forward を 1 回捨てていました。サブクラスはこの無駄を止めます。

データ

概念モデル

入力（State / Image / Question / Stage）から canvas を組み、スロットの分布を Answer に写すまでの関係です。

情報モデル

主要な属性の実装差は次のとおりです。

structured_server.py の内部スキーマは、choice を A〜Z の単一トークンラベルに載せます。そのため上限は 26 です。
公開ワイヤ上の選択肢名は、このラベルへ写像されます。

構築方法

構築経路は 3 つです。

• DGX Spark / GB10: djev-spark
• x86 の NVIDIA GPU: OpenJev
• パッチ未取り込みの素の vLLM: PR #57250 の Test Plan

前提（djev-spark）

• DGX Spark または他の GB10 箱（aarch64、unified memory、CUDA 13 ドライバ）
• NVIDIA runtime と BuildKit を有効にした Docker
• ディスク: イメージ 25 GB、checkpoint 18 GB
• メモリ: 重み 19 GB、KV プール KV_CACHE_GB、起動時の一時領域は MAX_SEQS x CANVAS に比例
• ベースイメージ: vllm/vllm-openai:nightly-dee37d89115db4c94a820a79a78a7828e141c910（vLLM 0.29.1rc1.dev347、flashinfer 0.6.18.post1）
• overlay: mmastrac/vllm のブランチ structured-reads-spark
• compose.yaml: network_mode: host、runtime: nvidia、ipc: host、container_name: dgemma

unified memory では、CUDA のメモリ超過がリクエスト失敗ではなくホストのハングになります。
他の大きなプロセスと同居させないでください。

clone と環境変数

git clone https://github.com/mmastrac/djev-spark
cd djev-spark
cp .env.example .env

既定値（.env.example と compose.yaml で同一）は次のとおりです。

チェックポイントの取得

HF の repo ID は nvidia/diffusiongemma-26B-A4B-it-NVFP4（it は小文字）です。

scripts/download-model.sh

• スクリプトはホストの hf、無ければイメージ内の hf で、checkpoint を $MODELS_DIR/$MODEL_NAME に置きます。
• entrypoint は $MODEL/config.json が無いと no model at $MODEL; run scripts/download-model.sh を出して exit 2 します。

compose で起動する

docker compose up -d --build
docker compose logs -f dgemma
scripts/smoke.sh

entrypoint が起動する vllm serve は、変数展開後の既定で次のとおりです。

vllm serve /models/dgemma --served-model-name dgemma --trust-remote-code \
  --max-num-seqs 32 --max-model-len 4096 \
  --attention-backend TRITON_ATTN --gpu-memory-utilization 0.40 \
  --kv-cache-memory 2147483648 \
  --max-logprobs 32 --enable-prefix-caching \
  --diffusion-config '{"canvas_length": 128}' \
  --override-generation-config '{"max_new_tokens": null}' \
  --port 8010 --async-scheduling

続けて structured server を起動します。

python3 /opt/dgemma/structured_server.py --upstream "http://127.0.0.1:8010" --model dgemma \
  --tokenizer /models/dgemma --canvas 128 --port 8011 --tls-port 0 --cert-dir /root/.cache/djev

scripts/smoke.sh は :8010 に生成を 1 本、:8011 に決定を 1 本送ります。
両方が応答するまで起動完了とみなしません。

OpenJev で構築する

x86 の NVIDIA GPU 向けです。README の要件は NVFP4 用に 24 GB 以上で、検証環境は RTX PRO 6000 Blackwell（sm_120）です。
この記事の OpenJev の記述は、main ブランチのコミット 91d5005（2026-09-18）時点の実装に基づきます。拡張フィールド（images / samples / think / sequential）と /v1/chat/completions は、これより前の版には無い場合があります。

git clone https://github.com/razorback16/openjev && cd openjev
docker compose up -d
curl localhost:8080/v1/models

• ビルド済みイメージは razorback16/openjev:0.2.0 です。
• 約 18 GB の重みは初回起動時に ~/.cache/huggingface へダウンロードされます。
• ホスト版は https://api.codiv.ai/v1/systemone で、README によるとカード登録なしで 100M 入力トークンまで使えます。

Docker を使わない場合は、PR 未マージのため fork を pin します（OpenJev README の手順）。

git clone https://github.com/razorback16/vllm -b structured-reads-54309 && cd vllm
VLLM_USE_PRECOMPILED=1 \
  VLLM_PRECOMPILED_WHEEL_COMMIT=2c88fb131c7ae0be01907cd8c276911db5e7aad4 pip install -e .
vllm serve nvidia/diffusiongemma-26B-A4B-it-NVFP4 --served-model-name dgemma \
  --diffusion-config '{"canvas_length": 64}' --max-logprobs 32 --enable-prefix-caching \
  --async-scheduling --attention-backend TRITON_ATTN \
  --limit-mm-per-prompt '{"image": 8, "video": 0}' \
  --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4 \
  --override-generation-config '{"max_new_tokens": null}'
pip install -e path/to/openjev && python -m openjev

PR #57250 のブランチで素の vllm serve を使う

PR の Test Plan の手順です（upstream は :8000）。

vllm serve nvidia/diffusiongemma-26B-A4B-it-NVFP4 --diffusion-config '{"canvas_length": 32}' \
  --max-logprobs 32 --enable-prefix-caching --async-scheduling --attention-backend TRITON_ATTN --max-num-seqs 32
python examples/features/diffusion_reads/structured_server.py --upstream http://127.0.0.1:8000 \
  --tokenizer nvidia/diffusiongemma-26B-A4B-it-NVFP4 --canvas 32

NVIDIA の HF カードにある vllm serve 例は生成用です。
--diffusion-config と --max-logprobs が無いため、この例だけでは POST /v1/systemone は動きません。

利用方法

POST /v1/systemone のパラメータ

エンドポイントは次のとおりです。

noul / choice / score をまとめて聞く

djev README の例です。API キーは不要で、model は無視されます。

curl -s localhost:8011/v1/systemone -H 'content-type: application/json' -d '{
  "model": "jev-latest",
  "state": {"ticket": "Everything is down and we have a demo at noon."},
  "questions": {
    "urgent": {"type": "noul", "instructions": "Does the customer need a reply within the hour?"},
    "team": {"type": "choice", "instructions": "Which team owns this?",
             "criteria": {"billing": null, "outage": "service down", "feature": null}},
    "tone": {"type": "score", "instructions": "How angry is the customer?",
             "criteria": ["calm", "annoyed", "furious"]}
  }}'

同じ形で TypeSafe 本体を呼ぶ場合は、Bearer を付けます。

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state":"Hi, I have been trying to connect Stripe for 3 days.","model":"jev-latest","questions":{"urgency":{"type":"noul","instructions":"Does this message express urgency?"}}}'

TypeSafe Quick start に載っている応答形は次のとおりです。

{
  "model": "jev-latest",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": {"billing": 0.84, "technical": 0.159, "sales": 0.001},
      "confidence": 0.596
    },
    "frustration": {
      "type": "score",
      "score": 1.035,
      "legend": {"0": "Calm, just stating facts", "1": "Frustrated but civil", "2": "Very angry, strong language"},
      "confidence": 0.842
    },
    "is_urgent": {"type": "noul", "noul": 0.999}
  },
  "usage": {"input_tokens": 312, "output_tokens": 48}
}

Quick start のこの例では、score 回答の probabilities が省略されています。
API reference では、score 回答にも各水準の確率を並べた probabilities が必須です。

djev の 3 型の応答は、公開契約の形に diagnostics が加わります。
djev の choice の confidence は、選ばれたラベルの確率です。
次の例は説明用に diagnostics を一部のキーだけに省略し、確率も丸めています。実サーバーは stages、chunks、samples、timing.total_ms なども返します。

{
  "model": "dgemma",
  "answers": {
    "urgent": {"type": "noul", "noul": 0.88},
    "team": {
      "type": "choice",
      "choice": "outage",
      "probabilities": {"billing": 0.0, "outage": 1.0, "feature": 0.0},
      "confidence": 1.0
    },
    "tone": {
      "type": "score",
      "score": 2.0,
      "legend": {"0": "calm", "1": "annoyed", "2": "furious"},
      "probabilities": {"0": 0.0, "1": 0.0, "2": 1.0},
      "confidence": 1.0
    }
  },
  "usage": {"input_tokens": 240, "output_tokens": 33},
  "diagnostics": {"steps": 1, "engine": "vllm", "timing": {"reads": 1}}
}

• TypeSafe の応答のルートは {model, answers, usage} だけです。OpenJev README の応答形にも diagnostics はありません。
• djev の検証失敗は 422 {"error":{"message":...}}、上流の失敗は 502 です。
• 空の questions は questions: needs a non-empty map of id -> question になります。

seed と samples

djev の拡張です。TypeSafe の API にはありません。

• seed の既定は 42 です。同じリクエストと同じ seed なら同じ answer になります。
• samples の既定は "auto" です。初回の entropy が auto_threshold（0.1）を超えると再読みし、上限は auto_max（4）です。
• 回数を固定するときは整数を渡します。djev の上限は 32、OpenJev は 1〜32 です。

curl -s localhost:8011/v1/systemone -H 'content-type: application/json' -d '{
  "model": "jev-latest",
  "seed": 42,
  "samples": 1,
  "state": {"ticket": "Everything is down and we have a demo at noon. Fix it now."},
  "questions": {
    "urgent": {"type": "noul", "instructions": "Does the customer need a reply within the hour?"}
  }
}'

リクエスト側の既定値（応答ではありません）は次のとおりです。

{
  "model": "jev-latest",
  "samples": "auto",
  "auto_max": 4,
  "auto_threshold": 0.1,
  "steps": 1
}

OpenJev の samples は 1〜32 の整数だけを受け付けます。"auto" という文字列は 422 です。
省略時はサーバ側で自動再読み（entropy > 0.1、最大 4 回）になります。

画像について質問する（djev の拡張）

Jev 本体に画像入力はありません。djev ではプロンプト上で画像が state より前に置かれます。

curl -s localhost:8011/v1/systemone \
  -F 'request={"model": "jev-latest", "state": {"note": "the photo is from the returns desk"},
               "questions": {"damaged": {"type": "noul", "instructions": "Is the item damaged?"}}}' \
  -F 'photo=@returns/1234.jpg'

• JSON で送る場合は images 配列（data URL または {content_type, base64}）を使います。
• OpenJev は最大 8 枚、1 枚 5 MB まで、1 枚あたり約 280 入力トークンです。
• OpenJev は sequential / think と画像の組み合わせを 422 にします。

djev-spark の playground。webcam のフレームに対して noul と choice を 1 read で返している（出典: djev-spark）

依存質問を組む（djev-spark）

{
  "questions": {
    "ahead": {
      "type": "choice",
      "instructions": "Judge only a 30 degree window at the center.",
      "criteria": {"all clear ahead": null, "danger: wall ahead": null}
    },
    "side": {
      "type": "choice",
      "instructions": "Which half of the frame is the obstacle in?",
      "criteria": {"left half": null, "right half": null},
      "ask_if": {"ahead": ["danger: wall ahead"]}
    }
  }
}

TypeSafe は、同一リクエスト内の質問を独立・並列に評価します。合成は呼び出し側のコードで行います。
後続の質問が先行の答えを必要とする場合、TypeSafe の推奨は「同じ呼び出しに投機的な質問も並べ、コードで分岐する」です。複数リクエストに分けるのはツリー走査などに限られます。

typesafe-sdk から呼ぶ

pip install typesafe-sdk
export TYPESAFE_BASE_URL=http://127.0.0.1:8080
export TYPESAFE_API_KEY=sk-local

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    state="Everything is down and we have a demo with our biggest client at noon.",
    questions={
        "urgent": Noul(instructions="Does the customer need a reply within the hour?"),
        "team": Choice(
            instructions="Which team should handle it?",
            criteria={"outage": "service down", "billing": "charges, refunds", "feature": "requests, how-to"},
        ),
        "tone": Score(
            instructions="How upset is the customer?",
            criteria=["calm", "annoyed", "furious"],
        ),
    },
)
print(response.answers["urgent"].noul)
print(response.answers["team"].choice)
print(response.answers["tone"].score)

上の TYPESAFE_BASE_URL は OpenJev ローカル（:8080）向けです。
djev-spark に向けるときは structured ポート（:8011）を指定します。既定では API_KEY は空です。

vllm_xargs を直接送る

Jev の JSON を介さず、vLLM の chat completions へ直接送る形です。PR #57250 の Example request に基づきます。

{
  "model": "dgemma",
  "messages": [
    {"role": "system", "content": "Answer a fixed set of questions... Reply with one line per question, formatted as \"id: label\"."},
    {"role": "user", "content": "{\"ticket\": \"Since this morning the dashboard shows a blank page after login...\"}"}
  ],
  "chat_template_kwargs": {"enable_thinking": false},
  "max_tokens": 17,
  "logprobs": true,
  "top_logprobs": 20,
  "logprob_token_ids": [58369, 13112, 144194],
  "return_tokens_as_token_ids": true,
  "vllm_xargs": {
    "diffusion_seed_canvas": [100, 45518, 107],
    "diffusion_max_steps": 1,
    "diffusion_read_only": true,
    "diffusion_canvas_length": 32
  }
}

上の diffusion_seed_canvas は形を示すための省略例です。
実際には canvas 幅ちょうどの長さの ID 列を渡します。PR 本文の例では seed を「64 ids total」と書いています。

運用

決定経路の SLO は req/s と p50 で設計します。
H100 の 1008 tok/s は通常生成の値なので、決定経路の指標には使いません。

起動確認

• scripts/smoke.sh は、:8010 に max_tokens: 32 の chat を 1 本、:8011 に samples: 1 の 3 問の決定を 1 本送ります。
• エンジンの初期化は GX10 上で 88〜93 s です（djev-spark README Benchmarks、2026-09-18）。

scripts/smoke.sh

ヘルスチェック

• GET /health は structured ポートで常に開いています。API_KEY を設定してもトークンは不要です。
• entrypoint は vLLM の /health を 5 秒間隔で最大 WAIT_SECS（既定 1800 s）待ち、通ってから structured server を起動します。

curl -sf localhost:8010/health
curl -sf localhost:8011/health
curl -sf localhost:8080/v1/models

最後の行は OpenJev 向けです。

ログとリロード

• サービス名は dgemma です。compose は restart: unless-stopped、host network です。
• structured server が落ちると structured server exited; restarting が出て、entrypoint が再起動します。
• vLLM が落ちるとコンテナ全体が止まります。

docker compose logs -f dgemma
docker cp server/. dgemma:/opt/dgemma/ && docker exec dgemma pkill -f structured_server.py

2 行目は structured server だけを差し替えて再起動する手順です。
エンジンの overlay、sampler のパッチ、CANVAS を変えるときはイメージを再ビルドします。

KV プロファイル 4k と 128k

• 128k プロファイルは .env.example でコメントアウトされています。3 変数を同時に有効にします。
• 128k リクエスト 1 本の KV は約 1.7 GiB です。
• djev-spark README は、hybrid allocator の観察として「30 層のうち 25 層が sliding-window 1024」と書いています。Google の model card に載っているのは Layers 30 と Sliding Window 1024 だけです。
• MAX_MODEL_LEN=131072 KV_CACHE_GB=24 のとき、KV プールは 1,808,085 tokens（128k の 13.79 本分）です。

長い state の cold / warm は次のとおりです（scripts/long-context-probe.py、128k プロファイル）。

scripts/long-context-probe.py 8678 35133 110707

同時実行数 MAX_SEQS

128k プロファイル、canvas 32、read-only、state は毎回別、各レベル 15 秒の計測です（vllm-patch/curve.py、GX10、2026-09-18）。

同じ条件で MAX_SEQS=16 にすると、32 クライアントで 42.89 req/s、p50 0.74 s です。

GPU_UTIL とメモリ上限

• Spark の既定 GPU_UTIL=0.40 は、sampler の一時領域を残すための値です。
• entrypoint は 重み 19 GB + KV + 一時領域 + HEADROOM_GB(12) を MemAvailable と比べ、不足なら起動を拒否します。
• TORCH_MEM_FRACTION は空なら無制限です。0.85 を入れるとワーカーごとの上限になり、超過はホストのハングではなくリクエストの失敗になります。このパッチは patches/worker_memory_cap.py で、upstream には未取り込みです。

GPU_UTIL=0.40
HEADROOM_GB=12
TORCH_MEM_FRACTION=0.85

単発読み取りのレイテンシ

canvas 幅 32、逐次実行、15 回の中央値です（djev-spark README の計測ハーネス vllm-patch/bench_read.py、GX10、2026-09-18）。

• 新しい tile 幅または batch size の最初のバッチは、1 回コンパイルが走ります。8 並列の cold は 7.7 s です。
• walking demo では、障害物の無いフレームの判定が Spark 上で約 320 ms + アップロード時間です。障害物がある場合は 2 回の決定になります。

デモページと TLS

• TEST_PAGE=1 で playground が :8011/ に出ます。/walk と /cube も同じフラグで有効になります。
• ブラウザの webcam は secure origin でしか使えません。別端末からは TLS_PORT=8443 を設定し、https://<box-ip>:8443/ を開きます。証明書は自己署名です。

TEST_PAGE=1
TLS_PORT=8443

認証

djev の API_KEY は、structured ポートへの POST に Bearer を要求します。GET /health と playground の HTML は認証なしで開いたままです。

API_KEY=replace-me
curl -s localhost:8011/v1/systemone \
  -H "Authorization: Bearer $API_KEY" \
  -H 'content-type: application/json' \
  -d '{"model":"jev-latest","state":"ping","questions":{"ok":{"type":"noul","instructions":"Is this a ping?"}}}'

OpenJev は OPENJEV_API_KEY と、プロキシ向けの OPENJEV_ORIGIN_SECRET（X-Origin-Secret ヘッダ）を持ちます。キューが溢れると 529 を返します。

ベストプラクティス

1-step read を既定にする

• structured read の既定は steps: 1、diffusion_read_only: true、diffusion_max_steps: 1 です。
• 1 回の forward で、ラベル位置の温度 1 の logprobs を読みます。commit の forward は走りません。
• steps > 1 にすると canvas がテンプレートから drift します（djev-spark README Extensions）。
• 単発の中央値は、1 step が 98.4 ms、2 steps が 225.1 ms、3 steps が 282.0 ms です。

通常生成の設定を決定経路に持ち込まない

• Google model card の Maximum Denoising Steps = 48、Temperature 0.8 → 0.4、entropy bound = 0.1、adaptive stop 0.005 は、通常のテキスト生成サンプラーの設定です。
• vLLM blog の H100 1,008 tok/s、H200 1,288 tok/s は、batch size 1 の FP8 生成 スループットです。structured read の req/s ではありません。

entropy 0.1 で自動再読みする

PR #57250 の Test Result にある samples=auto の例です。
質問ごとの entropy（top-20 logprobs 上）が 0.1 を超えると reads=4 になります。

choice のラベルを単一トークンにする

• PR #57250 は「canvas 自体がずれないよう、選択肢は単一トークンでなければならない」としています。
• 複数トークンの選択肢は、クライアント側で単一トークンへ写します（例: moderation_spam → A）。
• top-k だけに頼ると、26 選択肢でも top-k に乗るのは 1〜8 個です。logprob_token_ids にラベルのトークン ID を渡します。

depends_on / ask_if / alone を使い分ける

walking demo の実測が根拠です。障害物の位置が分かっているフレームで、次の結果が出ています。

• 「どちらが空いているか（turn left / turn right）」は右に偏り、p(turn left) は 0.03〜0.25 でした。
• 「障害物はフレームのどちら半分か」は 0.95〜1.00 で当たりました。
• 方向と hazard を同じ read に置くと、障害物の無いフレームの all clear が 0.8 から 0.04 へ落ちました。

互いに引っ張り合う組だけを alone / ask_if にします。
独立に分解できる判断は、同じリクエストに並べてコード側で合成します。

画像は state より前に置く

• Google model card の「Modality order」では、マルチモーダル入力で画像を text より前に置きます。
• 画像トークン予算は 70 / 140 / 280 / 560 / 1120 です。分類は低い予算、OCR は高い予算が向きます。

think は canvas 幅で頭打ちになる

• 画像付きの djev-spark では thought を canvas にシードするため、canvas 幅が上限になります。
• CANVAS=128 でそれ以上を要求するとクリップされ、diagnostics.thought.budget に実際の予算が出ます。
• OpenJev の think はテキスト専用で、画像との組み合わせは 422 です。複数ステップの問題には 512 以上を推奨しています。

prefix cache を使う

• エンコーダの因果注意と commit した KV は AR モデルと同じ書き方なので、vLLM の automatic prefix caching がそのまま効きます。
• 複数の質問で同じ前文を使い回すときは、トップレベルの instructions に共通文脈を置きます。
• 128k の warm は 8,678 tokens で 0.14 s、110,707 tokens で 0.44 s です。cold は 5.42 s / 104.94 s です。

質問を原子的にしてコードで合成する

• TypeSafe 公式は「できるだけ明示的・狭い・具体的・原子的な質問をする」ことを推奨しています。
• 「このスタートアップのピッチを評価して」は、市場規模・技術的実現性・差別化に分解し、重みはコードで持ちます。
• confidence の定義は実装ごとに違います。TypeSafe は分布の尖り、djev の choice は選ばれたラベルの確率、OpenJev は 1 − H(p)/ln K です。しきい値は実装ごとに校正します。

# TypeSafe How-to-build の分解例。係数は公式の 3 質問に対応する。
questions = {
    "requests_credentials": {"type": "noul",
        "instructions": "Does the body ask for a password or login credential?"},
    "sender_identity_mismatch": {"type": "noul",
        "instructions": "Does the sender identity fail to match the claimed organization?"},
    "unexpected_reward": {"type": "noul",
        "instructions": "Does the body claim an unexpected prize or payment?"},
}
# spam_risk = 0.45*n1 + 0.30*n2 + 0.25*n3  は呼び出し側で計算する

契約は「スキーマ外のトークンを出さない」と捉える

• TypeSafe Jev は RLCD で訓練した typed values を返します。ベンダーは type error が数学的に 0% だと説明しています。
• djev / OpenJev は DiffusionGemma の 1-step 読み取りです。保証できるのは「スキーマ外のトークンを出さない」ことで、誤分類は起こります。
• PR の Additional Results: プログラミング言語 10/10、自然言語 9/10（want=portuguese、got=french、p(want)=0.47±0.11）、単位比較 10/12。
• OpenJev の Caveats も「回答品質は、このモードで使う DiffusionGemma 26B-A4B の品質そのもの」と明記しています。

コンパイルキャッシュを永続化し、公開面を絞る

• CACHE_DIR=./cache に FlashInfer の autotune と torch compile の結果を置きます。
• djev-spark は sampler で dynamo の recompile limit を 64 に上げています。canvas 幅ごとに 1 つの specialization が要り、既定の 8 では足りないためです。
• djev-spark の既定は API キーなし・0.0.0.0 待ち受けです。LAN に公開するときは API_KEY を付けます。
• PR #57250 のレビューでは、example server の auto_max に上限が無いこと、ThreadPoolExecutor(max_workers=len(groups)) が質問数に比例して無制限に増えることが指摘されています。公開面では auto_max を 4〜32 に固定し、質問数にも上限を設けます。OpenJev は並列数の上限と 529 を実装済みです。

注意点

ドキュメントと実装の乖離

資料間の食い違い

2026-09-19 時点の未確認事項

トラブルシューティング

症状は次の 4 系統で切り分けます。

• HTTP ステータス（422 / 502 / 500 / 529 / 401）で切り分ける
• canvas のずれとラベル欠落は、steps と logprob_token_ids を見る
• 並列時の 500 と vllm_xargs の無視は、overlay の欠落を疑う
• webcam とメモリの問題は、TLS と HEADROOM_GB を見る

HTTP と契約のエラー

空の questions で 422 の形を確認できます。

curl -s localhost:8011/v1/systemone -H 'content-type: application/json' \
  -d '{"model":"jev-latest","state":"x","questions":{}}'

エンジンと並列

canvas とラベル

画像・webcam・メモリ

ヘルスチェック、smoke、8 並列の読み取りを順に流すと、どの層で止まっているかを切り分けられます。

curl -sf localhost:8010/health && curl -sf localhost:8011/health
scripts/smoke.sh
for i in 1 2 3 4 5 6 7 8; do
  curl -s localhost:8011/v1/systemone -H 'content-type: application/json' \
    -d '{"model":"jev-latest","state":{"n":'"$i"'},"questions":{"ok":{"type":"noul","instructions":"Is n even?"}},"samples":1}' &
done
wait

まとめ

• djev は、オープン重みの拡散 LLM DiffusionGemma を、Jev と同じ POST /v1/systemone 契約の型付き決定器として動かすスタックです。
• 仕組みの核は、テンプレートで固定した seed canvas を read-only 1-step で読み、スロットのラベル分布を noul / choice / score に写すことです。
• DGX Spark では djev-spark、x86 GPU では OpenJev で構築でき、決定の p50 は約 0.1 秒、32 並列で約 50 req/s です。
• 運用では、生成用の設定値（48 step、tok/s）を決定経路に持ち込まず、単一トークンのラベル・logprob_token_ids・entropy による再読みを使います。
• エンジン変更の PR は 2026-09-19 時点で未マージです。confidence の定義や choice の上限も実装ごとに違うため、採用時は実装を固定して自分のタスクで評価してください。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

概要 / モデル

• DiffusionGemma model overview
• Diffusion in Text Generation Explained
• DiffusionGemma model card
• Introducing DiffusionGemma
• arXiv:2608.00146 DiffusionGemma Technical Report
• Hugging Face google/diffusiongemma-26B-A4B-it
• Hugging Face nvidia/diffusiongemma-26B-A4B-it-NVFP4

構造 / エンジン

• vLLM blog: DiffusionGemma natively supported
• vLLM PR #57250 structured generation mode for DiffusionGemma
• vLLM structured outputs

構築 / 利用 / 運用

• djev-spark
• djev-spark .env.example
• djev-spark structured_server.py
• OpenJev

契約（TypeSafe Jev）

• Introducing System One Models & Jev
• TypeSafe docs
• TypeSafe Quick start
• TypeSafe API reference
• TypeSafe Noul
• TypeSafe Confidence
• TypeSafe Models

関連実験

• JoshuaSP/open-jev