自托管 AI 助手的经验教训

自托管对我来说有几个实际原因。

控制。我想要对路由、安全、访问和插件的完全控制。
灵活性。我可以混合和匹配模型。GPT-5 用于一般任务，DeepSeek R1 用于推理，Perplexity 用于网络搜索，GPT-Image-1 用于生成。
集成。当平台在你的堆栈内运行时，运行 RAG、SSO、日志记录和自定义文档管道更容易。
成本和性能优化。你决定缓存策略、自动扩展、副本数量和模型层选择。

OpenWebUI 提供干净、可扩展的界面，同时让你连接你想要的任何后端。这成为了基础。

1、架构概述

系统建立在以下基础上：

Azure Kubernetes Service (AKS) 用于容器编排
Helm charts 用于部署和配置
PostgreSQL 作为 OpenWebUI 的持久存储
Azure AI Foundry 用于置备 LLM 端点
LiteLLM Proxy 部署在 AKS 内用于推理模型
Perplexity API 用于实时网络搜索
Azure Entra ID 用于 SSO
Nginx Ingress Controller 用于负载均衡、SSL 和 DNS
Apache Tika 用于 RAG 文档解析

OpenWebUI 的 GitHub 仓库在这里：https://github.com/open-webui/open-webui

你可能对我这里的选择有一些疑问。让我解释：

为什么使用 LiteLLM Proxy？ 部署时，OpenWebUI 不支持使用 Responses API 的 LLMs，而 O3 等推理模型不支持该 API。
为什么使用 Apache Tika？ 它是 OpenWebUI Helm charts 中开箱即用的服务。扩展 OpenWebUI 就像在 values.yaml 中启用它一样简单。

2、使用 Helm 在 AKS 上部署 OpenWebUI

OpenWebUI 附带工作的 Helm chart。只要你有一个工作的 AKS 集群，这使得部署容易得多。如果你没有 AKS 设置，那将构成你工作的大部分。我会建议与你的基础设施/平台团队合作建立基础配置。

创建 AKS 集群

az aks create \
  --name ai-assistant \
  --resource-group ai-rg \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --enable-managed-identity

添加 Helm 仓库并安装

helm repo add openwebui https://helm.openwebui.com
helm repo update
helm install ai-ui openwebui/open-webui \
  --namespace ai \
  --create-namespace \
  --values values.yaml

你的 values.yaml 是大部分繁重工作发生的地方。我的包括 PostgreSQL 连接字符串、SSO 配置、入口详细信息和模型路由。

我建议在你的设置上启用的一些有用配置：

OpenWebui：

ENABLE_WEBSOCKET_SUPPORT：用于会话管理、websocket 协调和状态同步。使整个体验非常流畅。
VECTOR_DB：值设置为 pgvector，除非你想设置和使用自己的向量数据库。
WEB_SEARCH_ENGINE：使用 Perplexity API，它在可用的选项中给了我们最好的结果。

Postgresql：

PgBouncer：改进数据库服务器上的空闲连接和短生命周期连接。
pgvector：在 Postgresql 中安装扩展，用于 RAG 使用的相似性搜索功能。

3、设置 LiteLLM Proxy

要使用 Helm 在 Kubernetes 中部署 LiteLLM Proxy，你可以依赖其官方 Helm chart。文档在这里。

helm pull oci://ghcr.io/berriai/litellm-helm
# Pulled: ghcr.io/berriai/litellm-helm:0.1.2
# Digest: sha256:7d3ded1c99c1597f9ad4dc49d84327cf1db6e0faa0eeea0c614be5526ae94e2a
tar -zxvf litellm-helm-0.1.2.tgz

helm install litellm-proxy ./litellm-helm \
  --set masterkey="sk-your-master-key" \
  --namespace ai \
  --create-namespace

部署后，你可以端口转发或外部暴露服务；默认情况下，代理监听端口 4000。此时，LiteLLM 充当统一 LLM 网关：你可以定义它代理哪些模型（通过 config.yaml 或环境变量），你的上游应用程序（如 OpenWebUI）然后可以对 LiteLLM 发出标准的 OpenAI 风格请求，LiteLLM 处理跨多个底层 LLM 提供商的路由、负载均衡、凭据管理、可选速率限制或支出跟踪和服务编排。我配置了 DeepSeek R1 推理模型作为通过我们的 Azure AI Foundry 服务置备的代理。

4、集成 AI 模型

OpenWebUI 通过简单的 JSON 配置与模型提供商通信。我连接了四个后端：

Azure AI Foundry

GPT-5
GPT-4o
DeepSeek R1

Perplexity AI API 平台

Search API — Sonar

Azure AI Foundry 和 Perplexity AI API 平台本质上是安全和私有的，这对于从数据安全角度来说的组织很重要。

5、与 Entra ID 的 SSO 集成

这部分需要一些摆弄，但一旦配置，它感觉无缝。

应用程序注册

在 Azure Entra ID 中注册新应用程序。
添加重定向 URI： https://your-domain.com/oauth/callback
生成客户端密钥。
然后，更新 Helm chart 的 values.yaml 中的值，如下：

auth:
  oidc:
    enabled: true
    clientId: ${AZURE_OIDC_CLIENT_ID}
    clientSecret: ${AZURE_OIDC_SECRET}
    providerName: AZURE
    providerUrl: https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration
    scopes: "openid email profile"

部署后，用户能够使用 Microsoft SSO 登录。

6、Nginx Ingress + DNS

在 Kubernetes Helm chart 中也可以定义干净的入口设置：

ingress:
  enabled: true
  class: "nginx"
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
  host: "ai.mycompany.com"
  tls: true
  existingSecret: "openwebui-tls"

你可以使用 Azure Key Vault 证书或 cert-manager 启用 TLS。

Nginx 也与 OpenWebUI 使用的 WebSockets 配合得很好。

7、我学到的经验

一些可能为你节省数小时的经验：

1. LiteLLM 被低估了

我将所有模型提供商拉到了一个干净的端点后面，这使路由和故障转移简单得多。我的最初目标只是暴露推理模型，但事后看来，LiteLLM 作为中央枢纽工作得好得多。你配置每个 LLM 后端一次，OpenWebUI 获得统一接口而无需任何额外布线。

2. 使用托管 PostgreSQL

除非你积极想要运营痛苦，否则不要在 AKS 上自托管 PostgreSQL。使用托管的 Postgres 服务代替，并确保启用了 PgBouncer 和 pgvector。除此之外，默认配置就足够了。

3. SSO 优先，然后公开暴露

太多部署先暴露 Nginx 然后稍后锁定安全性。做相反的。

4. RAG 仅与你的解析一样好

Tika 在我调整内存限制和调整分块行为后表现得更好。它确实附带了 5 MB 上传上限，但实际上你需要适当地调整 Kubernetes pod 的大小。如果你希望它可靠地处理更重的文档加载，请预期分配额外的 CPU 或内存。

5. 自动扩展很重要

流量峰值会触发模型活动的突然爆发，这使得 HPA 设置变得必要。有 15-20 个并发用户，集群会很快达到其限制，所以我添加了自动扩展以确保 pod 能够使用合理的请求和限制适当地调整自身大小。我还定义了清晰的扩展和缩减规则，以在高峰和安静期间保持体验流畅。如果你引入 HPA，请记住你的存储配置也可能需要调整。以下是我最终使用的设置：

# HPA
autoscaling:
  enabled: true
  maxReplicas: 4
  minReplicas: 1
  targetCPUUtilizationPercentage: 75
  targetMemoryUtilizationPercentage: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60

# Storage
persistence:
  enabled: true
  size: 20Gi
  accessModes:
    - ReadWriteMany
  storageClass: "azureblob-nfs-premium"
  selector: {}
  annotations: {}
  provider: local

8、结束语

自托管 AI 助手不仅仅是一个有趣的工程项目。它改变了团队与知识、代码、文档和运营任务的交互方式。使用 OpenWebUI、Azure Kubernetes Service 和一些集成，你可以构建一个高能力的 AI 平台，而无需完全依赖 SaaS 产品。

如果你是开发人员或正在考虑将助手带给数据的 AI 爱好者，这个设置是一个很好的起点。各个部分干净地融合在一起，几乎一切都是可定制的。

原文链接: Lessons Learnt Self-hosting an AI Assistant

汇智网翻译整理，转载请标明出处