IT咨詢顧問的關鍵抓手-DeepSeek+企業架構-快速的熟悉和洞察一個新的行業
所以在上一篇文章中，我也只能無奈選擇退回到V0引擎的版本。聽聞有些技術能力強的大廠哥哥們已經搞定了這個問題，這個確實佩服，點贊??！起初在部署起來的時候是非常讓人興奮的，簡單看了一下VLLM后臺的日志，每秒的生成速度在21-30之間波動，人肉平均一下就是25tokens/s左右（沒有詳細測，人肉估計），人肉檢測首個token返回時間大概在1.8s-1.9s左右，已經達到了跟官網網頁上的速度類似的速度。但是隨著開放使用之后，問題就來了，在處理長上下文的時候（4k以上），出現了一種偶發性的降速，并且這個請求直到處理完之前，都會一直保持1 tokens/s以下。
在中可以看到所有GPU的利用率會直接沖到100%，直到這個超卡的請求全部生成完，才會恢復正常。實體感受就像一個人前一秒在口若懸河的瘋狂吹牛，下一秒他突然就卡殼了。如果單純只是這一個請求卡住了，那么影響的是這一個人的使用，倒還勉強能接受。可惜的是接下來進來的每一個請求都會非常慢，有一種一個壞學生把全班的好學生都教壞了的既視感??。如果長prompt無法使用，那么就注定在RAG這個企業內部最常用的AI場景出現了死局。
鑒于上述問題，希望有感興趣的大佬也可以來指導我一下，感激不盡，我這邊也會和開源社區繼續研究推理引擎，把這個問題解決掉。馬斯克說，很多即使很優秀的工程師都會在已有的路徑上持續去優化一個也許不該存在問題，這就是路徑依賴。通往羅馬的路不止只有一條，解決問題的辦法也可以是讓問題本身不存在。VLLM就是我的路徑依賴，因為太熟悉也太好用，所以一開始就直接選擇了他抱著這樣的想法我們再來回頭重新審視問題重新找到Deepseek的官方倉庫：https://github.com/deepseek-ai/DeepSeek-V3可以看到除了第一個以外，Deepseek推薦的第一個是一個叫作SGLang的推理引擎。
查看這個引擎的文檔清晰的寫到：SGLang從一開始就在與Deepseek團隊深度合作，完成了Deepseek V3的適配工作，并且給出的詳細的部署步驟。大佬之間的已經達成深度合作了，那還有啥好說的呢？直接開測！
部署文檔可見：https://github.com/sgl-project/sglang/tree/main/benchmark/deepseek_v3
有了這個，我們只需要重新調整一下部署腳本，把相應的Deepseek V3換成Deepseek R1即可（tokennizer是一樣的，所以可以通用）在兩個節點上分別執行下面的命令，過一會就看得到
神奇的事情就自然而然的發生了，引擎一次性啟動成功并且經過測試，token的生成速度達到了31+tokens/s，較原方案大幅提升了20%+
經過一天多的使用，也沒有再次出現過降速和卡頓的問題。
一個大模型系統，從直觀感受來目測系統響應速度有兩個點
單個請求TTFT首先簡單用one-api去測試一下系統的反應，首次未命中緩存時，大概在1.9s左右，后續命中緩存的情況下，降低到只有0.43秒。
針對TTFT的測試：隨機生成16/256/1024/2048/4096/8192/16384/32768/65536個隨機token來當做輸入prompt，模擬在不同長度輸入的場景下，用戶能接收到的第一個字符的平均等待時間，時間越短，用戶見到第一個token速度越快。
這里可以看到一個非常有趣的現象，在長度為8192個token之前的TTFT增長曲線是比較平緩的，到8192之后陡然上升，而且呈現一個很有意思的趨勢16384是8192的2倍，5.11接近2.94的2倍；32769是8192的4倍，11.78接近2.94的4倍；貌似是一個線性的增長關系，這個8192就是一個比較有趣的數字。這時候回頭再看系統在啟動過程中打印的日志中包含了這樣一個數字，那么大概率這里就跟這個chunked_prefill_size有關。
8 * H100了，直接拉大來提升速度就會是一個不錯的優化選擇，具體的優化細節我們有機會再來討論。
Output Thoughput token/s上文已經提到過，單個請求的輸出速度基本保持在了31-32token/s之間，肉眼可見的快速。
并發TTFT這次我們使用1024個隨機輸入token，對模型的進行10/20/30/40/50/100并發進行測試，來看分別在不同并發量的情況下，token最大的生成速度和TTFT。
可以看到當并發請求上到超過50并發時，系統的等待時間已經超過10秒了，這時候給人的感覺已經是很慢了，再往上拉高并發數量也基本失去了意義。Output Thoughput token/s這塊基本上就是純屬娛樂一下了系統的最大吞吐量，當以1024個隨機token輸入，500并發時出現將近1192.06token/s（當然這個數據只是估算出來的，并沒有太多實際的價值）。
在我們使用默認參數的情況下，能看到日志中最大可以處理的請求數量為78。
這個參數在默認的時候是沒有設置的，Deepseek給出的推薦值如下圖所示。
在完成Deepseek-r1的部署之后，我們發現的VLLM中可能存在的潛在問題目前無法解決，隨后替換成了SGLang來暫時讓系統達到可用狀態。接下來對整個系統進行了一系列的測試，在測試過程中發現了很多有意思的參數設置，比如
個人能力有限，本次測試的效果可能不能代表最真實的生產環境，肯定有很多大佬的優化效果更好，望指正或許/沒準/Perhaps，下次我們拿村里的大學生組合，華為昇騰再來折騰折騰？？
大家都在看的硬核博主技術分享真·生產級滿血版Deepseek-r1 671B部署實例
原文轉載自：https://mp.weixin.qq.com/s/b8R8r7SbG0HRq9wdbhqGRQ
