Day 60 / 共 68 天 · 阶段 11 部署
云上部署概览:Bedrock / Vertex / SageMaker 全景
这几天你学会了打包(Docker)、编排(K8s)、自动化交付(CI/CD)。今天抬头俯瞰:这一切最终跑在哪片云上?各大云厂商都推出了「托管的大模型/机器学习平台」,帮你省去买卡、部署、运维大模型的重活。今天做一次全景扫描:AWS Bedrock、GCP Vertex AI、Azure ML、AWS SageMaker 各自定位、怎么选型,让你面试聊到「上云」时心里有张地图。学完阶段 11 的部署基础就通了;明天(Day 61)收官这个阶段,讲 AI 网关——所有请求进云之前的那道统一大门。
📍 你在阶段 11(部署 D57-61)的位置
D57 Docker→
D58 K8s 基础→
D59 CI/CD&IaC→
D60 云上部署→
D61 AI 网关
💡 用一个类比兜住今天(今天全程沿用「开店选铺位」的世界观)
把 Agent 部到云上 = 给你的店选个经营场地。自己买服务器+部大模型 = 自己盖楼开店(投入大、全权掌控、也全责自扛);托管平台(Bedrock/Vertex 等) = 进大商场租铺位(水电、保安、客流都由商场搞定,你专心经营);调 API 用现成模型 = 商场里现成的中央厨房(直接下单出餐,不用自己养厨师);SageMaker 自托管/微调 = 商场给你一间可自由装修的大厨房(能上自己的秘制配方,但要自己管更多)。今天你学的是「怎么给店选到最合适的铺位」。
L01
为什么用云托管:别自己养大模型
🤔 痛点想在生产里用大模型,自己买 GPU 服务器、部署开源模型、调优、保证不宕机?一张高端显卡卡贵得吓人,运维更是无底洞。绝大多数团队根本负担不起、也没必要。
💡 本质云托管平台把「大模型 + 底层算力 + 运维」打包成服务,你按用量付费,像用水用电一样即开即用。省掉了买卡、装模型、扩缩容、保高可用这些重活。就像开店进商场:你不用自建供电和安保,专心卖你的东西。对转行者:你几乎永远是「用托管平台」,而不是「自己养模型」——这点想清楚,选型就不慌。
图注:越往右越「全权掌控」,代价是越操心越花钱。绝大多数场景,①② 足矣。
👶 那 Day11 学的「直接调 OpenAI/Claude API」算哪种?算最左边的①,最轻量。「云平台(Bedrock/Vertex 等)」是在它之上多给了企业级能力:多个模型统一接入、数据不出你的云(合规)、和云上其他服务(数据库/权限)打通、支持微调和自托管。小项目直接调 API 就够;公司级、要合规和私网的,才上托管平台。
L02
AWS Bedrock:亚马逊云的「模型超市」
🤔 痛点公司数据和系统都在 AWS 上,想用大模型又不想把数据发到外部 API,还想在一个地方挑不同厂商的模型试。
💡 本质Bedrock 是 AWS 的托管大模型服务:一个统一入口,能调用多家厂商的多个基础模型(如 Anthropic Claude、Meta Llama、Amazon 自家等),数据留在你的 AWS 环境里,还和 AWS 的权限、监控体系打通。像商场里的「模型超市」——货架上摆着不同品牌,你用统一的购物车(API)挑选,收银(计费)和安保(权限)都归商场统一管。
# 用 AWS SDK(boto3) 调 Bedrock 上的模型(示意,参数以官方文档为准)
import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
# 通过 Bedrock 统一入口调某个模型,请求体格式随所选模型而定
resp = client.invoke_model(
modelId="anthropic.claude-3-5-sonnet", # 在货架上挑一个模型
body='{"messages":[{"role":"user","content":"你好"}], "max_tokens":200}'
)
# 好处:换成别家模型只需改 modelId,鉴权/网络/计费都走 AWS,数据不出自己的云
📝 举个例子:Bedrock 最打动人的一点
一家银行要做客服 Agent,监管要求「客户数据不得离开自有云环境」。用外部 API 不合规;用 Bedrock,数据在自己的 AWS 里流转、模型就近调用,既满足合规又能用上顶级模型。「合规 + 多模型统一接入 + 与现有 AWS 打通」就是 Bedrock 的核心卖点。
这里的 modelId、body 格式都会随版本和所选模型变,别背。记住定位:AWS 生态里的「多模型托管超市」,一个入口挑多家模型、数据留在自家云。
L03
GCP Vertex AI:谷歌云的一站式 AI 平台
🤔 痛点公司在用谷歌云(GCP),想用 Gemini 这类模型,还想把「数据处理→训练/微调→部署→监控」放在一个平台里管,而不是东拼西凑。
💡 本质Vertex AI 是 GCP 的一站式机器学习/AI 平台:既能直接调 Google 的 Gemini 等模型,也提供从数据、训练、微调到部署、监控的整套工具链。定位类似「谷歌云里的 AI 全能商场」——从进货(数据)到出餐(部署)一条龙都在一个屋檐下,尤其和 GCP 其它服务(BigQuery 等)咬合紧密。
👶 Bedrock 和 Vertex 到底怎么区分?粗记:Bedrock 更聚焦「多家模型的统一托管入口」;Vertex 是「谷歌云的整套 AI 平台」,模型以自家 Gemini 为主,同时覆盖更全的 ML 生命周期。但最实际的选择因素往往不是功能细节,而是「你公司本来用哪朵云」——在 AWS 就用 Bedrock,在 GCP 就用 Vertex,跨云迁移成本很高。选云平台常常是「跟着公司现有基建走」。
📝 举个例子:跟着数据走
一家公司的用户行为数据几十 TB 全在 GCP 的 BigQuery 里。做 RAG/分析型 Agent 时,用 Vertex 能就近读数据、少搬运、少花跨云流量费。「模型离数据近」往往比「模型本身强一点」更省钱省事——这是选型的隐藏重点。
L04
Azure 与其他:跟着公司的云走
🤔 痛点除了 AWS、GCP,还有微软 Azure,以及国内的云。面试被问到「你会选哪个」,总不能只知道两家。
💡 本质三大国际云各有对应的 AI 平台,能力大体对齐(都能托管模型、微调、部署、监控),真正的差别在生态和「你公司在哪」。就像不同商场设施差不多,选哪个主要看「你家离哪个近、你的货源在哪」。
| 云厂商 | AI 平台 | 一句话定位 |
|---|---|---|
| AWS | Bedrock / SageMaker | 多模型托管超市 / 自托管训练部署 |
| GCP | Vertex AI | 谷歌云一站式 AI 平台,自家 Gemini |
| Microsoft Azure | Azure AI / Azure OpenAI | 企业市场强,与微软生态(Office/AD)紧密 |
| 国内云 | 阿里/腾讯/火山等各自平台 | 国内合规、接国产模型(通义/文心/DeepSeek 等) |
👶 小白:面试官问「你会选哪个云平台部署 Agent」,标准答案是啥?
👨🏫 老师:没有绝对标准答案,但有一个让面试官点头的思路:「先看约束,再看功能」。你可以这么答:「首先跟公司现有云走,数据和系统在哪朵云,就优先用那朵云的 AI 平台,避免跨云搬数据的成本和延迟;其次看合规要求(数据能不能出境/出云);再看要不要微调、多模型路由等具体能力;小项目其实直接调 API 最快。」——这个「约束优先、跟着现有基建走」的框架,比背某个平台的功能列表值钱得多。
L05
AWS SageMaker:想自己训练/微调时的大厨房
🤔 痛点现成模型不够用——你想用自家独有数据微调一个模型、或部署一个开源模型自己托管。这时候前面那些「现成模型超市」就不够了。
💡 本质SageMaker 是 AWS 更偏「自己动手」的机器学习平台:提供训练、微调、部署自定义/开源模型的完整工具和算力,掌控力更强,但要懂的也更多。如果说 Bedrock 是「点现成菜的中央厨房」,SageMaker 就是「给你一间配齐设备、能上自家秘方的大厨房」——能做更多,也要你自己多操心(选机器、管训练、控成本)。
图注:转行初期基本用不到 SageMaker——知道「它是给要自训/自托管模型的场景用的」即可,别被它劝退。
👶 转行者需要学会 SageMaker 吗?不需要深学。绝大多数 Agent 岗位的工作是「用好现成模型 + 做 RAG/工具/编排/评测」,几乎不碰自己训模型。你只要能说清「SageMaker 是给需要自训练/微调/自托管模型的场景用的,比 Bedrock 灵活但更重」,就足够应对面试。把精力放在你真正的主战场(RAG、Agent、评测、工程化)上。
L06
选型对照表:一张图决定用哪个
🤔 痛点平台一堆,真到项目里,到底该按什么顺序做决定?
💡 本质把选型压成一条决策链,从简到繁、从约束到功能,照着走就不乱:能调 API 解决就别上重平台 → 有合规/多模型/私网需求上托管平台(跟着公司现有云选) → 非要自训/自托管才动 SageMaker 这类。
图注:绝大多数转行者的项目,停在前两层就够了。越往下越重,别为了显得高级而过度设计。
📝 举个例子:三个场景怎么选
① 个人作品集里的知识库问答:直接调 API + 自己 Docker 部一个小服务,零负担。
② 公司(在 AWS)做内部合规客服:Bedrock,数据不出云 + 多模型可选。
③ 有独家标注数据、要微调专属模型:SageMaker / Vertex 的训练能力。
「先看约束再看功能、能简单就别复杂」——把这句讲给面试官,胜过背一堆产品名。
② 公司(在 AWS)做内部合规客服:Bedrock,数据不出云 + 多模型可选。
③ 有独家标注数据、要微调专属模型:SageMaker / Vertex 的训练能力。
「先看约束再看功能、能简单就别复杂」——把这句讲给面试官,胜过背一堆产品名。
L07
今日小结 + 动手 10 分钟
🧠 今天你应该能回答
- 为什么大多数团队用云托管而不自己养大模型?
- 「直接调 API / 托管平台 / 自托管」三种方式各适合什么场景?
- Bedrock 的核心卖点是什么?(多模型统一入口 + 合规 + 与 AWS 打通)
- Vertex AI 的定位?为什么选云平台常常「跟着公司现有云走」?
- SageMaker 和 Bedrock 的区别?转行者需要深学 SageMaker 吗?
- 部署选型的决策链是怎样的?怎么用「约束优先」回答面试?
✋ 动手 10 分钟:写一段你的「上云选型」面试答案
今天没有代码要跑——最该练的是「把选型讲清楚」。请对着下面模板,填成属于你自己的一段话,大声念两遍:
# 面试问:「如果让你把这个 Agent 部署上线,你会怎么选平台?」
# 照这个框架组织你的回答(约束优先 → 功能其次 → 别过度设计):
# 1) 先问约束:数据合规要求?公司现在用哪朵云?预算和团队规模?
# 2) 给默认方案:如果没有特殊约束,我会先用「直接调模型 API +
# 容器化(Docker)部一个 FastAPI 服务 + K8s 编排 + CI/CD 自动发布」,
# 这套最快最省,能满足绝大多数场景。
# 3) 按需升级:若要数据不出云/多模型/合规,就上对应云的托管平台
# (AWS→Bedrock,GCP→Vertex),跟着公司现有云走;
# 只有需要自训练/微调专属模型时,才用 SageMaker 这类更重的平台。
# 4) 补一句工程化:无论哪种,都会配 Day55 的可观测和 Day56 的成本治理。
能把这段话不看稿讲顺,你就把整个阶段 11(Day57~60)串成了一个完整的「部署观」——这比记住任何一个产品名都值钱。
明日预告 · Day 61:部署篇还差最后一块拼图。当你有了多个模型、多个 Agent 服务在云上跑,所有请求进来之前需要一道统一大门来做限流、鉴权、多模型路由、token 计量和缓存——这就是 AI 网关。明天用 Higress、APISIX 讲清这道「云上入口」怎么工作,给部署篇画上句号。