GPU／NPU Capacity Planning

Private AI、self-hosted inference、edge/on-device、fine-tuning、batch/streamingを実装段階へ進めると、モデル名やparameter countだけでは必要accelerator数を決められない。weights、KV cache、activation/workspace、quantization、context length、concurrency、prefill/decode比、parallelism、interconnect、runtime/kernel、SLA、power/costがcapacityを決める。GPU/NPU/TPU等のaccelerator class間でもmemory architecture・software stack・supported model/operatorが異なるため、単純な「TOPS」「VRAM」「GPU枚数」比較を辞典のcapacity claimへ持ち込まないための独立contractが必要である。

Enterprise AI Core: capacity planning / deployment acceptance / operability / cost governance provider mapping: NVIDIA GPU、Google TPU、AWS Inferentia/Trainium等のavailability/spec mapping organization overlay: quota、region、procurement、power/cooling、SRE ownership benchmark: MLPerf + tenant workload replay implementation: model server/runtime、parallelism、KV cache、quantization、scheduler non-LLM component: accelerator、HBM、interconnect、host memory/network/storage

• accelerator capacityはparameter countやnominal VRAMだけでなく、実際のserving/training workload envelopeで決めるべきか。
• GPU/NPU/TPUの公称specや公開benchmarkを、tenant固有SLA・model/runtime構成へどこまで外挿できるか。
• model fit、steady-state throughput、tail latency、burst/concurrency、failure/recovery、cost/powerを同一capacity contractで追跡できるか。

• official hardware specification — NVIDIA H100 Tensor Core GPU / H200 Tensor Core GPU / Blackwell architecture; NVIDIA; https://www.nvidia.com/en-us/data-center/h100/ ; https://www.nvidia.com/en-us/data-center/h200/ ; https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/ ; accessed 2026-09-16; exact board/SXM/PCIe SKU must be pinned per deployment; locator: memory capacity/bandwidth and platform specifications; VERIFIED_SPEC + PRODUCT_VOLATILE; support/context.
• official accelerator orchestration documentation — NVIDIA GPU Operator / MIG documentation; NVIDIA; https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/ ; https://docs.nvidia.com/datacenter/tesla/mig-user-guide/ ; accessed 2026-09-16; deployment-specific Operator/driver/CUDA/device-plugin/MIG profile must be pinned; locator: component lifecycle and MIG partition/profile semantics; VERIFIED_SPEC + OSS_PRACTICE + PRODUCT_VOLATILE; support/limit.
• official cloud accelerator documentation — Cloud TPU v6e documentation; Google Cloud; https://cloud.google.com/tpu/docs/v6e ; accessed 2026-09-16; TPU v6e; locator: architecture/specification/topology; VERIFIED_SPEC + PRODUCT_VOLATILE; support/context.
• official accelerator documentation — AWS Inferentia2 / EC2 Inf2 instances; Amazon Web Services; https://aws.amazon.com/machine-learning/inferentia/ ; https://aws.amazon.com/ec2/instance-types/inf2/ ; accessed 2026-09-16; exact instance type and Neuron release must be pinned; locator: accelerator memory, instance topology, Neuron software; VERIFIED_SPEC + PRODUCT_VOLATILE; support/context.
• author-maintained implementation documentation — Distributed Inference and Serving / Optimization and Tuning; vLLM project; https://docs.vllm.ai/en/latest/serving/distributed_serving.html ; https://docs.vllm.ai/en/latest/configuration/optimization.html ; accessed 2026-09-16; exact installed vLLM release/commit UNKNOWN in this packet; locator: tensor/pipeline parallel deployment and GPU memory/KV-cache tuning; OSS_PRACTICE; support/limit.
• independent/open industry benchmark — MLPerf Inference v6.0 results; MLCommons; https://mlcommons.org/2026/04/mlperf-inference-v6-0-results/ ; published 2026-04-01 / accessed 2026-09-16; MLPerf Inference v6.0; locator: GPT-OSS 120B, DeepSeek-R1 interactive, multi-node submissions, LoadGen++; RESEARCH + VERIFIED_SPEC; support/context/limit.
• independent/open benchmark methodology — A new GPT-OSS benchmark and DeepSeek R1 updates for latency-optimized reasoning; MLCommons; https://mlcommons.org/2026/03/mlperf-inference-gpt-oss/ ; published 2026-03-24 / accessed 2026-09-16; MLPerf Inference v6.0; locator: GPT-OSS 120B performance mode, Interactive TTFT p99 <=2.0s / TPOT <=15ms, Server TTFT p99 <=3.0s / TPOT <=80ms, accuracy/compliance separation; RESEARCH + VERIFIED_SPEC; support/limit.
• independent/open mobile benchmark — MLPerf Mobile v6.0: New GenAI Benchmarks for On-Device LLMs; MLCommons; https://mlcommons.org/2026/06/mlperf-mobile-v6/ ; published 2026-06-15 / accessed 2026-09-16; MLPerf Mobile v6.0; locator: Llama 3.2 1B/3B and Llama 3.1 8B on-device tests, CPU fallback and supported NPU acceleration; RESEARCH + VERIFIED_SPEC; support/context/limit.

• Capacity planningの最小単位は accelerator SKU ではなく MODEL × RUNTIME × WORKLOAD × SLA × TOPOLOGY である。同じacceleratorでもmodel precision、quantization、context、batch/concurrency、KV-cache policy、runtime/kernel、tensor/pipeline parallelismでfitとperformanceは変わる。
• memory fitをweightsだけで計算してはならない。少なくとも model weights + KV cache + runtime/activation/workspace + communication/fragmentation headroom を分離する。autoregressive LLMではcontext lengthとconcurrent sequenceがKV-cache pressureを増やす。OOMしないこととSLAを満たすことは別判定である。
• HBM容量とbandwidthは別軸。大容量memoryはmodel/context fitを改善し得るが、decode/prefill、memory bandwidth、compute、interconnect、scheduler bottleneckのどれが支配的かはworkload依存。公称FLOPS/TOPSだけでtoken throughputを予測しない。
• parallelismは容量拡張であると同時に通信コストを導入する。vLLM等のdistributed servingではtensor/pipeline parallelismを利用できるが、accelerator間・node間interconnect、collective communication、load balanceがtail latencyとthroughputを変える。GPU枚数を倍にして性能が線形に倍増するとは扱わない。
• partitioningはcapacity isolationとperformance isolationを同一視しない。MIG等でaccelerator資源をpartitionできても、選択profile、memory/compute slice、workload shape、scheduler、I/Oを含めてtenant fixtureで検証する必要がある。
• NPU/TPU/ASICは「GPUより速い/安い」という一般claimにしない。Inferentia/TPU/on-device NPU等は対応compiler/runtime/operator/model、topology、region/device availabilityがgateになる。supported pathでのprice/performanceが良くてもunsupported model/operatorやmigration costを含む総運用適合性は別問題である。
• 公開benchmarkは比較入口でありcapacity guaranteeではない。MLPerf Inference v6.0はarchitecture-neutral/reproducibleな比較基盤を提供し、GPT-OSS 120BやDeepSeek-R1でlatency-constrained scenariosも持つ。だがsubmissionは特定model、precision、software stack、system topology、scenarioで成立した結果であり、tenant prompt length、output length、concurrency、RAG/tool overhead、SLAへそのまま外挿しない。
• MLPerf v6.0ではmulti-node submissionが増え、large-scale capacityが単体accelerator性能ではなくnetwork/interconnect/storage/software orchestrationを含むsystem problemであることを裏付ける。
• on-device/NPUについてもMLPerf Mobile v6.0がLLM benchmarkを導入し、CPU executionと特定supported NPU accelerationを区別している。「NPU搭載端末」だけでは任意LLMがNPU実行可能とは言えない。

• vendor theoretical peak FLOPS/TOPSをapplication throughputへ変換しない。
• nominal HBM合計がmodel artifactより大きくても、KV cache/workspace/fragmentation/replicationでOOMし得る。
• modelがfitしてもTTFT/TPOT/p95-p99 latency、throughput、queue waitがSLAを満たすとは限らない。
• quantizationでmemoryを削減しても、quality regression、unsupported kernels、conversion time、runtime compatibilityが生じ得る。
• tensor/pipeline parallelismはcommunication overheadとfailure domainを増やす。
• multi-node scale-outはnetwork topology、collectives、host memory、storage/model loadingを新たなbottleneckにする。
• benchmark winnerを別model、別precision、別software revision、別prompt/output distributionへ一般化しない。
• GPU/NPU/TPU availabilityはregion、quota、instance/device generation、cloud capacity、driver/compiler/runtime supportに依存する。
• thermal/power/cooling constraintsはon-prem/edgeでcapacityを制約する。TDPの単純合算をfacility designの代替にしない。
• accelerator partitioning/virtualizationがあることと、security/performance isolationが要件を満たすことは別claim。

exact accelerator SKU/form factor and HBM capacity; cloud region/zone/quota/reservation/stock; driver+firmware+CUDA/ROCm/Neuron/TPU runtime/compiler revision; framework/model-server version and supported kernels/operators; model license/weights format/precision/quantization path; interconnect topology and multi-node network; Kubernetes device plugin/operator/DRA/MIG profile; on-device NPUのSoC+OS+SDK/runtime+supported model/operator; owned infrastructureのpower/cooling/rack/network constraints.

Core候補 ACCELERATOR CAPACITY CONTRACT: workload_id/version; model_id + weights hash + tokenizer/processor; runtime/server version/commit + container digest; precision/quantization + conversion artifact hash; accelerator vendor/SKU/count + HBM per device; driver/firmware/compiler/runtime; topology/interconnect/network; tensor/pipeline/data/expert parallelism + replicas; max context/input/output distribution; concurrency/batch/scheduler/KV-cache policy; measured idle/model-loaded/steady/peak memory; TTFT/TPOT/tokens-s/requests-s/p50-p95-p99 latency; OOM/rejection/queue rate; power/energy where measurable; hourly/capital cost + utilization; failover/restart/model-load time; benchmark fixture/hash + acceptance threshold; capacity headroom + rollback configuration.

後続Work用SAFE TEST_PROFILE（未実施）: A) fixed weights/precisionでcold load・steady memory・max safe context/concurrency。B) concurrency 1→NでTTFT/TPOT/p50/p95/p99/queue time。C) offline/batchとinteractiveを分離しtokens/s・requests/s。D) short/median/long input × short/long outputでKV-cache pressureとOOM/rejection。E) 1 accelerator、tensor-parallel、multi-nodeでscaling efficiency。F) FP/BF16 baseline対quantized artifactでmemory・latency・throughput・task quality。G) full device対MIG/virtualized profileでlatency variance/isolation。H) synthetic worker/node lossでrecovery time/request loss。I) accepted-SLA構成だけでcost/request、cost/1M tokens、energy/request。J) MLPerf等と同一hardware familyでもtenant fixtureとの差を記録。

Security: shared accelerator/partitioning、device plugin、driver/firmware、container/model artifact supply chainを監査対象とする。accelerator memory isolationを名称だけで保証扱いしない。 Privacy: model/input/KV/cache/telemetryがどのmemory/storage/logへ残るかをruntimeごとに確認する。 Audit: hardware SKUだけでなくdriver/runtime/container/model/quantization/topologyまでversion pinしないとcapacity resultを再現できない。 Cost: purchase/instance単価だけでなくutilization、idle、reservation、rebuild/re-quantization、engineering、power/cooling、networkを含める。SLA未達の安価構成を「低コスト」と評価しない。 Operability: quota exhaustion、GPU failure、driver upgrade、kernel/runtime regression、model reload時間、capacity fragmentation、autoscaling warm-upを運用試験へ含める。

「GPU/NPU capacityは、acceleratorの公称性能やVRAMだけでは決まらない。モデルartifact、precision/quantization、contextとconcurrency、KV cache、runtime、parallelism、interconnect、SLAを固定した実測単位で設計する。公開benchmarkはhardware/software構成を比較する重要な入口だが、別workloadの性能保証ではない。GPU・TPU・NPU・専用ASICは、対応software stackとavailability gateを含むdeployment artifactとして比較する。」

• EA-087 PRIVATE_AI_DEPLOYMENT_CONTRACT のaccelerator–driver–runtime–model compatibility matrixを本EAの ACCELERATOR CAPACITY CONTRACT へ接続する。
• 公開後更新時にNVIDIA/AMD/Intel GPU、Google TPU、AWS Inferentia/Trainium、主要on-device NPUのcurrent SKU/spec/runtime/region matrixを再pinする。
• candidate hardwareをparameter countで選ばず、対象model/workloadのmemory estimator→single-device smoke→load curve→parallel scaling→failure/cost testの順で採否判断する。
• MLPerf Inferenceは公開後時点の最新roundを再確認し、同一model/scenarioに近いsubmissionだけを比較入口にする。
• 後続のFinOps/energy/edge隣接項目には本Packetのmeasured utilization・power・cost artifactを再利用し、claim relationは別に保持する。

2026-09-16時点の各cloud/provider全accelerator SKUのregion/quota/on-demand/reservation availability matrix; NVIDIA GPU Operator、vLLM、Neuron SDK、TPU runtime等の本番採用時exact release/tag/commit compatibility matrix; AMD/Intelを含むcurrent cross-vendor同一tenant fixture比較; specific enterprise workloadでのKV-cache/parallelism/quantization最適点; on-device NPUで任意model/operatorを実行できる範囲。これらは実測または公開後再確認なしに閉じない。

capacity planningのCore contract、公開一次仕様、author-maintained implementation、独立benchmark、failure envelope、安全な後続TEST_PROFILEまで揃った。製品横断SKU価格表を無限採集せず、current availability/pricing/runtime compatibilityとtenant workload実測は公開後Workの再pin/実機段階へ残す。

---