前言
在大模型应用开发中,我们讨论了众多功能模块与范式。但在生产环境中,如何设计一个完整的、通用的、可不断优化迭代的全局视角架构至关重要。
架构图解
整个大模型应用系统通常分为三层:应用层、服务层、模型层。
- 应用层:直接接入大模型能力的具体业务应用。
- 服务层:提供核心能力的中间层。
- Core(核心应用):包含 Agent、Workflow、CoT 等原子功能。
- Scene(场景):基于原子能力搭建的定制化功能服务。
- BaaS:将能力以 API 形式开放,提供工程化支持。
- WebUI:提供界面交互,包含调试、流程搭建、评测及应用市场等功能。
- 模型层:负责数据清洗、模型训练、微调及基座模型管理。
最佳实践
1. 原子功能的界定
在功能划分上,核心功能被视为原子功能,代表它们地位对等,但不一定是物理上的不可分割。 例如,Agent 可以挂载 Workflow,Workflow 也可以包含 Agent,二者地位对等。但从应用角度看,Agent 或 Workflow 内部可能包含多个子功能,因此并非绝对原子。这里的'原子'主要指业务逻辑上的最小可用单元。
2. 对外服务的 BaaS 模式
从市场格局来看,能提供底层大模型能力的公司有限,多数企业聚焦于应用层。因此,大模型应用平台应以 BaaS(Backend as a Service)方式提供 LLM 能力和应用能力较为合理。
实际场景中,端云协同方案常采用 Agent SDK + SLM + CloudService 模式。
3. 场景层级的定位
场景功能放在服务层而非应用层,是为了降低应用接入复杂度。若仅提供 原子功能 + 流程编排,虽然保持了开放性,但会导致业务重复搭建类似流程,接入难度过高。在开放性与易用性之间保持平衡,提供相对开放的场景功能十分必要。
4. lmOps 下沉的重要性
不建议将 lmOps(大模型运维)功能集成到服务层,以防止因频繁微调导致成本失控。服务层的定位是为应用服务,而非为模型服务。若自研模型效果不佳,应直接切换更优模型,而非死磕微调。与低效模型做隔离是成本控制的关键。
5. 场景与范式的选择
两者皆需,但场景优先。如果纠结于提供通用范式还是特殊场景,建议先做场景。场景积累多了,自然能抽象出通用范式。
6. 推动架构落地的策略
大模型应用方向较新,产品经理往往缺乏分层架构概念。若团队地位较高,可强推落地;若处于执行层,建议分模块从应用侧入手,逐步沉淀,遵循结构化迭代原则(S-B-P-D)。此外,产品团队常缺乏 AI 评测指标认知,技术人员需反推产品需求,引导其理解技术亮点与价值。
7. 通用技术架构实现
针对服务层功能繁杂的问题,以下提供一个通用的技术架构参考,可根据实际情况调整:
7.1 核心组件
- API 网关:统一入口,处理鉴权、限流、路由。
- 编排引擎:负责 Workflow 的执行调度,支持状态机管理。
- 向量数据库:存储知识库嵌入,支持 RAG 检索。
- 模型注册中心:管理不同版本模型的元数据与路由策略。
- 监控告警系统:追踪 Token 消耗、延迟、错误率等关键指标。
7.2 扩展能力
- 安全过滤层:输入输出内容审核,防止敏感信息泄露。
- 缓存机制:对高频 Prompt 结果进行缓存,降低推理成本。
- 多模态支持:集成图像、语音处理能力,丰富应用场景。
7.3 部署建议
建议采用微服务架构,各组件独立部署,便于弹性伸缩。模型推理服务可单独集群管理,利用 GPU 资源池化技术提升利用率。
总结
大模型应用架构设计需要兼顾灵活性、成本与稳定性。通过清晰的层级划分、合理的原子功能定义以及工程化的 BaaS 支持,可以有效支撑复杂业务场景的快速迭代。技术团队应主动引导产品方向,注重评测体系的建设,确保技术投入转化为实际业务价值。
未来,随着端侧模型能力的增强,混合云架构将成为主流,开发者需持续关注 SLM(小语言模型)与云端大模型的协同优化。


