大模型推理引擎vLLM源码编译踩坑记录 - 文章 - 开发者社区

vLLM 作为目前最流行的开源大模型推理引擎，已然成为业界标杆。一个新的推理优化引擎出来，必然要拿来和vLLM比较一番，如果没有超过vLLM的地方，那就没有必要发布了。而vLLM也在不断集成新的优化技术，飞速迭代。比如最近DeepSeek开源周第一天刚发布的FlashMLA，vLLM已经第一时间集成，优化到自己的引擎中了。vLLM项目更新有多频繁呢？就是在你下载了源码构建时，报了个错，调试下重新构建前，再pull下发现它又有更新了，你永远编译不到最新的代码。

本来使用 vLLM 也不需要自己编译源码，它有现成的docker镜像可用，比如最新的是 vllm/vllm-openai: 0.7.3，是两周之前2月20号发布的。但是用这个镜像来启动 DeepSeek 671B 满血 AWQ 量化版一推理就崩溃。问了个朋友，以及查了一些贴子，说是要用最新源码构建的版本才能跑起来。于是自己尝试构建了下，还真是不太容易，把服务器都搞挂两次。所以这里分享下踩坑过程。

step1. 源码准备

源码构建时，经常有 github 拉取依赖代码失败，造成编译报错。这是最先踩到的坑，因为github的网络时好时坏，比较烦人。而vLLM依赖的源码工程还不止一个，所以干脆把所有依赖源码都拉取到本地，再来构建。

在网络畅通的机器上，你懂得，将如下内容：

  
#!/bin/bash  
set -ex  
# 创建一个干净的目录 pkg  
rm -rf pkg && mkdir -p pkg && cd pkg  
# 克隆 vllm（这里默认拉取最新版本）  
git clone --depth 1 https://github.com/vllm-project/vllm.git && echo ""  
# 克隆 NVIDIA/cutlass 指定分支 v3.8.0（浅克隆）  
git clone --depth 1 --branch v3.8.0 https://github.com/NVIDIA/cutlass.git && echo ""  
# 克隆 vLLM 依赖的 FlashMLA  
# 如果目标 commit 不在默认浅克隆中，则手动 fetch 该 commit  
git clone --depth 1 https://github.com/vllm-project/FlashMLA.git && cd FlashMLA  
git fetch --depth 1 origin 575f7724b9762f265bbee5889df9c7d630801845  
git checkout -b vllm 575f7724b9762f265bbee5889df9c7d630801845  
git submodule update --init --recursive --depth 1  
cd .. && echo ""  
# 克隆 flash-attention 指定 commit  
git clone --depth 1 https://github.com/vllm-project/flash-attention.git && cd flash-attention  
git fetch --depth 1 origin 9bfa9869829d8c593527eb34c5271d0090f7ccc9  
git checkout -b vllm 9bfa9869829d8c593527eb34c5271d0090f7ccc9  
git submodule update --init --recursive --depth 1  
cd ..  && echo ""  
# 返回上级目录并打包  
cd ..  
tar zcf pkg.tgz pkg

保存为 pkg.sh，然后执行：

  
chmod +x pkg.sh  
./pkg.sh

会将所有依赖代码打包成 pkg.tgz , 拷贝解压到构建源码的服务器。和后面要讲到的的dockerfile文件放在同一个目录，结构如下：

  
└── vllm-cu121-srcbuild.dockerfile  
└── pkg  
   ├─ cutlass/  
   ├─ flash-attention/  
   ├─ FlashMLA/  
   ├─ vllm/

以上脚本中的源码地址和版本号是从哪里来的呢？可以根据这个列表在vLLM源码目录中找到：

  
➜  vllm git:(main) grep -r GIT_REPOSITORY .  
./CMakeLists.txt:        GIT_REPOSITORY https://github.com/nvidia/cutlass.git  
./cmake/external_projects/vllm_flash_attn.cmake:          GIT_REPOSITORY https://github.com/vllm-project/flash-attention.git  
./cmake/external_projects/flashmla.cmake:        GIT_REPOSITORY https://github.com/vllm-project/FlashMLA.git  
./cmake/cpu_extension.cmake:        GIT_REPOSITORY https://github.com/oneapi-src/oneDNN.git

验证下这些特定版本有没有更新：

  
➜  vllm git:(main) grep "v3.8.0" CMakeLists.txt  
  set(CUTLASS_REVISION "v3.8.0" CACHE STRING "CUTLASS revision to use")  
        GIT_TAG v3.8.0  
➜  vllm git:(main) grep 575f7724b9762f265bbee5889df9c7d630801845 ./cmake/external_projects/flashmla.cmake  
        GIT_TAG 575f7724b9762f265bbee5889df9c7d630801845  
➜  vllm git:(main) grep 9bfa9869829d8c593527eb34c5271d0090f7ccc9 ./cmake/external_projects/vllm_flash_attn.cmake  
          GIT_TAG 9bfa9869829d8c593527eb34c5271d0090f7ccc9

一致的说明没有更新。否则用源码中最新的引用版本，更新上面的下载脚本。

同时这些文件中，可以找到编译时所依赖第三方工程的源码本地路径的变量。后面会用到。

step2. 编写 dockerfile

下面是一个可以构建成功的 dockerfile 内容：

  
FROM pytorch/pytorch:2.5.1-cuda12.1-cudnn9-devel  
# 设置pip源为阿里云pip源  
ENV PIP_INDEX_URL=https://mirrors.aliyun.com/pypi/simple/  
  
# 安装基础工具  
RUN --mount=type=cache,target=/var/cache/apt \  
    apt update && \  
    apt install -y apt-utils && \  
    apt install -y vim-tiny net-tools telnet curl wget netcat lsof build-essential git  
  
# 根据实际 GPU 架构修改  
# import torch  
# device = torch.cuda.current_device()  
# major, minor = torch.cuda.get_device_capability(device)  
# print(f"当前GPU的计算能力: {major}.{minor}")  
# RTX4090 是 8.9  
ENV VLLM_CUDA_ARCH_LIST="8.9"  
ENV VLLM_TARGET_DEVICE=cuda  
  
COPY pkg /home  
WORKDIR /home/vllm  
  
# 安装 vllm  
# 参见： https://docs.vllm.ai/en/latest/getting_started/installation/gpu/index.html  
# Use an existing PyTorch installation  
# pip install -r requirements/common.txt  && \ 不需要  
RUN --mount=type=cache,target=/root/.cache/pip ls -l /root/.cache/pip && \  
    python use_existing_torch.py  && \  
    pip install -r requirements/build.txt  && \  
    pip install xformers==0.0.28.post3  && \  
    VLLM_CUTLASS_SRC_DIR=/home/cutlass \  
    FLASH_MLA_SRC_DIR=/home/FlashMLA \  
    VLLM_FLASH_ATTN_SRC_DIR=/home/flash-attention \  
    MAX_JOBS=24 \  
    pip install -e . --no-build-isolation  
WORKDIR /home  
# 清空父镜像的 ENTRYPOINT  
ENTRYPOINT []  
CMD []

其中基础镜像 pytorch/pytorch:2.5.1-cuda12.1-cudnn9-devel 根据你目标环境的NVIDIA驱动情况来选择。可以看到这个dockerfile比较简洁，相比vLLM源码中的Dockerfile简单很多。因为是基于这个公开的 PyTorch 镜像来构建的。

配合上文同级目录的 pkg 源码目录使用。有以下几点需要说明下：

python use_existing_torch.py ；来自 vLLM文档，当依赖环境中现有的 PyTorch 版本时（这里就是基础镜像），需要执行这句以设置torch版本相关变量
pip install xformers == 0.0.28.post3 是基础镜像没有而 vllm 依赖的。来自 requirements/cuda.txt ；这个文件中的其他包基础镜像已有
VLLM_CUTLASS_SRC_DIR 等3个变量，指定了依赖源码的本地路径，对应之前下载好的 pkg 下的子目录
MAX_JOBS=24 并行编译进程数，根据自己编译器的资源情况来设置。实际编译进程大概是这个数字的2倍左右。如果不设置，则取系统cpu核数

有了这个dockerfile和下载好的源码之后，理论上就可以通过如下命令构建了：

  
nohup docker build -f vllm-cu121-srcbuild.dockerfile -t vllm:20250309_cu121 --push . > build.log 2>&1 &  
tail -100f build.log

但是且慢，一定要看你的构建过程是否做了资源限制保护。

step3 设置资源限制

vLLM 源码构建非常吃CPU和内存，所以要加限制，否则会拖挂整个系统。这是踩的第二个坑。来看下没有限制资源时的盛况：

picture.image

  
top - 07:42:16 up 49 min,  3 users,  load average: 1248.44, 1244.86, 1006.70  
Tasks: 2425 total, 181 running, 2235 sleeping,   0 stopped,   9 zombie  
%Cpu(s):  1.1 us, 98.9 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st  
MiB Mem : 515805.3 total,   1274.1 free, 506646.3 used,   7884.9 buff/cache  
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1514.0 avail Mem  
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND  
  27161 root      20   0   42.4g   8.2g   7.1g R 227.6   1.6  65:22.58 python3.11                                                                                                              279374 root      20   0 6780676   6.4g      0 R  10.7   1.3   4:50.64 cicc  
 279326 root      20   0 6689268   6.3g      0 R   4.2   1.3   4:04.82 cicc  
 279385 root      20   0 6672960   6.3g      0 R  20.9   1.3   4:48.49 cicc  
 279358 root      20   0 6669956   6.3g      0 R   9.8   1.3   4:05.57 cicc  
 279588 root      20   0 6638680   6.3g      0 R  19.7   1.2   4:42.67 cicc  
 279557 root      20   0 6551568   6.2g      0 R  15.7   1.2   4:00.71 cicc  
 279567 root      20   0 6536376   6.2g      0 R   7.0   1.2   3:51.39 cicc  
 279598 root      20   0 6513848   6.2g      0 R   5.7   1.2   3:39.33 cicc  
 279541 root      20   0 6356508   6.0g      0 R   7.2   1.2   3:55.56 cicc  
 279577 root      20   0 6269788   5.9g      0 R   9.4   1.2   3:58.53 cicc  
 281268 root      20   0 5791532   5.5g      0 R  13.1   1.1   4:57.91 cicc  
 281084 root      20   0 6633588   5.4g      0 R  14.2   1.1   4:44.07 cicc  
 281286 root      20   0 5569544   5.3g      0 R   9.3   1.0   4:50.00 cicc  
 281288 root      20   0 5553296   5.3g      4 R   6.9   1.0   4:01.06 cicc  
 281401 root      20   0 6282340   5.2g      0 R   5.8   1.0   3:40.81 cicc  
 281133 root      20   0 5526536   5.2g      0 R   5.7   1.0   3:52.45 cicc  
 280989 root      20   0 6348628   5.2g      0 R   7.8   1.0   4:42.86 cicc  
 281139 root      20   0 6348840   5.2g      0 R  14.8   1.0   3:41.63 cicc  
 281203 root      20   0 6312924   5.1g      0 R  10.3   1.0   3:37.58 cicc  
 281243 root      20   0 6091916   5.1g      0 R   7.8   1.0   4:47.20 cicc  
 281102 root      20   0 5393092   5.1g      0 R  12.9   1.0   3:43.16 cicc  
 281508 root      20   0 6049872   5.0g      0 R   7.8   1.0   4:46.70 cicc  
 280862 root      20   0 5826652   4.8g      0 R   4.9   1.0   4:29.91 cicc  
 281276 root      20   0 5798568   4.8g      0 R   5.4   0.9   4:39.48 cicc  
 281278 root      20   0 5800712   4.8g      0 R  10.7   0.9   4:18.57 cicc  
 281122 root      20   0 5713280   4.7g      0 R   2.8   0.9   3:53.33 cicc  
 280966 root      20   0 5676980   4.7g      0 R  14.7   0.9   3:44.32 cicc  
 280936 root      20   0 5642908   4.7g      0 R  10.6   0.9   3:45.07 cicc  
 280866 root      20   0 5364100   4.5g      0 R   5.7   0.9   3:48.95 cicc  
 280993 root      20   0 5220628   4.5g      0 R   6.3   0.9   3:40.13 cicc  
 280981 root      20   0 5179692   4.5g      0 R   5.2   0.9   4:38.40 cicc  
 280636 root      20   0 5120568   4.4g      0 R   7.2   0.9   3:51.28 cicc

一个 cicc 的进程就占4到6g的内存，这样的进程有多少个呢？

  
# ps aux | grep cicc | wc -l  
253

因为默认的 docker buildx 的 builder 是和 docker 平级的，直接使用系统所有资源。系统是128核，启动的编译进程大概是核数的两倍少一点儿(没有加MAX_JOBS参数的情况 )。编译还没过半，系统就因为内存耗尽死得硬邦邦，通过物理重启才能恢复。第二次做了一些设置，试图限制编译用的资源，没生效，构建进程kill得慢了一点，系统再次夯死。血泪教训啊，以下是经过验证最后降服这头资源巨兽的方法：

新建一个 driver 为 docker container 的 builder 实例

  
docker buildx create --name container \  
  --driver=docker-container --use --bootstrap \  
  --driver-opt=memory=384g,memory-swap=384g,cpuset-cpus=0-31,cpu-shares=1024,network=host,default-load=true \  
  --buildkitd-flags '--oci-worker-net host'

其中：

--name container 指定 builder 的名称
--driver=docker-container 指定 builder 的 driver 为 docker 容器
--use 设置为默认 builder
--bootstrap 创建后启动
--buildkitd-flags '--oci-worker-net host' oci容器使用主机网络
--driver-opt= 这行是 docker-container 这个 driver 支持的特定设置。其中

memory=384g, 指定构建容器的最大内存为384g
memory-swap=384g,和memory相同则不开启swap内存磁盘交换
cpuset-cpus=0-31, 使用的cpu限制为第0到31核
cpu-shares=1024, 每个cpu上的 cpu shares 为默认权重 1024
network=host, 构建容器使用主机host网络
default-load=true, 构建成功的镜像自动加载到主机docker引擎（实测并不管用，build时还是需要加上--load参数，构建成功后host上才能看到新镜像）

参数详细含义可以参见 buildx 官方文档：

执行样例：

  
[+] Building 30.6s (1/1) FINISHED  
 => [internal] booting buildkit                                                                                                                                                         30.6s  
 => => pulling image moby/buildkit:buildx-stable-1                                                                                                                                      30.1s  
 => => pulling failed, using local image moby/buildkit:buildx-stable-1                                                                                                                   0.0s  
 => => creating container buildx_buildkit_container0                                                                                                                                     0.5s  
container

这里事先在机器上 pull 好了 moby/buildkit 镜像，但它还是会去官网pull下最新的。

创建好后 docker buildx ls 可以看到新增了一条记录：

  
# docker buildx ls  
NAME/NODE        DRIVER/ENDPOINT                   STATUS    BUILDKIT   PLATFORMS  
container*       docker-container  
 \_ container0    \_ unix:///var/run/docker.sock   running   v0.20.1    linux/amd64 (+3), linux/386  
default          docker  
 \_ default       \_ default                       running   v0.12.5    linux/amd64 (+3), linux/386

可以看到背后创建的用来构建镜像的容器： buildx_buildkit_container0

  
# docker ps -a | grep buildx  
9f55e63e3356   moby/buildkit:buildx-stable-1                                           "buildkitd --allow-i…"    17 minutes ago   Up 17 minutes                                                                                             
   buildx_buildkit_container0

对应的 volume 也会被自动创建好：

  
# docker volume ls | grep buildx  
local     buildx_buildkit_container0_state  
  
# docker inspect buildx_buildkit_container0_state  
[  
    {  
        "CreatedAt": "2025-03-08T11:50:07Z",  
        "Driver": "local",  
        "Labels": null,  
        "Mountpoint": "/data/docker/volumes/buildx_buildkit_container0_state/_data",  
        "Name": "buildx_buildkit_container0_state",  
        "Options": null,  
        "Scope": "local"  
    }  
]

删除 builder 的时候，加上 --keep-state 参数，这个 volume 就可以保留：

  
docker buildx rm --keep-state container

再创建同名 builder 的时候 volume 会自动挂回去

docker inspect 查看 buildx_buildkit_container0 容器可以看到和 docker buildx create 命令执行时对应的参数：

  
# docker inspect buildx_buildkit_container0  
[  
    {  
        "Path": "buildkitd",  
        "Args": [  
            "--oci-worker-net",  
            "host",  
            "--allow-insecure-entitlement=network.host"  
        ],  
        "Name": "/buildx_buildkit_container0",  
        "HostConfig": {  
            "NetworkMode": "host",  
            "CpuShares": 1024,  
            "Memory": 274877906944,  
            "CgroupParent": "/docker/buildx",  
            "CpusetCpus": "0-31",  
            "MemorySwap": 274877906944,  
            "MemorySwappiness": null,  
            "Mounts": [  
                {  
                    "Type": "volume",  
                    "Source": "buildx_buildkit_container0_state",  
                    "Target": "/var/lib/buildkit"  
                }  
        "Config": {  
            "Image": "moby/buildkit:buildx-stable-1",  
        },

（以上内容删去了和docker buildx create命令行参数无关的内容）

启动构建时，带上 --builder 参数，指向新创建的 builder

  
nohup docker build --builder=container -f vllm-cu121-srcbuild.dockerfile -t vllm:20250309_cu121 --push . > build.log 2>&1 &  
tail -100f build.log

这里踩到第二个坑：即使创建 builder 时用了 --use 设置为默认 builder，而创建后 docker buildx ls 看到新 builder container 后面也确实有个 * 号。但是若 docker build 或 docker buildx build 时不加 --builder=container 参数，还是会用回 default 的 builder 实例把资源爆掉。

可以通过几个方法检查，是否新启动的构建任务，真正用上了限制了资源的新 builder ：

方法1.登录新 builder 对应的容器：

在docker build 或 docker buildx build 命令执行后，登录 builder 容器：

  
# docker  exec -it buildx_buildkit_container0 sh  
/ # ps aux  
PID   USER     TIME  COMMAND  
    1 root      0:00 /sbin/docker-init -- buildkitd --oci-worker-net host --allow-insecure-entitlement=network.host  
    7 root      0:00 buildkitd --oci-worker-net host --allow-insecure-entitlement=network.host  
   74 root      0:00 sh  
   80 root      0:00 ps aux  
/ #

如果只能看到如上两个 buildkitd 进程，说明构建进程没进来。如果能看到 buildx 进程，比如：

  
# docker  exec -it buildx_buildkit_container0 sh  
/ # ps aux  
PID   USER     TIME  COMMAND  
    1 root      0:09 /sbin/docker-init -- buildkitd --oci-worker-net host --allow-insecure-entitlement=network.host  
    7 root      2:02 buildkitd --oci-worker-net host --allow-insecure-entitlement=network.host  
   74 root      0:00 sh  
  157 root      0:03 buildctl dial-stdio  
  251 root      0:00 buildkit-runc --log /var/lib/buildkit/runc-overlayfs/executor/runc-log.json --log-format json run --bundle /var/lib/buildkit/runc-overlayfs/executor/11z9ussgrzxl2x7d9ue  
  264 root      0:00 /bin/sh -c apt update &&     apt install -y apt-utils &&     apt install -y vim-tiny net-tools telnet curl wget netcat lsof build-essential git  
  273 root      0:00 apt update  
  523 root      0:00 ps aux

看到有 buildctl 或 buildkit-runc 进程，说明构建进程成功被关进了笼子。

方法2：查看构建日志：

  
# head -2 build.log  
nohup: ignoring input  
#0 building with "container" instance using docker-container driver

说明用了 container 这个新实例

根据实际构建的资源情况调整builder容器的资源配比及构建参数

比如内存如果相比CPU(或MAX_JOBS) 配比太少了也不行。32核起了53个 cicc 进程之后，256g 内存 OOM 了，触发了内核的 oom-killer，这也是踩到的第三个坑：

  
# dmesg | grep -i kill  
[26003.000666] cicc invoked oom-killer: gfp_mask=0x1100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0  
[26003.000705]  oom_kill_process.cold+0xb/0x10  
[26003.001076] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=izbwbghd27ff9hv0mma7b09t2,mems_allowed=0-1,oom_memcg=/docker/buildx/5d8bbb310f05b2ddc198d77acdf99c761e16d272e355b5325c7fe5cf276d07b1,task_memcg=/docker/buildx/5d8bbb310f05b2ddc198d77acdf99c761e16d272e355b5325c7fe5cf276d07b1/buildkit/izbwbghd27ff9hv0mma7b09t2,task=cicc,pid=2901607,uid=0  
[26003.001090] Memory cgroup out of memory: Killed process 2901607 (cicc) total-vm:19378376kB, anon-rss:17177836kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:37956kB oom_score_adj:0  
[29457.432969] cicc invoked oom-killer: gfp_mask=0x1100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0  
[29457.433015]  oom_kill_process.cold+0xb/0x10  
[29457.433414] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=izbwbghd27ff9hv0mma7b09t2,mems_allowed=0-1,oom_memcg=/docker/buildx/5d8bbb310f05b2ddc198d77acdf99c761e16d272e355b5325c7fe5cf276d07b1,task_memcg=/docker/buildx/5d8bbb310f05b2ddc198d77acdf99c761e16d272e355b5325c7fe5cf276d07b1/buildkit/izbwbghd27ff9hv0mma7b09t2,task=cicc,pid=2906451,uid=0  
[29457.433429] Memory cgroup out of memory: Killed process 2906451 (cicc) total-vm:19341204kB, anon-rss:17159528kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:37880kB oom_score_adj:0  
[29495.065005] cicc invoked oom-killer: gfp_mask=0x1100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0  
[29495.065049]  oom_kill_process.cold+0xb/0x10

对应的构建日志：

  
#10 13528.1       [179/261] Building CUDA object vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_softcap_packgqa_sm90.cu.o  
#10 13528.1       FAILED: vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_softcap_packgqa_sm90.cu.o  
#10 13528.1       /usr/local/cuda/bin/nvcc -forward-unknown-to-host-compiler -DFLASHATTENTION_DISABLE_BACKWARD -DFLASHATTENTION_DISABLE_DROPOUT -DFLASHATTENTION_DISABLE_FP8 -DFLASHATTENTION_DISABLE_PYBIND -DFLASHATTENTION_DISABLE_UNEVEN_K -DFLASHATTENTION_VARLEN_ONLY -DPy_LIMITED_API=3 -DTORCH_EXTENSION_NAME=_vllm_fa3_C -DUSE_C10D_GLOO -DUSE_C10D_NCCL -DUSE_DISTRIBUTED -DUSE_RPC -DUSE_TENSORPIPE -D_vllm_fa3_C_EXPORTS -I/home/flash-attention/csrc -I/home/flash-attention/hopper -I/home/flash-attention/csrc/common -I/home/flash-attention/csrc/cutlass/include -isystem /opt/conda/include/python3.11 -isystem /opt/conda/lib/python3.11/site-packages/torch/include -isystem /opt/conda/lib/python3.11/site-packages/torch/include/torch/csrc/api/include -isystem /usr/local/cuda/include -DONNX_NAMESPACE=onnx_c2 -Xcudafe --diag_suppress=cc_clobber_ignored,--diag_suppress=field_without_dll_interface,--diag_suppress=base_class_has_different_dll_interface,--diag_suppress=dll_interface_conflict_none_assumed,--diag_suppress=dll_interface_conflict_dllexport_assumed,--diag_suppress=bad_friend_decl --expt-relaxed-constexpr --expt-extended-lambda -O3 -g -DNDEBUG -std=c++17 -Xcompiler=-fPIC --expt-relaxed-constexpr -DENABLE_FP8 --threads=1 --expt-extended-lambda --use_fast_math -DCUTLASS_ENABLE_DIRECT_CUDA_DRIVER_CALL=1 -D_GLIBCXX_USE_CXX11_ABI=0 -gencode arch=compute_90a,code=sm_90a -gencode arch=compute_80,code=sm_80 -MD -MT vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_softcap_packgqa_sm90.cu.o -MF vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_softcap_packgqa_sm90.cu.o.d -x cu -c /home/flash-attention/hopper/instantiations/flash_fwd_hdimall_bf16_softcap_packgqa_sm90.cu -o vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_softcap_packgqa_sm90.cu.o  
#10 13528.1       Killed  
#10 13528.1       [180/261] Building CUDA object vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_packgqa_sm90.cu.o  
#10 13528.1       FAILED: vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_packgqa_sm90.cu.o  
#10 13528.1       /usr/local/cuda/bin/nvcc -forward-unknown-to-host-compiler -DFLASHATTENTION_DISABLE_BACKWARD -DFLASHATTENTION_DISABLE_DROPOUT -DFLASHATTENTION_DISABLE_FP8 -DFLASHATTENTION_DISABLE_PYBIND -DFLASHATTENTION_DISABLE_UNEVEN_K -DFLASHATTENTION_VARLEN_ONLY -DPy_LIMITED_API=3 -DTORCH_EXTENSION_NAME=_vllm_fa3_C -DUSE_C10D_GLOO -DUSE_C10D_NCCL -DUSE_DISTRIBUTED -DUSE_RPC -DUSE_TENSORPIPE -D_vllm_fa3_C_EXPORTS -I/home/flash-attention/csrc -I/home/flash-attention/hopper -I/home/flash-attention/csrc/common -I/home/flash-attention/csrc/cutlass/include -isystem /opt/conda/include/python3.11 -isystem /opt/conda/lib/python3.11/site-packages/torch/include -isystem /opt/conda/lib/python3.11/site-packages/torch/include/torch/csrc/api/include -isystem /usr/local/cuda/include -DONNX_NAMESPACE=onnx_c2 -Xcudafe --diag_suppress=cc_clobber_ignored,--diag_suppress=field_without_dll_interface,--diag_suppress=base_class_has_different_dll_interface,--diag_suppress=dll_interface_conflict_none_assumed,--diag_suppress=dll_interface_conflict_dllexport_assumed,--diag_suppress=bad_friend_decl --expt-relaxed-constexpr --expt-extended-lambda -O3 -g -DNDEBUG -std=c++17 -Xcompiler=-fPIC --expt-relaxed-constexpr -DENABLE_FP8 --threads=1 --expt-extended-lambda --use_fast_math -DCUTLASS_ENABLE_DIRECT_CUDA_DRIVER_CALL=1 -D_GLIBCXX_USE_CXX11_ABI=0 -gencode arch=compute_90a,code=sm_90a -gencode arch=compute_80,code=sm_80 -MD -MT vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_packgqa_sm90.cu.o -MF vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_packgqa_sm90.cu.o.d -x cu -c /home/flash-attention/hopper/instantiations/flash_fwd_hdimall_bf16_packgqa_sm90.cu -o vllm-flash-attn/CMakeFiles/_vllm_fa3_C.dir/hopper/instantiations/flash_fwd_hdimall_bf16_packgqa_sm90.cu.o  
#10 13528.1       Killed

step4 执行构建并启动验证

成功日志：

  
#10 40.50 Building wheels for collected packages: vllm  
#10 40.50   Building editable for vllm (pyproject.toml): started  
#10 164.7   Building editable for vllm (pyproject.toml): still running...  
。。。  
#10 5066.8   Building editable for vllm (pyproject.toml): still running...  
#10 5077.5   Building editable for vllm (pyproject.toml): finished with status 'done'  
#10 5077.5   Created wheel for vllm: filename=vllm-0.1.dev1+g9513290.d20250308.cu121-0.editable-cp311-cp311-linux_x86_64.whl size=16667 sha256=69a93a6ebe2c46c13d355a465b7b59702e3b6bc9282b3acb2e81cbbb74d1a066  
#10 5077.5   Stored in directory: /tmp/pip-ephem-wheel-cache-8twew2pu/wheels/a9/74/b5/d9b5249c84b7a2670888a017ccab26c3c9ddf2686e8da2cfc1  
#10 5077.5 Successfully built vllm  
...  
#10 5097.9 Successfully installed aiohappyeyeballs-2.5.0 aiohttp-3.11.13 aiosignal-1.3.2 airportsdata-20250224 annotated-types-0.7.0 anyio-4.8.0 astor-0.8.1 blake3-1.0.4 cloudpickle-3.1.1 compressed-tensors-0.9.2 cupy-cuda12x-13.4.0 depyf-0.18.0 dill-0.3.9 diskcache-5.6.3 einops-0.8.1 email-validator-2.2.0 fastapi-0.115.11 fastapi-cli-0.0.7 fastrlock-0.8.3 frozenlist-1.5.0 gguf-0.10.0 h11-0.14.0 httpcore-1.0.7 httptools-0.6.4 httpx-0.28.1 huggingface-hub-0.29.2 importlib-metadata-8.6.1 iniconfig-2.0.0 interegular-0.3.3 jinja2-3.1.6 jiter-0.8.2 lark-1.2.2 llvmlite-0.43.0 lm-format-enforcer-0.10.11 markdown-it-py-3.0.0 mdurl-0.1.2 mistral-common-1.5.3 msgpack-1.1.0 msgspec-0.19.0 multidict-6.1.0 nest_asyncio-1.6.0 numba-0.60.0 numpy-1.26.4 openai-1.65.4 opencv-python-headless-4.11.0.86 outlines-0.1.11 outlines_core-0.1.26 partial-json-parser-0.2.1.1.post5 pillow-11.1.0 prometheus-client-0.21.1 prometheus-fastapi-instrumentator-7.0.2 propcache-0.3.0 protobuf-6.30.0 py-cpuinfo-9.0.0 pybind11-2.13.6 pycountry-24.6.1 pydantic-2.10.6 pydantic-core-2.27.2 pytest-8.3.5 python-dotenv-1.0.1 python-json-logger-3.3.0 python-multipart-0.0.20 pyzmq-26.2.1 ray-2.43.0 regex-2024.11.6 rich-13.9.4 rich-toolkit-0.13.2 safetensors-0.5.3 scipy-1.15.2 sentencepiece-0.2.0 shellingham-1.5.4 sniffio-1.3.1 starlette-0.46.1 tiktoken-0.9.0 tokenizers-0.21.0 transformers-4.49.0 typer-0.15.2 uvicorn-0.34.0 uvloop-0.21.0 vllm-0.1.dev1+g9513290.d20250308.cu121 watchfiles-1.0.4 websockets-15.0.1 xgrammar-0.1.11 yarl-1.18.3  
#10 5097.9 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager, possibly rendering your system unusable.It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv. Use the --root-user-action option if you know what you are doing and want to suppress this warning.  
#10 DONE 5101.8s  
...

也就是最耗时的源码编译这一步只花了 85 分钟，算很快了。官方编译也要一个多小时。

构建好的镜像，启动验证下：

  
# docker run --name vllm -itd \  
    --gpus '"device=7"' \  
    -p 7899:7899 \  
    --shm-size=24gb \  
    -v /data/ai/models:/models \  
    vllm:20250309_cu121 bash  
      
# docker exec -it vllm bash  
root@c15ba684ef42:/home# pip list | grep -E 'vllm|torch|flash'  
torch                             2.5.1+cu121  
torchaudio                        2.5.1+cu121  
torchelastic                      0.2.2  
torchvision                       0.20.1+cu121  
vllm                              0.1.dev1+g9513290.d20250308.cu121 /home/vllm

可以看到vllm的版本是：

  
0.1.dev1+g9513290.d20250308.cu121 /home/vllm

说明是从源码构建的。

在容器中启动最新的 QwQ-32B-AWQ 模型推理服务：

  
VLLM_LOG_LEVEL=DEBUG PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True \  
vllm serve "/models/qwen/QwQ-32B-AWQ" \  
  --host 0.0.0.0 --port 7899 --served-model-name "QwQ-32B" \  
  --tensor-parallel-size 1 \  
  --gpu-memory-utilization 0.98 \  
  --max-model-len 4096 \  
  --max-num-batched-tokens 16384 \  
  --trust-remote-code \  
  --dtype bfloat16

然后发 curl 消息验证推理功能：

  
curl -X POST http://localhost:7899/v1/chat/completions \  
    -H "Content-Type: application/json" \  
    -d '{ "model": "QwQ-32B",  
          "messages": [{"role": "user","content": "五星出东方利中国是什么意思"}]  }'

大功告成。文章到此结束，后面是源码编译的 vLLM 引擎，在单卡4090上，推理 QwQ-32B-AWQ 模型，对这个测试问题的返回内容，可忽略：

嗯，用户问“五星出东方利中国是什么意思”，我需要仔细分析这个问题。首先，这个短语看起来像是一个成语或者历史上的某种说法，可能和天文学或古代预言有关。我记得在《汉书·天文志》里提到过五星连珠的现象，可能和这个有关。五星指的是金木水火土五星，当它们同时出现在东方天空时，古人可能认为这是吉祥的征兆，所以“利中国”可能意味着对国家有利。

不过，用户可能不仅仅想知道字面意思，还可能想知道背后的历史背景或者文化意义。比如，这个说法是否在历史上出现过，或者有没有相关的考古发现。我记得新疆尼雅遗址出土过一块织锦，上面就绣有“五星出东方利中国”的文字，这可能是一个重要的考古发现，用户可能也想知道这个文物的背景。

另外，用户可能对现代的应用感兴趣，比如这个织锦现在在哪个博物馆，或者有没有相关的影视作品，比如央视的《国家宝藏》节目有没有介绍过。需要确认这些信息是否正确，比如织锦确实是在新疆发现的，属于汉代文物，现在存放在新疆博物馆。

还要考虑用户可能的深层需求，比如他们可能在学习中国历史，或者对中国古代天文学感兴趣，或者在准备考试需要准确的信息。因此，回答时要详细但不过于复杂，分点解释，确保涵盖历史背景、文物发现、现代意义等方面，同时语言要通俗易懂，避免学术术语过多。

需要确认几个关键点：五星指的是哪五星，东方指的是方位，利中国是预言吉祥。考古发现的织锦年代和出土地点是否正确，以及现代的引用情况。如果有不确定的地方，可能需要查阅资料确认，但根据已有的知识，应该是正确的。最后要确保回答结构清晰，信息准确，能够全面解答用户的问题。

“五星出东方利中国”是一句源自中国古代天文学的吉语，其含义和背景可以从以下几个方面理解：

字面含义

五星：指金星、木星、水星、火星、土星（中国古代称“五行”星，对应五行学说）。出东方：指这五颗行星在天空中同时出现在东方的方位。利中国：意为“对中原（中国）有利”，古人认为这种天文现象是祥瑞的征兆，预示国家繁荣安定。

历史背景

天文现象与预言：在古代中国，天文学与政治、宗教密切相关。古人观测到五星同时出现在东方（即“五星连珠”或“五星聚合”）时，认为这是上天对人间的警示或吉兆。《汉书·天文志》记载：“五星分天之中，积于东方，中国利；积于西方，夷狄利。”祥瑞象征：古人将五星东方的现象视为国家昌盛、天下太平的吉兆，因此衍生出“五星出东方利中国”这一吉语。

考古发现：汉代织锦护臂

重要文物：1995年，考古工作者在新疆和田地区尼雅遗址（古西域精绝国所在地）的墓葬中，发现了**“五星出东方利中国”**汉代织锦护臂。这是国家一级文物，现藏于新疆维吾尔自治区博物馆。织锦特点：锦面用青、赤、白、黑、黄五色丝线织出云气纹，上方织有“五星出东方利中国”汉字，下方织有“讨北敌，斩单于，辟贺除凶”等字样。历史意义：该织锦印证了汉代中原与西域的密切联系，证明汉代中央政权对西域的有效管辖，体现了“中国”一词在汉代已作为政治实体的象征。技术价值：其“经锦”织造工艺精湛，代表了汉代织锦的最高水平。

文化与现代意义

历史与民族融合：该织锦是汉代丝绸之路繁荣、中原与西域文化交流的实物见证，体现了中华文明多元一体的特征。现代引用：这一吉语在当代被广泛引用，例如：2019年央视《国家宝藏》节目曾重点介绍该文物。成为新疆与中原历史渊源的文化符号，象征各民族共同缔造中华文明。在影视、文学中常被用作象征国家繁荣或历史命运的隐喻。

总结

“五星出东方利中国”既是古代天文现象的吉语，也是汉代珍贵文物的核心铭文，其意义跨越时空：

天文层面：反映了古人对天象的崇拜与政治解读。历史层面：印证了汉代对西域的管辖，是中华文明多元一体的实物证据。文化层面：成为中华文化中“祥瑞”“团结”“繁荣”的象征，至今仍被赋予新的时代内涵。

这一发现被誉为“20世纪中国考古十大发现之一”，其历史与文化价值不可估量。