GPUリッチと日本の現状

GPUリッチと日本の現状
NVIDIA H100

世界的なGPU不足が深刻化しており、特に高性能なグラフィックスプロセッシングユニット(GPU)の確保が困難な状況に直面しています。この不足は、AI研究開発をはじめとする多くのテクノロジー業界に大きな影響を及ぼしており、企業や研究機関の間で新たな競争が生まれています。

GPU不足の現状

「GPUが非常に不足しているため、当社の製品を使用する人が少ないほど良いです」「GPUが不足しているため、当社の製品の使用量が減ってくれると嬉しいです」との声が業界内で聞かれるほど、GPUの調達は困難を極めています。

イーロン・マスクは、GPUの入手困難さを「麻薬よりも取得が難しい」と形容しています。

米国のビッグテックやメガベンチャーでは、GPUを万単位で確保しており、一例として1万台のGPUを確保するには約600億円の投資が必要とされています。これらの企業は、「GPUリッチ」と呼ばれるほどに、NVIDIAのA100やH100などの高性能GPUを大量に所有しています。

man in black framed sunglasses holding fan of white and gray striped cards

GPUリッチの影響

このGPUリッチな環境は、米国内でのAI研究開発競争を加速させています。ベイエリアのトップAI研究者たちは、GPUへのアクセスを自慢し、それが彼らの職場選びに大きな影響を与え始めています。Metaなどの企業は、採用戦術としてGPUリソースを活用しており、豊富な資金力により高性能のGPUを大量に確保し、競争に勝ちに行く戦略を取っています。

日本の状況

一方、日本では、国策とも言える産業技術総合研究所(産総研)のABCI(AI Bridging Cloud Infrastructure)でさえ、新モデルのH100は保有している気配は無く、旧式のGPUしか保有できていない状態です。このような状況は、日本が国際競争において不利な立場に立たされていることを示しており、どう頑張っても、小粒な日本語LLMしか作れない可能性があります。

(そもそも、日本語の言語リソースが英語のそれよりもずっと少ないという課題もあります)

日本の戦い方

日本がこのGPUリッチな環境においてどのように競争していくべきかは、重要な課題となっています。私たちは日本の企業や研究機関は、限られたリソースの中で、高度に最適化されたアルゴリズム、効率的なデータ処理、そして創造的な問題解決戦略を発見していくことと信じています。また当社のようなLLMプラットフォーム企業をハブとして活用していただくことで、相互のパートナーシップが生まれ、新しい技術の開発において力を結集することができるのではないでしょうか。そのためのネットワーキングの支援、事例共有なども積極的に行っていきたいとおもいます。つまり、米国が力で戦っているのにたいして、日本は技と技の結集で戦うというわけです。

LLMスタートアップには依然厳しい

その「技」を担う重要なプレイヤーとして、LLMを研究しているベンチャー・スタートアップという存在を忘れてはいけないでしょう。

彼らはさらに深刻で、GPU Poor ともいえるべき状況ではないでしょうか。たとえば、NVIDIA A100(80GB)は1台300万円、H100(80GB)は600万円以上します。 大学発スタートアップなどがエクイティ調達しようとすると例えばシード期 Post Valuation で数億円。実際の調達額はせいぜい数千万円となり、いまの日本のスタートアップエコシステムでの調達額では、高性能GPUを数枚買ったら枯渇してしまいます。

a close up of a sign in the dark

この業界は、とにかく GPUありきなので、従来のAASのように小さく生んで大きく育てられるビジネスモデルとコスト構造が決定的に違いますが、なかなかそれを説明して正しく理解していただくのは難しいという話を聞きます。また、仮に数億円調達できても、数億円程度ではとても”大規模な”LLMをトレーニングすることはできません。GPUクラウド環境も割高で、そもそも、学習をまわしてもうまくいく保証はないので何百万円かけてトレーニングしても成果無しということもよく起こり、なかなか厳しい状況です。このままでは運よくスポンサーをみつけたスタートアップや大企業にM&Aされたスタートアップ以外は打席に立つ前に淘汰されてしまうとおもいます。それが競争といえば競争かもしれませんが、せめて打席に立つ(GPU資源は気軽に使える)チャンスが必要でしょう。AWS による支援プログラムなど太っ腹な救済策?もはじまっていますが、より多くの挑戦者が打席に立つためには、豊富なGPU資源に”気軽に”アクセスできる環境が必要であり、「GPU使用無償化」の国策に期待したいところであります。これはまったく他人事ではなく、私たちもトレーニングほどの資源は使用しないものの、推論環境に必要な GPU資源 の確保に苦慮しており、心を同じくしております。

All you all need is GPU! (^_-)


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 プロダクト開発部