1. 從算力焦慮說起為什么數(shù)據(jù)中心成了AI戰(zhàn)略的勝負(fù)手過去兩年圈子里聊AI十句話里有八句繞不開模型參數(shù)、訓(xùn)練技巧、推理優(yōu)化。但真正在一線做過大規(guī)模訓(xùn)練的人心里都清楚模型架構(gòu)再漂亮算法再精巧最后卡脖子的往往不是代碼而是算力供給——具體來說是能不能拿到足夠多、足夠穩(wěn)定、足夠便宜的GPU集群以及支撐這些集群運轉(zhuǎn)的數(shù)據(jù)中心。Meta這家公司在AI上的投入力度業(yè)內(nèi)是有目共睹的。從早期的PyTorch生態(tài)布局到后來的大模型開源策略再到近兩年在推薦系統(tǒng)和生成式AI上的全面發(fā)力它走的每一步都跟底層基礎(chǔ)設(shè)施深度綁定。很多人只看到它開源模型帶來的聲量卻忽略了背后那套支撐訓(xùn)練和推理的龐大機(jī)房體系。這篇文章就想把這件事掰開揉碎講清楚為什么數(shù)據(jù)中心會被Meta放到AI戰(zhàn)略的核心位置這背后有哪些技術(shù)邏輯、工程考量和現(xiàn)實約束以及這些經(jīng)驗對普通開發(fā)者、中小團(tuán)隊有什么參考價值。先說結(jié)論AI競爭的本質(zhì)正在從誰的模型更聰明轉(zhuǎn)向誰能更高效地把電力轉(zhuǎn)化為智能。而數(shù)據(jù)中心就是完成這個轉(zhuǎn)化的核心工廠。理解這一點后面所有的技術(shù)選型、架構(gòu)設(shè)計、成本控制才有落腳點。這篇文章適合幾類人看一是對AI基礎(chǔ)設(shè)施感興趣但不太清楚全貌的開發(fā)者二是正在做模型訓(xùn)練、被算力和成本折磨的工程同學(xué)三是想理解大廠AI戰(zhàn)略背后邏輯的技術(shù)管理者。我會盡量用大白話把里面的門道講透不堆術(shù)語多講為什么這么干。2. 數(shù)據(jù)中心為什么成了AI的命脈核心邏輯拆解2.1 訓(xùn)練和推理對基礎(chǔ)設(shè)施的真實需求要理解數(shù)據(jù)中心的分量得先搞清楚AI到底吃什么。一個大規(guī)模模型的訓(xùn)練過程本質(zhì)上是在做海量的矩陣運算這些運算需要成千上萬張加速卡并行協(xié)作。這里有幾個硬指標(biāo)算力密度單張卡的算力有限必須靠數(shù)量堆疊但堆疊不是簡單插卡就行卡與卡之間的通信帶寬直接決定訓(xùn)練效率?；ヂ?lián)帶寬分布式訓(xùn)練時梯度同步、參數(shù)更新都需要高速網(wǎng)絡(luò)支撐。網(wǎng)絡(luò)一旦成為瓶頸加再多卡也是白搭。存儲吞吐訓(xùn)練數(shù)據(jù)動輒幾十上百TB數(shù)據(jù)讀取速度跟不上GPU就會空轉(zhuǎn)等數(shù)據(jù)。供電與散熱高密度機(jī)柜的功耗和發(fā)熱是傳統(tǒng)機(jī)房的好幾倍供電和制冷方案必須重新設(shè)計。這四點決定了AI訓(xùn)練不能隨便找個機(jī)房就開干。傳統(tǒng)數(shù)據(jù)中心是為通用計算設(shè)計的網(wǎng)絡(luò)架構(gòu)、供電能力、散熱方案都是按普通服務(wù)器來的。而AI集群需要的是專門優(yōu)化過的高性能計算環(huán)境這就是為什么大廠都在自建或深度定制數(shù)據(jù)中心。我打個比方普通數(shù)據(jù)中心像是城市里的普通公路能跑車但高峰期會堵AI專用數(shù)據(jù)中心則像是為重型卡車專門修的高速公路路面承重、匝道寬度、加油站布局全都是按大載重設(shè)計的。你讓重型卡車走普通公路不是不能走是走不快還容易把路壓壞。2.2 自建數(shù)據(jù)中心 vs 租用云服務(wù)一筆算得清的賬很多人會問現(xiàn)在云服務(wù)這么發(fā)達(dá)直接租GPU不就行了為什么要自己建數(shù)據(jù)中心這個問題在一線特別實際我試著從幾個維度拆解。成本維度短期看租用云服務(wù)靈活、啟動快不用一次性投入巨資。但AI訓(xùn)練是長期、持續(xù)、大規(guī)模的需求當(dāng)你的算力消耗達(dá)到一定量級后自建的單位成本會顯著低于租用。這就像打車和買車的區(qū)別——偶爾出行打車劃算天天通勤還是買車更經(jīng)濟(jì)。大廠的訓(xùn)練任務(wù)是7×24小時不間斷的自建的規(guī)模效應(yīng)非常明顯?？煽匦跃S度租用云服務(wù)意味著你的訓(xùn)練任務(wù)跑在別人的硬件和網(wǎng)絡(luò)架構(gòu)上遇到性能瓶頸時你能調(diào)的參數(shù)有限。自建數(shù)據(jù)中心可以從網(wǎng)絡(luò)拓?fù)?、存儲架?gòu)、調(diào)度系統(tǒng)全鏈路優(yōu)化針對自己的模型特點做深度定制。這種可控性對追求極致訓(xùn)練效率的團(tuán)隊來說價值巨大。供應(yīng)鏈維度高端加速卡的供應(yīng)一直緊張誰能更早鎖定產(chǎn)能、更深度參與硬件定制誰就能在算力競賽中占先機(jī)。自建數(shù)據(jù)中心往往伴隨著與硬件廠商的深度合作甚至聯(lián)合設(shè)計專用芯片這是單純租用服務(wù)做不到的。數(shù)據(jù)安全與合規(guī)維度訓(xùn)練數(shù)據(jù)里可能包含敏感信息自建機(jī)房在數(shù)據(jù)管控上更自主。這一點對企業(yè)級應(yīng)用尤其重要。當(dāng)然自建也有明顯劣勢前期投入巨大、建設(shè)周期長、運維復(fù)雜度高、技術(shù)迭代風(fēng)險大硬件可能很快過時。所以現(xiàn)實中大廠往往是自建為主、租用為輔的混合策略用自建承載核心的長期訓(xùn)練任務(wù)用租用應(yīng)對突發(fā)的彈性需求。2.3 從堆算力到提效率數(shù)據(jù)中心的角色演變早期大家比的是誰卡多誰集群大。但很快發(fā)現(xiàn)光堆硬件不行集群的實際利用率才是關(guān)鍵。一個一萬張卡的集群如果因為網(wǎng)絡(luò)擁塞、調(diào)度不合理、故障頻繁實際有效算力可能只有理論值的一半甚至更低。這就把數(shù)據(jù)中心的角色從硬件倉庫推向了效率引擎。具體體現(xiàn)在幾個層面網(wǎng)絡(luò)架構(gòu)優(yōu)化從傳統(tǒng)的樹形網(wǎng)絡(luò)轉(zhuǎn)向更適應(yīng)AI訓(xùn)練的拓?fù)浣Y(jié)構(gòu)減少通信跳數(shù)提升帶寬利用率。調(diào)度系統(tǒng)智能化根據(jù)任務(wù)優(yōu)先級、資源需求、故障狀態(tài)動態(tài)分配算力讓集群盡量滿負(fù)荷運轉(zhuǎn)。故障自愈能力大規(guī)模集群里硬件故障是常態(tài)關(guān)鍵是能不能快速檢測、隔離、恢復(fù)把對訓(xùn)練任務(wù)的影響降到最低。能效管理電費是數(shù)據(jù)中心運營的大頭通過液冷、余熱回收、智能調(diào)溫等手段降低PUE能源使用效率直接關(guān)系到運營成本。所以你看數(shù)據(jù)中心早就不只是放服務(wù)器的地方它本身就是一個需要持續(xù)優(yōu)化的復(fù)雜系統(tǒng)工程。Meta把數(shù)據(jù)中心提到戰(zhàn)略核心本質(zhì)上是因為它意識到AI的競爭力越來越取決于基礎(chǔ)設(shè)施的工程能力而不只是算法本身。3. 拆解Meta的數(shù)據(jù)中心技術(shù)棧關(guān)鍵環(huán)節(jié)與實操要點3.1 網(wǎng)絡(luò)架構(gòu)決定集群效率的隱形骨架在AI訓(xùn)練集群里網(wǎng)絡(luò)的重要性怎么強(qiáng)調(diào)都不過分。我見過太多案例模型代碼沒問題卡也夠多但訓(xùn)練速度就是上不去最后排查發(fā)現(xiàn)是網(wǎng)絡(luò)成了瓶頸。Meta在數(shù)據(jù)中心網(wǎng)絡(luò)上的投入方向業(yè)內(nèi)比較公認(rèn)的幾個關(guān)鍵點高帶寬互聯(lián)訓(xùn)練時梯度同步的數(shù)據(jù)量極大網(wǎng)絡(luò)帶寬不足會直接拖慢整體速度。所以AI集群普遍采用高速互聯(lián)方案單端口帶寬遠(yuǎn)高于通用數(shù)據(jù)中心。低延遲拓?fù)鋫鹘y(tǒng)的三層網(wǎng)絡(luò)架構(gòu)跳數(shù)多、延遲高不適合AI訓(xùn)練的東西向流量卡與卡之間的通信。更扁平化的拓?fù)淠軠p少跳數(shù)降低延遲。擁塞控制大規(guī)模集群里多個訓(xùn)練任務(wù)同時跑網(wǎng)絡(luò)擁塞幾乎不可避免。好的擁塞控制算法能讓帶寬分配更公平避免個別任務(wù)餓死。實操中如果你在搭建或優(yōu)化訓(xùn)練集群網(wǎng)絡(luò)這塊我建議重點關(guān)注幾個指標(biāo)卡間通信帶寬、網(wǎng)絡(luò)往返延遲、擁塞發(fā)生頻率。這三個指標(biāo)直接決定你的集群能跑多快。具體排查時可以用帶寬測試工具先摸清實際網(wǎng)絡(luò)能力再對比理論值找差距。注意網(wǎng)絡(luò)優(yōu)化往往是最容易被忽視的環(huán)節(jié)。很多團(tuán)隊把精力全放在模型和GPU上結(jié)果網(wǎng)絡(luò)成了木桶最短的那塊板。建議在集群上線前就做完整的網(wǎng)絡(luò)基準(zhǔn)測試。3.2 供電與散熱高密度機(jī)柜的工程挑戰(zhàn)AI集群的功耗密度遠(yuǎn)超傳統(tǒng)機(jī)房。一個裝滿高功耗加速卡的機(jī)柜功耗可能是普通機(jī)柜的好幾倍。這就帶來兩個直接問題供電能不能跟上散熱能不能壓住。供電方面需要重新設(shè)計配電方案確保每個機(jī)柜能拿到足夠的電力同時要有冗余設(shè)計防止單點故障。大廠的數(shù)據(jù)中心往往在選址時就考慮電力供應(yīng)靠近發(fā)電資源或電網(wǎng)容量充裕的區(qū)域。散熱方面?zhèn)鹘y(tǒng)風(fēng)冷在高密度場景下逐漸力不從心液冷方案越來越受重視。液冷又分冷板式和浸沒式各有優(yōu)劣冷板式改造成本相對低適合逐步升級浸沒式散熱效率更高但對機(jī)房改造要求大。這里有個實操經(jīng)驗散熱方案的選擇要結(jié)合機(jī)柜功率密度和現(xiàn)有基礎(chǔ)設(shè)施來定。如果單機(jī)柜功率密度在某個閾值以下優(yōu)化風(fēng)道和空調(diào)可能就夠了超過閾值就得考慮液冷。盲目上液冷可能造成投資浪費散熱不足又會限制算力發(fā)揮。能效指標(biāo)PUE是衡量數(shù)據(jù)中心能源效率的關(guān)鍵參數(shù)計算方式是總能耗除以IT設(shè)備能耗。PUE越接近1說明能源利用越高效。傳統(tǒng)數(shù)據(jù)中心PUE可能在1.5以上優(yōu)秀的新建數(shù)據(jù)中心能做到1.1左右。這個差距乘以巨大的用電量就是真金白銀的成本差異。3.3 存儲與數(shù)據(jù)管道別讓GPU等數(shù)據(jù)訓(xùn)練集群里最浪費的場景之一就是昂貴的GPU在等數(shù)據(jù)。存儲和數(shù)據(jù)處理管道的設(shè)計直接決定GPU能不能吃飽。存儲分層是常見做法熱數(shù)據(jù)放在高速存儲上冷數(shù)據(jù)放在大容量低成本存儲上通過智能調(diào)度把需要的數(shù)據(jù)提前搬到高速層。這樣既保證訓(xùn)練時的讀取速度又控制總體存儲成本。數(shù)據(jù)預(yù)處理管道也很關(guān)鍵。原始數(shù)據(jù)往往需要清洗、格式轉(zhuǎn)換、增強(qiáng)等處理如果這些都在訓(xùn)練時實時做會嚴(yán)重拖慢速度。更好的做法是提前處理好訓(xùn)練時直接讀取。Meta這類公司通常有專門的數(shù)據(jù)處理流水線把原始數(shù)據(jù)加工成訓(xùn)練友好的格式。實操建議在搭建訓(xùn)練環(huán)境時先做數(shù)據(jù)讀取的基準(zhǔn)測試。用真實的訓(xùn)練數(shù)據(jù)跑一遍看GPU利用率能不能維持在較高水平。如果GPU經(jīng)常空轉(zhuǎn)八成是數(shù)據(jù)管道有問題。常見原因包括存儲帶寬不足、數(shù)據(jù)格式不友好、預(yù)處理邏輯太重等。3.4 調(diào)度與容錯讓萬卡集群穩(wěn)定運轉(zhuǎn)大規(guī)模集群里硬件故障是家常便飯。一張卡掛了、一根網(wǎng)線松了、一個節(jié)點過熱了都可能影響整個訓(xùn)練任務(wù)。調(diào)度和容錯系統(tǒng)的核心任務(wù)就是讓故障的影響最小化讓集群盡量滿負(fù)荷運轉(zhuǎn)。調(diào)度系統(tǒng)需要解決幾個問題怎么把不同優(yōu)先級、不同資源需求的任務(wù)合理分配到集群上怎么在任務(wù)之間做資源隔離避免互相干擾怎么在故障發(fā)生時快速重新調(diào)度。容錯機(jī)制則要保證訓(xùn)練任務(wù)在遇到故障時能快速恢復(fù)。常見做法包括定期保存檢查點checkpoint故障后從最近的檢查點恢復(fù)冗余設(shè)計關(guān)鍵組件單點故障不影響全局自動檢測和隔離故障節(jié)點避免問題擴(kuò)散。這里有個容易被忽視的點檢查點的保存頻率需要權(quán)衡。保存太頻繁會占用大量存儲和網(wǎng)絡(luò)帶寬拖慢訓(xùn)練保存太少故障后要重算很多浪費時間。實踐中需要根據(jù)任務(wù)時長、故障率、存儲能力綜合確定。提示容錯系統(tǒng)的價值在集群規(guī)模小時不明顯但規(guī)模越大越關(guān)鍵。萬卡集群如果沒有好的容錯機(jī)制實際可用算力可能大打折扣。4. 從戰(zhàn)略到落地數(shù)據(jù)中心如何支撐AI業(yè)務(wù)4.1 訓(xùn)練與推理的不同基礎(chǔ)設(shè)施需求AI業(yè)務(wù)分訓(xùn)練和推理兩大塊它們對基礎(chǔ)設(shè)施的需求差異很大數(shù)據(jù)中心需要同時支撐這兩種負(fù)載。訓(xùn)練的特點是計算密集、周期長、對網(wǎng)絡(luò)和存儲要求高、可以容忍一定延遲。訓(xùn)練任務(wù)往往跑幾天甚至幾周中間偶爾慢一點問題不大關(guān)鍵是整體吞吐。推理的特點是延遲敏感、并發(fā)量大、對穩(wěn)定性要求極高。用戶請求過來必須在毫秒級返回結(jié)果不能有卡頓。推理的基礎(chǔ)設(shè)施更強(qiáng)調(diào)響應(yīng)速度和可用性。數(shù)據(jù)中心要同時服務(wù)這兩類負(fù)載就需要做資源池化和隔離。訓(xùn)練用一部分資源推理用另一部分通過調(diào)度系統(tǒng)動態(tài)調(diào)整。有些公司還會針對推理做專門的硬件優(yōu)化比如用更適合推理的加速卡或者做模型量化壓縮來降低推理成本。實操中訓(xùn)練和推理的資源配比需要根據(jù)業(yè)務(wù)節(jié)奏動態(tài)調(diào)整。比如新產(chǎn)品上線期推理需求大模型迭代期訓(xùn)練需求大靈活的資源調(diào)度能顯著提升整體利用率。4.2 規(guī)?；瘞淼倪呺H效應(yīng)與挑戰(zhàn)數(shù)據(jù)中心有個特點規(guī)模越大單位成本越低但管理復(fù)雜度越高。這就是規(guī)?；碾p刃劍。邊際效應(yīng)體現(xiàn)在大規(guī)模采購硬件有議價優(yōu)勢自建供電和散熱設(shè)施的單位成本更低運維團(tuán)隊可以攤薄到更多設(shè)備上技術(shù)積累可以復(fù)用到更多場景。挑戰(zhàn)則體現(xiàn)在故障率隨規(guī)模線性增長萬卡集群每天可能都有硬件出問題網(wǎng)絡(luò)復(fù)雜度指數(shù)上升調(diào)度和容錯的難度大幅增加能耗和散熱壓力持續(xù)加大。Meta這類公司的應(yīng)對思路是把很多運維工作自動化、智能化。比如用機(jī)器學(xué)習(xí)預(yù)測硬件故障提前更換用智能調(diào)度算法優(yōu)化資源分配用自動化工具做故障檢測和恢復(fù)。這些能力本身就是核心競爭力。對中小團(tuán)隊來說雖然規(guī)模沒那么大但自動化運維的思路是通用的。哪怕只有幾十張卡建立基本的監(jiān)控、告警、自動恢復(fù)機(jī)制也能顯著降低運維負(fù)擔(dān)。4.3 數(shù)據(jù)中心布局的地理與能源考量數(shù)據(jù)中心建在哪里是個綜合了地理、能源、網(wǎng)絡(luò)、政策等多因素的決策。能源因素數(shù)據(jù)中心耗電巨大電價直接影響運營成本。所以很多數(shù)據(jù)中心建在電力資源豐富、電價較低的區(qū)域。同時可再生能源的使用也越來越受重視既降低成本又符合可持續(xù)發(fā)展方向。氣候因素涼爽的氣候有利于散熱降低制冷能耗。所以不少數(shù)據(jù)中心選址在氣溫較低的地區(qū)。網(wǎng)絡(luò)因素數(shù)據(jù)中心需要與用戶和其他數(shù)據(jù)中心高速互聯(lián)網(wǎng)絡(luò)基礎(chǔ)設(shè)施的完善程度是重要考量。地理分散為了容災(zāi)和降低延遲大公司往往在多個地區(qū)布局?jǐn)?shù)據(jù)中心通過高速網(wǎng)絡(luò)連成整體。一個地方出問題其他地區(qū)可以接管。這些考量對普通團(tuán)隊的啟示是基礎(chǔ)設(shè)施布局要有全局視角不能只看單點成本要綜合考慮能源、網(wǎng)絡(luò)、容災(zāi)等因素。當(dāng)然中小團(tuán)隊通常沒這個煩惱但理解大廠的邏輯有助于看清行業(yè)趨勢。5. 常見問題與排查技巧實錄5.1 訓(xùn)練集群性能不達(dá)預(yù)期的排查思路這是最常遇到的問題集群搭好了卡也夠多但訓(xùn)練速度就是上不去。我整理了一套排查思路按優(yōu)先級從高到低排查項常見癥狀排查方法解決方向GPU利用率GPU經(jīng)常空轉(zhuǎn)監(jiān)控工具看利用率曲線檢查數(shù)據(jù)管道、調(diào)度邏輯網(wǎng)絡(luò)帶寬卡間通信慢帶寬測試工具實測優(yōu)化拓?fù)洹⑸壔ヂ?lián)存儲讀取數(shù)據(jù)加載慢存儲吞吐基準(zhǔn)測試存儲分層、數(shù)據(jù)預(yù)處理散熱降頻卡溫度高、頻率降監(jiān)控溫度與頻率優(yōu)化散熱、調(diào)整機(jī)柜布局調(diào)度沖突任務(wù)互相搶資源分析調(diào)度日志優(yōu)化調(diào)度策略、資源隔離排查時建議從最上層往下查先看GPU利用率如果低再看是等數(shù)據(jù)還是等網(wǎng)絡(luò)逐步定位瓶頸。不要一上來就懷疑硬件很多問題其實是軟件配置或調(diào)度策略導(dǎo)致的。5.2 硬件故障的快速定位與恢復(fù)大規(guī)模集群里硬件故障不可避免關(guān)鍵是快速定位和恢復(fù)。幾個實操技巧建立完善的監(jiān)控體系溫度、功耗、網(wǎng)絡(luò)狀態(tài)、GPU狀態(tài)都要實時監(jiān)控異常時自動告警。故障隔離機(jī)制檢測到故障節(jié)點后自動從集群中隔離避免影響其他任務(wù)。快速恢復(fù)流程從最近的檢查點恢復(fù)訓(xùn)練把損失降到最低。故障根因分析每次故障后做復(fù)盤找出根本原因避免同類問題重復(fù)發(fā)生。注意故障處理的速度直接決定集群的有效利用率。一個故障如果處理幾小時損失的算力成本可能非?？捎^。所以自動化故障處理能力非常重要。5.3 成本控制的幾個實用手段AI基礎(chǔ)設(shè)施成本高昂控制成本是持續(xù)課題。幾個實用手段提升利用率讓集群盡量滿負(fù)荷運轉(zhuǎn)避免資源閑置。這需要好的調(diào)度系統(tǒng)和任務(wù)管理。優(yōu)化能效降低PUE使用更高效的散熱方案在電價低的時段跑非緊急任務(wù)。硬件生命周期管理合理規(guī)劃硬件更新周期既不過早淘汰造成浪費也不過度使用導(dǎo)致故障率上升?；旌喜呗院诵拈L期任務(wù)用自建突發(fā)彈性需求用租用平衡成本和靈活性。模型優(yōu)化通過量化、剪枝、蒸餾等手段降低模型的計算需求從源頭減少算力消耗。這些手段需要綜合使用單靠某一個效果有限。而且成本控制是個持續(xù)過程需要不斷監(jiān)控、分析、優(yōu)化。6. 這套邏輯對普通開發(fā)者和團(tuán)隊的啟示聊了這么多大廠的基礎(chǔ)設(shè)施戰(zhàn)略回到普通開發(fā)者和中小團(tuán)隊能借鑒什么第一重視基礎(chǔ)設(shè)施的工程能力。很多人把精力全放在模型和算法上忽視了底層工程。但實際項目中工程能力往往決定成敗。哪怕你用的是云服務(wù)理解底層原理也能幫你更好地選型、調(diào)優(yōu)、控成本。第二建立性能監(jiān)控和優(yōu)化的習(xí)慣。不管規(guī)模大小監(jiān)控GPU利用率、網(wǎng)絡(luò)狀態(tài)、存儲吞吐這些指標(biāo)能幫你及時發(fā)現(xiàn)瓶頸。很多性能問題不是突然出現(xiàn)的而是慢慢累積的早發(fā)現(xiàn)早解決。第三成本意識要貫穿始終。AI項目燒錢是常態(tài)但燒得值不值很關(guān)鍵。定期分析成本構(gòu)成找出優(yōu)化空間能顯著提升項目的可持續(xù)性。第四自動化是降本增效的關(guān)鍵。哪怕團(tuán)隊小也要盡量把重復(fù)性工作自動化比如訓(xùn)練腳本、監(jiān)控告警、故障恢復(fù)。省下來的時間可以投入到更有價值的事情上。第五保持對行業(yè)趨勢的關(guān)注?；A(chǔ)設(shè)施技術(shù)迭代很快新的網(wǎng)絡(luò)方案、散熱技術(shù)、調(diào)度算法不斷涌現(xiàn)。保持學(xué)習(xí)才能不掉隊。說到底Meta把數(shù)據(jù)中心視為AI戰(zhàn)略核心反映的是一個行業(yè)共識AI的競爭最終是基礎(chǔ)設(shè)施工程能力的競爭。模型可以開源算法可以學(xué)習(xí)但支撐大規(guī)模訓(xùn)練和推理的基礎(chǔ)設(shè)施需要長期的投入和積累。這個道理對大廠和小團(tuán)隊都成立只是規(guī)模不同、形式不同而已。我在實際項目里踩過的坑告訴我越是基礎(chǔ)的東西越值得花時間打磨。網(wǎng)絡(luò)、存儲、調(diào)度這些看起來不性感的環(huán)節(jié)往往才是決定項目成敗的關(guān)鍵。希望這篇梳理能幫你建立起對AI基礎(chǔ)設(shè)施的整體認(rèn)知在后續(xù)的項目中少走彎路。