架构师视角:AI系统架构设计与大模型部署
面向嵌入式软件工程师,从系统架构师的角度理解AI。
不只是"怎么用API",而是"怎么设计一个完整的AI系统"。
涵盖:架构模式、部署策略、性能优化、边缘部署、生产实践。
一、为什么架构师需要深入理解AI架构
传统软件架构 vs AI系统架构
| 维度 | 传统软件架构 | AI系统架构 |
|---|---|---|
| 确定性 | 输入确定,输出确定 | 输入确定,输出概率性 |
| 性能瓶颈 | CPU/内存/IO | GPU/显存/模型大小 |
| 部署模式 | 二进制/容器化 | 模型权重+推理引擎 |
| 扩展方式 | 水平扩展(加节点) | 垂直扩展(更大GPU)+ 批处理 |
| 故障模式 | 崩溃/超时/内存泄漏 | 幻觉/输出质量下降/显存溢出 |
| 调试方式 | 日志/断点/性能分析器 | Prompt分析/输出评估/Token监控 |
| 版本管理 | 代码版本 | 模型版本+数据版本+Prompt版本 |
核心认知转变:
AI系统的架构不仅仅是"跑模型的服务器",而是一个包含数据流、模型流、评估流的完整生态系统。
嵌入式工程师的独特优势
作为嵌入式工程师,你在以下方面有天然优势:
| 嵌入式经验 | AI架构中的对应能力 |
|---|---|
| 内存管理(malloc/free) | KV Cache管理、激活内存优化 |
| 实时系统调度 | 推理延迟优化、批处理调度 |
| 硬件加速(DMA/NEON) | GPU/NPU上的矩阵乘法优化 |
| 功耗优化 | 量化、模型压缩、边缘部署 |
| 协议栈设计 | MCP协议、服务网格、API网关 |
二、AI系统的整体架构全景
2.1 大模型应用的四层架构
┌─────────────────────────────────────────────────────────────┐
│ 应用层 (Application) │
│ Chatbot / Agent / 代码助手 / 数据分析 / 内容生成 │
├─────────────────────────────────────────────────────────────┤
│ 编排层 (Orchestration) │
│ RAG / Agent框架 / Prompt管理 / 工具调用 / 工作流 │
│ LangChain / LlamaIndex / MCP / AutoGen / CrewAI │
├─────────────────────────────────────────────────────────────┤
│ 模型层 (Model) │
│ GPT-4 / Claude / Llama / Qwen / DeepSeek │
│ API调用 / 本地部署 / 混合部署 │
├─────────────────────────────────────────────────────────────┤
│ 基础设施层 (Infrastructure) │
│ GPU集群 / 推理引擎(vLLM/TensorRT-LLM/llama.cpp) / 向量数据库 │
└─────────────────────────────────────────────────────────────┘
2.2 各层核心组件
应用层
- Chatbot:对话式交互,最常见
- Agent:能调用工具、执行任务的AI
- Copilot:辅助编程/写作的AI助手
- 嵌入式AI:在边缘设备上运行的本地AI
编排层(架构师最需要关注的层)
- RAG (检索增强生成):让模型基于你的知识库回答
- Agent框架:让AI能自主规划和执行任务
- Prompt管理:版本化、A/B测试、优化
- 工作流引擎:多步骤AI任务的编排
模型层
- API模型:OpenAI、Claude、Gemini等
- 开源模型:Llama、Qwen、DeepSeek等
- 小模型:Phi-3、Qwen-1.8B等适合边缘部署
基础设施层
- 推理引擎:vLLM、TensorRT-LLM、llama.cpp、SGLang
- 向量数据库:Milvus、Chroma、Pinecone、Qdrant
- GPU管理:Kubernetes + GPU插件、NVIDIA Triton
三、核心架构模式
3.1 RAG架构(检索增强生成)
核心思想:先检索相关知识,再让模型基于知识回答。
用户问题
│
▼
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ 问题向量化 │───>│ 向量检索 │───>│ 相关文档 │
│ (Embedding)│ │ (Vector DB) │ │ (Top-K) │
└─────────────┘ └──────────────┘ └──────┬──────┘
│
▼
┌─────────────────────┐
│ 组合Prompt │
│ "基于以下资料回答..." │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ LLM生成回答 │
└─────────────────────┘
架构决策点:
| 决策点 | 选项 | 适用场景 |
|---|---|---|
| 向量化模型 | OpenAI embedding / BGE / M3E | 中文选BGE/M3E,英文选OpenAI |
| 向量数据库 | Chroma / Milvus / Qdrant | 小规模用Chroma,大规模用Milvus |
| 分块策略 | 固定长度 / 语义分块 / 递归分块 | 技术文档用语义分块 |
| 检索策略 | 向量检索 / 关键词检索 / 混合检索 | 混合检索效果最好 |
| 重排序 | 不用 / Cross-Encoder / LLM重排 | 精度要求高用LLM重排 |
嵌入式场景的RAG:
- 本地向量数据库(SQLite + 轻量embedding模型)
- 量化后的本地LLM(llama.cpp + Qwen-1.8B INT4)
- 适合:离线知识库查询、设备诊断辅助
3.2 Agent架构
核心思想:AI不仅能回答,还能调用工具、执行任务、自我反思。
五种Agent架构模式:
| 模式 | 描述 | 适用场景 | 复杂度 |
|---|---|---|---|
| ReAct | 思考→行动→观察→思考循环 | 简单工具调用 | 低 |
| Plan-and-Execute | 先规划计划,再逐步执行 | 复杂多步骤任务 | 中 |
| Reflection | 生成→反思→改进循环 | 高质量内容生成 | 中 |
| Multi-Agent | 多个Agent协作,各司其职 | 复杂系统(如客服+技术+销售) | 高 |
| Hierarchical | 主管Agent分配任务给子Agent | 企业级应用 | 高 |
嵌入式Agent场景:
- 设备自主诊断Agent:收集传感器数据→分析→生成诊断报告→建议维修方案
- 产线监控Agent:实时数据流→异常检测→根因分析→通知工程师
3.3 MCP架构(Model Context Protocol)
核心思想:标准化的AI工具调用协议,让AI能安全地访问外部数据源。
AI应用 (Host)
│
│ MCP协议 (JSON-RPC over stdio/HTTP)
│
▼
┌─────────────────────────────────────────┐
│ MCP Servers │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ 数据库 │ │ 文件系统 │ │ API服务 │ │
│ │ Server │ │ Server │ │ Server │ │
│ └─────────┘ └─────────┘ └──────────┘ │
└─────────────────────────────────────────┘
为什么架构师要关注MCP:
- 标准化:不再为每个AI应用定制工具接口
- 安全性:明确的权限边界和审计日志
- 可组合:像乐高一样组合不同的数据源
四、推理服务架构
4.1 推理引擎对比
| 引擎 | 语言 | 适用场景 | 特点 |
|---|---|---|---|
| vLLM | Python | GPU服务器,高吞吐 | PagedAttention,批处理强 |
| TensorRT-LLM | C++/Python | NVIDIA GPU极致优化 | 性能最强,但只支持NVIDIA |
| llama.cpp | C++ | CPU/边缘设备 | 纯CPU运行,量化支持好 |
| SGLang | Python | 复杂生成任务 | 结构输出控制强 |
| Ollama | Go/CLI | 本地开发/测试 | 开箱即用,一键运行 |
嵌入式推荐:llama.cpp(纯C++,可交叉编译到ARM)
4.2 推理优化技术全景
┌──────────────────────────────────────────────────────────────┐
│ 推理优化技术栈 │
├──────────────┬──────────────────┬────────────────────────────┤
│ 模型层 │ 系统层 │ 调度层 │
├──────────────┼──────────────────┼────────────────────────────┤
│ • 量化 │ • KV Cache │ • 连续批处理 │
│ INT8/INT4 │ 缓存注意力KV │ 动态合并请求 │
│ • 剪枝 │ • PagedAttention │ • speculative decoding │
│ 移除冗余 │ 分页管理显存 │ 猜测式解码 │
│ • 蒸馏 │ • FlashAttention │ • 动态批大小 │
│ 大模型教小 │ 加速注意力计算 │ 根据负载调整 │
│ • MoE │ • 算子融合 │ • 多GPU并行 │
│ 专家混合 │ 合并计算步骤 │ 张量/流水线并行 │
└──────────────┴──────────────────┴────────────────────────────┘
关键技术详解:
| 技术 | 原理 | 嵌入式类比 | 效果 |
|---|---|---|---|
| 量化(INT4) | FP32权重压缩到4bit | 浮点转定点 | 模型大小减少8倍,速度提升2-3倍 |
| KV Cache | 缓存已计算的Key/Value | DMA缓存命中 | 生成速度提升2-5倍 |
| PagedAttention | 显存分页管理,避免碎片 | 虚拟内存管理 | 吞吐量提升2-4倍 |
| 连续批处理 | 动态合并不同长度的请求 | 动态任务调度 | GPU利用率提升3-5倍 |
| FlashAttention | IO感知的注意力算法 | 缓存友好的矩阵计算 | 注意力计算加速3-5倍 |
4.3 部署架构选型
场景1:云端API调用(最简单)
你的应用 ──HTTPS──> OpenAI/Claude/Gemini API
- 优点:零运维,模型最强
- 缺点:延迟高,成本高,数据外发
场景2:云端自部署(中等复杂度)
你的应用 ──内网──> vLLM集群 ──GPU──> Llama/Qwen模型
- 优点:数据不出域,可控性强
- 缺点:需要GPU服务器,运维成本高
场景3:边缘部署(嵌入式场景)
你的应用 ──本地──> llama.cpp ──CPU/NPU──> Qwen-1.8B INT4
- 优点:零延迟,离线可用,数据不出设备
- 缺点:模型能力有限,需要量化
场景4:混合部署(推荐)
简单任务 ──> 边缘小模型 (llama.cpp + Qwen-1.8B)
复杂任务 ──> 云端大模型 (API 或 vLLM集群)
- 优点:兼顾延迟和能力,成本最优
- 缺点:路由逻辑复杂
五、架构设计决策框架
5.1 模型选择决策树
需要中文能力?
├── 是 → 需要离线部署?
│ ├── 是 → 设备有GPU?
│ │ ├── 是 → TensorRT-LLM + Qwen-7B INT8
│ │ └── 否 → llama.cpp + Qwen-1.8B INT4
│ └── 否 → API调用:通义千问 / DeepSeek
└── 否 → 需要最强推理能力?
├── 是 → OpenAI o1 / Claude 4 Opus
└── 否 → GPT-4o mini / Claude Haiku(性价比高)
5.2 架构选型评估矩阵
| 需求 | API方案 | 自部署方案 | 边缘方案 |
|---|---|---|---|
| 开发速度 | ★★★★★ | ★★☆☆☆ | ★★★☆☆ |
| 运维成本 | ★★★★★ | ★★☆☆☆ | ★★★☆☆ |
| 模型能力 | ★★★★★ | ★★★★☆ | ★★☆☆☆ |
| 数据隐私 | ★☆☆☆☆ | ★★★★★ | ★★★★★ |
| 延迟 | ★★☆☆☆ | ★★★★☆ | ★★★★★ |
| 成本(长期) | ★★☆☆☆ | ★★★★☆ | ★★★★★ |
| 离线能力 | ☆☆☆☆☆ | ★★☆☆☆ | ★★★★★ |
5.3 容量规划公式
显存需求 = 模型参数量 × 精度字节数 + KV Cache + 激活值
例如 7B模型:
- FP16: 7B × 2bytes = 14GB
- INT8: 7B × 1byte = 7GB
- INT4: 7B × 0.5bytes = 3.5GB
加上KV Cache和激活值,实际需要约 1.5-2倍
吞吐量估算:
- vLLM + A100(80GB): 7B模型约 100-200 tokens/s
- llama.cpp + CPU: 7B INT4约 5-10 tokens/s
- llama.cpp + Apple M3: 7B INT4约 20-40 tokens/s
六、生产级AI系统架构要素
6.1 可观测性
AI系统需要特殊的监控指标:
| 指标类型 | 具体指标 | 意义 |
|---|---|---|
| 性能指标 | 首Token延迟、生成速度、吞吐量 | 用户体验直接相关 |
| 质量指标 | 幻觉率、相关性评分、安全拦截率 | 输出质量监控 |
| 成本指标 | Token消耗、API费用、GPU利用率 | 成本控制 |
| 业务指标 | 用户满意度、任务完成率、人工接管率 | 业务价值 |
6.2 安全与合规
| 风险 | 防护措施 |
|---|---|
| Prompt注入 | 输入过滤、系统Prompt加固 |
| 数据泄露 | PII检测、输出脱敏、权限控制 |
| 幻觉风险 | RAG提供依据、关键事实校验 |
| 滥用风险 | 速率限制、内容审核、使用审计 |
6.3 版本管理
AI系统需要三重版本管理:
应用版本 v1.2.0
├── 模型版本: qwen-7b-v2
├── Prompt版本: prompt-template-v3
└── 数据版本: knowledge-base-2024-05
七、嵌入式AI架构专项
7.1 边缘大模型部署架构
┌─────────────────────────────────────────────────────────┐
│ 应用层 │
│ 语音助手 / 设备诊断 / 产线监控 / 质量检测 │
├─────────────────────────────────────────────────────────┤
│ AI推理层 │
│ llama.cpp / MLC-LLM / TVM │
│ INT4量化模型 (1.5-4GB) │
├─────────────────────────────────────────────────────────┤
│ 硬件加速层 │
│ CPU (ARM Cortex-A78) / NPU / GPU (Mali) │
│ 内存: 4-8GB LPDDR5 │
├─────────────────────────────────────────────────────────┤
│ 传感器/输入层 │
│ 麦克风 / 摄像头 / 传感器数据 / 串口指令 │
└─────────────────────────────────────────────────────────┘
7.2 嵌入式部署优化清单
| 优化项 | 方法 | 预期效果 |
|---|---|---|
| 模型选择 | 选小模型(1-3B参数) | 内存占用减少70%+ |
| 量化 | INT4/INT8量化 | 模型大小减少4-8倍 |
| 算子优化 | ARM NEON指令优化 | CPU推理加速2-3倍 |
| 内存管理 | 预分配内存池 | 避免运行时分片 |
| 流式输出 | Token-by-Token输出 | 首字延迟降低50% |
| 唤醒词 | 本地唤醒词检测 | 降低无效推理 |
7.3 推荐的嵌入式AI技术栈
| 组件 | 推荐方案 | 说明 |
|---|---|---|
| 推理框架 | llama.cpp | 纯C++,ARM交叉编译友好 |
| 模型 | Qwen-1.8B / Phi-3-mini | 小模型,中文能力强 |
| 量化 | GPTQ / AWQ INT4 | 精度损失<3% |
| 向量检索 | SQLite + 轻量embedding | 离线可用 |
| 语音识别 | Sherpa-ONNX / Whisper.cpp | 本地STT |
八、架构师学习路径
第一阶段:建立架构认知(1-2周)
- 理解AI系统四层架构
- 掌握RAG、Agent、MCP三种核心架构模式
- 学习决策框架:什么时候用什么方案
第二阶段:深入推理架构(2-4周)
- 学习vLLM、llama.cpp等推理引擎原理
- 理解量化、KV Cache、PagedAttention等优化技术
- 动手部署一个开源模型
第三阶段:生产架构实践(4-8周)
- 设计一个完整的RAG系统
- 实现Agent工作流
- 建立AI系统的可观测性
第四阶段:边缘AI架构(持续)
- 学习边缘部署优化技术
- 设计混合部署架构
- 在真实嵌入式设备上运行AI
九、关键GitHub资源
| 项目 | Stars | 说明 |
|---|---|---|
| study8677/awesome-architecture | 108 | 21张AI架构图(RAG、Agent、推理服务等) |
| FareedKhan-dev/all-agentic-architectures | 3,370 | 17种Agent架构模式实现 |
| microsoft/mcp-for-beginners | 16,200 | MCP协议入门课程 |
| lastmile-ai/mcp-agent | 8,338 | 用MCP构建Agent的工作流模式 |
| Eric-LLMs/Awesome-AI-Engineering | 5 | 全栈LLM工程手册(架构+训练) |
| sunilpradhansharma/production-rag-patterns | 2 | 26种生产级RAG模式 |