LLMを自社で開発・運用するとき、モデルだけ選べば終わりではありません。データの収集・加工から、ファインチューニング、推論の高速配信、そしてそれらを束ねるバックエンド基盤まで、複数のレイヤーにまたがるツール選定が求められます。
この記事では、LLMエンジニアリングで実務に採用されている9ツールの構成を、データ→学習→推論→配信の流れに沿って紹介します。
この記事でわかること：
- LLM開発パイプラインの全体像と各レイヤーの役割
- 各ツールが選ばれる技術的な理由
- ツール同士の組み合わせ方
LLMパイプラインの全体像
LLM開発のパイプラインは、データ処理・モデル学習（ファインチューニング）・推論サービングの3フェーズに分かれます。
データ処理フェーズでは大量の生データを収集・整形し、学習に使える形にします。学習フェーズではベースモデルを自社のユースケースに合わせて調整します。推論フェーズでは学習済みモデルをAPIとして外部に公開し、低レイテンシで応答を返します。
この3フェーズを支えるインフラとして、キャッシュ、ベクトルDB、タスクキュー、メッセージブローカーが加わります。今回の構成ではこれらすべてをOSSでカバーします。
データ処理レイヤー：PySpark + HuggingFace Datasets
LLM開発のデータ処理で最初にぶつかる壁は、データの量です。数十GB〜数TBのテキストデータを単一マシンのPandasで処理しようとすると、メモリ不足で止まります。PySpark（Apache SparkのPython API）は分散処理フレームワークで、クラスタを組めばTBスケールのデータを並列に処理できます。テキストのクレンジング、重複排除、トークナイズ前の前処理がPySparkの守備範囲です。
加工したデータをモデルに渡す段階では、HuggingFace Datasetsが標準的な選択肢になっています。Arrow形式でメモリマップされたデータセットを扱えるため、数十GBのデータでもメモリを圧迫しません。HuggingFace Hub上で公開されている30万以上のデータセットをそのまま読み込める点も、プロトタイプの高速化に効きます。
ファインチューニング：Unsloth
ベースモデルをそのまま使うだけでは、特定のタスクで十分な精度が出ないケースがあります。自社データで追加学習するファインチューニングが必要ですが、70Bパラメータ規模のモデルをフルファインチューニングするにはA100を複数枚用意しなければならず、コストが現実的ではありません。
Unslothは、手書きのTritonカーネルでLoRA/QLoRA（Low-Rank Adaptation / Quantized Low-Rank Adaptation）のファインチューニングを最適化したOSSです。GitHubスターは6万3,000を超えています。通常のHugging Face Transformersと比べてVRAMを最大74%削減し、学習スループットを2〜5倍に引き上げます。QLoRA（4ビット量子化）を使えば、8Bパラメータのモデルを12GBのコンシューマGPU 1枚でファインチューニングできます。
2026年現在の推奨設定は、LoRAランクr=16、DoRA有効、target_modules=”all-linear”です。Unsloth独自の動的4ビット量子化により、QLoRAでもLoRAに匹敵する精度を維持します。Gemma 4、Qwen 3.6、DeepSeekなど主要なオープンモデルに対応しており、Web UIの「Unsloth Studio」からGUIでの学習実行も可能です。
推論サービング：vLLM
https://github.com/vllm-project/vllm
学習が終わったモデルを本番環境で使うには、推論エンジンが必要です。vLLMはGitHubスター7万8,000超のOSS推論エンジンで、Amazon（Rufus、2.5億ユーザー対応）、LinkedIn、Roblox（週40億トークン処理）、Metaなどが本番環境で採用しています。
vLLMの中核技術はPagedAttention（ページドアテンション）です。KVキャッシュのメモリを小さなブロック単位で柔軟に管理する仕組みで、従来の大きな連続メモリ確保方式と比べてスループットを最大24倍に引き上げます。Continuous Batching（継続バッチング）と組み合わせることで、リクエストの到着順に動的にバッチを組み替え、GPUの空き時間を最小化します。
2026年時点ではGPUレス前処理によるマルチモーダル対応の分離、NGramスペキュレーティブデコーディングのGPU実行、FP8量子化によるメモリ半減といった機能が加わっています。NVIDIA GPU、AMD GPU、Google TPU、Apple Siliconなど幅広いハードウェアに対応している点も、採用の決め手です。
バックエンドAPI：FastAPI
推論エンジンの前段には、リクエストのルーティング、認証、レート制限を担うAPIサーバーが必要です。FastAPIはPython製の非同期Webフレームワークで、async/awaitによるノンブロッキングI/Oが標準で使えます。
LLMサービングとの相性が良い理由は、StreamingResponseによるトークン単位のストリーミング配信に対応している点です。vLLMの非同期APIを直接呼び出し、生成されたトークンを逐次クライアントに返せます。OpenAPI仕様の自動生成により、フロントエンドチームとの連携やドキュメント作成の手間も省けます。
データストア：Redis + Qdrant
https://github.com/qdrant/qdrant
LLMアプリケーションには2種類のデータストアが求められます。高速なキャッシュ層と、ベクトル検索層です。
Redisはインメモリのキーバリューストアで、LLM用途ではプロンプトキャッシュとセッション管理に使います。同じプロンプトに対する推論結果をRedisにキャッシュすれば、2回目以降はGPUを使わずにミリ秒単位で応答を返せます。これだけで推論コストを大幅に削減できます。
QdrantはRust製のベクトル検索エンジンで、RAG（Retrieval-Augmented Generation、検索拡張生成）の中核を担います。GitHubスターは3万を超えています。100万件のOpenAI Embeddingに対して3msの応答速度を実現しており、密ベクトルとスパースベクトルを組み合わせたハイブリッド検索に対応しています。メタデータフィルタリングによる絞り込みも可能です。ユーザーの質問に関連するドキュメントをQdrantから取得し、プロンプトに埋め込んでLLMに渡す——このRAGパイプラインが、LLMの回答精度を引き上げます。
非同期処理とメッセージング：Celery + Kafka
LLMの推論は数秒〜数十秒かかるため、同期的にリクエストを待つとAPIサーバーがボトルネックになります。非同期のタスクキューが欠かせません。
CeleryはPython製の分散タスクキューで、時間のかかるLLM推論をバックグラウンドジョブとして実行します。バッチ処理、スケジュール実行、リトライ制御が標準で備わっており、FastAPIからタスクを投げてワーカーに処理を委譲する形で組み合わせます。ブローカーにはRedisを兼用できるため、追加のインフラなしで導入できます。
Kafkaは分散メッセージブローカーで、マイクロサービス間のイベントストリーミングを担います。ユーザーの入力ログ、推論結果、フィードバックデータをKafkaのトピックに流し、下流のデータパイプラインで集約します。ファインチューニング用の学習データを継続的に蓄積するデータフライホイールの基盤として機能し、モデルの改善サイクルを回し続ける仕組みを支えます。
9ツールを束ねる設計の強み
この構成の利点は、各レイヤーが独立してスケールできる点です。推論リクエストが増えればvLLMのワーカーを追加し、データ量が増えればPySparkのクラスタを拡張します。ツール間はAPI（FastAPI）とメッセージキュー（Kafka/Celery）で疎結合になっているため、1つのコンポーネントを差し替えても他に影響しません。
9ツールすべてがOSSで、ベンダーロックインのリスクがありません。クラウドでもオンプレミスでも同じスタックを展開できます。LLMの開発基盤をゼロから構築する際の出発点として、この構成を検討してみてください。