[{"data":1,"prerenderedAt":487},["ShallowReactive",2],{"blog-ja-k3s-edge-ai-inference-fractional-gpu-time-slicing":3,"blog-related-ja-k3s-edge-ai-inference-fractional-gpu-time-slicing":427,"blog-ja-k3s-edge-ai-inference-fractional-gpu-time-slicing-alt":415},{"id":4,"title":5,"author":6,"body":7,"date":409,"description":410,"extension":411,"image":412,"locale":413,"meta":414,"navigation":415,"path":416,"seo":417,"stem":418,"tags":419,"__hash__":426},"blog\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing.md","K3sでエッジAI推論基盤を組んだら、1台のGPUに2つのモデルを乗せられなかった。fractional GPUという壁","Kubo Team",{"type":8,"value":9,"toc":401},"minimark",[10,15,23,31,39,50,53,57,63,66,79,85,92,101,106,109,113,119,136,179,199,206,210,216,219,228,233,244,253,258,261,265,271,280,306,309,333,342,345,349,355,358,361,372,375,388,397],[11,12,14],"h2",{"id":13},"_1-1台のjetsonに2つ目の推論モデルを乗せようとしたらpodがスケジュールされなかった","1. 1台のJetsonに2つ目の推論モデルを乗せようとしたら、Podがスケジュールされなかった",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Fsection01.webp",[16,24,25,26,30],{},"K3sでエッジAI推論基盤を組んでいる現場でよく起きる話がある。1台のエッジノードに画像認識モデルをデプロイして無事に動いた。次に、同じノードにもう1つ別の推論モデルを追加でデプロイしようとしたところ、新しいPodが",[27,28,29],"code",{},"Pending","のまま動かなくなった。",[16,32,33,34,38],{},"ノードのリソースを確認すると、CPUにもメモリにも余裕はある。それなのにスケジューラは「GPUが足りない」と判断して新しいPodを配置できない。これは設定ミスではなく、",[35,36,37],"strong",{},"Kubernetesの標準的なGPUリソース管理の仕様そのものが原因","だ。",[16,40,41,42,49],{},"標準Kubernetesであれ、K3sであれ、この制約は同じ土俵の上にある。むしろK3sのような軽量ディストリビューションでエッジに1ノード1GPUの構成を組むときほど、この壁に真っ先にぶつかる。K3sはサーバーで2GB、エージェントで512MBという最小要件で動作し(",[43,44,48],"a",{"href":45,"rel":46},"https:\u002F\u002Fdocs.k3s.io\u002Finstallation\u002Frequirements",[47],"nofollow","K3s公式ドキュメント",")、シングルバイナリで素早く展開できる軽量さが魅力だが、その省リソース性と、GPUというハードウェア資源の扱いにくさは別の問題として向き合う必要がある。",[16,51,52],{},"本記事では、なぜこの壁にぶつかるのか、Kubernetesの設計思想から掘り下げ、K3s環境でエッジAI推論基盤を組む際にどう回避すべきかを解説する。",[11,54,56],{"id":55},"_2-原因はkubernetesの設計思想gpuは割当の有無だけを見ていて使用率を見ていない","2. 原因はKubernetesの設計思想。GPUは「割当の有無」だけを見ていて「使用率」を見ていない",[16,58,59],{},[19,60],{"alt":61,"src":62},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Fsection02.webp",[16,64,65],{},"まず理解すべきは、KubernetesがGPUをCPUやメモリとは根本的に異なる扱いをしているという事実だ。",[16,67,68,69,72,73,78],{},"CPUやメモリはLinuxカーネルのcgroupsによって細かく制御できる。",[27,70,71],{},"500m","(0.5コア)のような小数単位のリクエストが可能で、使われていない分は他のPodに融通される。しかしGPUは事情が違う。",[43,74,77],{"href":75,"rel":76},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fextended-resource-node\u002F",[47],"Kubernetes公式ドキュメント","ははっきりとこう定義している。",[80,81,82],"blockquote",{},[16,83,84],{},"Extended resources must be advertised in integer amounts. For example, a Node can advertise four dongles, but not 4.5 dongles.",[16,86,87,88,91],{},"GPUはKubernetesにおいて「拡張リソース(Extended Resource)」として扱われ、",[35,89,90],{},"整数単位でしか広告・割当ができない","。0.5個のGPUをリクエストすることはできず、1個の物理GPU全体を占有するか、まったく使わないかの二択になる。",[16,93,94,95,100],{},"この背景には、GPUがcgroupsの管理対象外であるという技術的な事情がある。",[43,96,99],{"href":97,"rel":98},"https:\u002F\u002Fscaleops.com\u002Fblog\u002Fgpus-in-kubernetes-how-it-actually-works-under-the-hood\u002F",[47],"ScaleOpsの解説","によれば、CPUやメモリはカーネルプリミティブでメータリング・制限できるのに対し、GPUは「opaque(不透明)」で、NVIDIAドライバが独立して制御する領域だという。そのため、Kubernetesのスケジューラから見えるのは「GPUが割り当てられているかどうか」だけであり、",[80,102,103],{},[16,104,105],{},"The resource count tracks allocation, not use.",[16,107,108],{},"実際の使用率はまったく見えない。GPU使用率0%のPodも99%のPodも、スケジューラにとっては同じ「GPU 1個を占有している」状態として扱われる。これが、1台のGPUに2つ目の推論モデルを素直に同居させられない根本原因だ。",[11,110,112],{"id":111},"_3-nvidia-device-pluginとtime-slicingの仕組み1個のgpuを見かけ上複数に増やす","3. NVIDIA device pluginとtime-slicingの仕組み。1個のGPUを「見かけ上」複数に増やす",[16,114,115],{},[19,116],{"alt":117,"src":118},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Fsection03.webp",[16,120,121,122,125,126,131,132,135],{},"そもそもKubernetesは、GPUの存在すら標準では認識できない。GPUをPodに割り当てられるようにするには、",[35,123,124],{},"NVIDIA device plugin","をDaemonSetとして各ノードにデプロイする必要がある。",[43,127,130],{"href":128,"rel":129},"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fk8s-device-plugin",[47],"NVIDIA公式のdevice pluginリポジトリ","によれば、このプラグインは各ノードのGPU数を自動検出し、",[27,133,134],{},"nvidia.com\u002Fgpu","というリソース名でkubeletに登録する。Pod側は以下のようにリソースを要求する。",[137,138,143],"pre",{"className":139,"code":140,"language":141,"meta":142,"style":142},"language-yaml shiki shiki-themes tokyo-night","resources:\n  limits:\n    nvidia.com\u002Fgpu: 1\n","yaml","",[27,144,145,158,166],{"__ignoreMap":142},[146,147,150,154],"span",{"class":148,"line":149},"line",1,[146,151,153],{"class":152},"s0U2E","resources",[146,155,157],{"class":156},"sAklC",":\n",[146,159,161,164],{"class":148,"line":160},2,[146,162,163],{"class":152},"  limits",[146,165,157],{"class":156},[146,167,169,172,175],{"class":148,"line":168},3,[146,170,171],{"class":152},"    nvidia.com\u002Fgpu",[146,173,174],{"class":156},":",[146,176,178],{"class":177},"sOJ5S"," 1\n",[16,180,181,182,185,186,191,192,195,196,198],{},"ここで効いてくるのが",[35,183,184],{},"time-slicing","という仕組みだ。",[43,187,190],{"href":188,"rel":189},"https:\u002F\u002Fdocs.nvidia.com\u002Fdatacenter\u002Fcloud-native\u002Fgpu-operator\u002F26.3\u002Fgpu-sharing.html",[47],"NVIDIA公式ドキュメント","によると、time-slicingはConfigMapで",[27,193,194],{},"resources.replicas","を指定することで、1個の物理GPUを複数の「レプリカ」として広告できる。たとえば1GPUに4レプリカを設定すれば、物理GPUが2個のノードでは計8個の",[27,197,134],{},"リソースが広告される計算になる。これにより、Kubernetesのスケジューラから見ると「GPUが8個ある」ように見え、1つの物理GPUに複数のPodを同居させられるようになる。",[16,200,201,202,205],{},"ただし注意点もある。同ドキュメントは「複数のtime-sliced GPUへのリクエストは、GPU計算パワーの比例配分を保証しない」とも明記している。time-slicingはあくまで",[35,203,204],{},"時分割でワークロードを多重化","しているだけで、各Podが同時にフルパワーを使えるわけではない。推論のレイテンシが読める形でSLAに関わる場合は、この性質を踏まえた設計が必要になる。",[11,207,209],{"id":208},"_4-エッジ特有の罠-migが使えないjetsonは統合メモリ","4. エッジ特有の罠: MIGが使えない、Jetsonは統合メモリ",[16,211,212],{},[19,213],{"alt":214,"src":215},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Fsection04.webp",[16,217,218],{},"GPU共有の選択肢として、time-slicingのほかに**MIG(Multi-Instance GPU)**というハードウェアレベルの隔離機能もある。MIGを使えば、物理GPUを複数の独立した区画に分割し、メモリもフォルト(障害)も完全に隔離できる。",[16,220,221,222,227],{},"しかしMIGには大きな制約がある。",[43,223,226],{"href":224,"rel":225},"https:\u002F\u002Fwww.vcluster.com\u002Fblog\u002Fdiy-gpu-sharing-in-kubernetes",[47],"vClusterの解説","によれば、",[80,229,230],{},[16,231,232],{},"MIG's only supported on select NVIDIA GPUs, starting from the Ampere generation introduced in 2020.",[16,234,235,236,239,240,243],{},"MIGが使えるのは2020年以降のAmpere世代以降の、",[35,237,238],{},"データセンター向け高性能GPU","に限られる。NVIDIA Jetsonのようなエッジ向けSoC(System on Chip)はこの対象外だ。つまりエッジ環境では、GPUを共有する手段は事実上",[35,241,242],{},"time-slicingしかない","。time-slicingはメモリもフォルトも隔離されないため、1つのPodが暴走すれば同居する他のPodの推論にも影響しうる。この信頼性の差を理解せずにエッジで複数モデル同居を設計すると、本番障害時に原因切り分けができなくなるリスクがある。",[16,245,246,247,252],{},"さらにJetsonのようなエッジデバイスには、もう1つの構造的な違いがある。データセンターのGPUサーバーでは、CPUのメモリとGPUのVRAM(ビデオメモリ)は物理的に独立しており、PCIe経由でテンソルをコピーする。一方",[43,248,251],{"href":249,"rel":250},"https:\u002F\u002Fiotdigitaltwinplm.com\u002Fnvidia-jetson-k3s-edge-ai-cluster-tutorial-2026\u002F",[47],"iotdigitaltwinplmの解説","によれば、Jetsonは**統合メモリ(Unified Memory)**アーキテクチャを採用しており、CPUとGPUが同じメモリプールを共有する。",[80,254,255],{},[16,256,257],{},"Size your inference pod's memory request against the whole board, not against an imaginary separate GPU.",[16,259,260],{},"つまり、「GPUに80GBのVRAMがあるから大丈夫」という発想のクラウドGPUサーバー前提のリソース設計は、Jetsonではそのまま通用しない。モデル・アクティベーション・OS・K3s自体が1つのメモリプールを取り合う構造になっているため、ボード全体のメモリに対してPodのリソースをサイジングしなければ、簡単にメモリ不足を引き起こす。",[11,262,264],{"id":263},"_5-k3sでの実装-time-slicing設定とリソース指定の具体例","5. K3sでの実装: time-slicing設定とリソース指定の具体例",[16,266,267],{},[19,268],{"alt":269,"src":270},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Fsection05.webp",[16,272,273,274,279],{},"K3sでエッジAI推論基盤を構築する際、",[43,275,278],{"href":276,"rel":277},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-03-20-k3s-edge-ai-ml\u002Fview",[47],"oneuptimeの実践ガイド","を参考にすると、以下の設定が最低限必要になる。",[281,282,283,290,300],"ul",{},[284,285,286,289],"li",{},[35,287,288],{},"runtimeClassName: nvidia"," の指定 — containerdがNVIDIAランタイムをデフォルトで使うよう、テンプレート化された設定が必要",[284,291,292,295,296,299],{},[35,293,294],{},"nodeSelector"," でGPUノードを明示指定(例: ",[27,297,298],{},"ai-capable: \"true\"",") — CPUノードに誤ってスケジュールされるのを防ぐ",[284,301,302,305],{},[35,303,304],{},"メモリのrequest\u002Flimitを現実的な値に"," — 同ガイドの例ではrequest 2〜3Gi、limit 4〜6Giという具体的な範囲が示されている。これをボード全体のメモリに対して余裕を持って設定する",[16,307,308],{},"GPUスケジューリングが期待通りに動かないときの典型的な失敗パターンは3つある。",[310,311,312,321,327],"ol",{},[284,313,314,317,318,320],{},[35,315,316],{},"device plugin未導入",": Podが",[27,319,29],{},"のまま。リソース不足エラーが出る",[284,322,323,326],{},[35,324,325],{},"誤ったruntime設定",": Podはスケジュールされるが、CUDAにアクセスできずCPUで実行される。性能が静かに劣化するため、ログだけでは気づきにくい",[284,328,329,332],{},[35,330,331],{},"RuntimeClassの欠如",": リソースは割り当てられているのに、GPUデバイスがコンテナにマウントされない",[16,334,335,336,341],{},"これらはいずれも「Podは動いているように見えるのに、実際には性能が出ていない」という形で現れるため、推論のレイテンシやスループットを監視する仕組みとセットで運用することが欠かせない。GPUノードがどのPodにどれだけ割り当てられているかをダッシュボードで可視化できれば、こうしたサイレントな性能劣化にも早く気づける。",[43,337,340],{"href":338,"rel":339},"https:\u002F\u002Fkubo.hexabase.io\u002F",[47],"Kubo","のCaptain UIは、こうしたクラスタのリソース割当状況をブラックボックスにせず確認できる管理画面を備えている。",[16,343,344],{},"複数モデルを同居させたい場合は、NVIDIA GPU OperatorのConfigMapでtime-slicingのreplicas数を設定し、各推論ワークロードのレイテンシ要件がtime-slicingの「比例配分を保証しない」特性と両立できるかを事前に検証しておくべきだ。SLAが厳しい推論と、バッチ的に処理できる推論を同じGPUに同居させない、といった切り分けも現実的な選択肢になる。",[11,346,348],{"id":347},"_6-まとめ-エッジai推論でk3sを選ぶならgpu共有の限界を前提に設計する","6. まとめ: エッジAI推論でK3sを選ぶなら、GPU共有の限界を前提に設計する",[16,350,351],{},[19,352],{"alt":353,"src":354},"section06","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Fsection06.webp",[16,356,357],{},"K3sはサーバー2GB・エージェント512MBという最小要件で動く軽量さが魅力で、エッジへのKubernetes展開を現実的にしてきた。しかし、GPUという物理リソースの制約はディストリビューションを問わずKubernetes共通の仕様であり、K3sだからといって回避できるわけではない。",[16,359,360],{},"整理すると、エッジAI推論基盤の設計で押さえるべきポイントは次の3つだ。",[281,362,363,366,369],{},[284,364,365],{},"GPUは整数単位・request=limit固定で、fractional(小数)割当は標準では不可能",[284,367,368],{},"複数モデルを1GPUに同居させるにはtime-slicingが必要だが、メモリもフォルトも隔離されない。MIGのようなハードウェア隔離はデータセンター向けGPU(Ampere世代以降)限定でエッジでは使えない",[284,370,371],{},"Jetson等のエッジデバイスは統合メモリアーキテクチャのため、クラウドGPUサーバー前提のリソース設計ではなく、ボード全体に対してサイジングする必要がある",[16,373,374],{},"クラウドだけでなく、工場や店舗といったエッジにもKubernetesを展開する動きは広がっている。K3sの軽量性は、そうしたエッジでのAI推論を現実的なコストで実現する土台になる。ただし、GPU共有の限界を理解せずに「クラウドと同じ感覚」で設計すると、本番環境で見えない性能劣化や障害の切り分け困難に直面する。",[16,376,377,378,381,382,387],{},"こうしたエッジ・AI基盤特有の設計判断を、構築のたびにゼロから検証するのは負荷が大きい。",[43,379,340],{"href":338,"rel":380},[47],"はK3sベースのマネージドKubernetesとして、GPUノードの設定やAI-Driven Deploymentにより、こうした構成をYAML地獄に陥らず構築できる環境を提供している。さらに、推論基盤の上でAIエージェントを運用したい場合は、",[43,383,386],{"href":384,"rel":385},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[47],"Captain.AI","がAIワークロードの実行基盤として連携する。",[16,389,390,391,396],{},"エッジAI推論基盤の設計を相談したい場合は、",[43,392,395],{"href":393,"rel":394},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[47],"お問い合わせ","から気軽に相談してほしい。",[398,399,400],"style",{},"html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sOJ5S, html code.shiki .sOJ5S{--shiki-default:#FF9E64}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":142,"searchDepth":160,"depth":160,"links":402},[403,404,405,406,407,408],{"id":13,"depth":160,"text":14},{"id":55,"depth":160,"text":56},{"id":111,"depth":160,"text":112},{"id":208,"depth":160,"text":209},{"id":263,"depth":160,"text":264},{"id":347,"depth":160,"text":348},"2026-10-02","K3sでエッジAI推論基盤を構築する際、標準KubernetesのGPUリソース管理(整数単位・request=limit固定)が壁になる。1台のGPUに複数モデルを同居させる方法とtime-slicing導入時の注意点を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing",{"title":5,"description":410},"blog\u002Fja\u002Fk3s-edge-ai-inference-fractional-gpu-time-slicing",[420,421,422,423,424,184,425],"k3s","kubernetes","edge-ai","gpu-scheduling","device-plugin","fractional-gpu","xVFiMIOI4VpXEAUKwPxs0VWThsT0W5ooMmaB7WlgXK4",[428,437,445,455,467,477],{"path":429,"title":430,"description":431,"date":432,"tags":433},"\u002Fblog\u002Fja\u002Fk3s-ai-inference-gpu-scheduling-dra-keda-kserve","Kubernetesは10年前と同じ設計のままでいいのか。AI推論ワークロードのためにK3sクラスタが見直すべき3つの前提","Kubernetesが登場して10年。AIエージェント・LLM推論の普及で、GPUリソースの扱い方、オートスケーリング、推論サービングという3つの前提が根本から変わった。K3sクラスタでDynamic Resource Allocation・KEDA・KServeをどう見直すべきかを解説する。","2026-08-31",[420,421,434,423,435,436],"ai-workload","dynamic-resource-allocation","mlops",{"path":438,"title":439,"description":440,"date":441,"tags":442},"\u002Fblog\u002Fja\u002Fkubernetes-mlops-gpu-scheduling-talent-shortage","AIがコードを書ける時代に、なぜインフラエンジニアの給料は上がったのか。企業のAI導入ラッシュが生んだ「MLOps人材不足」の実態","生成AIの普及でコードは誰でも書ける時代になったが、企業のAI導入が進むほどKubernetes上でGPUやモデルサービングを安定運用できるMLOps人材の需要は逆に高まっている。その理由と解決策を解説する。","2026-07-30",[421,420,436,443,423,444],"ai-infrastructure","devops",{"path":446,"title":447,"description":448,"date":449,"tags":450},"\u002Fblog\u002Fja\u002Fk3s-hpa-containerresource-sidecar-utilization-dilution","HPAがサイドカーの分まで合算してスケールしていた。KubernetesのContainerResourceという盲点","KubernetesのHPAはPod内の全コンテナの使用量を合算して利用率を計算するため、Istioサイドカーやログエージェントの負荷が判定を薄める。ContainerResourceメトリクスで解決する方法をK3s\u002FKubo文脈で解説する。","2026-10-21",[420,421,451,452,453,454],"hpa","containerresource","autoscaling","service-mesh",{"path":456,"title":457,"description":458,"date":459,"tags":460},"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","2026-10-20",[420,421,461,462,463,464,465,466],"cni","flannel","calico","cilium","networkpolicy","networking",{"path":468,"title":469,"description":470,"date":471,"tags":472},"\u002Fblog\u002Fja\u002Fk3s-topology-spread-constraints-poddisruptionbudget-node-drain-pending","ノードをdrainしたらPodがPendingのまま戻らなかった。K3sでTopology Spread ConstraintsとPodDisruptionBudgetが衝突する理由","K3s本番でノードをdrainしたら一部PodがPendingのまま戻らなかった。原因はTopology Spread ConstraintsのmaxSkewとPodDisruptionBudgetの衝突。drainがノード数不足を自ら作り出す仕組みを公式ドキュメントベースで検証する。","2026-10-19",[420,421,473,474,475,476],"topology-spread-constraints","poddisruptionbudget","scheduling","node-drain",{"path":478,"title":479,"description":480,"date":481,"tags":482},"\u002Fblog\u002Fja\u002Fkyverno-validatingadmissionpolicy-cel-migration-silent-bypass","CELに書き換えたポリシーは、本当に同じ意味なのか。KyvernoからValidatingAdmissionPolicyへの移行で\"黙って素通り\"したリソースの正体","KyvernoのClusterPolicyが廃止へ向かう中、ValidatingAdmissionPolicy（CEL）に移行したら一部リソースだけ検証が素通りしていた。原因のCELランタイムエラーとfailurePolicyの罠、安全な移行手順を解説する。","2026-10-18",[420,421,483,484,485,486],"validatingadmissionpolicy","kyverno","cel","admission-control",1792592604364]