タグ: #gpu
GPU・LLM・MLOps・Kubernetes、そしてマインドセット · 70 件
3行の設定ファイルが GPU 4枚を1週間殺した — containerd ドロップイン統合の真実
ノードが GPU を広告しませんでした。設定ファイルには nvidia ランタイムがちゃんと書かれているのに、containerd config dump には存在しませんでした。犯人は1週間前に入れた3行のレジストリ設定で、理由は containerd の imports 統合がフィールド単位ではなくプラグイン単位の丸ごと置き換えだからでした。二度まちがえて診断した過程と、最後に答えをくれた実験をそのまま書きます。
2026-08-26 · 21 分で読めます #kubernetes#containerd#gpu#nvidia#troubleshootingGPU障害診断プレイブック — 層を決めてから降りる
KubernetesでGPUの問題を診断するとき最大の無駄は、順序なくあちこち突くことです。Podがスケジュールされない、Podは起動したのにGPUが見えない、ドライバとツールキットのバージョンがずれている、メモリが足りない、ノードからGPUが消える、これらは別の層の問題であり確認順序が異なります。本記事ではNVIDIA GPU Operatorの公式トラブルシューティングドキュメントとdcgm-exporterリポジトリを根拠に、五つ
2026-08-12 · 13 分で読めます #gpu#kubernetes#troubleshooting#nvidia#gpu-operatorNVIDIA GPU Operator入門 — もともと手で入れていた六つの部品
KubernetesでGPUを使うには、ドライバ、NVIDIA Container Toolkit、デバイスプラグイン、DCGM、GPU Feature Discovery、Node Feature Discoveryをノードごとに手で揃える必要がありました。NVIDIA GPU Operatorはそれらを一つのオペレータにまとめ、ClusterPolicy一つで望ましい状態を管理します。各コンポーネントが実際に何をするのか、Helmチ
2026-08-12 · 10 分で読めます #gpu#kubernetes#gpu-operator#nvidia#dcgmvLLMメトリクス — 何をダッシュボードに載せ何でアラートを張るか
vLLMが公開する時系列は、GPUメトリクスが答えられない問いに答えます。今いくつ実行中でいくつ待機中か、KVキャッシュがどれだけ埋まっているか、最初のトークンまで何秒かかるか、といったことです。本記事ではvLLM公式ドキュメントとリポジトリのメトリクスロガーのソースを直接読み、スケジューラ状態のゲージ、キャッシュ系カウンタ、遅延ヒストグラムの正確な名前と意味を整理し、カウンタ名の接尾辞の違いのようにバージョン間で人をつまずかせる箇所を
2026-08-12 · 12 分で読めます #gpu#kubernetes#vllm#prometheus#observabilityMIGとtime-slicing — GPU一枚を複数で使う二つの方法
GPU一枚に複数のワークロードを載せる方法は大きく二つあります。時間を分けるtime-slicingとハードウェアを分けるMIGですが、名前が似て見えるのとは裏腹に隔離の水準がまったく異なります。本記事ではNVIDIA GPU Operatorの公式ドキュメントを基準に、両方式の設定ファイル構造とノードラベル、広告されるリソース名、対応ハードウェア条件を整理し、time-slicingのレプリカ間にメモリ隔離も障害隔離も無いという事実が
2026-08-12 · 11 分で読めます #gpu#kubernetes#mig#time-slicing#nvidiaDCGM Exporter — GPU利用率はあなたが思っているものではない
DCGM ExporterはGPUテレメトリをPrometheus形式で公開する標準経路ですが、最も多くダッシュボードに載るGPU利用率系のメトリクスは、人々が期待するものを測っていません。本記事ではdcgm-exporterリポジトリの既定カウンタCSV、DCGM公式ドキュメント、NVML APIドキュメントを直接読み、既定で有効なメトリクス一覧、利用率メトリクスが実際に何を意味するのか、併せて見るべきプロファイリングメトリクスは何か
2026-08-12 · 16 分で読めます #gpu#kubernetes#dcgm#prometheus#observabilityGPUサービングのSLOとアラート設計 — 何を約束し何で人を起こすか
GPU推論サービスにSLOを掛けるには、まずどの指標が利用者体験を代弁するかを決める必要があります。最初のトークンまでの遅延とスループットは互いを食い合う関係にあり、片方だけを見て目標を立てると必ずもう一方が崩れます。本記事ではvLLMとDCGM Exporterが実際に公開する時系列だけを使ってSLIを定義する方法、ヒストグラムのバケット境界を閾値にすべき理由、飽和シグナルを読む順序、症状ベースのアラート設計、そしてGPUサービングで
2026-08-12 · 13 分で読めます #gpu#kubernetes#slo#alerting#prometheusデバイスプラグインとGPUスケジューリング — nvidia.com/gpuはどこから来るのか
KubernetesはGPUを知りません。ノードにGPUをリソースとして広告させるのはkubeletに登録されたデバイスプラグインであり、その結果生まれる名前が拡張リソースnvidia.com/gpuです。本記事では、デバイスプラグインが実装すべきgRPCインターフェースと登録ソケットのパス、拡張リソースでrequestsとlimitsが必ず一致しなければならない理由、GPUをCPUのようにミリコアへ分割できない根本的な理由、そしてGP
2026-08-12 · 10 分で読めます #gpu#kubernetes#device-plugin#scheduling#nvidiavLLM 内部構造 (1) — リクエスト一つがトークンになるまでの全経路
vLLMにリクエストが一つ入ってからトークンが出てくるまでの全経路をたどる。APIサーバー、スケジューラ、KVキャッシュマネージャ、ワーカー、サンプラーがそれぞれ何をしているのか、V1書き換え以降プロセスがどう分かれているのかを公式ドキュメントとソースで確認して整理した。vLLM内部構造シリーズ第1回。
2026-08-12 · 9 分で読めます #vllm#llm#inference#gpu#ai-platformvLLM 内部構造 (7) — デプロイのチューニングとよくある落とし穴、OOM の切り分け順
vLLMのデプロイを実際にチューニングする手順を整理する。gpumemoryutilizationが何を決めるのか、テンソル並列とパイプライン並列をいつ使うのか、量子化とKVキャッシュのデータ型をどう選ぶのか、そしてOOMが起きたときに起動段階と運用段階を分けて診断する手順まで、公式ドキュメントを基準に確認して整理した。vLLM内部構造シリーズ最終回。
2026-08-12 · 16 分で読めます #vllm#gpu#quantization#tensor-parallel#llmvLLM 内部構造 (2) — PagedAttention はなぜ KV キャッシュをページに分けたのか
PagedAttentionがKVキャッシュをブロック単位に分割した理由を、原論文(arXiv:2309.06180)とvLLM公式設計ドキュメントで確認して整理した。連続割り当てが生む内部・外部フラグメンテーション、ブロックテーブルが担う役割、ブロックサイズを大きくしたり小さくしたりする際のトレードオフまで扱う。vLLM内部構造シリーズ第2回。
2026-08-12 · 12 分で読めます #vllm#paged-attention#kv-cache#llm#gpuGPUコンパイラとフレームワークの地形図 — グラフからカーネルを作るという一つの問題、層ごとに違う答え
NVCCとPTXからLLVM、MLIR、Triton、torch.compile、XLA、IREE、TVMまでを一枚の地図に載せました。名前も所属も違いますが、これらはすべて同じ問題を解いています。演算グラフを受け取り、実行可能なカーネルを作るという仕事です。各層がその問題のどの部分を切り取ったのか、なぜ層がこれほど増えたのか、そしてエンジニアがどんな状況でどの層まで降りるべきかを整理しました。2026年8月2日に確認したバージョンと公
2026-08-02 · 38 分で読めます #gpu#compiler#mlir#triton#pytorchRay 2.56のラベルロカリティスケジューリング — 配置グループがノードではなくNVLinkラックを見始めた
2026年6月29日に出たRay 2.56.0は、配置グループにドメインレベルのスケジューリング層をアルファとして追加しました。これまでPACKやSTRICTPACKといった配置戦略はすべてノード単位でしか動かず、GB200・GB300 NVL72のようにNVLinkドメインが複数ノードにまたがるラックでは「この配置グループを1つのラックの中に全部入れてくれ」を表現する方法がありませんでした。新しいラベルロカリティスケジューリングは、r
2026-07-17 · 19 分で読めます #ray#gpu#scheduling#distributed-systemsローカルでLLMを動かすにはVRAMがどれだけ必要か — 表ではなく数式で計算する
「8Bモデルには何GB必要ですか」の正解は表ではなく2つの数式です。重みはパラメータ数 × bpw ÷ 8、KVキャッシュは2 × レイヤー数 × KVヘッド数 × headdim × バイト数 × トークン数です。本稿はこの2つの式をllama.cppのソースと公式の表に直接照らして検証します — ggmlのブロック構造体から導いたQ80の8.5 bpwはllama.cppが公表した8.5008と小数第3位まで一致し、同じやり方で逆算
2026-07-17 · 43 分で読めます #llm#quantization#kv-cache#local-llm#gpuTriton Gluon — コンパイラが隠していたレイアウトを手で書く言語
Gluonは、Tritonと同じコンパイラスタックの上に載る下位レベルGPU言語で、Tritonが隠していたレイアウト・共有メモリ・ワープ特殊化をカーネル作成者にそのまま渡します。存在理由は明快です — Tritonコンパイラがうまくコードを出せない場面に出会ったとき、今まで打つ手がなかったからです。本稿ではGluonが何を露出するか、BlockedLayoutが実際に何を意味するか、そして上流のチュートリアルがGB200で記録した測定
2026-07-16 · 32 分で読めます #gpu#triton#kernel#compiler#performanceRust 1.97 が Volta 以前の GPU を切り捨てた — nvptx64 ベースライン引き上げの内幕
Rust 1.97(2026年7月9日)は、nvptx64-nvidia-cuda ターゲットの最小要件を PTX ISA 7.0(CUDA 11 ドライバー以上)と SM 7.0(Volta 以上)に引き上げました。Maxwell・Pascal 世代の GPU と CUDA 10 以下のドライバーは、もはや対象外です。本稿では、実際に変わった数字、コンパイラチームが根拠として挙げた三つの具体的な欠陥(デバッグシンボル・アトミック順序・
2026-07-16 · 21 分で読めます #rust#cuda#gpu#compiler#nvidiaRTX 5090 一枚で小さなモデルたちを直接動かしてみる — microGPT・OCR・音楽生成
RTX 5090（Blackwell、32GB）一枚に SSH で接続し、小さなモデル三つを直接動かしてみました。char-level GPT をゼロから 28 秒で学習させ（10.75M パラメータ、117 万 tokens/s）、専用 OCR（TrOCR）と小型 VLM（Qwen2-VL-2B）を同じ画像に当てて CER で対決させ、MusicGen で 8 秒の音楽を 1.9 秒（実時間の 4.2 倍）で生成しました。その過程で出
2026-07-11 · 12 分で読めます #pytorch#gpu#llm#ocr#hands-onKubeVirt GPU パススルー VM はなぜ112日間スケジュールされなかったのか — 実際のクラスタ剖検
Rust オペレーターが「GPU ノード4台すべて NotReady」という診断を下した後、その死の原因を実際の8ノードクラスタ(GPU Operator v25.3.0、KubeVirt v1.7.0)で最後まで追跡しました。gpu-fedora と rhel9-gpu-vm が112日間 ErrorUnschedulable で止まっていた本当の理由は、華やかな GPU 設定ではなく kubelet の1行のエラー — 「runni
2026-07-11 · 8 分で読めます #kubevirt#gpu#kubernetes#nvidia#devops拡散 LLM が CUDA カーネルを書く — DICE と、なぜ並列生成が効きうるのか
DICE は 2026 年 2 月のプリプリントで、拡散(diffusion)大規模言語モデルが CUDA カーネル生成において同規模の自己回帰(autoregressive)モデルを上回り、新たな最高性能(SOTA)を打ち立てたと主張します。核心は、トークンを左から右へ一つずつ書く代わりに、系列全体を並列に生成し、どの位置でも非逐次的に書き直せることです。大域構造が重要なコードという課題に合いそうな性質です。著者らは CuKe という
2026-07-11 · 12 分で読めます #ai#llm#diffusion#cuda#gpuRustでKubernetes GPUオペレーターを作る — kube-rsで実際のクラスターを診断する
8ノードの実運用ホームラボクラスター（k8s v1.32.5）を相手に、kube-rsを使ってGPUオペレーターをRustで自作して動かしました。GpuInventoryカスタムリソースを定義し、2つのコントローラー（ノードスキャン→CR状態の記録、ノード監視→ConfigMap更新）を1つのバイナリで起動し、クラスターの外で実行しました。そして、オペレーターが実際に吐き出した結果 — GPUノード4個のうちReady 0個、つまりGP
2026-07-11 · 9 分で読めます #rust#kubernetes#operator#gpu#kube-rs