6月13日，由益企研究院和CDCC主办，隆高展览承办的2025中国智算中心全栈技术大会、第6届中国数据中心绿色能源大会、暨第11届中国（上海）国际数据中心产业展览会（以下简称“大会”）在上海新国际博览中心圆满闭幕。
会上，行吟信息科技（上海）有限公司（小红书）基础设施负责人陈立波，带来《小红书自建基础设施之路》的分享，首次系统披露自研基建体系，深入剖析了小红书在基础设施建设中，如何结合自身业务需求，实现从规划到落地的全流程优化，为行业提供了宝贵的借鉴经验。
以下内容根据演讲实录整理（有删减）：
大家好！非常荣幸今天能与各位分享小红书在下云和自建基础设施过程中的探索与思考。作为行业内布局基础设施建设较晚的参与者，小红书在这一领域有着独特的观察视角——我们不仅亲历了行业技术的迭代浪潮，更在实践中见证了诸多极具参考价值的发展轨迹。
这几年，技术领域的革新可谓繁花似锦：以暖通技术为例，其迭代升级从未停歇；我们也目睹了行业从大规模新建数据中心到部分资源闲置的阶段性变化；更见证了不少企业从整机采购到全面自研自产，最终又回归整机采购的策略调整。这些经历如同鲜活的行业图鉴，让我们在技术选型与基建布局时，得以更全面地借鉴经验、规避风险。
今天的分享，我们将围绕这些真实历程展开，希望能为大家呈现小红书在基础设施建设中的思考逻辑与实践心得。
1
小红书为什么自建
小红书的自建基础设施之路始于2023年，恰逢公司成立10周年的关键节点。在此之前，我们长期采用纯公有云架构——从最初单一云服务商的合作模式，到2021年因业务高速发展催生的多云扩展需求，这一转变背后实则是对稳定性、成本控制与效率优化的多重考量。然而，即便是在多云的场景下，我们依然会碰到一些比如关键资源出现断供、公有云资源部署不符合我们业务需求等问题。
在小红书自建云的决策历程中，有两个关键事件值得重点分享：一个是某年春节，当时我们向公有云一次性提出100万核的资源需求，却发现没有任何一家公有云能够完全承接；另一个是来自全球数据合规浪潮，随着欧洲GDPR《数据安全法案》的落地，行业内一系列巨额罚单令人警醒——Uber被处罚了23亿欧元，Meta被罚款12亿欧元，近期tiktok海外业务也面临5.3亿美元罚款。这些案例让我们清晰认识到：若类似风险发生在小红书，可能构成致命打击。
供应链安全的不确定性与数据合规的刚性要求，共同推动小红书在2023年做出重要技术决策——将算力架构从“多云协作” 升级为“公有云+自建云”的混合模式。这一调整不仅是对业务稳定性的保障，更是从企业长期发展视角，对技术自主权与合规安全边界的重新定义。
2
要做哪些准备工作
国内基础设施行业历经数十年发展，已形成深度专业化的分工体系——从暖通工程、供配电系统到设备运维、网络架构等领域，市场上已具备相对充足的专业人才储备。然而在行业高度细分的背景下，鲜有从业者系统思考过一个核心命题：当需要从零开始构建完整的基础设施体系时，该如何规划顶层设计？又该如何实现暖通、电力、网络、设备等多专业维度的协同落地？这本质上是一个涉及技术架构、工程管理、成本控制的复杂系统工程。
作为小红书自建基础设施的1号员工，我有幸以亲历者视角参与了从0到1的全流程搭建。今天想从实践者的角度，分享我们在顶层设计、跨专业协同及落地执行中的思考逻辑与实战经验，希望能为行业同仁提供一些借鉴。
首先，财务模型会发生显著变化，若过去采用公有云的话是一个Opex模型，你账期可能是一个月，而自建会把Opex向Capex转化，短期来讲对你公司现金流会有比较重要的影响，但是长期成本一定是低的。以设备采购为例，多数企业都是按照四年做折旧的，但实际设备使用寿命可能会到5-6年甚至更长，这意味着它的长期使用成本是非常低的，可以低到什么程度呢？大概是20%以下。
第二，自建基础设施需同步扩充职能部门，不仅要增设面向硬件的采购团队、财务人员、审计人员及法规合规岗，更需重点强化技术部门建设——比如配备服务器硬件架构与选型人员、上线后的运维团队，网络领域需配置DCN/DCI架构设计、线缆规划、路由与IP设计及后续运维人员，而IDC选址关乎业务5-10年发展，其选型、建设及后期运维团队也至关重要；同时，所有业务动作均需运维平台支撑，对大规模基础设施而言，自动化是避免管理效率崩塌的必要条件，否则将陷入运维灾难。
如果要建设独立站点，就需配置独立的流量出口与入口，同时要部署LVS等网关产品；若基础规模庞大，还需招聘OS或 Kernel运维人员——因为大规模场景下会面临资源高效利用、处理各类复杂异常问题等挑战，这类专业人员正是解决上述问题的核心力量。
我们当前采购的设备往往具备强大的核心处理能力，动辄拥有数十甚至数百颗核心，很少有业务能够独立把节点吃掉，因此需要借助虚拟化技术，把资源做切分和分配，通常来讲我们会选择K8S的技术，当然也有公司会选择类似于KUM一样的虚拟化技术。
现在很多公司也会把存储作为自己的核心资产，如果你的业务有非常海量的数据存储需求，这里的“海量”通常指至少达到EB 级的数据规模。在此场景下，你可能要考虑做一些存储系统的开发，这是涉及多专业协同的复杂系统性工程。除了各专业领域的核心技术人员，还需配备集成工程师，对不同专业模块进行深度整合，如此方能构建起一个最小化的基础设施单元。
也有人会问，如果企业既没有数据存储的需求，也没有数据合规严格苛刻的要求，仅从成本角度考量，什么时候应该考虑下云，什么时候应该考虑自建。这是第一个问题。
第二个问题，扩充如此多专业团队究竟需要多少人力？从实践经验来看，最小化配置仅需30人即可支撑基础体系运转。30人其实对很多公司来讲是一个不太真实的数字，因为这个专业确实非常复杂，需要很多人；小红书其实也处在高速发展的阶段，不是处在业务的平稳期或者下降期，当然30人确实今天经过实践得出来的经验，我们人效非常高。
关于第一个成本考量的问题，小红书通过实践测算与落地验证形成了明确结论：200万核心可能是成本平衡点的关键阈值——若低于这一规模，企业选择公有云往往更具成本优势，因其具备灵活弹性的资源调配能力与友好的OPEX财务模型，尤其对小公司而言，无需过早投入底层基础设施建设；而200万核心的设定还隐含多重战略考量：一方面，该规模下企业可与 Tier1级核心供应商合作，充分保障设备质量与服务稳定性；另一方面，实际成本平衡点会受云上云下采购价格差影响，企业可基于具体报价进一步精细化测算，但200万核心无疑是兼具成本效益与资源保障的参考基准。
3
硬件设计选型
接下来可以介绍一下具体设备选型上的思考，作为一名互联网老兵，在行业里我也看到过很多创新，大部分都是含Buff出来的，我们观测到一些创新比较有局部性，有些创新会有一些时效性，还有一些创新是纯KPI驱动的，真正能够沉淀下来并且能上规模的创新我们看到也不太多，所以我们做基础设施的时候一开始定了一些比较原则性的主张，比如说我们不会为了创新而创新，我们不会为了不同而不同，这些听起来都是比较简单的道理，做起来其实也并不是很容易，因为这将失去很多造轮子的机会，这其实也挺重要的。
还有一条就是我们认为资源的利用率大于单价指标，怎么理解？我们认为如果我们能够充分把基础设施所有资源能够比较好用起来，这其实是最大的一个节约，比单纯的局部优化可能来得会更有意义一点，因为我们观察到很多底层优化往往都会给使用设置门槛，这样会导致很多设施出现一些闲置，然后增加运营成本，这反而会造成更大的浪费。
在架构特征上我们有几个关键词：单一、池化、弹性。
单一：我们设备选型层面坚持单一，比如我们在业务场景下面整个公司只有一款计算型服务器，我们不会为不同的业务而设置不同的机型，即便在某些业务场景下该机型可能会带来更好的TCO，我们坚持底层一定是原子、同构的，这样为我们未来池化技术提供非常好的基础。
池化：我们现在的每个计算节点都有上百个核心，我们公司会把几百万的核心放在一起组成一个大的资源池，通过K8S技术对资源进行切分和分配，我们公司所有的在离线业务都在这个资源池里面跑，好处就是我们可以把我们公司的CPU利用率可以跑得非常高。
弹性：小红书的业务特点其实有比较明显的日潮汐和周潮汐的特点，为了应对这样的特征，我们在从基础设施一直往上每一层都做了很多弹性设计，这样的好处也是充分把我们整个资源能够利用起来。比如，我们自己的基础设施电力利用率和它的网络端口分配率几乎都接近100%，CPU平均利用率都在40%以上，峰值做到70%以上，了解相关工作的人都知道这些指标实现起来难度极大，而从成本优化视角看，在这些核心指标的优化下，很多局部优化都显得微不足道；所以我们认为simple is best。
在计算型服务器选型上，我们仅采用一款具备1923->192线程的机型，而推理服务器则基于业务对大内存带宽的严苛需求，选择了两路四卡的设计方案——相比业界普遍采用的单路架构，这种最大化设计虽在个别场景并非最优解，但通过支持全局资源混布策略，实现了整体资源调度效率的最大化，也正是基于 “全局最优”的架构理念，我们坚持采用向上设计的选型思路。这一选型思路与业界常见的分类型存储方案形成了显著差异。
在存储设备选型上，我们采用60盘机型设计，负责我们温存和冷存设计，我们并没有针对不同存储类型单独设计机型，而是通过规模化部署解决效率与带宽问题，这样也让我们整个资源利用率跑得更高，这是我们在存储选型上面的思考，可能跟有些公司不太一样。
在IDC选型设计方面，近期经常有人问及小红书自建基础设施会不会做纯自建的IDC，我们的思考是：当前IDC行业竞争已经十分充分，头部服务商在建设效率与成本控制上已达极致水平，且能提供灵活的商务合作模式。基于“专业的人做专业的事”的原则，我们暂不考虑自主建设IDC，而是将需求方案输出给合作商，由其完成落地实施。
在IDC设计方面，我们认为单个IDC容量为30-50兆瓦比较合适，这样可以应对我们未来3-5年业务长期发展，单机柜功率我们做了12-20千瓦设计，一是可以应对我们周潮汐和日潮汐的特征；二是弹性功率下可以帮助我们应对通算场景也可以应对一些智算场景。智算的时候我们把功率拉高，通算的时候把功率降低，这样全局都不会浪费，这样对我们来讲是比较好的设计。
在暖通系统选型上，尽管行业存在诸多创新方案，但我们认为冷冻水+精密空调还是最可靠、最简单的选型，同时我们也关注到，像风墙这类新型方案在TCO成本优化及管路施工便捷性等方面具备显著优势，因此已在部分机房包间中落地试点。
在配电系统设计上，我们始终坚持双路市电接入的硬性标准，拒绝单路市电配置；末端我们认为双路UPS和双路HVDC都是比较可靠的选型；后备电源方面，柴发系统的配置与行业标准一致，上述设计构成了我们在IDC配电规划中的完整考量。
在网络DCN选型上面，我们整体架构与业内主流设计思路趋同，但在接入层设计上存在显著差异。我们采用1：1无收敛设计，选用了200G带宽，我知道这一块行业里很多玩家都会根据不同业务特点设计不同接入的收敛比，比如说1：2、1：4、1：1.5我都见过，好处就是它可以在特定业务场景下面可以拿到更好网络模型的TCO，问题就是说它会让整个基础设施跟你的业务做了强绑定，这样会造成很多问题，比如说一些业务因为它的流量差异有很大不同，它其实很难在机柜和整机层面去做一些混布，因为流量很容易出现浪费，结果会造成很多基础设施出现闲置和浪费的情况，这是非常沉重的运营成本，设计的时候很难考虑到，但是玩过之后就知道这里面其实有很大的坑。
所以我们做设备选型的时候、IDC架构的时候，坚持做了接入层1：1无收敛设计，好处就是我们所有业务都可以充分做混布，缺点就是不同场景下面可能模型不是特别好，但是我们坚信在全局的场景下面我们一定会拿到更好的一个收益。
4
混合云设计
一开始介绍了如果你基础设施不是孤立存在的，也有公有云搭配，如何做差异化屏蔽，如何做跨资源的扩容以及它的容灾，其实都会有非常多的问题，面对这些问题我们构建了非常超大规模的云原生基础设施，云原生Infra，主要作用就是帮我们屏蔽不同云的差异，比如说阿里云、腾讯云或者其他云它在虚拟化技术上面，OS技术包括它在硬件层的设计上面，其实都会有很多不同，包括它开放的API都会不一样，包括我们自建之后在刚才的这些点上也会不一样，对业务来讲如果说我要去适配每朵云这是非常痛苦的，所以我们云原生Infra最大作用就是帮助业务屏蔽了不同云的差异，我们在这个云原生Infra之上我们还构建了联邦式多集群解决方案，这套解决方案下面我们可以在多云之间统一进行资源的扩容、资源的弹性、资源的分发，像一朵云一样。我们在这套技术下面最大好处就是让我们在全局能够拿到资源最优解，屏蔽单云带来的比如说资源瓶颈、成本的一些差异等。
最后，给大家介绍一下我们在多活架构上面的思考，我们混合云架构我们引入了多朵云包括自建云，好处就是让我们资源供给更加丰富，我们也可以让多云让不同供应商竞价，我们拿到更好成本的优势，它的主要问题就是说风险敞口也打开了，因为没有一朵云的SLA是100%，也没有一根专线的SLA是100%”，没有单一基础设施是可靠的。为此我们设计了多地多中心的容灾架构，目前已具备通过南北向以及东西向路由策略，让我们能够把单机房容量非常容易切走，让单机房业务逃逸，同时流量通过我们的GSLB、DNS技术可以无缝切到其他一些地域，来保证我们业务的始终高可靠。近年来公有云虽陆续出现各类问题，但小红书业务因这套自动化、高可靠的架构设计，基本未受严重影响，充分验证了该方案的有效性。
前面介绍了小红书在下云如何构建基础设施包括如何处理多云问题的一些思考和实践，谢谢大家。
end
2026中国智算中心全栈技术大会暨展览会暨第12届中国（上海）国际数据中心产业展览会、第7届中国数据中心绿色能源大会，即将于2026年6月在上海新国际博览中心举办。
参展、参会或了解更多详情，请联系：
金笑雨先生
电话：18610941758
微信：Jin_Xiaoyuer
热门跟贴