TensorSharp とは — C# だけで動く GGUF 推論エンジンが llama.cpp に挑む

ローカル LLM のコミュニティ r/LocalLLaMA で、TensorSharp という .NET 製の推論エンジンが llama.cpp とのベンチマークを公開し、注目を集めました。多くの推論エンジンが C/C++ や Python を土台にする中で、TensorSharp は純粋な C# / .NETで LLM 推論の中核までを実装しているのが特徴です。C# を主戦場とする立場からは、AI 推論を .NET のスタックへ引き込める点で見逃せない動きです。

本記事では、作者による Reddit 投稿と GitHub リポジトリの情報をもとに、TensorSharp が何を実現しているのか、llama.cpp と比べてどうなのかを整理します。数値は投稿の実測値をそのまま紹介し、そのうえで .NET 開発の観点を添えます。

TensorSharp とは何か

TensorSharp は、GGUF 形式のモデルを対象にした ネイティブ .NET の LLM 推論エンジンです。作者の zhongkaifu 氏が開発し、BSD-3-Clause ライセンスで公開しています。コンソールアプリ、Web ベースのチャットボット UI、そして Ollama / OpenAI 互換の HTTP API を備え、プログラムから呼び出せます。Windows・macOS・Linux で動作し、GPU を活用できます。

重要なのは、これが llama.cpp の単なる C# ラッパーではない点です。作者は推論エンジンをボトムアップで実装したと述べており、CPU バックエンドを使う場合は 100% ピュア C# で動作します。加えて CUDA、MLX、GGML の各バックエンドを実装し、GGML バックエンドは外部プロジェクトとして参照しつつ、上位でいくつかの融合演算を組んでいるとしています。対応バックエンドは Metal（macOS）、CUDA（NVIDIA）、Vulkan（GPU 汎用）、CPU と幅広く、いずれも CPU へのフォールバックを備えます。

対応モデルも広く、Gemma 3 / 4、Qwen 3 / 3.5 / 3.6、GPT OSS、Nemotron-H、Mistral 3、さらに DiffusionGemma や Qwen-Image-Edit といったマルチモーダル系まで挙がっています。画像・映像・音声や PDF ドキュメントの入力、ツール呼び出し、思考モード、構造化出力にも対応します。Q4_K_M・Q8_0・MXFP4・IQ2_XXS といった量子化を、逆量子化を挟まず直接計算する設計になっている点も特徴です。

llama.cpp とのベンチマーク

作者が公開したベンチマークは、TensorSharp と llama.cpp を同一バックエンドで比べ、シナリオごとの速度比の幾何平均を示したものです。1.00× を超えれば TensorSharp が速く、decode と prefill はスループット、TTFT は初回トークンまでのレイテンシを表します。CUDA と Vulkan の両方で、複数のモデルにわたって測られています。

TensorSharp と llama.cpp を同一バックエンドで比較したベンチマーク表。Gemma 4 と Qwen 3.6 の各モデルについて、decode・prefill・TTFT の速度比が CUDA と Vulkan で並んでいる — TensorSharp vs llama.cpp のベンチマーク（出典: Reddit r/LocalLLaMA / fuzhongkai）

結果はモデルとバックエンドで濃淡があります。prefill と TTFT は多くのケースで TensorSharp が優位で、たとえば Gemma 4 E4B の CUDA では prefill が 1.28 倍、TTFT が 1.27 倍でした。一方 decode は 1.0 前後で拮抗し、Qwen 3.6 35B-A3B の Vulkan では 0.87 倍と llama.cpp を下回るケースもあります。Qwen 3.6 27B の dense では逆に prefill / TTFT が 1.0 未満になるなど、一律に速いわけではありません。作者自身も全体として「llama.cpp と同等の性能」と表現しており、この慎重な言い回しはベンチマークの実態と整合しています。

ここで押さえたいのは、純粋 .NET 実装でこの水準に届いているという事実です。推論エンジンは行列演算とメモリ管理の塊で、従来は C/C++ の独壇場でした。そこへ C# が同等のレンジで並んでくること自体が、.NET の実行性能とエコシステムの成熟を示しています。

取り込まれた最適化技術

TensorSharp は、近年の推論最適化を積極的に取り込んでいます。作者は、vLLM から ページド KV キャッシュと連続バッチ処理を、MoE モデル向けの SSD ベースキャッシュを oMLX から、GGUF 量子化を llama.cpp から学んで適用したと述べています。KV キャッシュはブロックハッシュによるプレフィックス共有とイテレーションレベルのスケジューラを備え、連続バッチ処理は既定で有効です。

さらに Qwen 3.6 と Gemma 4 では MTP / NextN による投機的デコードに対応し、テンソル並列化は Megatron-LM の列 / 行並列パターンを採用して複数 GPU やマルチノードの TCP クラスタリングまで視野に入れています。マルチ GPU 対応は Reddit のコメントでも質問が出ており、作者は単一ノードの複数 GPU と複数ノードの両方に対応する PR が進行中で、活発に更新していると回答しています。この点はまだ発展途上と捉えるのが妥当です。

X で広がった反応

この話題は日本語圏の技術アカウントでも取り上げられ、「Python 環境を用意せずに C# だけでローカル LLM を動かせる」という切り口で紹介されました。紹介では、TensorSharp が llama.cpp の単なるラッパーではなく独自実装である点、CPU なら 100% C# で動き CUDA・MLX・Vulkan と幅広い GPU に対応する点、Paged KV Cache や Continuous Batching といった最新の推論最適化を取り込み、一部モデルでは本家 llama.cpp を上回る速度を出している点、そして OpenAI / Ollama 互換 API で既存の仕組みをそのまま活かせる点が、.NET 開発者にとっての魅力として挙げられています。

【.NET開発者に衝撃！Python不要でLLMを爆速起動する「TensorSharp」が凄すぎる】

C#だけで動く革新的なGGUF推論エンジン「TensorSharp」が登場しました！✨… pic.twitter.com/IsaPhewgXa
— ハカセアイ(Ai-Hakase)最新トレンドＡＩのためのＸ (@ai_hakase_) 2026年7月27日

もっとも、ベンチマークが示すとおり「爆速」という一言だけで片づけられる話ではありません。強みは、Python ランタイムや C++ の外部依存を持ち込まずに、.NET のプロセス内で推論まで完結できることにあります。デプロイやパッケージングが .NET の作法で一貫し、既存の C# 資産と自然につながる点は、業務システムに組み込むうえで実利があります。

.NET 開発の現場にとっての意味

ローカル LLM を業務に取り込むとき、多くの現場は Python 側にモデルサーバーを立て、アプリケーションからは HTTP で叩く構成を採ります。これは動きますが、ランタイムが二重になり、デプロイと運用の面が増えます。TensorSharp のように推論エンジン自体が .NET で動く選択肢が現実的な性能で登場したことは、この構成を見直す余地を生みます。Ollama / OpenAI 互換 API を備えるため、既存のクライアント実装を大きく変えずに差し替えられる点も現実的です。

とはいえ、本番採用にあたっては冷静な見極めが要ります。ベンチマークはモデルとバックエンドで結果がばらつき、マルチ GPU 対応は開発途上です。まずは対象モデルと想定ハードウェアで自ら計測し、llama.cpp や既存構成と比較したうえで判断するのが堅実です。AI をアプリケーションへ組み込む設計そのものについては、.NET × AI 活用完全ガイドもあわせてご覧ください。

まとめ

TensorSharp は、GGUF モデルの推論を純粋 .NET で実装し、llama.cpp と同等レンジの性能をベンチマークで示したプロジェクトです。prefill や TTFT では優位なケースが多い一方、decode では拮抗や劣位もあり、一律に速いわけではありません。それでも、C# だけで LLM 推論を完結できる選択肢が実用の射程に入ってきたことの意味は大きく、AI を .NET のスタックへ取り込みたい現場にとって注目に値します。

エンハンスド株式会社では、LLM や AI エージェントを .NET を中心とした業務システムへ実装・内製化する支援を行っています。推論エンジンやモデルサーバーの構成選定、既存資産との統合、性能検証まで含めてご相談いただけます。レガシーシステムモダナイゼーションのページもあわせてご覧ください。