为什么我坚持用物理机做开发

在云原生统治世界的时代，我固执地组了一台 96 核的机器。 这不是复古，是清醒。

过去五年，我们经历了一场浩浩荡荡的「云化」。 开发环境要上云，测试环境要上云， 甚至笔记本都变成了瘦客户端，通过 SSH 连到某个 c5.4xlarge。 前几年我也跟风。今年我把这套东西全撤了。

先说结论

我的开发主力现在是一台放在书房的机器：

CPU:  AMD Threadripper 7970X (32C/64T)
      + Ryzen 9 7950X (16C/32T)  — 备机
RAM:  128 GB DDR5 ECC
存储: 4 × 4TB NVMe (ZFS mirror)
      2 × 20TB HDD (冷数据)
GPU:  RTX 4090 (本地跑 7B~14B 模型)
网络: 万兆内网 + 千兆上行
系统: Arch Linux, kernel-lts
噪音: 满载 42 dB (风冷 + 静音风扇)

我通过 Tailscale 从任何地方 SSH 上去， 或者用 mosh 保持长连接。 笔记本只是一块屏幕加一个键盘。

为什么不用云？

我用过。用了三年。三年之后我算了一笔账。

同等配置的 AWS 实例（m6i.24xlarge） 按需价格是每小时 $4.6。 一天 10 小时开机，一个月按 22 工作日算， $1012 / 月，$12,144 / 年。

我这台物理机整机成本大约 ¥85,000（约 $11,800）。 一年不到就回本，然后开始白嫖。

这还没算 EBS 存储、数据传输费、以及那些 「我忘了关机」的深夜账单。

但真正的原因不是钱

钱只是让我下定决心的最后一根稻草。 真正的原因是——延迟、控制、心智。

延迟

云上开发最讨厌的一件事：tab 补全都要等。 哪怕你用 mosh，哪怕你连的是同一个 region， 键盘和眼睛之间总有一层雾。 本地开发时，Neovim 里 <C-x><C-o> 是瞬间的。 你会低估这层「瞬间感」对 flow 的重要性。

「延迟不是数字，是一种精神损耗。」

控制

我用 ZFS，我用 zfs snapshot。 每 15 分钟自动打一个快照，保留 24 小时； 每天一个快照，保留 30 天； 每周一个，保留 5 年。

我用 nvidia-persistenced，我用 cpupower， 我用 ionice。 我能决定编译进程用哪 8 个核，能决定 rustc 优先级低于 tmux。

云上呢？你连你运行在什么 CPU 型号上都不完全清楚， 更别提隔壁 tenant 昨晚在跑什么。

心智

这一点最重要。

用物理机迫使你理解你的系统。

内存不够？你得知道为什么。 硬盘满了？你得自己扩容。 内核崩了？你得从 rescue 分区起来修。 这些「麻烦」在云上被抽象掉了，代价是—— 你也慢慢丧失了理解一台机器的能力。

我不希望我的下一代程序员， 连一块硬盘的物理形状都没见过。 我不希望我自己也变成那样。

那云是错的吗？

不。云对生产环境是正确的答案。 弹性、可用区、托管服务——这些在生产环境里都是巨大的价值。

但生产环境和开发环境是两回事。 把开发环境云化，是把子弹变成手榴弹的操作。

我们混淆了「云是好的」和「一切都要上云」。 前者是事实，后者是意识形态。

回到桌面

我现在的日常：

• 早晨 8 点，机器已经开机（wake-on-lan），编译好了昨晚的分支。
• 咖啡放桌上，tmux attach，昨天的 session 原封不动。
• 跑一次全量测试，Rust 项目大约 45 秒。云上同样配置，我上次跑要 2 分 10 秒。
• 需要 GPU？直接调用本地 4090，跑 7B 模型 fine-tune。
• 下班关机（或者不关）。零成本。

这种感觉，很像 2005 年我第一次组装台式机的下午。 风扇转起来，屏幕亮起来， 你知道这一切都在你手里。

云给了我们规模，但拿走了这个下午。 我想把这个下午拿回来。

---

后记：有人问 96 核用来干嘛。答： cargo build --release 之后你就懂了。