当我们谈论 Meta 这类超大规模社交平台时，推荐系统的工程复杂度往往超出普通开发者的想象。表面上，用户滑动 Instagram Reels 或刷新 Facebook Feed 的流畅体验背后，是数万个服务器、数千个模型和数十亿次推理的精密协同。然而，正是在这种极限规模下，技术决策的局限性与架构挑战才真正显现出来。本文将从工程视角出发，剖析 Meta 推荐系统在容量与延迟、模型实验、数据一致性以及硬件基础设施四个维度面临的核心挑战。
一、容量与延迟的零和博弈
在 Meta 的推荐系统中，p95 和 p99 延迟 SLA 是硬性约束，每一毫秒的响应延迟都直接影响用户体验和平台参与度。研究数据显示，Facebook Marketplace 曾部署智能缓存配合轻量级调整模型，在不损害排序质量的前提下将容量削减约 50%，p75 延迟降低约 35%。这一案例揭示了推荐系统面临的根本矛盾：缓存能显著降低计算成本和延迟，但会牺牲内容的新鲜度，进而影响用户参与度。
Meta 采用多阶段漏斗架构来处理这一矛盾：检索阶段从数十亿内容中快速筛选出数千个候选，早期排序进一步缩减至数百个，后期排序进行精细打分，最后通过重排序层加入业务规则。这种级联架构的每个阶段都必须在严格的端到端延迟预算内完成，而模型却变得越来越复杂、参数量越来越大。当_embedding table_" 膨胀到无法完全装入内存时，延迟预算的压力会急剧攀升。
全球分布进一步放大了这一挑战。请求来自数十个数据中心区域、数百个边缘节点和数千个 CDN 站点，路由、故障转移和地理复制必须在保持低延迟的同时确保排序一致性。Meta 提出的 "All DCs as one computer" 理念，将放置、资源分配和故障转移自动化到全球规模，但这也意味着单个区域的网络或电力故障可能导致数万台服务器同时受影响。
二、模型实验的组合爆炸困境
Instagram 的推荐系统可能是世界上最复杂的模型生态系统之一。每个表面（Feed、Reels、Explore）都包含检索模型、早期排序、晚期排序以及持续进行的 A/B 测试，这种架构被 Meta 工程师称为 "Journey to 1000+ models"。在仅 Instagram 一个平台上，就存在数千个生产模型同时运行，每一次模型更新都需要精心规划的容量预评估、分阶段流量转移和副本回收。
这一问题的本质是组合基础设施问题，而非纯粹的建模问题。Meta 建立了模型注册表和关键性分层机制（TIER0 到 TIERR4），以便基础设施团队了解哪些推荐模型可能引发 SEV0 或 SEV1 级事件，并在发布和故障期间得到优先保护。发布一个新模型通常需要迭代式 20% 递增步骤，因为备用容量有限，估计错误可能导致代价高昂的回滚。
这种复杂性带来了隐性成本：模型间的依赖关系、特征共享冲突、实验隔离难度增加，以及跨团队协调的认知负荷。Meta 不得不在工具链上大量投入，包括模型元数据追踪、容量规划器、流量转移工具、实验平台和部署自动化，因为手动操作根本无法扩展。
三、数据一致性与分布式系统的隐性代价
推荐系统依赖于大规模、新鲜的用户行为日志和内容特征，这些数据分布在多个地理区域。缓存一致性问题是 Meta 遇到过的典型工程噩梦：用户收到被标记照片的通知，却在实际页面中看不到该照片；聊天消息到达顺序错乱。这些问题的根源是跨区域缓存的不一致。
在地理分布的故障域中，电力和网络域（如主配电柜、整个区域）可能导致数万服务器同时宕机。系统必须能够承受单个 MSB 甚至整个区域的损失，同时继续提供排序服务。这要求分片和副本策略经过精心设计，但过度冗余会显著增加成本和延迟。
持续部署的风险同样不容忽视。基础设施每天经历大量代码和配置推送，阶段式发布、金丝雀健康检查成为避免大规模服务中断的必备机制。一旦部署事故发生，直接后果就是推荐质量的下降，这比普通的系统故障更影响核心业务指标。
四、硬件基础设施的异构与效率困境
现代推荐系统使用大规模 embedding 表、深度网络，甚至日益增多的生成式模型（如 Meta 的 GEM 广告模型），这些 workloads 对计算、内存和网络都提出了极高要求。Meta 的 fleet 包含多种 GPU 和 CPU SKU，年年迭代，这使得工作负载迁移和利用率保持变得极为困难。软件必须隐藏这种异构性，同时调度延迟敏感的排序任务、训练任务和 LLM 任务。
内存和带宽压力尤为突出。推荐系统的 embedding 表体积巨大，需要高带宽内存。Meta 正在探索 HBM（高带宽内存）、内存解构和高性能网络，以避免受限于封装内内存和散热约束。单个配备 72 块 NVIDIA Blackwell GPU 的 AI pod 功耗约 140kW，需要空气辅助液冷，这对现有数据中心设计提出了全新要求。
排序和推荐 workloads 与 LLM 的模式截然不同：前者是海量的低延迟推理，后者是计算密集型训练和长上下文推理。基础设施必须同时支持这两类截然不同的工作负载，而强化学习、测试时推理等技术的快速发展进一步增加了需求的不确定性。
写在最后
Meta 推荐系统的工程实践揭示了一个深刻事实：在超大规模场景下，技术决策的本质是在多个相互冲突的目标之间寻找动态平衡点。容量与延迟、新鲜度与缓存效率、模型迭代速度与系统稳定性、硬件成本与性能 —— 这些都不是简单的优化问题，而是需要持续权衡的艺术。
对于分布式系统工程师而言，Meta 的经验提供了宝贵的参考框架：多目标优化必须成为架构设计的核心原则；基础设施与 ML 模型的协同设计比单独优化任何一方更重要；工具链和自动化的投入是应对规模复杂性的唯一可行路径。当系统规模达到数十亿用户和数万亿次每日推理时所谓的「优雅架构」往往让位于务实的技术债务管理，而这本身就是一个值得深思的工程哲学命题。
参考资料
- Meta Engineering: "Journey to 1000 models: Scaling Instagram's recommendation system"
- Meta Research: "Jointly Optimize Capacity, Latency and Engagement in Large-scale Recommendation Systems"
- Meta Engineering: "Meta's Infrastructure Evolution and the Advent of AI"