旧笔记本当服务器跟开发板到底差在哪

1. 开发板即插即用，笔记本不行

树莓派插上网线和电源，SSH 连上去就能干活。没有屏幕，没有电池，没有散热焦虑——它生来就是个服务器。

笔记本不一样。它被设计成「打开盖子、插上电源、坐在面前用」的东西。你要把它变成服务器，得跟它的三个硬件设计对着干：合盖会休眠、电池会鼓包、散热撑不住 7×24。

软件层面倒是没什么特别的——apt install、Docker CE、配置镜像源，跟装 Ubuntu 一样。区别全在硬件上。

2. 合盖：让它别睡觉

笔记本默认行为：合盖 = 休眠。服务器不能休眠。

Ubuntu 上改一行配置：

# /etc/systemd/logind.conf
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

改完 systemctl restart systemd-logind，合盖就只是关掉内置显示器，系统照跑。

有个副作用：合盖之后 BIOS 阶段看不到输出。所以你得确保系统能自动进桌面或者直接装 Server 版。我装的是 Ubuntu 24.04 桌面版，留着 GNOME——NVIDIA 老卡在桌面环境下的驱动兼容性比纯 headless 好。

3. 电池：一定要拔

这是旧笔记本当服务器最容易被忽视的坑，也是跟开发板最大的区别。

锂电池在长期满电 + 高温的状态下老化最快。笔记本 7×24 插着电跑 = 电池一直 100% + 机器持续发热，这是鼓包的标准配方。

鼓包的后果：电池膨胀，顶起触控板和键盘；严重的顶裂后盖；极端情况下有起火风险。开发板没电池，不存在这个问题。Mini PC 也没电池。只有笔记本会踩这个坑。

正确做法：拆掉电池，只用电源适配器供电。

大部分笔记本后盖拧几颗螺丝就能拆电池，断开排线就行。拆掉之后有个代价：停电即断电，没有 UPS 功能。如果你那边偶尔停电，要么接受这个风险，要么另外配一个小型 UPS。

还有一个折中方案：部分 ThinkPad 和 Dell 支持在 BIOS 或 tp-smapi 里设置充电阈值（比如只充到 60%），能大幅延缓老化。但不是所有品牌都支持，而且电池还是在机器里占空间、产热。对服务器场景来说，直接拆掉是最干净的。

4. 散热：最大的敌人

笔记本是为「打开盖子、面前使用」设计的，散热风道考虑的是正面操作时的空气流通。合盖之后，热量被闷在壳子里，散热效率直接打折。

几个实际做法，按效果排序：

垫高 > 散热底座 > 限频

• 垫高：四角垫高 2cm，让底部进风。最简单最有效，零成本
• 散热底座：30 块钱的带风扇底座，降 3-5°C，聊胜于无
• 限频：cpupower frequency-set -g powersave 把最高频率压到基频（比如 2.8GHz），温度能降不少，性能损失对服务器场景可以接受
• 清灰：每半年拆后盖清一次。十年老本的散热铜管里灰能积成毯子

我的 N551JW 日常 CPU 温度 72°C，夏天偶尔飙到 85°C+。不算好看，但还在安全范围内——Intel 处理器的 Tjunction 一般在 100°C，72°C 还有余量。开发板的散热问题完全不同：树莓派 4 满载 8W，加个散热片就够了，根本不需要风扇。

5. 三年里踩过的坑

合盖、电池、散热是装机时一次性解决的。真正折磨人的是跑起来之后的日常维护。这三年踩的坑，比装机时多十倍。

5.1 内核更新断网

这是最狠的一次。

Ubuntu 自动更新了内核，重启之后网卡驱动没了。SSH 连不上，浏览器打不开，远程桌面也连不上。只能搬显示器接上去看——新内核把 Realtek 网卡的 r8169 模块改了，老卡不认。

为什么改？因为上游觉得 r8169 太臃肿，重构了。你的老网卡恰好不在测试矩阵里。这不是 bug，是 feature。

解决办法：apt-mark hold linux-image-* 锁住内核版本，等稳定了再手动升。教训是——服务器不是开发机，内核更新不能随它来。自动更新在桌面系统上是安全的，在服务器上是炸弹。

5.2 NVIDIA 老卡驱动

这是一场持续三年的拉锯战。

GTX 960M 是 Maxwell 架构，CUDA Compute Capability 5.0。Ubuntu 每次大版本升级都要重新折腾一遍 NVIDIA 驱动。apt 源里的版本不一定兼容老卡，得手动去 NVIDIA 官网下 .run 安装包。装完驱动还得装 CUDA Toolkit，版本要对齐——驱动 535 对应 CUDA 12.2，但 PyTorch 2.0 要求 CUDA 11.8，两头打架。

CUDA 11+ 已经不正式支持 CC 5.0 了。PyTorch 2.0 以后的版本对这块卡各种玄学问题——编译通过，运行时 segfault；或者编译不通过，报一堆 deprecated API 的错。vLLM、llama.cpp 的 CUDA 后端更不稳定，跑几轮就崩。

折腾了一圈，最后的结论是：别指望老 GPU 做 AI 推理，老实走云端 API。GPU 这块等于废了，但笔记本还有 CPU、内存、硬盘——这些才是服务器的核心资源。

5.3 磁盘健康监控

机械硬盘跑了三四年，SMART 数据要定期看。smartctl -a /dev/sda 检查重分配扇区数和通电时间。有一块盘坏道数在涨，赶紧换了数据。

怎么发现的？不是主动查的，是 PostGIS 查询突然变慢，一看日志全是 I/O error。这才去查 SMART，发现 Reallocated_Sector_Ct 已经从 0 涨到了 47。从那以后设了 cron 任务，每周跑一次 smartctl，坏道数超过阈值就发邮件提醒。

SSD 也别掉以轻心，写入量大了同样会挂。smartctl 里的 Wear_Leveling_Count 和 Total_LBAs_Written 要看。

5.4 重启策略

机器断电重启后，Docker 容器要自动拉起来。restart: unless-stopped 解决大部分情况，但有些容器有启动依赖——比如 LangGraph RAG 依赖 PostgreSQL，PostgreSQL 依赖数据盘挂载。

得在 compose 文件里加 depends_on，再加上 healthcheck 确保依赖服务真的 ready 了再启动。不然 PostgreSQL 没起来，后面的容器全报错退出，日志刷屏，但服务就是不干活。

5.5 zram 救命

16GB 内存跑 35 个容器，实际可用经常吃满。加了 11.6GB zram 交换分区，把不活跃的内存页压缩到 RAM 里。

为什么用 zram 而不是普通 swap？普通 swap 需要磁盘空间，我的系统盘已经用了 83%，挤不出来。zram 直接在内存里压缩，不用额外磁盘。压缩比大概 2:1，11.6GB 的 zram 相当于多了 5-6GB 可用内存。

代价是 CPU。压缩解压都吃 CPU 算力，对双核四线程来说这是个权衡。但总比 OOM kill 掉容器好。

5.6 最大的经验

别自动更新。 内核、驱动、甚至 Docker 镜像，全部锁定版本、手动更新。服务器求稳不求新。你可以在桌面系统上追最新版，但服务器上，能跑就行。

6. 数据

7. 一句话总结

开发板是天生的服务器，笔记本是改造出来的服务器。合盖、电池、散热——三个开发板不存在的问题，旧笔记本全有。但解决完这三个，剩下的跟装系统没什么区别。

真正折磨人的不是装机，是三年里的日常维护。内核更新断网、驱动版本打架、磁盘悄悄坏掉——每一个坑都是事后才知道的。但这些经验，看十篇教程学不到。