Paddock、Rust／CUDA推論エンジンをオープンソース化――単一NVIDIA GPUでのエージェント同時実行に照準

Truesparは9月4日、Paddockの内部ライブラリをMIT／Apache-2.0のデュアルライセンスで公開した。これはllama.cppやPython推論バックエンドをラップしたものではない。Rust製のサービス層、continuous batchingスケジューリング、ページングKV cache、radix prefix cache、メモリ管理、C++ CUDA kernelsがすべて同一リポジトリに収められている。`paddock-runner`は、OpenAI Chat Completions、Responses、embeddings、音声文字起こし、Anthropic Messagesなどの互換インターフェースを直接提供できる。重みはGGUFとsafetensorsから読み込め、量子化パスはFP8、NVFP4、MXFP4、Q8_0、および一部のQ4_Kに対応する。

設計の中心にあるのは、単一GPUで複数のコーディングエージェントや長時間の対話を同時に処理することだ。chunked prefillと公平なスケジューリングに加え、PaddockはKV cacheをメインメモリやディスクへ退避できるほか、VRAMに収まらないMoE expertsをRAMからストリーミングすることもできる。CUDA kernel packは安定したC ABIを介してRust binaryから分離されており、プリコンパイル済みバージョンの実行に必要なのはNVIDIAドライバだけだ。kernelsを自分でビルドする場合に限り、CUDA 13.xが必要となる。内蔵のStudioはモデルのダウンロード、比較、artifactsの管理を担うが、こうした周辺機能によって監査対象となるコード領域も広がっている。

開発者はNVIDIAの`aiperf`を用い、RTX PRO 6000上でQwen3.8-27B FP8をテストした。その主張によれば、13のシナリオすべてでvLLMを上回り、速度差は1.02～1.19倍だった。SGLangとの比較では10勝2敗1引き分けだった。ただし、これは依然としてベンダー側が管理した単一GPUでのテストである。また、Redditユーザーからは、RTX 5080でのコンパイルエラー、一部のGGUF量子化モデルが実行できない問題、loopback接続で認証が不要になることや、障害発生時にも起動を継続することなど、潜在的なセキュリティ問題が報告されている。このうちコンパイルエラーは修正済みだが、セキュリティ上の影響については正式な告知による確認がまだない。現時点で対応しているのはWindows／Linux向けのCUDAパスのみで、1つのモデルを単一GPUに配置する必要がある。tensor parallel／pipeline parallelには対応せず、ROCm、Vulkan、Metalも利用できない。導入担当者は、モデル、量子化方式、ドライバ、負荷条件を固定して公開済みシナリオを再検証し、APIを強制認証が設定されたreverse proxyの背後に配置すべきだ。