#gpu

Waferは、GLM-5.2をAMDのMI355X GPU上で動かし、かなり高い性能を出した。 しかもポイントは「速い」だけでなく、「Blackwell系より2倍以上安いのに性能効率が高い」こと。 ただし、AMDで最先端LLMをそのまま使うのは簡単ではなく、quantizationやinference frameworkの調整がかなり効いている。 speculative decode という高速化手法のために、ROCm向けの小さな修正も必要だった。 個人的には、ここで見えるのは「GPUの勝負」だけではなく、「ソフトウェアの面倒をどこまで減らせるか」が勝負になってきた、という現実だと思う。 Waferの記事は、タイトルの通りかなりストレートです。要するに「1ドルあたりの性能、まだ伸ばせるし、しかも安くできる」という話です。対象はGLM-5.2というオープン系の大規模言語モデルで、これをAMD MI355X上でかなりうまく動かした、という内容でした。 まず数字が強いです。Waferは、20k input / 1k output、cache hit rate 60% という条件で、1ノードあ

Moondreamのブログ「Popping the GPU Bubble」は、AI推論を速くする話です。 ただし、単に「GPUを強く使えば速くなる」という雑な話ではありません。むしろ逆で、GPUがサボってしまう“すき間時間”をどう消すかに真正面から向き合っています。ここが面白い。 AIの推論では、GPUが大量の計算をして次のトークン（ざっくり言うと、文章のかたまり）を出します。ところが実際には、GPUが計算している時間よりも、CPUが「次は何をやるか」を準備している時間のせいで、GPUが待たされることがあります。これが記事のいう GPU bubble です。風船みたいに膨らんだ無駄な待ち時間、という比喩ですね。 Moondreamはこの待ち時間を、pipelined decoding という方法で減らしています。要するに、 「前のトークンの後片付けをCPUがしているあいだに、GPUは次のトークンの計算をもう始める」 という並行処理です。これだけ聞くと当たり前に見えますが、実際に安全にやるのがかなり難しい。そこでこの記事では、その工夫をかなり丁寧に説明しています。

高性能なLLMを「自分のPCや自宅サーバー」で動かすための、かなり本気の実践メモ集です。 予算ごとに「どこまでできるか」をはっきり書いていて、夢物語ではなく現実の設計図になっています。 4枚のRTX PRO 6000を使った構成は豪快ですが、単なるお金の話ではなく、PCIeスイッチや電力制御まで踏み込んでいるのが渋いです。 speech-to-text（音声→文字起こし）やDockerを使った運用も含まれていて、実験ではなく“使うための環境”として整っているのが強いです。 このリポジトリは、ひと言でいうと「ローカルでLLMをちゃんと使うための、かなり筋の通った設計図」です。 しかも雰囲気がいい。ふわっとした夢の話ではなく、「$2,000ならここまで」「$40,000ならこの景色」という、かなり生々しい金額感で話が進みます。ここがまず面白いところです。 最近のLLMはクラウドで使うのが当たり前になりましたが、ローカルで動かす意味はちゃんとあります。たとえば、外部サービスにデータを投げたくない場面。社内資料や個人メモ、音声データみたいな“出したくない情報”を扱うとき、手元で完結する安心感は

「GPUで計算する」と聞くと、なんだか一瞬で魔法みたいに処理が終わる印象があります。 でも元記事は、その裏側にある泥臭い手順を、かなり執念深く追いかけています。しかも題材は、たった1行のベクター加算。`a[i] + b[i]` を並列に足すだけの、いちばん地味なCUDAプログラムです。地味だからこそ面白い。GPUという巨大な装置が、どれだけの段取りを踏んでこの1行を実行しているのかが、くっきり見えてきます。 `nvcc` は1つのコンパイラではなく、複数のコンパイラをまとめて動かす“司令塔”です CUDAのコードは、まずPTXという中間表現になり、その後SASSというGPU実機向け命令に変わります `vadd<<<4096, 256>>>(...)` のような記法は、ホスト側で引数を詰める「stub」に置き換えられます GPUカーネルの引数は、constant bank 0 に載って読み出されます 実行時には、CPU側のランタイム、`libcuda.so`、ドライバ、PCIe越しのGPUが連携して動きます ただ“GPUに投げた”だけに見える処理の背後で、かなり多くの機械的な準備が走って

AWSが、AI向けGPUの予約料金を約20%引き上げました。しかもこれ、今年2回目です。 地味に見えて、かなり大きい話です。AI業界って、モデルの賢さばかりが話題になりますが、実際には「どれだけGPUを確保できるか」で勝負が決まる場面が多い。そこに値上げが入ると、スタートアップも大企業も、みんな一気に息苦しくなります。 AWSは「EC2 Capacity Blocks for ML」というサービスの価格を、7月から約20%上げました。 これは、NvidiaのGPUをあらかじめ押さえておける仕組みです。長時間の学習やファインチューニングを途中で止めたくない企業にとっては、かなり重要な“席予約”みたいなものです。 面白いのは、今回が初回ではないことです。AWSは1月にも同じ料金を約15%上げていました。半年で15%と20%。単純に足すと35%で、かなりの上げ幅です。もちろん商品や条件が完全に同じとは限りませんが、「AI計算資源の値段がじわじわ上がる局面に入った」と見るのは自然だと思います。 AWSはこの変更を「需要と供給に応じて定期的に調整している」と説明しています。要するに、欲しい人が多

GoogleがSpaceXに、月額9億2000万ドル（約920億円）を支払う契約を結んだ 契約期間は2026年10月〜2029年6月で、約110,000基分のNVIDIA GPUなどの計算資源を使う内容 これはGoogleのAI製品、特にGemini Enterpriseなどへの需要急増に対応するための「つなぎ」の契約だと説明されている SpaceXはGoogleのほかにもAnthropicと大規模契約を結んでおり、AI向け計算資源の巨大市場化が鮮明になっている GoogleとSpaceXは昔からの関係だが、今回はAIインフラ不足という現実がかなり露骨に表れた形だと思う TechCrunchによると、SpaceXはGoogleと、かなり異例の大規模契約を結びました。内容はシンプルに言うと、GoogleがSpaceXの計算資源（compute）を使うために、お金を払うというものです。 金額がすごい。 Googleは2026年10月から2029年6月まで、毎月9億2000万ドルを支払います。日本円感覚だと、毎月920億円前後。

著者はすでにRTX 4080を持っていたが、ローカルLLM用にはVRAM（GPUのメモリ）が足りなかった そこで中古のTesla V100 SXM2 16GBを約£150で購入し、PCIe変換アダプタを約£50で追加 合計約£200で、16GB + 16GB = 32GBのVRAM環境を実現 2枚のGPUにモデルを分散させ、27B規模のLLMを約32 tok/sで動かしている データセンター向けGPUなので冷却ファンが爆音だったが、配線を工夫して静音化に成功 ソフト面ではNixOSがかなり役立ったが、古いGPU対応のためにドライバやCUDAのバージョン調整が必要だった Qwen3.6-27B-MTPは性能面でもかなり強く、ローカル実行でも最新クラウドモデルと比較できるレベルだと著者は述べている この記事、かなり好きです。理由は単純で、「お金をかければ解決する問題」を、中古パーツと少しの工夫でねじ伏せているからです。 著者はもともとRTX 4080を持っていました。16GBのVRAMは、ゲーム用途なら十分です。でも、最近の大きめのLLMをローカルで動かそうとすると、16GBでは足

NVIDIA RTX Sparkは、「Slim Laptops & Small Desktops」向けに打ち出された製品シリーズ キャッチコピーは 「The fusion of NVIDIA AI and RTX graphics」。つまり、AIとRTXグラフィックスの組み合わせが主役 NVIDIAの製品群の中では、RTX AI PCs や NVIDIA RTX PRO などと並ぶ位置づけで紹介されている つまりこれは、単なるGPUの話というより、「薄いノートでも、小さなデスクトップでも、AI時代の作業を快適にしたい」というメッセージだと読める ただし、このページ本文からは具体的なスペックや価格は読み取れない。まずはコンセプト紹介ページとして見るのがよさそう NVIDIAの「RTX Spark」ページは、ぱっと見だと製品名だけでは何のことか少しつかみにくいです。ですが、ページタイトルに 「Slim Laptops & Small Desktops」 とあり、さらに説明文には **「The fusion of NVIDIA AI a

元記事は、Reddit上で「巨大なGPUを深く考えずに借りてみたら、なんだかすごいことをやっている気分になった」という趣旨の投稿です。 GPUは、AIの学習や画像生成、重い計算を高速にこなすための重要な計算資源です。 こうしたGPUをクラウドで借りると、手元のPCでは到底無理な規模の処理ができる一方、コスト感覚がかなり大事になります。 「とりあえず使ってみる」体験は面白いですが、同時にクラウド時代の計算資源の重みを実感させます。 投稿の雰囲気からは、技術の興奮と少しの怖さが同居している感じが伝わってきます。 元記事は、Redditの`r/artificial`に投稿されたもので、タイトルの雰囲気からしてかなり“生っぽい”です。内容をざっくり言うと、大きなGPUを深く考えずに借りてみたら、まるで自分がすごい計算を動かしている人になった気分だった、という話です。 まず、GPUって何かを簡単に言うと、もともとはゲームや画像処理向けに作られた、超並列計算が得意な部品です。今ではAIの世界で大活躍していて、特に大きなモデルの学習や推論（学習済みモデルを使って答えを出すこと）には欠

GPUの matrix multiplication（matmul）は、普通は「入力の値に関係なく同じ速さ」で動くと思いがち ところが実際には、ゼロや同じ値のような“予測しやすいデータ”のほうが速くなることがある 理由は、GPU内部の dynamic/switching power（トランジスタが切り替わるたびに消費される電力） 電力制限に当たると GPU は throttling（性能を落として消費電力を抑える）するので、速さが変わる これは「GPUは計算性能だけでなく、電力との綱引きで速さが決まる」ことをよく示していて、かなり面白い Nvidiaのカタログ上の FLOPS と、実際の持続性能に差が出る理由もここにある この記事の出発点は、かなりシンプルです。 著者の Horace He さんは、GPU向けの高速matmul実装である CUTLASS を試していました。 8192×8192×8192 の大きな行列積をベンチマークすると、最初は CUTLASS が CuBLAS より速いように見えたそうです。これは「お、すごい」と思いますよね。私もここで

分散学習って、速いはずなのに急に遅くなることがあります。しかも厄介なのは、全体が止まって見えるのに、原因は1台だけというパターン。今回紹介する記事は、そんな「見えない犯人」を eBPF と fleet fan-out という仕組みで、4台のGPUノードをまたいで一発で特定したという話です。かなり面白いです。しかも、中央の収集サーバーなしでやっているのが筋がいい。 4ノードの distributed training が遅くなった原因を、1つのSQLクエリで特定 各ノードに入っている eBPFエージェント が、CUDA APIやカーネルイベントを追跡 fleet fan-out により、同じクエリを複数ノードへ並列実行して結果をまとめる 原因は gpu-node-01 の CPU競合。checkpoint の書き込みが training process を邪魔していた 中央集約の collector を置かない設計で、シンプルさを優先 オフライン環境向けに SQLite DB の merge と **

深層学習の高速化は、Compute / Memory / Overhead の3つに分けて考えると整理しやすい GPUを速く使うには、まずどこで時間を食っているかを見極めるのが大事 多くの小さな演算は、計算そのものよりメモリ往復で遅くなる そこで効いてくるのが operator fusion（演算のまとめ実行） 速さは「理論上のFLOPS」だけでは決まらず、データ移動の少なさがかなり効く PyTorchやGPU最適化の話に見えるが、考え方はかなり汎用的 元記事の主張はかなりシンプルです。 深層学習を速くしたいとき、闇雲に「このテクニックが効くらしい」「とりあえず in-place にしよう」みたいな小技を積むのではなく、何に時間を使っているかを第一原理で分解して考えよう、という話です。 ここは個人的にすごく好きなポイントです。 性能チューニングって、経験則が強すぎて魔術っぽく見えがちなんですよね。でも著者はそこに対して、「いや、まずは大きく3分類しようよ」と言ってくる。こういう整理の仕方は、地味だけど本当に強いと思います。 --- 記事で

CODAは、Transformerの一部処理を GEMM + epilogue という形にまとめて実行するGPU kernel abstraction ねらいは、メモリを何度も往復する無駄を減らして、実行効率を上げること 特に normalization、activation、residual update、reduction など、計算量は少ないのにデータ移動が多い処理が対象 GEMM本体の流れは固定し、epilogue側に scaling、reductions、pairwise transformations、accumulation といった小さな部品を組み合わせる設計 標準的なTransformer blockの attention以外の前向き・逆伝播のほぼ全部 をカバーできる、と論文は主張している 人手でもLLMでも書ける設計で、しかも高性能が出るのが面白いところ Transformerと聞くと、みんなまず attention を思い浮かべると思います。実際、巨大なモデルの心臓部です。でもこの論文が面白いのは、**本丸そのものよ

中国当局が、Nvidiaの`RTX 5090D V2`を税関の禁輸リストに加えたと報じられた ちょうどその時期に、Nvidia CEOのJensen Huang氏が中国を訪問していた、というのがなんともドラマチック 背景には、北京が自国のAI企業に国産チップを使わせたいという強い方針がある これは単なる「1製品の規制」ではなく、米中のAI覇権争いの一場面として見るとかなり重要 個人的には、これは「性能」より「政治」と「供給網」がGPUの運命を決める時代を象徴していると思う 中国がNvidiaの`RTX 5090D V2`を禁止した――そんな報道が出ています。しかもタイミングがかなり妙で、NvidiaのCEOであるJensen Huang氏が中国を訪れていた最中の話だとされています。 元記事が引用しているのはFinancial Timesの報道で、中国当局がこのGPUを中国税関の禁輸品リストに追加したという内容です。税関のリストに入る、というのはつまり「持ち込めない」「通せない」ということ。一般の感覚だと少し地味な表現ですが、実際に

著者はFAANG企業を辞め、独立研究者になるために 6枚の RTX 6000 Ada を積んだGPUサーバー「grumbl」を自作した 価格は 約4.8万ドル。かなり高いが、「仕事を早く進められるなら投資になる」という発想で購入 住んでいるのがアパートだったため、電源制約が大きな壁になり、2つの電源を別回路のコンセントに分ける構成にした 自前サーバーの利用率は 平均76%、2025年以降に絞ると 85% 2026/3/13時点の試算では、クラウドで同等の計算資源を借りるより 約1.7万ドル安かった ただし、自分の作業時間・構築や保守の手間はコスト計算に入っていない 結論としては「節約のため」よりも、面白いものを作るための投資だった、というのが著者の本音 GPUサーバーを4.8万ドルで買う、という時点でだいぶ普通ではありません。 でもこの記事の面白さは「豪遊しました」ではなく、自分の働き方そのものを変えた結果として、その投資が合理的だったのかを、かなり真面目に検証しているところです。 しかも著者は「FAANGの仕事を

CUDAを学びたいと思ったとき、まず困るのが「で、どの本を読めばいいの？」問題です。 このGitHubリポジトリ awesome-cuda-books は、その悩みにかなり真っ向から答えてくれる「CUDA本のおすすめ一覧」です。 GPUプログラミングは、普通のC++やPythonとは少し勝手が違います。 CPUが「順番にコツコツ処理する」のが得意なのに対して、GPUは「同時にたくさん処理する」のが得意。 この違いをうまく使えると、画像処理、科学計算、機械学習の一部などで大きな高速化が狙えます。 ただし、学び方を間違えると「用語が多すぎて何が何だか…」となりがち。そこを本リストが助けてくれます。 CUDA学習向けの本を、初心者〜上級者まで段階別に整理している C++中心の本だけでなく、Python向けのCUDA本も載っている 「理論」だけでなく、実践・最適化・デバッグ寄りの本もある 2022〜2026年の比較的新しい本も拾っていて、古い情報だけに偏っていない ただし、CUDAは変化が速いので、本だけで完結しないのが重要 公式のCUDA C++ Programming Gu