大模型私有化算力平台建设基于虚拟化切分与统一网关的异构集群纳管实战在多团队共用异构算力的场景下算力闲置与资源抢占往往同时发生。算法团队抱怨申请一张整卡跑轻量实验太浪费而线上生产推理服务在高峰期却拿不到整卡资源。为了打破这种算力孤岛我们在 Kubernetes 之上搭建了一套支持物理整卡、vGPU 切分与统一网关纳管的企业级私有化 AI 算力平台。整个平台的核心目标非常明确屏蔽底层硬件差异向下纳管多种架构的 GPU 硬件向上提供统一的声明式申请 API 与请求级流量网关。flowchart TD subgraph 接入与控制面 Client[客户端请求] -- APIGateway[AI 统一推理网关] APIGateway -- RouteEngine[模型路由与配额鉴权] end subgraph 算力调度与虚拟化 RouteEngine -- KubeScheduler[扩展调度器] KubeScheduler -- NodeA[A100/H800 整卡计算节点] KubeScheduler -- NodeB[vGPU 切分节点 显存/算力隔离] KubeScheduler -- NodeC[国产异构加速卡节点] end subgraph 底层设备纳管 NodeB -- CgroupDriver[显存 Cgroup 硬隔离] NodeB -- DevicePlugin[Extended Device Plugin] end1. 异构算力纳管与 vGPU 虚拟化切分方案在统一纳管异构算力时首要问题是解决显存切分与算力隔离。整卡直通模式对微调和重度推理非常合适但对于日常调试、LoRA 浅层推理或 Embedding 服务整卡利用率经常低于 15%。我们采用了基于内核层拦截与动态库劫持相结合的虚拟化技术方案在 Device Plugin 层面将物理卡抽象为显存Memory与算力核心Core两个维度的扩展资源apiVersion: apps/v1 kind: Deployment metadata: name: qwen-embedding-service namespace: ai-platform spec: replicas: 4 selector: matchLabels: app: qwen-embedding template: metadata: labels: app: qwen-embedding spec: containers: - name: embedding-server image: registry.internal/ai/embedding:v1.4 resources: limits: cpu: 4 memory: 8Gi nvidia.com/gpu-mem: 6144 # 申请 6GB 显存切片 nvidia.com/gpu-core: 30 # 限制 30% 计算时间片 requests: cpu: 2 memory: 4Gi nvidia.com/gpu-mem: 6144 nvidia.com/gpu-core: 30通过扩展资源上报Kubernetes 可以将一台搭载 80GB 显存的物理节点切分为十几个相互隔离的轻量推理实例。当某个实例发生显存泄漏或突发 OOM 时只会被虚拟驱动层隔离并杀掉自身容器绝不影响同卡上的其他业务 Pod。2. 统一推理网关的流量路由与鉴权控制在集群之上统一网关扮演了流量总控的角色。所有前端业务系统不再直接调用后端的具体 Pod IP而是通过统一网关进行基于模型名称、租户 Token、优先级和版本号的路由分发。网关层基于 Go 语言构建内置了基于令牌桶的速率限制与动态连接池管理package gateway import ( context errors net/http sync time ) type TenantQuota struct { MaxConcurrent int64 CurrentActive int64 mu sync.Mutex } func (q *TenantQuota) Acquire() bool { q.mu.Lock() defer q.mu.Unlock() if q.CurrentActive q.MaxConcurrent { return false } q.CurrentActive return true } func (q *TenantQuota) Release() { q.mu.Lock() defer q.mu.Unlock() if q.CurrentActive 0 { q.CurrentActive-- } } type ModelRouter struct { tenants map[string]*TenantQuota mu sync.RWMutex } func (r *ModelRouter) RouteRequest(ctx context.Context, tenantID, modelName string, handler http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, req *http.Request) { r.mu.RLock() quota, exists : r.tenants[tenantID] r.mu.RUnlock() if !exists { http.Error(w, 未授权的租户凭证, http.StatusForbidden) return } if !quota.Acquire() { http.Error(w, 租户并发度超限请降级或稍后重试, http.StatusTooManyRequests) return } defer quota.Release() // 执行实际的反向代理转发 handler(w, req) } }网关支持热更新路由表。当底层模型服务完成金丝雀升级或者动态扩容后网关在 50ms 内即可通过集群 Watch 机制拉取最新的后端实例列表实现无损流量切换。3. 生产落地中的边界防御与避坑实践在实际运行过程中异构算力平台的稳定性往往受制于边缘异常第一驱动与 CUDA 版本的兼容性矩阵必须严格锁定。平台在节点接入阶段运行 DaemonSet 初始化检查容器校验宿主机驱动、NVLink 状态以及 Fabric Manager 是否正常任何一项不达标则自动给节点打上不可调度污点Taint。第二显存碎片整理与定时回收。在长时间运行低优先级任务后显存切片可能会产生大量微小空洞导致大模型无法分配连续显存。平台通过在夜间低峰期执行 Pod 驱逐与重排确保次日业务高峰期能够快速容纳大颗粒度任务。第三严密布防网络 IO 瓶颈。多卡分布式推理服务如 DeepSeek、LLaMA 等通过 Tensor Parallel 跨卡运行的模型对跨卡互联带宽极度敏感。我们强制在调度规则中加入物理拓扑亲和约束严禁将同一个模型的并行进程分散在无 NVLink 支持的异构插槽上。通过这套覆盖设备层切分、控制面编排与接入层网关的完整体系我们将集群整体 GPU 显存利用率由原本的 28% 提升至 67%同时彻底杜绝了不同业务组因资源争抢导致的线上突发不可用事故。