GDC 网闸隔离配置上的开放权重模型参考架构

问题陈述

在经过网闸隔离的环境中运营的组织面临着重大挑战：他们需要大语言模型，但由于严格的安全协议，他们被严格禁止连接到基于云的外部 API。为了弥补这一差距，这些客户需要一个强大的、自包含的生态系统，能够直接在其 Google Distributed Cloud (GDC) 网闸隔离配置基础设施上托管和管理开放权重模型。这种本地化部署对于维护绝对的数据主权至关重要，可确保敏感信息绝不会离开实体场所。通过将安全执行环境与服务后端集成，用户可以使用高级 AI 功能，同时保留对数据、模型权重和内部安全状况的完全管理控制。

虽然 GDC 上的 Gemini 提供了强大的代管式前沿功能，但客户通常会部署 Gemma 4 或 Llama 4 等开放权重模型，以实现更高的精细度和控制力。与托管式专有服务相比，在经过网闸隔离的 GDC 环境中部署开放权重模型具有显著的成本优势。通过拥有模型权重，组织可以消除经常性的按 token 收取的 API 费用，对于大批量、自动化工作负载，这些费用可能会让人望而却步。此外，开放权重模型支持量化（例如 4 位或 8 位），从而能够在边缘端更小、更便宜的硬件上运行高性能推理。这种垂直优化，加上无需额外许可费用即可在多个内部应用之间共享基础架构的能力，可显著降低持续、大规模推理操作的总拥有成本 (TCO)。

建议的解决方案

本文档概述了在 Google Distributed Cloud (GDC) 网闸隔离环境中部署和管理开放权重的大语言模型 (LLM) 的参考架构。许多客户（尤其是高度受监管行业的客户）由于严格的数据主权和安全要求，无法使用基于云的 LLM API。此架构可满足在自己的安全 GDC 实例中本地运行强大 LLM 的需求。

包含的内容：此架构涵盖使用 vLLM 或 Ollama 服务后端部署开放权重模型（例如 Gemma 4、Llama、DeepSeek、Mistral）。它包括使用 Kubernetes 进行编排、使用 Harbor 进行工件存储、使用永久性卷存储模型权重、使用网络政策（NetworkPolicy / ProjectNetworkPolicy）保障网络安全，以及使用 Open WebUI 作为可选的浏览器前端。

不包含的内容：此架构不涵盖托管式 AI Gateway 服务、专有模型（例如 Google 的 Gemini）、模型微调流程，或用于其他模态（例如图片生成）的 GenAI 模型。

受众群体：本文档的主要受众群体包括负责在 GDC 上部署和管理服务的平台管理员，以及在网闸隔离环境中设计 AI 解决方案的技术架构师。将与已部署模型进行交互的最终用户和开发者是次要受众群体，他们可以从了解底层结构中受益。

架构

该解决方案在标准集群中将 vLLM、Ollama 或两者部署为容器化推理服务后端 (Deployment)。模型权重存储在永久性卷上，这些卷通过模型加载器 Pod 从工作站填充。LoadBalancer 类型的 Kubernetes Service 会公开后端 API，NetworkPolicy / ProjectNetworkPolicy 对象会保护对这些 API 的访问，并且可以选择将 Open WebUI 部署为 OpenAI 兼容 API 的浏览器前端。

GDC 网闸隔离配置上的开放权重模型参考架构。

解决方案组件

此解决方案使用以下组件：

解决方案组件 需求管理代表的职责 数据流 接口
GDC 网闸隔离配置客户可用区 托管 Kubernetes 集群、网络和存储基础架构 基础平台 IO 的基础设施管理接口。面向平台管理员和用户的 Kubernetes API
负载均衡器 将 LLM 服务 Pod（vLLM、Ollama）公开给来自 Kubernetes 集群外部的流量，并提供稳定的 IP 地址。 外部客户端请求会发送到 LoadBalancer 的外部 IP。LoadBalancer 根据 Service 的选择器将请求分配到运行状况良好的后端 Pod（vLLM 或 Ollama） Kubernetes Service API。在 GDC 环境中自动预配网络负载均衡器。
vLLM 高吞吐量 LLM 推理服务。使用 PagedAttention 等技术针对低延迟进行了优化。通常每个实例提供一个模型。 接收来自客户端的 HTTP 推理请求。从装载的 PVC 加载模型权重。在挂接的 GPU 上执行计算。返回包含生成文本的 HTTP 响应。 OpenAI 兼容的 RESTful API，用于推理。接受 JSON 请求。
Ollama LLM 推理服务，旨在易于使用；一个实例可以提供多个模型，并按需加载。 接收 HTTP 推理请求。从装载的 PVC (OLLAMA_MODELS) 加载模型。在挂接的 GPU 上执行计算。返回 HTTP 响应。模型会在一段可配置的非活跃期 (OLLAMA_KEEP_ALIVE) 后卸载。 Ollama RESTful API 和 OpenAI 兼容 API (/v1)。接受 JSON 请求。还提供 CLI。
NVIDIA GPU 和 MIG 为 LLM 推理提供硬件加速。 LLM 后端（vLLM、Ollama）将密集型模型计算（例如矩阵乘法）分流到 GPU，以加速推理。MIG 允许对单个 GPU 进行分区，以供多个较小的模型实例使用。 在 Kubernetes 中作为资源类型公开（例如 nvidia.com/gpu-pod-NVIDIA_H200；确切的资源名称取决于安装的 GPU 型号，并从节点中发现）。Pod 会请求这些资源
Harbor 安全地存储和管理 vLLM、Ollama、Open WebUI 和任何辅助 Pod（例如 busybox）的容器映像 容器映像会通过 seed_registry.sh (crane) 从可访问互联网的工作站复制到 Harbor。Kubernetes 节点会从 Harbor 中拉取这些映像来运行容器。 Docker Registry API。Kubernetes 节点在创建 Pod 期间与 Harbor 交互以拉取映像。用户使用 crane、Docker CLI 或 Harbor 界面推送映像。
永久性卷声明 为 LLM 模型权重提供永久性存储，与 Pod 生命周期解耦。 模型文件会下载到工作站，用于动态计算 PVC 大小（包含 25% 的开销），并通过临时模型加载器 Pod (busybox) 使用 model_weight_upload.sh 流式传输到永久性卷。如果启用了高性能块存储，则 PVC 会使用 performance-rwo 进行预配；否则，基础设施运维人员会将 system-performance-<org>-admin QoS 政策应用于其后备卷。这两种选项均可提供每 GiB 30 IOPS（最低 6,148 IOPS）。两个后端在启动时都会从这个装载的卷中读取模型权重：vLLM 会加载 Hugging Face 模型目录，Ollama 会将 OLLAMA_MODELS 指向装载路径。不使用 kubectl cp，也没有模型捆绑到容器映像中。 Kubernetes 存储 API。在 YAML (ReadWriteOnce) 中定义，并作为卷装载到 Pod 中。
网络政策 强制执行网络隔离，并控制流向 LLM 服务的流量。命名空间 NetworkPolicy (networking.k8s.io/v1) 允许来自集群内部的流量访问服务端口；如需从项目外部访问，还需要 ProjectNetworkPolicy (networking.gdc.goog/v1)。 系统会检查进出命名空间中 Pod 的网络流量。这些政策规则决定了是否允许连接到 LLM 服务端口（例如，vLLM 为 8000，Ollama 为 11434），通常基于来源 IP 范围或其他标签。 Kubernetes networking.k8s.io/v1 和 networking.gdc.goog/v1 API。在 YAML 中定义。
Open WebUI 面向最终用户的可选基于浏览器的前端。与 vLLM 和 Ollama 的 OpenAI 兼容 API 通信；它不包含模型权重，也不需要加速器。 用户通过 Open WebUI 的 Kubernetes Service 访问该应用。Open WebUI 通过与 OpenAI 兼容的 /v1 API 将聊天请求转发到 vLLM 和 Ollama 服务，并在 Persistent Volume 上保留自己的状态（用户、聊天、设置）。 面向用户时使用 HTTP（浏览器），面向后端时使用与 OpenAI 兼容的 REST API。在自己的命名空间中部署的有状态工作负载。

特性和功能

此参考架构提供以下核心功能：

  • 开放权重 LLM 托管：支持托管和推理各种开放权重模型（例如 Gemma 4、Llama、DeepSeek、Mistral）。
    • 组件：LLM 服务后端（vLLM、Ollama）、Kubernetes Deployment/Pod。
    • 职责：加载模型权重、管理推理过程、在硬件加速器上执行模型以及公开端点。
    • 接口：REST API（与 OpenAI 兼容，适用于 vLLM 和 Ollama，以及 Ollama 专用 API），用于推理请求，通常使用 JSON。
  • 自带模型 (BYOM)：用户可以将所选的开放权重 LLM 导入并部署到经过网闸隔离的环境中。
    • 组件：Harbor、永久性卷声明、模型加载器 Pod、Kubernetes。
    • 职责：安全存储容器映像和模型权重。将模型传输到环境（通过加载器 Pod 传输到 model_weight_upload.sh）并使其可供服务引擎访问的机制。
    • 接口：Docker Registry API（适用于 Harbor）、Kubernetes API（适用于 PVC 和卷装载）。
  • 硬件加速推理：使用 GDC 集群中的 NVIDIA GPU 高效运行 LLM 推理。
    • 组件：NVIDIA GPU、Kubernetes、设备插件。
    • 职责：在具有 GPU 资源的节点上调度 Pod。向 LLM 后端容器公开 GPU 硬件。支持多实例 GPU (MIG)（用于分区）和多 GPU 张量并行处理 (TENSOR_PARALLEL_SIZE)（用于 Mixtral 8x7B bf16 等大型模型）。
    • 接口：Kubernetes API（用于请求 nvidia.com/gpu-pod-NVIDIA_H200 或 nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE 等 GPU 资源）。
  • 网络控制访问权限：确保对 LLM 推理端点的访问权限在 GDC 环境中受到控制和隔离。
    • 组件：Kubernetes Service (LoadBalancer)、NetworkPolicy、ProjectNetworkPolicy。
    • 职责：使用稳定 IP 公开推理服务。 定义和强制执行网络规则，以根据来源、目的地和端口允许或拒绝流向 LLM 后端的流量。
    • 接口：Kubernetes API（适用于服务、NetworkPolicy 和 ProjectNetworkPolicy）。
  • 可扩缩的服务：允许根据需求调整容量。
    • 组件：Kubernetes Deployment。
    • 职责：通过增加 LLM 后端 Pod 的副本数量来实现横向伸缩。通过调整资源请求/限制进行纵向伸缩。
    • 接口：Kubernetes API（用于管理 Deployment 副本和资源）。
  • 浏览器前端（可选）：让最终用户无需编写 API 调用即可与已部署的模型聊天。
    • 组件：Open WebUI Deployment、Service 和 Persistent Volume Claim。
    • 职责：在一个界面中呈现由 vLLM 和 Ollama 提供的模型部署；保留用户、对话和设置。
    • 接口：HTTP（浏览器）；面向后端的 OpenAI 兼容 /v1 API。

架构原则

  • 安全至上：所有组件和数据都位于 GDC 网闸隔离边界内，可确保最大限度地提高数据安全性和控制力。网络访问权限使用 NetworkPolicy 和 ProjectNetworkPolicy 对象进行限制。
  • 数据主权：客户可以完全控制其模型和数据，无需外部连接即可运行。
  • 开放且灵活：该架构使用开源服务后端（vLLM、Ollama），并支持各种开放权重 LLM，从而为客户提供选择，并避免推理引擎被供应商锁定。
  • 组件解耦：模型存储 (PVC)、映像管理 (Harbor)、推理服务（vLLM/Ollama pod）和界面 (Open WebUI) 等关键功能是不同的组件，可实现独立管理和更新。
  • 可伸缩性和性能：旨在通过增加 Pod 副本数量进行横向扩缩，以及通过调整 CPU/GPU 资源（包括多 GPU 张量并行处理）进行纵向扩缩，以满足性能需求。vLLM 适用于高吞吐量、低延迟场景。
  • 资源优化：支持 NVIDIA 多实例 GPU (MIG)，让较小的模型能够高效共享 GPU 资源；支持动态 PVC 大小调整（+25% 开销），并搭配高性能存储 QoS，在不牺牲模型加载速度的情况下消除存储过度预配。
  • 标准接口：基于 Kubernetes 标准构建，用于编排、部署和服务公开。推理端点提供 REST API， vLLM 和 Ollama 均提供 OpenAI 兼容性。
  • 弹性：使用 Kubernetes 健康检查和复制来确保服务可用性。

注意事项

  • 可伸缩性和性能：
    • 横向伸缩是通过增加 vLLM 和 Ollama 的 Kubernetes Deployment 中的副本数量来实现的。如果没有 ReadOnlyMany StorageClass，模型 Deployment 仅限于一个副本（模型卷为 ReadWriteOnce）；额外的容量则来自其他 Deployment，每个 Deployment 都有自己的 PVC。
    • 纵向伸缩涉及分配更多 CPU/内存和更大的 GPU 切片，最多可分配完整 GPU 或同一节点上多个 GPU 之间的多 GPU 张量并行处理 (TENSOR_PARALLEL_SIZE)。
    • vLLM 每个实例提供一个模型，需要为其他模型创建新的 Deployment。Ollama 可以通过一个实例提供多个模型；在这些指南中，每个 Ollama 部署都提供一个模型。
    • 每个模型的 PVC 都会根据其下载的权重动态调整大小，并留有 25% 的开销，同时配置高性能存储 QoS 政策（system-performance-<org>-admin，每 GiB 30 IOPS，下限为 6,148 IOPS，或在启用高性能块存储时为 performance-rwo），这样模型加载时间就不会受到默认 standard-rwo 每 GiB 3 IOPS 上限的限制。
  • 资源管理：
    • 因此，必须仔细规划 GPU 资源。NVIDIA MIG 可用于对 GPU 进行分区，以运行较小的模型，从而提高利用率；而较大的模型（例如 bf16 中的 Mixtral 8x7B）可以使用张量并行处理技术，在多个 GPU 之间对权重进行分片。
    • 必须分配足够的 CPU 和内存来处理推理和模型管理开销；vLLM 和 Ollama 通过 GPU 加速来提供模型。
    • 必须为 PVC 预配足够的存储空间，以适应模型大小并确保性能。
  • 可用性和可靠性：
    • Kubernetes Deployment 提供自我修复和滚动更新功能。
    • LoadBalancer Service 会将流量分配到正常运行的 Pod 中，从而掩盖单个 Pod 故障。
    • 将模型权重存储在 PVC 上可确保在 Pod 重启后仍能保留这些权重。
  • 操作复杂性：
    • 在 Harbor 中管理不同后端和版本的容器映像。
    • 将模型权重安全传输到经过网闸隔离的环境中的程序。
    • 为每个模型和后端创建和管理 Kubernetes 清单（Deployment、Service、PVC、网络政策）。
    • 监控 GPU 利用率、推理延迟时间和错误率。
  • 安全与合规性：
    • 整个解决方案在 GDC 网闸隔离安全边界内运行。
    • 必须使用网络政策来强制执行严格的网络隔离并控制对 LLM 端点的访问：一个用于集群内访问的命名空间 NetworkPolicy，以及一个用于从项目外部访问的 ProjectNetworkPolicy。
    • Harbor 机器人账号和 Kubernetes 映像拉取 Secret 可确保对容器映像的安全访问。
    • 网络政策会限制哪些客户端可以访问端点。PVC 上的静态数据依赖于 GDC 存储加密。

设计决策

我们为此参考架构做出了以下关键设计决策：

决策 1：同时提供 vLLM 和 Ollama，而不是仅提供一个服务后端

上下文 关键决策 理由
提供一个服务后端（vLLM 或 Ollama）或同时提供两者。 同时提供这两种方案，因为用户和应用场景在性能、API 兼容性和模型管理简易性方面的要求各不相同。 vLLM 提供高吞吐量、低延迟的服务，并与 OpenAI API 兼容，非常适合生产应用。Ollama 的设置更简单，更易于管理多个模型，且易于使用，更适合开发和实验。同时支持这两种方式可提供灵活性。

决策 2：PersistentVolumeClaims 上的模型权重

上下文 关键决策 理由
vLLM 和 Ollama 在运行时需要文件系统中的模型权重。在经过网闸隔离的环境中，无法按需下载模型。 将每个模型的权重存储在各自的 ReadWriteOnce PersistentVolumeClaim 中，这些权重通过临时模型加载器 Pod 从工作站填充。 PersistentVolumeClaims 为大型模型文件提供了一个弹性且永久性存储层，该存储层与推理 Pod 生命周期解耦。这样，模型就可以在 Pod 启动时快速加载。

决策 3：将 Ollama（加载器 Pod）的模型权重存储在 PersistentVolume 上，而不是将其打包到映像中

上下文 关键决策 理由
Ollama 可以下载模型，但这需要互联网访问权限，而经过网闸隔离的环境不具备此权限。而将模型打包到自定义 Ollama 映像中，则需要为每个模型重新构建映像，并在 Harbor 中存储数 GB 的映像。 Ollama 使用与 vLLM 相同的加载器 Pod 工作流：在工作站上拉取模型（ollama pull 到 ollama_model_weight_download.sh），通过模型加载器 Pod 使用 model_weight_upload.sh (GNU tar) 将模型流式传输到 PVC，并将 OLLAMA_MODELS 指向装载路径。 一个工作流适用于两个后端；无需重新构建映像即可添加或更新模型；未修改的上游 Ollama 映像在 Harbor 中保持较小。

决策 4：使用 LoadBalancer Service 公开 vLLM 和 Ollama，还是不使用负载均衡器

上下文 关键决策 理由
LLM API 需要可供 GDC 环境中的应用访问。 通过 LoadBalancer 类型的 Service（标准 Kubernetes 方法）公开每个后端。这依赖于 GDC 网闸隔离配置平台的负载均衡器预配。 LoadBalancer 类型的 Kubernetes Service 提供了一种标准、可靠的方法来公开 LLM 后端，从而提供稳定的 IP 地址并分配负载。

决策 5：强制执行强制性网络政策（NetworkPolicy 和 ProjectNetworkPolicy）

上下文 关键决策 理由
安全性和隔离性在 GDC 网闸隔离配置中至关重要。 在每个 LLM 端点上强制执行网络政策（一个仅允许服务端口的命名空间 NetworkPolicy，当项目外部的客户端需要访问时，辅以 ProjectNetworkPolicy），以增强已部署 LLM 服务的安全状况。 NetworkPolicy 对象提供了一种 Kubernetes 原生方式，可在命名空间级别强制执行网络隔离，而 ProjectNetworkPolicy 对象则将其扩展到项目边界，从而确保只有获得授权的流量才能到达 LLM 服务。

决策 6：动态 PVC 适当调整（+25% 开销）与高性能存储 QoS 政策搭配使用

上下文 关键决策 理由
默认 standard-rwo StorageClass 会强制执行 standard-<org>-admin ONTAP 自适应 QoS 政策（3,072 IOPS per TiB 或 3 IOPS per GiB，最低下限为 75 IOPS）。如果严格按照模型权重大小来调整 standard-rwo PVC 的大小，则顺序权重读取速度会限制在 5 到 21 MBps 之间；而过度预配静态 300 到 500 GiB PVC 会浪费存储空间，同时顺序读取吞吐量仍会限制在约 60 MBps。 首先下载模型权重，从下载的目录中动态计算 GDCS_MODEL_PVC_SIZE，并加上 25% 的开销（向上舍入到下一个整数 GiB），然后在启用了高性能块存储的位置使用 storageClassName: performance-rwo，或让基础架构运维人员将 system-performance-${GDC_ORG}-admin QoS 政策应用于后备卷。 system-performance-<org>-admin QoS 政策为任何不超过 204 GiB 的卷提供 30,720 IOPS per TiB（30 IOPS per GiB，比 standard 高 10 倍），最低下限为 6,148 IOPS（ONTAP 上限约为 393 MBps）。将动态 25% 开销大小调整与 system-performance 搭配使用，可消除 3 倍到 40 倍的存储空间超额预配（12Gi 到 109Gi，而不是 100Gi 到 500Gi），同时将单 LUN KubeVirt virtio-scsi 顺序读取速度提高到约 150 MBps（模型启动速度提高 2.5 倍到 30 倍）。

假设和限制

  • GDC 网闸隔离配置 1.16.2 hotfix 1 (1.16.2-gdch.1353-1) 或更高版本的环境可用（标准集群中的 GPU 节点池需要此版本；早期版本仅在共享集群中提供 GPU）。
  • 标准集群中存在足够的硬件资源（包括 NVIDIA GPU）。vLLM 和 Ollama 都需要 GPU。
  • Harbor 实例已设置且可访问。
  • 有一个可访问互联网并连接到 GDC 环境（Harbor 和 Kubernetes API）的工作站，用于播种映像和上传模型权重。
  • 用户拥有必要的权限：项目角色 Harbor Instance Viewer 和 Standard Cluster Admin，以及标准集群上的 StandardClusterRoleBinding (cluster-admin)，请参阅 SRI。
  • 模型与所选的服务后端（vLLM/Ollama）兼容。
  • 限制：模型权重 PVC 为 ReadWriteOnce；如果没有 ReadOnlyMany StorageClass，每个模型 Deployment 仅限一个副本。

用户体验流程

以下是在 Google Distributed Cloud (GDC) 网闸隔离环境中部署开放权重的大语言模型 (LLM) 的完整用户体验流程。该流程分为常见设置、两个部署路径（vLLM 和 Ollama）、一个可选前端和最终验证。

1. 常见设置：映像管理

在部署任何 LLM 之前，您必须配置 GDC 环境如何从私有 Harbor 注册表中拉取容器映像。

  • 创建 Harbor 机器人账号：在 Harbor 界面中生成机器人账号：一个具有 crane 的推送权限（映像播种），另一个具有 Kubernetes 映像拉取 Secret 的拉取权限。
  • 对 crane 和种子映像进行身份验证：使用机器人账号凭证从可访问互联网的工作站 (crane auth login) 登录 Harbor，然后使用 seed_registry.sh 将所需的容器映像（busybox、ollama/ollama、vllm/vllm-openai，以及可选的 Open WebUI）复制到 Harbor。
  • 创建 Kubernetes Secret：使用 kubectl 在工作负载命名空间中创建 docker-registry Secret，以存储拉取机器人账号凭证，供集群使用。

2. 部署途径 A：使用 vLLM 实现高吞吐量

建议通过此路径在 GPU 上提供注重性能的模型（例如 Mistral 7B Instruct）。

  • 获取映像：使用 seed_registry.sh 将 vLLM 映像 (vllm/vllm-openai:v0.26.0) 植入 Harbor，然后按照 SRI 中的说明构建并推送已修补的映像标记 v0.26.0-fips。
  • 准备模型存储空间：
    • 在工作站 (hf download) 上从 Hugging Face 下载权重。
    • 根据下载的权重（加上 25% 的开销）计算所需的 PVC 大小，创建 ReadWriteOnce 永久性卷声明 (PVC) 来存储模型权重，并应用高性能 QoS 政策。
    • 启动一个临时模型加载器 Pod (busybox)，该 Pod 会装载 PVC 并使用 model_weight_upload.sh 将权重流式传输到其中（通过 kubectl exec 的 GNU tar；不使用 kubectl cp，因为 BusyBox tar 无法读取大于 8 GiB 的文件的 PAX 标头），然后删除加载器 Pod。
  • 部署后端：应用 Kubernetes Deployment 清单，该清单引用 vLLM 映像，请求从节点发现的加速器资源（例如 nvidia.com/gpu-pod-NVIDIA_H200），并装载模型权重 PVC。
  • 公开服务：创建 LoadBalancer 服务，为 vLLM API 提供外部 IP。
  • 安全网络：应用命名空间 NetworkPolicy 以允许服务端口 (8000) 上的入站流量；当项目外部的客户端需要访问权限时，添加 ProjectNetworkPolicy。

3. 部署途径 B：Ollama（易于使用）

此路径侧重于简化设置。它使用未经更改的上游 Ollama 映像，并使用与 vLLM 相同的模型加载器工作流。

  • 种子映像：使用 seed_registry.sh 将上游 Ollama 映像 (ollama/ollama:0.32.14) 复制到 Harbor。
  • 准备模型存储空间：
    • 使用 ollama_model_weight_download.sh 在工作站上拉取模型（例如 gemma4:e4b），这会运行一个临时本地 ollama serve，其中 OLLAMA_MODELS 指向下载目录。
    • 根据下载的权重（加上 25% 的开销）计算所需的 PVC 大小，创建 ReadWriteOnce PVC，应用高性能 QoS 政策，然后启动一个装载该 PVC 的临时模型加载器 Pod。
    • 使用 model_weight_upload.sh 将下载目录上传到 PVC，然后删除加载器 Pod。
  • 部署和公开：创建一个 Ollama Deployment，其中 OLLAMA_MODELS 指向 PVC 装载路径（请求从节点发现的加速器资源），并创建一个 LoadBalancer 服务。
  • 安全网络：为 Ollama 端口 (11434) 应用命名空间 NetworkPolicy；当项目外部的客户端需要访问权限时，添加 ProjectNetworkPolicy。

4. 可选：打开 WebUI

  • 部署 Open WebUI：将 Open WebUI 映像植入 Harbor，并将其部署在自己的命名空间中，为其状态提供永久性存储；将其指向 vLLM Service、Ollama Service 或两者的 OpenAI 兼容 /v1 端点。具体步骤请参阅适用于开放权重模型的 Open WebUI 用户指南。

5. 验证和测试

部署完成后，最后一步是验证服务是否正常运行。

  • 检查状态：验证 Pod 是否正在运行，以及服务是否已分配外部 IP 地址。
  • 测试推理：
    • vLLM：使用与 OpenAI 兼容的 /v1/models 和 /v1/chat/completions 端点向 vLLM LoadBalancer IP 发送 curl 请求。
    • Ollama：使用与 OpenAI 兼容的相同 /v1/models 和 /v1/chat/completions 端点，向 Ollama LoadBalancer IP 发送 curl 请求。
  • 端口转发回退：如果无法从工作站访问 LoadBalancer IP（例如，因为尚未实施 ProjectNetworkPolicy），请对服务使用 kubectl port-forward，并将相同的请求发送到 127.0.0.1。

6. 运营和伸缩

  • 纵向扩缩：增加 GPU 切片或改用多 GPU 配置，以支持更大的模型。
  • 横向扩缩：增加 Deployment 中的副本数量（需要 ReadOnlyMany 模型卷），或部署其他模型 Deployment，以处理更多并发用户请求。
  • 问题排查：使用 kubectl logs 监控日志，并检查是否存在常见问题，例如 FIPS 自测失败或网络政策限制。

详细步骤请参阅使用 Ollama 参考实现的开放权重模型、使用 vLLM 参考实现的开放权重模型及其用户指南。

其他资料