企业官网建设流程全解析

去年底有个做制造业的客户找我，说他们想在内部跑一个大模型问答系统，但所有生产数据严格禁止出内网，不能调用任何公有云 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 全精度权重约 14GB，Q4_K_M 量化后约 4.4GB，Q8 约 7.8GB。8B 模型 Q4 量化后约 5.2GB 左右。如果你用 L4（24GB）跑一个 Q4 的 7B/8B 模型，权重大概只占 5-6GB，剩下的空间全留给 KV Cache 和并发请求。这也是为什么一张 24GB 的"普通卡"足够企业内部小规模推理服务跑起来，不需要一上来就上 A100。

下面这张表是我在实际部署中经常对照的参考值，基于 Q4_K_M 量化、默认上下文长度（4K-8K）、单并发条件下估算：

有个容易被忽视的点：上面的表是"单并发"的静态占用，一旦业务系统把同一时刻的请求数提上来，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 L4（24GB）、A10（24GB）这种单槽低功耗专业卡；真要用消费级卡，建议先在测试环境把直通、驱动、压力跑完一遍再上生产。

第三，消费级卡在设计上不擅长 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 Grid（TKG）走容器化路线是更合适的选择。

第一步，在 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/completions：

curl -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 利用率

模型端点交给业务方之后，运维的关注点就变成"怎么判断壮不健康"。我自己长期盯的是三个指标：

第一个是 TTFT（Time 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 到底该怎么被共享、被调度、被运维"。把这个问题想明白了，后面的部署基本都是水到渠成的操作。