Atlas
DGX Spark(GB10)向けに手が入っている、Rust + CUDA 系の LLM 推論エンジン。社内検証のエンジン比較対象のひとつです。
Python / PyTorch スタックを持たない路線で、対応モデル×量子化が限定的になりやすい点が特徴です。多ユーザー常駐と単発低遅延で向きが分かれやすいため、ベンダー発表の tok/s は使わず、同じ試合規則の実測だけで判断します。

Glossary
連載で使う言葉のうち、初見だと止まりやすいものを短く説明します。一般的な用語と、この連載独自の呼び方を分けています。
一般的 … ソフトウェアやLLMの現場でよく使われる言い方。連載用語 … 社内検証の慣習名で、業界標準そのものではありません。
DGX Spark(GB10)向けに手が入っている、Rust + CUDA 系の LLM 推論エンジン。社内検証のエンジン比較対象のひとつです。
Python / PyTorch スタックを持たない路線で、対応モデル×量子化が限定的になりやすい点が特徴です。多ユーザー常駐と単発低遅延で向きが分かれやすいため、ベンダー発表の tok/s は使わず、同じ試合規則の実測だけで判断します。
ツールを使うか・どれを使うかの選択を、モデル側に任せやすくする設定です。
常にツールを呼ぶ意味ではありません。parser なしで有効化している、逆に parser だけある、という欠落が起きやすいです。
長い入力の prefill を分割して進める設定。長大処理が他リクエストを長く塞ぐられないようにします。
prefix caching とは役割が別です。長文と短文が混在する常駐で候補になりやすい項目です。
同時に受け付けるリクエスト数。負荷条件のひとつです。
concurrency を上げると数字が良く見えることがありますが、失敗率やテール(遅い側)の待ち時間が悪化していないかをセットで見ます。
本番と同じ手順を、実害が出ない確認だけ先に行うこと。ソフトウェア運用では比較的一般的な言い方です。
AWS CLI や構成管理でも「実行せずに計画だけ見る」意味で使われます。この連載では、GPU を占有する起動の前に、コマンドとプロファイルの指し先を確認する文化を指します。
Google の Gemma 系列に属する LLM の一系統。この連載では、社内検証で使う具体モデル(例: coding-agent 向け・NVFP4)の題材名として登場します。
記事の主題が Gemma4 解説ではない場合でも、vLLM 起動プロファイルの具体例として開くことがあります。ベンチの勝ち負け宣言ではなく、設定の読み方の題材として扱います。
GPU メモリのうち、推論エンジンが使ってよい割合(0.0〜1.0)。枠の宣言ノブです。
大きいほど KV や同時処理に使える余白が増えやすく、小さいほど一台共有や OOM 回避に寄ります。速さ最大化のノブではなく、占有上限の宣言として読んでください。
KVキャッシュを保持する数値精度(例: fp8)。モデル重みの量子化とは別レイヤです。
fp8 などは KV のメモリ圧を下げ、同じ枠で長い文脈や同時実行の余白を作る意図が典型です。「量子化した」一語で重みと混ぜないでください。
生成の途中経過(Key/Value)を保持するメモリ領域。長い文脈や同時実行で消費が増えます。
量子化の話で「KV を軽くする」などと出たときは、モデル重みの量子化とは別レイヤとして読んでください。
リクエスト開始から応答完了までの待ち時間。利用者が感じる「全部出終わるまでの長さ」に近い指標です。
TTFT(最初のトークンまで)や throughput(単位時間あたりの処理量)とは別物です。平均だけでなく p95 / p99(遅い側の境目)を併記すると、たまに極端に遅い回を見逃しにくくなります。
1プロンプトあたりの画像・動画などマルチモーダル入力の件数上限です。
例: image 3 / video 0。モデルが対応していても、プロファイル側で閉じていることがあります。用途と一致しているかを見ます。
OpenAI互換のAIゲートウェイ実装のひとつ。利用側と背面エンジンのあいだで、論理モデル名・routing・利用量などを担います。
連載では入口レイヤの具体例として扱います(`litellm-gateway-for-teams`)。推論エンジンの代替ではなく、経路差は「入口経由か直叩きか」の別ラベルで残します。
軽量系統の LLM 推論エンジン。この連載のエンジン比較対象(vLLM / TRT-LLM / SGLang / Atlas)には含めません。
社内基盤のスキーマに将来枠として残ることがありますが、エンジン横比較の主対象ではありません。
扱える文脈長の上限(トークン数)。入力と出力を合わせた天井、と粗く理解します。
モデルカードの最大長とプロファイル値が一致するとは限りません。長くするほど KV 予約が増え、同時実行の余白が減りやすいです。
1回のバッチに載せるトークン数の上限。一度に噛める量の制限です。
seqs が「何本まで」なら、batched_tokens は「合計何トークンまで」です。長い prefill と同時実行のバランスに効きます。
同時に進められるシーケンス(リクエスト)数の上限に近い制約です。
上げると並列は受けやすい一方、1本あたりの安定や TTFT が犠牲になりやすいです。max_num_batched_tokens とセットで読みます。
モデル重み側の量子化形式のひとつ。KVキャッシュの dtype(例: fp8)とは別レイヤです。
「量子化した」一語で重みと KV を混ぜると比較が無効になります。プロファイルでは model 側の量子化と kv_cache_dtype を分けて書いてください。
50パーセンタイル(中央値)。計測を並べたときの真ん中の値です。
典型的な一回のイメージに近いです。平均と近いことも多いですが、外れ値の扱いは平均と違います。採用判断では p50 に加えて p95 を見るのが基本です。
95パーセンタイル。計測を並べたとき、おおむね100回中95回はこの値以下、という意味の遅い側の境目です。
平均はたまに遅い回を薄めます。現場の不満は長尾(たまに極端に遅い)に出やすいので、latency や TTFT では p95 を定番で見ます。p50 は中央値、p99 はさらに厳しい長尾です。
99パーセンタイル。おおむね100回中99回はこの値以下、というより厳しい遅い側の境目です。
p95 よりさらに長尾を見ます。クレーム級の遅さや、飽和直前の崩れを拾いたいときに使います。平均や p50 だけ見て合格にしないための補助指標です。
Proof of Concept。実現可能性を確かめるための短い検証・試作です。
一度動いただけでは定着しません。この連載では、PoC の結果を再現可能な記録に残し、本番化の会話へつなぐことを重視します。
プロンプト先頭の共通部分を再利用し、同じ先頭を毎回フル計算しない仕組みです。
固定のシステムプロンプトやツール定義が長いエージェント用途で効きやすいです。先頭が毎回違うと効きません。
モデルの思考過程出力を、API 応答として分離・解釈するためのパーサです。
モデル系列ごとに形式が違うため、例では gemma4 などを明示します。不一致だと品質評価が答えを拾えず全面赤に見えることがあります。
1回の起動・計測・評価をひとまとめにして残すための識別子。社内検証での呼び方であり、業界標準の正式用語ではありません。
実験管理(MLflow の run など)でも似た考えは一般的ですが、この連載の run_id は「いつ・どの設定・どの評価スイート・どの環境か」を後から辿れるように付けるラベルです。役割は成績表の通し番号に近く、モデル名や速度数字そのものではありません。
出力が合格かを機械的に判定する部品(含む文字列、JSON 妥当性、ツール呼び出しなど)。
人手レビューの代わりというより、繰り返し回すための門番です。観点を差し替え可能にしておくと実験が速くなります。
オープンソースの LLM 推論エンジンのひとつ。serve 中心で、vLLM と並べて比較する対象です。
モデル/量子化の公式サポート範囲がはっきりしている点が特徴です。サポート外の組み合わせではパーサ不一致などが起きやすいので、比較前に対応表を確認します。
NVIDIA 系の推論最適化スタック。ビルド(準備)してから serve する流れが典型です。
準備コスト込みで比較しないと、導入判断としては不完全になりやすい、というのが連載側の見方です。
単位時間あたりに処理できる量。LLM ではトークン/秒やリクエスト/秒などで表します。
システム全体の処理能力を見る指標です。利用者一人の待ち時間(レイテンシ / TTFT)とは切り分けて読む必要があります。
ツール呼び出しの出力を、実行可能な構造化データとして解釈するパーサです。
モデルは呼べていてもパーサ不一致で下流だけ失敗することがあります。tool calling 用途では auto tool choice とセットで確認します。
Time To First Token。最初のトークン(文言の断片)が返るまでの待ち時間。利用者が「反応した」と感じる指標に近いです。
latency(完了まで)や throughput(単位時間あたりの処理量)とは別物です。同時実行を上げると throughput は良く見えても、TTFT の最悪値が壊れ、現場体感は悪化することがあります。
オープンソースの LLM 推論エンジンのひとつ。起動引数で試しやすいのが特徴です。
この連載では社内検証の比較対象(vLLM / TRT-LLM / SGLang / Atlas)のひとつとして扱い、「届け方(ランタイム)」の列で並べます。
評価や計測で流す仕事の内容・負荷条件(同時実行数、出力長など)。
モデルやエンジンを比べるときは、workload を固定しないと「何が効いたか」が分かりません。
本番前の短い確認試験。ソフトウェアのスモークテストに近い考え方です。
長いベンチの前に、明らかに壊れている設定を落とすための最小セットを指します。
計測や起動の手順がちゃんと動くかを試すための「試験用の台/枠組み」。本番GPUでの本気の速さ比べとは別物です。
自動車の配線ハーネスのように「つなぎ方をまとめたもの」が語源イメージです。この連載では、開発機などでパイプライン(起動→計測→記録)が通るか確認する段階を指すことが多いです。そこで出た数字は『測る仕組みの確認値』であり、DGXなどの実機ベンチ結果と並べて勝ち負けを語ってはいけません。
外部の生成AI API に頼らず、自社の閉域・オンプレ・プライベートクラウドなどで動かす大規模言語モデル。
データやネットワーク制約が強い現場向けの選択肢です。この連載の前提領域です。
モデルやエンジンをどう起動するかをまとめた設定のセット。
YAML や環境変数の束ね方を指します。どのプロファイルで測ったかが run_id のメタ情報に残ります。