RAGパイプラインでベクトル検索を高速化する手段として、インデックス構造の工夫だけでなく「ベクトルそのものをどう圧縮するか」という量子化のアプローチが注目されている。turbovecは、Google ResearchとNYUの論文が示したTurboQuantという量子化アルゴリズムを、個人開発者がRustで実装したベクトル検索インデックスだ。star数14,655・fork数1,308という規模を持ちながら、GitHub Releasesは0本というpre-1.0のプロジェクトでもある。本記事ではTurboQuantの仕組み、README記載のFAISSとの実測比較、そして実際にPythonから動かした検証結果をまとめる。

TurboQuantとFAISS IndexPQのRecall比較グラフ（OpenAI embedding d=1536、2bit/4bit）
OpenAI embedding（d=1536）でのRecall比較。TurboQuantがFAISS IndexPQ（LUT256, nbits=8）を2bit・4bitともに上回る（出典: RyanCodrai/turbovec 公式README）
30秒でわかる turbovec（2026年8月時点）
  • ・正体：個人開発者Ryan Codrai氏が開発するRust製ベクトル検索インデックス。TurboQuant量子化アルゴリズム（arXiv:2504.19874）の非公式実装
  • ・何ができる：ベクトルを学習フェーズ無しで2bit/4bitへオンライン量子化し、ARM NEON／x86 AVX-512の手書きSIMDカーネルで検索する
  • ・何を代替できる：FAISSの`IndexPQ`/`IndexPQFastScan`を使ったベクトル圧縮検索の代替候補。LangChain・LlamaIndex・Haystack・Agnoの標準ベクトルストアを差し替えるアダプタもある
  • ・実測：1万件（d=1536）の`add()`が約1.28秒、`search(k=10)`が約0.087秒（本日x86環境で計測。README記載の10万件ベンチとは条件が異なる参考値）
  • ・注意：GitHub Releasesが0本・実質コミッター1〜2名のpre-1.0プロジェクト。本番導入はこの体制を踏まえて判断する

RAGにおけるベクトル検索の全体像は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ で解説している。turbovecはこのうち「ベクトルインデックスの圧縮・高速化」というレイヤーを担うOSSとして位置づけられる。

turbovecとは｜TurboQuant量子化でベクトル検索を高速化する仕組み

turbovecは、ベクトルの次元をそのまま保持する代わりに、各ベクトルを少ないビット数（2bitまたは4bit）へ圧縮してからインデックスに追加する。この圧縮アルゴリズムがTurboQuantで、FAISSのIndexPQのような従来のProduct Quantization（PQ）と異なり、事前の学習データやk-means++によるコードブック訓練を必要としない。ベクトルをadd()した時点で分布をその場で推定し、オンラインに量子化する設計になっている。

turbovecの量子化フロー図。ベクトル追加→分布推定→2/4bit量子化→SIMD LUT検索の4段階
turbovecの処理フロー。FAISS PQのような事前学習ステップが存在せず、追加した時点でオンラインに量子化される（AI Heartland作成、README記載の設計に基づく）

検索時は、量子化済みのビット列に対してLook-Up Table（LUT）方式でスコアリングする。READMEによれば、この処理はARM NEONとx86 AVX-512BWそれぞれに手書きされたSIMDカーネルで実行され、32ベクトル単位のブロック粒度で計算されるという。一般的なベクトルDBの量子化（PQ・スカラー量子化等）が事前の学習ステップを前提にするのに対し、turbovecはこのオンライン推定によってベクトル検索の圧縮とインデックス構築を同時に進められる点が設計上の特徴だ。

読者の3つの問いへの答え
① 何ができる：ベクトルを2/4bitへオンライン量子化し、FAISSより高速な条件でSIMD検索できる ② 何を解決する：PQ方式で必要だった事前学習・コードブック訓練の手間とコスト ③ 何を代替できる：FAISSのIndexPQ系、およびLangChain/LlamaIndex等の標準インメモリベクトルストア

インストールと基本的な使い方

turbovecはPythonバインディングとRustクレートの両方で配布されている。Python版はPyPIからpip installでき、2026年8月7日時点の最新版は0.8.0（MITライセンス）だ。

pip install turbovec

READMEに掲載されている基本的な使い方は、次元数とビット幅を指定してインデックスを作るだけとシンプルだ。

from turbovec import TurboQuantIndex

index = TurboQuantIndex(dim=1536, bit_width=4)
index.add(vectors)
index.add(more_vectors)

scores, indices = index.search(query, k=10)

index.write("my_index.tv")
loaded = TurboQuantIndex.load("my_index.tv")

削除を伴う運用向けには、外部IDを保持できるIdMapIndexも用意されている。add_with_ids()で任意のuint64 IDを紐付け、remove(id)でO(1)削除できる。Rust側からもほぼ同じAPI構成で利用できる。

use turbovec::TurboQuantIndex;

let mut index = TurboQuantIndex::new(1536, 4).unwrap();
index.add(&vectors);
let results = index.search(&queries, 10);
index.write("index.tv").unwrap();

vectorsとqueryはfloat32の2次元配列である必要があり、他のdtypeは自動変換されず拒否される。事前にnp.asarray(x, dtype=np.float32)でキャストしておく必要がある点は、実装を試す際につまずきやすいポイントだ。

フィルタ検索（ハイブリッド検索）にも対応

turbovecは、SQLやBM25など外部システムで絞り込んだ候補IDに対してベクトル検索を行う「ハイブリッド検索（フィルタ済み検索）」もサポートしている。READMEによれば、このフィルタリングはSIMDカーネルの内部で32ベクトル単位のブロック粒度で行われ、許可されたIDが1つも含まれないブロックはLUTルックアップ自体をスキップする設計になっている。

flowchart LR A["外部システムで候補を絞り込み
SQL / BM25 / ACL / 時間窓など"] --> B["allowlist（uint64配列）を生成"] B --> C["idx.search(query, k, allowlist=allowed)"] C --> D{"ブロックにallowlist該当あり？"} D -- "無し" --> E["LUTルックアップをスキップ"] D -- "有り" --> F["スコアリング→ヒープ挿入
非allowed枠は挿入時に除外"]

出力件数はmin(k, n_allowed)で決まり、n_allowedは重複を除いた実際に許可されたベクトル数を指す。許可対象が少ない場合はパディングされたダミー結果ではなく、実際に該当する件数分だけが返る仕様だ。

FAISSとの実測比較｜Recall・圧縮率・検索速度

turbovecのREADMEには、FAISSのIndexPQ（LUT256, nbits=8、ビット幅に合わせてサブ量子化器数を調整）を対照群にした詳細なベンチマークが公開されている。ベンチマーク条件は100K vectors, 1K queries, k=64, 5回実行の中央値で統一されている。

x86環境でのturbovecとFAISSの検索速度比較（シングルスレッド）
x86（Intel Xeon Platinum 8481C）でのシングルスレッド検索速度。4-bit設定では最大5%程度turbovecが上回るが、2-bit設定ではFAISSのAVX-512 VBMI経路が有利な区間もある（出典: 公式README）

Recallについては、OpenAI embeddingのd=1536・d=3072でTurboQuantがFAISSを0.4〜3.1ポイント上回り、k=8以降はどちらも0.997以上に収束する。低次元のGloVe（d=200）ではTurboQuantの前提とする漸近的なBeta分布の仮定が緩くなるため差が縮まるが、それでも4-bitで1.4ポイント、2-bitで0.5ポイント上回るとREADMEは報告している。速度面はアーキテクチャで傾向が分かれ、ARMではFAISS FastScanを19〜31%上回る一方、x86の2-bit設定では逆にFAISSが優位な場面がある。

圧縮率のグラフも公開されている。

turbovecのメモリ圧縮率グラフ
ビット幅ごとのメモリ圧縮率（出典: 公式README）

比較対象のFAISS本体は、Meta（旧Facebook）のFundamental AI Researchグループが開発するC++製ライブラリで、GitHub star数は40,684（2026-08-07時点、facebookresearch/faiss実測）とturbovecの約2.8倍の規模を持つ。両者の位置づけを表に整理する。

項目 turbovec FAISS（比較対象）
開発元 個人（Ryan Codrai） Meta Fundamental AI Research
言語 Rust（Pythonバインディング） C++（Pythonラッパー）
ライセンス MIT MIT
⭐（2026-08-07時点） 14,655 40,684
GitHub Releases 0本（pre-1.0） 継続的にタグ管理
量子化の学習ステップ 不要（オンライン推定） IndexPQはk-means++によるコードブック訓練が必要
対応ビット幅 2bit / 4bit 可変（nbits指定）

READMEはFAISS IndexPQFastScanを「多くのユーザーが最初に選ぶ本番グレードのPQ実装」として比較対象に据えており、TurboQuant論文自身のu8-LUT PQよりも強いベースラインだと明記している。turbovecはFAISSに対する量子化アルゴリズムの代替候補という位置づけであり、Qdrant・Milvus・pgvector等を含めたベクトルDB全体の選定軸で比較したい場合は ベクトルデータベース比較2026｜Qdrant・Milvus・pgvectorをRAG用途で選ぶ完全ガイド を参照してほしい。「FAISSより速い」という単純な比較（FAISS比較）を全面的な優位性として読むのではなく、ビット幅とCPUアーキテクチャで結果が変わる条件付きの主張として読む必要がある。

挿入・削除・保存もベンチマーク対象

README記載のベンチマークはRecall・検索速度だけでなく、挿入・削除・永続化までを対象にしている。挿入速度は、空インデックスへのadd()一括投入（初回のみ発生する回転行列・コードブック初期化とTQ+キャリブレーションのfitを含む）と、キャリブレーション済みの状態で1万件を追記する「ウォームな追記」（定常状態のエンコード経路）の2パターンを、FAISS IndexPQFastScanの一括追加（訓練時間は計測対象外）と比較している。削除はIdMapIndex.remove(id)と、IDマップを持たない生のTurboQuantIndex.swap_removeの単発レイテンシを比較しており、両者ともO(1)のswap-and-pop方式で、差分はIDマップの管理コストに相当するという。シングルスレッド計測ではRAYON_NUM_THREADS=1を固定している。

保存・読み込みについても、同じ10万件のOpenAI embeddingコーパスで比較している。turbovecは単一の.tvファイルへfsync＋atomic renameで直列化する方式を採用しており、FAISS側はビット幅を揃えたIndexPQFastScanのwrite_index/read_indexが比較対象になっている。これらの詳細な数値はグラフとして公開されているが、benchmarks/suite/配下のベンチマークスクリプト自体もリポジトリ内で確認できるため、自分の環境で再実行して条件を揃えた比較をすることも可能だ。

実機で動かしてみた｜1万件のベクトル追加と検索速度

READMEのベンチマークは10万件・GCP c4a-standard-8（Google Axion）等の特定環境が前提のため、手元の環境でも簡易に動作を確認した。x86環境でpip install turbovec numpyを実行したところ、依存解決を含めて約2.6秒で完了した。

pip install turbovec numpy

続けて、1,536次元のランダムベクトル1万件を4bitで量子化・追加し、検索1回にかかる時間を計測した。

import numpy as np
from turbovec import TurboQuantIndex
import time

dim = 1536
n = 10000
rng = np.random.default_rng(0)
vectors = rng.standard_normal((n, dim)).astype(np.float32)
query = rng.standard_normal((1, dim)).astype(np.float32)

index = TurboQuantIndex(dim=dim, bit_width=4)
t0 = time.time()
index.add(vectors)
print("add:", time.time() - t0, "sec")

t0 = time.time()
scores, indices = index.search(query, k=10)
print("search:", time.time() - t0, "sec")
turbovecの実行結果のターミナル出力。addが約1.28秒、searchが約0.087秒
実行結果。1万件の`add()`が約1.28秒、`search(k=10)`が約0.087秒（AI Heartland実測、x86環境）

結果はadd()が約1.28秒、search()が約0.087秒だった。この数値はREADME記載の10万件・特定クラウド環境でのベンチマークとは件数もハードウェアも異なるため、直接比較できる数値ではなくあくまで手元環境での参考値として扱ってほしい。README自身も、実行環境のCPUがAVX-512やNEONに対応していない場合は速度が出ないケースがあると注記している。README記載のベンチマークはGCP c4a-standard-8（Google Axion）やIntel Xeon Platinum 8481Cのような特定のクラウドインスタンスを前提にしているため、ノートPCやコンテナ環境など異なるCPU世代・仮想化レイヤーで動かす場合は、SIMD命令セットの対応状況によって数値が大きく変わりうる点も踏まえておきたい。

LangChain・LlamaIndex等のフレームワーク統合

turbovecはRAGフレームワーク側の標準ベクトルストアを置き換えるアダプタも提供している。READMEに記載された対応フレームワークは次の4つで、いずれも既存のストレージクラスをそのまま差し替える形で使える。

・LangChain — pip install turbovec[langchain]。langchain_core.vectorstores.InMemoryVectorStoreを置き換え
・LlamaIndex — pip install turbovec[llama-index]。llama_index.core.vector_stores.SimpleVectorStoreを置き換え
・Haystack — pip install turbovec[haystack]。haystack.document_stores.in_memory.InMemoryDocumentStoreを置き換え
・Agno — pip install turbovec[agno]。agno.vectordb.lancedb.LanceDbを置き換え

パイプライン全体の構築や検索チェーンの組み方については、LangChainとは｜使い方入門ガイド — LLMエージェント・RAG・チェーン構築をPythonで実践 を参照してほしい。文書解析からRAGパイプラインを組みたい場合は RAGFlowとは｜高精度な文書解析でRAGを組むOSSエンジンの使い方・Docker導入・GraphRAG のようなエンジン側の選定も合わせて検討するとよい。

⭐14,655なのにGitHub Releasesが0本という実体

turbovecを評価する上で見落とせないのが、star数と開発体制の乖離だ。

turbovecのstar数14,655・GitHub Releases 0本・実質コミッター1〜2名という実測データ
GitHub API実測値（2026-08-07時点）。star数の規模に対してリリース管理・開発体制は個人プロジェクトの初期段階にある（AI Heartland作成）

GitHub API実測では、star数14,655・fork数1,308に対し、GitHub Releasesは0本、contributor数は約8（anon含む概算）だが実質的な開発は個人開発者Ryan Codrai氏がほぼ単独で担っている。総コミット数は約335で、pushed_atは2026-08-06と直近の活性度自体は高い。企業スポンサーの記載も見当たらず、TurboQuantアルゴリズムの原論文（arXiv:2504.19874）はGoogle ResearchとNYUの共著で、ICLR 2026への採択を海外メディアが報じているが、turbovecというRust実装自体はGoogleの公式プロジェクトではなく個人による非公式実装である点はREADME内でも明記されている。論文発の量子化アルゴリズムを、原著者とは別の個人開発者が実装からベンチマークまで独自に組み上げている構図であり、アルゴリズムの学術的な裏付けと、実装プロジェクトとしての成熟度は分けて評価する必要がある。

・バス係数：事実上1名。GitHub Releasesが0本という運用も個人プロジェクトらしさの裏付け
・pre-1.0か：該当。安定版のリリース宣言はREADMEにも見当たらない
・技術的な誠実さ：ベンチマーク数値自体は検証条件（件数・k値・試行回数）を明記して公開されており、誇張ではなく「規模の割に体制が薄い」という運用面の課題として捉えるのが正確

本番導入前に確認したいこと
GitHub Releasesが無いため、pipパッケージのバージョン管理とGitHubタグが同期していない可能性がある。バージョンを固定して使う場合は、GitHubのコミットハッシュではなくPyPI側のバージョン番号を基準に管理するのが安全だ。

まとめ｜turbovecはどんな用途に向くか

turbovecは、学習フェーズ無しのオンライン量子化というTurboQuantの特徴をRustで実装し、ARM/x86それぞれに手書きSIMDカーネルを持つという技術的な作り込みが確認できるOSSだ。README記載のベンチマークは検証条件を明示した上でFAISSとの比較データを公開しており、「ビット幅とCPUアーキテクチャによって結果が変わる」という限界も含めて誠実に書かれている。一方でGitHub Releases 0本・実質1〜2名という開発体制は、star数14,655という規模感から連想する「安定した本番採用OSS」のイメージとは異なる。LangChain・LlamaIndex等への統合アダプタが既に用意されている点は既存パイプラインへの導入コストの低さを示す一方、バージョン管理の仕組みそのものはまだ発展途上と見た方がよい。

turbovecが向いている場面
・研究用途や検証環境で、FAISSの`IndexPQ`系との比較検討をしたいケース
・LangChain/LlamaIndex等のインメモリベクトルストアを、量子化による省メモリ実装に差し替えたいケース
・逆に、リリース管理された安定版・企業サポートが前提の本番基盤が必要な場合は、pre-1.0という現状を踏まえて別の選択肢と比較した方がよい

参照ソース

・RyanCodrai/turbovec（公式リポジトリ・README） — ベンチマーク条件・API・比較対象を確認
・turbovec PyPIページ — 配布状況・バージョン（0.8.0）を確認
・TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate（arXiv:2504.19874） — turbovecが実装する量子化アルゴリズムの原論文