Kubernetes／Private AI

Private AIは「クラウドを使わない」ことではなく、model weights、inference runtime、retrieval store、network、identity、telemetry、upgradeを組織側がより多く管理する運用形態である。Kubernetesはその共通control planeになり得るが、GPU plugin、model serving、network policy、storage、supply chain、observabilityまで責任が組織へ戻る。

Enterprise AI Core / infrastructure / implementation / organization overlay / governance / security / operability / non-LLM component

KubernetesをPrivate AIの共通substrateとして採用する際、何がplatform capabilityで、何が追加component/organization responsibilityか。KServe/vLLM等のmodel servingを含め、private deploymentを「安全・可用」と断定しないための境界は何か。

• official project docs | Schedule GPUs | Kubernetes | https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/ | accessed 2026-09-16 | GPU scheduling stable since Kubernetes v1.26 | locator: GPU access via device plugins; vendor drivers/device plugin must be installed by administrator; GPU custom resources exposed to pods | VERIFIED_SPEC | support + implementation limit
• official project docs | Network Policies | Kubernetes | https://kubernetes.io/docs/concepts/services-networking/network-policies/ | accessed 2026-09-16 | current docs | locator: NetworkPolicy requires network plugin that enforces it; without implementation resource has no effect; default pods are non-isolated absent policy | VERIFIED_SPEC | support + security limit
• author-maintained release/docs | Announcing KServe v0.20 | KServe | https://github.com/kserve/website/blob/main/blog/2026-08-06-KServe-0.20-release.md | published 2026-08-06 | v0.20 | locator: confidential model serving, traffic splitting, canary, KV cache offloading, distributed tracing, managed DRA | OSS_PRACTICE / PRODUCT_VOLATILE | support
• official project docs | Runtime Overview | KServe | https://kserve.github.io/website/docs/model-serving/generative-inference/overview | accessed 2026-09-16 | v0.20 docs | locator: Hugging Face runtime uses vLLM; supports generation, embeddings, reranking; OpenAI-compatible endpoints; continuous batching/PagedAttention etc. | OSS_PRACTICE | support
• official project docs | Understanding LLMInferenceService | KServe | https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview | accessed 2026-09-16 | v0.20 | locator: Kubernetes CRD; vLLM/llm-d; intelligent routing, disaggregated prefill-decode, distributed inference, monitoring/RBAC/storage integration | OSS_PRACTICE | support + context
• official project docs | KServe Administrator Guide | KServe | https://kserve.github.io/website/docs/admin-guide/overview | accessed 2026-09-16 | v0.20 | locator: Standard InferenceService recommended for GPU/production; Knative/serverless mode for predictive scale-to-zero; LLMInferenceService for advanced generative workloads | OSS_PRACTICE | context + limit

• KubernetesはGPUをnative hardware abstractionだけで完結させない。administratorがvendor driverとdevice pluginを導入し、custom resourceとしてscheduleする。従って「Kubernetes対応＝GPU ready」ではない。
• Private AIのsecurityはcluster内だから自動的に成立しない。Kubernetes NetworkPolicyは対応CNI/pluginがなければ作成してもenforcementされず、policy不在時はpod ingress/egressが既定でnon-isolatedである。
• KServe v0.20は2026-08-06公開で、generative inferenceにvLLM/llm-d、LLMInferenceService、traffic splitting/canary、KV cache offload、tracing、DRA等を提供する実装例である。これはKubernetes上でLLM servingがproduction-oriented OSS stackとして成立している証拠だが、個別clusterのSLO/securityを保証しない。
• generative workloadはpredictive serverlessと同じdeployment profileではない。KServe admin guide自身がgenerative workloadにより高いcompute/memory、streaming、GPUを挙げ、Standard Kubernetes Deployment/Gateway APIを推奨している。
• Private AIの主要trade-offはdata localityだけではなく責任移転である。model image/weights、driver/CUDA等のcompatibility、Kubernetes/KServe/runtime upgrade、GPU capacity、autoscaling、network segmentation、secret/IAM、telemetry、backup、incident responseを組織側が所有する。

• cluster内配置だけではdata residency、confidentiality、tenant isolation、egress controlの証明にならない。
• NetworkPolicy YAMLの存在だけではenforcement証明にならない。CNI/plugin capabilityと実測が必要。
• GPU resourceがschedule可能でもmodelがVRAMへ収まる、driver/runtime互換、期待throughputを満たすことは別問題。
• KServe/vLLMの機能存在を任意model/hardware/backendの互換性へ一般化しない。
• self-hostingはprovider outage依存を減らし得るが、patch lag、supply-chain、capacity shortage、operator errorを新たなfailure surfaceとして持つ。
• OpenAI-compatible APIはsemantic/behavioral equivalenceを意味しない。

Kubernetes version / CNI and NetworkPolicy enforcement / GPU vendor-driver-device-plugin / container runtime / node OS/kernel / CUDA-ROCm-XPU等runtime / KServe version / vLLM/backend compatibility / model license and weight access / registry access / storage class / Gateway/API / observability stack / secret/KMS / air-gap level / cluster capacity。

OBSERVED_EXTERNALではなくOSS_PRACTICEとして、Kubernetes GPU scheduling + KServe v0.20 generative servingを確認。PROPOSAL: PRIVATE_AI_DEPLOYMENT_CONTRACT をCore候補とする。fields: cluster/version, node image/kernel, accelerator/driver/plugin, model ID/revision/license/hash, inference runtime/version/image digest, serving CRD/config, quantization, replicas/parallelism, storage/weight source, ingress/gateway, authn/authz, NetworkPolicy+CNI enforcement evidence, egress policy, secrets/KMS, telemetry destinations, autoscaling/capacity, upgrade/rollback, SBOM/signature, backup/restore, SLO and incident owner。

TEST_PROFILE（未実施）: single-node/multi-node、cold model load、steady concurrency、burst、node drain、pod restart、GPU loss/OOM、network partition、registry unavailable、model storage unavailable、CNI deny/allow fixture、unauthorized namespace access、upgrade/canary/rollbackを実施。TTFT、tokens/s、throughput/GPU、VRAM headroom、queue time、recovery time、failed request rate、cross-namespace unauthorized reachability、egress leakage、rollout error、cost/GPU-hour、operator toilを別軸化。

Security: default-deny ingress/egress、service identity/RBAC、network enforcement実測、signed image/SBOM、secret rotation、model weight accessを要求。Privacy: telemetry/log/traces/KV cache/vector DBへのdata spillを対象化。Audit: model hash、container digest、cluster config、policy、request traceを結ぶ。Cost: GPU purchase/reservation/idle、storage/network、operator/SRE、upgrade/test costを含むTCOで比較。Operability: capacity planning、driver/runtime matrix、canary、rollback、backup/restore、security patch SLAが必須。

「KubernetesはPrivate AIの共通control planeになり得、KServe等によりLLMを含むmodel servingを構成できる。ただしGPU driver/device plugin、network enforcement、model/runtime互換性、capacity、patching、observabilityは組織側の責任となる。『private』は配置場所ではなく、identity・network・data flow・supply chainを含む検証可能な運用境界として扱う。」

• EA-088 GPU/NPU Capacity Planningへ、accelerator/driver/runtime/model compatibility matrixとthroughput/VRAM測定を引き渡す。
• EA-090 Air-gapped AIではregistry/model/OS/package/update経路を切断した場合のartifact promotionとpatch運用を追加採集する。
• KServe/vLLM exact current release、Kubernetes current supported minor、CNI実装差は公開後更新時に再pinする。
• managed Kubernetes/private cloud/on-premを同義にせずorganization overlayで分離する。

upstream vLLM exact current stable tag/commit（今回検索では派生hardware plugin情報が混在したため未固定）、Kubernetes current support window、主要CNIのNetworkPolicy feature差、KServe v0.20の各backend/hardware compatibility matrix。STOP_CONDITION: Kubernetes GPU scheduling、network enforcement boundary、KServe v0.20 generative serving、Private AI responsibility shiftが一次/author-maintained資料で確立したため初回bounded packetは完了。

---