第 02 讲 | AI 应用架构的七层思维框架
本节我们将掌握：
- 一个端到端的AI应用分析框架（七层模型）
- 七层模型在AI应用体系的关注点（AI构建在传统能力之上，有很多特殊的关注点，不过传统架构是基础，也要了解）
- 建立全局视角，为后续22讲的深入学习奠定基础
架构框架的必要性
无论是传统的应用，还是AI应用，我们都需要关注架构体系。这可以让我们快速定位，系统思考，而且这种分层体系比较的贴近数据流以及大家的直觉，非常容易理解
传统应用
手机/web -> 网关->（微）服务->数据库/Redis等组件-> 基础设施AI应用
手机/web -> 网关+AI特色能力->（微）服务 + AI特色服务->数据库/Redis等组件+ AI特色组件-> 大模型(新增）->基础设施+AI特色基础设施这样对比其实很简单，唯一的不同就是，AI在原有架构的基础上，在各个层面都增加了AI的特别内容，这也是本课程要讲解的要点。
一个说明：这个七层框架是**"构建 AI 产品"的架构地图——我们为用户设计、开发、运维 AI 系统时，用这七层来定位和思考。而"用 AI 构建"**（Claude Code 编程、Agent 辅助架构设计、个人工具链提效）是另一条线，在第四篇 AI Coding 展开。
七层架构框架
从上到下，以用户视角，一个完整的 AI 应用可以分为七层：
| 层级 | 名称 | 核心组件 | 定位 |
|---|---|---|---|
| 7 | 接入层 | 客户端（Web/App/SDK）+ 网关（CDN/WAF/API Gateway） | 用户交互 + 流量入口，两个关注点 |
| 6 | 服务层 | 用户&多租户体系，以及跟用户有关的权限、费用、运营等能力 | 和传统 SaaS 重叠，但是关注token |
| 5 | 应用能力层 | RAG 引擎 / Agent 编排 / Prompt 管理 / 输出清洗 | AI 架构师的核心战场 |
| 4 | 模型能力层 | 模型网关 / 多模型路由 / 容灾降级 / 成本管控 | 传统应用没有这一层 |
| 3 | 数据能力层 | 业务库 / 向量库 / 缓存 / 知识库 / 数据管道 | AI 引入向量数据库 |
| 2 | 基础设施层 | 云服务器 / 容器 / K8s / GPU 实例 / 推理运行时 | AI 的核心区别：需不需要 GPU |
| — | 治理体系 | 可观测性 / SLO / 版本管理 / 安全 / 成本治理 | 横切所有层，事实上不占层号 |
重要说明：
- 这不是学习顺序——后续课程会按6大技术方向展开（Agentic、LLM架构、AI Harness等），每个方向会涉及多个层次
- 这不是强制清单——0→1阶段的MVP可能只有3-4层，但我们要知道未来需要补什么
- 这是分析工具——拿到任何AI项目，用这个框架快速拆解，检查有没有遗漏的关键维度
- 层与层之间有依赖——上层依赖下层的能力，但设计时要从上往下思考（先明确业务需求，再选技术方案）
逐层解析（注意AI Vs 传统）
下面从用户视角到基础设施，逐层讲解每一层的职责、AI场景的特殊性、以及常见误区。
第 7 层：接入层
这一层包含两个完全不同的关注点：
- 端侧（代码跑在用户设备上）：Web 前端、移动 App、桌面客户端、SDK
- 网关层（代码跑在服务器上）：CDN、WAF、API Gateway（Kong/APISIX/Traefik）、负载均衡
前者关注 UI 交互和用户体验，后者关注认证、限流、安全、Metering 埋点。工程上它们分属前端和后端，但在架构全景图中合为一层——因为对用户来说，它们都是"和 AI 系统交互的入口"。
AI 应用在这层的核心差异：关注点变了。 就像第 4 层的 AI 网关和传统 API 网关关注点完全不同一样，AI 应用的接入层也不只是"请求进来、结果出去"——它还需要关注 Token 计量、概率性输出的用户体验、以及 AI 特有的安全边界。
AI vs 传统：接入层的关注点差异
| 维度 | 传统 Web 接入层 | AI 应用接入层 |
|---|---|---|
| 核心关注⭐ | 路由、负载均衡、CDN 缓存 | Token 计量与计费、额度分配、限流入口、模型切换、流式体验 |
| 交互模式 | 请求-响应（确定性的） | 请求-响应 + 流式输出 + 长任务轮询 |
| 用户体验 | 点击 → 等 < 3 秒 → 完整结果 | 打字 → 首字 < 1 秒 → 渐进生成 → 可能失败 |
| 前端技术 | React/Vue + REST API | React/Vue + SSE/WebSocket + 流式渲染 |
| 错误处理 | 弹窗提示、404 页面 | 优雅降级 + 重新生成 + 停止生成按钮 |
| 安全边界 | XSS、CSRF、SQL 注入 | 前端不能直连 LLM API（密钥泄露 + 成本失控） |
客户端这部分，最典型的就是“对话框+流式交互”，演化出了“openai"、”豆包"，网站侧边栏等AI 应用及其特有的交互模式。
网关这部分，也演化出很多独立的产品，比如Lite-LLM, Portkey等，从他们的功能上我们也可以看出传统网关和AI网关的不同。
前端架构的关键决策
决策点 1：要不要流式输出？
是：（高自由度场景：对话、长文生成） → 必须用，LLM等待很久，不用用户会以为卡死了。
否：（SaaS应用等有特定工作流程和目的的产品，如分类、翻译、提取、人在循环的工作流） → 同步/异步HTTP调用即可决策点 2：如何处理生成失败？
代码只为想了解原理同学准备，非编程场景可不看
// 错误示例：直接弹窗报错
if (response.error) {
alert("生成失败"); // 用户体验极差
}
// 正确做法：优雅降级 + 重试机制
if (response.error) {
showPartialResult(); // 显示已生成的部分
showRegenerateButton(); // 提供"重新生成"按钮
suggestAlternativeAction(); // 建议其他操作（如简化问题）
}一个常见的架构陷阱
问题：企业场景，前端直接调用 LLM API
后果：
- API Key 泄露（前端/App代码可以被反编译）
- 无法做统一的成本管控和限流
- 难以实现复杂的业务逻辑（如权限检查、审计日志、合规）
正确架构：
前端 → 我们的后端 API → AI网关 → LLM API
↑ ↑
权限检查 成本计量/限流/审计架构师决策清单：
- 对话类应用支持流式输出（SSE），非对话类可以用普通 HTTP
- 企业应用，前端永远不要直接调用 LLM API （个人的或者MVP项目可以怎么简单怎么来）
- 设计好"生成失败"的用户体验（重试、降级、引导）
- 首字延迟（TTFT）是关键指标，目标 < 1 秒
第 6 层：服务层
这一层做的是业务逻辑：用户体系（注册/登录/组织）、计费结算（算账、定价、账单）、细粒度权限（谁能用什么模型/知识库）、运营后台。
和 L7 网关层的边界：L7 做请求级的"能不能进"（认证、粗限流、安全），可以多项目共用；L6 做业务级的"能干什么"（细化权限、计费结算、业务规则），往往是单个项目独有的。LiteLLM 这类 AI 网关做的鉴权/限流属于 L7，而用户注册登录、用户的Token/服务账单结算属于 L6。
有些企业是做了一个统一的网关服务，集成了类似LiteLLM的SDK，这样的网关具备L6服务层+L7网关层两重属性。但在业界，网关往往可以是独立的产品，多项目共用，和具体业务无关，甚至作为独立云服务不和产品DB交互，所以分两层是合适的。
服务层能力和传统 SaaS 高度重叠，但有几个 AI 特有的关键点。
AI vs 传统：服务层的三大差异
差异一：计费模型（最重要）
| 维度 | 传统 SaaS | AI SaaS |
|---|---|---|
| 计费维度 | 功能模块 / 用户数 / 存储空间 | 用户Token/Credit / 服务额度的消耗 + 功能模块 |
| 成本可预测性 | 高（用户和功能确定，成本就确定） | 低（同一功能，不同用户 Token 消耗差异巨大） |
| 用量控制 | 不需要特别控制 | 必须做额度管理、用量预警、超额处理 |
| 定价策略 | 固定套餐 | 基础订阅 + 按量超额 / 纯按量 / 分档套餐 |
真实案例：同样是"AI 分析"功能（以下为示意数据）
- 用户 A 输入 100 字 → Token 成本较低
- 用户 B 输入 2000 字 + 上传 10 页 PDF → Token 成本可能是用户 A 的数十倍
如果按传统 SaaS 的"固定套餐"定价，要么亏死（用户 B 太多），要么被骂贵（用户 A 觉得不值）。
AI SaaS 常见计费模式：
- 按次计费：简单粗暴，适合 Token 消耗稳定的场景
- 按 Token 计费：精确但用户不友好（用户看不懂 Token 是什么）
- 分档套餐：每月 X 次 AI 操作，超出部分按量计费（体验最优）
- 混合计费：基础订阅费 + 按量超额（平衡成本和体验）
详见第 20 讲（云原生 AI SaaS 架构）。
差异二：权限体系的扩展
传统应用的权限：谁能访问哪个功能/数据。
AI 应用的权限还要考虑：
- 模型访问权限：普通用户只能用 GPT-4o-mini，管理员才能用 GPT-4o
- Token 配额：每个用户/部门的月度 Token 上限 / 服务额度。
- 知识库可见性：RAG 场景下，用户只能检索到有权限的文档
- 工具调用权限：某些 Agent 工具（如删除数据）需要额外授权
差异三：运营后台的新增模块
传统 SaaS 后台：用户管理、订单管理、数据统计。
AI SaaS 后台还要加：
- Prompt 管理界面：运营人员可以调整 System Prompt，不用等研发发版
- 评测看板：实时监控准确率、幻觉率、用户满意度
- 成本分析：按功能/用户/模型维度查看 Token 消耗
- Bad Case 标注：收集错误案例，用于优化 Prompt 和模型
架构建议
- 复用成熟方案：用户体系、权限、支付优先选用 Auth0、Stripe 等 PaaS 服务，缩短上线周期。
- 重点自建 AI 特有模块，但要追求“可扩展、可编排”：
- 计费引擎：设计成策略模式，支持按 Token / 时长 / 模型等级 / 任务复杂度的多维计价，并可热加载折扣规则。
- 权限体系：采用 ABAC 模型，融合组织层级、部门预算、个人配额，实现“谁在何时能用何模型花多少钱”的动态管控。 （RBAC模型也可以，但AI时代可能不是特别灵活）
- 运营后台：内置 Prompt 自动优化（基于用户反馈的 Bad Case 分析与 Prompt 调优）和成本异常检测（基于时序分析的突发 Token 告警），变"事后管理"为"智能运营"。
- 异步：将计费计量、权限变更、日志采集等异步解耦，甚至做到独立模块、读写分离，使L6可扩展，独立运维，可被多种服务（如BI、运营服务）引用而不影响主流程性能。
架构师决策清单：
- 计费锚点放在哪：Token 计量建议在模型调用侧（L7 或推理代理）就埋点上报，L6 只做聚合与计费结算；如果埋点太晚（比如只在业务侧计），会漏掉 RAG 检索、工具调用带来的隐性成本。拍板点：计量 SDK 要嵌在推理链路里，不是业务代码里。
- 计费精度 vs 用户可理解性：纯按 Token 计费最准但用户看不懂，纯分档套餐最简单但厂商扛波动。拍板点：面向 C 端用"次/额度"包装 Token（内部换算），面向 B 端开放 Token 明细供对账。
- 额度控制的"挡位"设在哪：L7 做粗限流（防止击穿），L6 做额度扣减（涉钱，必须事务 + 幂等），超额后是"拒请求"还是"降级到便宜模型"还是"走审批"——拍板点：降级策略要产品一起定，技术只给能力。
- 权限模型选 RBAC 还是 ABAC：用户/角色少、模型只有两三个，RBAC 够用；但只要出现"部门预算 + 模型等级 + 知识库范围"三维组合，直接上 ABAC，别在 RBAC 上打补丁打到后面没人敢动。
- 哪些模块绝对不自制：用户体系（Auth0 / Keycloak）、支付（Stripe / 国内支付渠道 SDK）、邮件短信——这些的自制 ROI 为负，省下的时间全砸在 AI 特有模块（计费引擎、评测、Prompt 管理）上。
第 5 层：应用能力层（⭐极大加强）
这是 AI 应用架构中最复杂、决策密度最高的一层。传统应用里不存在对应的层——它完全是因为"要把大模型的能力和业务逻辑结合起来"才诞生的。
如果说第 4 层（模型能力层）是"厨师团队"，这一层就是"餐厅经理"——决定什么时候用什么菜系、怎么组合菜品、如何保证出品质量。
AI vs 传统：应用层的本质变化
| 维度 | 传统应用 | AI 应用 |
|---|---|---|
| 核心逻辑 | 确定性代码（if-else） | 概率性推理（LLM）+ 确定性流程（编排） |
| 开发模式 | 写代码实现功能 | 写 Prompt + 编排工作流 + 调参 |
| 质量控制 | 单元测试覆盖 | 评测集 + 人工审核 + 在线监控 |
| 迭代方式 | 改代码 → 测试 → 发布 | 改 Prompt/配置 → A/B 测试 → 灰度 |
| 调试难度 | 断点调试、日志追踪 | 黑盒推理、需要 Trace 全链路 |
这一层的六大核心组件
| 组件 | 解决的问题 | 对应课程 | AI 特异性 |
|---|---|---|---|
| RAG 引擎 | 从知识库检索信息，增强生成准确性 | 第 09-10 讲 | 语义检索 vs 传统关键词搜索 |
| Agent 编排引擎 | 让 LLM 自主规划、调用工具、多步完成任务 | 第 03-08 讲 | 概率性推理的工程管理 |
| Prompt 管理 | System Prompt 的版本管理、模板化、A/B 测试 | 第 15 讲 | Prompt 即代码，需要工程化 |
| 输出格式化与校验 | 处理 LLM 不可靠的输出格式，确保下游稳定 | 第 10 讲 | 输出清洗与一致性校验 |
| 状态管理 / 记忆层 | 上下文记忆/分层记忆/中断恢复/多步执行能力 | 第 06 讲 | 大模型无内置记忆，需外挂状态管理 |
| 工具平台（MCP） | 标准化工具的注册、发现、调用 | 第 06-07 讲 | LLM 与外部世界的桥梁 |
最重要的架构决策：Pipeline vs Agent vs RAG
这是 AI 应用开发中最常见的架构陷阱——"什么都想用 RAG/Agent"。
正确的决策树：
第一步：大模型本身能力&网上公开信息 是否足够支撑场景。
├── 否（不够） → 需要 RAG 补充私有/领域知识
└── 是（够了） → 跳过 RAG，直接用 Prompt 即可
第二步：任务的执行步骤是确定的吗？
├── 是，且步骤固定 → 固定 Pipeline（最简单、最可控、最便宜）
│ 例：用户提问 → 检索知识库 → 生成答案 → 格式化输出
│
├── 是，但步骤间需要动态判断 → 带条件分支的 Pipeline
│ 例：如果检索结果为空 → 走兜底逻辑；如果有结果 → 继续生成
│
└── 否，需要模型自主决策/人决策下一步 → Agent（最灵活、最能发挥AI能力，但最难控、最贵）
例："帮我调研竞品并生成报告"（模型自己决定搜什么、怎么分析）真实案例对比：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| FAQ 问答机器人 | RAG + 固定 Pipeline | 步骤确定，无需自主决策 |
| 代码补全 | 固定 Pipeline | 上下文清晰，输出格式固定 |
| 数据分析助手 | Agent + RAG | 需要自主决定查哪些表、怎么分析 |
| 创意写作助手 | Agent | 需要多轮迭代、自我修正 |
| 客服工单分类 | 固定 Pipeline | 简单的文本分类任务 |
教训举例：某团队花 3 个月开发了一个"全能 Agent"，结果发现 80% 的场景用固定 Pipeline 就能解决，而且 Pipeline 方案速度更快、成本更低、稳定性更高。
原则：能用 Pipeline 解决的，绝不上 Agent。
详见第 10 讲（LLM 模型选型与输出质量管控）。
架构师决策清单：
- 选 Pipeline 还是 Agent：如果业务方说"流程就是这样，不会变"——选 Pipeline；如果业务方说"看情况，有时候这样有时候那样"——选 Agent。作为工程师，别替产品决策。
- RAG 的召回精度不够怎么办：先调 chunk 策略 + embedding 模型，不行再加 reranker...不要一上来就搞复杂。有时候不同的场景用不同的方案更加重要。
- 输出校验做到什么粒度：如果下游是 API 调用（如写数据库），输出必须严格校验 + 重试 + 降级；如果下游是展示给用户看，宽松校验 + 前端兜底即可。拍板点：校验粒度和风险成正比，否则永远上不了线。
第 4 层：模型能力层
这是 AI 应用和传统应用最大的架构差异。传统应用不需要"调用一个外部智能服务来做核心计算"。
这一层的四个核心决策
决策一：模型选型
不同任务适合不同模型，不是"越贵越好"：
| 任务类型 | 选型策略 | 原因 |
|---|---|---|
| 复杂推理、代码生成 | 旗舰模型（Claude Sonnet/GPT-4o 级别） | 质量优先，不能出错 |
| 简单分类、提取、格式化 | 轻量模型（GPT-4o-mini/Flash 级别） | 成本敏感，轻量模型足够 |
| 代码补全、嵌入 | 专用小模型 | 延迟敏感，专用模型更快 |
| 敏感数据场景 | 自部署开源模型 | 数据不出境 |
关键原则：按任务类型路由模型，而不是一刀切用同一个。
决策二：容灾降级
模型服务会宕机、会限流，必须有 Plan B：
主力模型（如 Claude Sonnet）不可用？
├── 降级到备用模型（如 GPT-4o）
├── 备用也不可用？→ 降级到轻量模型（如 GPT-4o-mini）
└── 全不可用？→ 返回缓存结果 or 提示用户稍后重试这不是理论设计——主流模型提供商每年都会有几次宕机事件，现在因为云厂商算力不足，也经常限流，不做容灾风险极大。
决策三：成本优化
Token 成本是 AI 应用最大的变动成本，必须管控：
- 分层缓存/语义缓存：相似问题命中缓存，不调模型（如"公司政策是什么"和"公司有什么规定"）
- 批量异步：离线任务用”批量推理”或者”闲时算力”（如 DeepSeek 峰谷价格、阿里云 Night Plan），成本通常显著降低。
- Token 预算：按用户/功能设上限，防止账单失控
- 路由优化：简单任务走便宜模型，复杂任务才用贵模型
决策四：统一调用抽象
业务代码不应该直接绑定某个模型的 API：
代码只为想了解原理同学准备，非编程场景可不看
# 错误做法：硬编码模型
response = openai.chat.completions.create(model="gpt-4o", messages=[...])
# 正确做法：通过抽象层调用
response = model_service.call(task_type="analysis", prompt="...")
# 底层路由到哪个模型，业务代码不关心这样切换模型、加新模型、做灰度，都不需要改业务逻辑。
详见第 11 讲（版本管理与灰度发布）、第 12 讲（成本管控与性能调优）、第 13 讲（稳定性治理与 SLO）。
架构师决策清单：
- MVP 阶段：可以直接调用模型 API，但要预留网关抽象层
- 1→10 阶段：必须引入 AI 网关（LiteLLM/Portkey），开始成本管控
- 10→N 阶段：自定义网关，深度集成业务逻辑和合规要求
第 3 层：数据能力层
这一层负责数据的存储、检索和处理。传统应用里，MySQL/PostgreSQL 做业务数据，Redis 做缓存，ES 做搜索。大家都很熟了。
首先，如果AI产品用到传统数据，那还是要求企业做好数据治理，如数据的分层、数仓、数据湖等，这是不可逃避的。欠债要还。
其次， AI 应用极大加强了两个方向：向量数据库 + 上下文工程。
AI vs 传统：数据层的范式转变
| 维度 | 传统应用 | AI 应用 |
|---|---|---|
| 查询方式 | 精确匹配（SQL/ES） | 语义相似（向量检索）+ 精确匹配（混合）+联网检索 |
| 数据结构 | 结构化字段 | 非结构化文本 + 向量嵌入 + 元数据 |
| 返回结果 | 格式化完整内容 | LLM统筹后的自然语言/LLM 格式化输出。 |
| 索引目标 | 快速定位 | 语义相关性 + 召回率 + 对象化 |
| 新增组件 | - | 向量库、Embedding 模型、重排序模型 |
AI 特有的挑战：上下文窗口是"稀缺资源"
上下文是很多大模型及AI应用的"命门"。和传统应用不同，大模型没有内置记忆——每次调用都是独立的，它只能通过上下文窗口里的内容来"理解"我们。所以我们必须：
- 每次输入都带上历史信息，但不能带上所有历史（窗口有限）
- 上下文窗口有限（目前典型的为 128K~1M tokens），反复输入不仅增加成本，还带来噪音，分散注意力，易产生幻觉
- 为了解决这些问题：需要存储策略、删除策略、压缩策略...
- 不仅使用自己的模型，还使用各种平台（如 OpenRouter、Claude），有些厂商做了分级缓存，但要注意模型切换对效果的影响
- 有些组件（如网关）的引入，以及模型对接的方式，可能带来上下文处理方式、处理深度的巨大差别
所有这些都是"上下文工程"要关注的事情——它不是简单的"检索"，而是所有跟上下文管理有关的事情，包括：
[存储] → [召回] → [精排] → [压缩] → [组织] → [送入模型]
↑
[缓存]（贯穿全程）详见第 09-10 讲（RAG 全链路：分块、索引与检索优化）。
架构师决策清单：
- 传统数据治理的债要还：如果 AI 产品用到业务库（MySQL/数仓），数据分层、质量、血缘这些传统问题不会因为加了 AI 就消失。数据湖/数仓建设是前置条件，不可跳过。
- **什么时候用向量检索：**很多场景不需要用检索，如简单工作流。很多检索用关键词搜索（ES/BM25）或者数据库就够了，比如精确匹配订单号、用户名、政策条款编号。向量检索的收益在"语义模糊匹配"时才体现——用户说"怎么退款"≠文档标题叫"退款流程"，常见在RAG相关场景。
- 上下文质量 > 数量，宁缺毋滥：塞入大量无关片段会稀释注意力、增加幻觉概率。优先保证召回的 Top-3~5 是高相关的，而不是凑满窗口。
第 2 层：基础设施层
这一层提供系统的计算和存储底座。在传统应用中，我们已经很熟了：ECS、Docker、K8s、对象存储。
AI 应用在这层的挑战完全不同——从"确定性算力"到"概率性算力"的跃迁。
推理运行时：基础设施层中的特殊关注点 （纯Token调用不涉及，可跳过）
如果我们选择自部署模型，基础设施层中还有一个容易被忽略的子层——推理运行时：
| 组件 | 作用 |
|---|---|
| 推理引擎 | vLLM / TGI / TensorRT-LLM / llama.cpp，负责模型加载、推理加速 |
| GPU 调度器 | 管理 GPU 显存分配、动态批处理（Dynamic Batching） |
| KV Cache 管理 | 优化多轮对话的上下文缓存，减少重复计算 |
| 模型仓库 | HuggingFace / 私有 S3，管理模型版本和权重文件 |
L4（模型能力层）决定"调哪个模型"，推理运行时负责"把这个模型跑起来并返回结果"。如果是纯调用商业 API（如 GPT-4），这一层可以退化或省略。详见第 18 讲（容器编排与可观测性）。
AI vs 传统：基础设施的本质差异
| 维度 | 传统应用 | AI 应用 |
|---|---|---|
| 算力特性 | CPU 为主，计算结果确定 | GPU/TPU 为主，推理有延迟波动 |
| 弹性策略 | 秒级扩缩容，无状态服务 | GPU 冷启动几分钟，需要预热池 |
| 成本模型 | 按实例时长付费（相对固定） | 按 Token/GPU 小时付费（波动巨大） |
| 资源瓶颈 | IO/CPU/内存 | GPU 显存、模型加载时间、Token 限额 |
| 可观测性 | QPS、延迟、错误率 | Token 消耗、推理延迟分布、模型质量指标 |
三种部署模式的架构差异
模式一：纯 API 调用（最常见）
我们的服务器 → LLM API（OpenAI/Anthropic/DeepSeek）- 基础设施需求：普通 CPU 服务器即可
- 核心关注点：API 限流、重试策略、多模型路由
- 优势：零运维、按需付费、快速上线
- 劣势：依赖第三方（模型商宕机 = 我们的服务宕机）、数据出境风险、长期成本高（月用量 1M Token 时，API 费用可达自部署的 2-3 倍）
模式二：自部署开源模型
我们的服务器 + GPU → vLLM/Ollama → 本地模型- 基础设施需求：GPU 实例（A10/A100/H100）、大显存
- 核心关注点：GPU 利用率、模型加载速度、并发控制
- 优势：数据可控、成本可预测、定制化能力强
- 劣势：运维复杂度高（需专人维护 GPU 集群和推理引擎）、初期投入大（A100 GPU 实例月费数万元）、弹性困难（GPU 冷启动需几分钟）
模式三：混合架构（生产环境推荐）
我们的服务器 → AI Harness（LiteLLM/Portkey）→
├─ 主力：外部 API（GPT-4o/Claude）
└─ 降级：自部署模型（Llama/Qwen）- 核心价值：兼顾质量、成本、稳定性
- 关键设计：智能路由策略、自动降级机制、统一监控
详见第 18 讲（容器编排与可观测性）和第 20 讲（云原生 AI SaaS 架构）。
架构师决策清单：
- 0→1 阶段：优先用外部 API，验证业务价值
- 1→10 阶段：引入 AI Harness 做成本优化和多模型路由
- 10→N 阶段：评估自部署 ROI，考虑混合架构
治理体系（横切所有层）
治理体系不占层号，而是横切所有层的关注点。
传统应用关注：日志、监控、告警、灰度、安全。AI 应用中这些都需要，但还不够。
AI 应用的治理体系多了几个维度：
| 治理维度 | 传统应用 | AI 应用多了什么 |
|---|---|---|
| 可观测性 | 请求量、延迟、错误率 | Token 用量、Prompt 命中率、模型响应质量 |
| SLO 管理 | 可用性、P99 延迟 | 答案准确率、幻觉率、任务完成率 |
| 版本管理 | 代码版本、配置版本 | Prompt 版本、模型版本（需要绑定） |
| 成本治理 | 服务器成本（相对固定） | Token 成本（随用量波动，需要预算和预警） |
| 安全合规 | 认证、授权、加密 | Prompt 注入防护、模型输出合规审查 |
很多 AI 项目在 MVP 阶段完全不做治理——不记 Token 用量、不监控延迟、不做 Prompt 版本管理。等上线后出问题，已经无法追溯。
一个常见教训：Token 用量记录表建了，但 call_llm() 函数没有接入写入——导致始终没有精确的 Token 消耗数据，所有成本都是估算。如果重来，第一天就应该接入，尤其是企业自用、做审计、成本敏感的，一定要提前规划。（反过来，如果是小型项目，或者用量固定且量小，就不用过度关注）。详见第 12 讲（成本管控与性能调优）。
架构自检清单
每次设计 AI 应用时，用这张表逐层自检：
| 层级 | 我们需要回答的问题 | 跳过这层的后果 |
|---|---|---|
| 接入层 | 端侧和网关怎么分？需不需要流式？前端框架怎么选型？ | 体验差或前端过度设计 |
| 服务层 | 计费模型怎么设计？额度怎么管？ | 成本与收入不匹配 |
| 应用能力 | Pipeline 还是 Agent 还是 RAG？输出怎么清洗？ | 输出不稳定，体验差 |
| 模型能力 | 选哪个模型？怎么容灾？怎么控制成本？ | 模型挂了全系统挂，成本失控 |
| 数据能力 | 需不需要向量库？上下文窗口怎么填充？ | 检索效果差，输出质量低 |
| 基础设施 | 需不需要 GPU？自部署模型的话推理运行时怎么搭？弹性伸缩策略？ | 上线后扩容手忙脚乱 |
| 治理体系 | SLO 怎么定？Prompt 怎么做版本管理？ | 出了问题没法定位，成本黑箱 |
能回答的说明想过，回答不出的就是架构盲区——不一定现在就要解决，但必须知道它的存在。
不同产品范式，七层侧重不同
不是所有 AI 应用都要把七层做满：
| 产品范式 | 重点层 | 轻/空的层 | 原因 |
|---|---|---|---|
| AI SaaS 平台 | 全层都需要，治理体系尤其重要 | 无 | 面向外部用户，全生命周期负责 |
| 本地 AI 工具 | 应用能力层 + 治理体系 | 基础设施层（几乎为空） | 100% 本地运行，没有服务器 |
| 企业内部 AI 平台 | 模型能力层 + 数据能力层 | 接入层（内部使用） | 私有化部署，数据安全第一 |
"轻部署"不等于"轻设计"。本地运行的 AI 工具没有基础设施层的复杂度，但应用能力层和治理体系反而要做得更精细——没有服务端兜底，出了问题就是直接崩溃。
小结
这一讲建立了一个七层架构思维框架，它的价值在于：
- 系统性：覆盖AI应用的所有关键维度，避免"盲人摸象"
- 实用性：拿到任何AI项目，用这个框架快速拆解，识别风险和盲区
- 可扩展性：MVP阶段可以简化，但要预留扩展空间
- 通用性：无论是Agent系统、RAG应用、还是AI SaaS平台，都可以用这个框架分析
下一讲开始，我们进入第一个核心技术方向——Agentic Engineering，从最基础的 Agent 范式开始，逐步构建多智能体协作系统。
思考题
- 用七层检查清单过一遍我们当前在做的 AI 项目：哪些层能回答出问题？哪些层是盲区？
- 我们的 AI 应用中，哪一层复杂度最高？如果要扩展 10 倍用户量，哪一层最先遇到瓶颈？