> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 自托管 AI 助手的经验教训
- URL: https://www.hubwiz.com/blog/lessons-learned-from-self-hosting-an-ai-assistant/
- Published: 2026-03-05T12:57:12.000Z
- Updated: 2026-03-05T12:57:12.000Z
- Description: 如果你计划自托管自己的 AI 助手，我希望这能节省你的时间。
- Author: admin
- Tags: AI, #Import 2026-10-14 14:41

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

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

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](https://github.com/open-webui/open-webui?ref=hubwiz.com)

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

- ***为什么使用 LiteLLM Proxy？*** 部署时，OpenWebUI 不支持使用 [Responses API](https://platform.openai.com/docs/api-reference/responses/create?ref=hubwiz.com) 的 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。文档[在这里](https://docs.litellm.ai/docs/proxy/deploy?ref=hubwiz.com)。

```
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 集成

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

### 应用程序注册

1. 在 Azure Entra ID 中注册新应用程序。
2. 添加重定向 URI： `https://your-domain.com/oauth/callback`
3. 生成客户端密钥。
4. 然后，更新 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](https://medium.com/hooman-in-the-loop/lessons-learnt-self-hosting-an-ai-assistant-363d5111a360?ref=hubwiz.com#bypass)

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