私有化 AI 架构全景 · 现状与演进路径

环境锚点：192.168.110.207（编排/应用）+ 116.62.10.183（vLLM）
HTML：docs/html_cursor/私有化AI架构全景_现状与演进路径_cursor.html
定位：新增专题（不替换 Higress 之一～六 / LiteLLM 部署等）。对齐中大企业私有化主流分层，对照本环境实装，给出多套架构图、组件点评与业务场景走线。
阅读建议：先看 §1 分层表 → §2 选一张贴合你阶段的图 → §3 对上业务场景 → §4 查组件细节。

0. 一句话结论

你是谁	该怎么看本环境	下一步主流方向
小团队 / 试点	已够用：Dify + LiteLLM + vLLM + Xinference + Langfuse	先把问答/编程场景跑稳，别急上 K8s
本环境运维 / 学习	Higress 已是「总入口增强层」，职责与 LiteLLM 要分清	限流/TLS/审计按之六逐步开
中大企业规划	本环境 ≈ 精简私有化样板，缺：企业 WAF、K8s GPU、Milvus 集群、Vault、统一出站管控	按 §2.3 目标态补层，不要一次全换

分层原则（2025–2026 私有化共识）：

推理层把模型变成 HTTP 服务（vLLM 等）。
模型网关管鉴权、路由、限流、多模型、计量（LiteLLM；边缘策略可用 Higress）。
应用/Agent管编排、工具、人机协同（Dify）。
向量与检索服务 RAG。
可观测管 Trace / Token / 延迟 / 质量。
基础设施 + 密钥决定能不能规模化与合规。

不必每层都精通安装；必须知道：这一层挂了业务症状是什么、看哪张盘、如何降级。

1. 分层对照表（现状 vs 主流）

层	职责	本环境（已落地）	小型公司够用方案	中大企业主流（2025–2026）
模型推理	模型 → HTTP	vLLM `qwen3.6-27b` @183 `:8000`	单机 vLLM / Ollama（试点）	vLLM / SGLang / TensorRT-LLM；多副本；可选合规模型专线
模型网关	鉴权、路由、限流、多模型	LiteLLM `:4000` + Higress `:18080`（总入口）	可只上 LiteLLM；或 Dify 直连推理	LiteLLM Proxy 或 Higress AI + 企业 API 网关/WAF；计量计费
应用 / Agent	编排、工具、工作流	Dify `:80`（亦可 `dify.ai.local:18080`）	Dify 私有化 / FastGPT	Dify / RAGFlow / 自研 LangGraph+Temporal；人机协同
Embedding / Rerank	向量化与重排	Xinference `:9997`（bge-m3 / rerank）	同左或小模型同机	独立推理池；GPU/CPU 分流
向量库	RAG 存储检索	Weaviate（Dify `VECTOR_STORE=weaviate`）；Milvus 可选未主用	Weaviate / pgvector	Milvus / ES 向量 / Qdrant；多租户与备份
可观测	Trace、Token、质量	Langfuse `:3000` + Prometheus/Grafana（SLA）	至少 Langfuse 或日志	Langfuse + Prom/Grafana + Loki/ELK + OTel
基础设施	GPU / 编排	双机 Compose；无 K8s	1～2 台 Docker	K8s + NVIDIA GPU Operator；Harbor；GitLab/Argo CD
密钥与配置	密钥轮换、配置中心	环境变量 / 文档明文（内网学习）	`.env` + 权限收紧	Vault / 企业配置中心；Prompt 配置化发布

目标态理论教程（不装机）：基础设施 · K8s GPU / Operator / Harbor·GitLab·Argo CD · 单私有化 GPU 集群完整案例 · 单私有化 GPU 集群完整案例

本环境口诀：Key 进门看 Higress（一期多透传）；模型名看 LiteLLM；编排看 Dify；向量算力看 Xinference；大模型看 183 vLLM。

2. 多套架构图（按阶段选）

2.1 图 A · 本环境实装（现状）

适用：当前 207 实验室 / 试点生产雏形；排障与培训主图。

flowchart TB
  U[用户 / SDK / 业务系统]
  subgraph EDGE["总入口 · Higress standalone :18080"]
    GW[Gateway]
    CON[Console :8001]
    NAC[Nacos :8848]
  end
  subgraph APP207["应用主机 192.168.110.207"]
    DIFY[Dify :80]
    LITELLM[LiteLLM :4000]
    XF[Xinference :9997]
    WV[Weaviate]
    LF[Langfuse :3000]
    PG[Prometheus + Grafana]
  end
  subgraph GPU183["GPU 主机 116.62.10.183"]
    VLLM[vLLM qwen3.6-27b :8000]
  end

  U --> GW
  GW -->|/llm/*| LITELLM
  GW -->|Host dify.ai.local| DIFY
  GW -->|/xf/*| XF
  U -.->|排障直连| DIFY
  U -.->|排障直连| LITELLM
  DIFY --> LITELLM
  DIFY --> WV
  DIFY --> XF
  DIFY --> LF
  LITELLM -->|chat| VLLM
  LITELLM -->|embeddings| XF
  PG -.->|指标| LITELLM
  PG -.->|指标| VLLM
  CON -.-> GW
  NAC -.-> GW

现状特征：

双机 Compose，不是 K8s。
Higress 与 LiteLLM 并存：Higress 做路径/Host/策略增强；LiteLLM 做 model 路由与上游 Key。
向量库用 Weaviate；Milvus 在 compose 里可选，当前主路径不是 Milvus。
企业级 WAF / Vault / 统一出站白名单：尚未按生产级强制（Higress 之六可演示插件）。

2.2 图 B · 小型公司最小闭环（推荐起步）

适用：10～50 人团队、先验证业务价值；预算紧、运维人手少。

flowchart TB
  U[用户 / 浏览器]
  DIFY[Dify 私有化]
  LLM[LiteLLM 可选]
  INF[单机或 1 台 GPU：vLLM]
  EMB[Embedding：Xinference 或同机小模型]
  VEC[pgvector 或 Weaviate 单节点]
  LF[Langfuse 可选但强烈建议]

  U --> DIFY
  DIFY --> LLM
  LLM --> INF
  DIFY --> EMB --> VEC
  DIFY --> LF

中肯建议：

项	建议
Higress	可不上；等要对多系统统一入口、TLS、限流再上
LiteLLM	第二模型或要换 Key/LB 时再上；前期 Dify 直连 vLLM 也能活
向量库	知识量小用 pgvector；文档多再 Weaviate
K8s	不要为了架构好看上 K8s
合规	至少关掉公网裸奔 Key；内网 + HTTPS 反代即可

2.3 图 C · 中大企业目标态（主流最佳实践）

适用：数据不出域、要审计、要成本计量、多部门共用；对齐附件「中大型私有 Agent 典型链路」。

flowchart TB
  U[用户 / 业务系统]
  WAF[企业 API 网关 / WAF]
  DIFY[Agent 应用层：Dify / 自研]
  TOOLS[内部工具：CRM / 工单 / 内网搜索]
  POLICY[出站策略 / 域名白名单]
  GW[LLM 网关：LiteLLM ± Higress 策略]
  LOCAL[本地推理集群：K8s + vLLM GPU]
  CLOUD[可选：合规模型专线]
  LF[Langfuse + Prometheus]
  MILVUS[向量库：Milvus 等]
  VAULT[Vault / 密钥中心]

  U --> WAF --> DIFY
  DIFY <--> TOOLS
  TOOLS -.-> POLICY
  DIFY --> GW
  GW --> LOCAL
  GW -.-> CLOUD
  DIFY --> MILVUS
  DIFY --> LF
  GW --> LF
  VAULT -.->|API Key / 工具凭证| DIFY
  VAULT -.-> GW

与本环境差异（演进清单）：

能力	现状	目标态
边缘安全	Higress 可演示 WAF/IP/限流	企业统一 WAF + 零信任
推理弹性	单机 vLLM	K8s 多副本 + GPU Operator
向量	Weaviate 单栈	Milvus/ES 集群 + 备份多租户
密钥	文件/环境变量	Vault 轮换
工具调用	作业级 HTTP 工具	出站白名单 + 审计
计量	Langfuse + 作业级预算	网关级配额 + 部门账单

2.4 图 D · 从现状演进到目标态（路径，不是推倒重来）

flowchart LR
  S0[现状双机 Compose] --> S1[策略加固：Higress TLS/限流/审计]
  S1 --> S2[推理水平扩展：多 GPU + LiteLLM LB]
  S2 --> S3[向量升级：Milvus 集群可选]
  S3 --> S4[平台化：K8s + Vault + 企业 WAF 对接]

建议顺序：先控风险与成本（S1）→ 再扩算力（S2）→ 再换向量底座（S3）→ 最后平台工程化（S4）。逆序（先上 K8s 再补可观测）是中大企业最常见浪费。

3. 业务场景走线（问答 / 编程 / 其它主流）

3.1 企业知识库问答（RAG）

诉求： 制度、产品手册、FAQ；要引用可追溯、幻觉可控。

sequenceDiagram
  participant U as 用户
  participant D as Dify
  participant V as Weaviate/Milvus
  participant E as Xinference Embedding/Rerank
  participant L as LiteLLM
  participant M as vLLM
  participant F as Langfuse

  U->>D: 提问
  D->>E: embed 查询
  D->>V: 检索 TopK
  D->>E: 可选 Rerank
  D->>L: 带上下文 chat
  L->>M: 推理
  M-->>U: 回答
  D->>F: Trace / Token

规模	建议
小	Dify 知识库 + Weaviate/pgvector + 单模型；先不开 Rerank
中大	分库分权；Rerank；敏感库隔离；Langfuse 抽检命中质量；向量集群

本环境：专题十三 Rerank、专题十四容量与变慢排查可直接复用。

3.2 编程类助手（代码解释 / 补全 / Review）

诉求： 低延迟、长上下文、少检索或只检索内部代码规范；常走 API 而不是重 RAG。

flowchart LR
  IDE[IDE / CI / 内部 Portal] --> H[Higress /llm 或直连 LiteLLM]
  H --> L[LiteLLM]
  L --> V[vLLM 大上下文]
  L -.->|可选| CLOUD[合规模型]
  IDE --> F[Langfuse]

点	中肯建议
要不要知识库	规范/安全基线可进知识库；仓库全文 RAG 成本高，优先「打开的文件 + 规则」进 Prompt
模型	本环境 Qwen3.6-27b 可做解释/Review；极致补全可另部署代码专用模型，仍挂 LiteLLM 同网关
限流	编程场景易刷爆 GPU → 必须 Key 限流 / 队列（Higress 或 LiteLLM）
小公司	IDE → LiteLLM → vLLM 即可
中大	源码不出域；网关审计；禁止把密钥贴进 Prompt（Vault + 扫描）

3.3 工具型 Agent（工单 / CRM / 查服务器）

诉求： 编排 + 工具调用 + 权限；本环境作业 1/2/5 已演示闭环。

flowchart TB
  U[用户] --> D[Dify Agent/Workflow]
  D --> KB[知识库可选]
  D --> T1[HTTP 工具：状态/工单/CRM]
  D --> L[LiteLLM → vLLM]
  T1 --> POL[出站白名单 / 鉴权]
  D --> F[Langfuse 看工具 Span]

规模	建议
小	OpenAPI 工具 + 内网 API；Langfuse 看清工具是否乱调
中大	工具凭证进 Vault；按角色授权；出站域名白名单；失败降级「转人工」

3.4 运维 / AIOps（健康检查、周报、自愈）

诉求： 指标 → 结构化结论 → 通知；本环境作业 5/6/7/8。

flowchart LR
  A[Dify Agent] --> API[巡检 API / docker / GPU]
  A --> L[LiteLLM → vLLM]
  M[Prometheus/Grafana] --> A
  A --> N[钉钉/邮件]
  A --> F[Langfuse]

建议：生成类用较低 max_tokens；写操作（重启）必须人工确认或强审批，避免「自愈」变「自毁」。

3.5 场景 × 组件速查

场景	必经	常选	可省略（早期）
知识库问答	Dify + 向量库 + Embedding + 聊天模型	Rerank、Langfuse	Higress、K8s
编程助手	模型网关 + 推理	Langfuse、限流	向量库
工具 Agent	Dify + 工具 + 模型	Langfuse、白名单	Milvus
多模型/多部门	LiteLLM	Higress、配额	—
对外统一入口	Higress 或企业 WAF	TLS、WAF 插件	—
合规审计	Langfuse + 网关日志	Vault、WAF	—

4. 组件详解（用途 · 场景 · 优缺点 · 规模建议）

评分口径：适合小公司 / 适合中大 指「作为该层主力是否划算」，不是「绝对不能用」。

4.1 vLLM（模型推理）

项	说明
用途	把权重跑成高吞吐 OpenAI 兼容 HTTP 服务
适合场景	私有聊天、RAG 生成、代码助手、批量评测
优点	生态成熟、连续批处理、吞吐好；与 LiteLLM/Dify 对接简单
缺点	要 GPU；参数/量化/并发调优有门槛；单机是单点
小公司	推荐单机或 1 机多卡；先保证稳定再谈复制
中大	推荐 K8s 多副本 + 健康检查；关键模型多部署；可评估 SGLang/TRT-LLM

本环境：116.62.10.183:8000，经 LiteLLM 转发，业务勿直连裸奔。

4.2 LiteLLM Proxy（模型网关）

项	说明
用途	统一 OpenAI API；按 `model` 路由；多上游 LB；托管上游 Key
适合场景	多模型、多 GPU、虚拟 Key、统一 SDK
优点	与 OpenAI SDK 兼容好；配置直观；LB/降级能力够用
缺点	不是完整 API 网关（WAF/企业 SSO 弱）；高可用要自己做进程守护
小公司	第二模型出现时再上；一个模型时可被 Dify 直连替代
中大	强烈推荐作为 LLM 流量中枢；配合配额与日志

本环境：:4000，Master Key sk-litellm-bocheng-207；详见 LiteLLM部署_cursor。

4.3 Higress（AI 网关 / 总入口）

项	说明
用途	统一入口、TLS、路径/Host 路由、WASM 插件（限流/WAF/缓存/Prompt 拦截等）
适合场景	多后端统一暴露、边缘安全策略、与 Ingress 文化接近的团队
优点	插件丰富（之本环境约 50+）；可与 Istio/云原生对齐；能补 LiteLLM 不做的边缘能力
缺点	与 LiteLLM 职责易重叠（都别抢着做 model 路由）；学习与排障成本高于「只开 LiteLLM」；Dify 等 SPA 不能硬挂子路径
小公司	非必须；有公网暴露或多样入口再上
中大	推荐作为企业入口增强，或对接已有 API 网关；LLM 语义路由仍优先 LiteLLM

本环境：:18080；系列见 Higress 之一～六。

4.4 Dify（应用 / Agent 平台）

项	说明
用途	知识库、Agent、Workflow、工具、提示词、应用发布
适合场景	业务快速搭助手；人机协同；非纯 SDK 项目
优点	私有化友好；上手快；覆盖 RAG+Agent 主流
缺点	超复杂编排不如自研 LangGraph 灵活；高并发要拆读写与扩容；子路径部署坑多
小公司	首选应用层
中大	部门级应用首选；集团级可 Dify + 自研核心流程并存

本环境：:80 日常；经 Higress 用 dify.ai.local:18080。

4.5 Xinference（Embedding / Rerank 等）

项	说明
用途	统一拉起嵌入、重排、部分生成模型
适合场景	RAG 管道；与 Dify 嵌入/Rerank 对接
优点	模型管理方便；OpenAI 兼容向量接口
缺点	与 vLLM 分工要清晰（别所有模型塞一台乱抢 GPU）；生产要独立资源池
小公司	推荐与聊天模型分资源
中大	Embedding/Rerank 独立池；高峰与聊天隔离

本环境：:9997，经 Higress /xf 亦可。

4.6 Weaviate（本环境向量库）与 Milvus（中大常选）

项	Weaviate（现状）	Milvus（中大主流之一）
用途	向量检索，服务 Dify 知识库	大规模向量检索、多租户
优点	与 Dify 集成成熟、部署相对直接	大规模、生态与运维资料多
缺点	超大规模与多租户要额外规划	组件多（etcd/minio 等），运维重
小公司	够用就用 Weaviate/pgvector	一般不必
中大	可继续用，但要备份与容量规划	知识库很大、多 BU 时优先评估

本环境：主用 Weaviate；Milvus 栈可选未切主路径——不要为了「看起来企业」强行双跑。

4.7 Langfuse（LLM 可观测）

项	说明
用途	Trace、Span、Prompt、Token、评分
适合场景	调教提示词、查工具乱调、成本与质量复盘
优点	对 Agent 链路友好；自托管可控数据
缺点	不是基础设施监控；要与 Prom/Grafana 分工
小公司	强烈建议上（否则出了问题只剩猜）
中大	标配；可接评测集与人工标注流程

本环境：:3000，已接 Dify。

4.8 Prometheus + Grafana（基础设施 / SLA）

项	说明
用途	可用性、延迟、GPU/队列、自定义 SLA
适合场景	运维值班、领导大盘、容量预警
优点	云原生事实标准
缺点	不管 Prompt 语义；要自己定义黄金指标
小公司	有对外 SLA 再上；否则 Langfuse + 主机监控也可
中大	标配

本环境：Grafana :3001 等，见集成环境部署文档。

4.9 企业 API 网关 / WAF、Vault、K8s（目标态组件）

组件	用途	小公司	中大
企业 WAF/网关	统一鉴权、防攻击、TLS、流量镜像	Nginx/Caddy 反代往往够	标配，Higress 可做 AI 侧增强或对接
Vault	密钥托管与轮换	权限收紧的 `.env` 过渡	标配
K8s + GPU Operator	弹性、发布、多租户调度	通常过重	多机多卡后推荐
合规模型专线	本地不够用时的补充	按需	有分级数据策略时常见

5. 选型决策（避免重复建设）

需求	优先组件	避免
只想多一个模型名	LiteLLM `config.yaml`	再加一层 Higress 模型路由
对外只暴露一个端口 + TLS/限流	Higress	在 LiteLLM 里硬造 WAF
搭业务助手	Dify	一上来自研全部编排
看清每次工具调用	Langfuse	只看 nginx access
知识库变慢	向量库 + Embedding/Rerank 容量	先怪 vLLM
编程高峰打满 GPU	网关限流 + 排队	无限制开放 Key

6. 与本仓库文档的索引关系

主题	文档
Higress 理论与实装图	`Higress_之一_理论与架构_cursor`
Higress 企业能力（证书/限流/WAF/SSE…）	`Higress_之六_企业级能力展示_cursor`
LiteLLM 路由与 LB	`LiteLLM部署_cursor`
Dify 安装与知识库	`Dify_Qwen安装配置手册_cursor`、专题十三/十四
Langfuse	`Langfuse_部署教程_cursor`、连接专题
SLA 大盘	`集成环境部署_Prometheus_Grafana_SLA_cursor`
场景作业	作业 1～8（工具/客服/AIOps/周报等）

7. 附录 · 本环境端口速查

端口	组件
80	Dify
3000	Langfuse
3001	Grafana
4000	LiteLLM
8001	Higress Console
9997	Xinference
18080 / 18443	Higress Gateway HTTP/HTTPS
183:8000	vLLM

维护：架构变更时先改本专题图 A，再同步 Higress 之一；目标态图 C 随企业规范演进，不必与实验室端口一一对应。