1. 從一篇隨筆說起為什么LLVM ADT和大模型推理會被放在一起先交代一下這篇隨筆的由頭。最近在做一個偏底層的推理性能優(yōu)化項目原本只是打算把某個算子的內(nèi)存分配模式捋清楚結(jié)果順著調(diào)用棧一路追到了LLVM的ADT層又從ADT層的引用計數(shù)語義聯(lián)想到了大模型推理里常見的顯存管理策略。這兩件事乍一看八竿子打不著——一個是編譯器的通用數(shù)據(jù)結(jié)構(gòu)庫一個是深度學習部署的工程領(lǐng)域——但實際沉進去之后會發(fā)現(xiàn)它們底層面對的問題是完全同構(gòu)的怎么在極致的性能要求下安全、高效地管理內(nèi)存的生命周期。這篇隨筆不做面面俱到的源碼逐行注釋也不打算從零科普LLVM的全部知識體系。我的目標是把我這段時間踩過的坑、想明白的幾個關(guān)鍵節(jié)點、以及在推理場景下做的對應(yīng)關(guān)系梳理整理成文字希望能給那些正在啃LLVM源碼、或者正在做大模型推理優(yōu)化的朋友一些可參考的思考路徑。如果你只是想快速了解某個語法糖或者某個API的用法這篇文章可能不太適合你但如果你關(guān)心“為什么LLVM要這么設(shè)計”“這個設(shè)計思想在推理框架里能怎么遷移”那我們可以聊得很深入。先說結(jié)論LLVM ADT中隨處可見的“按值傳遞 拷貝語義 專屬內(nèi)存分配器”的組合拳以及SmallVector、PointerUnion這類數(shù)據(jù)結(jié)構(gòu)對“小對象優(yōu)化”的極致追求和大模型推理中KV Cache的分塊管理、顯存池化、tensor 生命周期追蹤本質(zhì)上是同一套哲學在不同抽象層級的投影。把這個關(guān)系想明白你再看推理框架的源碼很多看似莫名其妙的工程決策都會變得順理成章。2. 先拆LLVM ADT的設(shè)計哲學LLVM的ADTAbstract Data Type不是STL的替代品也不是對STL的簡單包裝。它是在“編譯器這種極端性能敏感場景”約束下重新思考過的一套數(shù)據(jù)結(jié)構(gòu)集合。如果你只把它當成一堆容器類來用你會錯過它背后最有價值的設(shè)計思路。2.1 為什么LLVM要重新發(fā)明一套容器庫STL本身已經(jīng)很成熟vector、map、string應(yīng)有盡有LLVM完全可以直接用。但編譯器領(lǐng)域的特殊之處在于編譯過程會產(chǎn)生海量的短生命周期小對象同時又會長期持有少量的大結(jié)構(gòu)。前者比如每個基本塊里的指令列表、每個表達式生成的臨時節(jié)點后者比如整個Module的符號表、全局常量池。STL的默認行為在這種場景下并不友好。以std::vector為例它的增長策略是倍增式的當你頻繁push_back小元素時分配器會反復調(diào)用::operator new而每一層調(diào)用背后都是malloc的堆管理開銷。編譯器一遍遍解析、生成、優(yōu)化IR的過程中這種開銷會被放大到一個不可忽略的量級。LLVM的解法是在ADT層重寫一套與編譯場景耦合的容器語義。它們不是為了通用而通用而是為了“在編譯器里跑得足夠快”而服務(wù)。這就帶來了一些與STL截然不同的設(shè)計取舍比如SmallVector的棧上緩沖、PointerUnion的指針復用、StringRef的零拷貝視圖。每一個設(shè)計背后都對應(yīng)著編譯階段的某類痛點。2.2 SmallVector小對象優(yōu)化的極致形態(tài)SmallVector是LLVM ADT里最值得反復咀嚼的一個類。它解決的問題非常具體你的容器里往往只會有三五個元素但如果每次都用堆分配來容納這三個元素那么分配和釋放的時間可能比數(shù)據(jù)操作本身還昂貴。SmallVector的做法是在對象內(nèi)部預留一段棧上緩沖比如模板參數(shù)N就可以指定這個緩沖的大小。當實際元素數(shù)量不超過N時所有數(shù)據(jù)都在這段內(nèi)聯(lián)空間里操作不觸碰堆分配器。只有元素數(shù)量超過N時才切換到堆上的動態(tài)緩沖區(qū)。這種“先棧后堆”的設(shè)計并不是什么新發(fā)明很多語言的標準庫也有類似機制但LLVM把它做到了極致——它會根據(jù)實際使用場景調(diào)整緩沖區(qū)大小而且在臨界點處的切換是平滑且可預測的不會出現(xiàn)棧上滿后突然劇烈變慢的情況。在實際編譯器代碼里這種設(shè)計的收益非常直觀。比如遍歷某個函數(shù)的所有基本塊你拿到的基本塊列表可能只有兩三個也可能有幾十個。用SmallVector的情況下絕大多數(shù)情況永遠不會觸發(fā)堆分配整個遍歷過程就是純粹的棧操作加指針movecache友好度極高。我在做推理優(yōu)化的時候會不自覺地把這套思路遷移過去對于一個小batch的激活張量與其在每一次forward循環(huán)里重新分配內(nèi)存不如在棧上預留一個足夠大的buffer只有超限時才落入緩存池。2.3 PointerUnion和TypeSwitch用內(nèi)存布局省下判斷成本再聊一個容易被忽視但極其實用的設(shè)計PointerUnion。它本質(zhì)上是在一個指針大小的空間里同時表達“這是一個什么類型”和“指向哪個對象”兩個信息。LLVM中大量使用PointerUnion的場景是某些節(jié)點要么是A類型要么是B類型兩者互斥。傳統(tǒng)做法是用一個枚舉標記類型再配一個void*指針指向?qū)ο筮@樣至少要兩個word的空間還會有對齊和判空的開銷。PointerUnion利用“指針本身天然會有對齊位空閑”的特點把類型標記塞進指針的低位或特殊位里只用一個word就能完成類型判斷和取值的雙重任務(wù)。這個設(shè)計思想如果單拿出來說可能讓人覺得只是個小技巧。但在編譯器這種高頻分支判斷的環(huán)境里節(jié)省一次內(nèi)存訪問和一次分支預測失敗的代價換來的是整個pass執(zhí)行時間的顯著下降。更重要的是它啟示我們內(nèi)存布局本身可以作為信息的載體而不一定非要額外冗余一個字段。大模型推理中很多算子融合的思路其實也是這個邏輯——把多個中間tensor的元信息合并到一個統(tǒng)一描述里減少結(jié)構(gòu)體間的解引用鏈從而提升訪存效率。3. LLVM內(nèi)存管理機制的核心邏輯數(shù)據(jù)結(jié)構(gòu)只是表象真正撐起整套體系的是LLVM對內(nèi)存生命周期的獨特管理方式。這一節(jié)我會把最核心的幾個機制串起來講清楚重點放在它們的設(shè)計動因上。3.1 為什么LLVM偏愛“按值傳遞”而非“共享所有權(quán)”現(xiàn)代C代碼里std::shared_ptr幾乎成了“內(nèi)存安全”的默認答案。但在LLVM的代碼庫里你很少看到shared_ptr。大量接口選擇的是按值傳遞對象配合move語義來傳遞所有權(quán)。這里面的邏輯并不復雜。編譯器的數(shù)據(jù)結(jié)構(gòu)往往呈圖狀——指令之間互相引用基本塊與基本塊之間形成CFG類型系統(tǒng)里存在復雜的遞歸定義。如果使用引用計數(shù)來管理這些節(jié)點的生命周期那么每當圖中新增一條邊或刪除一條邊都要同步調(diào)整引用計數(shù)這不僅會產(chǎn)生大量原子操作開銷還會在圖中出現(xiàn)環(huán)時造成內(nèi)存泄漏。LLVM的選擇是在明確的“所有權(quán)邊界”內(nèi)使用值語義而在跨越邊界時使用裸指針加顯式的setParent關(guān)系由更上層的容器統(tǒng)一負責生命周期。這也解釋了為什么LLVM的很多API不返回shared_ptr而是返回一個預期生命周期較長的裸指針或引用。調(diào)用者默認約定這個對象由某個owner持有你只是臨時借用。這種約定在編譯器這種層次清晰、邊界明確的系統(tǒng)里比引用計數(shù)更高效、更可預測。我在推理框架側(cè)也用類似思路管理tensor的懶加載和持久化權(quán)重——張量的存儲不屬于某一個算子的調(diào)用幀而屬于整個推理會話的“圖級owner”算子在執(zhí)行時只做borrow不去影響生命周期。3.2 allocator的定制化與BumpPtrAllocator的精妙定制化allocator是LLVM內(nèi)存管理里最硬核、也最值得向其他領(lǐng)域遷移的部分。其中BumpPtrAllocator也叫競技場分配器是我認為最優(yōu)雅的實現(xiàn)之一。它的思想極其樸素一次性從系統(tǒng)申請一大塊內(nèi)存然后內(nèi)部維護一個游標指針后續(xù)每次分配只需要把游標向前移動size字節(jié)并做一下對齊。釋放呢不支持單個釋放要么整體清空要么在棧式層級上進行rollback。這個機制在編譯器場景里大放異彩的原因是編譯一個函數(shù)的過程中會創(chuàng)建大量臨時對象這些對象的生命周期往往嵌套——進入一個pass時創(chuàng)建一批pass結(jié)束時整體消亡。用BumpPtrAllocator整個過程的分配成本只是指針移動析構(gòu)成本幾乎為零釋放只是一次游標重置。這種分配方式有幾個極其重要的工程細節(jié)對齊處理、內(nèi)存碎片的天然規(guī)避、以及分配順序的cache友好性。因為BumpPtrAllocator的內(nèi)存是連續(xù)分布的因此同一批次分配出來的對象在物理上相鄰遍歷時CPU cache命中率會遠高于從堆里隨機分配出來的對象。這一點和推理框架里常用的arena內(nèi)存池如出一轍——許多框架在同一個推理step里分配的臨時tensor都來自同一個緩存池就是想讓它們的地址盡量緊湊。引用計數(shù)在這種體系里沒有用武之地——因為你根本不需要關(guān)注單個對象的釋放時機整個arena的生命周期才是唯一的、確定性的邊界。這也是我剛才強調(diào)的“同構(gòu)性”的真正內(nèi)涵。3.3 RAII在編譯器源碼中的嵌入式應(yīng)用BumpPtrAllocator和RAII真正結(jié)合起來才顯現(xiàn)威力。在LLVM的pass框架里一個pass往往會通過一個scope guard或者一個自定義的SaveAndRestore工具類在進入時創(chuàng)建一個arena層級在離開時通過析構(gòu)函數(shù)自動恢復arena游標位置。這種做法讓編譯器源碼里出現(xiàn)了大量看似“魔法”的代碼一組對象在新的arena棧上創(chuàng)建一旦離開某個scope所有對象自動失效不需要顯式清理也不會有遺漏。RAII在這里不是資源管理的簡單包裝而是充當了一個“生命周期編譯器”——讓原本需要手工維護的分配/釋放配對變成結(jié)構(gòu)性的必然。我看到很多做數(shù)據(jù)處理的人對RAII的理解停留在“析構(gòu)函數(shù)釋放資源”這個層面但LLVM的用法更進了一步它把RAII延伸到“邏輯分層的開始與結(jié)束”。這在大模型推理的顯存管理中能直接套用——一個decode step的臨時張量區(qū)域就是一個scopestep結(jié)束時統(tǒng)一回滾一個layer的前向計算又是一個子scopelayer內(nèi)部創(chuàng)建的中間激活區(qū)域在這個子scope結(jié)束時回收。用RAII把step和layer的邊界硬編碼到代碼結(jié)構(gòu)里你幾乎不會再出現(xiàn)臨時張量泄漏的問題。4. 大模型推理的內(nèi)存模型與LLVM的對應(yīng)關(guān)系現(xiàn)在把話題拉回到大模型推理。很多人覺得推理框架的內(nèi)存管理不外乎malloc/free或者最多加個緩存池。但真實情況遠復雜于此——一個多層的Transformer運行起來每個token生成步驟都伴隨大量中間張量的創(chuàng)建和銷毀同時還要維持KV Cache這種跨步驟的持久結(jié)構(gòu)以及連續(xù)batch拼接時動態(tài)變化的形狀。4.1 KV Cache的分配與生命周期管理KV Cache是自回歸生成里最核心的顯存消費者。對于每個序列每一層都需要保存過去所有token的Key和Value向量。隨著生成過程的推進KV Cache是動態(tài)增長的——每生成一個新token就要在每一個層里追加一小段張量。如果采用樸素方案每新增一個token就重新malloc一塊更大內(nèi)存然后memcpy舊數(shù)據(jù)進去那么生成幾千個token之后總復制時間會呈平方增長整個推理會卡到無法接受。這里就是LLVM的SmallVector和BumpPtrAllocator思想可以直接遷移的地方。一種常見的工程實踐是按block為單位預分配KV Cacheblock大小固定比如每個block能存64個token的KV。推理時預留一批空閑block每當新token到來就往當前block的空槽里寫。block寫滿之后再從空閑池里取下一個。這種策略和BumpPtrAllocator的“預先一塊大內(nèi)存游標移動分配”完全一致差別只是游標移動的粒度是block而非字節(jié)。這樣做的好處非常明顯第一分配次數(shù)急劇減少從每個token一次malloc變成幾十個token才取一個新block第二數(shù)據(jù)在物理內(nèi)存上的連續(xù)性大幅提升GPU顯存訪問有更好的局部性第三生命周期邊界清晰——block一旦從空閑池取出并分配給某個序列就只屬于這個序列直到序列停止生成才整體歸還不存在碎片化的釋放順序。KV Cache這種“長生命周期、動態(tài)增長但預先池化”的對象確實是小對象優(yōu)化之外的另一類經(jīng)典場景。4.2 中間激活張量的臨時分配與arena復用除了KV Cache大模型推理中更頻繁也更隱蔽的是中間激活張量的分配。每過一層Transformer就會有attention輸出、MLP中間結(jié)果、LayerNorm后的歸一化張量等。這些張量很少跨出當前層的計算邊界它們只服務(wù)于當前層的feed-forward過程。很多推理框架會把這一批張量放進一個“臨時工作區(qū)”本質(zhì)上就是套用arena的思路。工作區(qū)按當前seq_len * hidden_size對齊一次性分配足夠容納單層激活的最大buffer。每次前向計算時張量直接在buffer上切片view用完不釋放下一次復用。我在實際優(yōu)化中會發(fā)現(xiàn)如果不用這種策略而是讓每個算子自行分配輸出張量那么一次生成步驟里會觸發(fā)數(shù)十甚至上百次cudaMalloc。cudaMalloc本身很慢而且顯存碎片化嚴重更容易導致OOM。換成arena復用后一次推理session最多做兩三次“按需增長”的大塊分配剩下所有中間張量都在arena內(nèi)切片不僅速度提升明顯顯存峰值也下降了一大截。這不正是SmallVector里“棧上預留、堆上擴容”策略在GPU顯存層的翻版嗎區(qū)別只是數(shù)據(jù)規(guī)模從幾個元素變成了幾千兆字節(jié)。4.3 連續(xù)批處理與PointerUnion式的元信息壓縮連續(xù)批處理continuous batching為了保證高質(zhì)量調(diào)度需要跟蹤每個序列的當前長度、是否已完成、KV Cache被分配到了哪個block以及一個個非常離散的元信息。許多框架為了優(yōu)化這些信息的訪存會把可能同時存在的狀態(tài)字段壓縮到一個結(jié)構(gòu)體里。這時PointerUnion給我們的啟示就很關(guān)鍵為什么不把“當前狀態(tài)”和“當前數(shù)據(jù)指針”放在同一個word里比如某個字段要么表示“正在等待輸入”要么表示“指示器指向的某個數(shù)據(jù)塊”那就可以用低位標志區(qū)分。雖然現(xiàn)代硬件對這種位運算的開銷已經(jīng)不敏感但密集調(diào)度器里每一個結(jié)構(gòu)體的縮小都會減少cache miss次數(shù)大量序列并行時這是一個很實在的收益。不過要說明的是PointerUnion的這套手段在推理框架里通常不會做得那么底層——因為大部分跑在GPU上的代碼是沒法直接玩指針低位的。但這個思想轉(zhuǎn)譯成“元數(shù)據(jù)聚攏”是成立的把調(diào)度所需的少量標志位塞進連續(xù)排布的numpy數(shù)組或結(jié)構(gòu)體數(shù)組里讓整個調(diào)度器的工作集壓縮到幾十個cache line內(nèi)性能就能獲得肉眼可見的提升。5. 實操手記在推理加速中落地這些內(nèi)存思路光聊理論不夠我挑一個我在模擬項目X里做的小優(yōu)化來展示具體操作路徑。這個項目是一個輕量級的大模型推理Demo跑在某國產(chǎn)加速卡上需要處理動態(tài)長度的并發(fā)請求。優(yōu)化前它的TPS不算差但顯存峰值經(jīng)常逼近卡的上限而且生成進行到一半時會出現(xiàn)偶發(fā)性的顯存不足。排查后發(fā)現(xiàn)大部分問題都出在內(nèi)存管理上。5.1 用“分層arena”重構(gòu)臨時張量分配我做的第一件事是給推理框架增加一個“分層臨時分配器”。整體結(jié)構(gòu)參考了LLVM pass的scope機制每次decode step開始進入一個頂層arena scope每層Transformer的前向函數(shù)進入一個子scope子scope結(jié)束時自動回滾arena游標到該層起始位置。這樣做的關(guān)鍵收益不只是分配本身變快更是讓生命周期變得有跡可循。原來每個tensor的釋放需要調(diào)用者手動管理代碼里到處是漏洞?，F(xiàn)在開發(fā)者只需要把中間變量聲明為arena張量剩下的釋放全部交給scope退出時的游標回滾。和RAII的SaveAndRestore如出一轍。具體實現(xiàn)上我參照BumpPtrAllocator的做法維護了一個全局“arena chunk鏈表”chunk的大小區(qū)分為幾個檔次小chunk給單層激活用中等chunk給attention分數(shù)矩陣用大chunk給左右拼接的中間buffer用。分配時通過一個可配置的對齊參數(shù)一般是512字節(jié)對齊到cache line大小避免奇怪的地址錯位。實測下來最明顯的改善是cudaMalloc類型的調(diào)用從每step幾十次降到每step可能一次都沒有顯存峰值也降低了約27%。5.2 按block池化的KV Cache改造第二件事是KV Cache從“按seq動態(tài)增長”改成“block池化”。我們觀察到的規(guī)律是推理負載的序列長度分布非常分散短的可能只有幾十個token長的可能到上千。如果按最大長度預分配每條序列的KV Cache顯存浪費很大如果按需增長又會頻繁觸發(fā)大的顯存分配。block池化方案里我設(shè)定block大小是64個token的KV每塊大小固定。空閑block掛在一個簡單的無鎖隊列上序列需要時就取一個生成結(jié)束時整塊歸還到隊列末尾。這種方案和LLVM SmallVector的增長邏輯本質(zhì)上是一回事——減少分配次數(shù)控制內(nèi)存增長的粒度讓對象在物理層面盡量連續(xù)。需要注意的是block池化之后KV Cache的地址空間可能不再連續(xù)直接帶來一個不小的問題注意力計算時的矩陣乘法無法一次性加載整條序列的KV需要按block做分塊處理。為了規(guī)避這個問題我把block池設(shè)計成兩層L0池連續(xù)塊較大用于單條長序列L1池小block用于短序列和突發(fā)請求。這樣既保證了80%情況下的連續(xù)訪存又不會浪費整體顯存。5.3 生命周期追蹤表的運維視角做大模型推理優(yōu)化光有分配策略是不夠的你還必須知道“當前哪個對象活著、哪個對象已經(jīng)無效”。我在框架里添加了一張生命周期追蹤表記錄每個arena chunk當前屬于哪個step、哪個layer、哪個序列。這張表平時開銷極低——只需要一個哈希表key是chunk地址value是五個整型字段。調(diào)試時它能幫我把OOM的時間點精確到具體的layer和sequence而不必靠日志海撈。它相當于LLVM源碼里常見的統(tǒng)計斷言和Debug驗證工具平時不開啟但一旦內(nèi)存相關(guān)的bug出現(xiàn)立刻能定位到是“哪一步?jīng)]有歸還哪個arena”。這類跟蹤工具讓我意識到一件事內(nèi)存管理的工程化不只是設(shè)計一個更好的分配策略還要設(shè)計一套與之匹配的可觀測手段。分配器的行為可以被運行時統(tǒng)計actor模型也好arena模型也好沒有觀測手段就很難持續(xù)地調(diào)優(yōu)。6. 常見問題速查從編譯器和推理框架兩側(cè)踩過的坑我把這幾個月里真實踩過的、以及幫別人排過的典型問題整理成一張速查表。這些問題有的是LLVM ADT使用層面的有的是推理框架側(cè)內(nèi)存管理層面的但很多坑背后的根因驚人地一致。現(xiàn)象可能的根因排查方向和經(jīng)驗LLVM SmallVector擴容后迭代器失效忽略了內(nèi)聯(lián)緩沖區(qū)到堆緩沖區(qū)的切換會使指針失效擴容前保留index而不是pointer或者用reserve預分配避免在遍歷中途擴容BumpPtrAllocator管理的對象出現(xiàn)野指針對象被析構(gòu)后arena整體空間變成了未初始化區(qū)域明確對象生命周期邊界在scope退出后絕對禁止再引用arena內(nèi)對象不要試圖“部分釋放”推理時顯存碎片導致的偶發(fā)OOM每個算子獨立分配臨時張量未做池化/arena復用減少分配次數(shù)按生命周期層級集中分配必要時啟用顯存整理KV Cache按需增長時頻繁大塊分配增長粒度過小或未預分配改為block池化讓block大小匹配典型序列長度分布調(diào)試時觀察分配次數(shù)而非只看總顯存連續(xù)批處理調(diào)度器cache miss高序列元信息分散在多個孤立結(jié)構(gòu)體把調(diào)度相關(guān)的關(guān)鍵字段壓縮到連續(xù)內(nèi)存的元數(shù)據(jù)數(shù)組里類似PointerUnion的聚攏思想引用計數(shù)圖狀結(jié)構(gòu)導致析構(gòu)循環(huán)在編譯器圖或推理計算圖中使用shared_ptr管理帶環(huán)引用改用“明確的owner 借用”模式由最外層圖表統(tǒng)一管理生命周期這張表里每個條目都值得展開但我更想強調(diào)的是其中共通的方法論任何一個優(yōu)化問題先問“對象的生命周期是誰定義的”再問“分配的規(guī)模與頻率是多少”最后問“釋放的時機可以推遲到哪一級”。把這三個問題回答清楚內(nèi)存方案的大方向就錯不了。7. 從LLVM抽象到領(lǐng)域遷移的個人體會做這個項目的時候我一直在想為什么LLVM作為編譯器基礎(chǔ)庫它的ADT和內(nèi)存管理機制能在大模型推理里找到如此直接的映射?，F(xiàn)在我的理解是凡是層層嵌套、生命周期分層清晰、對分配延遲和內(nèi)存碎片極度敏感的系統(tǒng)最終都會收斂到類似的設(shè)計范式。編譯器有pass pipeline的嵌套結(jié)構(gòu)推理框架有step/layer的嵌套結(jié)構(gòu)編譯器用BumpPtrAllocator管理一次編譯過程中的短命對象推理框架用顯存arena管理一次forward的中間激活編譯器用SmallVector照顧小容器的高頻使用推理框架用block池照顧動態(tài)長度的KV Cache編譯器用PointerUnion壓縮類型與指針信息推理框架用緊湊元數(shù)據(jù)數(shù)組壓出cache line里的最后一點性能。這些不是巧合而是同一種工程哲學在不同問題空間里的必然顯現(xiàn)。如果你現(xiàn)在正在某個性能敏感的領(lǐng)域做優(yōu)化我建議你系統(tǒng)地啃一遍LLVM的ADT源碼——不必全部讀通只要把SmallVector、StringRef、PointerUnion、BumpPtrAllocator這幾個核心類的實現(xiàn)讀懂就能獲得一套比STL更鋒利的思考工具。帶著這套工具再回來看推理框架、數(shù)據(jù)庫引擎或是網(wǎng)絡(luò)協(xié)議棧你會發(fā)現(xiàn)自己能一眼看出它們內(nèi)存設(shè)計中的關(guān)鍵取舍。按我個人的經(jīng)驗與其把時間花在反復調(diào)參上不如先花兩周時間把這些底層設(shè)計思想吃透后面遇到的很多所謂性能問題其實都會變成“早該想到”的布局問題。這篇隨筆算是一次思路梳理后續(xù)我會繼續(xù)寫LLVM里其他值得遷移的設(shè)計模式也歡迎有類似實踐經(jīng)驗的朋友一起交流。