搭过这套配置的人多半都有同感：E3老平台加上一张当年矿场退役的P106计算卡，本身都是别人眼里的电子垃圾，但放进PVE里做虚拟化之后，反而成了一套既能跑AI推理、又能扛网站流量的全能小服务器。这篇教程我会从硬件选型开始，一路走到PVE安装、GPU直通、AI环境搭建和建站整合，包括我自己踩过的坑和验证过的细节。适合手头正好有旧E3主板、不想再花大价钱换新平台、又想把这台机器变成7x24小时多用途服务器的朋友，原文里那些零散参数，我尽量整理成能直接照着操作的形式。

1. 为什么偏偏是E3+16G+P106？这套组合的性价比账本

1.1 E3“神U”到底神在哪儿

E3系列在DIY圈子里的地位不用多解释。当年它和桌面旗舰共用同一套核心设计，但价格便宜得多，唯一的代价是通常不能超频、部分型号需要搭配服务器或商用主板。放到今天，二手市场里一块带核显或者不带核显的E3，价格普遍只有几十到一百多，而它依然保有四核八线程，支持VT-x和VT-d两组虚拟化指令。

对PVE这种虚拟化平台来说，VT-d才是真正的关键。没有VT-d，后续想把P106直通给虚拟机就会非常痛苦，甚至根本插不进去。E3主板大多来自H81、B85、C226这类芯片组，虽然年代老，但基本都有完整的VT-d选项，这比很多消费级新平台把直通功能藏起来要好得多。再加上DDR3内存如今几乎是白菜价，四条插槽插满32G也花不了多少钱，作为折腾用的宿主平台非常舒服。

它的短板同样明显：单核性能放到现在只能算入门水平，内存带宽受限于DDR3-1600双通道，跑需要频繁交换显存的数据时会感到吃力。但AI推理这个场景很有意思，很多任务并不依赖单核性能，反而更看线程数量和显存容量，E3的八线程在这里能发挥出超出预期的表现。

1.2 16G内存够不够用

16G在今天的标准下确实不算宽裕，但在这套配置里是够用的，关键看你怎么分。我推荐的大致方案是：PVE宿主本身占用大约1G到2G，AI虚拟机分10G到12G，建站容器分2G到4G，剩下的留给缓存和突发。这样分配的前提是AI服务主要用于推理而不是训练，训练动辄需要十几G内存缓存数据集，16G会非常紧张。

如果只跑文本生成、接口服务、中小型网站，16G完全能做。如果打算跑图像生成类应用，模型权重会占用大量显存，显存放不下的部分必然往内存里溢，内存不足会导致速度急剧下降甚至进程被杀。这时候我会建议直接把内存升到32G，毕竟DDR3内存便宜，升级成本几乎可以忽略，收益却非常明显。

1.3 P106-100为什么适合当AI计算卡

P106-100用的是和GTX 1060同款的GP106核心，拥有6G GDDR5显存，计算能力和当年的甜品卡相当。它被矿场大量采购后，如今二手价格跌到了百元级，而且因为没有视频输出接口，普通用户不愿用，反而让它的价格一直上不去。对AI推理来说，视频输出接口本来就不需要，我们完全可以通过SSH或PVE的VNC控制台来管理虚拟机，所以P106这个“残疾”特性根本不是问题。

6G显存决定了它能跑的下限：常见的7B参数模型用4bit量化后大约需要4G多显存，刚好能塞进去；2B、3B级别的小模型更是游刃有余。再大的14B或更大模型就得靠内存溢出，速度会慢很多。所以在入手P106之前，先想清楚自己要跑什么规模的模型，6G显存能覆盖的范围是“入门级AI服务器”的天花板。

不过矿卡有矿卡的脾气。很多P106被矿场长期高负载摧残过，散热器里积灰严重，风扇策略也被改得乱七八糟，甚至有的被刷过第三方BIOS。拿到手之后建议先清灰、换硅脂，然后用软件查看实际温度和功耗，再决定要不要限制功耗墙。这一百多块钱花得值不值，完全取决于你愿不愿意花半小时做保养。

2. PVE底层搭建与直通前置准备

2.1 BIOS设置：一切虚拟化的前提

装PVE之前，先进主板BIOS把虚拟化相关选项打开。E3主板普遍有VT-x和VT-d两个开关，VT-x是CPU虚拟化，VT-d是设备直通功能，两者都要开启。有些主板把VT-d藏在“Advanced → System Agent Configuration”或“South Bridge”这类菜单里，翻箱倒柜找一下总能看到。

另外，老主板默认可能是Legacy引导模式。虽然PVE也能在Legacy模式下装，但后续维护和恢复不如UEFI方便，尤其是4G以上内存映射和PCIe直通空间分配的问题，UEFI模式更省心。如果主板支持UEFI，优先切到UEFI。还有一项叫做“Above 4G Decoding”或“大于4G地址空间解码”的选项，如果主板BIOS里有，务必打开，这对PCIe设备直通后的地址空间分配影响很大，不开启可能会导致直通后虚拟机启动异常。

2.2 安装PVE与第一次网络配置

下载最新版Proxmox VE的ISO，用写盘工具写入U盘，开机选择U盘启动进入安装界面。安装过程中会让你选择安装磁盘，这里我强烈建议把PVE系统装在一块独立的SSD上，至少128G。不要想着系统盘和数据盘共用一块硬盘，PVE本身有大量的日志写入和虚拟机快照，系统盘分离能省掉很多麻烦。

安装时的网络配置要特别留意：PVE的管理网口默认是第一个网口，通常设置为vmbr0网桥，IP地址根据你的局域网网段配置，网关和DNS也要填对。安装完成后通过浏览器访问“https://PVE的IP:8006”就能打开管理后台。老浏览器访问这个页面可能会有证书警告，直接继续访问即可，这是PVE自签名证书的正常现象。

装好系统后，第一件事是更换软件源。PVE默认的官方源在国内访问速度很慢，可以把源替换成自己常用的镜像源，具体方法取决于个人网络环境，一般就是修改/etc/apt/sources.list和/etc/apt/sources.list.d/pve-no-subscription.list这两个文件。替换完成后执行apt update，确保后续安装软件包时不会卡在网络这一步。

2.3 开启IOMMU内核参数

直通设备的核心是IOMMU。PVE默认不开启IOMMU，需要在引导参数里显式加上。修改/etc/default/grub文件，在GRUB_CMDLINE_LINUX_DEFAULT一行后面加入：

intel_iommu=on iommu=pt

iommu=pt表示只在直通场景下启用IOMMU，日常性能损耗更小。然后执行：

update-grub reboot

重启之后，用下面这条命令确认IOMMU已经生效：

dmesg | grep -e DMAR -e IOMMU

如果能看到类似“DMAR: IOMMU enabled”的日志，说明内核已经成功开启。接着检查一下IOMMU分组情况：

for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group $(basename $g)"; ls $g/devices; done

这个命令会把所有IOMMU分组的设备列出来。为什么要看分组？因为PCIe设备直通时，同一IOMMU分组里的设备必须一起直通给虚拟机，否则会失败。好在P106所在的PCIe插槽通常有独立分组，少见需要连带声卡一起直通的情况，确认一下总归没坏处。

3. P106直通与驱动打通：真正的第一道鬼门关

3.1 先建一个虚拟机骨架

PVE直通P106的第一步是创建一台虚拟机。我建议先装一个Ubuntu Server 22.04 LTS，理由后面会讲。创建虚拟机时，CPU类型选择“host”，这样虚拟机能直接用宿主CPU的完整指令集，对后续AI和编译类任务都有好处。核心数可以先给4核，内存给10G，磁盘给40G以上。

显示设备保持PVE默认的VNC，不要一开始就设置成无显示设备。为什么？因为安装系统的时候你还需要通过控制台看画面，等到系统装好、SSH能连上之后，再用VNC控制台也不会和P106冲突。P106直通后只是作为计算设备，不负责显示输出，虚拟机自己的虚拟显卡继续承担控制台画面，两者互不干扰。

创建完成后，在硬件设置里添加PCI设备，选择P106那一个设备。如果主板把音频控制器和显卡分在同一组里，一般需要一并勾选，否则启动时会报错。添加完成后确认启用PCI-Express选项，PCI设备使用PCIe模式更稳定。

3.2 安装NVIDIA驱动并验证CUDA

启动虚拟机，安装好Ubuntu Server后，第一件事就是安装NVIDIA驱动。直接使用系统自带的驱动源最稳：

sudo apt update sudo ubuntu-drivers devices sudo ubuntu-drivers autoinstall

自动安装会拉取一个相对合适的驱动版本。装完之后重启，再执行：

nvidia-smi

如果能看到P106的信息和显存容量，说明直通已经成功。这一步是整套配置的分水岭，走到这里，后面AI环境的搭建就是普通软件层面的工作了。

接着安装CUDA工具包。很多人会去官网下载一个巨大的runfile，其实在Ubuntu上直接安装发行版自带的工具包最省事：

sudo apt install nvidia-cuda-toolkit

装完之后可以用nvcc --version检查CUDA编译器版本。这里要提醒一句：如果你之后要跑需要特定CUDA版本的项目，最好先用Docker里的官方镜像，不要在这台机器上反复折腾不同版本的CUDA，否则很容易把驱动环境搞乱。

3.3 无显示输出与矿卡的体质问题

P106没有显示输出接口，所以就算直通成功，你也永远看不到它输出的画面，这不代表有问题。第一次测试直通是否成功，不要看显示器，直接看nvidia-smi的输出。

矿卡回来后，温度和功耗校验一定要做。执行：

nvidia-smi -q -d TEMPERATURE nvidia-smi -q -d POWER

如果待机温度就超过60度，那基本可以判断是散热器积灰或者硅脂干了，建议拆开清理。P106的散热器通常很简单，清理并不难，但注意显存和供电部分的灰尘也要一起处理。清理完重涂硅脂后，温度一般能下降十几度。

功耗方面，P106默认功耗墙大约120W，性能释放是够的。如果你对这台的散热没信心，或者电源瓦数比较紧，可以手动把功耗墙压到100W：

sudo nvidia-smi -pl 100

再有就是开启持久模式，减少驱动加载和唤醒的延迟：

sudo nvidia-smi -pm 1

3.4 直通失败的常见现象排查

直通失败最常见的有三种表现。第一种是虚拟机启动后控制台黑屏，这时候先检查VM的显示设备是不是被设置成了“无显示设备”，或者PCI设备有没有被误设成主GPU。排查方法是先移除P106直通，用VNC控制台正常启动系统，确认系统没问题后再重新添加PCI设备。

第二种是Windows系统下驱动报Error 43。这是因为NVIDIA驱动会检测虚拟机状态，故意屏蔽显卡。解决办法是在PVE的VM设置里把CPU类型设为host，然后在VM的配置文件/etc/pve/qemu-server/xxx.conf中追加隐藏KVM虚拟化特征的参数。Linux系统下基本不会遇到这个问题，所以初学者建议直接用Ubuntu，难度低很多。

第三种是重启主机后虚拟机里的GPU消失。先看PVE里的PCI设备是否还在，再看虚拟机是否设置了开机自启动。有时候主板的PCIe枚举顺序会变，导致设备编号变化，重新添加一次直通设备就能解决。

4. AI环境的两种装法：用VM还是LXC，哪种更省心

4.1 虚拟机与容器的选择逻辑

PVE里跑AI应用，其实有两条路线：一是继续用刚才的Ubuntu虚拟机，在虚拟机里装Docker跑模型；二是新建一个LXC容器，通过设备节点方式把GPU挂进容器里。这两条路我实际都试过，结论很明确：16G内存压力下，虚拟机的隔离性更稳，LXC确实更省资源，但GPU直通的坑更多。

虚拟机方案的优点是驱动完全独立，你在VM里随便装什么CUDA版本，都不会影响PVE宿主。缺点是内存浪费一点，Ubuntu Server加Docker大约需要额外占用1G到2G内存。LXC方案的优点是几乎零开销，CPU和内存配额可以直接压到很小，但GPU设备需要通过cgroup和mount entry手动映射，而且容器内驱动和宿主机内核模块必须严格匹配，否则设备节点虽然存在，但驱动加载不了，还是白搭。

我自己最后是选择VM + Docker的组合。理由很简单：AI环境最脆弱，模型推理框架、CUDA版本、系统库之间的依赖极其复杂，一旦环境被搞坏，重新配置的成本远超省下的那点内存。虚拟机把整个环境隔离起来，坏了直接回滚快照，省心很多。

4.2 在虚拟机里安装Docker并让容器使用GPU

登录Ubuntu虚拟机，安装Docker：

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh

然后安装NVIDIA容器工具包，让Docker能够识别GPU：

sudo apt install nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

配置完成后，用官方CUDA镜像验证GPU是否被Docker正确识别：

sudo docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi

如果这段命令能输出P106的信息，说明从宿主到虚拟机再到Docker的GPU链路已经全线打通。这个验证步骤非常关键，很多机器卡在“宿主动核显正常、虚拟机里nvidia-smi正常、但容器里看不到GPU”这个问题上，多半是nvidia-container-runtime没有配置成功，重跑一遍nvidia-ctk runtime configure基本能解决。

之后跑模型就成了常规操作。6G显存适合跑7B以下的量化模型，比如常见的4bit量化版7B模型，大约需要4G显存，P106可以稳跑。吞吐量虽然不能和RTX 4090比，但相比CPU推理依然是数量级的提升，日常测试和中小规模并发完全够用。

4.3 为什么我不推荐LXC跑AI

LXC跑AI不是不行，而是容易在细节上翻车。要把GPU挂进LXC，你需要修改容器配置文件，加入类似下面的条目：

lxc.cgroup2.devices.allow: c 195:* rwm lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file lxc.mount.entry: /dev/nvidia-modeset dev/nvidia-modeset none bind,optional,create=file

而且宿主机必须预先安装好NVIDIA驱动，容器里的驱动版本还必须与宿主机内核模块匹配。PVE宿主本身装NVIDIA驱动这件事就挺折腾，还会影响整个宿主系统的稳定性。除非你是LXC老手且内存紧张到必须省那1G，否则我不建议在这套配置里选LXC。

4.4 模型托管与内存策略

跑模型时，显存不够的部分会向内存溢出，16G内存的压力主要集中在AI虚拟机。我会在Docker启动命令里加上--shm-size=4g参数，因为PyTorch框架经常用共享内存做数据加载，默认的64M很容易不够用。平时不要把AI虚拟机的内存额度设满，留出1G左右给宿主和其余容器做缓冲，避免OOM把整台PVE弄卡死。

5. 建站部分与AI接口整合：一台机器干两件事

5.1 建站容器的资源规划

建站不一定要再开一台完整虚拟机，用LXC容器更合适。PVE的LXC模板可以直接下载Debian或Ubuntu的标准模板，创建容器时分配2核CPU和2G内存就足够应付中小流量网站。

创建并启动容器后，进入容器安装Nginx、PHP和MariaDB：

apt install nginx php-fpm mariadb-server

如果只是搭静态站或轻量博客，Nginx加PHP就够了。数据库虽然占内存，但MariaDB在小内存下可以通过调整performance_schema和缓冲区参数降到100M以内，2G内存完全够用。和AI虚拟机不同，网站容器追求的是稳定和低占用，用LXC放这里是最合适的。

5.2 用Nginx做反向代理，把AI接口收进内网

建好网站后，最自然的做法是把AI能力暴露成网站的一个子路径或子域名。比如AI服务在虚拟机里监听8000端口，网站这边通过Nginx反向代理统一收口：

server { listen 80; server_name ai.example.local; location / { proxy_pass http://192.168.1.20:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这样一来，外部访问网站时只看到80和443端口，AI后端服务不需要直接暴露公网，安全性高很多。如果以后需要HTTPS，用Caddy做自动证书管理比Nginx配证书简单得多，资源占用也不大，可以二选一。

5.3 同一块GPU怎么同时服务AI和网站

P106毕竟只有一张，如果网站本身也要调用AI接口，GPU的并发能力是有限的。建议把AI服务封装成一个HTTP接口，每次推理请求短小精悍，网站前端再把请求转发过来。对于轻量应用，比如文章摘要、智能搜索、对话机器人，P106完全能同时扛下，只要并发控制在个位数，每个请求的推理时间在几秒到几十秒量级，用户体验尚可。

真要面对高并发AI请求，这张卡就不够了，可以在后续升级时增加并行推理服务或换更高显存的卡。但“网站和AI共用一套资源”这个架构思路是正确的，老平台也扛得住。

6. 长期运行的资源调度与排坑清单

6.1 把CPU频率榨干的设置

PVE默认的CPU调频策略是保守模式，偏向省电，E3这种老CPU很容易跑在低频率上，响应变慢还不自知。装一个cpufrequtils工具把策略改成performance：

apt install cpufrequtils -y echo 'GOVERNOR="performance"' > /etc/default/cpufrequtils systemctl restart cpufrequtils

改完后可以用cpufreq-info确认当前策略。性能模式会让CPU始终工作在最高频率附近，带来的代价是功耗和温度略微上升，但对AI推理这类突发负载场景，体验提升非常明显。

6.2 内存防爆与PVE宿主保护

16G内存分给多个虚拟机之后，宿主本身的内存余量很薄。PVE默认会使用内存Ballooning技术，让虚拟机归还未用内存，但AI任务的特点是内存波动大，Ballooning机制有时反而会造成性能抖动。我建议AI虚拟机把内存设为固定分配，不要开Balloon；建站LXC可以开，因为它内存占用相对稳定。

接着在PVE宿主机设置一个最低空闲内存保护值，避免宿主内存被虚拟机和缓存吃光后卡死：

sysctl -w vm.min_free_kbytes=65536

写入到/etc/sysctl.conf后永久生效。这条配置会让系统提前预留64M内存用于应急分配，对整机稳定运行很有帮助。

6.3 温度、功耗与日常运维

P106要做好长期高温运行的准备。机箱内建议增加一个后排风扇，把GPU热量直接抽出去。日常监控可以用：

watch -n 1 nvidia-smi

在PVE宿主上，用lm-sensors查CPU温度：

apt install lm-sensors -y sensors

如果发现P106长期在70度以上运行，优先做三件事：清灰换硅脂、加机箱风道、用nvidia-smi -pl把功耗墙压低一档。这三步做完，温度通常能控制在60度上下，非常稳妥。

6.4 故障速查表

6.5 这套方案还能往哪里走

如果后续想把16G内存升级到32G，直接插满四条DDR3内存条即可，成本低见效快。PVE里可以继续添加更多LXC容器，比如监控系统、备份服务、开发测试环境。但GPU方面我不建议加第二张P106，老平台PCIe通道有限，双卡协作的收益远不如直接换一张高显存卡来得明显。模型规模提升到一定阶段后，整套平台的瓶颈会从显存转为CPU和内存带宽，那才是考虑更新换代的时候。

这套E3加P106的配置，我用下来最大的感受是：折腾的价值不在于硬件本身有多强，而是让你用最小的成本把虚拟化、GPU直通、容器编排、反向代理这一整条现代服务器技术栈完整跑了一遍。初次直通遇到问题时不要急着怀疑硬件，绝大多数问题出在BIOS设置和PVE配置上，按这个流程一步步走下来，稳定运行并不难。