SOSP 的 Session 1A 開(kāi)場(chǎng)就是 Model Serving at Scale這個(gè)安排本身就很能說(shuō)明問(wèn)題。這幾年我和團(tuán)隊(duì)一直在做 LLM 推理服務(wù)化眼看著這個(gè)方向從AI 實(shí)驗(yàn)室里的小工具變成了真正意義上的系統(tǒng)軟件——調(diào)度、緩存、資源池化、故障恢復(fù)每一個(gè)話題都回到了操作系統(tǒng)研究的老本行。這個(gè) Session 值得逐篇細(xì)看不只是因?yàn)檎撐谋旧矶且驗(yàn)樗姓故玖苏麄€(gè)行業(yè)在規(guī)模化部署大模型推理時(shí)的真實(shí)瓶頸和解決思路。這篇文章我按自己的理解把 Session 1A 的幾條主線拆開(kāi)講包含對(duì)系統(tǒng)設(shè)計(jì)的分析、對(duì)工程落地的思考以及我自己在部署過(guò)程中踩過(guò)的坑。如果你也在做模型服務(wù)化或者正準(zhǔn)備上手搭推理平臺(tái)這些內(nèi)容應(yīng)該能幫你省不少時(shí)間。1. 為什么 Model Serving at Scale 值得單獨(dú)開(kāi)一場(chǎng)先把背景說(shuō)清楚。SOSP 一直是以操作系統(tǒng)、存儲(chǔ)、分布式系統(tǒng)見(jiàn)長(zhǎng)的頂會(huì)往年這類會(huì)議上的工作大多是文件系統(tǒng)、內(nèi)存管理、一致性協(xié)議?，F(xiàn)在 Model Serving 能占一個(gè) Session說(shuō)明學(xué)術(shù)界已經(jīng)達(dá)成了一個(gè)共識(shí)大模型推理瓶頸不再是模型精度而是系統(tǒng)效率。1.1 從跑通模型到規(guī)?；?wù)的轉(zhuǎn)折過(guò)去一年里行業(yè)里能穩(wěn)定對(duì)外提供大模型推理服務(wù)的團(tuán)隊(duì)基本都遇到了相同的問(wèn)題。單機(jī)單卡跑一個(gè) 7B 模型很容易但一旦要支持幾百路并發(fā)請(qǐng)求、上下文長(zhǎng)度動(dòng)輒幾十 k token、還有嚴(yán)格的響應(yīng)時(shí)間要求問(wèn)題立刻變成資源調(diào)度問(wèn)題。GPU 顯存怎么分、請(qǐng)求怎么排隊(duì)、cache 怎么復(fù)用、負(fù)載怎么均衡這些都不是 PyTorch 或者 Transformer 庫(kù)能解決的。Session 1A 里的工作本質(zhì)上就是在回答一個(gè)問(wèn)題當(dāng)模型推理變成基礎(chǔ)服務(wù)操作系統(tǒng)的那套方法論——調(diào)度、緩存、隔離、容錯(cuò)——要怎么遷移到 GPU 上。1.2 這個(gè) Session 的三條核心主線我把分場(chǎng)論文歸納成三個(gè)方向方便理解。調(diào)度與批處理解決怎么讓 GPU 一直有事干。連續(xù)批處理、chunked prefill、請(qǐng)求級(jí)優(yōu)先級(jí)這些都是圍繞吞吐和延遲的博弈。狀態(tài)管理解決KV Cache 放哪里、怎么復(fù)用。涉及顯存管理、跨請(qǐng)求復(fù)用、緩存淘汰策略。資源池化解決多 GPU、多節(jié)點(diǎn)如何協(xié)同。包括 prefill/decode 分離、異構(gòu)調(diào)度、彈性伸縮。這三條線不是孤立的好的系統(tǒng)設(shè)計(jì)通常同時(shí)處理多個(gè)問(wèn)題。后面我逐個(gè)展開(kāi)。2. 全景拆解Session 1A 的四條技術(shù)主線這一節(jié)把分場(chǎng)的內(nèi)容按主題做一個(gè)總覽。如果你只想要一個(gè)速覽結(jié)論今年的模型服務(wù)研究已經(jīng)從單卡優(yōu)化全面轉(zhuǎn)向集群協(xié)同所有論文都在試圖打破單機(jī)資源上限。2.1 主線一調(diào)度與批處理調(diào)度是模型服務(wù)系統(tǒng)的心臟。早期推理服務(wù)用靜態(tài)批處理請(qǐng)求來(lái)了先湊一批再一起算延遲高、利用率低。vLLM 提出的 PagedAttention 是一次突破但它解決的是顯存管理問(wèn)題真正讓吞吐大幅提升的是連續(xù)批處理continuous batching——每個(gè) step 動(dòng)態(tài)決定哪些請(qǐng)求進(jìn)入計(jì)算不用等整批結(jié)束。今年的論文在連續(xù)批處理基礎(chǔ)上又往前走了一步。請(qǐng)求級(jí)搶占、優(yōu)先級(jí)隊(duì)列、prefill 分塊調(diào)度這些都是為了讓調(diào)度器有更細(xì)的控制粒度。我的看法是未來(lái)的調(diào)度器會(huì)越來(lái)越像 CPU 調(diào)度器只是時(shí)間片換成了 token 計(jì)算步。2.2 主線二KV Cache 的狀態(tài)管理KV Cache 是模型服務(wù)里最系統(tǒng)的部分。一個(gè) 7B 模型生成長(zhǎng)度為 4096 的響應(yīng)KV Cache 占的顯存可能比模型權(quán)重還大。緩存怎么分配、怎么換出、怎么在請(qǐng)求之間復(fù)用直接決定了單卡能并行處理多少請(qǐng)求。這一方向的代表作就是 PagedAttention把 KV Cache 切成固定大小的塊用類似虛擬內(nèi)存的方式管理。后續(xù)工作在此基礎(chǔ)上做了分層緩存、壓縮緩存、跨節(jié)點(diǎn)共享。本質(zhì)上這就是把操作系統(tǒng)的頁(yè)面置換算法搬到了 GPU 顯存上。2.3 主線三Prefill/Decode 分離與池化這是今年最值得關(guān)注的方向。推理過(guò)程分兩個(gè)階段prefill計(jì)算密集和 decode訪存密集。兩個(gè)階段對(duì) GPU 資源的需求完全不同混在一起會(huì)導(dǎo)致資源浪費(fèi)。DistServe 提出的方案是把兩者拆到不同的 GPU 池各干各的Mooncake 更進(jìn)一步把 KV Cache 當(dāng)作一個(gè)可共享的存儲(chǔ)層prefill 池算完就把中間結(jié)果丟給 decode 池。分離架構(gòu)的收益很明顯但工程復(fù)雜度也很高。請(qǐng)求怎么流轉(zhuǎn)、失敗怎么恢復(fù)、兩個(gè)池的容量怎么配比都是難題。2.4 主線四性能可觀測(cè)性與 SLO 治理規(guī)?；?wù)不能只靠感覺(jué)。TTFT首 token 延遲、TPOT每 token 生成時(shí)間、端到端延遲這些指標(biāo)要能實(shí)時(shí)監(jiān)控并且要能根據(jù) SLO 自動(dòng)伸縮。相關(guān)論文給出的思路是把 SLO 作為調(diào)度器的輸入?yún)?shù)而不是事后統(tǒng)計(jì)。3. 調(diào)度細(xì)節(jié)從連續(xù)批處理到請(qǐng)求級(jí)控制調(diào)度這塊看起來(lái)簡(jiǎn)單但真做起來(lái)全是細(xì)節(jié)。我下面拆解幾個(gè)關(guān)鍵環(huán)節(jié)。3.1 為什么連續(xù)批處理成了標(biāo)配傳統(tǒng)批處理的問(wèn)題很好理解一批請(qǐng)求里最慢的那個(gè)決定了整批的結(jié)束時(shí)間。如果一批里有 8 個(gè)請(qǐng)求其中一個(gè)要生成 2000 token其他 7 個(gè)只要 50 token那這 7 個(gè)快的也得等慢的跑完。GPU 的算力大量浪費(fèi)在等待上。連續(xù)批處理的思路是每個(gè)解碼步結(jié)束后完成的請(qǐng)求立刻離開(kāi) batch新請(qǐng)求立刻補(bǔ)進(jìn)來(lái)。這樣 GPU 永遠(yuǎn)在算密度最高的批次。實(shí)測(cè)下來(lái)同樣的硬件連續(xù)批處理能把吞吐提升 2-3 倍。代價(jià)是調(diào)度器的復(fù)雜度上來(lái)了每一步都要檢查有哪些請(qǐng)求完成、新請(qǐng)求是否要搶占、KV Cache 是否夠分。3.2 Chunked Prefill 與請(qǐng)求優(yōu)先級(jí)連續(xù)批處理引入了一個(gè)新問(wèn)題prefill 階段計(jì)算量大一個(gè)長(zhǎng)請(qǐng)求的 prefill 可能會(huì)阻塞后面一排短請(qǐng)求的 decode。于是大家開(kāi)始做 chunked prefill——把 prefill 的一大段計(jì)算切成小塊穿插在 decode 步之間。這就像操作系統(tǒng)的搶占式調(diào)度長(zhǎng)任務(wù)不再獨(dú)占 CPU而是分時(shí)執(zhí)行。實(shí)際調(diào)優(yōu)中chunk 大小的選擇很講究太大導(dǎo)致 decode 延遲飆升太小又增加調(diào)度開(kāi)銷。我們團(tuán)隊(duì)的經(jīng)驗(yàn)是chunk 大小控制在 512-1024 token 之間比較穩(wěn)妥同時(shí)要給短延遲請(qǐng)求開(kāi)快車道——可以搶占低優(yōu)先級(jí)請(qǐng)求的算力。提示chunked prefill 不是銀彈。如果你的業(yè)務(wù)首 token 延遲要求極高比如低于 200ms還是要把短請(qǐng)求湊成一個(gè)獨(dú)立優(yōu)先級(jí)隊(duì)列避免被長(zhǎng) prefill 拖累。3.3 調(diào)度器里最難調(diào)的參數(shù)調(diào)度器的核心其實(shí)是三個(gè)數(shù)字的博弈TTFT、TPOT、吞吐量。想提升吞吐就得多塞請(qǐng)求進(jìn) batch但每個(gè)請(qǐng)求的 TPOT 就會(huì)變慢想降低 TTFT 就得讓請(qǐng)求快速插隊(duì)但頻繁插隊(duì)會(huì)導(dǎo)致整體吞吐下降。我給團(tuán)隊(duì)定的調(diào)優(yōu)策略是先定 SLO 紅線然后在這條線下最大化吞吐。具體做法是給請(qǐng)求分三類——交互型要求 TTFT 500ms、生成型要求 TPOT 穩(wěn)定、批處理型無(wú)所謂延遲。這三類請(qǐng)求分別走不同的隊(duì)列調(diào)度器按比例分配 GPU 時(shí)間片。4. KV Cache分層、復(fù)用與壓縮KV Cache 是模型服務(wù)的顯存大頭也是緩存系統(tǒng)的重點(diǎn)研究對(duì)象。這一節(jié)講我在讀論文和實(shí)操中理解到的核心問(wèn)題。4.1 PagedAttention 之后的世界PagedAttention 的核心貢獻(xiàn)是把 KV Cache 切成固定大小的塊通過(guò)頁(yè)表映射管理從而消除顯存碎片、支持跨請(qǐng)求共享。這個(gè)思路對(duì)顯存利用率提升非常明顯。但它的粒度是塊一個(gè)塊通常是 16 個(gè) token 的 KV這在長(zhǎng)上下文場(chǎng)景下仍有浪費(fèi)——最后一塊可能只用了幾個(gè) token。后續(xù)的優(yōu)化方向是更小的塊粒度、動(dòng)態(tài)塊大小、以及把 KV 數(shù)據(jù)壓縮到更低位寬。比如 FP8 甚至 INT4 存儲(chǔ) KV Cache配合量化感知的注意力計(jì)算。代價(jià)是精度損失但實(shí)測(cè)中大多數(shù)場(chǎng)景的生成質(zhì)量影響很小可以接受。4.2 跨請(qǐng)求共享與語(yǔ)義緩存不同用戶問(wèn)什么是 KV Cache前面幾層網(wǎng)絡(luò)prompt 前綴是完全相同的。如果每次請(qǐng)求都重新算一遍 prefill浪費(fèi)十分嚴(yán)重。RadixAttentionSGLang 的核心思想把 KV Cache 按公共前綴組織成樹(shù)結(jié)構(gòu)新請(qǐng)求能直接復(fù)用已有緩存跳過(guò)重復(fù)計(jì)算。這在共享前綴命中率高的場(chǎng)景收益極大比如聊天機(jī)器人的 system prompt、RAG 的固定檢索頭。但要注意緩存容量管理——樹(shù)結(jié)構(gòu)緩存需要配套的淘汰機(jī)制LRU 是最基礎(chǔ)的更高級(jí)的是按未來(lái)復(fù)用概率做加權(quán)淘汰。緩存策略適用場(chǎng)景命中率提升復(fù)雜度普通 LRU通用場(chǎng)景一般低Radix Tree 前綴復(fù)用固定 system prompt高中語(yǔ)義緩存相似問(wèn)題聚類高高需要 embedding 匹配分層緩存多 GPU 集群較高高4.3 緩存淘汰的權(quán)衡緩存淘汰最大的坑是你沒(méi)法預(yù)知哪個(gè) KV Cache 會(huì)被復(fù)用。有些請(qǐng)求只是偶爾重復(fù)一次占著大量顯存有些用戶的高頻請(qǐng)求卻因?yàn)槿萘坎粔虮粨Q出下次又要重算 prefill。我的建議是淘汰策略不要只看訪問(wèn)時(shí)間要結(jié)合請(qǐng)求頻率、前綴長(zhǎng)度、是否來(lái)自高價(jià)值用戶來(lái)綜合打分。另外考慮把冷 KV Cache 下移到 CPU 內(nèi)存或遠(yuǎn)端存儲(chǔ)而不是直接丟棄。雖然從 CPU 拉回 GPU 有帶寬開(kāi)銷但相比重算 prefill通常還是劃算的。5. Prefill/Decode 分離與資源池化的實(shí)戰(zhàn)思考分離式架構(gòu)是今年討論熱度最高的話題也是實(shí)際操作中收益和坑并存的方向。5.1 為什么非拆不可一個(gè) LLM 請(qǐng)求的 prefill 階段是計(jì)算密集的GPU 的算力能跑滿但顯存帶寬需求低decode 階段則反過(guò)來(lái)每個(gè) token 只需要做一次小矩陣乘大量時(shí)間花在讀顯存上。把兩個(gè)階段混在同一批里GPU 一會(huì)兒算到冒煙一會(huì)兒又閑得等顯存調(diào)度效率很低。分離架構(gòu)把 prefill 和 decode 交給不同的 GPU 池處理。prefill 池用高算力 GPUdecode 池用大顯存 GPU各得其所。請(qǐng)求先到 prefill 池算出 KV Cache然后 KV Cache 傳到 decode 池繼續(xù)生成。理論吞吐可以提升數(shù)倍。5.2 分離架構(gòu)的工程代價(jià)聽(tīng)起來(lái)很美但工程實(shí)現(xiàn)遠(yuǎn)比想象復(fù)雜。KV Cache 傳輸帶寬是硬瓶頸。一個(gè) 32K 上下文的 KV Cache 大約有幾百 MB跨節(jié)點(diǎn)傳輸本身就是延遲大頭。請(qǐng)求分配策略難調(diào)。prefill 池和 decode 池的比例要根據(jù)業(yè)務(wù)特征動(dòng)態(tài)調(diào)整今天聊天請(qǐng)求多明天長(zhǎng)文生成請(qǐng)求多比例不對(duì)就會(huì)一邊忙死一邊閑著。故障恢復(fù)復(fù)雜。decode 池里的請(qǐng)求可能依賴 prefill 池傳過(guò)來(lái)的中間結(jié)果prefill 池故障意味著要追溯重算。我的建議是如果單集群規(guī)模不大比如少于 32 卡不要輕易上分離架構(gòu)。先把連續(xù)批處理和緩存復(fù)用做到位通常就能解決 80% 的吞吐問(wèn)題。分離架構(gòu)是為了沖更高規(guī)模上限的手段不是起點(diǎn)。5.3 池化調(diào)度的核心指標(biāo)一旦決定做資源池化就要盯著幾個(gè)關(guān)鍵指標(biāo)看池間隊(duì)列深度如果 prefill 池的隊(duì)列深度長(zhǎng)期高于 decode 池說(shuō)明 prefill 能力不足要加卡。KV Cache 傳輸耗時(shí)占比這個(gè)占比超過(guò) 20%說(shuō)明網(wǎng)絡(luò)帶寬是瓶頸考慮壓縮 KV 或走共享顯存。池內(nèi)空閑率min(池 A 空閑, 池 B 空閑) 越低越好。如果經(jīng)常出現(xiàn)一邊空轉(zhuǎn)一邊排隊(duì)說(shuō)明池比例沒(méi)調(diào)對(duì)。6. 落地實(shí)操讀完論文后的部署經(jīng)驗(yàn)論文給的是思路落地全是細(xì)節(jié)。分享一些我在實(shí)踐中獲得的經(jīng)驗(yàn)希望能幫你少走彎路。6.1 論文指標(biāo)和生產(chǎn)指標(biāo)不是一回事論文里通常報(bào)告吞吐量tokens/s、首 token 延遲等指標(biāo)但它們大多數(shù)是在特定數(shù)據(jù)集上測(cè)的前綴緩存命中率可能很高batch 里的請(qǐng)求分布也和你的業(yè)務(wù)不一樣。生產(chǎn)環(huán)境要關(guān)心的是有效吞吐——滿足 SLO 的那些請(qǐng)求的吞吐而不是理論吞吐。我見(jiàn)過(guò)不少團(tuán)隊(duì)被論文數(shù)字吸引上線后實(shí)測(cè)只有論文數(shù)據(jù)的 30%。原因幾乎都是兩類業(yè)務(wù)請(qǐng)求長(zhǎng)度分布跟論文數(shù)據(jù)集差異大或者高峰期的并發(fā)波動(dòng)把調(diào)度器打懵了。所以用你自己的真實(shí)流量做壓測(cè)建立基線指標(biāo)再找優(yōu)化點(diǎn)。6.2 架構(gòu)選型建議根據(jù)集群規(guī)模和業(yè)務(wù)場(chǎng)景我給一個(gè)簡(jiǎn)單直接的建議表規(guī)模場(chǎng)景推薦架構(gòu)理由單機(jī) 1-4 卡內(nèi)部工具、小流量vLLM 連續(xù)批處理簡(jiǎn)單可靠夠用單機(jī) 8 卡中等流量、RAG獨(dú)立 prefill/decode 分離利用多卡異構(gòu)優(yōu)勢(shì)多機(jī)多卡高并發(fā)、多租戶池化 KV Cache 共享存儲(chǔ)彈性伸縮資源效率高混合云流量波動(dòng)大Serverless 自動(dòng)伸縮成本最優(yōu)但要解決冷啟動(dòng)如果流量比較平穩(wěn)那不一定要上復(fù)雜的池化架構(gòu)如果流量有早晚高峰那就要提前規(guī)劃彈性擴(kuò)縮。調(diào)度器的自動(dòng)伸縮觸發(fā)條件建議用排隊(duì)長(zhǎng)度而不是 GPU 利用率因?yàn)?GPU 利用率往往有滯后。6.3 部署監(jiān)控的最小清單做推理服務(wù)下面這些指標(biāo)缺一不可請(qǐng)求級(jí)TTFT、TPOT、尾延遲P99系統(tǒng)級(jí)GPU 利用率、顯存占用、KV Cache 命中率隊(duì)列級(jí)每類請(qǐng)求的排隊(duì)長(zhǎng)度、平均等待耗時(shí)資源級(jí)CPU/內(nèi)存/網(wǎng)絡(luò)帶寬尤其是跨節(jié)點(diǎn) KV Cache 傳輸帶寬我習(xí)慣把 TTFT 和排隊(duì)長(zhǎng)度放在同一張圖上。只要隊(duì)一長(zhǎng)TTFT 必然跟著漲這時(shí)候靠加卡解決不了問(wèn)題——得看是不是調(diào)度策略把長(zhǎng)請(qǐng)求和短請(qǐng)求混在一起了。7. 高頻問(wèn)題排查記錄把幾個(gè)我反復(fù)遇到、也最適合拿來(lái)說(shuō)明系統(tǒng)原理的問(wèn)題整理成速查表?，F(xiàn)象可能原因排查思路解決建議TTFT 忽高忽低長(zhǎng)請(qǐng)求 prefill 阻塞看調(diào)度日志檢查 chunk 大小拆 prefill 塊或啟用長(zhǎng)請(qǐng)求單獨(dú)隊(duì)列GPU 利用率高但吞吐低decode 階段顯存帶寬受限看解碼步的平均耗時(shí)檢查 KV Cache 是否壓縮降低數(shù)據(jù)讀取量KV Cache 頻繁換出緩存容量不足看命中率曲線增加顯存份額或引入 CPU 分層緩存多節(jié)點(diǎn)時(shí)吞吐上不去KV 傳輸帶寬瓶頸看節(jié)點(diǎn)間網(wǎng)絡(luò)占用壓縮 KV、減少跨節(jié)點(diǎn)請(qǐng)求自動(dòng)伸縮反復(fù)抖動(dòng)伸縮閾值太敏感看隊(duì)列長(zhǎng)度變化增大冷靜周期用加權(quán)移動(dòng)平均7.1 典型場(chǎng)景一TTFT 突然從 300ms 飆到 2 秒排查思路分三步。第一步看有沒(méi)有大請(qǐng)求進(jìn)來(lái)第二步看調(diào)度器是否啟用了連續(xù)批處理但 prefill 沒(méi)分塊第三步看請(qǐng)求是否都擠進(jìn)了同一個(gè)邏輯隊(duì)列。我遇到過(guò)最隱蔽的問(wèn)題是緩存命中率突然下降導(dǎo)致 prefill 計(jì)算量翻倍緩存沒(méi)失效但用戶請(qǐng)求的 prompt 模板變了前綴全部 miss。7.2 典型場(chǎng)景二加了卡吞吐沒(méi)變化這通常說(shuō)明瓶頸不在算力而在別處。可能是 KV Cache 傳輸網(wǎng)絡(luò)帶寬打滿、也可能是調(diào)度器單點(diǎn)成了瓶頸。你應(yīng)該做的第一件事是看吞吐曲線的增長(zhǎng)坡度如果是線性走平就需要檢查各環(huán)節(jié)的隊(duì)列深度。7.3 典型場(chǎng)景三長(zhǎng)上下文請(qǐng)求把緩存打爆長(zhǎng)上下文的 KV Cache 動(dòng)輒幾個(gè) GB一個(gè)并發(fā)稍高就填滿顯存。解法有兩類一類是限制單請(qǐng)求最大上下文長(zhǎng)度另一類是給長(zhǎng)請(qǐng)求設(shè)獨(dú)立的池避免它們擠占普通請(qǐng)求的緩存空間。后一種更推薦因?yàn)橐坏肚邢拗崎L(zhǎng)度會(huì)傷用戶體驗(yàn)。8. 寫在最后一些個(gè)人觀察Session 1A 這一整場(chǎng)看下來(lái)我最大的感受是模型服務(wù)正在快速操作系統(tǒng)化。調(diào)度、緩存、隔離、池化、容錯(cuò)——這些詞本來(lái)就是操作系統(tǒng)教材里的核心章節(jié)現(xiàn)在它們?cè)诖竽Ｐ屯评韴?chǎng)景里重新煥發(fā)了生命力。我的第二個(gè)觀察是論文給出的系統(tǒng)設(shè)計(jì)越來(lái)越復(fù)雜但工業(yè)界實(shí)際部署時(shí)越簡(jiǎn)單的系統(tǒng)越容易成功。你可以先從一個(gè)單機(jī)版的連續(xù)批處理做起把監(jiān)控和排障體系建好再逐步迭代到池化架構(gòu)。系統(tǒng)復(fù)雜度和團(tuán)隊(duì)維護(hù)能力要匹配否則論文里漂亮的設(shè)計(jì)會(huì)變成生產(chǎn)事故的來(lái)源。如果你正在搭建模型推理服務(wù)建議盯著兩個(gè)指標(biāo)P99 TTFT 和有效吞吐。把這兩個(gè)指標(biāo)排在所有優(yōu)化工作之前就不會(huì)跑偏。至于緩存復(fù)用、prefill 分塊這些技術(shù)細(xì)節(jié)都屬于怎么讓這兩個(gè)指標(biāo)更好的工具箱按需取用就好。我個(gè)人在實(shí)操中還有一個(gè)習(xí)慣每篇相關(guān)論文讀完不急著改架構(gòu)先畫一張當(dāng)前系統(tǒng)瓶頸在哪的圖把論文方案和我們的瓶頸對(duì)照。很多論文確實(shí)優(yōu)秀但它解決的瓶頸你可能還沒(méi)遇到先確認(rèn)自己真的卡在哪一層再?zèng)Q定要不要借鑒。這樣既能避免過(guò)度設(shè)計(jì)也能在真正遇到瓶頸時(shí)知道該從哪個(gè)方向找答案。