【AI】本地安全RAG + 云端弹性大模型混合架构方案设计

hkNaruto

212人浏览 · 2026-07-14 10:04:18

hkNaruto · 2026-07-14 10:04:18 发布

本地安全RAG + 云端弹性大模型混合架构方案设计

一、项目概述与需求分析

1.1 项目背景

随着大模型技术的成熟，企业希望利用AI智能体提升内部知识管理与客服效率。本项目旨在为一家中型企业设计一套兼顾数据安全与模型能力的RAG（检索增强生成）+ 智能体系统。

1.2 核心需求指标

指标项	具体数值
注册用户数	10,000 人
日活跃用户（DAU）	2,000 人
峰值会话并发	100 QPS（每秒查询次数）
知识库规模	约 2TB（Word / PPT / PDF 为主）
部署形态	企业私有化本地部署
预算级别	中小型企业可承受

1.3 关键约束与决策

在方案设计过程中，我们确立了三条不可妥协的原则：

数据安全第一：企业敏感文档（合同、技术资料、内部制度）绝不离域。RAG检索全链路（文档存储、文本切分、向量索引）必须部署在本地内网。
模型能力决定商业价值：经过实测评估，本地部署的7B~14B参数模型（如Qwen2.5系列）智力水平不足以支撑严肃的企业商用场景。弱模型生成的幻觉答案将使整个系统沦为废纸。
弹性利用云端算力：放弃本地部署百亿级大模型（规避昂贵的A100/H100集群采购），通过购买国内主流云厂商API的方式获取顶尖模型能力。

基于以上约束，最终确立 “本地RAG检索 + 本地智能体编排 + 云端多模型API” 的混合架构。

二、总体架构设计

2.1 逻辑分层架构图

┌─────────────────────────────────────────────────────────────────────────┐
│                         用户接入层                                      │
│              企业内部 Web / App / 企业微信 / 钉钉 机器人                │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                     本地智能体编排层（Dify）                            │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐    │
│  │  意图识别    │  │  查询改写    │  │  多轮对话 & Agent 工作流  │    │
│  └──────────────┘  └──────────────┘  └──────────────────────────┘    │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │           智能模型路由层（核心创新）                             │   │
│  │  · 简单FAQ / 高频问答 → DeepSeek V4 Flash（极致性价比）         │   │
│  │  · 复杂推理 / 工具调用 → DeepSeek V4 Pro / MiniMax M2.7       │   │
│  │  · 超长文档解析（>100K tokens）→ Kimi K2.7 / Qwen3.7-Max     │   │
│  └─────────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────────┘
              │                                     │
              ▼                                     ▼
┌──────────────────────────────┐   ┌────────────────────────────────────┐
│       本地 RAG 检索层         │   │        云端大模型 API 层           │
│  ┌────────────────────────┐  │   │  ┌──────────────────────────────┐ │
│  │  Qdrant 向量数据库     │  │   │  │  多供应商容灾网关             │ │
│  │  （存储2TB文档向量）   │  │   │  │  · 阿里云/DeepSeek官方       │ │
│  └────────────────────────┘  │   │  │  · MiniMax / 硅基流动        │ │
│  ┌────────────────────────┐  │   │  │  · Moonshot(Kimi)            │ │
│  │  BGE-M3 Embedding模型  │  │   │  └──────────────────────────────┘ │
│  │  （本地RTX 4090推理）  │  │   │  ┌──────────────────────────────┐ │
│  └────────────────────────┘  │   │  │  语义缓存（Redis）            │ │
│  ┌────────────────────────┐  │   │  │  高频命中缓存，降低50% API调用│ │
│  │  MinIO + PostgreSQL    │  │   │  └──────────────────────────────┘ │
│  │  （文档源文件+元数据） │  │   │                                   │
│  └────────────────────────┘  │   └────────────────────────────────────┘
└──────────────────────────────┘

2.2 数据流向说明

离线知识入库：Word/PPT/PDF → 本地解析切分 → BGE-M3生成向量 → 存入Qdrant（全程内网，无外泄风险）
在线问答链路：用户提问 → Dify查询改写 → Qdrant混合检索（向量+BM25）→ 召回Top-K文档
云端推理：将“用户问题 + 召回文档片段”拼接 → 经模型路由层选择最优API → 发送至公网大模型 → 流式返回答案
安全隔离：发送至云端的仅有脱敏后的用户问题与检索片段，原始文档从未离开本地

三、本地 RAG 与智能体层详细设计

3.1 硬件配置清单

节点角色	推荐配置	数量	职责
智能体应用节点	16核CPU / 32GB内存 / 100GB SSD	2台（主备）	运行Dify API服务与Worker
向量数据库节点	8核CPU / 32GB内存 / 500GB NVMe SSD	2台（集群）	运行Qdrant，承载2TB文档的向量索引
Embedding推理节点	RTX 4090 24GB / 16核CPU / 64GB内存	1台	运行BGE-M3 Embedding模型（显存占用约4-6GB）
缓存节点	4核CPU / 16GB内存 / 50GB SSD	1台	运行Redis（语义缓存）
存储节点	4核CPU / 8GB内存 / 4TB+ NVMe SSD	1台	运行MinIO（文档源文件）+ PostgreSQL（元数据）

说明：因大模型推理已迁移至云端，本地无需采购A100/H100等昂贵GPU。现有RTX 4090足以胜任Embedding与轻量级Reranker任务。

3.2 开源技术栈选型

组件	选型方案	选型理由
智能体框架	Dify（社区版）	可视化工作流编排、原生支持多模型供应商接入、RBAC权限管理、社区活跃
向量数据库	Qdrant	单机性能优异（延迟~73ms），相比Milvus省去etcd+MinIO三组件，运维成本极低
Embedding模型	BAAI/bge-m3	多语言支持，1024维，在中文MTEB基准上表现优异
对象存储	MinIO	兼容S3协议，私有化部署首选
关系数据库	PostgreSQL 15	Dify元数据存储，稳定可靠
语义缓存	Redis 7	支持高速向量相似度比对，实现智能缓存

3.3 本地服务部署步骤（精简）

Step 1：基础设施（Docker Compose）

# 部署 Qdrant 集群
docker run -d --name qdrant -p 6333:6333 \
  -v ./qdrant_storage:/qdrant/storage \
  qdrant/qdrant:latest

# 部署 MinIO + PostgreSQL + Redis
docker-compose -f docker-compose-data.yml up -d

Step 2：部署 Ollama 并加载 Embedding 模型

curl -fsSL https://ollama.com/install.sh | sh
ollama pull bge-m3:latest
# 验证：ollama list 确认模型已加载

Step 3：部署 Dify

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
# 修改 .env：VECTOR_STORE=qdrant，并配置 QDRANT_HOST
docker-compose up -d

四、云端大模型 API 选型与配置

这是本次方案的智力核心。既然放弃本地小模型，我们就直接对标国内最顶尖、最主流的商用API。

4.1 主流模型价格与能力对比（2026年7月）

模型系列	输入价格（元/MT）	输出价格（元/MT）	核心优势	适用场景
DeepSeek V4 Flash	1（平时）/ 2（高峰）	2（平时）/ 4（高峰）	极致性价比，推理能力接近Pro版	主力模型：高频FAQ、通用客服
DeepSeek V4 Pro	3（平时）/ 6（高峰）	6（平时）/ 12（高峰）	Agent能力强，内部员工使用的编码模型	复杂推理、多步Agent任务
MiniMax M2.7	2.1	8.4	高性能Agent，成本约为Claude Opus的1/15	复杂的业务Agent编排
Kimi K2.7 Code	~6.9	~29	MoE架构，1万亿总参数，256K上下文	超长合同、财报、技术手册解析
豆包 2.1 Pro	6	30	综合成本较Claude降低80%	字节生态、内容生成
Qwen3.7-Max	~18	~54	国产第一，全球评测第五	对效果有极致要求的旗舰场景

特别关注：DeepSeek V4 引入了峰谷定价，每日9:00-12:00及14:00-18:00为高峰时段，其余时段及节假日价格减半。建议将批量离线任务安排在夜间运行。

4.2 模型路由策略（在Dify中实现）

我们不再只用单一模型，而是在Dify工作流中通过IF-ELSE节点实现智能路由：

路由条件	目标模型	成本控制逻辑
问题长度 > 100,000 tokens（超长文档）	Kimi K2.7	仅长文档场景触发，保护上下文窗口
含“分析/推理/编程/总结报表”等关键词（复杂任务）	DeepSeek V4 Pro 或 MiniMax M2.7	高智力投入换取高质量输出
默认情况（80%以上的常规问答）	DeepSeek V4 Flash	极低成本兜底，保证项目经济性

4.3 Dify 多供应商接入配置示例

在Dify后台的“模型供应商”中，选择“OpenAI-API-compatible”类型，分别填入各厂商的Endpoint和Key：

# 概念配置示例
供应商1: DeepSeek
  - 模型: deepseek-v4-flash
    API Key: sk-xxx
    Base URL: https://api.deepseek.com/v1

供应商2: MiniMax
  - 模型: MiniMax-M2.7
    API Key: ey-xxx
    Base URL: https://api.minimaxi.com/v1

供应商3: Moonshot (Kimi)
  - 模型: kimi-k2.7-code
    API Key: sk-xxx
    Base URL: https://api.moonshot.cn/v1

五、成本精算与优化模型

5.1 峰值成本估算（最坏情况）

假设100 QPS持续2小时高峰，平均输入3000 tokens，输出400 tokens，且无缓存的情况下：

模型	日峰值费用（估算）	年化估算（含缓存优化）
DeepSeek V4 Flash（推荐）	~¥5,472	~¥50-80万
DeepSeek V4 Pro	~¥16,416	~¥150-250万
MiniMax M2.7	~¥6,955	~¥60-100万
Kimi K2.7	~¥23,256	~¥200-350万

5.2 三大降本增效利器

语义缓存（杀手锏）：企业高频问答（如“如何申请年假？”“公司报销流程”）命中语义缓存（余弦相似度>0.92）。预计命中率40%-50%，直接使API调用量减半，成本降低50%以上。
峰谷错峰：将数据入库分析、报表生成等非实时任务调度到夜间（非高峰时段），利用DeepSeek V4的5折优惠。
模型路由降级：80%的简单问题跑在Flash上，只有20%复杂问题跑在Pro上，加权平均成本远低于全量使用Pro。

六、安全与合规专项设计

安全层级	具体措施
物理隔离	原始文档、切分块、向量索引绝对不离开企业内网服务器
传输加密	发送至公网API的数据仅包含“用户问题文本+检索片段”，且全程TLS 1.3加密
脱敏处理	在Prompt构建阶段，利用正则表达式过滤身份证、手机号、银行卡号等敏感实体
合规协议	与DeepSeek/MiniMax等厂商签署《数据处理协议》（DPA），明确禁止将请求数据用于模型训练
审计日志	所有API调用记录（含Request/Response长度、耗时、模型版本）全量保留在本地PostgreSQL，支持事后追溯

七、实施路线图（3个月）

阶段	时间	关键里程碑
第一阶段：基建	第1-2周	服务器上架、Docker/K8s环境配置、内网互通性测试
第二阶段：本地RAG部署	第3-4周	Qdrant+MinIO+PostgreSQL+Ollama(bge-m3) 全部就绪
第三阶段：云端API开通	第3-4周（并行）	注册DeepSeek、MiniMax、Kimi官方账号，完成企业实名与充值
第四阶段：Dify集成	第5周	Dify部署完成，接入三家API，验证模型路由逻辑
第五阶段：知识入库	第6-8周	2TB文档分批清洗、切分、向量化入库（首次全量约需2周）
第六阶段：智能体打磨	第8-9周	设计Prompt模板、配置Rerank、调试多轮对话上下文
第七阶段：灰度与全量	第10-12周	内部员工10%灰度 → 50% → 全量100%上线

八、风险应对预案

潜在风险	影响	应对措施
API服务商突然涨价/断供	成本飙升	多供应商容灾：Dify中配置主备切换，一键切流至MiniMax或Kimi
公网延迟抖动	用户体验变差	1. 启用Redis语义缓存（命中直接毫秒级返回）；2. 考虑购买云厂商的“专属VPC直连”服务降低延迟
数据泄露合规审查	法律风险	严格执行脱敏与DPA协议；若审查极严，可回退至方案二（本地部署QwQ-32B量化版，牺牲部分智力）
日峰值超过100 QPS	触发云厂商限流	提前在控制台申请提高QPS配额（通常需要联系商务）

九、方案总结

本方案精准定位了中小企业在AI落地中的核心痛点：买不起高端GPU，但又无法忍受弱智模型的劣质答案。

安全与智能的解耦：将“存数据”与“算数据”分离。数据存本地保安全，计算上云端保智商。
经济性极佳：利用DeepSeek V4 Flash的超低价（1元/百万输入）和语义缓存机制，将年度API成本控制在可接受的范围内，避免了数十万的A100显卡采购费用。
主流模型护航：依托DeepSeek、MiniMax、Kimi等国内一线大厂的SOTA模型，智力水平直接对齐行业顶尖，确保系统具备真正的商业实用价值。
弹性扩展：未来若业务量暴增，只需横向扩展本地Qdrant节点，并上调API调用配额，架构无需大幅改动。

最终建议：立即启动第一阶段基建，同时申请DeepSeek等厂商的试用心额度（新用户通常赠送百万tokens），在真实业务数据上进行为期两周的盲测对比，用实测数据验证Flash与Pro的精度差异，从而确定最终的路由分配比例。

附：部署架构图与软硬件拓扑结构

10.1 整体物理与逻辑拓扑

下图展示了本方案中 本地安全域 与 公网API服务域 之间的软硬件部署关系、网络边界及核心数据流。

┌─────────────────────────────────────────────────────────────────────────────────────────────┐
│                                        用户端                                               │
│            [企业微信]  [钉钉]  [Web PC]  [移动App]  [API调用方]                           │
└───────────────────────────────────────┬─────────────────────────────────────────────────────┘
                                        │ HTTPS (443)
                                        ▼
┌─────────────────────────────────────────────────────────────────────────────────────────────┐
│                              企业内网  (DMZ / 应用层)                                       │
│  ┌──────────────────────────────────────────────────────────────────────────────────────┐  │
│  │                          负载均衡器 (Nginx / HAProxy)                                │  │
│  │                      (SSL终结、限流、反向代理、健康检查)                             │  │
│  └───────────────────────────────┬──────────────────────────────────────────────────────┘  │
│                                  │                                                         │
│                                  ▼                                                         │
│  ┌───────────────────────────────┴──────────────────────────────────────────────────────┐  │
│  │                         智能体应用集群 (Dify)                                        │  │
│  │  ┌─────────────────────┐  ┌─────────────────────┐  ┌─────────────────────┐         │  │
│  │  │   Dify API 节点1    │  │   Dify API 节点2    │  │   Dify Worker 节点  │         │  │
│  │  │  (16C/32G/100G SSD) │  │  (16C/32G/100G SSD) │  │  (16C/32G/100G SSD) │         │  │
│  │  │  容器：api, web     │  │  容器：api, web     │  │  容器：worker, beat │         │  │
│  │  └─────────────────────┘  └─────────────────────┘  └─────────────────────┘         │  │
│  └───────────────────────────────┬──────────────────────────────────────────────────────┘  │
│                                  │                                                         │
│              ┌───────────────────┴───────────────────┬─────────────────────────────┐       │
│              │                                       │                             │       │
│              ▼                                       ▼                             ▼       │
│  ┌───────────────────────┐       ┌───────────────────────────┐   ┌───────────────────────┐│
│  │ 向量数据库集群 (Qdrant)│       │  Embedding推理节点         │   │   缓存节点 (Redis)    ││
│  │  ┌───────────────────┐│       │  ┌───────────────────────┐│   │  ┌───────────────────┐││
│  │  │  Qdrant 节点1     ││       │  │  硬件: RTX 4090 24GB  ││   │  │  Redis 7           │││
│  │  │  (8C/32G/500G     ││       │  │  软件: Ollama         ││   │  │  (4C/16G/50G SSD)  │││
│  │  │   NVMe SSD)       ││       │  │  模型: bge-m3:latest ││   │  │  端口: 6379        │││
│  │  │  端口: 6333,6334  ││       │  │  端口: 11434         ││   │  └───────────────────┘││
│  │  └───────────────────┘│       │  └───────────────────────┘│   └───────────────────────┘│
│  │  ┌───────────────────┐│       └───────────────────────────┘                             │
│  │  │  Qdrant 节点2     ││                                                                 │
│  │  │  (8C/32G/500G     ││                                                                 │
│  │  │   NVMe SSD)       ││                                                                 │
│  │  │  端口: 6335,6336  ││                                                                 │
│  │  └───────────────────┘│                                                                 │
│  └───────────────────────┘                                                                 │
│              │                                                                              │
│              ▼                                                                              │
│  ┌──────────────────────────────────────────────────────────────────────────────────────┐  │
│  │                              存储层 (MinIO + PostgreSQL)                             │  │
│  │  ┌─────────────────────────────────┐  ┌─────────────────────────────────────────────┐│  │
│  │  │  MinIO 对象存储                 │  │  PostgreSQL 15                              ││  │
│  │  │  (4C/8G/4TB+ HDD/SSD)          │  │  (4C/16G/200G SSD)                          ││  │
│  │  │  端口: 9000 (API), 9001 (控制台)│  │  端口: 5432                                 ││  │
│  │  │  存储: 原始文档 (2TB)           │  │  存储: Dify元数据、API调用日志、用户信息   ││  │
│  │  └─────────────────────────────────┘  └─────────────────────────────────────────────┘│  │
│  └──────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                             │
│  ═══════════════════════════════════════ 内网边界 ═══════════════════════════════════════  │
│                                                                                             │
│  ┌──────────────────────────────────────────────────────────────────────────────────────┐  │
│  │                            安全网关 / 防火墙 (NGFW)                                  │  │
│  │    · 仅允许 Dify 节点对外发起 HTTPS (443) 请求                                       │  │
│  │    · 严格的出站白名单：仅放行特定API域名 (api.deepseek.com, api.minimaxi.com, ...)   │  │
│  │    · 入侵检测 / DLP 数据防泄漏                                                       │  │
│  └───────────────────────────────────────┬──────────────────────────────────────────────┘  │
└──────────────────────────────────────────┼─────────────────────────────────────────────────┘
                                           │ HTTPS (TLS 1.3)
                                           │ 请求内容：脱敏后的用户问题 + 检索片段
                                           │ (不包含原始文档)
                                           ▼
┌─────────────────────────────────────────────────────────────────────────────────────────────┐
│                                  公网互联网 / 云API服务商                                   │
│                                                                                             │
│  ┌───────────────────┐  ┌───────────────────┐  ┌───────────────────┐  ┌───────────────┐  │
│  │  DeepSeek API     │  │  MiniMax API      │  │  Moonshot (Kimi)  │  │  阿里云百炼   │  │
│  │  (主用Flash/Pro)  │  │  (备选/复杂Agent) │  │  (超长文档专用)   │  │  (备用渠道)   │  │
│  │  Endpoint:        │  │  Endpoint:        │  │  Endpoint:        │  │               │  │
│  │  api.deepseek.com │  │  api.minimaxi.com │  │  api.moonshot.cn  │  │               │  │
│  └───────────────────┘  └───────────────────┘  └───────────────────┘  └───────────────┘  │
│                                                                                             │
│  注：所有API请求均经过Dify内置的模型路由层，按策略自动选择目标服务商                         │
└─────────────────────────────────────────────────────────────────────────────────────────────┘

10.2 核心数据流详解

10.2.1 离线知识入库流（带编号）

[管理员上传文档] 
      │
      ▼ (1) 通过Dify控制台上传
┌─────────────────┐
│   MinIO存储     │  ← (2) 原始文档持久化 (Word/PPT/PDF)
└────────┬────────┘
         │ (3) 触发异步解析任务
         ▼
┌─────────────────┐
│ Dify Worker     │  ← (4) 文档解析、语义切分 (Chunking)
└────────┬────────┘
         │ (5) 调用Embedding服务
         ▼
┌─────────────────┐
│ Ollama (bge-m3) │  ← (6) 将文本块转为1024维向量
└────────┬────────┘
         │ (7) 向量数据 + 元数据
         ▼
┌─────────────────────────────────────────────┐
│  Qdrant (向量索引)  +  PostgreSQL (元数据)  │  ← (8) 入库完成，等待检索
└─────────────────────────────────────────────┘

10.2.2 在线问答流（带编号）

[用户提问] 
      │
      ▼ (1) 通过Web/企微等入口发起
┌─────────────────┐
│  负载均衡器     │  ← (2) 分发至Dify API节点
└────────┬────────┘
         │ (3) 进入Dify工作流
         ▼
┌───────────────────────────────────────────────┐
│  Dify 智能体工作流 (模型路由决策)              │
│  a. 意图识别 & 查询改写                       │
│  b. 判断问题类型 (简单/复杂/超长)             │
└────────┬──────────────────────────────────────┘
         │ (4) 并行执行两种检索
         ├──────────────────────────────┐
         ▼                              ▼
┌─────────────────────┐  ┌─────────────────────────┐
│ Qdrant 向量检索     │  │ PostgreSQL BM25关键词检索│
│ (语义相似度)        │  │ (精确匹配)               │
└──────────┬──────────┘  └───────────┬─────────────┘
           │                         │
           └──────────┬──────────────┘
                      ▼ (5) 混合检索结果融合 (RRF算法)
┌─────────────────────────────────┐
│  本地重排序 (可选，用CPU/GPU)   │  ← (6) 精排Top-10 → Top-3
└────────────────┬────────────────┘
                 │ (7) 构造Prompt: [用户问题] + [检索到的Top-3片段]
                 ▼
┌─────────────────────────────────────────────────────────┐
│  智能模型路由层 (根据路由规则选择API)                   │
│  · 默认 → DeepSeek V4 Flash                            │
│  · 复杂推理 → DeepSeek V4 Pro / MiniMax M2.7          │
│  · 超长上下文 → Kimi K2.7                              │
└────────────────┬────────────────────────────────────────┘
                 │ (8) 通过安全网关发起HTTPS请求
                 ▼
┌─────────────────────────────────┐
│  公网大模型API (返回生成答案)   │  ← (9) 流式或非流式响应
└────────────────┬────────────────┘
                 │ (10) 答案返回Dify
                 ▼
┌─────────────────────────────────┐
│  可选：Redis语义缓存写入        │  ← (11) 若为高频问题，缓存向量+答案
└────────────────┬────────────────┘
                 │ (12) 最终答案返回用户
                 ▼
              [用户]

10.3 软件部署拓扑（容器视角）

所有本地组件均以容器方式运行，统一由Docker Compose（或Kubernetes）编排。下图展示各容器之间的依赖关系：

┌──────────────────────────────────────────────────────────────────────┐
│                          Docker 网络 (bridge)                       │
│                                                                      │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │                    Dify 应用容器组                          │   │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌──────────────┐ │   │
│  │  │ api     │  │ web     │  │ worker  │  │ beat         │ │   │
│  │  │ (Flask) │  │ (React) │  │ (Celery)│  │ (Celery Beat)│ │   │
│  │  └────┬────┘  └─────────┘  └────┬────┘  └──────────────┘ │   │
│  │       └────────────┬────────────┘                          │   │
│  └────────────────────┼───────────────────────────────────────┘   │
│                       │                                           │
│              依赖服务  │                                           │
│                       ▼                                           │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │                    第三方服务容器组                         │ │
│  │  ┌─────────────┐  ┌─────────────┐  ┌───────────────────┐  │ │
│  │  │ PostgreSQL  │  │   Redis     │  │   MinIO           │  │ │
│  │  │ (元数据)    │  │ (缓存/队列) │  │ (对象存储)        │  │ │
│  │  └─────────────┘  └─────────────┘  └───────────────────┘  │ │
│  │  ┌─────────────┐  ┌──────────────────────────────────────┐ │ │
│  │  │  Qdrant     │  │   Ollama (bge-m3)                    │ │ │
│  │  │ (向量库)    │  │   (Embedding推理)                    │ │ │
│  │  └─────────────┘  └──────────────────────────────────────┘ │ │
│  └─────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘

10.4 硬件机柜布局示意（物理视图）

┌─────────────────────────────────────────────────────────────┐
│                         机柜 (42U)                          │
├─────────────────────────────────────────────────────────────┤
│  1U │  交换机 (核心网络)                                  │
├─────┼─────────────────────────────────────────────────────┤
│  1U │  防火墙 / 安全网关                                  │
├─────┼─────────────────────────────────────────────────────┤
│  2U │  服务器1: Dify 应用节点1 (2*CPU 16核, 32GB RAM)    │
├─────┼─────────────────────────────────────────────────────┤
│  2U │  服务器2: Dify 应用节点2 (2*CPU 16核, 32GB RAM)    │
├─────┼─────────────────────────────────────────────────────┤
│  2U │  服务器3: Qdrant 节点1 + 存储节点 (8核, 32GB,     │
│     │           500GB NVMe SSD + 4TB HDD)                │
├─────┼─────────────────────────────────────────────────────┤
│  2U │  服务器4: Qdrant 节点2 + 缓存节点 (8核, 32GB,     │
│     │           500GB NVMe SSD + 50GB SSD)               │
├─────┼─────────────────────────────────────────────────────┤
│  4U │  服务器5: Embedding推理节点 (RTX 4090 24GB,        │
│     │           16核CPU, 64GB RAM, 200GB SSD)            │
├─────┼─────────────────────────────────────────────────────┤
│  2U │  服务器6: 备用/监控节点 (Prometheus+Grafana)       │
├─────┼─────────────────────────────────────────────────────┤
│  剩余 │  散热 & 冗余电源                                   │
└─────────────────────────────────────────────────────────────┘

10.5 网络端口映射清单

服务	容器端口	主机映射端口	协议	访问来源
Dify Web UI	3000	80/443	HTTP/HTTPS	用户浏览器
Dify API	5001	5001	HTTP	内部调用
Qdrant gRPC	6334	6334	gRPC	Dify Worker
Qdrant HTTP	6333	6333	HTTP	管理/监控
Ollama API	11434	11434	HTTP	Dify Worker
MinIO API	9000	9000	HTTP/S3	Dify Worker
MinIO Console	9001	9001	HTTP	管理员
PostgreSQL	5432	5432	TCP	Dify服务
Redis	6379	6379	TCP	Dify服务
Nginx/HAProxy	80/443	80/443	HTTP/HTTPS	外部用户
SSH管理	22	22	TCP	运维人员

安全策略：所有对外暴露端口仅限内网访问，公网访问仅开放Dify Web UI（需配置SSL证书）及API网关。出站流量严格限制为各API服务商的域名和443端口。

附：成本评估

11.1 三种方案定义

本章对三种部署方案进行全生命周期的成本对比分析：

方案	定义
方案A：混合部署（本方案）	本地RAG检索（1台RTX 4090服务器）+ 云端大模型API（DeepSeek V4 Flash为主）
方案B：全自建-中配	4卡A100 80GB服务器 + 本地部署QwQ-32B/Qwen2.5-72B等开源模型
方案C：全自建-高配	8卡A100 80GB服务器 + 本地部署DeepSeek V4等顶级开源模型

11.2 成本对比总览（3年TCO）

成本项	方案A：混合部署	方案B：全自建-中配（4×A100）	方案C：全自建-高配（8×A100）
一次性硬件投入	~¥5万	~¥80万	~¥150万
年API调用费	~¥50-80万	0	0
年运维人力	~¥20-40万	~¥40-80万	~¥60-120万
年电费+机房	~¥2万	~¥15万	~¥30万
3年总成本	~¥230-310万	~¥280-420万	~¥420-690万
3年成本差异	—	高出约¥50-110万	高出约¥190-380万

关键结论：混合部署方案不仅在初期投入上节省95%以上，在3年总成本上也具备明显优势，且模型智力水平对齐行业顶尖。

11.3 方案A：混合部署（本方案）成本详解

11.3.1 一次性硬件投入

项目	配置	数量	单价	小计
Dify应用节点	16核/32GB/100GB SSD	2台	~¥2万	~¥4万
Qdrant节点	8核/32GB/500GB NVMe	2台	~¥3万	~¥6万
Embedding推理节点	RTX 4090 24GB / 16核 / 64GB	1台	~¥4万	~¥4万
Redis缓存节点	4核/16GB/50GB SSD	1台	~¥1万	~¥1万
存储节点	4核/8GB/4TB	1台	~¥2万	~¥2万
网络设备	交换机/防火墙	1套	~¥2万	~¥2万
硬件合计				~¥19万

本方案硬件投入约19万元，其中RTX 4090服务器是唯一GPU设备。相比全自建方案，节省了A100采购费用。

11.3.2 年度API调用费（核心成本）

基于100 QPS峰值、日均2000活跃用户的业务场景：

假设条件：

日峰值请求数（2小时高峰）：720,000次
每次请求平均输入：3,000 tokens（含检索上下文）
每次请求平均输出：400 tokens
语义缓存命中率：50%（高频问题命中缓存）
全年运营天数：250个工作日

年API调用量估算：

项目	计算	结果
年总请求数	720,000 × 250	1.8亿次
缓存命中率	50%	9,000万次命中
实际API调用	1.8亿 × 50%	9,000万次
年输入tokens	9,000万 × 3,000	2.7万亿
年输出tokens	9,000万 × 400	360亿

年API费用（DeepSeek V4 Flash，平时价格） ：

计费项	用量	单价	费用
输入（缓存命中）	2.7万亿 × 50% = 1.35万亿	0.02元/百万	¥2,700
输入（缓存未命中）	2.7万亿 × 50% = 1.35万亿	1元/百万	¥135,000
输出	360亿	2元/百万	¥72,000
年API费用合计			~¥21万

说明：以上为平时价格估算。若部分请求在高峰时段（9:00-12:00、14:00-18:00）调用，费用将翻倍。实际年均费用预计在¥30-50万区间。DeepSeek-V4-Flash在平时段百万tokens输入（缓存命中/未命中）分别为0.02元和1元，输出为2元。

多模型路由的成本影响：

80%请求使用Flash：年费约¥17-40万
20%复杂请求使用Pro：年费约¥10-30万
综合年API费用：约¥30-70万

11.3.3 年度运维成本

项目	费用
运维人力（1人，兼职）	~¥20-30万/年
电费+机房（6-7台服务器）	~¥2万/年
网络带宽	~¥1万/年
年运维合计	~¥23-33万

11.3.4 方案A 3年总成本

项目	第1年	第2年	第3年	3年合计
硬件投入	¥19万	—	—	¥19万
API调用费	¥30-50万	¥30-50万	¥30-50万	¥90-150万
运维成本	¥23-33万	¥23-33万	¥23-33万	¥69-99万
年度合计	¥72-102万	¥53-83万	¥53-83万	¥178-268万

11.4 方案B：全自建-中配（4×A100 80GB）成本详解

11.4.1 一次性硬件投入

4卡A100 80GB服务器属于中端AI服务器配置：

项目	配置	数量	单价	小计
4×A100 80GB服务器	双路至强/512GB内存/4TB NVMe	1台	~¥50-80万	~¥50-80万
配套网络设备	InfiniBand交换机	1台	~¥5-10万	~¥5-10万
机柜/制冷/UPS	基础设施	1套	~¥5万	~¥5万
硬件合计				~¥60-95万

A100 80GB单卡价格稳定在4.8-5.2万元区间。4卡服务器（含双路至强+1TB内存）报价约50-80万元。配套存储与网络设备成本占比可达20%。

11.4.2 年度运维成本

项目	费用
GPU运维工程师	~¥30-60万/年
模型工程师	~¥40-80万/年
安全合规专员	~¥20-40万/年
电费（4×A100约2,400W）	~¥5万/年
机房/制冷	~¥10万/年
年运维合计	~¥105-195万

11.4.3 隐性成本

项目	说明
GPU故障率	8卡集群年故障率约15%，单次更换成本（含数据迁移）3-5万元
模型更新成本	需定期重新训练/微调模型，消耗大量算力
技术债务	硬件锁定风险，无法自由升级GPU

11.4.4 方案B 3年总成本

项目	第1年	第2年	第3年	3年合计
硬件投入	¥60-95万	—	—	¥60-95万
运维成本	¥105-195万	¥105-195万	¥105-195万	¥315-585万
隐性成本	¥3-5万	¥3-5万	¥3-5万	¥9-15万
年度合计	¥168-295万	¥108-200万	¥108-200万	¥384-695万

11.5 方案C：全自建-高配（8×A100 80GB）成本详解

11.5.1 一次性硬件投入

8卡A100 80GB服务器属于企业级旗舰配置：

项目	配置	数量	单价	小计
8×A100 80GB服务器	双路至强8462Y/1TB内存	1台	~¥58-80万	~¥58-80万
分布式存储	Lustre/全闪存阵列	1套	~¥15万	~¥15万
InfiniBand网络	高速交换机	1套	~¥10万	~¥10万
基础设施	机柜/制冷/UPS	1套	~¥5万	~¥5万
硬件合计				~¥88-110万

8卡A100服务器主流报价58-65万元，某互联网大厂批量采购成交价55.8万元/台。入门级8卡A100服务器约28-35万元。

11.5.2 年度运维成本

与方案B类似但更高，因集群规模更大、故障率更高：

项目	费用
GPU运维团队（2人）	~¥60-100万/年
模型工程师（2人）	~¥80-120万/年
安全合规专员	~¥20-40万/年
电费（8×A100约4,800W）	~¥10万/年
机房/制冷	~¥20万/年
年运维合计	~¥190-290万

11.5.3 方案C 3年总成本

项目	第1年	第2年	第3年	3年合计
硬件投入	¥88-110万	—	—	¥88-110万
运维成本	¥190-290万	¥190-290万	¥190-290万	¥570-870万
隐性成本	¥5-10万	¥5-10万	¥5-10万	¥15-30万
年度合计	¥283-410万	¥195-300万	¥195-300万	¥673-1,010万

11.6 三种方案核心指标对比

对比维度	方案A：混合部署	方案B：4×A100自建	方案C：8×A100自建
初期硬件投入	~¥19万	~¥60-95万	~¥88-110万
3年总成本	~¥178-268万	~¥384-695万	~¥673-1,010万
模型智力水平	行业顶尖（DeepSeek V4）	中高（QwQ-32B/72B）	高（开源旗舰）
数据安全性	高（文档不离域）	极高（完全内网）	极高（完全内网）
运维复杂度	低	高	极高
扩展灵活性	高（API按量扩展）	低（硬件瓶颈）	低（硬件瓶颈）
技术迭代速度	快（API持续更新）	慢（需手动升级模型）	慢（需手动升级模型）
GPU故障风险	低（仅1张4090）	中（4张A100）	高（8张A100）

说明：方案B的“模型智力水平”取决于具体部署的模型。4×A100 80GB可支撑70B参数模型的推理，可部署QwQ-32B或Qwen2.5-72B等开源模型，但与DeepSeek V4等千亿级MoE模型仍有代际差距。

11.7 成本敏感性分析

11.7.1 API调用量对方案A成本的影响

日均API调用量	年API费用	3年总成本（方案A）
50万次/日（保守）	~¥10-20万	~¥140-200万
100万次/日（基准）	~¥30-50万	~¥178-268万
200万次/日（激进）	~¥60-100万	~¥240-350万

11.7.2 硬件价格波动对方案B/C的影响

2026年A100 GPU服务器价格持续走低：

8卡A100服务器从2025年的80万+降至2026年的58-65万
预计2027年将进一步下降10-15%

但仍需注意：

A100需搭配高速网络（InfiniBand）和分布式存储，配套设备成本占比可达20%
GPU故障率随规模指数级上升

11.8 成本优化建议

11.8.1 方案A（混合部署）优化

语义缓存：高频问答缓存命中率50%，直接降低50% API调用成本
峰谷错峰：批量任务安排在夜间非高峰时段，享受5折价格
模型路由降级：80%简单问题用Flash，仅20%复杂问题用Pro
预留实例：如用量稳定，可考虑购买Token套餐包进一步降价

11.8.2 方案B/C（全自建）优化

竞价实例替代：短期峰值需求可租赁云端A100，而非满配采购
GPU资源共享：通过容器化Kubernetes调度，GPU利用率可从35%提升至78%
3年期预付费：云服务商3年期预付费可享4-5折

11.9 本章小结

维度	结论
最低成本	方案A（混合部署）3年TCO约¥178-268万，比方案B低50%以上
最低初期投入	方案A仅需~¥19万硬件投入，是方案B的1/4、方案C的1/6
最高模型智力	方案A使用DeepSeek V4等云端旗舰模型，智力水平行业顶尖
最高数据安全	方案B/C完全内网，但需承担极高运维成本和硬件老化风险
最佳综合性价比	方案A（混合部署）在成本、智力、安全、运维四维度取得最佳平衡