去年底有个做制造业的客户找我说他们想在内部跑一个大模型问答系统但所有生产数据严格禁止出内网不能调用任何公有云 API。我的第一反应是配一台桌面级显卡工作站装个 Ubuntu 跑 Ollama 就算了。后来真正落地才发现企业内部做私有 AI 服务难点从来不是装软件而是 GPU 资源怎么和现有虚拟化平台对齐、多部门怎么共用、模型端点怎么安全地开放给业务系统。这篇文章就是把这套思路和实操链路完整记录下来希望能给同样准备在 VCF 9.0 环境里跑 AI 服务的团队一点参考。先说一个结论VMware VCF 9.0 这个版本在私有 AI 这件事上做得比 8.x 顺滑很多最大的变化是 GPU 不再只是某台 ESXi 主机上的一块卡而是可以被池化、被调度、被切分后按需分配给虚拟机或 Kubernetes 工作负载。这对用普通 GPU 搭建专属模型端点这个需求来说是一条非常自然的路。1. VCF 9.0 在私有 AI 这件事上做了哪些别人没做的1.1 从一台 GPU 一台虚拟机到GPU 资源池大家应该都有印象以前在 vSphere 里跑 GPU 工作负载基本就两种姿势要么把整块物理 GPU 通过直通模式绑给某一台虚拟机要么用 NVIDIA 的 vGPU 技术手动把卡切片再一块块手动挂到虚拟机上。直通模式的问题很明显——一块卡只能给一台虚拟机用几个部门各要一个模型端点时你就得买好几块卡而且每块卡的利用率可能都不到 20%vGPU 则需要额外维护一套 license 和调度逻辑配置复杂普通运维碰一次就头皮发麻。VCF 9.0 的做法是引入GPU 资源池这个抽象层。你先把宿主机上的物理 GPU可以跨多台主机统一收进一个池子然后在创建虚拟机或者部署 Tanzu Kubernetes 工作负载集群时直接向这个池子申请资源。至于底层到底是直通、SR-IOV 还是 vGPU平台自动处理大部分调度逻辑。对用户来说GPU 变成了像 CPU、内存一样可以直接分配的资源而不是绑死在某台物理机上的特殊硬件。这里要特别提醒一下VCF 9.0 的 GPU 池机制在工作负载类型上有一个很实际的分界线如果只跑一个模型端点用虚拟机直挂 vGPU 是最省心的如果要做多模型、多租户、自动扩缩容那走 Tanzu 工作负载集群才是正路。两种路线我在第 3 节会分别展开。1.2 模型端点到底是什么为什么需要单独部署很多刚开始接触私有 AI 的同学会把部署模型和写代码调模型混在一起。实际上模型本身只是一堆权重参数文件真正让业务系统能用到模型的是一个跑在服务器上的常驻推理程序它负责加载模型到显存、接收外部请求、把 prompt 变成 tokens 交给模型计算、再把输出 tokens 解码成文字返回。这个常驻程序加它暴露出来的 HTTP 接口就是模型端点。我习惯用一个类比模型端点相当于自助餐厅的打饭窗口。厨房里的大锅菜模型参数一直在锅里热着就餐的人业务系统不关心后厨怎么切菜炒菜只需要到窗口递盘子HTTP 请求就能拿到菜推理结果。每个模型端点背后由三部分组成模型权重文件、推理服务框架Ollama/vLLM/TGI 之类、以及一块能装下模型和中间计算结果的显存。既然是专属模型端点核心诉求就是三件事模型跑在你自己内网、端点接口形态可控、对并发和延迟有相对确定的保障。这些诉求决定了我们不会把模型权重复制到每台终端机器上而是集中在私有环境里做成标准服务再让各个业务系统通过 API 来调用。1.3 一个普通企业场景的画像我给客户做的那套环境算是一个典型的普通 GPU 私有 AI场景硬件单台或者两三台已经跑在 VCF 9.0 集群里的 ESXi 宿主机每台插一块 NVIDIA L4 24GB 或者 RTX 4090 24GB模型开源的中小型模型7B 到 32B 之间的量化版本主要做内部知识库问答和工单摘要使用方内部三个系统调用端点知识库助手、客服质检、研发的日志分析工具约束数据不出内网不能注册任何外部 SaaS 服务端点必须有鉴权这个画像是我写下面内容的基础。如果你的场景是单卡要跑 70B 模型或者要支撑 100 并发那很多选型和参数要重新算我会在涉及的地方额外标注。2. 动手前先算账GPU 显存、模型大小与并发量的换算关系2.1 显存估算公式与常见模型对照很多人选 GPU 只看参数数量和显存越大越好但真正在私有环境部署时显存需求是可以算出来的。核心公式不复杂模型加载显存 模型权重文件大小 推理上下文显存KV Cache 推理框架自身开销对一个 7B 模型来说FP16 全精度权重约 14GBQ4_K_M 量化后约 4.4GBQ8 约 7.8GB。8B 模型 Q4 量化后约 5.2GB 左右。如果你用 L424GB跑一个 Q4 的 7B/8B 模型权重大概只占 5-6GB剩下的空间全留给 KV Cache 和并发请求。这也是为什么一张 24GB 的普通卡足够企业内部小规模推理服务跑起来不需要一上来就上 A100。下面这张表是我在实际部署中经常对照的参考值基于 Q4_K_M 量化、默认上下文长度4K-8K、单并发条件下估算模型参数规模显存占用约推荐最低显存典型卡型1.5B1.0-1.5GB4GB核显都能跑7B/8B5-7GB12GBRTX 3060 12GB / L413B/14B9-12GB16GBRTX 4090 24GB / L432B20-24GB32GBL40S 48GB / 双卡70B40-48GB64GBA100 80GB / 多卡有个容易被忽视的点上面的表是单并发的静态占用一旦业务系统把同一时刻的请求数提上来KV Cache 会线性增长显存会肉眼可见地往上跳。这也是为什么第 3 节我会推荐 vLLM——它在调度上能显著提升并发上限而不是让每个请求各自占用一整份显存。2.2 直通、vGPU、GPU Pool 三种模式怎么选在 VCF 9.0 里GPU 资源按使用方式可以分成三种形态它们的透明度和隔离性各有取舍。第一种是普通直通整卡绑定一整台虚拟机。优点是完全隔离、性能无损、驱动匹配最简单一张卡上的显存全部归这台 VM 用缺点是无法拆分一块 24GB 的卡跑 7B 模型只用了 6GB剩下的空间基本浪费。第二种是 NVIDIA vGPU把一块物理 GPU 切成多个虚拟 GPU 实例每个 VM 拿到的是虚拟设备。VCF 9.0 会把底层的 vGPU 切分方式和显存配额封装进 GPU 池的定义里你在创建 VM 时只需要选要多少显存。这种模式的资源利用率最高但需要 NVIDIA vGPU license且不是所有显卡都支持 vGPU 切分。第三种是 VCF 9.0 的 GPU Pool它严格来说是上面两种准备工作的统一入口。你创建一个 GPU 池池子里放着若干物理 GPU 以及允许的分配策略后续无论是手动创建 VM 还是部署 Tanzu Kubernetes 集群都从这个池子申请 GPU 资源。我的建议是军工/金融这类对隔离要求极高的场景用直通或整卡 vGPU一般企业内部跑模型端点优先用 vGPU 切分模式宁可单卡多分给几个小模型也别让显存空着如果想做生产级的多租户推理平台那就以 GPU Pool 为核心粒度直接接到 Tanzu 的节点池上。2.3 消费级显卡的隐藏门槛标题写了普通 GPU很多朋友第一反应是那我用 RTX 3090/4090 行不行。答案是可以但有几个隐藏门槛必须先说清楚。第一vSphere 的 GPU 池机制虽然很顺滑但它对消费级显卡的 vGPU 切分支持是受限的。NVIDIA 的 vGPU 功能只对专业卡和数据中心卡开放RTX 4090 在多数版本下只能走直通不能做 vGPU 切分。也就是说消费级卡可以进 GPU 池但通常是以整卡直通的形态存在你想一张卡切成两个 12GB 给两台 VM 用消费级卡基本没戏。第二ESXi 的驱动兼容性列表对消费级卡的覆盖不如专业卡全。我遇到过 RTX 4090 在部分 ESXi 版本上直通后虚拟机里 GPU 掉卡、Windows 虚拟机直接重启的情况。所以如果预算允许企业环境我更推荐 NVIDIA L424GB、A1024GB这种单槽低功耗专业卡真要用消费级卡建议先在测试环境把直通、驱动、压力跑完一遍再上生产。第三消费级卡在设计上不擅长 7x24 小时持续满载。单个模型端点的 GPU 利用率通常不会一直 100%但如果并发上来了消费级卡的散热和供电冗余会先到头。企业内部做模型端点稳定性优先级高于峰值性能这一点最好提前跟业务方对齐预期。2.4 存储网络的最低配置清单GPU 资源只是模型端点的一个维度存储和网络同样会卡脖子而且往往是小白最容易忽略的地方。模型文件的大小很吓人一个 8B 模型量化后约 5GB一个 70B 模型量化后约 40GB如果再加上推理框架镜像、微调数据几个模型版本轮流切换时几百 GB 是很正常的量。所以 vSAN 数据存储建议预留至少 200GB 可用空间给模型文件如果有多台 ESXi 主机尽量让存储走 vSAN ESA 或 NVMe 全闪避免从机械盘加载模型的冷启动时间过长。网络方面模型端点的请求和响应体积通常不大一个请求几十几百 KB但如果是知识库场景embedding 模型要把大量文档向量化内部 API 的调用频率会很高。最低要求是端点所在 VLAN 与其他业务网段之间开通 8443 或 11434 之类端口的访问规则并记录好源网段方便后续在 NSX DFW 上收紧。我在实际部署中发现网络瓶颈很少出现在带宽不够而是出现在防火墙规则太松导致流量不可控或太紧导致业务方调了半天调不通。建议一开始就明确模型端点只允许内网特定网段访问这是安全底线。3. 完整部署过程从 VCF 资源池到第一个可用 AI 服务3.1 路线A只跑一个模型端点虚拟机直挂 GPU如果你的需求就是给业务方快速提供一个能用的模型接口不要嫌这条路简单它反而是大多数中小团队的最优解。整个流程如下第一步在 VCF 9.0 中把物理 GPU 收进资源池。登录 vCenter找到对应的计算集群在 GPU 池GPU Pool入口新建一个池把集群里空闲的物理 GPU 勾选进去。这里要注意 vGPU 模式需要提前填好 NVIDIA license server 的地址和类型license 类型直接决定能切的 vGPU 规格上限。第二步创建一台 Ubuntu Server 22.04/24.04 LTS 虚拟机分配 8 核 CPU、32GB 内存、100GB vSAN 存储。然后给这台 VM 添加 GPU 设备编辑虚拟机设置时选择添加其他设备在设备类型里选 NVIDIA vGPU 或 PCIe 直通设备再指定从哪个 GPU 池分配资源。保存后这台 VM 就拥有一块虚拟 GPU 了。第三步启动 VM安装 NVIDIA vGPU 对应的客户机驱动。这个驱动不能在 NVIDIA 官网随便下最新的 Game Ready 驱动要用和 vSphere 平台版本匹配的 vGPU 驱动包。装完后执行nvidia-smi如果能看到显卡型号和显存容量就说明 GPU 路径已经打通。第四步安装推理服务。先用最省事的 Ollama一句命令搞定安装curl -fsSL https://ollama.com/install.sh | sh。然后拉取模型ollama pull llama3.1:8b-instruct-q4_K_M。启动服务时用环境变量把监听地址改成0.0.0.0这样同一内网的其他机器才能访问。第五步测试端点是否可用curl http://VM-IP:11434/api/chat -d { model: llama3.1:8b-instruct-q4_K_M, messages: [{role: user, content: 用一句话介绍你自己}] }能返回 JSON 就说明模型端点已经建好了。Ollama 的写法基本是零学习成本适合先把服务跑起来的阶段。3.2 路线B走 TKG把 GPU 端点变成 Kubernetes 服务如果业务方不止一个后续还要上多模型、自动扩缩容、按命名空间隔离那虚拟机直跑路线就不够优雅了。这时候用 VCF 9.0 自带的 Tanzu Kubernetes GridTKG走容器化路线是更合适的选择。第一步在 VCF 9.0 中确认 Tanzu 功能已经启用并创建一个 Supervisor Namespace。这个命名空间是后续资源配额和权限的边界建议把 GPU 池绑定到这个命名空间上这样之后创建的工作负载集群就能从池子里申请 GPU。第二步创建 Tanzu Kubernetes 集群时在节点池配置里勾选启用 GPU选择一个型号为 GPU 的节点池模板。TKG 会根据 VCF 平台侧的 GPU 池配置自动给每个节点 VM 挂上 vGPU。这里注意节点池的 VM 模板最好选一个大一点的规格因为 GPU 推理服务通常吃内存32GB 是最低起步。第三步集群创建完成后先确认 GPU 是否真的出现在 K8s 节点上kubectl get nodes -o json | jq .items[].status.allocatable如果看到nvidia.com/gpu这个资源并且数值大于 0就说明 GPU 已经被 K8s 感知了。这一步可能会因为 vGPU device plugin 没装而失败需要看集群初始化日志里有没有 GPU plugin 相关错误。第四步部署推理服务。以下是一个 vLLM 的 Deployment 示例能直接推理 Qwen2.5-7B-Instruct 模型并且暴露 OpenAI 兼容端点apiVersion: apps/v1 kind: Deployment metadata: name: vllm-qwen25-7b namespace: ai-endpoint spec: replicas: 1 selector: matchLabels: app: vllm-qwen25-7b template: metadata: labels: app: vllm-qwen25-7b spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [python3, -m, vllm.entrypoints.openai.api_server] args: - --model - Qwen/Qwen2.5-7B-Instruct - --quantization - gptq - --dtype - float16 - --max-model-len - 8192 - --gpu-memory-utilization - 0.85 env: - name: VLLM_PORT value: 8000 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1第五步用 Service Ingress 把 8000 端口暴露给集群内和外部系统。Service 类型选 LoadBalancer 或 ClusterIP 配合 Ingress 都可以关键是记录好最终的访问地址和端口。到这一步你已经拥有了一个跑在 Kubernetes 上的模型端点后续如果要增加 GPU 副本改replicas和limits.nvidia.com/gpu就行扩缩容都是平台在管。3.3 推理服务选哪个Ollama、vLLM 还是 NIM很多人在推理框架这个环节纠结很久。我的判断维度就三个部署难度、并发性能、生态兼容性。Ollama 是部署难度最低的非常适合验证环境和单机小流量场景。它把模型下载、加载、API 暴露全封装好了一条命令就能跑起来OpenAI 兼容接口在现代版本也补齐了。但代价是并发性能一般高并发下多个请求基本是排队处理没有 vLLM 那种 continuous batching 能力。vLLM 是生产级并发性能最强的开源方案。它通过 PagedAttention 能把显存利用率做到很高多个并发请求可以在同一块 GPU 上交错计算吞吐量比 Ollama 高不少。代价是配置参数多、学习曲线陡而且对显存规划更敏感模型加载到显存时如果超过上限会直接报错。NVIDIA NIM 则是企业级求稳的选择。它的容器化程度极高NVIDIA 官方预构建、预优化支持企业级 license 管理但需要你有 NVIDIA AI Enterprise 的授权而且要自己拉起 Triton 这套链路对刚从零起步的团队来说反而可能增加理解负担。我个人的倾向是快速验证用 Ollama正式上线优先 vLLM预算充足、要 NVIDIA 原厂兜底再考虑 NIM。4. 端点验证与安全暴露让业务系统真正用起来4.1 全链路验证一次普通的聊天请求是如何走完的部署完成后不要急着交给业务方先在命令行走一遍全链路。这个验证动作看着简单但能帮你定位 80% 的部署问题。以 vLLM 为例标准调用是发一个 POST 到/v1/chat/completionscurl -X POST http://endpoint-ip:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: VCF 9.0 中 GPU 池的作用是什么}], max_tokens: 512, temperature: 0.7 }正常返回的 JSON 里会包含choices[0].message.content、usage.prompt_tokens、usage.completion_tokens这些字段其中completion_tokens配合请求耗时就能算出实际吞吐。我习惯把一次典型请求的耗时压到 2 秒以内再交付如果超过 5 秒先检查显存状态和模型是不是没有完全加载到显存。全链路验证还有个关键点一定要在另一台机器上发起请求不要用部署推理服务的同一台宿主机。这样可以排除这台机器自身网络堆栈造成的假通现象确保业务系统所在的网段真的能通。4.2 安全暴露API Key、网络隔离与限流私有部署最大的错觉是反正内网不需要鉴权。真实情况是内部业务系统的告警全、日志转发、甚至某个低权限机器都有可能触碰到这个端点没有鉴权的模型端点等于给所有内网用户开了一个免费的 AI 入口既不可控也不安全。Ollama 本身没有原生 API Key 机制vLLM 可以通过--api-key参数开启简单的静态 Key 校验。我的经验是不要过度依赖框架自带的 Key 校验在模型端点前面再加一层反向代理统一做 API Key 校验、请求日志和限流。一个在 vLLM 前面加 nginx 反代的最小配置思路是用 nginx 代理到 8000 端口在请求头里校验Authorization: Bearer your-secret用一个简单令牌桶模块做每客户端每秒 1-2 请求的限流只监听内网 IP绝不绑定公网地址网络层面VCF 9.0 自带 NSX 分布式防火墙DFW可以按业务网段下发规则只允许知识库系统的源 IP 访问 8000/11434 端口其他网段一律 deny。这一步建议在交付前就配好不要在端点已经跑起来之后再临时补墙。4.3 健康检查指标TTFT、tokens/s、GPU 利用率模型端点交给业务方之后运维的关注点就变成怎么判断壮不健康。我自己长期盯的是三个指标第一个是 TTFTTime To First Token即从请求发出到模型吐第一个 token 的时间。正常小并发下 1-2 秒为佳如果持续超过 5 秒大概率是显存不足导致换页或者是 KV Cache 碎片化严重。第二个是 Decode 吞吐也就是每秒能生成多少 token。24GB 的 L4 上跑 Q4 的 7B 模型单并发大概 40-60 tokens/s如果掉到 10 以下说明模型可能没有真正用 GPU 跑或者被 CPU 回退执行了。第三个是 GPU 利用率。NVIDIA 的nvidia-smi dmon命令可以秒级看 GPU 利用率、显存占用、温度。利用率长期 100% 不一定是坏事但温度长期超过 85 度就要警惕散热利用率长期极低则说明负载模型和业务需求不匹配可以考虑换成更小的量化版本或者把 GPU 池拆分给更多工作负载。4.4 端点的备份与版本更新方法模型端点备份最大的误解是我要把整个 VM 都备份。实际上模型本身可以从模型源重新拉取不是易失资产真正需要备份的是推理服务的配置启动参数、模型路径、量化版本、API Key 映射、网络策略以及如果做了微调时的 LoRA 权重文件。我在多个项目里用的备份方案是模型文件全部放在 vSAN 一个独立目录按模型名和版本号建子目录微调权重按日期加标签存储推理服务的 deployment YAML 和 nginx 配置存一份到 Git 仓库。这样即使 VM 被删了也能在一个小时内在新 VM 或新 K8s 集群上重建端点。版本更新时最忌讳的是原地升模型——直接在同一个 VM 里把新的模型权重下载覆盖然后重启。这会让回滚变得很被动。更好的做法是新模型跑在新端口上迁移流量前先在内部做一遍接口兼容性测试确认业务方调用的字段没变化再把旧端口摘掉。5. 我踩过的坑以及建议你提前规避的同类问题5.1 GPU Pool 创建后VM 里看不到 GPU第一次在 VCF 9.0 里创建 GPU 池后我高高兴兴给 VM 加了 GPU 设备进系统执行nvidia-smi结果报错说没有可用驱动。排查后发现vGPU 模式要求 VM 先安装对应版本的 NVIDIA vGPU Manager 驱动而不是普通的显卡驱动这个前提在 UI 上不会自动提示。解决办法是去 NVIDIA 官网找匹配 vSphere/ESXi 版本的 vGPU 软件包在 VM 的 guest OS 里手动安装然后重启。如果你用的是直通模式则必须确认客户机操作系统里安装了支持该卡的 NVIDIA Game Ready 或 Studio 驱动。5.2 vGPU license 比想象的更早就开始生效vGPU 切分功能即使只在内部使用也需要 NVIDIA vGPU license。我第一次部署时没有提前配置 license server结果 VM 里 vGPU 设备能识别但是显存被限制在一个极低的规格模型加载直接 OOM。后来在 VCF 9.0 GPU 池配置里补了 license server 地址又在 VM 里重启一次 NVIDIA 服务才恢复正常。这里提醒一句NVIDIA 对 vGPU 提供了评估类 license用于测试是够用的但生产环境一定要算清楚采购成本。如果暂时不想采购就老老实实走直通模式宁可浪费显存也不要陷入设备可用但功能受限的尴尬。5.3 消费级卡直通的兼容性坑我有一台插了 RTX 4090 的宿主机直通模式下给 VM 装好驱动后一跑推理就出现NVRM: GPU at PCI:0000:05:00.0 has fallen off the bus的错误然后整个 VM 直接重启。排查结果是显卡的 PCIe 复位机制在消费级卡和 ESXi 直通之间兼容性不佳属于常见的已知问题。对这种问题我的建议是如果新采购硬件直接选 NVIDIA L4 或 A10 这类数据中心卡它们是 vSphere 官方支持列表里的常客直通和 vGPU 都稳。如果手里只有消费级卡那就先跑单并发验证确认 24 小时满载不宕机之后再交给业务方不要拿生产环境赌稳定性。5.4 模型反复 OOM显存被碎片化用 vLLM 跑推理时并发一多就容易报CUDA out of memory。除了模型太大之外还有一个隐蔽原因vLLM 的 KV Cache 是预分配的如果你设置的gpu-memory-utilization过高同时加载多个模型显存很容易被占满碎片化加剧。我的控制方法是vLLM 的--gpu-memory-utilization保守设置到 0.85预留 15% 给 CUDA context 和临时张量同时为每个模型端点单独分配一块显存配额不要在一个 VM 里同时塞两个大模型把多模型拆到多个端点 VM 上反而更好管理和排查。5.5 下载模型导致的存储带宽打满模型文件动辄几个 GB多台宿主机同时从外网拉取模型时最容易出事的是网络出口和存储 IO。我在一个项目里遇到过三台宿主机同时拉一个 7B 模型vSAN 存储带宽被占满其他虚拟机全部变卡。解决办法是在内网搭一个模型缓存仓库。先在离网络出口最近的 VM 上把模型下载到本地再通过 vSAN datastore 把模型文件拷贝到其他宿主机或者用 HTTP 内网源分发。这样既节省外网带宽也避免每次重建模型端点都要重新下载。后续如果企业要统一管理多个模型还可以规划一个专门的模型制品库服务把模型文件、版本、校验和都管起来。我在多个私有化 AI 项目里形成的最终工作流是先直通跑通再评估 vGPU 切分三者各留好文档和标准操作步骤推理服务从 Ollama 起步跑稳之后迁移到 vLLM 承接更大并发。整个链路跑下来你会发现VCF 9.0 里最难的不是技术参数而是提前想清楚这个 GPU 到底该怎么被共享、被调度、被运维。把这个问题想明白了后面的部署基本都是水到渠成的操作。