起因：一个让我又激动又紧张的任务

最近 DeepSeek-V4、Kimi K2.6、GLM-5.1 这些开源大模型刷屏，朋友圈一堆"私有化部署"、"自建 ChatGPT"、"摆脱 OpenAI"的话术，每条都让公司老板心潮澎湃。

机会来了。

公司决定上一台大模型服务器,任务交给我。说实话,作为程序员,这种"亲手摸最新技术"的机会不多,我主动接下了。

到手的机器配置长这样:

• 2 颗 Intel 至强 6530，64 核 128 线程
• 512GB DDR5 内存
• 8 张 NVIDIA RTX 5090（消费级显卡里目前最强，每张 32GB 显存，加起来 256GB）
• 8.6TB 固态硬盘

按某乎大 V 的说法,这配置"随便跑满血 DeepSeek"。

实际呢？一整天就为了让 8 张显卡跑出来一个"Hello"。

下面这篇文章，把所有坑原原本本写出来——不是劝退，是让你心里有个真实预期。

---

序章:一个我自己挖的坑——选了"最新"的 Ubuntu 26.04

我有点技术洁癖,看到 Ubuntu 26.04 刚发布(2026 年 4 月),想着"新系统肯定支持最新硬件",主动选了 26.04 而不是更稳定的 24.04 LTS。

这是我第一个、也是最关键的决策失误。

后来才知道：

• 新系统配的内核是 6.17,比 LTS 新一年——但NVIDIA 驱动还在追赶
• 系统自带 gcc-15,但 CUDA Toolkit 13.1 的头文件还没适配 gcc-15
• 阿里云镜像源对新版本支持也不完善

如果你重来一次，结论是：做生产环境，不要碰最新系统。LTS 落后半年到一年，但这半年是社区帮你踩平所有坑的时间。

下面所有的故事,几乎都跟这个选择有关。

---

第一坑：装个驱动用了 3 个小时

服务器到手，Ubuntu 26.04 已经预装。我满怀信心敲下：

nvidia-smi

回车。

nvidia-smi: command not found

没有驱动。

8 张 RTX 5090 像 8 块板砖躺在主板上，系统认得它们是"NVIDIA 显示卡"，但完全不会用。

普通人以为的步骤：

apt install nvidia-driver
搞定

实际要做的事：

1. 系统源里最新版驱动只到 580，但 RTX 5090 是 Blackwell 架构,需要 595 以上
2. 默认选 proprietary(专有)模块？错的。Blackwell 必须用 open kernel module,老模块有 bug
3. 装完发现编译失败:linux-headers not supported——内核头文件没装
4. 装上头文件再编译:还是失败,gcc not found——这台机器连 C 编译器都没有
5. 装上 gcc-15:又失败,The kernel was built by gcc 15.2.0, you're using ...——内核编译用的 gcc 版本和系统当前 gcc 对不上
6. 终于编译成功,开机能自动加载吗?还得手写一个 /etc/modules-load.d/nvidia.conf

全套流程下来 3 小时,期间我把"nouveau"(开源显卡驱动)卸了三次都卸不干净,因为它绑定到了内核模块队列里。

熬过这关,敲下 nvidia-smi:

+-------------------------------------------+
|  8 张 NVIDIA GeForce RTX 5090,持久模式已开 |
+-------------------------------------------+

那一刻我以为见到了希望。

后来证明,这只是地狱的入口。

---

第二坑：系统盘的 891GB，只给我用了 100GB

跑 df -h：

/dev/mapper/ubuntu--vg-ubuntu--lv   98G   11G   83G   /

完蛋,根分区才 98GB,已用 11GB。

但物理盘明明是 894GB。剩下 791GB 哪去了？

$ vgs
  VG        #PV #LV #SN Attr   VSize    VFree
  ubuntu-vg   1   1   0 wz--n- <891.20g <791.20g
  vg_data     2   1   0 wz--n-   <6.99t       0

看 VFree 那一列——ubuntu-vg 卷组里有 791GB 是 FREE 状态,没分配给任何分区。系统镜像默认只切了 100GB 给根分区,剩下的留作"机动空间"。

意思就是:你装个 PyTorch(约 4GB)、再装个 vLLM(约 3GB)、再下个 Python 环境(约 5GB)、再 git clone 几个仓库……100GB 半天就满。

老司机的解决方案(在线扩容,不需要重启):

lvextend -L +400G /dev/ubuntu-vg/ubuntu-lv
resize2fs /dev/ubuntu-vg/ubuntu-lv

执行完之后:

$ vgs
  ubuntu-vg   1   1   0 wz--n- <891.20g <391.20g

VFree 从 791G 降到 391G,根分区从 100GB 扩到 500GB,剩 391GB 留作机动。

小白的解决方案:找一个能动手做的师傅。这两条命令打错一个字母,你的系统就废了。

lvextend 是 LVM(逻辑卷管理)的扩容命令,resize2fs 是文件系统跟着扩。但如果你不知道这是什么,看到 /dev/mapper/ubuntu--vg-ubuntu--lv 这种鬼路径,第一反应只会是"我是不是把数据库给删了"。

---

第三坑：7TB 数据盘里有几百 GB"前任租户"的数据

$ df -h /data
/dev/mapper/vg_data-lv_data  7.0T  1.2T  5.4T  /data

7TB 是挂上了,但是…… cat /etc/fstab 没找到这一行。

意思是:重启一次,/data 就消失了。服务商用 systemd mount unit 临时挂着,不是开机自动挂载的。

更让我惊讶的是,数据盘里已经有 1.2TB 的内容:

• 一堆 AI 评测用的代码
• Docker 数据目录(几百 GB)
• 一些项目相关文件夹

这台服务器,之前被别的团队用过。

我反复跟服务商确认"这些数据没人要、可以清空"之后,才敢动手。删之前,我做了三件事:

1. 用 stat 看每个目录的最后修改时间(确认是旧数据)
2. 看 docker 服务是否在运行(确认没人正在用)
3. 跟服务商书面留痕(以防扯皮)

这三件事各花了点时间,但这是必要的成本。在生产环境,"看起来没用就删"是大忌——你删的可能是别人花一周下的模型。

清干净之后,写好 fstab、加上开机挂载,这一关又花了 1.5 小时。

思考一下:租用服务器(尤其是二手转租),永远不要假定盘里是干净的。第一件事是 ls / 看遍每个目录,确认归属。

---

第四坑：apt 源里有个拼写错误，让所有事情都失败

服务器装好后，第一次跑 apt update：

Err:1 http://miirors.aliyun.com/ubuntu resolute InRelease
  Could not resolve 'miirors.aliyun.com'

仔细看——miirors,多了一个 i。

阿里云正确的镜像是 mirrors.aliyun.com,服务商装机时手抖打错了。

这一个 typo 导致:

• 装不了驱动
• 装不了编译器
• 装不了任何依赖包

整套环境寸步难行,因为软件源根本访问不到。

我修了这个 typo,用 sed 一行命令搞定:

sed -i 's/miirors\.aliyun\.com/mirrors.aliyun.com/g' \
    /etc/apt/sources.list.d/ubuntu.sources

然后整个世界突然清净了。

思考一下:你拿到一台服务器,会去检查 apt 源文件里的拼写吗？大部分人不会。这个错误可能在那台机器上躺了好几个月,没人发现——直到你试图用它做事。

---

第五坑：内核版本号竟然出现了"7.0.0"

装完驱动,apt 提示要升级。我没多想,跑了 apt upgrade。

升级过程中报错:

Builds for the following kernel(s) failed: 6.17.0-5-generic 7.0.0-15-generic

等等,7.0.0？？？

Linux 内核目前主流是 6.x 系列,Linus 公开说过 7.0 还要很久。这台机器上怎么会有 7.0.0 的内核？

查了一下,是 Ubuntu 26.04 的一个非标准更新——Canonical 给某些上游改动打了 7.0.0-15.15 这种内部编号。技术上是合法包,但NVIDIA 595 驱动的 DKMS 编译过不去——因为这套驱动还没适配这个内核。

更可怕的是:GRUB 启动菜单默认会选最新的 7.0.0。如果我没注意直接重启,机器就会用一个"驱动半装的内核"启动,然后大概率黑屏。

我做了几件事:

1. 用 apt purge 移除 7.0.0-15 相关所有包
2. 手动把 /boot/vmlinuz 软链接改回 6.17
3. 删掉 7.0.0 内核的所有文件
4. 重新生成 GRUB(update-grub)
5. 验证 GRUB 菜单里只剩 6.17,才敢按下重启

这一步是我第一次后悔选了 26.04 而不是 24.04 LTS。如果当初选 LTS,根本不会出现这种新内核混乱。

---

第六坑（最戏剧性的）：DeepSeek-V4 跑不动

熬过前面所有坑,我开始下载 DeepSeek-V4-Flash(160GB)。下完启动 vLLM。

显存够(256GB > 160GB),驱动正确,参数也对。但 vLLM 就是启不起来。

报错往下翻,翻了几千行,找到根本原因:

Worker failed with error 'Assertion error
(deepgemm-src/csrc/apis/hyperconnection.hpp:56):
Unsupported architecture'

DeepGEMM 是 DeepSeek 自己开发的加速库,里面调用了 NVLink switch 的硬件指令。这个指令只有 H100 / H200 / B200 这种数据中心卡才有。

RTX 5090 虽然是 Blackwell 架构,但消费级,没 NVLink switch。

意思就是:DeepSeek-V4 这个模型,从根本上就不适合消费卡跑。

DeepGEMM 的调用是写死在模型代码里的,没法关、没法绕。我试了 5 个环境变量、3 种参数组合,全都不行。

结论:8 张 RTX 5090,跑不动 DeepSeek-V4。

不是配置错,不是显存不够,是模型设计时就没考虑消费卡。

这一刻我必须做一个选择:

选项	代价	我的判断
公司加钱换 H100	¥80 万起	老板不会同意,而且我不一定真的需要 V4
换其他开源模型	重新下载 200GB	可行,继续干
放弃自建,用 API	退掉服务器	已经花了钱,不能放弃

我选了换模型——具体说,换 Qwen3 系列(阿里出品,5090 验证可跑)和 MiniMax M2(国产开源 SOTA,vLLM Day-0 支持)。

这个选择背后的逻辑很重要:

不是"最强的模型就是最好的"。最好的是"你硬件能跑、用着稳、智力够用"的那个。

---

第七坑：连下载模型都能踩坑

放弃 DeepSeek,转向 Qwen 系列。模型在 ModelScope 上,国内下载快。

modelscope download --model Qwen/Qwen-Image-Layered \
    --include "transformer/*" \
    --local_dir ./qwen_layered

几秒钟："下载完成"。

打开目录一看,只有 20KB 的配置文件,真正的 50GB 模型权重没下来。

原因:modelscope 命令行的 --include "transformer/*" 通配符不递归匹配深层文件。要么改用 Python SDK,要么用双星号 transformer/**。

# 正确做法
from modelscope import snapshot_download
snapshot_download(
    'Qwen/Qwen-Image-Layered',
    allow_patterns=['transformer/*', 'vae/*'],  # SDK 模式下,这种写法是递归的
    local_dir='./qwen_layered'
)

这种文档里查不到、官方示例不写的细节,让你以为下载成功了,其实啥也没下。

我浪费了将近 1 小时,才发现 5 个文件夹的"已下载"全是配置文件。

---

一天后,我的真实战绩

任务	状态
装好 NVIDIA 驱动	✅
8 张卡识别正常	✅
Python 环境 + PyTorch	✅
编译 ik_llama.cpp	✅(CUDA 头文件冲突修了 2 小时)
下载 DeepSeek-V4-Flash 149GB	✅
跑起来 DeepSeek-V4-Flash	❌ DeepGEMM 不兼容
下载 Qwen3.6-27B 52GB	✅
ComfyUI 安装	✅
Qwen-Image-Layered 模型下载	⏳ 还在搞

14 小时,完成了"装好底座"和"踩遍前置坑"。真正的 AI 服务还没起来。

---

复盘:这一天我学到的几件事

1. 选系统不要追新

我选了 26.04(刚发布)而不是 24.04 LTS(成熟)。省了什么?省了一年寿命。代价是?多踩 4-5 个坑。

下次?生产环境只用 LTS,而且是发布超过 6 个月的 LTS——让别人帮你踩坑。

2. 服务器交付时,做完检查再开始

下次拿到一台机器,第一件事不是装软件,而是:

• lsblk 看分区
• df -h 看挂载
• cat /etc/fstab 看开机自动挂载
• cat /etc/apt/sources.list* 看源
• vgs && lvs && pvs 看 LVM
• ls / 看每个目录归属
• nvidia-smi / lspci 看硬件

这 10 分钟会救你几小时。

3. 模型选型,从硬件兼容性反推,不是从评测分数

我一开始选 DeepSeek-V4 是因为它跑分最高。但跑分高没用——你硬件跑不动。

正确顺序应该是:

1. 我的硬件有什么? → 8 张消费级 Blackwell
2. 这个硬件支持哪些推理引擎? → vLLM(部分)、llama.cpp(全部)
3. 这些引擎支持的模型里,哪些能跑? → Qwen 系列、MiniMax、gpt-oss
4. 这些能跑的模型里,哪个最强? → 选这个

而不是反过来。

4. 留出预算给"踩坑时间"

如果老板问"多久能搭好",不要按教程标注的时间答。教程是 "2 小时搞定",真实是"2 天起步"。

我的经验比例是:教程时间 × 5 = 真实时间。这个倍数对老司机也成立,新手要 × 10。

---

自建大模型的真实成本拆解

对比给参考:

项目	一次性成本	隐藏成本
8 张 RTX 5090	¥20 万	普通家用电路供不起,需要工业电
服务器主板/电源/机箱	¥3 万	要双路至强 + 大电源(2000W+)
内存 / 硬盘	¥3 万	模型动辄几百 GB
机房托管	¥1500/月起	噪音、散热,家里放不了
时间	1-7 天起	这是你看不到的最大成本
运维知识	无价	Linux + CUDA + Python + 多卡调优,缺一不可

总计:30 万左右,加上无穷的折腾时间。

而 OpenAI / Claude API:充值 100 美元,今天就能用,速度比你自建快 5 倍。

---

那为什么还要自建？

我没有否定自建的价值。自建大模型确实有不可替代的场景:

1. 数据隐私:医院、银行、政府——数据不能出本地
2. 特定定制:需要在自己数据上微调,私有 API 出不了
3. 极端高频:每天调用上亿次,公网 API 会算账算到怀疑人生
4. 断网环境:野外、船舶、军用,根本没网
5. 学习研究:搞 AI 的人,不亲手摸一遍模型,理解永远停在表面

但如果只是"想拥有自己的 ChatGPT"——

这玩意不值得。

---

最后说点实话

写这篇文章的时候,我后台还在重新下载 Qwen-Image-Layered 模型(50GB,预计 1 小时)。我的 DeepSeek-V4-Flash 模型权重 149GB 还躺在硬盘上,但已经确定永远没法运行——除非把 8 张 RTX 5090 全卖了,换 4 张 H100,再花 ¥80 万。

自建大模型这事,本质上是用钱、时间、技术,换取数据自由。这三样,缺一不可:

• 没钱:买不起卡
• 没时间:搞不下来
• 没技术:搞下来也跑不顺

我们这些做技术的,至少能用时间 + 技术省钱。这次任务公司给我两周时间,看起来够,实际上前两天就过去了——大部分是我今天讲的这些坑。

如果你也准备给公司搭一套:先给自己留两周,再砍掉一半评估的工期。

最后留个问题:你公司有没有让你搞过类似的"看起来很简单实际很坑"的任务?评论区聊聊。