1. 为什么用 Sealos 做私有化部署企业大模型私有化部署最近成了运维圈子里绕不开的话题。业务部门递过来一张需求表要私有化、要能跑 LLM、要能对接内部知识库最好一周内上线。真正接过这种需求的人都知道从裸金属到跑起一个带 GPU 调度的推理服务中间隔着一条完整的配置链路操作系统参数、容器运行时、Kubernetes 集群、存储、网络、GPU 驱动、设备插件、模型服务。任何一个环节没对齐后面全卡住。我自己的做法是凡是让我重复超过两次的部署动作一律固化成踩坑记录和配置清单下次直接照抄。Sealos 就是这套思路里非常顺手的一环。它把 Kubernetes 集群的搭建收敛成一条sealos run命令再用同样的方式叠加网络、存储、Ingress、GPU 插件然后把企业大模型这类 AI 工作负载作为普通云原生应用跑在集群里。这篇文章就是我的私有化部署配置清单分硬件规划、环境准备、集群安装、模型服务落地、问题排查五部分全部按实际可复现的粒度写你照着操作即可。1.1 Sealos 解决的到底是什么问题先解释清楚 Sealos 的定位避免你带着错误预期去用它。Sealos 不是云平台也不是 PaaS 层它的核心是一套以集群镜像Cluster Image为交付单元的 Kubernetes 发行版。你可以把它理解成装机的Ghost 镜像与软件包管理的结合底层操作系统的初始化、Kubelet 安装、etcd 启动、控制面组件配置、加入节点这些动作被打包成一个可重复执行的镜像一条命令跑完结果是一个干净可用的集群。这和传统的部署方式有本质区别。kubeadm 能给你一个最小的控制面但 CNI 要自己选、存储要自己装、Ingress 要自己配、GPU 插件要自己折腾每一步都有版本兼容性问题。Rancher 和 KubeSphere 这类产品解决的是管理面问题但他们自身也是要部署的一坨东西而且升级节奏往往跟着上游走私有化场景里容易变成新的维护负担。Sealos 的价值在于它把集群本身当作可版本化、可迁移的交付物你要的是一套生产配置直接 run 对应的镜像组合就行不需要在部署环节耗费两三天的调试时间。1.2 大模型私有化部署为什么绕不开这类工具企业大模型私有化部署的核心矛盾是模型权重和推理服务是大文件、大计算、大显存但集群基础设施却必须做到小而稳。GPU 节点要能被调度器识别和分配显存模型文件要落在持久化存储上推理服务要暴露给内部业务方调用整套链路还要能隔离不同部门的使用配额。这些需求落到 Kubernetes 里就是调度、存储、网络、网关四件事。Sealos 恰好把四件套都封装好了。更关键的是私有化环境往往没有外网条件或者只有受控的镜像仓库。Sealos 的镜像可以提前拉取、离线导入这正好匹配企业内网交付的大前提。我去年做过一个制造业客户的交付客户机房只给开了一个能访问内网镜像仓库的出口其他外网全部禁止。Sealos 在这种受限网络下依然能完成集群搭建和组件交付这是它在我清单里一直占据位置的重要原因。2. 部署前的硬件与网络规划硬件规划是私有化部署的第一个大坑。很多人一上来就按官网最低配置跑跑到一半发现 etcd 磁盘 IO 跟不上、GPU 节点内存不够模型加载最后推倒重来。这个环节不值得省时间我建议你先按下面的表格做一次容量评估再开始动服务器。2.1 控制面与通用节点的规格评估控制面节点承载 etcd、kube-apiserver、kube-controller-manager、kube-scheduler对 CPU 和磁盘 IO 的要求远高于普通业务机。etcd 对磁盘延迟极其敏感建议单独挂 SSD 数据盘不要把系统盘和数据盘混用。节点角色CPU内存系统盘数据盘数量控制面生产8 核16G100G SSD200G SSDetcd 专用3做高可用控制面测试4 核8G50G100G SSD1通用工作节点16 核64G100G SSD500G SSD 起按业务扩GPU 工作节点32 核256G100G SSD1T SSD 或 NVMe按显存需求扩测试环境我建议也别太省。跑 7B 模型至少需要 16G 内存做推理进程13B 模型建议 32G 以上加上系统开销和缓存64G 的通用节点是底线。生产环境做高可用时3 个控制面是标配etcd 数据盘必须独立这是无数人用数据换来的教训。2.2 企业大模型对 GPU 节点的真实要求GPU 选型不能只看显存大小要看你的模型规格和并发预期。推理场景的显存占用有一个经验公式显存 ≈ 模型权重大小 KV Cache 推理框架开销。以 Llama-3-8B 为例FP16 权重约 16G加上 KV Cache 和运行时开销单卡 24G如 RTX 4090、L20能跑但余量不大70B 级别模型用 FP16 至少需要约 140G 权重显存通常得 2 张 80G 的 A100/A800 做张量并行或者用 AWQ/GPTQ 4bit 量化后压到 40G 左右单卡可跑。GPU 节点的 CPU 和内存不能太低。模型加载时需要把权重文件读进内存再拷到显存内存不足会导致加载即 OOM。推理时也要做 Tokenizer、请求调度等 CPU 计算。我常用的配置是 32 核 CPU、256G 内存、2 张或 4 张 GPU。如果你只是做内部小范围试用一张 L20/4090 也能起步但要把节点规划成可横向扩容的模式否则后期加卡要动集群拓扑。另外所有 GPU 节点建议预留一块独立系统盘驱动和 CUDA 库装在系统盘上权重文件放数据盘。GPU 服务器普遍散热噪声大、功耗高机房配电和制冷也要提前确认这些虽然不是软件配置但经常成为交付进度的隐形杀手。2.3 存储规划的三种可行方案大模型私有化部署中存储是最容易被低估的。模型文件动辄几十 GB 到上百 GB推理服务的高并发读取、训练场景的 Checkpoint 写入对存储的性能要求差别很大。Sealos 默认推荐 OpenEBS它提供基于节点磁盘的openebs-hostpath存储类适合模型文件和普通应用数据。注意一点hostpath 的副本数取决于 Pod 所在节点数据不带跨节点复制节点坏了数据可能丢。对于模型权重这类可以从镜像或对象存储重建的数据问题不大但如果是业务数据库建议上独立存储方案比如对接已有 NFS 或外部存储阵列。数据类别存储方案性能要求备份策略模型权重文件openebs-hostpath / 对象存储顺序读为主SSD 即可保留原始文件不依赖 PVC 副本推理日志与业务数据独立 NFS / 分布式存储随机读写SSD每日快照或异地复制etcd节点本地独立 SSD低延迟、高 IOPS每小时快照保留 7 天网络规划方面节点之间建议千兆以上内网GPU 节点之间做推理并行时尽量走万兆或 Infiniband不然多卡通信会成为瓶颈。Sealos 默认 CNI 用 Calico它的 BGP 模式在大规模集群里表现稳定小规模集群直接用 IPIP 或者 VXLAN 模式都行后面部署时会讲到具体参数。3. 环境准备与前置检查清单这个环节是整个私有化部署里最容易翻车的地方。很多人sealos run跑一半失败回头看往往是前置条件没做干净。我总结了六个必查项每一条都对应真实踩坑经历。3.1 操作系统与内核参数建议使用 Ubuntu 22.04 LTS 或 Rocky Linux 9内核版本不低于 5.15。Debian 系的默认内核参数偏保守需要手动调整RedHat 系则需要额外注意 SELinux 和防火墙。我统一用 Ubuntu 22.04理由很简单驱动生态最全尤其是 NVIDIA GPU 驱动和 container runtime 的兼容性测试做得好省掉很多编译折腾。拿到服务器后第一件事是关 swap。Kubernetes 从 1.22 之后虽然支持部分场景的 swap 配置但生产环境我从来不开原因很直接swap 会把 kubelet 和容器的内存隔离机制搞乱导致 Pod 内存限额失效推理服务 OOM 时系统反应会变得迟钝。然后是内核参数创建/etc/sysctl.d/99-k8s.conf写入以下内容net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 vm.swappiness 0 vm.overcommit_memory 1 fs.file-max 2097152 fs.inotify.max_user_instances 8192 fs.inotify.max_user_watches 524288执行sysctl --system生效。overcommit_memory 1这条对模型推理很重要推理框架申请大块虚拟内存时内核默认的 overcommit 策略可能直接拒绝导致进程启动即失败。3.2 主机名、DNS 与时间同步主机名规划看似小事实际影响面很大。etcd 的集群成员依赖主机名标识如果部署后改主机名可能出现 etcd 成员地址错乱的诡异问题。建议提前定好命名规则比如k8s-master-01、k8s-gpu-01并用/etc/hosts固定所有节点的主机到 IP 的映射避免依赖内网 DNS。时间同步用 chrony理由是对时钟漂移极为敏感的 Kafka、etcd 和 CSI 插件。不同步的时间会造成证书校验失败、监控指标错乱甚至 etcd 选举异常。安装配置命令如下apt install -y chrony systemctl enable --now chrony chronyc sources -v输出的^*表示已同步成功。如果公司内网有 NTP 源记得修改/etc/chrony/chrony.conf指向内网源外网源在私有化环境里往往不可达。3.3 安装 Sealos 命令行工具Sealos 的安装本身很简单下载二进制放到PATH下即可。在能访问外网的机器上可以直接从官方发布渠道下载对应版本。私有化环境则建议先在跳板机上下载好再通过内网分发到各节点。wget https://github.com/labring/sealos/releases/download/v4.3.7/sealos_v4.3.7_linux_amd64.tar.gz tar zxvf sealos_v4.3.7_linux_amd64.tar.gz chmod x sealos mv sealos /usr/local/bin/ sealos version有一个容易踩的坑Sealos 各小版本的集群镜像兼容性不完全一致我建议固定使用一个经过验证的版本组合比如 Sealos v4.3.7 Kubernetes v1.28.0 Calico v3.26.1。不要随手升级尤其不要在生产环境用latest标签拉镜像。另外执行命令的机器必须有各节点的 SSH 访问权限Sealos 是通过 SSH 远程执行安装逻辑的你需要提前准备好 root 密码或密钥。3.4 SSH 免密与安装用户准备Sealos 的节点接入依赖 SSH传统做法是让安装机免密登录所有目标节点。我通常用专门的部署账号把它加入sudo组并在各节点写入它的公钥。需要说明的是Sealos 也支持直接用--pk-passwd参数传 root 密码但那个方式在密码复杂度高或含特殊字符时容易出问题我还是推荐密钥方式。一个容易被忽略的配置是各节点sshd的MaxSessions和MaxStartups。集群规模在 10 台以上时Sealos 会并发建立 SSH 会话默认值可能不够表现为部分节点连接超时。建议在/etc/ssh/sshd_config中配置MaxSessions 50和MaxStartups 50:30:100然后重启 sshd。4. 集群部署实操与关键参数前置准备做完集群搭建反而成了最轻松的部分。Sealos 的核心命令就几条但每条命令后面的镜像标签、参数含义、执行顺序都有讲究。这一节我按实际执行顺序写。4.1 初始化控制面与添加节点初始化命令的基本形态如下sealos run kubernetes:v1.28.0 calico:v3.26.1 openebs:v3.9.0 ingress:v1.9.4 \ --masters 192.168.1.11,192.168.1.12,192.168.1.13 \ --nodes 192.168.1.14,192.168.1.15,192.168.1.16 \ --ssh-key /root/.ssh/id_rsa这条命令会同时完成三台控制面的高可用部署、三台工作节点的加入以及 Calico、OpenEBS、Ingress 组件的安装。执行时间取决于网络环境通常 5 到 15 分钟。如果中途失败不要盲目重跑先看日志定位原因。常见的是某台机器 SSH 不通、磁盘未格式化、镜像拉取超时。修复后直接重跑同一命令Sealos 具备幂等性不会重复创建已有资源。关于高可用的说明--masters传三台会部署 etcd 三节点集群这是生产环境推荐的形态。如果只有两台控制面etcd 的 quorum 是 2任何一台挂掉集群就只剩 1 票写不进去实际上没有高可用价值。资源不够的情况下宁可先单控制面也别做两台这种假高可用。4.2 用 Clusterfile 固化你的部署配置命令行的方式适合临时验证但私有化交付需要可重复我建议把配置写成 Clusterfile。这是一个 YAML 文件记录集群的节点拓扑、镜像列表、SSH 信息后续扩容或重装直接复用。apiVersion: apps.sealos.io/v1beta1 kind: Cluster metadata: name: my-enterprise-cluster spec: infra: hosts: - ips: [192.168.1.11, 192.168.1.12, 192.168.1.13] roles: [master] - ips: [192.168.1.14, 192.168.1.15] roles: [node] ssh: user: root passwd: your-secure-password image: - kubernetes:v1.28.0 - calico:v3.26.1 - openebs:v3.9.0 - ingress:v1.9.4然后执行sealos apply -f Clusterfileapply和run的差异在于apply会读取并应用整个 Clusterfile 的期望状态适合交付运维团队使用。我把 Clusterfile 提交到 Git 仓库管理版本化之后任何一次部署都能追溯到当时用的是什么镜像、什么节点拓扑。这个习惯在客户现场救过我很多次。4.3 核心组件版本固定与镜像离线导入私有化环境最麻烦的是镜像来源。Sealos 默认从阿里云镜像仓库拉取社区镜像如果客户环境完全离线需要提前准备好离线包。好在 Sealos 支持打包和导入流程是先在一台能连外网的机器上把镜像拉下来sealos pull kubernetes:v1.28.0 sealos pull calico:v3.26.1 sealos pull openebs:v3.9.0 sealos pull ingress:v1.9.4然后打成一个离线 tar 包搬运到内网机器再在部署机上导入。实际操作中我一般会导出到一个 U 盘或者内网共享目录分发给各节点后执行导入。版本固定的原则在这里尤其重要拉镜像的时候如果写成latest你拿到内网的镜像内容可能和当初验证的不一致客户现场就会成为你测试新版本的场所。4.4 验证集群健康状态集群搭建完成后先别急着部署业务。用下面几个命令做一次健康检查花五分钟可以省下后面几小时的排查时间kubectl get nodes -o wide kubectl get pods -A kubectl get sc检查点有三个节点状态必须全是Ready系统组件的 Pod 不能有CrashLoopBackOff或PendingStorageClass 必须存在且默认标记正确。另外建议执行一次 etcd 健康检查kubectl -n kube-system exec etcd-master-01 -- etcdctl endpoint health --cluster输出类似127.0.0.1:2379 is healthy即正常。如果这里有问题说明控制面节点之间的网络或磁盘有问题要优先处理否则后面的业务部署随时被隐含故障打断。5. 企业大模型私有化部署实操集群就绪后走到核心环节把企业大模型跑起来。这个环节的配置集中在 GPU 驱动、设备插件、推理服务三块我按照一条完整链路写下来。5.1 GPU 驱动、运行时与设备插件推理服务要用到 GPU必须先做三件事安装 NVIDIA 驱动、配置 nvidia-container-toolkit、部署 device plugin。驱动安装建议用 NVIDIA 官方 deb 包或 runfile不要用系统源里的旧驱动。以 Ubuntu 22.04 为例nvidia-smi # 如果未安装先安装驱动 apt install -y nvidia-driver-535 reboot nvidia-smi驱动装好只是第一层。容器要访问 GPU还必须在节点上装 nvidia-container-toolkit这样 containerd 才能给容器注入 GPU 设备。常见的问题是驱动装好了、节点也 Ready但 Pod 调度到 GPU 节点后报Failed to allocate gpu memory那就是 toolkit 没装或者配置没生效。toolkit 安装后需要重启 containerd。然后通过 Sealos 部署 NVIDIA 设备插件sealos run nvidia-device-plugin:v0.14.0部署完成后验证节点资源kubectl get nodes -o json | jq .items[].status.allocatable能看到nvidia.com/gpu: 2这样的字段说明 GPU 已经被调度器识别。走到这一步集群层面的 GPU 能力才算真正打通。5.2 用 Ollama 快速落地内部推理服务Ollama 是目前把开源模型私有化跑起来最快的方案对小型企业和测试环境尤其合适。它自带模型管理一条命令就能拉取 Llama 3、Qwen 等主流模型。部署方式就是一个普通 DeploymentKubernetes 里面对它唯一要做的就是给它挂足够的存储和 GPU 配额。apiVersion: v1 kind: Namespace metadata: name: ai --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ollama-models namespace: ai spec: accessModes: - ReadWriteOnce storageClassName: openebs-hostpath resources: requests: storage: 200Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: ollama namespace: ai spec: replicas: 1 selector: matchLabels: app: ollama template: metadata: labels: app: ollama spec: containers: - name: ollama image: ollama/ollama:0.1.32 ports: - containerPort: 11434 resources: limits: nvidia.com/gpu: 1 memory: 64Gi requests: memory: 32Gi volumeMounts: - name: models mountPath: /root/.ollama volumes: - name: models persistentVolumeClaim: claimName: ollama-models这里有两个细节容易踩坑。第一模型目录挂载到/root/.ollama而不是/root/.ollama/models因为 Ollama 的官方镜像里进程用户虽然是 root但模型索引、日志都在.ollama目录下挂整个目录才不会出现模型下载一半就报盘满的怪问题。第二nvidia.com/gpu的 request 不需要写limits 写多少就是实际占用的显卡数量写 1 表示占满整张卡多模型共享一张卡的场景需要配合显存调度方案Ollama 默认不支持需要额外做显存切分。部署完成后进入 Pod 拉模型kubectl exec -it deploy/ollama -n ai -- ollama pull llama3:8b kubectl exec -it deploy/ollama -n ai -- ollama pull qwen2.5:7b然后在集群内用Service暴露 11434 端口内部业务系统就可以通过http://ollama.ai.svc.cluster.local:11434调用了。5.3 用 vLLM 支撑高并发推理如果内部业务并发上来了或者是一次要同时服务多个部门Ollama 的吞吐会吃紧这时建议切到 vLLM。vLLM 的优势在于 PagedAttention 显存管理和 Continuous Batching吞吐量比原生推理框架高一个量级。中国团队开源的 Qwen 系列等主流模型对 vLLM 支持都很好生产中非常成熟。vLLM 的部署配置里最重要的是命令行参数这里给出一个可用于生产的模板apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen namespace: ai spec: replicas: 1 selector: matchLabels: app: vllm-qwen template: metadata: labels: app: vllm-qwen spec: containers: - name: vllm image: vllm/vllm-openai:latest command: - python3 - -m - vllm.entrypoints.openai.api_server - --model - /models/qwen/Qwen2.5-14B-Instruct - --served-model-name - qwen2.5-14b - --tensor-parallel-size - 2 - --max-model-len - 32768 - --gpu-memory-utilization - 0.92 - --port - 8000 env: - name: HUGGINGFACE_HUB_CACHE value: /models ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 2 memory: 128Gi volumeMounts: - name: models mountPath: /models volumes: - name: models persistentVolumeClaim: claimName: model-weights-pvc几个参数值得展开说。--tensor-parallel-size 2表示把模型切分到两张 GPU 上这个值必须和 limits 里的 GPU 数一致且最好在模型加载前就确定中途改会导致显存重新布局。--gpu-memory-utilization 0.92表示最多用 92% 的显存做推理留一点余量给上下文切换和碎片设成 0.99 虽然显存利用率高但并发上来后很容易触发 OOM。--max-model-len 32768是上下文窗口越长越占显存一般内部知识库问答用 8K 到 32K 足够不建议盲目拉高。模型权重文件管理是这个环节最容易出问题的地方。我通常在 PVC 里放一个目录用kubectl cp或者直接在 Pod 里用huggingface-cli下载模型下载完成后把 Deployment 的readinessProbe配置指向模型加载完成的端点避免后端流量把未就绪的推理服务打崩。5.4 模型服务的网关暴露与鉴权推理服务跑起来后要决定如何暴露给内部使用方。这里我推荐用 Sealos 自带 Ingress 组件Traefik配置以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: vllm-ingress namespace: ai spec: ingressClassName: nginx rules: - host: llm.internal.example.com http: paths: - path: / pathType: Prefix backend: service: name: vllm port: number: 8000私有化环境中 DNS 解析要落在内网 DNS 服务器上证书用内部 CA 签发不要在客户端跳过证书校验。更严谨的做法是在 Ingress 前加一层网关做 API Key 鉴权因为大模型服务一旦暴露出去又不加鉴权内网里任何知道地址的人都能消耗你的 GPU 资源这类事故我见过不止一次。6. 常见问题与排查技巧实录部署和运维过程中遇到的问题90% 都集中在几个固定区域。我整理了一张排查速查表每一条都是实际验证过的解决路径。6.1 节点 NotReady 的通用排查清单现象常见原因解决路径kubelet 服务未运行安装时 systemd 未刷新systemctl daemon-reload systemctl restart kubeletCNI 插件冲突多套 CNI 重复部署检查/etc/cni/net.d下残留配置清理后重启 kubelet磁盘压力导致驱逐数据盘使用率超阈值清理旧镜像、日志或调整image-gc-high-threshold节点时间偏差大chrony 未同步修 NTP 源重启 chrony 和 kubelet内核参数未生效未执行 sysctl重新sysctl --system并重启容器运行时我的经验是NotReady 问题不要一上来就猜原因先看kubectl describe node name里的 Conditions 和事件再逐个条件排查。有一次客户现场控制面节点 NotReady日志指向 kubelet 无法连接 apiserver最后发现是业务侧在服务器上改了防火墙规则把宿主机的 6443 端口给拦了。这类问题靠远程看日志很难定位必须到节点现场采集系统状态。6.2 GPU 不可调度的典型原因GPU 资源没出现在allocatable里最常见的原因是 device plugin 没跑起来。先确认 Pod 状态kubectl -n kube-system get pods | grep nvidia如果 Pod 是CrashLoopBackOff看日志大概率是 toolkit 没装或者驱动版本太新与插件不兼容。NVIDIA 官方插件的版本通常滞后于新驱动遇到这种情况建议回退驱动版本而不是升级插件去追新。另一种隐蔽情况是 GPU 节点的kubelet上报了nvidia.com/gpu: 0。这是因为 device plugin 注册成功但 runtime class 没配对容器运行时找不到 GPU。检查 containerd 配置里是否加载了nvidia-container-runtime加载后必须重启 containerd 才能生效。6.3 模型加载缓慢与存储瓶颈大型模型文件从 PVC 读取时如果存储是普通机械盘或网络延迟大的 NFS加载 70B 模型可能要等上十几分钟甚至更久。排查时先看推理服务启动日志里模型加载耗时再看 PVC 所在节点的磁盘 IO 状态。我踩过的坑是 OpenEBS hostpath 的 PVC 被调度到了某个 IO 繁忙的节点上模型加载期间整个节点的 IO 被打满其他业务也受影响。解决方案是在 StorageClass 里设置nodeAffinity让模型权重相关的 PVC 固定落在有 NVMe 盘的 GPU 节点上或者用独立的高速存储池承载模型文件。6.4 推理服务 OOM 的资源边界问题推理服务的 CrashLoopBackOff 很多是 OOM 导致。要区分两种 OOM容器内存 OOM 和 GPU 显存 OOM。看kubectl describe pod里的状态OOMKilled是容器内存如果日志里有CUDA out of memory那是显存不够。显存不够的解决路径有三个层次降低--gpu-memory-utilization预留碎片空间、缩短--max-model-len、换量化模型。内存 OOM 则要检查 Pod 的内存 requests 是否大于模型加载需要vLLM 加载模型到 CPU 时会先占用与权重等大的内存配置里把 requests 设得比权重文件大 20% 以上是基本操作。7. 运维节奏与避坑心得部署完成后真正的挑战在运维。私有化环境不像公有云那样有完善的控制台很多问题要靠规划好的运维节奏来规避。7.1 集群备份与升级策略etcd 备份是我排在第一位的事务。命令很简单mkdir -p /backup/etcd ETCDCTL_API3 etcdctl snapshot save /backup/etcd/snapshot-$(date %F).db \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key备份文件别只留在本机要同步到独立的存储。我在生产环境用 cron 每天晚上做快照保留最近 7 天同时每周做一次恢复演练确保备份不是白做的。恢复演练这事很多人嫌麻烦但真正遇到 etcd 数据损坏时你会庆幸自己练过。升级策略上我坚持一点非必要不升级。私有化交付后集群跑得稳比跑得新重要得多。真要升级先在测试环境完整跑一遍同样的 Clusterfile确认全部组件版本兼容再动生产。Sealos 的集群镜像机制让升级变成一个新镜像版本的 run 操作但这不代表可以跳过测试。7.2 资源配额与多部门隔离企业大模型服务往往被多个部门共享不加配额控制一个部门的高并发推理就能把 GPU 节点资源吃光。建议在 Namespace 上配置 ResourceQuota 和 LimitRangeapiVersion: v1 kind: ResourceQuota metadata: name: ai-quota namespace: ai spec: hard: requests.cpu: 16 requests.memory: 64Gi limits.nvidia.com/gpu: 4 persistentvolumeclaims: 5这样即使某个部门误提交了一个 8 卡的推理任务也会被配额拒绝不会影响其他部门。GPU 资源尤其要设配额因为它是整个私有化环境里最贵的资源。7.3 监控告警的最后一公里很多私有化项目监控做到一半就停了Prometheus 配好、Grafana 面板好看但告警没人看等于没监控。我建议告警规则精而不多优先覆盖这几类节点 Ready 状态、GPU 卡健康状态通过 DCGM 指标、etcd 磁盘延迟、PVC 使用率、Pod 重启次数。- alert: GPUUnhealthy expr: dcgm_device_status{statusdisabled} 1 for: 5m labels: severity: critical annotations: summary: GPU device {{ $labels.gpu }} on node {{ $labels.instance }} is unhealthyGPU 卡因为温度、供电问题进入降级状态在推理服务那边表现可能是请求变慢或报错但nvidia-smi不会直接告诉你卡坏了。DCGM 指标能提前暴露这类隐患。告警通道我建议直接接企业微信或钉钉机器人别只发邮件邮件真的没人在故障发生时看。写在最后的小经验Sealos 私有化部署这条链路我前前后后交付过十多个项目最大的体会是工具本身只解决部署这一层真正决定项目成败的是配置的规范化和运维的纪律性。Clusterfile 要用版本管理、镜像版本要固定、备份要定期演练、资源配置要设配额这些动作单拎出来都不起眼但合在一起就是一套能让企业大模型服务稳定跑下去的底子。如果只让我留一句建议那就是第一次部署时不要贪多先单控制面、单 GPU 节点把 Ollama 跑通再把 vLLM、高可用、离线交付这些复杂度一层层加上去。企业大模型私有化部署不是一锤子买卖前期把地基打稳后面才有资格谈扩展。 
长河君 · 2026/10/7 4:50:35 · 阅读 1.2k Sealos企业大模型私有化部署指南：从硬件规划到GPU推理落地
1. 为什么用 Sealos 做私有化部署企业大模型私有化部署最近成了运维圈子里绕不开的话题。业务部门递过来一张需求表要私有化、要能跑 LLM、要能对接内部知识库最好一周内上线。真正接过这种需求的人都知道从裸金属到跑起一个带 GPU 调度的推理服务中间隔着一条完整的配置链路操作系统参数、容器运行时、Kubernetes 集群、存储、网络、GPU 驱动、设备插件、模型服务。任何一个环节没对齐后面全卡住。我自己的做法是凡是让我重复超过两次的部署动作一律固化成踩坑记录和配置清单下次直接照抄。Sealos 就是这套思路里非常顺手的一环。它把 Kubernetes 集群的搭建收敛成一条sealos run命令再用同样的方式叠加网络、存储、Ingress、GPU 插件然后把企业大模型这类 AI 工作负载作为普通云原生应用跑在集群里。这篇文章就是我的私有化部署配置清单分硬件规划、环境准备、集群安装、模型服务落地、问题排查五部分全部按实际可复现的粒度写你照着操作即可。1.1 Sealos 解决的到底是什么问题先解释清楚 Sealos 的定位避免你带着错误预期去用它。Sealos 不是云平台也不是 PaaS 层它的核心是一套以集群镜像Cluster Image为交付单元的 Kubernetes 发行版。你可以把它理解成装机的Ghost 镜像与软件包管理的结合底层操作系统的初始化、Kubelet 安装、etcd 启动、控制面组件配置、加入节点这些动作被打包成一个可重复执行的镜像一条命令跑完结果是一个干净可用的集群。这和传统的部署方式有本质区别。kubeadm 能给你一个最小的控制面但 CNI 要自己选、存储要自己装、Ingress 要自己配、GPU 插件要自己折腾每一步都有版本兼容性问题。Rancher 和 KubeSphere 这类产品解决的是管理面问题但他们自身也是要部署的一坨东西而且升级节奏往往跟着上游走私有化场景里容易变成新的维护负担。Sealos 的价值在于它把集群本身当作可版本化、可迁移的交付物你要的是一套生产配置直接 run 对应的镜像组合就行不需要在部署环节耗费两三天的调试时间。1.2 大模型私有化部署为什么绕不开这类工具企业大模型私有化部署的核心矛盾是模型权重和推理服务是大文件、大计算、大显存但集群基础设施却必须做到小而稳。GPU 节点要能被调度器识别和分配显存模型文件要落在持久化存储上推理服务要暴露给内部业务方调用整套链路还要能隔离不同部门的使用配额。这些需求落到 Kubernetes 里就是调度、存储、网络、网关四件事。Sealos 恰好把四件套都封装好了。更关键的是私有化环境往往没有外网条件或者只有受控的镜像仓库。Sealos 的镜像可以提前拉取、离线导入这正好匹配企业内网交付的大前提。我去年做过一个制造业客户的交付客户机房只给开了一个能访问内网镜像仓库的出口其他外网全部禁止。Sealos 在这种受限网络下依然能完成集群搭建和组件交付这是它在我清单里一直占据位置的重要原因。2. 部署前的硬件与网络规划硬件规划是私有化部署的第一个大坑。很多人一上来就按官网最低配置跑跑到一半发现 etcd 磁盘 IO 跟不上、GPU 节点内存不够模型加载最后推倒重来。这个环节不值得省时间我建议你先按下面的表格做一次容量评估再开始动服务器。2.1 控制面与通用节点的规格评估控制面节点承载 etcd、kube-apiserver、kube-controller-manager、kube-scheduler对 CPU 和磁盘 IO 的要求远高于普通业务机。etcd 对磁盘延迟极其敏感建议单独挂 SSD 数据盘不要把系统盘和数据盘混用。节点角色CPU内存系统盘数据盘数量控制面生产8 核16G100G SSD200G SSDetcd 专用3做高可用控制面测试4 核8G50G100G SSD1通用工作节点16 核64G100G SSD500G SSD 起按业务扩GPU 工作节点32 核256G100G SSD1T SSD 或 NVMe按显存需求扩测试环境我建议也别太省。跑 7B 模型至少需要 16G 内存做推理进程13B 模型建议 32G 以上加上系统开销和缓存64G 的通用节点是底线。生产环境做高可用时3 个控制面是标配etcd 数据盘必须独立这是无数人用数据换来的教训。2.2 企业大模型对 GPU 节点的真实要求GPU 选型不能只看显存大小要看你的模型规格和并发预期。推理场景的显存占用有一个经验公式显存 ≈ 模型权重大小 KV Cache 推理框架开销。以 Llama-3-8B 为例FP16 权重约 16G加上 KV Cache 和运行时开销单卡 24G如 RTX 4090、L20能跑但余量不大70B 级别模型用 FP16 至少需要约 140G 权重显存通常得 2 张 80G 的 A100/A800 做张量并行或者用 AWQ/GPTQ 4bit 量化后压到 40G 左右单卡可跑。GPU 节点的 CPU 和内存不能太低。模型加载时需要把权重文件读进内存再拷到显存内存不足会导致加载即 OOM。推理时也要做 Tokenizer、请求调度等 CPU 计算。我常用的配置是 32 核 CPU、256G 内存、2 张或 4 张 GPU。如果你只是做内部小范围试用一张 L20/4090 也能起步但要把节点规划成可横向扩容的模式否则后期加卡要动集群拓扑。另外所有 GPU 节点建议预留一块独立系统盘驱动和 CUDA 库装在系统盘上权重文件放数据盘。GPU 服务器普遍散热噪声大、功耗高机房配电和制冷也要提前确认这些虽然不是软件配置但经常成为交付进度的隐形杀手。2.3 存储规划的三种可行方案大模型私有化部署中存储是最容易被低估的。模型文件动辄几十 GB 到上百 GB推理服务的高并发读取、训练场景的 Checkpoint 写入对存储的性能要求差别很大。Sealos 默认推荐 OpenEBS它提供基于节点磁盘的openebs-hostpath存储类适合模型文件和普通应用数据。注意一点hostpath 的副本数取决于 Pod 所在节点数据不带跨节点复制节点坏了数据可能丢。对于模型权重这类可以从镜像或对象存储重建的数据问题不大但如果是业务数据库建议上独立存储方案比如对接已有 NFS 或外部存储阵列。数据类别存储方案性能要求备份策略模型权重文件openebs-hostpath / 对象存储顺序读为主SSD 即可保留原始文件不依赖 PVC 副本推理日志与业务数据独立 NFS / 分布式存储随机读写SSD每日快照或异地复制etcd节点本地独立 SSD低延迟、高 IOPS每小时快照保留 7 天网络规划方面节点之间建议千兆以上内网GPU 节点之间做推理并行时尽量走万兆或 Infiniband不然多卡通信会成为瓶颈。Sealos 默认 CNI 用 Calico它的 BGP 模式在大规模集群里表现稳定小规模集群直接用 IPIP 或者 VXLAN 模式都行后面部署时会讲到具体参数。3. 环境准备与前置检查清单这个环节是整个私有化部署里最容易翻车的地方。很多人sealos run跑一半失败回头看往往是前置条件没做干净。我总结了六个必查项每一条都对应真实踩坑经历。3.1 操作系统与内核参数建议使用 Ubuntu 22.04 LTS 或 Rocky Linux 9内核版本不低于 5.15。Debian 系的默认内核参数偏保守需要手动调整RedHat 系则需要额外注意 SELinux 和防火墙。我统一用 Ubuntu 22.04理由很简单驱动生态最全尤其是 NVIDIA GPU 驱动和 container runtime 的兼容性测试做得好省掉很多编译折腾。拿到服务器后第一件事是关 swap。Kubernetes 从 1.22 之后虽然支持部分场景的 swap 配置但生产环境我从来不开原因很直接swap 会把 kubelet 和容器的内存隔离机制搞乱导致 Pod 内存限额失效推理服务 OOM 时系统反应会变得迟钝。然后是内核参数创建/etc/sysctl.d/99-k8s.conf写入以下内容net.bridge.bridge-nf-call-iptables 1 net.ipv4.ip_forward 1 vm.swappiness 0 vm.overcommit_memory 1 fs.file-max 2097152 fs.inotify.max_user_instances 8192 fs.inotify.max_user_watches 524288执行sysctl --system生效。overcommit_memory 1这条对模型推理很重要推理框架申请大块虚拟内存时内核默认的 overcommit 策略可能直接拒绝导致进程启动即失败。3.2 主机名、DNS 与时间同步主机名规划看似小事实际影响面很大。etcd 的集群成员依赖主机名标识如果部署后改主机名可能出现 etcd 成员地址错乱的诡异问题。建议提前定好命名规则比如k8s-master-01、k8s-gpu-01并用/etc/hosts固定所有节点的主机到 IP 的映射避免依赖内网 DNS。时间同步用 chrony理由是对时钟漂移极为敏感的 Kafka、etcd 和 CSI 插件。不同步的时间会造成证书校验失败、监控指标错乱甚至 etcd 选举异常。安装配置命令如下apt install -y chrony systemctl enable --now chrony chronyc sources -v输出的^*表示已同步成功。如果公司内网有 NTP 源记得修改/etc/chrony/chrony.conf指向内网源外网源在私有化环境里往往不可达。3.3 安装 Sealos 命令行工具Sealos 的安装本身很简单下载二进制放到PATH下即可。在能访问外网的机器上可以直接从官方发布渠道下载对应版本。私有化环境则建议先在跳板机上下载好再通过内网分发到各节点。wget https://github.com/labring/sealos/releases/download/v4.3.7/sealos_v4.3.7_linux_amd64.tar.gz tar zxvf sealos_v4.3.7_linux_amd64.tar.gz chmod x sealos mv sealos /usr/local/bin/ sealos version有一个容易踩的坑Sealos 各小版本的集群镜像兼容性不完全一致我建议固定使用一个经过验证的版本组合比如 Sealos v4.3.7 Kubernetes v1.28.0 Calico v3.26.1。不要随手升级尤其不要在生产环境用latest标签拉镜像。另外执行命令的机器必须有各节点的 SSH 访问权限Sealos 是通过 SSH 远程执行安装逻辑的你需要提前准备好 root 密码或密钥。3.4 SSH 免密与安装用户准备Sealos 的节点接入依赖 SSH传统做法是让安装机免密登录所有目标节点。我通常用专门的部署账号把它加入sudo组并在各节点写入它的公钥。需要说明的是Sealos 也支持直接用--pk-passwd参数传 root 密码但那个方式在密码复杂度高或含特殊字符时容易出问题我还是推荐密钥方式。一个容易被忽略的配置是各节点sshd的MaxSessions和MaxStartups。集群规模在 10 台以上时Sealos 会并发建立 SSH 会话默认值可能不够表现为部分节点连接超时。建议在/etc/ssh/sshd_config中配置MaxSessions 50和MaxStartups 50:30:100然后重启 sshd。4. 集群部署实操与关键参数前置准备做完集群搭建反而成了最轻松的部分。Sealos 的核心命令就几条但每条命令后面的镜像标签、参数含义、执行顺序都有讲究。这一节我按实际执行顺序写。4.1 初始化控制面与添加节点初始化命令的基本形态如下sealos run kubernetes:v1.28.0 calico:v3.26.1 openebs:v3.9.0 ingress:v1.9.4 \ --masters 192.168.1.11,192.168.1.12,192.168.1.13 \ --nodes 192.168.1.14,192.168.1.15,192.168.1.16 \ --ssh-key /root/.ssh/id_rsa这条命令会同时完成三台控制面的高可用部署、三台工作节点的加入以及 Calico、OpenEBS、Ingress 组件的安装。执行时间取决于网络环境通常 5 到 15 分钟。如果中途失败不要盲目重跑先看日志定位原因。常见的是某台机器 SSH 不通、磁盘未格式化、镜像拉取超时。修复后直接重跑同一命令Sealos 具备幂等性不会重复创建已有资源。关于高可用的说明--masters传三台会部署 etcd 三节点集群这是生产环境推荐的形态。如果只有两台控制面etcd 的 quorum 是 2任何一台挂掉集群就只剩 1 票写不进去实际上没有高可用价值。资源不够的情况下宁可先单控制面也别做两台这种假高可用。4.2 用 Clusterfile 固化你的部署配置命令行的方式适合临时验证但私有化交付需要可重复我建议把配置写成 Clusterfile。这是一个 YAML 文件记录集群的节点拓扑、镜像列表、SSH 信息后续扩容或重装直接复用。apiVersion: apps.sealos.io/v1beta1 kind: Cluster metadata: name: my-enterprise-cluster spec: infra: hosts: - ips: [192.168.1.11, 192.168.1.12, 192.168.1.13] roles: [master] - ips: [192.168.1.14, 192.168.1.15] roles: [node] ssh: user: root passwd: your-secure-password image: - kubernetes:v1.28.0 - calico:v3.26.1 - openebs:v3.9.0 - ingress:v1.9.4然后执行sealos apply -f Clusterfileapply和run的差异在于apply会读取并应用整个 Clusterfile 的期望状态适合交付运维团队使用。我把 Clusterfile 提交到 Git 仓库管理版本化之后任何一次部署都能追溯到当时用的是什么镜像、什么节点拓扑。这个习惯在客户现场救过我很多次。4.3 核心组件版本固定与镜像离线导入私有化环境最麻烦的是镜像来源。Sealos 默认从阿里云镜像仓库拉取社区镜像如果客户环境完全离线需要提前准备好离线包。好在 Sealos 支持打包和导入流程是先在一台能连外网的机器上把镜像拉下来sealos pull kubernetes:v1.28.0 sealos pull calico:v3.26.1 sealos pull openebs:v3.9.0 sealos pull ingress:v1.9.4然后打成一个离线 tar 包搬运到内网机器再在部署机上导入。实际操作中我一般会导出到一个 U 盘或者内网共享目录分发给各节点后执行导入。版本固定的原则在这里尤其重要拉镜像的时候如果写成latest你拿到内网的镜像内容可能和当初验证的不一致客户现场就会成为你测试新版本的场所。4.4 验证集群健康状态集群搭建完成后先别急着部署业务。用下面几个命令做一次健康检查花五分钟可以省下后面几小时的排查时间kubectl get nodes -o wide kubectl get pods -A kubectl get sc检查点有三个节点状态必须全是Ready系统组件的 Pod 不能有CrashLoopBackOff或PendingStorageClass 必须存在且默认标记正确。另外建议执行一次 etcd 健康检查kubectl -n kube-system exec etcd-master-01 -- etcdctl endpoint health --cluster输出类似127.0.0.1:2379 is healthy即正常。如果这里有问题说明控制面节点之间的网络或磁盘有问题要优先处理否则后面的业务部署随时被隐含故障打断。5. 企业大模型私有化部署实操集群就绪后走到核心环节把企业大模型跑起来。这个环节的配置集中在 GPU 驱动、设备插件、推理服务三块我按照一条完整链路写下来。5.1 GPU 驱动、运行时与设备插件推理服务要用到 GPU必须先做三件事安装 NVIDIA 驱动、配置 nvidia-container-toolkit、部署 device plugin。驱动安装建议用 NVIDIA 官方 deb 包或 runfile不要用系统源里的旧驱动。以 Ubuntu 22.04 为例nvidia-smi # 如果未安装先安装驱动 apt install -y nvidia-driver-535 reboot nvidia-smi驱动装好只是第一层。容器要访问 GPU还必须在节点上装 nvidia-container-toolkit这样 containerd 才能给容器注入 GPU 设备。常见的问题是驱动装好了、节点也 Ready但 Pod 调度到 GPU 节点后报Failed to allocate gpu memory那就是 toolkit 没装或者配置没生效。toolkit 安装后需要重启 containerd。然后通过 Sealos 部署 NVIDIA 设备插件sealos run nvidia-device-plugin:v0.14.0部署完成后验证节点资源kubectl get nodes -o json | jq .items[].status.allocatable能看到nvidia.com/gpu: 2这样的字段说明 GPU 已经被调度器识别。走到这一步集群层面的 GPU 能力才算真正打通。5.2 用 Ollama 快速落地内部推理服务Ollama 是目前把开源模型私有化跑起来最快的方案对小型企业和测试环境尤其合适。它自带模型管理一条命令就能拉取 Llama 3、Qwen 等主流模型。部署方式就是一个普通 DeploymentKubernetes 里面对它唯一要做的就是给它挂足够的存储和 GPU 配额。apiVersion: v1 kind: Namespace metadata: name: ai --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ollama-models namespace: ai spec: accessModes: - ReadWriteOnce storageClassName: openebs-hostpath resources: requests: storage: 200Gi --- apiVersion: apps/v1 kind: Deployment metadata: name: ollama namespace: ai spec: replicas: 1 selector: matchLabels: app: ollama template: metadata: labels: app: ollama spec: containers: - name: ollama image: ollama/ollama:0.1.32 ports: - containerPort: 11434 resources: limits: nvidia.com/gpu: 1 memory: 64Gi requests: memory: 32Gi volumeMounts: - name: models mountPath: /root/.ollama volumes: - name: models persistentVolumeClaim: claimName: ollama-models这里有两个细节容易踩坑。第一模型目录挂载到/root/.ollama而不是/root/.ollama/models因为 Ollama 的官方镜像里进程用户虽然是 root但模型索引、日志都在.ollama目录下挂整个目录才不会出现模型下载一半就报盘满的怪问题。第二nvidia.com/gpu的 request 不需要写limits 写多少就是实际占用的显卡数量写 1 表示占满整张卡多模型共享一张卡的场景需要配合显存调度方案Ollama 默认不支持需要额外做显存切分。部署完成后进入 Pod 拉模型kubectl exec -it deploy/ollama -n ai -- ollama pull llama3:8b kubectl exec -it deploy/ollama -n ai -- ollama pull qwen2.5:7b然后在集群内用Service暴露 11434 端口内部业务系统就可以通过http://ollama.ai.svc.cluster.local:11434调用了。5.3 用 vLLM 支撑高并发推理如果内部业务并发上来了或者是一次要同时服务多个部门Ollama 的吞吐会吃紧这时建议切到 vLLM。vLLM 的优势在于 PagedAttention 显存管理和 Continuous Batching吞吐量比原生推理框架高一个量级。中国团队开源的 Qwen 系列等主流模型对 vLLM 支持都很好生产中非常成熟。vLLM 的部署配置里最重要的是命令行参数这里给出一个可用于生产的模板apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen namespace: ai spec: replicas: 1 selector: matchLabels: app: vllm-qwen template: metadata: labels: app: vllm-qwen spec: containers: - name: vllm image: vllm/vllm-openai:latest command: - python3 - -m - vllm.entrypoints.openai.api_server - --model - /models/qwen/Qwen2.5-14B-Instruct - --served-model-name - qwen2.5-14b - --tensor-parallel-size - 2 - --max-model-len - 32768 - --gpu-memory-utilization - 0.92 - --port - 8000 env: - name: HUGGINGFACE_HUB_CACHE value: /models ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 2 memory: 128Gi volumeMounts: - name: models mountPath: /models volumes: - name: models persistentVolumeClaim: claimName: model-weights-pvc几个参数值得展开说。--tensor-parallel-size 2表示把模型切分到两张 GPU 上这个值必须和 limits 里的 GPU 数一致且最好在模型加载前就确定中途改会导致显存重新布局。--gpu-memory-utilization 0.92表示最多用 92% 的显存做推理留一点余量给上下文切换和碎片设成 0.99 虽然显存利用率高但并发上来后很容易触发 OOM。--max-model-len 32768是上下文窗口越长越占显存一般内部知识库问答用 8K 到 32K 足够不建议盲目拉高。模型权重文件管理是这个环节最容易出问题的地方。我通常在 PVC 里放一个目录用kubectl cp或者直接在 Pod 里用huggingface-cli下载模型下载完成后把 Deployment 的readinessProbe配置指向模型加载完成的端点避免后端流量把未就绪的推理服务打崩。5.4 模型服务的网关暴露与鉴权推理服务跑起来后要决定如何暴露给内部使用方。这里我推荐用 Sealos 自带 Ingress 组件Traefik配置以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: vllm-ingress namespace: ai spec: ingressClassName: nginx rules: - host: llm.internal.example.com http: paths: - path: / pathType: Prefix backend: service: name: vllm port: number: 8000私有化环境中 DNS 解析要落在内网 DNS 服务器上证书用内部 CA 签发不要在客户端跳过证书校验。更严谨的做法是在 Ingress 前加一层网关做 API Key 鉴权因为大模型服务一旦暴露出去又不加鉴权内网里任何知道地址的人都能消耗你的 GPU 资源这类事故我见过不止一次。6. 常见问题与排查技巧实录部署和运维过程中遇到的问题90% 都集中在几个固定区域。我整理了一张排查速查表每一条都是实际验证过的解决路径。6.1 节点 NotReady 的通用排查清单现象常见原因解决路径kubelet 服务未运行安装时 systemd 未刷新systemctl daemon-reload systemctl restart kubeletCNI 插件冲突多套 CNI 重复部署检查/etc/cni/net.d下残留配置清理后重启 kubelet磁盘压力导致驱逐数据盘使用率超阈值清理旧镜像、日志或调整image-gc-high-threshold节点时间偏差大chrony 未同步修 NTP 源重启 chrony 和 kubelet内核参数未生效未执行 sysctl重新sysctl --system并重启容器运行时我的经验是NotReady 问题不要一上来就猜原因先看kubectl describe node name里的 Conditions 和事件再逐个条件排查。有一次客户现场控制面节点 NotReady日志指向 kubelet 无法连接 apiserver最后发现是业务侧在服务器上改了防火墙规则把宿主机的 6443 端口给拦了。这类问题靠远程看日志很难定位必须到节点现场采集系统状态。6.2 GPU 不可调度的典型原因GPU 资源没出现在allocatable里最常见的原因是 device plugin 没跑起来。先确认 Pod 状态kubectl -n kube-system get pods | grep nvidia如果 Pod 是CrashLoopBackOff看日志大概率是 toolkit 没装或者驱动版本太新与插件不兼容。NVIDIA 官方插件的版本通常滞后于新驱动遇到这种情况建议回退驱动版本而不是升级插件去追新。另一种隐蔽情况是 GPU 节点的kubelet上报了nvidia.com/gpu: 0。这是因为 device plugin 注册成功但 runtime class 没配对容器运行时找不到 GPU。检查 containerd 配置里是否加载了nvidia-container-runtime加载后必须重启 containerd 才能生效。6.3 模型加载缓慢与存储瓶颈大型模型文件从 PVC 读取时如果存储是普通机械盘或网络延迟大的 NFS加载 70B 模型可能要等上十几分钟甚至更久。排查时先看推理服务启动日志里模型加载耗时再看 PVC 所在节点的磁盘 IO 状态。我踩过的坑是 OpenEBS hostpath 的 PVC 被调度到了某个 IO 繁忙的节点上模型加载期间整个节点的 IO 被打满其他业务也受影响。解决方案是在 StorageClass 里设置nodeAffinity让模型权重相关的 PVC 固定落在有 NVMe 盘的 GPU 节点上或者用独立的高速存储池承载模型文件。6.4 推理服务 OOM 的资源边界问题推理服务的 CrashLoopBackOff 很多是 OOM 导致。要区分两种 OOM容器内存 OOM 和 GPU 显存 OOM。看kubectl describe pod里的状态OOMKilled是容器内存如果日志里有CUDA out of memory那是显存不够。显存不够的解决路径有三个层次降低--gpu-memory-utilization预留碎片空间、缩短--max-model-len、换量化模型。内存 OOM 则要检查 Pod 的内存 requests 是否大于模型加载需要vLLM 加载模型到 CPU 时会先占用与权重等大的内存配置里把 requests 设得比权重文件大 20% 以上是基本操作。7. 运维节奏与避坑心得部署完成后真正的挑战在运维。私有化环境不像公有云那样有完善的控制台很多问题要靠规划好的运维节奏来规避。7.1 集群备份与升级策略etcd 备份是我排在第一位的事务。命令很简单mkdir -p /backup/etcd ETCDCTL_API3 etcdctl snapshot save /backup/etcd/snapshot-$(date %F).db \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key备份文件别只留在本机要同步到独立的存储。我在生产环境用 cron 每天晚上做快照保留最近 7 天同时每周做一次恢复演练确保备份不是白做的。恢复演练这事很多人嫌麻烦但真正遇到 etcd 数据损坏时你会庆幸自己练过。升级策略上我坚持一点非必要不升级。私有化交付后集群跑得稳比跑得新重要得多。真要升级先在测试环境完整跑一遍同样的 Clusterfile确认全部组件版本兼容再动生产。Sealos 的集群镜像机制让升级变成一个新镜像版本的 run 操作但这不代表可以跳过测试。7.2 资源配额与多部门隔离企业大模型服务往往被多个部门共享不加配额控制一个部门的高并发推理就能把 GPU 节点资源吃光。建议在 Namespace 上配置 ResourceQuota 和 LimitRangeapiVersion: v1 kind: ResourceQuota metadata: name: ai-quota namespace: ai spec: hard: requests.cpu: 16 requests.memory: 64Gi limits.nvidia.com/gpu: 4 persistentvolumeclaims: 5这样即使某个部门误提交了一个 8 卡的推理任务也会被配额拒绝不会影响其他部门。GPU 资源尤其要设配额因为它是整个私有化环境里最贵的资源。7.3 监控告警的最后一公里很多私有化项目监控做到一半就停了Prometheus 配好、Grafana 面板好看但告警没人看等于没监控。我建议告警规则精而不多优先覆盖这几类节点 Ready 状态、GPU 卡健康状态通过 DCGM 指标、etcd 磁盘延迟、PVC 使用率、Pod 重启次数。- alert: GPUUnhealthy expr: dcgm_device_status{statusdisabled} 1 for: 5m labels: severity: critical annotations: summary: GPU device {{ $labels.gpu }} on node {{ $labels.instance }} is unhealthyGPU 卡因为温度、供电问题进入降级状态在推理服务那边表现可能是请求变慢或报错但nvidia-smi不会直接告诉你卡坏了。DCGM 指标能提前暴露这类隐患。告警通道我建议直接接企业微信或钉钉机器人别只发邮件邮件真的没人在故障发生时看。写在最后的小经验Sealos 私有化部署这条链路我前前后后交付过十多个项目最大的体会是工具本身只解决部署这一层真正决定项目成败的是配置的规范化和运维的纪律性。Clusterfile 要用版本管理、镜像版本要固定、备份要定期演练、资源配置要设配额这些动作单拎出来都不起眼但合在一起就是一套能让企业大模型服务稳定跑下去的底子。如果只让我留一句建议那就是第一次部署时不要贪多先单控制面、单 GPU 节点把 Ollama 跑通再把 vLLM、高可用、离线交付这些复杂度一层层加上去。企业大模型私有化部署不是一锤子买卖前期把地基打稳后面才有资格谈扩展。