TL;DR

春節(jié)假期開始, 好像很多人都在開始卷DeepSeek-R1的推理了. 渣B也被兄弟團(tuán)隊(duì)帶著一起卷了一陣, 其實(shí)推理中還有很多約束, 比較認(rèn)同的是章老師的一個(gè)觀點(diǎn): “推理框架很有可能就此走向兩種極致分化的方向.“ 本文來做一個(gè)詳細(xì)的闡述, 從一些亂七八糟的benchmark開始, 然后談?wù)劀y試方法, 推理系統(tǒng)的各種約束, 推理框架的區(qū)別, 并行策略的區(qū)別,然后再解構(gòu)一下DeepSeek的原廠方案.

1. 前情回顧
2. 推理性能指標(biāo)概述
3. 推理系統(tǒng)性能約束
3.1 用戶SLA的約束
3.2 內(nèi)存的約束
4.約束帶來的分叉
5. 私有化部署
5.1 基于SGLang
5.2 基于vLLM
5.3 并行策略選擇
6. 平臺(tái)部署
6.1 PD分離技術(shù)
6.2 Prefill階段
6.3 Decode階段
7. 未來優(yōu)化的方向和對開源生態(tài)的建議

1. 前情回顧

比較現(xiàn)實(shí)的是兩個(gè)極端, 一方面是各種平臺(tái)的測評, 例如公眾號(hào)“CLUE中文語言理解測評基準(zhǔn)”的

《DeepSeek-R1 網(wǎng)頁端穩(wěn)定性首測：12家第三方平臺(tái)真實(shí)測評》

另一方面是尤洋老師在微博的一個(gè)評論MaaS的商業(yè)模式和平臺(tái)推理虧損, 這里提到了4臺(tái)H800的總吞吐量

另一方面是各種私有化部署的需求, 例如小紅書上最近經(jīng)常刷到還有章明星老師的KTransformer可以在單卡的4090 24GB上配合Intel CPU的AMX部署Q4的量化版本. 通過將Routed Expert放置在CPU上運(yùn)行來降低內(nèi)存的使用量.

還有直接ollama找一個(gè)1TB內(nèi)存的CPU實(shí)例就開跑的方案.

然后Benchmark的定義上,一會(huì)兒20 Tokens/s, 一會(huì)兒又是幾千Tokens/s的benchmark滿天飛, 到底是怎么回事? 其實(shí)有很多認(rèn)知的問題, 讓渣B回憶起剛畢業(yè)入職工作的時(shí)候做運(yùn)營商級(jí)的電話信令網(wǎng)關(guān)時(shí), 天天測性能算Erlang模型的日子...

2. 推理性能指標(biāo)概述

推理是一個(gè)在線業(yè)務(wù), 因此對第一個(gè)Token出來的延遲(Time To First Token,TTFT)和后續(xù)token產(chǎn)生的延遲(Time Per output Token,TPOT)都會(huì)對用戶體感產(chǎn)生影響.

通常會(huì)使用測試工具生成如下一個(gè)報(bào)告, 具體數(shù)據(jù)就不多說了.

影響這個(gè)報(bào)告的因素很多, 例如測試工具是采用vllm的benchmark_serving還是采用sglang.bench_serving, 常用的參數(shù)是按照多少Request per seconds(RPS)測試或者按照多少并發(fā)量進(jìn)行測試, 但是DeepSeek-R1的推理Reasoning時(shí)間很長, 通常都會(huì)選擇并發(fā)數(shù)進(jìn)行約束.測試在一定的并發(fā)數(shù)量下的吞吐/延遲等指標(biāo). 測試命令如下所示:

###vLLM的bench測試
python3~/vllm/benchmarks/benchmark_serving.py--backendvllm
--model~/deepseek-R1--port8000
--dataset-namerandom
--random-input1234
--random-output2345
--random-range-ratio0.8
--dataset-path~/ShareGPT_V3_unfiltered_cleaned_split.json
--max-concurrency16
--num-prompts64

###sglangM的bench測試
python3-msglang.bench_serving--backendvllm
--model~/deepseek-R1--port8000
--dataset-name=random--random-input=1234
--random-output=2345
--max-concurrency=64
--num-prompts=128
--random-range-ratio0.9
--dataset-path~/ShareGPT_V3_unfiltered_cleaned_split.json

除了并發(fā)數(shù)max-concurrency以外, 另兩個(gè)比較重要的參數(shù)是input多少token和output多少token, 這也是非常影響測試結(jié)果的. DeepSeek-R1作為一個(gè)Reasoning模型, 輸出Thinking階段的token也挺多的, 所以要根據(jù)實(shí)際的業(yè)務(wù)需要來進(jìn)行分析.

因?yàn)橐郧伴L期做運(yùn)營商級(jí)的呼叫信令網(wǎng)關(guān), 對于請求到達(dá)是否按照Poisson過程, 對于結(jié)果的影響也很大, 這是一個(gè)非常重要的點(diǎn), sglang的bench例如并發(fā)128時(shí), 就是128個(gè)請求一起發(fā)出去了, 然后大家一起Prefill, 然后一起decode,這樣可能導(dǎo)致TTFT偏長. 而vllm的測試是如果設(shè)置并發(fā)時(shí)是按照Poisson過程請求的. 但是似乎做的也不太符合真實(shí)的情況.

3. 推理系統(tǒng)性能約束

主要的約束有幾個(gè)方面:

3.1 用戶SLA的約束

通常我們可以根據(jù)實(shí)際業(yè)務(wù)的需求獲得平均輸入Token數(shù)和輸出Token數(shù)以及方差, 然后根據(jù)企業(yè)員工的數(shù)量或者承載用戶的DAU計(jì)算出一個(gè)平均請求到達(dá)間隔, 然后根據(jù)一些SLA的約束, 例如TTFT首Token時(shí)間要小于4s, TPOT即用戶感知的每秒token輸出速度, 例如要大于20Token/S(TPS).然后再來估計(jì)用戶平均對一個(gè)請求的整體持續(xù)時(shí)間, 通過Erlang模型建模.

但是很多時(shí)候性能和成本之間會(huì)有一些取舍, 例如是否在一個(gè)低成本方案中,放寬對TTFT和TPOT的要求, 慢一點(diǎn)但是足夠便宜就好, 或者是另一方面例如袁老師的硅基流動(dòng), Pro版本就能夠嚴(yán)格保證用戶的SLA, 也就是夏Core講的, 穩(wěn)定保持TPOT > 20TPS、

但是為了保證API平臺(tái)的SLA, 通常需要采用更復(fù)雜的并行策略, 降低延遲提高吞吐, 例如DeepSeek論文提到的EP320的 40臺(tái)機(jī)器的集群方案.

3.2 內(nèi)存的約束

對于較長的Context,KVCache對顯存的占用也特別大, 雖然單機(jī)的H20顯存也能放得下滿血版的671B模型,但是剩余的顯存也會(huì)約束到模型的并發(fā)能力. 通常有些提供API的廠家會(huì)配置一個(gè)截?cái)? 例如最大長度就8192個(gè)Tokens. 通常在這種場景下為了提高并發(fā), 最小配置都會(huì)用2臺(tái)以上的H20, 或者一些MI300的實(shí)例, 國外還有一些會(huì)采用H200的實(shí)例.

4.約束帶來的分叉

正如前一章節(jié)所屬, 兩個(gè)約束帶來了分叉. 一方面用戶希望低成本的私有化部署,帶來了一些小型化部署的機(jī)會(huì), 例如小紅書上看到的, 200w如何私有化部署滿血版. 另一方面是大規(guī)模的云平臺(tái)提供服務(wù)的時(shí)候保障SLA.

這兩者直接決定了部署上的區(qū)別:

私有化部署: 2臺(tái)4臺(tái)并行小規(guī)模滿足成本的需求, 而不太在意TTFT和TPOT的需求, 能夠滿足企業(yè)內(nèi)并發(fā)需求即可,甚至是季宇老師提到的一個(gè)極端的情況,就只做一個(gè)并發(fā)時(shí), 如何用最低成本的硬件實(shí)現(xiàn)大概10~20TPS.

平臺(tái)部署: 最小320卡到最大數(shù)千數(shù)萬卡并行的需求, 這種需求下并發(fā)的請求數(shù)量, KVCache的用量和累計(jì)整個(gè)集群的TFTT和TPOT的約束都非常大, 因此需要在并行策略上進(jìn)行更多的考慮, 例如EP并行還有PD分離等.

很多較小的提供商通常只有開源軟件sglang和vllm的部署能力, 然后并行策略上只有非常局限的TP/PP選擇, 因此只有2~4臺(tái)機(jī)器并行一組的方式提供服務(wù), 自然就會(huì)遇到一些成本過高,吞吐過低無法通過token收費(fèi)掙錢的情況. 這也就是所謂的夾在中間非常難受的一個(gè)例子.

因此章明星老師講的這兩種部署帶來的推理系統(tǒng)分叉將會(huì)成為一個(gè)必然趨勢.

5. 私有化部署

通常的做法是買兩臺(tái)H20或者在云上租用2臺(tái)H20構(gòu)建一個(gè)最小部署集, 然后自建的方式來部署.

5.1 基于SGLang

基于Sglang的部署方式如下, 兩臺(tái)機(jī)器安裝sglang

pipinstallsgl-kernel--force-reinstall--no-deps
pipinstall"sglang[all]>=0.4.2.post3"--find-linkshttps://flashinfer.ai/whl/cu124/torch2.5/flashinfer/

第一臺(tái)機(jī)器執(zhí)行時(shí), nnodes=2, node-rank=0, dist-init-addr都是第一臺(tái)機(jī)器的IP地址.

python3-msglang.launch_server
--model-path~/deepseek-R1/
--tp16--dist-init-addr1.1.1.1:20000
--nnodes2--node-rank0
--trust-remote-code--host0.0.0.0--port8000

第二臺(tái)機(jī)器執(zhí)行時(shí),--nnodes 2 --node-rank 1

python3-msglang.launch_server
--model-path~/deepseek-R1/
--tp16--dist-init-addr1.1.1.1:20000
--nnodes2--node-rank1
--trust-remote-code--host0.0.0.0--port8000

需要注意的是,現(xiàn)階段Sglang只支持TP并行, PP并行在未來幾周可能會(huì)支持.

5.2 基于vLLM

vLLM需要基于Ray部署, 如下圖所示:

首先需要安裝Ray

pip3installray

然后第一臺(tái)機(jī)器配置

raystart--head--dashboard-host0.0.0.0

第二個(gè)機(jī)器根據(jù)第一個(gè)機(jī)器的提示輸入加入集群

raystart--address=':6379'

然后檢查集群狀態(tài)

raystatus
========Autoscalerstatus:2025-02-071906.335568========
Nodestatus
---------------------------------------------------------------
Active:
1node_50018fxxxxx
1node_11cc6xxxxx
Pending:
(nopendingnodes)
Recentfailures:
(nofailures)

Resources
---------------------------------------------------------------
Usage:
0.0/256.0CPU
0.0/16.0GPU
0B/1.59TiBmemory
0B/372.53GiBobject_store_memory

Demands:
(noresourcedemands)

然后兩臺(tái)機(jī)器都安裝vllm, 注意需要安裝最新版的vllm 0.7.2性能有很大提升.

pip3installvllm

最后在第一臺(tái)機(jī)器上開啟服務(wù)即可, 然后需要根據(jù)容忍的最大輸入和模型輸出調(diào)整max-num-batched-tokens和max-model-len

vllmserve~/deepseek-R1
--tensor-parallel-size16
--enable-reasoning
--reasoning-parserdeepseek_r1
--max-num-batched-tokens8192
--max-model-len16384
--enable-prefix-caching
--trust-remote-code
--enable-chunked-prefill
--host0.0.0.0

單個(gè)輸入的測試腳本如下

#test.py
fromopenaiimportOpenAI

#ModifyOpenAI'sAPIkeyandAPIbasetousevLLM'sAPIserver.
openai_api_key="EMPTY"
openai_api_base="http://localhost:8000/v1"

client=OpenAI(
api_key=openai_api_key,
base_url=openai_api_base,
)

models=client.models.list()
model=models.data[0].id

#Round1
messages=[{"role":"user","content":"whatisthepresheaf?andhowtoproveyonedalemma?"}]
response=client.chat.completions.create(model=model,messages=messages)

reasoning_content=response.choices[0].message.reasoning_content
content=response.choices[0].message.content

print("reasoning_content:",reasoning_content)
print("content:",content)

5.3 并行策略選擇

如果選擇sglang,當(dāng)前只有TP并行策略, 因此需要為每個(gè)GPU配置400Gbps網(wǎng)卡構(gòu)成雙機(jī)3.2Tbps互聯(lián), 這是一筆不小的開銷. 當(dāng)然TP并行理論上說在Token generate的速度上會(huì)有優(yōu)勢, 但事實(shí)上和vLLM新版本的PP并行差距并不大. 相反TP并行的SGlang在Prefill階段的性能還是有很大問題的, TTFT比起PP并行的vLLM很多場景下慢了一倍.

而vLLM更推薦PP并行, 主要是壓根就不需要RDMA網(wǎng)絡(luò), 就CPU上插一張網(wǎng)卡即可, 同時(shí)KV Cache的容量和吞吐都有提升. 特別是KVCache, 比起TP并行省了很多, 對于私有化部署提高并發(fā)很有好處.

有一篇關(guān)于vLLM 0.7.2優(yōu)化的分析文章[1]其中提到

具體分析一下兩種并行方式, PP并行也就是在模型的中間按層分開, 按照一個(gè)Token hidden-dim 7168和FP8計(jì)算, 如果每秒吞吐為1000個(gè)token, 則累積的帶寬需求為7MB/s 即便是Prefill階段需要5000tokens/s的能力,也就35MB/s, 一般一張100Gbps的網(wǎng)卡就夠了.

而TP并行在Sglang中的實(shí)現(xiàn)是采用了對MLA進(jìn)行DP并行, 每張卡維護(hù)不同Seq的KVCache, 并分別通過DP worker完成prefill/decode一類的任務(wù), 從而相對于TP并行節(jié)省KVCache開銷, 然后再進(jìn)行一次allgather 讓不同的卡都拿到hidden-state進(jìn)行MoE的計(jì)算.

但是官方的文檔[2]似乎并沒有開啟這種模式, 而是采用標(biāo)準(zhǔn)的TP并行, 這樣每個(gè)卡都要有全量的kvcache.

綜合來看, 從私有化部署的成本來考慮, 選擇vLLM或者未來支持pp并行的Sglang是一個(gè)更好的選擇. 性能差距很小的情況下,省掉了一個(gè)專用的GPU RDMA網(wǎng)絡(luò)的成本還是非常好的, 而且也適合企業(yè)部署, 隨便找個(gè)機(jī)柜放兩臺(tái), CPU的網(wǎng)卡接交換機(jī)上即可,無需特別的維護(hù). 另一方面伴隨著兩三個(gè)星期以后兩個(gè)框架都支持了MTP, 應(yīng)該整體性能還有進(jìn)一步的提升.

另外針對這樣的小規(guī)模兩機(jī)部署,通常會(huì)采用Chunk-Prefill的技術(shù), 將Prefill的計(jì)算拆分成chunk穿插在Decode任務(wù)中, 來避免同一個(gè)卡運(yùn)行Prefill和Decode時(shí), 兩階段的資源爭搶干擾會(huì)導(dǎo)致TTFT和TPOT都很難達(dá)到SLA的標(biāo)準(zhǔn).

6. 平臺(tái)部署

平臺(tái)部署,更多的就要參考Deepseek-V3的論文了. DeepSeek首先采用了PD分離的技術(shù).

6.1 PD分離技術(shù)

當(dāng)Prefill和Decode兩個(gè)階段在同一個(gè)卡上運(yùn)行時(shí), 兩階段的資源爭搶干擾會(huì)導(dǎo)致TTFT和TPOT都很難達(dá)到SLA的標(biāo)準(zhǔn). 例如突然來一個(gè)很長的prompt的請求需要大量的計(jì)算資源來進(jìn)行prefill運(yùn)算, 同時(shí)也需要大量的顯存來存儲(chǔ)這個(gè)請求的KV Cache.針對Prefill Compute-Bound計(jì)算和Decode Memory-bound計(jì)算的特點(diǎn), 以及不同卡的算力差異, 出現(xiàn)了Prefill-Decode分離的架構(gòu), 即用高算力的卡做Prefill, 低算力的卡做Decode, 并且Prefill節(jié)點(diǎn)在完成計(jì)算傳輸KV Cache給Decode節(jié)點(diǎn)后就可以free掉本地顯存.

分離后的延遲和性能(來自論文DistServe), 可以看到在滿足SLA的條件下, 分離后的性能會(huì)更好.

在PD分離架構(gòu)下, 可以分別針對Compute-bound和Memory-bound進(jìn)行有針對性的優(yōu)化. 例如對請求的batch處理, Prefill階段由于每個(gè)token都要計(jì)算,當(dāng)batch中的總token數(shù)達(dá)到計(jì)算瓶頸門限后, 吞吐率就趨于平緩了. 而在Decode階段隨著batchsize增大可以顯著的增加吞吐率

6.2 Prefill階段

預(yù)填充階段的最小部署單元由4個(gè)節(jié)點(diǎn)和32個(gè)GPU組成。

Attention block 采用4路張量并行（TP4）與序列并行（SP）結(jié)合，并輔以8路數(shù)據(jù)并行（DP8）。其較小的TP尺寸為4，限制了TP通信的開銷。

對于MoE部分，使用32路專家并行（EP32），確保每個(gè)專家處理足夠大的批量大小，從而提升計(jì)算效率。對于MoE的all-to-all通信，采用與訓(xùn)練時(shí)相同的方法：首先通過InfiniBand（IB）在節(jié)點(diǎn)間傳輸token，然后通過NVLink在節(jié)點(diǎn)內(nèi)的GPU之間轉(zhuǎn)發(fā)。

特別地，在最開始三層的 Dense MLP中使用1路張量并行，以節(jié)省TP通信開銷。

為了實(shí)現(xiàn)MoE部分中不同專家之間的負(fù)載均衡，需要確保每個(gè)GPU處理大致相同數(shù)量的token。為此，引入了冗余專家的部署策略，通過復(fù)制高負(fù)載專家并冗余部署它們來達(dá)到這一目的。高負(fù)載專家是基于在線部署期間收集的統(tǒng)計(jì)數(shù)據(jù)檢測出來的，并會(huì)定期調(diào)整（例如每10分鐘一次）。在確定冗余專家集合后，會(huì)根據(jù)觀察到的負(fù)載，在節(jié)點(diǎn)內(nèi)的GPU之間精心重新安排專家，盡可能在不增加跨節(jié)點(diǎn)alltoall通信開銷的情況下，實(shí)現(xiàn)GPU之間的負(fù)載均衡。在DeepSeek-V3的部署中，為預(yù)填充階段設(shè)置了32個(gè)冗余專家。對于每個(gè)GPU，除了其原本負(fù)責(zé)的8個(gè)專家外，還會(huì)額外負(fù)責(zé)一個(gè)冗余專家。

此外，在預(yù)填充階段，為了提高吞吐量并隱藏alltoall和TP通信的開銷，采用了兩個(gè)計(jì)算量相當(dāng)?shù)膍icro-batches，將一個(gè)micro ba t ch的Attention和MoE計(jì)算與另一個(gè)microbatch的Disptach和Combine操作overlap。

另外,論文還提到了他們正在探索動(dòng)態(tài)的專家冗余策略, 即每個(gè)GPU負(fù)責(zé)更多的專家（例如16個(gè)專家），但在每個(gè)推理步驟中只激活其中的9個(gè)。在每一層的AlltoAll操作開始之前，動(dòng)態(tài)計(jì)算全局最優(yōu)的路由方案.

6.3 Decode階段

在Decode階段, 將Shared Expert和其它Routed Expert一視同仁. 從這個(gè)角度來看，每個(gè)token在路由時(shí)會(huì)選擇9個(gè)專家，其中共享專家被視為一個(gè)高負(fù)載專家，始終會(huì)被選中。解碼階段的最小部署單元由40個(gè)節(jié)點(diǎn)和320個(gè)GPU組成。注意力部分采用TP4與SP結(jié)合，并輔以DP80，而MoE部分則使用EP320。在MoE部分，每個(gè)GPU僅負(fù)責(zé)一個(gè)專家，其中64個(gè)GPU專門用于托管冗余專家和共享專家。

需要注意的是, dispatch和combine部分的AlltoAll通信通過IB的直接點(diǎn)對點(diǎn)傳輸實(shí)現(xiàn)，以降低延遲。此外，還利用IBGDA技術(shù)進(jìn)一步最小化延遲并提升通信效率,即直接利用GPU構(gòu)建RDMA隊(duì)列和控制網(wǎng)卡doorbell

與Prefill階段類似, 基于在線服務(wù)的統(tǒng)計(jì)專家負(fù)載，定期確定冗余專家的集合。然而，由于每個(gè)GPU僅負(fù)責(zé)一個(gè)專家，因此不需要重新安排專家的位置。同時(shí)也在探索解碼階段的動(dòng)態(tài)冗余策略。不過，這需要對計(jì)算全局最優(yōu)路由方案的算法以及與Dispatch Kernel的融合進(jìn)行更細(xì)致的優(yōu)化，以減少開銷。

此外，為了提高吞吐量并隱藏AlltoAll通信的開銷，還在探索在解碼階段同時(shí)處理兩個(gè)計(jì)算工作量相似的microbatch。與預(yù)填充階段不同，解碼階段中Attention計(jì)算占據(jù)了更大的時(shí)間比例。因此，需要將一個(gè)Microbatch的注意力計(jì)算與另一個(gè)microbatch的Dispatch+MoE+Combine操作Overlap。

在Decode階段，每個(gè)專家的批量大小相對較小（通常在256個(gè)token以內(nèi)），瓶頸在于內(nèi)存訪問而非計(jì)算。由于MoE部分只需加載一個(gè)專家的參數(shù)，內(nèi)存訪問開銷極小，因此使用較少的SM不會(huì)顯著影響整體性能。因此，為了避免影響Attention block的計(jì)算速度，可以僅為Dispatch+MoE+Combine分配一小部分SMs。

其實(shí)DeepSeek的工作已經(jīng)做的非常細(xì)致了, 例如Prefill階段通過兩個(gè)microbatch來隱藏attention和MoE的A2A和TP通信開銷. 并且通過冗余專家來降低Alltoall開銷, 而在Decode階段并沒采用原來的訓(xùn)練中那樣的PXN方式, 而是采用了直接p2p IB通信的方式, 并啟用了IBGDA降低延遲. 對于一個(gè)大集群來看, 使用這些優(yōu)化比起尤洋老師估計(jì)的每臺(tái)機(jī)器400tokens/s的量, 應(yīng)該起碼高出20~50倍.

7. 未來優(yōu)化的方向和對開源生態(tài)的建議

私有化部署和平臺(tái)部署將會(huì)帶來推理生態(tài)的分叉, 在雙機(jī)部署或者未來大內(nèi)存的單機(jī)部署下, 可能更多的是考慮片上網(wǎng)絡(luò)如何高效的互聯(lián), 例如帶AMX的CPU來做MoE而輔助一些TensorCore做Attention Block, 例如GB200 NVL4這樣的單機(jī)推理平臺(tái)

或者就是極致的,像Apple M4那樣的Unified Memory, 帶一些NPU, 或者例如Project Digits那樣的GB10的chip, 然后做到大概10萬人民幣能夠完成滿血版671B的部署, 這些單U的服務(wù)器或許也逐漸會(huì)成為云服務(wù)提供商的主力機(jī)型. 另一方面最近在做一些R1-Zero的復(fù)現(xiàn)和算法分析相關(guān)的事情, 覺得似乎這樣的一些小規(guī)模集群對于強(qiáng)化學(xué)習(xí)RLFT也可能成為一個(gè)很好融合的機(jī)會(huì). 例如4臺(tái)~8臺(tái)的小規(guī)模集群做一些垂域的模型蒸餾等, 這個(gè)市場會(huì)逐漸打開.

對于這些小機(jī)器, 內(nèi)存通常受限的, 是否可以做一個(gè)雙向加載?例如論文《Compute or Load KV Cache? Why not both?》采用了雙向fill的機(jī)制, 從最后一個(gè)token開始倒著向前讀取KV-Cache, 然后前向從第一個(gè)Token開始進(jìn)行KVCache計(jì)算, 直到兩個(gè)過程交匯.

而另一個(gè)方向, 是大集群的MaaS/SaaS服務(wù)提供, 通信和計(jì)算的Overlap,計(jì)算集群的負(fù)載均衡等, 當(dāng)然首先還是要一些開源生態(tài)先去把一些EP并行框架的問題解決了才有后續(xù), 當(dāng)然我個(gè)人是一直比較看好vLLM+Ray的部署的, Ray本身和計(jì)算節(jié)點(diǎn)的負(fù)載以及內(nèi)存的ojbect抽象其實(shí)蠻好的, 其實(shí)在看《Infinite-LLM: Efficient LLM Service for Long Context with DistAttention and Distributed KVCache》的工作, 在多個(gè)實(shí)例間共享內(nèi)存實(shí)現(xiàn)分布式的KV-Cache存儲(chǔ).

還有一些很細(xì)致的內(nèi)存管理的工作, 例如GMLake/vTensor等...進(jìn)一步解決它的一些通信延遲后, 可能和其它在線業(yè)務(wù)融合是一個(gè)蠻大的優(yōu)勢.而另一方面Sglang也非常厲害, 前期性能超過vLLM很多.

更進(jìn)一步,作為PaaS的基于SLA的調(diào)度還有很多工作和機(jī)會(huì)可以去做. 例如KVCache的存儲(chǔ)和優(yōu)化. 其實(shí)每個(gè)做推理的PaaS或許都應(yīng)該下場參與到開源生態(tài)中, 例如當(dāng)年的Spark.

當(dāng)然還有一些更細(xì)節(jié)的內(nèi)容涉密就不多說了, 宏觀說幾點(diǎn)吧....從算子層來看, Group GEMM的細(xì)粒度打滿TensorCore, Warp specialization的處理, 如何統(tǒng)一ScaleUP和ScaleOut network, 如何更加容易的融入到現(xiàn)在的在線鏈路上? 然后這些RL模型是否可以逐漸做到按天的夜間FineTune白天上線快速迭代等?

最最后一條, 當(dāng)前MoE性能的優(yōu)化主要還是在AlltoAll, 優(yōu)化的方式并不是說, ok, 因?yàn)檠舆t敏感需要一個(gè)更低延遲的網(wǎng)絡(luò)通信, 而是如何通過一些microbatch等調(diào)度策略, 保證在一定通信延遲門限下能夠足夠的隱藏延遲.

舉個(gè)例子吧, DeepSeek為什么Decode階段要采用P2P直接RDMA通信,而不是像訓(xùn)練那樣采用PXN呢? 其實(shí)在一定的SLA約束下, ScaleUP的帶寬和延遲并不是那么極致的需求, 相反如何scaleOut, 才是關(guān)鍵. 這樣就會(huì)導(dǎo)致一個(gè)潛在的問題, 例如采用Multi-Rail或者Rail-Only的組網(wǎng),可能由于Expert的放置和過載, 需要跨越不同機(jī)器的不同Rank通信. IBGDA可能只是一個(gè)暫時(shí)的方案, 是否會(huì)因?yàn)檫@些新的需求, 又回到傳統(tǒng)的CLOS架構(gòu), 放棄Rail-based部署呢? 特別是Decode階段的延遲問題處理上, 假設(shè)未來部署的集群專家并行規(guī)模大幅度提升呢? 這就成為一個(gè)軟硬件協(xié)同的很有趣的問題了, 建議算法團(tuán)隊(duì)和一些有硬件能力的團(tuán)隊(duì)更加緊密的合作, 算法對硬件妥協(xié), 硬件進(jìn)一步解鎖...

再進(jìn)一步, 正如DeepSeek論文所示, Dynamic Routing, Experts placement也是一個(gè)很有趣的話題. 而DeepSeek對于未來硬件的建議也非常清楚的擺在那里了, 后面隨著推理的規(guī)模上量, 各個(gè)云之間卷推理成本而提高性能的事情

結(jié)論: 加大一些開源生態(tài)的投入吧:) 自己卷, 卷不過生態(tài)的.

參考資料 [1]

Enhancing DeepSeek Models with MLA and FP8 Optimizations in VLLM: https://neuralmagic.com/blog/enhancing-deepseek-models-with-mla-and-fp8-optimizations-in-vllm/

[2]

deepseek-v3-sglang: https://github.com/sgl-project/sglang/tree/main/benchmark/deepseek_v3#example-serving-with-2-h208