四虎影院永久免费,永久免费视频v片www,草莓视频一区二区精品

所以在上一篇文章中，我也只能無奈選擇退回到V0引擎的版本。聽聞有些技術(shù)能力強(qiáng)的大廠哥哥們已經(jīng)搞定了這個問題，這個確實(shí)佩服，點(diǎn)贊??！起初在部署起來的時候是非常讓人興奮的，簡單看了一下VLLM后臺的日志，每秒的生成速度在21-30之間波動，人肉平均一下就是25tokens/s左右（沒有詳細(xì)測，人肉估計(jì)），人肉檢測首個token返回時間大概在1.8s-1.9s左右，已經(jīng)達(dá)到了跟官網(wǎng)網(wǎng)頁上的速度類似的速度。但是隨著開放使用之后，問題就來了，在處理長上下文的時候（4k以上），出現(xiàn)了一種偶發(fā)性的降速，并且這個請求直到處理完之前，都會一直保持1 tokens/s以下。

在中可以看到所有GPU的利用率會直接沖到100%，直到這個超卡的請求全部生成完，才會恢復(fù)正常。實(shí)體感受就像一個人前一秒在口若懸河的瘋狂吹牛，下一秒他突然就卡殼了。如果單純只是這一個請求卡住了，那么影響的是這一個人的使用，倒還勉強(qiáng)能接受。可惜的是接下來進(jìn)來的每一個請求都會非常慢，有一種一個壞學(xué)生把全班的好學(xué)生都教壞了的既視感??。如果長prompt無法使用，那么就注定在RAG這個企業(yè)內(nèi)部最常用的AI場景出現(xiàn)了死局。

二、調(diào)整思路

鑒于上述問題，希望有感興趣的大佬也可以來指導(dǎo)我一下，感激不盡，我這邊也會和開源社區(qū)繼續(xù)研究推理引擎，把這個問題解決掉。馬斯克說，很多即使很優(yōu)秀的工程師都會在已有的路徑上持續(xù)去優(yōu)化一個也許不該存在問題，這就是路徑依賴。通往羅馬的路不止只有一條，解決問題的辦法也可以是讓問題本身不存在。VLLM就是我的路徑依賴，因?yàn)樘煜ひ蔡糜茫砸婚_始就直接選擇了他抱著這樣的想法我們再來回頭重新審視問題重新找到Deepseek的官方倉庫：https://github.com/deepseek-ai/DeepSeek-V3可以看到除了第一個以外，Deepseek推薦的第一個是一個叫作SGLang的推理引擎。

查看這個引擎的文檔清晰的寫到：SGLang從一開始就在與Deepseek團(tuán)隊(duì)深度合作，完成了Deepseek V3的適配工作，并且給出的詳細(xì)的部署步驟。大佬之間的已經(jīng)達(dá)成深度合作了，那還有啥好說的呢？直接開測！

部署文檔可見：https://github.com/sgl-project/sglang/tree/main/benchmark/deepseek_v3

有了這個，我們只需要重新調(diào)整一下部署腳本，把相應(yīng)的Deepseek V3換成Deepseek R1即可（tokennizer是一樣的，所以可以通用）在兩個節(jié)點(diǎn)上分別執(zhí)行下面的命令，過一會就看得到

神奇的事情就自然而然的發(fā)生了，引擎一次性啟動成功并且經(jīng)過測試，token的生成速度達(dá)到了31+tokens/s，較原方案大幅提升了20%+

經(jīng)過一天多的使用，也沒有再次出現(xiàn)過降速和卡頓的問題。

三、壓測

一個大模型系統(tǒng)，從直觀感受來目測系統(tǒng)響應(yīng)速度有兩個點(diǎn)

當(dāng)用戶提了問題，AI給出的第一個token的延時時間，也就是常說的Time To First Token（TTFT）
每秒輸出的字符數(shù)，用來評價(jià)系統(tǒng)的吞吐量，也就是在論文里常看到的Output Thoughput token/s

單個請求TTFT首先簡單用one-api去測試一下系統(tǒng)的反應(yīng)，首次未命中緩存時，大概在1.9s左右，后續(xù)命中緩存的情況下，降低到只有0.43秒。

針對TTFT的測試：隨機(jī)生成16/256/1024/2048/4096/8192/16384/32768/65536個隨機(jī)token來當(dāng)做輸入prompt，模擬在不同長度輸入的場景下，用戶能接收到的第一個字符的平均等待時間，時間越短，用戶見到第一個token速度越快。

這里可以看到一個非常有趣的現(xiàn)象，在長度為8192個token之前的TTFT增長曲線是比較平緩的，到8192之后陡然上升，而且呈現(xiàn)一個很有意思的趨勢16384是8192的2倍，5.11接近2.94的2倍；32769是8192的4倍，11.78接近2.94的4倍；貌似是一個線性的增長關(guān)系，這個8192就是一個比較有趣的數(shù)字。這時候回頭再看系統(tǒng)在啟動過程中打印的日志中包含了這樣一個數(shù)字，那么大概率這里就跟這個chunked_prefill_size有關(guān)。

8 * H100了，直接拉大來提升速度就會是一個不錯的優(yōu)化選擇，具體的優(yōu)化細(xì)節(jié)我們有機(jī)會再來討論。

Output Thoughput token/s上文已經(jīng)提到過，單個請求的輸出速度基本保持在了31-32token/s之間，肉眼可見的快速。

并發(fā)TTFT這次我們使用1024個隨機(jī)輸入token，對模型的進(jìn)行10/20/30/40/50/100并發(fā)進(jìn)行測試，來看分別在不同并發(fā)量的情況下，token最大的生成速度和TTFT。

可以看到當(dāng)并發(fā)請求上到超過50并發(fā)時，系統(tǒng)的等待時間已經(jīng)超過10秒了，這時候給人的感覺已經(jīng)是很慢了，再往上拉高并發(fā)數(shù)量也基本失去了意義。Output Thoughput token/s這塊基本上就是純屬娛樂一下了系統(tǒng)的最大吞吐量，當(dāng)以1024個隨機(jī)token輸入，500并發(fā)時出現(xiàn)將近1192.06token/s（當(dāng)然這個數(shù)據(jù)只是估算出來的，并沒有太多實(shí)際的價(jià)值）。

在我們使用默認(rèn)參數(shù)的情況下，能看到日志中最大可以處理的請求數(shù)量為78。

這個參數(shù)在默認(rèn)的時候是沒有設(shè)置的，Deepseek給出的推薦值如下圖所示。

四、結(jié)語

在完成Deepseek-r1的部署之后，我們發(fā)現(xiàn)的VLLM中可能存在的潛在問題目前無法解決，隨后替換成了SGLang來暫時讓系統(tǒng)達(dá)到可用狀態(tài)。接下來對整個系統(tǒng)進(jìn)行了一系列的測試，在測試過程中發(fā)現(xiàn)了很多有意思的參數(shù)設(shè)置，比如

預(yù)填充（Prefill）階段分塊處理相關(guān)的性能優(yōu)化參數(shù)
最大能處理的請求在不同場景下可能影響著系統(tǒng)的延遲和吞吐能力，這將會成為我們接下來的進(jìn)行繼續(xù)優(yōu)化的目標(biāo)，感謝你看到這里，如果還有什么想看的，歡迎在評論區(qū)留言跟我交流。

個人能力有限，本次測試的效果可能不能代表最真實(shí)的生產(chǎn)環(huán)境，肯定有很多大佬的優(yōu)化效果更好，望指正或許/沒準(zhǔn)/Perhaps，下次我們拿村里的大學(xué)生組合，華為昇騰再來折騰折騰？？

大家都在看的硬核博主技術(shù)分享真·生產(chǎn)級滿血版Deepseek-r1 671B部署實(shí)例

原文轉(zhuǎn)載自：https://mp.weixin.qq.com/s/b8R8r7SbG0HRq9wdbhqGRQ