TurboQuantとは？vLLM・Ollama・LM Studioの対応状況と使い方【2026年10月】

TurboQuantは、GoogleのAmir Zandiehらが提案したKVキャッシュ向けのベクトル量子化手法です。論文（arXiv:2504.19874）はICLR 2026に採択され、2026年3月24日のGoogle Researchの発表で一気に知られるようになりました。発表から半年が経ち、vLLMでは本家機能として育ち、llama.cppは手法の一部だけを取り込み、Ollama・LM Studioは今も専用の型を持たない、という形に落ち着いています。ここでは仕組み、公表値と実測値の差、エンジン別の使い方、NVIDIAのKVTCとの選び方を、PR・ソースコード・公式ブログにあたって整理します。

まとめ

• TurboQuantは「ランダム回転＋座標ごとのスカラー量子化（PolarQuant段）」と「1ビットの残差補正（QJL段）」の2段構成で、キャリブレーションも再学習も要らない。ただしvLLMとllama.cpp向けの主要フォークはQJL段を意図的に外している。
• Google Researchの「精度劣化ゼロ」を、実装やモデル、評価タスクを問わない保証として受け取ることはできない。vLLM公式の追試では3ビット系プリセットで長文検索（MRCR）のAUCが45.8%→31.2%、数学・コードの推論ベンチは最大約20ポイント落ちた。
• vLLMは2026年4月15日に本家マージ済みで、--kv-cache-dtype turboquant_4bit_nc などを指定するだけで動く。5月にはQwen3.5などのハイブリッドモデルにも対応した。ただしvLLM公式の評価が第一候補に推すのは今もFP8。
• Ollama・LM StudioにTurboQuantの型は無い。llama.cpp本家は専用の型を不採用にした代わりに、量子化したKVキャッシュへ自動でHadamard回転をかける処理（TurboQuantの第1段に近い）を取り込んだ。Ollamaなら OLLAMA_KV_CACHE_TYPE=q8_0 か q4_0 で回転込みの量子化KVキャッシュになる。ただし手元の実測（Qwen3-0.6B）では、回転があってもq4_0はPPLが3.5倍に悪化し、キーをq8_0に残せば値をq4_0にしても+0.44%に収まった。
• turbo3／turbo4というキャッシュ型を使いたいならllama.cppのフォーク（llama-cpp-turboquant）、MacのSwiftならmlx-swift-lm本家、PythonのサービングならLMDeploy（quant_policy=42）も選択肢になる。
• NVIDIA KVTCは保存・転送用のKVキャッシュを品質維持の評価で最大20倍に圧縮する手法で、事前のキャリブレーションが必要になる。生成時には展開して使うため、推論中のKVキャッシュを量子化するTurboQuantとは圧縮率だけで優劣を比較できない。vLLMで推論中のKVキャッシュを縮めるなら、FP8→TurboQuant 4bit_ncの順に評価するのが現実的。

KVキャッシュ圧縮としてのTurboQuantの位置づけ

TurboQuantが縮めるのはモデルの重みではなくKVキャッシュです。Transformerは生成済みトークンのkeyとvalueを保持し続けるので、必要なメモリはコンテキスト長×同時リクエスト数に比例して増えます。128Kトークン級の入力や同時実行の多いサービングでは、KVキャッシュがモデルの重みを追い越してVRAMを先に使い切ります。

重みの量子化と効き方が違うのはこの点です。重みを4ビットにすると、空いたVRAMをKVキャッシュへ割り当てて同時処理数を増やせる場合があります。KVキャッシュの圧縮はトークン当たりの保存容量を減らしますが、同時処理数やコンテキスト長の拡張幅はモデルの上限、作業用メモリ、エンジン設定にも制約されます。KVキャッシュを減らす方法には、ヘッドを共有するGQAのようなモデル構造側の工夫もあり、TurboQuantはそれとは別の層で効く「保存形式の圧縮」です。GQAで既に小さくなったKVキャッシュをさらに数分の1にする、という重ね方ができます。

PolarQuantとQJLの2段構成と、実装でQJLが外された理由

第1段：ランダム回転とLloyd-Max量子化

第1段はベクトルにランダムな回転をかけ、座標ごとにLloyd-Max量子化（値の分布に合わせて代表値を最適配置するスカラー量子化）を当てる処理です。回転を挟むと成分ごとの値の偏りがならされ、外れ値の大きいチャネルが量子化誤差を独占する状態を避けられます。この段の考え方は別論文のPolarQuant（arXiv:2502.02617、AISTATS 2026）に由来します。「TurboQuant vs PolarQuant」と比べて調べる人が多いのですが、両者は競合ではなく、PolarQuantの考え方がTurboQuantの第1段に組み込まれた関係です。

なおvLLM v0.32.0の turboquant/config.pyは、この段がTurboQuantより前のHIGGS（arXiv:2411.17525）のスカラー版と数学的に同等だと注記しています。

第2段：QJLの1ビット残差と、vLLM・llama.cpp系が採用しなかった理由

論文の理論上の核心は、「二乗誤差（MSE）が最小になる量子化器は、内積の推定に系統的なバイアスを生む」という指摘です。アテンションはqueryとkeyの内積を計算するので、二乗誤差が小さくてもバイアスが乗れば出力はずれ続けます。そこで第1段の残差にQJL（Quantized Johnson-Lindenstrauss）の1ビット射影を当てて内積推定を不偏にします。

ところが実装の現場では、この第2段が外されています。vLLMの同じソースには「QJLは意図的に省略した。5つ以上の独立したグループが、softmaxを通して分散を増幅しアテンションの品質を下げると確認した」とあります。llama.cpp向けのコミュニティ実装turboquant_plusのREADMEも「本番ではKとVの両方でQJLを落とす」と書いています。バイアスを消しても分散が増えれば、softmaxを通った後のアテンションはかえって乱れる、という理屈です。したがって「vLLMのTurboQuant」は論文の2段構成そのものではなく、第1段に値の均一量子化とノルム補正を組み合わせたものだと理解してください。プリセット名の _nc はこのノルム補正（norm correction）を指します。

キャリブレーション不要が効く場面

どちらの段も入力データの分布を前提にしないため、代表データで統計を取る工程（キャリブレーション）も再学習も要りません。キャリブレーション前提の手法では、代表データと本番データの違いによる精度変化を確かめる必要があり、社内文書・コード・多言語の問い合わせなど入力分布が読めないワークロードほどその確認が重くなります。TurboQuantは事前の代表データを必要としませんが、本番タスクでの量子化による精度低下がなくなるわけではありません。重みにも触らないので、既存のサービングに起動オプション1つで足せます。

「精度劣化ゼロ」の出所とvLLM公式追試の実測値

まず数字の出所を分けます。「少なくとも6分の1」「最大8倍」「精度劣化ゼロ」は論文の要旨ではなく、2026年3月24日のGoogle Researchブログの表現です。原文の “at least 6x” は最大ではなく少なくとも6分の1で、8倍はH100上でアテンションのロジットを計算する部分に限った値（4ビットTurboQuantと32ビットの未量子化キーの比較）です。推論全体が8倍速くなるわけではありません。論文の要旨は「3.5ビット／チャネルで品質中立、2.5ビット／チャネルで軽微な劣化」と、ブログより慎重です。

vLLMは2026年5月11日に大規模モデルでの追試（A First Comprehensive Study of TurboQuant）を公開しました。長文検索ベンチMRCRのAUCは次のとおりです（Qwen3-30B-A3B-Instruct-2507、最大256Kトークン）。同表のスループットは別の性能試験で、vLLM 0.20.2、H100×2、200プロンプトによる測定です。最大256KのMRCR試験中の速度や、v0.32.0の速度を示す値ではありません。

落ち込みは128K〜256Kの最長域に集中しており、低ビットの誤差は系列が長いほど積み上がります。スループットは図から読んだ値で、Llama-3.3-70B-Instruct（H100×4）ではk8v4と4bit_ncが75%、3bit_ncが66%とさらに下がります。推論系ではQwen3-30B-A3B-Thinking-2507のAIME25・LiveCodeBench-v6で、k3v4_ncと3bit_ncが約20ポイント落ちました。200B超のMiniMax-M2.7でも最大約8ポイントの低下です。干し草の山から1本の針を探す合成ベンチ（NIAH）は、PR #38479のQwen3-4Bによる測定では全プリセットが100%だったため、この測定結果だけではプリセット間の精度差を判別できません。

同じブログがKVキャッシュ量子化の第一候補として推奨するのは、FP8（--kv-cache-dtype fp8）です。FP8はKV容量を2倍にしてスループットをほとんど落としません。k8v4は容量が2.4倍とFP8から少し増えるだけで速度が落ちるので「FP8に対する利点は無い」、4bit_ncは最大3.4倍の容量と引き換えに多くのベンチで1〜4ポイント落ちる「メモリが最優先のときの選択肢」、k3v4_ncと3bit_ncは十分な検証なしに本番へ入れるべきではない、という評価です。TurboQuantの価値は速度ではなく、「メモリ不足で待たされていたリクエストを受け付けられる」ことにあります。

vLLMでTurboQuantを使う手順（v0.32.0）

プリセット4種の選び方

TurboQuantはvLLM本家に取り込まれています（PR #38479、2026年4月15日マージ）。プラグインは不要で、起動時のKVキャッシュ型を切り替えるだけです。2026年10月18日リリースのv0.32.0には4種のプリセットがあります。以下の圧縮率とPPL増はソースコメントの記載値で、前章のモデル全体のKV容量倍率とは条件が異なります。実際の容量はヘッド次元や圧縮対象層などで変わります。

選び方は単純です。FP8で収まるならFP8を使い、収まらないときに turboquant_4bit_nc を試します。k8v4はFP8との差が小さく、3ビット系は前章のとおり推論・長文で崩れます。劣化がキーの量子化から来る点も覚えておくと役に立ちます。turboquant_plusの検証では、値を2ビットまで落としてもキーの精度を保てばアテンションの品質はほとんど変わらず、劣化のほぼすべてがキーの圧縮から生じていました。vLLMのプリセットがキーを値と同等以上のビット数に保っているのはこのためです。

起動コマンドと境界層・ハイブリッドモデルの扱い

vllm serve Qwen/Qwen3-30B-A3B-Instruct-2507 \
  --kv-cache-dtype turboquant_4bit_nc \
  --max-model-len 131072

密なモデルでは、最初の2層と最後の2層を自動で元の精度のまま残します（境界層の保護）。ソースの注記によると、これを外すと3ビット系でQwen3-4BのGSM8Kが約30ポイント落ちるためです。当初はTurboQuantの対象外だったMambaや線形アテンションとフルアテンションを組み合わせたハイブリッド構成は、PR #39931（2026年5月5日マージ）でQwen3.5やQwen3-Nextなどにも対応し、フルアテンション層だけを圧縮するようになりました。ハイブリッドモデルではフルアテンション層が8〜12層しかないため、境界層の保護はかかりません。

スライディングウィンドウの層は、もともとKVキャッシュの上限が窓の幅で決まるので、圧縮しても得るものが小さく、量子化にも弱い層です。窓付きの層を挟むモデルでは --kv-cache-dtype-skip-layers sliding_window でその層を元の精度に残せますが、TurboQuantと組み合わせると起動時に ValueError で落ちる不具合があり、修正（PR #60364、10月8日マージ）が入ったのはv0.32.0です。v0.31.0以前ではこの指定は使えません。また、Gemma 4 E4Bのような層間でKVを共有する構成（YOCO）とスライディングウィンドウを併せ持つモデルへの対応PR #40108は、9月30日にマージされずクローズされました。Gemma系で使う前には、起動できるかと精度の両方を自分の環境で確かめてください。vLLMそのものの仕組みと起動方法はvLLMとは？PagedAttentionの仕組みと使い方にまとめています。

Ollama・LM StudioのTurboQuant対応状況

llama.cpp本家の専用型未採用とHadamard回転の導入

OllamaとLM StudioがGGUFモデルを実行する際の推論エンジンはllama.cppです。MLXモデルの実行経路は別なので、以下のllama.cppの説明とは区別します。そのllama.cpp本家では、TurboQuantのKVキャッシュ型を追加するPR #21089（TBQ3_0／TBQ4_0）が2026年6月2日に、TQ3_0を追加する2本のPRも同じ週にクローズされ、10月時点でもTurboQuant専用の型はマージされていません。

ただし、何も入っていないわけではありません。PR #21038「llama : rotate activations for better quantization」が2026年4月1日にマージされ、KVキャッシュに入れる前のQ・K・VにHadamard回転をかける処理が入りました。作者はPRの冒頭で、TurboQuantを実装するPRの殺到を見越して基準線を上げておく、と書いています。現行のソースでは、KVキャッシュの型が量子化型（q8_0・q4_0 など）で、ヘッドの次元が64の倍数なら、回転は自動でかかります。止めたいときは環境変数 LLAMA_ATTN_ROT_DISABLE=1 です。高速なWalsh-Hadamard変換のカーネルもCPU（5月5日）・CUDA（5月25日）・Vulkan（5月28日）の順に入りました。TurboQuantの第1段のうち「回転」だけを、既存の量子化型にかぶせた形です。

OllamaでKVキャッシュを量子化する設定

Ollamaは2026年5月29日のPR #16031で、GGUFモデルの実行をllama-serverに一本化しました。2026年10月16日のv0.40.6が同梱するllama.cppはb11669で、回転が入ったb8624（4月2日）より新しい版です。Ollamaは OLLAMA_KV_CACHE_TYPE の値をllama-serverの --cache-type-k と --cache-type-v の両方へ同じ値で渡すので、量子化型を指定すれば回転込みのKVキャッシュになります。

# macOS・Linux でサーバーを起動するとき
OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

# メモリを優先するなら 4ビット
OLLAMA_KV_CACHE_TYPE=q4_0 ollama serve

Ollama公式FAQが挙げる型は f16（既定）・q8_0（f16の約2分の1、迷ったらこれ）・q4_0（約4分の1、長いコンテキストで劣化が見えやすい）の3つで、量子化KVキャッシュはFlashAttentionが有効なときに使えます。設定はサーバー全体にかかり、モデルごとには変えられません。FAQは、Qwen2のようにGQAのグループ数が大きいモデルほど量子化の影響を受けやすいとも注意しています。TurboQuantを名乗るOllamaのPR #15090も残っていますが、5月を最後に更新が止まっています。

LM StudioのKVキャッシュ量子化とTurboQuant未対応

LM StudioにもTurboQuantの型はありません。公式バグトラッカーの要望issue #1719（2026年3月31日起票）は10月時点でも未解決で、コメントは59件に積み上がっています。LM Studio自体は0.3.7でllama.cppモデルのKVキャッシュ量子化を、0.3.9でMLXモデルのKVキャッシュ量子化を追加しており、モデル読み込み時の設定で q8_0 や q4_0 を選べます。同梱のllama.cppランタイムが4月以降の版であれば、量子化型を選んだ時点でOllamaと同じく回転がかかる計算です。ただしLM Studioのランタイムの版番号はllama.cppのビルド番号と一致せず、どの版から回転が入ったかは公表されていません。MLX側でも、LM Studioのmlx-engineにTurboQuantを足すPR #300と#332が、4月と6月にマージされずクローズされています。

フォーク版llama.cppのturbo3／turbo4設定

回転だけでなくTurboQuant本体の量子化（PolarQuantの符号帳とノルムの分離）まで使いたい場合は、本家ではなくフォークのllama-cpp-turboquantを使います。Metal・CUDA・HIP・CPUに対応し、Mac（Metal）とWindows（CUDA）向けのビルド済みバイナリが配布されています。

./llama-server -m model.gguf -fa on \
  --cache-type-k q8_0 --cache-type-v turbo4

turboquant_plusの表では、turbo4（4.25ビット・3.8倍）のPPL増はq8_0比で+0.23%、turbo3（3.5ビット・4.6倍）は+1.06%です。重みをQ4_K_Mなどの低ビットにしたモデルでは、上のようにキーを q8_0 に保って値だけturbo4にする非対称の組み合わせが推奨されています。フォークなのでOllamaやLM Studioからは使えず、llama-serverを直接起動する運用になります。

llama.cppのq4_0 KVキャッシュにおける回転効果の実測

回転がどれだけ効くのかを、llama.cpp本家で確かめました。環境はIntel Mac（CPU・AVX2、8スレッド）、llama.cppは2026年10月19日のb11721、モデルはQwen3-0.6BのQ8_0 GGUF（ヘッドの次元128で回転の条件を満たす）です。WikiText-2のテストデータを512トークン×40チャンクで llama-perplexity にかけ、KVキャッシュの型と LLAMA_ATTN_ROT_DISABLE の有無だけを変えました。

llama-perplexity -m qwen3-0.6b-q8_0.gguf -f wiki.test.raw \
  -c 512 --chunks 40 -t 8 -fa on -ctk q4_0 -ctv q4_0

# 回転を止めて比べるとき
LLAMA_ATTN_ROT_DISABLE=1 llama-perplexity -m qwen3-0.6b-q8_0.gguf -f wiki.test.raw \
  -c 512 --chunks 40 -t 8 -fa on -ctk q4_0 -ctv q4_0

KVの大きさは、q8_0が32値あたり34バイト、q4_0が18バイトというブロックの大きさから計算した値です。q4_0/q4_0は同じ条件で2回測り、2回とも68.9375で一致しました。

読み取れることは3つあります。1つ目に、回転は確かに効きます。比較した3つの量子化設定では、回転を止めるとPPLの悪化幅（基準からの増加分）が約2.6〜6.1倍に広がりました。2つ目に、今回のQwen3-0.6Bでは、回転があってもキーをq4_0にするとPPLが大幅に悪化しました。q4_0/q4_0は回転込みでもPPLが基準の約3.5倍でしたが、この測定だけで小型モデル全般の生成品質や実用可否までは判断できません。3つ目に、今回の測定では劣化の原因はキー側で、値は4ビットにしてもほとんど劣化しませんでした。キーをq8_0に残して値だけq4_0にすると、KVを約4割の大きさにしてPPL増は+0.44%に収まりました。前述のturboquant_plusやvLLMのプリセットが「キーの精度を守る」設計になっているのと同じ結果です。

ここで注意が要るのがOllamaです。v0.40.6のソースでは OLLAMA_KV_CACHE_TYPE の値を --cache-type-k と --cache-type-v に同じ値で渡しており、キーと値に別々の型を指定できません。つまりOllamaで選べるのは表のq8_0/q8_0かq4_0/q4_0のどちらかです。小型モデルでは q8_0 を選び、q4_0 は使うモデルと自分のタスクで精度を確かめてから使ってください。キーをq8_0、値をq4_0にする組み合わせが欲しい場合は、llama-serverを直接起動して -ctk q8_0 -ctv q4_0 を指定します。なお今回は0.6Bの小型モデル1つを、512トークンの短い文脈で測った結果です。今回の測定ではモデルサイズによる差を比較していないため、劣化の大きさはモデルやタスクごとに測り直す必要があります。

MacとそのほかのエンジンでのTurboQuant

Apple Silicon：mlx-swift-lmの本家実装

Macでは、Apple MLXのSwift版LLMライブラリmlx-swift-lmに、TurboQuantのKVキャッシュ圧縮が本家機能として入りました（PR #232、2026年7月20日マージ）。GenerateParameters の kvScheme に方式名を入れて使います。推奨既定の turbo8v3 はキーを8ビット、値を3ビットにする非対称方式で、PRのM5 Maxでの測定ではKVキャッシュを2.72倍に圧縮し、Qwen3-1.7Bのデコード速度はfp16の0.76倍でした。Gemma系のスライディングウィンドウ層はfp16のまま残し、全体を見る層だけを圧縮します。一方、7月版で紹介したPython向けのコミュニティ実装 arozanov/turboquant-mlx は4月30日を最後に更新が止まっており、mlx-lm本家へのPR #1067も8月にマージされずクローズされました。Pythonのmlx-lmで動かす場合は、MLXとmlx-lmの導入手順を前提に、標準のKVキャッシュ量子化を使うのが現時点の手堅い選択です。

LMDeploy：QJLを残した実装

InternLMのサービングエンジンLMDeployは、2026年4月16日（#4510）にTurboQuantを quant_policy=42 として入れました（LMDeploy公式ドキュメント）。vLLMと違い、キーは3ビットのLloyd-Max量子化に1ビットのQJLを足した4ビット、値は2ビットという、論文の2段構成に近い作りです。H200上のQwen3-30B-A3B-Baseで、KVキャッシュを約5分の1にしてエンドツーエンドの性能低下は7〜8%と公表されています。

from lmdeploy import pipeline, PytorchEngineConfig

engine_config = PytorchEngineConfig(tp=1, quant_policy=42)
pipe = pipeline("Qwen/Qwen3-8B", backend_config=engine_config)
print(pipe.infer("Hello, how are you?", max_new_tokens=30).text)

PyTorchエンジン専用（TurboMindエンジンでは不可）で、MLA（DeepSeek系のアテンション）と投機的デコードには非対応、ヘッドの次元は2のべき乗に限られます。

TensorRT-LLM・SGLangは未マージ

TensorRT-LLMでは、TurboQuant4のKVキャッシュを追加するPR #14369が2026年5月20日から開いたままで、10月時点でマージされていません。SGLangでは、TurboQuantを題名に含むPRが3月から6月にかけて7本出ましたが、9月までにいずれもマージされずにクローズされ、公式のServer Argumentsに載る --kv-cache-dtype の選択肢もBF16・FP8・FP4系だけです。Google自身の公式実装コードは、10月時点で公開されたものが見当たりません。

KVTC・KIVI・SnapKV・FP8との選定基準

KVキャッシュの圧縮はTurboQuantだけではありません。「KVTC」で調べてこの記事に来る人も多いので、代表的な手法を判断軸で並べます。

NVIDIAのKVTC（arXiv:2511.01815、ICLR 2026）は、JPEGなどで使われる変換符号化をKVキャッシュに持ち込み、PCA・適応量子化・エントロピー符号化で、品質を維持した評価では最大20倍、用途によっては40倍以上に圧縮します。対象は再利用のために保存・転送するキャッシュで、デコード中は展開したキャッシュを使います。論文によると12BモデルでH100 1枚・約10分のキャリブレーションが必要で、NVIDIAの分散推論基盤Dynamoへの移植PR #6573も2月から未マージのままです。

判断の軸は2つです。1つ目は事前準備を挟めるか。代表データを用意でき、再利用するKVキャッシュの保存容量や転送量を減らしたいならKVTCの研究実装を検証する価値があり、準備工程を挟めない・入力分布が読めないならTurboQuantです。2つ目は今のエンジンで動くか。vLLMでKVキャッシュ圧縮を検討するなら、まずFP8を評価し、容量が足りない場合にTurboQuantを比較するのが本記事の推奨です。KIVI（arXiv:2402.02750）も同じくチューニング不要ですが、TurboQuantほど低ビット域の精度を守れません。SnapKV（arXiv:2404.14469）はトークンそのものを捨てる方式なので、捨てた部分を後から参照しうる対話やエージェントでは原理的に危険で、単発の要約・分類に向きます。重みの量子化（GPTQ・AWQ・GGUF）とKVキャッシュの量子化は別の話で、両方を重ねて使えます。重み側の選び方はLLM量子化とは？GPTQ・AWQ・GGUFの違いを参照してください。

社内のGPUサーバーでLLMを運用していて、コンテキスト長や同時接続数の上限に当たっているなら、KVキャッシュの型を見直すのが最も手軽な改善策です。モデル選定から推論基盤の構成まで含めて検討する場合は、生成AI導入支援でもご相談を受け付けています。

KVキャッシュ圧縮とメモリ需要の関係

KVキャッシュの圧縮がメモリ需要の減少に直結するかは、技術上の削減率だけでは判断できません。TurboQuantが減らすのはGPU上のVRAM使用量で、浮いたメモリは「より長いコンテキスト」や「より多い同時実行」に回せますが、実際の使い方は運用方針によって変わります。主要エンジンで実用になっている圧縮率も2〜5倍程度で、「6分の1」をそのまま需要減に換算するのは無理があります。

よくある質問

TurboQuantの実用化はいつですか？

vLLMではすでに使えます。2026年4月15日に本家へマージされ、--kv-cache-dtype turboquant_4bit_nc などを指定するだけで動きます。LMDeploy（quant_policy=42）とmlx-swift-lmにも本家機能として入っています。未対応なのはllama.cpp本家とそれを使うOllama・LM Studio、TensorRT-LLM、SGLangです。

OllamaやLM StudioでTurboQuantは使えますか？

TurboQuantの型としては使えません。llama.cpp本家がTurboQuant専用の型を不採用にしたためです。ただしllama.cppには量子化KVキャッシュへ自動で回転をかける処理が入っており、Ollamaなら OLLAMA_KV_CACHE_TYPE=q8_0（または q4_0）で回転込みの量子化KVキャッシュになります。Ollamaはキーと値に同じ型しか指定できず、手元の実測（Qwen3-0.6B）ではq4_0を選ぶとPPLが大きく悪化したので、まずはq8_0を選んでください。turbo3／turbo4そのものを使うには、フォーク版のllama-serverを直接起動します。

3ビット化すると精度は落ちますか？

落ちます。vLLM公式の追試では、3ビット系プリセットでQwen3-30BのMRCR（長文検索）AUCが45.8%（BF16）から31.2%へ、数学・コードの推論ベンチは約20ポイント低下しました。第一候補はFP8、それで足りなければ turboquant_4bit_nc までに留めるのが安全です。

TurboQuantとNVIDIAのKVTCはどちらを選ぶべきですか？

今のサービング基盤で使うならTurboQuantです。KVTCは保存・転送時のキャッシュ圧縮を対象とし、生成時には展開するため、TurboQuantと圧縮率だけでは比較できません。事前のキャリブレーションが必要で、原論文にはLMCacheとvLLMを組み合わせた研究評価があります。KVTCは、代表データを用意でき、再利用するKVキャッシュの保存容量や転送量を減らしたい場合に研究実装で検証する段階です。

TurboQuantの公式実装はGitHubにありますか？

Google自身の公式実装は、10月時点で公開されたものが見当たりません。論文はarXiv:2504.19874（Zandieh、Daliri、Hadian、Mirrokni／ICLR 2026）で、実装の入り口はvLLMのPR #38479と vllm/model_executor/layers/quantization/turboquant/、llama.cpp向けはTheTomのturboquant_plusとllama-cpp-turboquant、Swift向けはmlx-swift-lmのPR #232です。

関連記事

• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】
• vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説
• LLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】
• MLXとは？Apple SiliconでLLMを動かすmlx-lmの導入手順と採用判断
• TensorRT-LLMとは？NVIDIA GPUでのLLM推論高速化の仕組みと採用判断を解説【2026年版】