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年發展，其選型、建設及后期運維團隊也至關重要；同時，所有業務動作均需運維平臺支撐，對大規?；A設施而言，自動化是避免管理效率崩塌的必要條件，否則將陷入運維災難。

如果要建設獨立站點，就需配置獨立的流量出口與入口，同時要部署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盤機型設計，負責我們溫存和冷存設計，我們并沒有針對不同存儲類型單獨設計機型，而是通過規?；渴鸾鉀Q效率與帶寬問題，這樣也讓我們整個資源利用率跑得更高，這是我們在存儲選型上面的思考，可能跟有些公司不太一樣。

在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