GPU
Ubuntuの自動更新でカーネルだけ上がり、再起動したらGPUが消えた。NVIDIAモジュールが置き去りになる原因と3つの対策
Ubuntu 24.04のGPUサーバーを再起動したらnvidia-smiが動かない。原因はunattended-upgradesがカーネルだけを更新し、NVIDIAモジュールが依存関係の都合で見送られていたこと。ログで原因を突き止め、1コマンドで復旧し、apt-mark holdを含む3つの再発防止策を比べて採用した記録。
GPU
GPU
「Blackwell」は 1 つではなかった。NVIDIA の Compute Capability 番号のわかりにくさを整理する
こんにちは！ NVIDIA の GPU を扱っていると、sm_120 や sm_100 といった番号を見かけます。Compute Capability と呼ばれる番号です。 この番号、製品の世代名と対応しているように見えて、実はずれています。 きっかけは、2026年9月23日に公開された TensorRT-LLM の v1.3.0rc28 でした。リリースノートに「SM107」という記述があります。次世代の Rubin に対応した、という文脈です。 ここで引っかかります。Blackwell の GeForce は sm_120 です。次の世代の Rubin が、なぜ 107 という小さい番号なのでしょうか。 調べてみると、引っかかりの原因は Rubin ではありませんでした。
GPU
TensorRT 10 × Blackwell 移行ガイド【後編】5D grid_sample をカスタムプラグインで通す
こんにちは！ 「TensorRT 10 × Blackwell 移行ガイド」シリーズもいよいよ最終回です。前編では TensorRT 化の基本と「5D（volumetric）の grid_sample はビルドが拒否される」という壁を、中編では「ビルドが通っても正しいとは限らない」沈黙劣化の数々を扱いました。 回テーマ 前編（Part 1）RTX 50 で推論資産が動かない — 基本と最初の壁 中編（Part 2）ビルドが通っても正しいとは限らない — 沈黙劣化 5 連発 後編（Part 3）5D grid_sample をカスタムプラグインで通す（本記事） 後編は、前編で保留にした最大の宿題に挑みます。TensorRT がネイティブに対応していない 5D grid_sample を、
GPU
TensorRT 10 × Blackwell 移行ガイド【中編】ビルドが通っても正しいとは限らない — 沈黙劣化 5 連発
こんにちは！ 前回の記事「TensorRT 10 × Blackwell 移行ガイド【前編】RTX 50 で推論資産が動かない — 基本と最初の壁」では、Blackwell 世代への移行で既存の推論資産が動かなくなる理由と、TensorRT 10 化を最小構成で通す手順を扱いました。前編で出てきた問題には、実はひとつ共通点があります。 すべて、エラーで止まってくれたということです。 回テーマ 前編（Part 1）RTX 50 で推論資産が動かない — 基本と最初の壁 中編（Part 2）ビルドが通っても正しいとは限らない — 沈黙劣化 5 連発（本記事） 後編（Part 3）5D grid_sample をカスタムプラグインで通す 本当に怖いのはその先です。TensorRT への移行パイプラインには、 * ビルドが通る * 実行も通る * 速度もちゃんと出る
GPU
TensorRT 10 × Blackwell 移行ガイド【前編】RTX 50 で推論資産が動かない — 基本と最初の壁
こんにちは！ 新しい GPU を手に入れてワクワクしながら既存の推論環境を載せ替えたら、 昨日まで普通に動いていたものが軒並みエラーで止まった そんな経験はないでしょうか。NVIDIA RTX 50 系、NVIDIA RTX PRO 系（Blackwell 世代）への移行では、これがかなりの高確率で起きます。 そして厄介なことに、エラーで止まってくれるのは、まだ親切なほうで、、TensorRT の世界には 「ビルドは通る、実行も通る、速度もちゃんと出る、けれど出力だけが静かに壊れている」 という、いちばん見つけにくい失敗の仕方が存在します。 本記事はその全体像を扱うシリーズの前編です。 回テーマ 前編（Part 1）RTX 50 で推論資産が動かない — 基本と最初の壁（本記事） 中編（Part 2）ビルドが通っても正しいとは限らない — 沈黙劣化 5 連発 後編（Part 3）5D
GPU
NCCL error: unhandled cuda error が出たら ─ WSL2 + マルチGPU + vLLM で詰まった話
こんにちは! Qualitegプロダクト開発部です！ 今日は、Windows + WSL2 のマシンに RTX 4090 を2枚挿して、大規模なオープンモデルを vLLM で動かそうとしたら、NCCL の初期化で見事に詰まった話を書きます。 世の中に断片的にしか情報がなく、抜けるまでにかなり粘ったので、同じ構成で消耗している方の時間を少しでも節約できれば嬉しいです。 経緯 今回の目的は、次々と登場する最新のオープンモデル（オープンウェイトのLLM）を、手元で評価することでした。 オープンモデルは数週間単位で新しいものが出てきます。ベンチマークの数字だけでなく、自分たちのユースケースに対して実際にどう振る舞うのか——出力の質、速度、量子化したときの劣化具合、エージェント的なタスクの得手不得手——を、手を動かして確かめています 今回の環境は Windows + WSL2(Ubuntu) に RTX 4090 を2枚(各24GB)挿したマシンです。 nvidia-smi 上の CUDA Version は 12.8。 動かすのは大規模オープンモデルを
GPUマシン自作
2026年 NVIDIA GPU 一発検索ツール【2026/9/25情報更新】
NVIDIA GPU 一覧検索 シリーズ すべて SM_107 (Rubin) SM_121 (Blackwell) SM_110 (Blackwell) SM_120 (Blackwell) SM_103 (Blackwell Ultra) SM_100 (Blackwell) SM_90 (Hopper) SM_89 (Ada Lovelace) SM_86/SM_87 (Ampere) SM_80 (Ampere) SM_75 (Turing) SM_70/SM_72 (Volta) SM_60/SM_
AI-Business
「AIを作る国」から「AIで勝つ国」へ ── 日本のAI投資戦略を再設計する【後編】
── SaaS再編の時代に、どこにポジションを取るか こんにちは！ Qualitegコンサルティングです！ ここ数年、「日本のAI戦略」というテーマでの相談やディスカッションが増えてきました。 生成AIの登場以降、経営層から現場のエンジニアまで、それぞれの立場で「自社はどこに張ればいいのか」「国としてはどう進むべきか」を模索している、というのが実感です。 本シリーズでは、その問いに対して少し腰を据えて向き合ってみたいと思い、前後編の構成で書いてみました。 前編では、国産LLM、データセンター投資、データ主権の3テーマを通じて、日本のAI投資が必ずしも「使われて勝つ構造」に向かっていない可能性を見てきました。投資の総額やプレイヤーの動きを並べてみると、号令の方向と実際の資金の流れにはちょっとしたズレがあるのではないか、という現在地が見えてきます。 後編では、その前提の上で視点をソフトウェア産業全体に広げます。もしAIによってアプリケーション層そのものの競争ルールが変わるなら、日本が張るべき場所もまた変わるはずです。海外で起きているSaaS産業の地殻変動を眺めたうえで、日本がど
LLM
日本語対応 LLMランキング2026 ～ベンチマーク分析レポート～（3月6日版）
はじめに 本レポートは、Nejumi Leaderboard 4のベンチマークデータ（2026/3/6版）に基づいて、日本語対応LLMの性能を総合的に分析したものです。 前回は 2025/12/18 版の分析レポート を公開しましたが、約3か月でまたもや大きな変動がありました！ （定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です） Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。 本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。 オープンソースモデルについて Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、モデルによっては「オープンソース」と呼ぶには不十分な場合があるため本稿では、「オープンソースモデル」ではなく「オープンモデル」と表現しています。 ベンチマーク分析について 本レポートは
生成AI最前線
AIプラットフォーマーの垂直統合と、残された戦略オプション
こんにちは！ Qualitegコンサルティングチームです！ 2026年現在、LLMの最大のユースケースの一つはコーディングだと考えています。実際、Menlo Venturesの調査でもコーディングはエンタープライズAI活用の代表的ユースケースとして位置づけられています。 そして、それにきづいたAIプラットフォーマー各社は自前のAIコーディングツールを次々と発表し人気を博しています。 逆にいえば、そのユースケースを早期に発見しプロダクト化してきた"コーディングSaaS"の開発企業は「胴元」であるAIプラットフォーマーが自分たちのSaaS領域に進出してきているわけで気が気でないでしょう。 ということで、本日はAIプラットフォーマーによる垂直統合と、私たちの取りうる戦略オプションについて考えてみたいと思います。 さて、2025年は、AIコーディングエージェント市場の勢力図が決定的に書き換えられた年でした。 Anthropicの「Claude Code」は2025年2月のリサーチプレビューから始まり、わずか半年で年換算ランレート（ARR）10億ドルに到達。 2026年初頭のア
LLM
KVキャッシュのオフロード戦略とGQAの実践的理解
こんにちは！ LLM推論基盤プロビジョニング講座、今回は番外編をお届けします！ 第3回「使用モデルの推論時消費メモリ見積もり」では、GPUメモリ消費の二大要素としてモデルのフットプリントとKVキャッシュを紹介し、1トークンあたりのKVキャッシュサイズの計算方法を解説しました。 また第4回「推論エンジンの選定」ではvLLMやDeepSpeedなど各推論エンジンの特性を比較し、第5回では量子化や並列化による最適化戦略を解説してきました。 しかし、実はKVキャッシュにはまだまだ掘り下げるべきトピックがあります。 * KVキャッシュをGPUのVRAMからCPU RAMやディスクにオフロードしたらどうなるのか？ どのくらい遅くなるのか？ * HuggingFace TransformersとvLLMでは、KVキャッシュの管理方針がなぜ根本的に異なるのか？ * そもそもKVキャッシュが大きくなる原因であるアテンション構造を変えてしまう GQA（Grouped-Query Attention）とは何か？ 第5回で紹介した量子化とは別の軸で、KVキャッシュを劇的に小さくする技術です。
AI-Business
「AIを作る国」から「AIで勝つ国」へ ── 日本のAI投資戦略を再設計する【前編】── 国産LLM・データセンター・データ主権の現在地を検証する
こんにちは! 2025年から2026年にかけて、日本のAI関連投資が急速に動いています。 国産LLMの開発、データセンターの建設ラッシュ、政府による支援策の拡充。「日本もAIで遅れを取るわけにはいかない」という危機感が、はっきりと数字に表れています。 この動き自体は歓迎すべきことですし、何もしないよりずっといい。 ただ、日々 AI活用の現場に立ち会っている中で、ちょっとした違和感を覚えることがあります。 予算は動いている。 意思もある。 でも、この方向で大丈夫なんだろうか、と。 もちろん未来のことは誰にもわかりません。 ただ、公開されているデータを並べてみると、少なくとも「ちょっと立ち止まって考えてみてもいいんじゃないか」と思える材料がいくつか見えてきます。 本稿では前後編に分けて、その材料を整理してみます。 前編では国産LLM、データセンター投資、データ主権の3テーマ。 後編では「SaaS is Dead」の構造変化と、この環境下でどういうポジションの取り方がありえるかを考えます。 第1章：国産LLMの現在地 ── 規模の話をしよう 国内の大手通信事業
LLM
LLM学習の現実：GPU選びから学習コストまで徹底解説
こんにちは！ なぜOpenAIやAnthropicは世界最高水準のLLMを作れるのに、それに肩を並べる日本発のLLMは存在しないのでしょうか？ 技術力の差でしょうか。それとも人材の問題でしょうか。 答えはもっとシンプルです。GPUの枚数とお金です。 今日はそんな 「LLMの学習」にフォーカスをあて、そのリアルについて徹底解説いたします！ 1. はじめに 「LLMを自分で学習させてみたい」 そう思ったとき、最初にぶつかる壁がGPUの問題です。 どのGPUを何枚使えばいいのか。クラウドで借りるべきか、オンプレで買うべきか。そもそも個人や小規模チームでLLM学習は現実的なのか。 本記事では、こうした疑問に対して、具体的な数字と事例を交えながら答えていきます。 たとえばLLaMA 2の学習にはA100が2,048枚使われました。DeepSeek-V3は約8億円かかりました。では、あなたの手元のGPUでは何ができるのか。そこを明らかにしていきたいと思います。 対象読者は、LLM学習に興味があるエンジニアや研究者です。PyTorchでモデルを書いたことがある程度の知識を前提とし
日々の開発Tips
GPUを使った分散処理で見落としがちなCPUボトルネックとtasksetによる解決法
こんにちは！ 複数枚のGPUをつかった並列処理システムを設計しているときCPUについてはあまり考えないでシステムを設計してしまうことがあります。 「機械学習システムの主役はGPUなんだから、CPUなんて、あんまり気にしなくてよいのでは」 いいえ、そうでもないんです。 推論中のあるタイミングに急に動作が遅くなったりするときCPUが原因であることがけっこうあります。 概要（5分で分かる要点） 先日GPUを使った並列処理システムで、予期しないCPUボトルネックが発生し、パフォーマンスが大幅に低下する問題に遭遇しました。 複数のプロセスが異なるGPUを使用しているにも関わらず、処理が極端に遅くなる現象の原因は、処理パイプラインの一部に含まれるCPU集約的な計算処理でした。 問題の症状 * 単一プロセス実行時：正常な速度 * 複数プロセス並列実行時：処理時間が数倍に増加 * GPUリソースに競合なし（nvidia-smiで確認済み） 根本原因 処理パイプラインにGPUに適さないCPU集約的な計算（データ前処理、統計変換など）が含まれており、複数プロセスが同じCP
生成AI最前線
発話音声からリアルなリップシンクを生成する技術 第5回(後編)：Transformerの実装と実践的な技術選択
なぜGPTで成功したTransformerが、リップシンクでは簡単に使えないのか？データ量・計算量・過学習という3つの課題を深掘りし、LSTMとTransformerの実践的な使い分け方を解説。さらに転移学習という第三の選択肢まで、CEATEC 2025で見せた「アバター」の舞台裏を、クオ先生とマナブ君の対話でわかりやすく紐解きます。
日々の開発Tips
その処理、GPUじゃなくて勝手にCPUで実行されてるかも ～ONNX RuntimeのcuDNN 警告と対策～
こんにちは！ 本日は、ONNX RuntimeでGPU推論時の「libcudnn.so.9: cannot open shared object file」エラーの解決方法についての内容となります。 ONNX Runtimeを使用してGPU推論を行う際、CUDAプロバイダの初期化エラーに遭遇することがありますので、このエラーの原因と解決方法を解説いたします。 エラーメッセージの詳細 [E:onnxruntime:Default, provider_bridge_ort.cc:2195 TryGetProviderInfo_CUDA] /onnxruntime_src/onnxruntime/core/session/provider_bridge_ort.cc:1778 onnxruntime::Provider& onnxruntime::ProviderLibrary::Get() [ONNXRuntimeError] : 1 : FAIL : Failed to load