久久综合结合久久很很很97色,中文字幕不卡一区,久久青草免费91线频观看不卡

手上剛好有幾張算力還算可以的顯卡經(jīng)過一系列折騰終于完成了完整版Deepseek-r1 671B滿血版生產(chǎn)級的部署，本來就來詳細講一下。本人水平有限，部署過程中對各種設(shè)備、模型、網(wǎng)絡(luò)等內(nèi)容的理解有限，還望各位高手指正。

一、準(zhǔn)備工作

1.1 模型文件

生產(chǎn)級滿血版的Deepseek-r1，我們應(yīng)該直奔他的原版?zhèn)}庫。

huggingface的Deepseek-r1倉庫地址：https://huggingface.co/deepseek-ai/DeepSeek-R1
魔塔社區(qū)(modelscope)的Deepseek-r1倉庫地址：https://modelscope.cn/models/deepseek-ai/DeepSeek-R1

因為網(wǎng)絡(luò)的問題，我們可以通過魔塔社區(qū)去下載可能會比較快，畢竟這個模型還是很大的。這里可能需要澄清一下，網(wǎng)絡(luò)上各種文章說Deepseek-r1的文件大小有600G、700G還有1T以上可能都不是非常準(zhǔn)確。實際在linux下載后的完整版是642G。

還需要注意的是，可能大家看到的更多的是ollama官網(wǎng)的671b寫的是404G，如下圖。

這個并非不準(zhǔn)確，而是ollama提供的是一個4bit的量化版本，并非真正的滿血非量化版本。

1.2 服務(wù)器/顯卡

在這里我們準(zhǔn)備2臺8 * NVIDIA H100 80GB HBM3的服務(wù)器，并且顯卡之間用Nvlink進行連接。當(dāng)然如果有H200可能效果會更好，但是畢竟那玩意還是太稀有了。按照英偉達官網(wǎng)安裝好顯卡驅(qū)動、cuda、以及nvidia-fabricmanager，這里列出我使用的版本。

顯卡驅(qū)動版本：

cuda版本：

nvidia-fabricmanager：

這里值得注意的是，上述三個軟件版本一定要相互匹配，不然是運行不起來的。

1.3 推理引擎

模型、硬件都準(zhǔn)備好了，接下來就是軟件了。在這里我選擇了vllm作為推理引擎，地址：https://github.com/vllm-project/vllm

它與ollama類似，但是具有更高性能的特點，社區(qū)也比較活躍，有關(guān)他的詳細介紹也可以看看其他的文章。為了簡化部署和統(tǒng)一環(huán)境，我們只需要下載vLLM的docker鏡像即可。在兩臺服務(wù)器上分別執(zhí)行命令。

如果網(wǎng)絡(luò)不太好，在阿里云上也有相應(yīng)的鏡像。

到此我們所有的準(zhǔn)備工作就都做完了，接下來就可以進入部署階段了。

二、開始部署

根據(jù)vllm的部署文檔https://docs.vllm.ai/en/latest/serving/distributed_serving.html，我們首先要找到一個腳本用來做分布式推理。腳本地址：https://github.com/vllm-project/vllm/blob/main/examples/online_serving/run_cluster.sh然后在兩個不同的節(jié)點上分別執(zhí)行命令。

兩個節(jié)點均完成啟動之后，找到其中一個節(jié)點，使用

進入容器，這時候就可以執(zhí)行vllm的啟動命令了。

如果順利的話，在漫長的等待之后，就可以看到模型所有的safetensors被一個一個的加載起來。

這時我們再去找一個Chatbox、Open WebUI等圖形化工具進行一些簡單的配置，就可以對話了。

2.1 但是

但是總會有但是，部署的過程肯定不會那么順利，尤其是在多機多卡的推理場景上。用上述腳本只能勉強把模型跑起來，跑起來之后，跟官網(wǎng)上那種流暢的速度比起來簡直是千差萬別，基本上就是一個字一個字在蹦非常的慢。我們在后臺看到token的生成速度，好一點的時候可能有20+tokens/s，稍微問多一點的時候可能會掉到只有不到1tokens/s，非常的慘。

到了這里可能會懷疑為什么這么多H100還是會這么慢？因為實際上這里的瓶頸已經(jīng)不在于顯卡的算力，即使不是16張H100而是16張4090的話，算力也不是阻礙。搞過多機多卡訓(xùn)練的大佬可能就會知道，在這種場景下網(wǎng)絡(luò)帶寬才是真正限制推理速度的最大阻礙。

2.2 超高性能網(wǎng)絡(luò)-Infiniband

InfiniBand?（以下簡稱IB網(wǎng)絡(luò)）是一種專為高性能計算（HPC）和超大規(guī)模數(shù)據(jù)中心設(shè)計的網(wǎng)絡(luò)技術(shù)，以亞微秒級超低延遲和超高帶寬為核心優(yōu)勢。這里的帶寬，不是指家里的千兆網(wǎng)或者機房中的萬兆網(wǎng)（10G/s）就那么簡單，而是有接近400G/s的超高速顯卡互聯(lián)網(wǎng)絡(luò)。

在保證系統(tǒng)上安裝且啟用了IB網(wǎng)卡的情況下，我們用命令

可以看到IB網(wǎng)口的狀態(tài)。

當(dāng)確認了IB網(wǎng)絡(luò)是通暢的時候，我們需要對上述的啟動腳本進行修改，在兩個節(jié)點上分別執(zhí)行以下命令。

新增的環(huán)境變量配置，主要用于啟用IB網(wǎng)絡(luò)通信，而非使用以太網(wǎng)進行通信，詳細的每一個參數(shù)的具體含義，可以在英偉達NCCL的官方網(wǎng)站上找到說明。https://docs.nvidia.com/deeplearning/nccl/archives/nccl_2215/user-guide/docs/env.html

在完成配置之后，重新啟動vllm，就可以看到如下的效果了。

三、下一步

部署到這里，我們就得到了一個跟官網(wǎng)不卡的時候速度類似的滿血版Deepseek-r1，希望這個文檔對你有所幫助。下一步，我會對已經(jīng)完成部署的模型進行壓測，來探索系統(tǒng)的性能極限在哪里，以及如何在生產(chǎn)環(huán)境中何如進行進一步的性能優(yōu)化，期待你的關(guān)注。個人水平有限，有誤的地方望指正。

附錄

一些折騰過程中遇到的問題

RuntimeError; Nccl error; unhandled svstem error (run with NCCL DEBUG INE for deta)

這個報錯大概率是nccl配置有問題，單機多卡場景下，請按照如下思路排查。
1. 請檢查pytorch版本與nccl版本是否匹配？
2. nvidia-fabricmanager是否開啟?
3. fabricmanager的版本與顯卡驅(qū)動版本是否匹配？
4. 執(zhí)行vllm的測試腳本，https://docs.vllm.ai/en/latest/getting_started/troubleshooting.html#incorrect-hardware-driver，以確定問題出現(xiàn)在哪里。
設(shè)置了IB網(wǎng)絡(luò)，輸出還是很慢

在啟動腳本前加入NCCL_DEBUG=INFO，并檢查是否有如下日志，最關(guān)鍵的就是。

NCCL中的RDMA（遠程直接內(nèi)存訪問）通過繞過操作系統(tǒng)內(nèi)核實現(xiàn)GPU內(nèi)存直接跨節(jié)點通信，減少數(shù)據(jù)傳輸延遲和CPU開銷；該技術(shù)利用網(wǎng)卡的零拷貝能力加速多機多卡間的集體操作（如AllReduce），顯著提升分布式訓(xùn)練的通信效率。如果你找到的日志是[send] via NET/SOCKET，則表示網(wǎng)絡(luò)通信是通過以太網(wǎng)傳輸?shù)?，那么這時字符輸出很慢是正常的。如果你找到的日志是[send] via NET/IB/0，則表示網(wǎng)絡(luò)通信是通過IB網(wǎng)絡(luò)的，但是沒有開啟GDRDMA技術(shù)，則會有大致5%的性能損耗（網(wǎng)傳，未實測）。

排查思路如下：
1. 檢查IB網(wǎng)絡(luò)是否開啟，并正確配置。
2. 在github上找一個代碼倉庫https://github.com/NVIDIA/nccl-tests，根據(jù)文檔進行nccl的測試，逐一排查問題。
3. 對
、

等環(huán)境變量的配置進行修改并調(diào)試，NCCL的官方網(wǎng)站https://docs.nvidia.com/deeplearning/nccl/archives/nccl_2215/user-guide/docs/env.html，會有給你很大的幫助。
1. 對于你找到的日志是[send] via NET/IB/0，無法正確開啟RDMA的場景，請關(guān)注https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#gpu-to-gpu-communication，并確認自己的系統(tǒng)中是否正確開啟了nvidia-peermem，因為默認它是不開啟的，會導(dǎo)致RDMA無法使用。