ブログ用語集

DGX Spark（GB10）向けに手が入っている、Rust + CUDA 系の LLM 推論エンジン。社内検証のエンジン比較対象のひとつです。

Python / PyTorch スタックを持たない路線で、対応モデル×量子化が限定的になりやすい点が特徴です。多ユーザー常駐では継続バッチング非対応などで向きが分かれやすいため、ベンダー発表の tok/s は使わず、同じ試合規則の実測だけで判断します。コーディング品質が他経路より退行した事例もありますが、『Atlas単体』より量子化／経路差として読み、速度だけで本線に載せません。

ツールを使うか・どれを使うかの選択を、モデル側に任せやすくする設定です。

常にツールを呼ぶ意味ではありません。parser なしで有効化している、逆に parser だけある、という欠落が起きやすいです。

長い入力の prefill を分割して進める設定。長大処理が他リクエストを長く塞ぐられないようにします。

prefix caching とは役割が別です。長文と短文が混在する常駐で候補になりやすい項目です。

同時に受け付けるリクエスト数。『混んだとき』の負荷条件です。

concurrency を上げると数字が良く見えることがありますが、失敗率やテール（遅い側）の待ち時間が悪化していないかをセットで見ます。

本番と同じ手順を、実害が出ない確認だけ先に行うこと。インフラの『apply 前の plan』に近いです。

AWS CLI や構成管理でも「実行せずに計画だけ見る」意味で使われます。この連載では、GPU を占有する起動の前に、コマンドとプロファイルの指し先を確認する文化を指します。

Google の Gemma 系列に属する LLM の一系統。この連載では、社内検証で使う具体モデル（例: coding-agent 向け・NVFP4）の題材名として登場します。

記事の主題が Gemma4 解説ではない場合でも、vLLM 起動プロファイルの具体例として開くことがあります。ベンチの勝ち負け宣言ではなく、設定の読み方の題材として扱います。

GPU メモリのうち、推論エンジンが使ってよい割合（0.0〜1.0）。枠の宣言ノブです。

大きいほど KV や同時処理に使える余白が増えやすく、小さいほど一台共有や OOM 回避に寄ります。速さ最大化のノブではなく、占有上限の宣言として読んでください。

複数の専門ノードと、分岐・並列・差し戻し・人間承認などの経路を、実行前に地図として設計すること。

ループを置き換えるのではなく、複数ループを配線する上位レイヤです。知識グラフや GraphRAG（データの検索）とは別問題です。LangGraph などのオーケストレーション枠組みはこの発想に近い実装例です。

KVキャッシュを保持する数値精度（例: fp8）。モデル重みの量子化とは別レイヤです。

fp8 などは KV のメモリ圧を下げ、同じ枠で長い文脈や同時実行の余白を作る意図が典型です。「量子化した」一語で重みと混ぜないでください。

生成の途中までの記憶を置くメモ領域。長い文脈や同時実行で消費が増えます。

量子化の話で「KV を軽くする」などと出たときは、モデル重みの量子化とは別レイヤとして読んでください。

リクエスト開始から応答完了までの待ち時間。利用者が感じる「全部出終わるまでの長さ」に近い指標です。

TTFT（最初のトークンまで）や throughput（単位時間あたりの処理量）とは別物です。平均だけでなく p95 / p99（遅い側の境目）を併記すると、たまに極端に遅い回を見逃しにくくなります。

1プロンプトあたりの画像・動画などマルチモーダル入力の件数上限です。

例: image 3 / video 0。モデルが対応していても、プロファイル側で閉じていることがあります。用途と一致しているかを見ます。

OpenAI互換のAIゲートウェイ実装のひとつ。利用側と背面エンジンのあいだで、論理モデル名・routing・利用量などを担います。

連載では入口レイヤの具体例として扱います（`litellm-gateway-for-teams`）。推論エンジンの代替ではなく、経路差は「入口経由か直叩きか」の別ラベルで残します。

軽量系統の LLM 推論エンジン。この連載のエンジン比較対象（vLLM / TRT-LLM / SGLang / Atlas）には含めません。

社内基盤のスキーマに将来枠として残ることがありますが、エンジン横比較の主対象ではありません。

1体のエージェントが Goal→Action→Observe→Verify を繰り返し、終了条件まで至る循環を設計すること。

ボトルネックはモデル性能より検証器と終了条件になりやすいです。人が Goal と合格バーを決め、途中ルートはエージェントが探索します。Graph Engineering の各ノードの内側でも使います。

扱える文脈長の上限（トークン数）。入力と出力を合わせた天井、と粗く理解します。

モデルカードの最大長とプロファイル値が一致するとは限りません。長くするほど KV 予約が増え、同時実行の余白が減りやすいです。

1回のバッチに載せるトークン数の上限。一度に噛める量の制限です。

seqs が「何本まで」なら、batched_tokens は「合計何トークンまで」です。長い prefill と同時実行のバランスに効きます。

同時に進められるシーケンス（リクエスト）数の上限に近い制約です。

上げると並列は受けやすい一方、1本あたりの安定や TTFT が犠牲になりやすいです。max_num_batched_tokens とセットで読みます。

モデル重み側の量子化形式のひとつ。KVキャッシュの dtype（例: fp8）とは別レイヤです。

「量子化した」一語で重みと KV を混ぜると比較が無効になります。プロファイルでは model 側の量子化と kv_cache_dtype を分けて書いてください。既製 checkpoint と自前量子化、VLM では vision 塔を除外するかも別列です。活性を 16bit に戻す設計（例: NVFP4A16）は重み方式と別に記録します。GPU が FP4 演算をネイティブに持たない場合、重み圧縮が主で decode 加速に直結しないことがあります。投機（MTP 等）と同時に変えないでください。

50パーセンタイル（中央値）。計測を並べたときの真ん中の値です。

典型的な一回のイメージに近いです。平均と近いことも多いですが、外れ値の扱いは平均と違います。採用判断では p50 に加えて p95 を見るのが基本です。

95パーセンタイル。計測を並べたとき、おおむね100回中95回はこの値以下、という意味の遅い側の境目です。

平均はたまに遅い回を薄めます。現場の不満は長尾（たまに極端に遅い）に出やすいので、latency や TTFT では p95 を定番で見ます。p50 は中央値、p99 はさらに厳しい長尾です。

99パーセンタイル。おおむね100回中99回はこの値以下、というより厳しい遅い側の境目です。

p95 よりさらに長尾を見ます。クレーム級の遅さや、飽和直前の崩れを拾いたいときに使います。平均や p50 だけ見て合格にしないための補助指標です。

Proof of Concept。実現可能性を確かめるための短い検証・試作です。

一度動いただけでは定着しません。この連載では、PoC の結果を再現可能な記録に残し、本番化の会話へつなぐことを重視します。

プロンプト先頭の共通部分を再利用し、同じ先頭を毎回フル計算しない仕組みです。

固定のシステムプロンプトやツール定義が長いエージェント用途で効きやすいです。先頭が毎回違うと効きません。

量子化後の品質スコアを基準（量子化前）で割った比。1.0 に近いほど品質を保てています。

軸別・総合の両方で残します。平均だけだと意味改変級の少数失敗が薄まるため、最悪サンプルや誤り件数・区間推定とセットで門番を組みます。tok/s の隣に置く列です。

モデルの思考過程出力を、API 応答として分離・解釈するためのパーサです。

モデル系列ごとに形式が違うため、例では gemma4 などを明示します。不一致だと品質評価が答えを拾えず全面赤に見えることがあります。応答キーも経路で違い、直叩きでは reasoning、入口経由では reasoning_content などに正規化されることがあります。

1回の実験（起動・計測・評価）に付ける通し番号。実験ノートの表紙ラベルに近い社内の呼び方です。

実験管理（MLflow の run など）でも似た考えは一般的ですが、この連載の run_id は「いつ・どの設定・どの評価スイート・どの環境か」を後から辿れるように付けるラベルです。役割は成績表の通し番号に近く、モデル名や速度数字そのものではありません。

出力が合格かを機械的に判定する部品（含む文字列、JSON 妥当性、ツール呼び出しなど）。

人手レビューの代わりというより、繰り返し回すための門番です。観点を差し替え可能にしておくと実験が速くなります。

オープンソースの LLM 推論エンジンのひとつ。serve 中心で、vLLM と並べて比較する対象です。

モデル／量子化の公式サポート範囲がはっきりしている点が特徴です。サポート外の組み合わせではパーサ不一致などが起きやすいので、比較前に対応表を確認します。

NVIDIA 系の推論最適化スタック。ビルド（準備）してから serve する流れが典型です。

準備コスト込みで比較しないと、導入判断としては不完全になりやすい、というのが連載側の見方です。

推論モデルの思考過程を有効にする指定。キー名はモデル系列で違い、未到達は OFF と同義です。

例として enable_thinking と thinking などがあります。設定ファイルや CLI に書いただけでは足りず、評価ハーネスが送ったリクエスト実体で確認します。フラグが届いていないと、ON/OFF 差がゼロに見えます。

単位時間あたりのさばき量。LLM ではトークン/秒やリクエスト/秒などで表します。

システム全体の処理能力を見る指標です。利用者一人の待ち時間（レイテンシ / TTFT）とは切り分けて読む必要があります。

ツール呼び出しの出力を、実行可能な構造化データとして解釈するパーサです。

モデルは呼べていてもパーサ不一致で下流だけ失敗することがあります。tool calling 用途では auto tool choice とセットで確認します。

最初の返事が返るまでの待ち時間（Time To First Token）。利用者が『反応した』と感じる指標に近いです。

latency（完了まで）や throughput（単位時間あたりの処理量）とは別物です。同時実行を上げると throughput は良く見えても、TTFT の最悪値が壊れ、現場体感は悪化することがあります。

LLM を届ける推論エンジンのひとつ。モデル用の Web サーバに近い層で、起動引数で試しやすいのが特徴です。

この連載では社内検証の比較対象（vLLM / TRT-LLM / SGLang / Atlas）のひとつとして扱い、「届け方（ランタイム）」の列で並べます。

評価や計測で流す仕事の内容・負荷条件（同時実行数、出力長など）。

モデルやエンジンを比べるときは、workload を固定しないと「何が効いたか」が分かりません。

本番前の短い確認試験。ソフトウェアのスモークテストに近い考え方です。

長いベンチの前に、明らかに壊れている設定を落とすための最小セットを指します。

計測や起動の手順がちゃんと動くかを試すための「試験用の台／枠組み」。本番GPUでの本気の速さ比べとは別物です。

自動車の配線ハーネスのように「つなぎ方をまとめたもの」が語源イメージです。この連載では、開発機などでパイプライン（起動→計測→記録）が通るか確認する段階を指すことが多いです。そこで出た数字は『測る仕組みの確認値』であり、DGXなどの実機ベンチ結果と並べて勝ち負けを語ってはいけません。

外部の生成AI API に頼らず、自社の閉域・オンプレ・プライベートクラウドなどで動かす大規模言語モデル。

データやネットワーク制約が強い現場向けの選択肢です。この連載の前提領域です。

モデルやエンジンをどう起動するかをまとめた設定のセット。

YAML や環境変数の束ね方を指します。どのプロファイルで測ったかが run_id のメタ情報に残ります。

投機的デコーディングで、下書き提案のうち本モデルが採用した割合。

低いと捨て作業が増え、体感速度が落ちます。低受理をチェックポイント欠陥と決めつけず、draft loader の重み欠落や override 脱落も疑います。起動成功・出力正常でも受理だけ悪化することがあります。