RTX PRO 6000 BlackwellでAITuberを作りたい

Last updated at 2026-07-30Posted at 2026-07-26

概要

こちらの記事は「MEDLEY Summer Tech Blog Relay」の10日目の記事です。

RTX PRO 6000 Blackwellの実用的な使い方を探るべく、ローカルAI配信者を実装しました。本記事では、技術選定の背景、システム構成、および実測した性能をもとにしたクラウドAPIとのコスト比較を紹介します。

はじめに

株式会社メドレーのmatsudaiです。
2026年4月に入社、クラウド歯科業務支援システム「DENTIS」を開発しています。

さて先日、車を買い替えたのですが下取りが予想外に高く、せっかくなのでいわゆるAIパソコンというものを買ってみました。

普段はクラウドのAI製品を使っているのですが、従量課金では使えば使うほど青天井に請求されます。一方でローカルAIは無限に使うことで実質ゼロ円とされている¹ので、今回は自律してトークンを消費しつづける「AI配信者」がこのパソコンで作れるかどうか試してみました。

RTX PRO 6000 Blackwell について

これはなに

NVIDIA社のウルトラハイエンドGPUです。ゲーム用途ではなくグラフィックレンダリングやAI用途に位置付けられています。VRAM容量が96GB、AI処理性能²が約3.5PFLOPS、メモリ帯域が約1.8TB/s。少し前ならデータセンターでしか見なかった水準の性能が、2スロットのカード1枚で提供されます。

当該GPUには消費電力・冷却方式が異なる3種類があります。

Workstation Edition（600W）
Max-Q Workstation Edition（300W）
Server Edition（ファンレス）

今回は、BTOパソコンの消費電力・冷却の都合でMax-Q版を購入しました。

購入したBTOパソコン

マシン全体の構成は下記の通りです。

マザーボード: ASRock X870E Taichi
CPU: AMD Ryzen 9 9950X3D
メモリ: DDR5 128GB（4,800 MT/s）
GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q
電源: 1,300W

GPUの性能比較

ローカルでLLMなどのいわゆるAIを動かすとき、GPUのVRAM容量・処理性能・メモリ帯域の3つが性能を左右すると言われています。
VRAM容量は載せられるモデルの上限、処理性能は初回応答までの速さ、メモリ帯域は生成速度につながるためです。

これらを基準に主要な選択肢³を並べると下記となります。

機種	VRAM容量	AI処理性能	メモリ帯域
RTX PRO 6000 Blackwell Max-Q	96GB	3.5 PFLOPS²	1,792 GB/s
RTX 5090	32GB	3.35 PFLOPS²	1,792 GB/s
DGX Spark	128GB	1 PFLOPS²	273 GB/s
Mac Studio (M3 Ultra)	96〜512GB	-⁴	819 GB/s
MacBook Pro (M5 Max)	48〜128GB	-⁵	614 GB/s

これは容量と処理性能・帯域にトレードオフがあることを示します。
RTX 5090は帯域こそRTX PRO 6000と同速ですが、容量が32GBのため巨大なモデルが載りません⁶。一方DGX SparkやMacは100GBを超える容量を持ちますが、処理性能・帯域はRTXの半分以下で応答性・生成速度に不安があります。モデル性能と速度の両方を満たすのがRTX PRO 6000となります。

何をさせるか

ここまでの話から、今回の環境には次の特性があることが分かります。

ローカルAIはクラウドに比べて、使えば使うほど安くなる
RTX PRO 6000 Blackwellは他の機種に比べて、性能の良いモデルが高速に動く

そこで考えたのが「AI配信者」です。

AI配信者（AITuber）とは

AIにキャラクター性を持たせ、YouTuberのようなストリーミング活動をすることと言われています。
例↓

なぜAITuber？

「配信」という形態から高速なレスポンスが必要であり、ゲームプレイでは視覚（画像）が必要です。画像はテキストに比べて桁違いにトークンが大きく、フルHDの画像10枚で3万トークン程度⁷になります。

これをひたすら繰り返すわけですから、コストパフォーマンスの観点からローカルAIが有利になると考えました。

設計

普段はWebアプリケーションの開発をしているため、Webシステム中心にまとめることにしました。
Ruby on Railsで進行管理、AIの入出力や音声生成の管理を行います。
キャラクターは3Dモデルとして表示し、ブラウザ上で動かすためにThree.jsおよび@pixiv/three-vrmのサンプルモデルを利用します。また、AI用APIとしてOllamaを利用しQwen3.6モデルをホスト（画像・テキスト入力が可能なため）、キャラクターの音声にはVOICEVOXの「ずんだもん」を利用します。

配信の題材としては「2048」というゲームを選びました。
数字が表示された4×4のタイルを上下左右で操作し、同じ数字がぶつかると合計の数字1つにまとまります。この操作を繰り返して「2048」を目指すゲームとなります。

ゲーム実況内の処理サイクルは次の通りです。

JavaScriptでゲーム画面のキャプチャをRailsに送る
Railsで画像と会話履歴等をOllamaに送り、次の発話内容・画面の操作を生成する
Railsで発話内容をVOICEVOXに送り、口パク（モーラ列）と音声を生成する
Railsから画面に通知、JavaScriptで発話内容・音声・操作を受け取って再生する

リポジトリは https://github.com/matsudai/aituber-poc です。

デモ

盤面を読みつつ自分で手を決めて進めていく様子です。
（画像認識や思考を挟むため、最初・手の合間では10〜30秒程度沈黙することがあります）

動かしている間のリソースは下記の通りです。
GPU使用率は生成中で約90%、消費電力は300W未満、VRAM使用量は約44GB（モデル本体約40GB＋キャッシュ）で96GBの半分にも届いていません。別途試した画像生成では300Wに張り付いたため、電力的にも今回はフル稼働はしていないと言えます。
また、そもそもGPUが遊んでいる時間もあり稼働率はおよそ3割程度でした。画面の再生中は何も生成していないためです。

クラウドAIとのコスト比較

この配信をクラウドAPIで賄うといくらかかるか概算します。

今回は1ターンあたり512pxの画像1枚と入力約1,000トークン、出力約2,100トークンを消費し、ペースは平均35秒に1ターン（100ターン/時）でした。これをクラウドAI製品のAPI利用料に換算すると以下の通りです⁸。

モデル	入力 / 1MTok	出力 / 1MTok	今回の消費量換算時間あたり
OpenAI GPT-5.6-sol	5.00 USD	30.00 USD	980円
Claude Opus 4.8	5.00 USD	25.00 USD	830円
Claude Sonnet 5	3.00 USD	15.00 USD	500円
OpenAI GPT-5.6-terra	2.50 USD	15.00 USD	490円
Gemini 3.1 Pro	2.00 USD	12.00 USD	390円
Gemini 3.5 Flash	1.50 USD	9.00 USD	290円
OpenAI GPT-5.6-luna	1.00 USD	6.00 USD	200円
Claude Haiku 4.5	1.00 USD	5.00 USD	170円

今回のパソコンを200万円として比較すると、API利用料を回収するのに必要な時間がわかります。

Claude Sonnet 5では約4,000時間、さらに安価なGemini 3.5 Flashでは約6,800時間と、現行では回収はなかなか厳しいものがあります。強みとして押し出すのであれば金銭的なコストパフォーマンスではなく、品質面ではモデルを固定することによるキャラクター性の安定、業務で使うならセキュリティ（機密性）向上を目的とするのが良さそうです。

また、今回はGPUの稼働率が30%でVRAM容量に余裕があったので、再生中に別のタスクを行う（例：今までの話の要約やコメントへの反応の並列化など）ことでこの差を縮めることも可能でしょう。

おわりに

今回はローカルAIの使い道として、自律してゲーム実況をする仕組みが作れるかどうか試してみました。ローカルLLMは遅くて低品質のイメージがありましたが、最新のモデル・良いハードウェアがあれば思ったより自然に受け答えができるように見えました。

課題としてはGPU稼働率の改善、インターネット検索や長期記憶などの「道具」を使わせることなど多くありますので、今後も改善していきたいと思います。

MEDLEY Summer Tech Blog Relay 11日目の記事は、同じくDENTIS開発グループの @avaice さんです！
明日もお楽しみに！✨

メドレーではエンジニアを積極採用中です！

メドレーではRubyを積極的に活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。

医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！

追記

入出力性能について

本記事のポストに対して入出力性能についてのご質問をいただきましたので計測しました。結果としては入力処理（prefill）は10,000tok/s程度、生成（decode）は180～200tok/s程度でした。

ただし画像を入力した場合は、そのサイズ・枚数にもよりますが約100ms/枚程度の遅延が固定で生じると思います。

これはなに

prompt eval (prefill) は入力を解析する性能で、返答を開始するまでの時間に関わります。生成速度（decode）は、出力を開始してからどれだけの速度で返答が生成されるかを示します。

さて、今回利用したOllamaでは下記のような入出力トークン量や時間を計測することができます。

{
  "prompt_eval_count":    1025,       // 入力トークン数
  "prompt_eval_duration": 201326000,  // 入力評価の所要時間 [ns]
  "eval_count":           1925,       // 出力トークン数
  "eval_duration":        9479971000, // 出力生成の所要時間 [ns]
  "total_duration":       9912276729, // 実時間 [ns]
  "load_duration":        180928153   // モデルのロード（初回など）
}

これを利用すると、次の式でprefill、decodeの性能が分かります。

prompt eval (prefill) [tok/s] = prompt_eval_count / (prompt_eval_duration / 10^9)
generation  (decode)  [tok/s] = eval_count        / (eval_duration        / 10^9)

結果

下記シーンに分けて計測して、平均の入出力トークン数・時間とprefill、decodeを計算しました。

ゲームプレイ中の実況 : テキスト＋画像（スクリーンショット）を入力
トーク : テキストのみ入力

ターンの種類	見かけ上のprefill [tok/s]	decode [tok/s]
実況（15ターン）	約5,100 tok/s（193ms/ターン※）	202.4 tok/s
トーク（35ターン）	約10,400 tok/s	183.0 tok/s

生成ごとの計測結果詳細は長いため畳みます

シーン	#	prompt_eval_count	prompt_eval_duration [ms]	eval_count	eval_duration [ms]	思考文字数	発話文字数
実況	1	970	191.2	876	4318.8	1381	153
実況	2	971	190.6	589	2908.5	1586	112
実況	3	945	186.7	1096	5420.0	1681	134
実況	4	962	189.7	2061	10205.5	3499	123
実況	5	960	189.6	2030	10000.8	3543	125
実況	6	968	190.8	853	4204.4	1302	112
実況	7	976	190.7	1032	5087.9	1479	102
実況	8	975	191.0	3419	16934.4	8993	256
実況	9	991	194.2	911	4498.0	1488	204
実況	10	987	14.6	1402	6928.9	2129	160
実況	11	1025	201.3	1925	9480.0	3039	118
実況	12	1010	196.8	3929	19441.4	9078	128
実況	13	1009	197.2	5844	29089.9	9825	294
実況	14	1062	198.0	2861	14145.7	7333	198
実況	15	1047	200.3	2225	10967.7	3751	125
トーク	1	2713	272.4	49	266.4	—	—
トーク	2	2412	218.7	56	301.6	—	—
トーク	3	2744	268.6	78	427.8	—	—
トーク	4	2366	230.7	29	166.6	6724	61
トーク	5	2461	251.8	38	210.7	6854	71
トーク	6	2833	280.9	51	277.8	8243	92
トーク	7	2631	261.9	75	408.8	6975	146
トーク	8	2299	212.9	40	225.4	6343	86
トーク	9	2180	203.8	55	282.6	5866	99
トーク	10	2730	274.0	48	251.1	7247	82
トーク	11	2924	295.8	83	451.1	8111	158
トーク	12	2719	271.6	34	192.6	7171	61
トーク	13	3121	309.7	33	187.8	9061	74
トーク	14	2459	235.8	52	282.1	6668	109
トーク	15	2933	294.4	97	510.6	8000	182
トーク	16	2133	195.1	35	196.9	5710	66
トーク	17	2305	213.7	38	224.8	6357	82
トーク	18	2218	203.6	55	308.9	6025	99
トーク	19	2744	272.2	87	460.2	7677	170
トーク	20	2874	290.5	47	260.5	7758	96
トーク	21	2362	216.8	39	218.5	6603	85
トーク	22	3528	339.7	66	371.5	9951	132
トーク	23	2617	256.0	61	313.6	6958	112
トーク	24	2402	222.2	42	217.9	6516	85
トーク	25	2641	268.9	45	250.3	7543	93
トーク	26	2397	218.8	66	351.2	6803	139
トーク	27	3342	327.0	84	432.5	8840	158
トーク	28	3767	360.3	36	194.7	10246	74
トーク	29	2355	215.7	40	221.6	6430	84
トーク	30	2304	207.2	69	366.4	6278	138
トーク	31	3128	303.3	80	423.9	8147	145
トーク	32	2344	220.8	34	207.3	6475	74
トーク	33	3256	324.3	38	224.5	9856	81
トーク	34	2159	199.4	61	312.0	5821	106
トーク	35	3315	329.5	79	421.7	9329	162

※計測結果詳細より、実況・トークシーンともにprompt_eval_countに対してprompt_eval_durationが比例しますが、実況シーンには固定で100ms程度の切片が入っているように見えます。
トークン処理速度自体が画像・テキストの由来によって2倍も変わるとは思えないため、入力画像をトークンに変換するエンコーディング処理などでこの差が発生したと推測します。
つまり画像変換＋トークン処理がprompt_eval_durationになる（余計な時間を含んでしまう）ため、prefillの参考値はトークシーンの10,400tok/sを見たほうが正確と考えた次第です。

諸説あります。 ↩
FP4・スパースな（ひとつひとつが軽くて並列度の高い）処理の場合。 ↩ ↩² ↩³ ↩⁴
サーバー用途まで含むとNVIDIA H100 GPU（1枚あたりVRAM容量80〜94GB）なども対象になりますが、金額・設備的に現実的ではないので除きます。 ↩
公称値なし。 ↩
「M4の4倍」とされています。 ↩
性能の良いローカルLLMでは、VRAM容量にモデル40GB以上+キャッシュ領域が要求されます。 ↩
日本語のテキストに換算すると、約3万文字に相当します。 ↩
単価は2026年7月時点の各社公表値、為替は1ドル150円で換算しています。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up