[自作日記7’] コラム:コンシューマ用GPUとプロ用GPUの違い

[自作日記7’] コラム:コンシューマ用GPUとプロ用GPUの違い

今回は、コンシューマー用GPUは本格的なAI計算に使用できるのか、プロ用GPUとの違いは何か。比較も交えながら考えてみたいと思います。

私たちAI ベンチャー(ベンチャーじゃなくても)でGPUを使うシーンは3つあります。

  1. AI研究:最新モデルや論文のちょっとしたお試し
    小規模な学習。小規模な推論。
  2. 学習:いわゆるディープラーニングのトレーニング。
    長いと数週間、数か月におよぶ。
  3. 商用運用:お客様が使用するサービスのバックエンドとしての
    AIエンジンの商用運用

今回 Jun さんが作ろうとしている GPU マシンは 1.AI研究 のためのものです。

というのも、たとえば、コンシューマー用GPUやコンシューマー用の自作パソコンの場合は長時間にわたるディープラーニングのトレーニングには向いていません。

やってる人もたまにみかけますが、心配になります。

なぜなら、学習させたいネットワークにもよりますが、1回の学習にかかる時間は数日から数週間、長いと数か月にわたります。その間、GPUをドライブするソフトウェアが安定的に稼働している必要があります。2,3日なら何の問題もないことが、数週間まわすと謎のソフトウェアバグがドライバ層などで発生して学習が止まっていた、ということはよくあります。
また、マシンが過熱しない、など廃熱系も安定させて稼働するためには、それなりの対策を施す必要があります。

もともとコンシューマー用のGPUは3Dゲームのために設計されており、数週間の連続高負荷は想定されておりません。1回の学習が3,4日程度なら人の目で監視ということも不可能ではないとおもいますが、いずれにしても、手間がかかるものとなります。

そこで今回 Jun さんが開発しているような秋葉原で手に入りそうなパーツで構成された GPUマシンは、長時間高負荷な計算はさせない ことが前提の ”研究用” GPUマシンと位置付けています。

では、プロ用のGPUとは何でしょうか。

プロ用のGPUには大きく2種類あります。

1つは、ワークステーション用GPU。もう1つはデータセンター用GPUです。

ワークステーション用のGPUはコンシューマー用GPUに近い環境で使用されますが、ドライバーの安定性や信頼性、商品の長期サポートなどが特長で、コンシューマー用GPUより高い信頼性があります。また高度な計算のため、計算精度がコンシューマー用GPUに比べて有利です。ワークステーション用として有名かつ人気のGPUには NVIDIA RTX A6000 などがあります。

データセンター用GPUはその名の通り、専用のデータセンター環境で稼働することを前提としているGPU。ワークステーション用のGPUの特長に加え、エネルギー効率(要は消費電力)が高く、高い並列性などが特長になっています。データセンター用GPUとして有名なものには、 NVIDIA RTX A100、NVIDIA RTX H100 などがあり、1枚あたり300万円以上します。データセンター用とはいっても、インタフェースはPCI Express ですので、通常のワークステーションで動作させることも可能です。

このように2や3の用途で ”安心して” 使用する場合には、ワークステーション用のGPUやデータセンター用のGPUが必要になってきます。

GPUサイズと排熱方式と稼働音

今度は排熱という視点で、GPUをみてみましょう。

GPUは高負荷の計算をすることから、その副産物として大量の”熱”を発生させます。そこで、GPUが発する熱をどうやって放出し、GPUが過熱したり燃えたりすることを防ぐか、が重要となります。

この排熱の方式には大きく3つの方式があります

  1. 空冷 - 内排気
  2. 空冷 - 外排気
  3. 水冷

内排気のグラフィックボード

内排気というのは、PCケースの中にグラフィックボードの熱を排気スタイルです。
コンシューマー用GPUでは、1のタイプが多く、一般的に大きなヒートシンクと一つまたは複数のプロペラファンを使用してケース内の広い範囲に熱を拡散します。この方式は比較的安価でグラフィックボードを作れる反面、大型のヒートシンクとファンによりグラフィックボードのサイズが大きくなる傾向にあります。また、次に紹介する外排気型のグラフィックボードに比べて、ファンの稼働音が静かです。

外排気のグラフィックボード

外排気は、PCケースの中ではなく、PCケースの外側に直接、熱された空気を排出する方式です。ワークステーション用やデータセンター用のグラフィックボードは主にこの方式が採用されます。このときによく使用されるファンが”ブロワーファン”です。

ブロワーファンは空気を中心から吸い込み、ブレードを通過させた後にラジアル(放射状)に排出しケース内の空気を一方向に強力(流量)に吹き出すことができます。以前のグラフィックボードでは同様の目的で”シロッコファン”(圧力優先)というファンが取り付けられていましたが最近は流量優先のブロワーファンが採用されています。

この方式では、ファンがケースの一端に取り付けられ、直線的に空気を外に押し出し空気流がGPUのヒートシンクを通過して直接外部へと押し出されるため、冷却効率が高まります。この方式ではケース内に熱を拡散する内排気型とは異なり、グラフィックボードのサイズを小さくすることができます。反面、ブロワファンは稼働音が大きい場合があるので、静音が重視の場合は内排気型がおすすめです。

水冷のグラフィックボード

水冷のグラフィックボードは一部コンシューマー用のラインナップ(簡易水冷)などで見かけることがあります。また大規模データセンターでは、サーバールーム全体の冷却効率を高めるために、水冷システムを導入する場合があります。これにより、大量のGPUを効率的に冷却することが可能ですが、水冷システムの構築には非常に高いコストがかかりますので、あまり一般的ではりません。

GPUサイズと稼働音

排熱方式について、簡単にみてきましたが、サイズと稼働音についてまとめると
外排気型のグラフィックボードだと、安くて、比較的静かだけど、サイズが巨大
内排気型のグラフィックボードだと、高価、排気音が大きい、サイズは小型

となります。

複数枚のグラフィックボードを挿して使いたい場合は、PCI Expressのスロット干渉に悩まなくてよい内排気型のグラフィックボードがオススメです。


navigation

Read more

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

こんにちは! Qualitegプロダクト開発部です! 「楽観的ロックを実装したのに、まだ競合エラーが出るんですけど...」 これは私たちが実際に経験したことです。 本記事では、楽観的ロックと悲観的ロックの違いを、実際に発生したトラブルを通じて解説します。 抽象的な説明ではなく、 「なぜそれが必要なのか」「どんな問題を解決できるのか」 を実感できる内容を目指します。 目次 1. 問題の背景:並列処理で謎のエラー 2. ロックなしの世界:なぜ競合が起きるのか 3. 楽観的ロックの導入:期待と現実 4. 楽観的ロックの限界:解決できなかった問題 5. 悲観的ロックによる解決 6. 実装時のハマりポイント 7. どちらを選ぶべきか:判断基準 8. まとめ 1. 問題の背景:並列処理で謎のエラー 1.1 システムの概要 私たちが開発していたのは、 複数のワークスペースを切り替えて使用するAPIサーバー でした。 当社AI関係のプロダクトの一部だったのですが、結合テスト兼負荷テストを実行すると、まれに発生してしまっていました。 ユーザーは複数のワーキン

By Qualiteg プロダクト開発部
企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

こんにちは! ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、 「AIに機密情報を送ってしまうリスク」 が新たなセキュリティ課題として浮上しています。 この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。 すると、ある疑問が浮かんできます。 「なんでこんなに複雑になってるんだっけ?」 企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。 アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。 当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。 本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。 第1章:観測点を集約できた時代 ― オンプレAD + Proxy(〜2010年代前半) 統制しやすかったモデル かつ

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

こんにちは。 —— 2003年のSOAから、2026年のAIへ —— この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。 歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。 そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。 だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。 はじめに:20年前の熱狂を覚えていますか 2000年代初頭。 私はSOA(サービス指向アーキテクチャ)に本気で取り組んでいました。 当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。 カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。 SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。 あれから

By Qualiteg コンサルティング
DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

こんにちは!Qualitegプロダクト開発部です! 本日は Docker環境でPythonをソースからビルドした際に発生した、GCCの内部コンパイラエラー(Segmentation fault) について共有します。 一見すると「リソース不足」や「Docker特有の問題」に見えますが、実際には PGO(Profile Guided Optimization)とLTO(Link Time Optimization)を同時に有効にした場合に、GCC自身がクラッシュするケースでした。 ただ、今回はDockerによって問題が隠れやすいという点もきづいたので、あえてDockerを織り交ぜた構成でのPythonソースビルドとGCCクラッシュについて実際に発生した題材をもとに共有させていただこうとおもいます 同様の構成でビルドしている方の参考になれば幸いです TL;DR * Docker内でPythonを --enable-optimizations --with-lto 付きでソースビルドすると GCCが internal compiler error(Segmentati

By Qualiteg プロダクト開発部