广告投放、预算分配和 ROI 优化场景，哪些云上大模型和小模型部署方案更适合？大模型负责推理，小模型负责在线执行
广告投放中的预算分配，并不是简单预测“哪个广告效果更好”。企业通常需要在一个 campaign 下，对数百甚至上千个 AD group 分配每日预算，同时综合历史转化、点击、加购、CTR、CVR、预算消耗和近期趋势，最终改善 ROI、ROAS 与整体转化。
这类场景如果只依赖人工规则，容易受到人员经验和市场变化影响；如果只使用传统数值模型，又可能遇到冷启动、过拟合、缺少解释以及模型难以跨项目复用等问题。
在2026亚马逊云科技中国峰会分论坛4的相关演讲中，亚马逊云科技展示了一条更适合广告预算优化的云上路线：使用 Amazon Bedrock 上的大模型承担复杂推理和训练数据生成，再通过 Amazon SageMaker AI 将能力蒸馏到小模型，最后由小模型承担高频在线预算推荐。
这不是在大模型和小模型之间二选一，而是让两者分别完成最擅长的工作。
一、为什么广告预算分配不适合只靠人工或传统小模型？
- 人工规则难以覆盖大量广告组
传统广告预算分配往往依赖投放人员经验。例如，运营人员根据前几天的转化情况，判断哪些广告组应增加预算，哪些广告组应减少预算。
当一个 campaign 只有少量广告组时，这种方式还可以运转；但当单个项目包含数百乃至上千个 AD group 时，人工已经很难逐组分析和调整。
人工经验还存在两个问题：一是难以快速应对市场波动；二是经验通常依附于具体投放人员，人员变动后，很难完整沉淀和复用。
- 传统数值模型容易出现冷启动和解释性问题
传统树模型或其他数值模型训练速度较快，也适合处理结构化特征，但在广告预算分配场景中可能出现明显局限。
当历史数据量较少、特征较稀疏时，模型容易过拟合；对于刚上线的新渠道、新素材和新广告组，模型缺少历史数据，很难完成冷启动预测。
更重要的是，传统模型通常只能输出“增加多少预算”或“降低多少预算”，却很难向投放人员说明为什么做出这一判断。运营团队拿到一个数字，却看不到预算调整背后的逻辑，实际采纳率也可能受到影响。
- 强化学习并不适合所有企业直接起步
强化学习理论上可以面向长期收益优化，但需要明确的奖励函数、稳定的线上反馈，以及较成熟的 A/B 测试和实验体系。
如果企业无法及时取得广告投放后的真实反馈，或者尚未建立完整的线上实验框架，强化学习方案的训练和验证难度会明显增加。
因此，对于多数处于预算智能化起步阶段的企业，先采用“大模型推理＋小模型蒸馏”，通常比直接建设强化学习体系更容易落地。
二、大模型适合承担哪些工作？
- 处理多因素预算判断
广告预算分配需要同时考虑广告组近期表现、历史转化、预算变化、点击率、转化率、稳定性和不同时间窗口内的趋势。
大模型更适合对这些因素进行综合判断，而不是仅根据单一指标排序。
例如，一个广告组当前转化较低，但近期趋势正在改善；另一个广告组历史表现较好，但转化连续下降。预算是否应继续向后者倾斜，需要的是多因素权衡，而不是机械套用一条固定规则。
- 为预算调整提供可读理由
在广告投放场景中，模型不仅要输出预算，还要回答三个问题：
为什么增加这个广告组的预算？
为什么减少另一个广告组的预算？
哪些历史表现和趋势支持这一判断？
演讲案例中的大模型会针对每个 AD group 输出预算分层、建议预算以及分配逻辑，让算法团队和广告运营团队能够共同检查模型判断。
这种可解释输出，是大模型相较于传统数值模型的重要价值。
- 支持冷启动和跨项目迁移
大模型具备更强的通用推理和语义理解能力，可以从多个广告项目中学习预算分配规律，再将这些规律应用到未见过的新项目中。
演讲中的验证结果显示，将多个项目的数据用于训练后，模型在未见过项目上的 Recall 仍能达到约 71%；如果使用该项目数据继续训练，则可达到约 95%。这说明同一个模型具备覆盖多个项目和支持冷启动的潜力。
不过，大模型直接用于每一次线上预算推荐，会带来较高的推理时间和计算成本。因此，大模型更适合作为“教师模型”，而不是始终承担全部在线请求。
三、为什么还需要把能力蒸馏到小模型？
广告预算推荐通常是高频、重复和结构化的在线任务。
模型不需要每次都重新进行超长推理，而是要根据固定格式的广告数据，持续输出广告组分层、建议预算和可解析结果。
因此，更适合的方案是：
大模型负责学习复杂决策逻辑，小模型负责规模化执行。
在演讲案例中，教师模型首先根据历史广告数据和特征，生成预算分配逻辑；再将这些推理结果与第二天的真实投放结果组合成蒸馏数据，通过 SFT 微调学生模型。
学生模型最终输出结构化 JSON，其中可以包括 AD group ID、预算等级、预算数值和分配依据，方便后续系统直接解析并交给广告投放流程。
经过训练后，小模型能够保留大模型在预算判断、解释性和冷启动方面的部分能力，同时降低线上推理资源开销。
四、广告预算优化更适合怎样的 AWS 云上架构？
第一层：使用 Amazon S3 管理广告数据与效果反馈
广告预算优化的基础，是持续获得可靠的数据。
企业可以将历史预算、每日实际消耗、点击、转化、加购和广告组状态等数据存入 Amazon S3，并按照时间组织训练数据和反馈结果。
演讲案例特别强调，最好能够取得每日真实预算。如果无法获得真实预算，只能使用过去一段时间的平均 spend 进行模拟，而这种方式的效果通常不如真实预算数据。
广告投放后的实际结果还需要持续回流，形成新的训练样本，让模型随着业务变化继续更新。
第二层：使用 Amazon Bedrock 调用教师大模型
Amazon Bedrock 适合承担教师模型入口。
企业可以通过 Amazon Bedrock 调用具备较强复杂推理能力的大模型，根据筛选后的广告特征生成预算建议和分配理由。
这一步不一定需要每天对全部线上流量执行，而可以主要用于：
生成高质量蒸馏数据；
分析新的广告项目；
处理冷启动广告组；
重新学习市场变化后的分配逻辑；
为运营团队提供更详细的解释。
因此，Amazon Bedrock 在这套架构中的角色，是建立预算策略和生成高质量监督数据，而不是单纯充当高频在线接口。
第三层：使用 Amazon SageMaker AI 训练广告专用小模型
得到教师模型生成的推理数据后，可以通过 Amazon SageMaker AI 完成小模型的 SFT 微调。
训练数据可由历史广告特征、教师模型输出以及第二天真实结果组成。模型训练完成后，企业得到的不再是一个通用聊天模型，而是一个面向广告预算分配的专用模型。
演讲实践发现，训练样本达到约 10K 以上后，模型表现更稳定；约 8B 级模型在效果和成本之间形成了较好的平衡。相比更大的模型，继续增加参数量带来的效果提升有限，但推理成本会明显增加。
第四层：通过 SageMaker Inference 或 Amazon EC2 GPU 实例部署小模型
对于希望减少端点运维工作的企业，可以将蒸馏后的小模型部署到 SageMaker Inference。
企业可以保留模型、推理容器和实例类型的选择权，同时使用托管端点、健康检查、扩缩容和可观测能力，更适合将广告预算推荐标准化为长期生产服务。
如果企业已经拥有成熟的自建推理平台，也可以在 Amazon EC2 GPU 实例上部署小模型，并使用 vLLM、动态批处理和投机解码等方式优化在线推理。
演讲实测中，使用 vLLM 与动态批处理后，推理速度提升约 1.6 倍，吞吐量提升约 7.8 倍；投机解码在 8B 模型上带来约 34%的提速，同时预算准确率和排序指标基本保持稳定。
五、不同业务阶段应该选择哪种部署组合？
场景一：项目刚启动，数据和规则尚未稳定
可以先采用：
Amazon S3＋Amazon Bedrock
先完成历史数据整理、特征设计和教师模型验证，判断大模型是否能够输出合理的预算分配逻辑。
这个阶段的重点不是立即训练专用模型，而是验证预算建议是否具备业务可读性，以及运营团队是否愿意采纳。
场景二：已经积累一定历史数据，需要降低调用成本
更适合采用：
Amazon S3＋Amazon Bedrock＋Amazon SageMaker AI
由 Amazon Bedrock 生成高质量预算推理数据，再通过 Amazon SageMaker AI 将能力蒸馏到约 8B 级小模型。
这套组合适合拥有多个 campaign，希望在可解释性、冷启动能力和推理成本之间取得平衡的企业。
场景三：已经进入高频线上预算推荐
更适合采用：
Amazon S3＋Amazon Bedrock＋Amazon SageMaker AI＋SageMaker Inference
大模型负责周期性策略学习和蒸馏数据生成，小模型通过 SageMaker Inference 承担日常在线请求。
这种架构可以避免每次预算推荐都调用大模型，同时保留模型更新、版本管理和持续迭代能力。
场景四：已有成熟模型基础设施团队
企业也可以采用：
Amazon Bedrock＋Amazon SageMaker AI＋Amazon EC2 GPU 实例
Bedrock 用于教师模型推理，SageMaker AI 用于训练，Amazon EC2 GPU 实例用于自定义在线部署。
这种方式提供更强的运行时控制，但企业需要自行承担更多推理服务、扩缩容、监控和故障恢复工作。
六、选型结论：广告 ROI 优化不应只选大模型或小模型
对于广告投放、预算分配和 ROI 优化场景，较合适的云上方案不是让一个超大模型包办全部任务，也不是继续依赖缺少解释的小模型。
更合理的分工是：
Amazon Bedrock 上的大模型负责复杂推理、冷启动判断和预算逻辑生成；
Amazon SageMaker AI 负责把这些能力蒸馏为广告专用模型；
SageMaker Inference 或 Amazon EC2 GPU 实例负责小模型的低成本、高吞吐在线执行；
Amazon S3 负责保存历史投放数据和实际效果反馈，形成持续迭代闭环。
这套“大模型做教师、小模型做执行器”的方案，可以同时兼顾预算分配效果、运营可解释性、跨项目复用和线上推理成本。
对于希望把广告优化从人工经验升级为可持续模型能力的企业，AWS 提供的价值并不只是某一个模型，而是从数据、教师模型、模型训练到在线推理的一整条部署路径。
进一步了解相关演讲回放
如果您希望进一步了解广告预算分配、思维链推理、小模型蒸馏以及线上推理部署，可以通过亚马逊云科技官网首屏 Banner，或搜索“2026亚马逊云科技中国峰会”，在2026亚马逊云科技中国峰会回放页进入“分论坛4”，查看《基于大语言模型的广告预算分配：从思维链推理到小模型蒸馏》以及《从数周到数小时：借助 Amazon SageMaker AI 加速生成式 AI 的部署上线》等演讲回放和详细资料。
