33 · AI 基础设施技术栈选型
一句话点题:AI 基础设施选型不是把热门工具全接一遍,而是先看清你的稀缺资源是什么:模型能力、GPU、上下文、检索质量、成本,还是可控性。选型的核心不是工具名,而是用最少组件把 AI 系统的风险关进笼子里。
🧰 技术栈选型篇第 7 章 · 本章只练一件事
17 章 讲 AI 系统多了非确定性、上下文、Agentic 三个硬骨头;22 章 讲 AI 原生系统怎么设计。本章专门回答:这些系统背后的 AI 技术栈该怎么选,什么时候托管 API 就够,什么时候才值得下沉到模型网关、自建推理、GPU、评测平台。
开场:你到底在自建什么
一听 AI Infrastructure(AI 基础设施),很多人脑子里马上冒出:
- GPU(图形处理器,训练/推理常用计算资源)
- 向量数据库
- Agent 框架
- 模型网关
- 推理引擎
- 评测平台
但架构判断的第一步不是列清单,而是问:
你是真的在建基础设施,还是只是在做一个 AI 应用?
如果你只是做早期产品,MVP 阶段最合理的默认答案通常是:调用托管模型 API,加最小日志和成本监控,先把业务闭环跑通。只有当你遇到明确触发信号,比如成本失控、数据不能出域、延迟不达标、供应商单点不可接受、模型需要深度定制,才值得往下沉到网关、自建推理、GPU 池这些重型组件。
**架构智慧:**AI 基础设施不是越底层越高级。越底层,你拿回的控制权越多,同时也接走了成本、容量规划、故障恢复、安全隔离和团队运维能力的账单。
一、AI 栈的四层
一套生产级 AI 系统,可以先粗略拆成四层:
入口治理层:
AI Gateway(模型网关) / 鉴权 / 限流 / 成本记录 / 模型路由
上下文层:
RAG(检索增强生成) / 向量库 / 文档权限 / 重排 / 引用
推理层:
Inference Serving(推理服务) / GPU / KV Cache(生成中间状态缓存) / 批处理
守门层:
Observability(可观测性) / Eval(评测) / Trace(调用链追踪) / 人工审批这四层不是一开始都要有。正确顺序是:先把不可省的风险看见,再补对应的层。
- 看不见成本,先补网关或用量日志。
- 检索质量决定答案上限,先补 RAG eval。
- 多个团队都在调模型,再补统一模型网关。
- GPU 成本超过 API 成本,再考虑自建推理。
- Agent 能执行副作用,必须补权限、人审和审计。
二、API 还是自建推理:这是成本账,不是面子账
| 方式 | 优势 | 代价 |
|---|---|---|
| 托管模型 API | 快、稳定、少运维、模型更新快 | 供应商锁定、数据路径受限、规模上来后单位成本可能贵 |
| 自建推理服务 | 控制模型、数据、成本结构和部署环境 | 要管理 GPU、显存、批处理、扩缩容、故障、容量 |
| 混合路由 | 简单任务走便宜模型,复杂任务走强模型 | 路由策略、评测、回退和成本核算更复杂 |
这个分叉不要问「哪个更先进」,要问四个问题:
- 数据能不能出域?
- 延迟目标托管 API 能不能满足?
- 调用量大到自建更便宜了吗?
- 团队会不会运营 GPU 服务?
四个问题里只中一个,通常还不足以上自建;同时命中两三个,才说明基础设施下沉有意义。
三、RAG、长上下文、微调:先分清你在补知识还是补行为
RAG、Long Context(长上下文)、Fine-tuning(微调)经常被混着比较,但它们解决的不是同一个问题:
| 路线 | 解决什么 | 适合 |
|---|---|---|
| RAG | 回答时检索外部知识 | 资料多、常更新、要引用来源、要权限过滤 |
| 长上下文 | 一次塞入大量材料 | 材料不多、临时任务、上下文放得下 |
| 微调 | 改变稳定行为、风格、格式 | 输出格式固定、领域风格稳定、样本质量高 |
小白最容易犯的错是:检索没做好就怪模型笨,或者把本该用 RAG 解决的「知识更新」问题拿去微调。
**判断句:**知识用检索,行为才谈微调。要引用、要更新、要权限,优先把 RAG 做对。
四、Agent 框架:先工作流,再自主
Agent 框架看起来很强,但第一个问题仍然是 22 章 的判断:
能用确定工作流解决?
├─ 能 → 工作流优先
└─ 不能 → Agent,但必须配权限、预算、人审、trace、eval如果流程固定,例如「检索订单 → 判断是否符合退款规则 → 调退款接口 → 发通知」,不要急着上自主 Agent。工作流更可预测、可测试、可审计。只有当步骤开放、工具多、任务目标需要动态规划,Agent 才开始有意义。
Agent 选型要重点看:
- 工具权限能否分级?
- 是否支持人工审批?
- 是否能记录每一步 trace?
- 是否能限制预算和最大步数?
- 是否能做上下文压缩和任务恢复?
五、守门层不是锦上添花,是生产门槛
AI 系统和传统系统最大的不同,是输出不稳定、质量会漂移。上线后只看接口成功率不够,还要看:
- prompt 和上下文是什么?
- 检索到了哪些片段?
- 模型调用成本多少?
- 工具调用有没有越权?
- 最终答案有没有引用、有没有胡编?
- 换模型或改提示后质量有没有退化?
这就是 25 章 eval 的价值。如果系统已经碰钱、碰用户数据、碰自动操作,eval 不是「以后再补」,而是架构的一部分。没有 eval,每次换模型、改提示、换检索策略,本质上都是闭眼上线。
六、AI 技术栈选型表
| 判断问题 | 起步选择 | 触发升级 | 代价提醒 |
|---|---|---|---|
| 只是验证 AI 产品吗? | 托管模型 API + 基础日志 | 多应用共用、成本看不清、供应商故障影响大 | 先别自建 GPU |
| 多模型 / 多团队调用吗? | AI Gateway | 需要统一鉴权、限流、计费、故障转移 | 网关在关键路径上,必须高可用 |
| 需要私有知识作答吗? | RAG + 简单向量检索 | 检索质量不稳、权限复杂、知识库变大 | RAG 上限是检索质量 |
| 向量规模小吗? | pgvector / 单机向量检索 | 百万级以上、过滤复杂、延迟吃紧 | 专用向量库是新运维对象 |
| 模型调用成本高吗? | 模型路由 + 缓存 + 配额 | API 成本高于自建总成本、数据不能出域 | 自建推理要管理 GPU 和显存 |
| 需要自动行动吗? | 确定性 Workflow | 步骤开放、必须动态规划 | Agent 要配权限、预算、人审 |
| 要稳定迭代吗? | Trace + 小 eval 集 | 生产级、碰钱、换模型频繁 | 没有评测就没有可靠升级 |
🎯 随堂检验
- A直接买 GPU 自建推理集群,顺便上分布式向量库和多 Agent 平台
- B先调用托管模型 API,加基础日志/成本记录,用最少组件验证业务闭环
- C先微调一个模型,否则不算 AI 基础设施
- ARAG,因为它让模型在回答时检索最新资料,并能指回来源
- B微调,因为所有知识都应该训练进模型
- C只扩大上下文窗口,把所有资料每次都塞进去
本章小结
- AI 基础设施选型先看稀缺资源:模型能力、GPU、上下文、检索质量、成本、可控性,哪一个最紧,就先围绕它设计。
- 默认从托管 API 起步:除非数据、成本、延迟、定制化或可用性触发升级,否则不要一开始自建推理。
- 四层拆解更清楚:入口治理、上下文、推理、守门。缺什么补什么,不要一次性全上。
- 知识用 RAG,行为才谈微调:别把检索问题误判成模型问题。
- 生产级 AI 必须有守门层:trace 看得见链路,eval 守得住质量。
承上启下:到这里,技术栈的主要拼图都看过了:语言、数据、中间层、API、部署、观测、AI 基础设施。最后一章 34 · 技术选型决策树,把它们收成一棵能照着走的判断树。
相关链接
- AI 方法论:17 · 大模型时代的架构判断 · 22 · AI 原生系统设计 · 25 · 评测驱动
- 模板对照:AI 网关 · 模型推理服务 · RAG 知识库 · 向量数据库
- 案例对照:DocuMind · CodePilot
💬 评论