本地跑大模型这件事，我从最早的 7B 量化版一路折腾到现在，中间换过三台机器，踩过的坑足够写一本小册子。这次的主角是极摩客 EVO-X3 这类迷你主机——18cm 见方、巴掌大一个金属盒子，塞进的是 12 核移动端处理器和一块共享内存的核显，最高能上 128GB 板载内存。标题里说的“无头部署 DeepSeek-V4，迷你主机变身本地 AI 推理服务器”，说白了就是：不接显示器、不插键鼠，机器通电就干活，局域网里任何一台设备通过接口调用它。这件事的价值不在于省钱，而在于数据不出门、服务不掉线、想什么时候用就什么时候用。适合谁看？手上有或者准备入手这类大内存迷你主机的人、想把本地模型变成“家里的一台服务器”而不是“桌面上的一次性实验”的人，以及被云端按 token 计费搞得心疼的人。下面我把整套思路、参数计算、实操命令和踩坑记录全部摊开讲。

1. 从“加台机器”到“加台服务器”：需求与硬件画像

1.1 我为什么执意要把推理放到本地

先说清楚动机，不然很容易变成“为了折腾而折腾”。我日常对模型的使用分三类：一是长文档的摘要、改写、结构化抽取，二是代码片段的解释和补全，三是些不适合往外发的内部资料整理。前两类云端完全够用，第三类不行——不是不信任谁，而是流程上就不该让原始文件离开本地网络。这类需求占比不算高，但每次遇到都得手动切来切去，体验很差。

本地推理解决的核心问题就三个字：可控性。模型权重在本地盘上，输入输出不经过任何外部链路，上下文多长、并发几个、什么时候关机，全由自己说了算。代价也很明确：速度比云端慢一个数量级，模型规模受硬件限制，以及最烦的一点——你得自己维护它。所以我的判断标准很简单：如果你的使用场景里有 30% 以上是“内容不方便外传”，或者你每天调用次数多到云端账单开始扎眼，本地推理就值得投入；否则老老实实用云端，别浪费时间。

这台机器的定位也因此清晰了：它不是替代云端的主力，而是补位。平时闲置，需要的时候通过局域网接口调一下，一次请求等个十几二十秒，能接受。

1.2 EVO-X3 这类机器的硬件底牌与天花板

这类迷你主机的配置结构很有代表性，我按自己的理解拆一下，因为后面所有参数选择都建立在这张硬件画像上。

关键要理解的是“统一内存”这个概念。台式机显卡有独立的显存颗粒，带宽动辄几百 GB/s 到上 TB/s；迷你主机的核显没有自己的显存，它和 CPU 共用同一块内存，靠 BIOS 里划出一部分（UMA Frame Buffer）当作“显存”用。这块内存的带宽怎么算？LPDDR5X-7500 表示每秒 7500 百万次传输，位宽 64 bit 即 8 字节，双通道就是两条：

7500 × 10^6 × 8 × 2 ≈ 120 GB/s（理论峰值）

实际能跑到 100 GB/s 出头就算不错。这个数字是整台机器的命门——大模型推理的解码阶段（也就是一个字一个字往外吐的阶段）本质上是“内存带宽受限”的活：每生成一个 token，都要把参与计算的权重完整读一遍。所以理论速度上限约等于：

每秒 token 数 ≈ 内存带宽 ÷ 单个 token 需要读取的权重大小

拿一个 8B 参数、4bit 量化的模型举例，权重大约 4.9GB，120 ÷ 4.9 ≈ 24 tok/s，这是天花板；实际受调度、KV cache 读写、核显算力限制，跑到 12～18 tok/s 是正常水平。这个估算方法你务必记住，它能让你在下载模型之前就判断“这玩意儿我能不能跑得动”，而不是下完 40GB 才发现加载失败。

至于标题里的 DeepSeek-V4，我的态度是先泼一盆冷水：这类旗舰模型的完整权重动辄几百 GB 起步，还是 MoE 结构，激活参数就远超这台机器的能力边界。可行路径有两条——一是等官方放出的小尺寸版本或蒸馏版，二是在社区量化版里挑参数量在 30B 以内、且量化到 4bit 后能塞进内存的版本。我的建议是先拿一个 8B～14B 的同类模型把整条链路跑通，等大模型的量化版成熟了再换，否则你会卡在“模型加载失败”这一步，连服务都搭不起来。

1.3 无头部署：省下的不只是显示器

“无头”（headless）这个词很多人第一次听会懵，其实就是不接显示器和键鼠，机器只通过网络访问。听起来像是省钱的小技巧，实际上是把它从“一台电脑”变成“一台设备”的分水岭。

接了显示器的机器，你会不自觉地把它当电脑用：装桌面环境、开浏览器、挂一堆自启软件，最后内存被吃掉几个 GB，风扇整天转。无头之后，系统里只有内核、SSH 服务和推理进程，空闲内存占用能压到 1GB 以内，这些省下来的内存全部可以让给模型。更实际的好处是：机器可以塞在电视柜后面、书架顶上、弱电箱旁边，只要有一根网线和电源，放哪儿都行。

代价也得说清楚。第一，所有故障排查都靠命令行，出问题时你没有“看一眼屏幕”这个选项，所以日志和开机自启必须提前配好。第二，BIOS 设置、系统安装这两个阶段还是得接一次显示器（或者用串口），装完才能拔。第三，一旦网络配置写错，机器就彻底失联，必须留后手（后面会讲）。

2. 方案设计：系统、推理栈与量化的三重取舍

2.1 系统选型：Server 版省事，桌面版省心，怎么选

这一步的选择会决定后面 80% 的麻烦程度。我试过三条路，给你摆出来对比。

我最终选的是 Ubuntu Server 的 LTS 版本。理由不复杂：这个系统的生命周期长、软件源里该有的都有、遇到问题搜出来的答案不会过时。装的时候有个细节要注意——安装镜像里默认不会勾选 OpenSSH 服务，一定要在安装向导里手动勾上，否则装完重启，机器就成了一个没有入口的黑盒，你还得重新接显示器。

还有个小坑：这类迷你主机用的是较新的核显架构，太老的内核认不全硬件。LTS 版本要确认内核版本在 6.8 以上，装完之后跑一下uname -r看一眼。如果内核偏旧，显卡跑不起来，就只能退化到纯 CPU 推理，速度直接砍半。

2.2 推理引擎：Vulkan 最省事，ROCm 最能折腾

推理引擎这块，我实际对比了三条路线，结论很明确：在核显上，Vulkan 后端是性价比最高的选择。

• Vulkan 后端：跨平台图形接口，核显天然支持，编译时打开开关就行，不需要折腾驱动版本匹配。实测在这类 RDNA3.5 核显上能吃到大部分算力，是“今天就能跑起来”的方案。
• ROCm 后端：理论上更贴近硬件，但对核显的支持一直是“能用但不保证”，需要手动指定架构代号、装特定版本的运行时，版本一升级就可能崩。我折腾了两个晚上，跑通了，但速度优势不明显，后来放弃了。
• 纯 CPU 后端：最稳，任何机器都能跑，但 12 核移动端处理器跑 8B 模型的量化版，速度大概只有核显的三分之一到一半。它的真正价值是兜底——当核显出问题时，你至少还有一个能用的方案。

所以我的方案是：主用 Vulkan，CPU 后端编译好放着当备胎。两者用同一个引擎的同一份代码，只是编译参数不同，切换成本极低。这里说的引擎选的是社区里最常用的那个 C++ 推理框架（llama.cpp 系），它的好处是单文件模型格式、自带 HTTP 服务端、OpenAI 兼容接口，一站式解决“加载”和“提供服务”两件事。

2.3 量化格式与体积测算：下载之前先把账算清

量化这个词听着玄，其实很好理解：模型权重原本用 16 位浮点数存储，量化就是用更少的位数近似表示，精度损失一点，体积和带宽需求大幅下降。常见档位和我的实测体感如下。

体积的估算公式很简单：

模型体积 ≈ 参数量 × 每参数量化后字节数

比如 14B 模型用 Q4_K_M：14 × 0.61 ≈ 8.5GB。加上 KV cache、上下文缓冲、系统占用，实际内存需求要在这个基础上再加 30%～50%。这台机器如果是 64GB 版本，跑 30B 级别的 Q4 量化模型是可行的；128GB 版本可以挑战更大的模型，但记住带宽没变，模型越大速度越慢，容量和速度是两条独立的曲线。

另外要留一笔内存给 KV cache。它的大小跟上下文长度成正比，估算方式是：

KV cache ≈ 2 × 层数 × KV 头数 × 每头维度 × 上下文长度 × 每元素字节数

举个具体的：某模型 40 层、8 组 KV 头、每头 128 维、上下文 16384、KV 用 8bit 存储，算下来大约 2 × 40 × 8 × 128 × 16384 × 1 ≈ 1.3GB。如果你把上下文开到 65536，这个数字就变成 5GB 以上，很容易成为压垮内存的最后一根稻草。所以上下文长度不要拍脑袋设，先算再设。

3. 无头环境从零搭建

3.1 BIOS 里必须改的四个地方

装机第一步，接上显示器进 BIOS。这一步做不好，后面全是坑。我按重要性排序。

第一，通电自启。找Restore on AC Power Loss或类似的选项，设成Power On。这个设置决定了停电恢复后机器会不会自己开机。没有它，一次跳闸你就得手动按电源键，无头部署就名存实亡了。

第二，显存分配（UMA Frame Buffer Size）。一般选项是 512MB 到 32GB 几档。设太小，核显分到的“显存”不够，模型权重放不进去会退化到 CPU；设太大，系统可用内存变少。我的经验值是：跑 8B～14B 模型设 16GB，跑 30B 级别设 32GB。注意这个分配不是“独占”，系统有需要时还能回收一部分，但给足总是更保险。

第三，风扇策略。默认策略通常偏静音，连续推理十分钟核显温度上去就降频。找Fan Control相关选项，切到性能模式。噪音会增加，但机器放在柜子里，问题不大。

第四，安全启动（Secure Boot）。装 Linux 建议先关掉，省得后续加载第三方驱动时被拦。装完系统、确认一切正常后想开再开。

顺便把启动顺序调一下，U 盘第一，装完再改回硬盘。这些改完记得保存退出，然后就可以开始装系统了。

3.2 系统安装与 SSH 接管

安装向导本身没什么好讲的，重点说三个容易翻车的地方。

第一，分区。模型文件动辄几十 GB，系统盘千万别只给 100GB。我的做法是系统盘分 200GB，剩下空间单独挂载到/data目录专门放模型。用 LVM 或者直接分区都行，但一定要想清楚，因为模型下到一半发现盘满了是非常难受的体验。

第二，网络配置。安装时要么用 DHCP 拿地址，要么直接写死静态 IP。我建议这里先用 DHCP 把系统装完，进系统后再改成静态，因为安装界面里手滑打错一个数字，装完就上不了网，还得重装。

第三，OpenSSH。安装界面有个复选框，一定要勾。这是唯一一次“顺手就能做对”的机会。

系统装完重启，在另一台电脑上打开终端：

ssh 用户名@机器IP

能进去就说明无头部署的第一阶段成了。接下来立刻做三件事：更新系统（sudo apt update && sudo apt full-upgrade -y）、检查内核版本（uname -r）、确认核显被识别（lspci | grep -i vga）。这三条都正常，才可以拔显示器。

提示：拔显示器之前，务必先用sudo reboot重启一次，重启后还能 SSH 上去，才算真正验证通过。有些人（包括我第一次）是热插拔显示器直接断电，结果 BIOS 报错，白跑一趟。

3.3 网络固定与远程访问：给自己留条后路

IP 地址变来变去是服务器的大忌。用 netplan 配置静态地址，配置文件在/etc/netplan/目录下：

network: version: 2 ethernets: eth0: dhcp4: false addresses: - 192.168.1.50/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [192.168.1.1, 223.5.5.5]

改完执行sudo netplan apply，然后别急着关当前连接，另开一个终端重新 SSH 一次，确认新地址能连上再退出。

后手怎么留？最土但最有效的办法：把机器的 MAC 地址记下来，在路由器的管理界面里给它做 DHCP 绑定，这样即使系统的静态配置写错了，路由器还能给它一个固定地址。另一个办法是接一个串口控制台或者 HDMI 采集卡，但一般家庭环境没必要。

服务要对外提供接口，就得让局域网里的其他设备能访问。我的原则是：只在局域网内提供服务，绝不做公网映射。这不是技术能力问题，是风险收益比的问题——把一台没有任何安全加固的推理服务器暴露到公网，等于把家门钥匙插在门锁上。

4. 推理服务落地：从跑通到常驻

4.1 编译带 Vulkan 后端的推理引擎

依赖装齐再编译，能省掉一堆报错：

sudo apt install -y build-essential cmake git libvulkan-dev vulkan-tools glslc

装完先用vulkaninfo | head -40确认 Vulkan 环境正常，能看到设备信息再往下走。然后拉代码、编译：

git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release cmake --build build -j$(nproc)

-DGGML_VULKAN=ON是开关，Release是必须的，用 Debug 模式编译出来的版本慢到没法用。编译大概十几分钟，期间风扇会转得比较凶，正常。

编译完验证一下后端有没有识别到设备：

./build/bin/llama-bench --help

能正常输出帮助就说明二进制没问题。真正的验证在加载模型时，日志里会打印出一行类似ggml_vulkan: Found 1 Vulkan devices的信息，看到这行才算 Vulkan 真的生效了。如果没有，八成是驱动或者权限问题，先跑vulkaninfo排查。

4.2 模型下载与首次加载

模型文件建议放到/data/models下，用命令行工具从模型仓库拉：

mkdir -p /data/models && cd /data/models # 以支持断点续传的工具拉取单个 GGUF 文件

文件名里通常带量化档位标识，比如...-Q4_K_M.gguf，认准这个后缀别下错。第一次跑，参数不要贪多，先把最简配置跑通：

./build/bin/llama-cli \ -m /data/models/model-Q4_K_M.gguf \ -ngl 99 \ -c 4096 \ -p "用三句话解释什么是内存带宽"

-ngl 99的意思是把所有层都放到 GPU（这里就是核显）上，99 是个足够大的数字，实际会按层数自动截断。-c 4096是上下文长度，先用小的跑通再说。

如果这一步报内存不足或者卡死，按顺序排查：先把-ngl改成 20 试试，能跑说明是显存分配不够，去 BIOS 调大 UMA；再把-c降到 2048；还不行就说明模型太大，换小一号的量化档位。

跑通之后，用内置的基准测试工具测一下真实速度：

./build/bin/llama-bench -m /data/models/model-Q4_K_M.gguf -ngl 99 -p 512 -n 128

它会分别给出“提示处理速度”（pp）和“生成速度”（tg），后者就是我们最关心的 token/s。记下这个数，换配置对比时才有依据。

4.3 参数调优：上下文、批大小与线程数

跑通和跑好是两回事。这几个参数我反复调过很多轮，结论如下。

上下文长度（-c）。不是越大越好。开大了 KV cache 占内存，而且在核显上，长上下文的注意力计算会显著拖慢速度。我的经验：日常问答 8192 够用，长文档处理开 16384，再往上就要算内存账了。

批大小（-b / -ub）。批量处理提示词时，一次喂多少 token。默认值偏保守，可以往上调。但注意这个值调太大，内存峰值会冲高，在共享内存的机器上容易触发 OOM。我的做法是从 512 起，每次翻倍测速度，找到拐点就停。

KV cache 量化（-ctk q8_0 -ctv q8_0）。这个技巧非常值钱：把 KV cache 从 16 位降到 8 位，内存占用直接减半，质量损失几乎感知不到。长上下文场景下，这一项能让你多开一倍的上下文。

线程数（-t）。混合架构的处理器有大核小核，全开反而可能因为调度抖动变慢。我的做法是设成物理大核数，在这台机器上大概是 6～8，而不是 24。

MoE 模型的专家层卸载。如果你跑的是 MoE 结构的模型，有个非常实用的参数可以把“专家层”放到 CPU 上算，把注意力层留在核显上，用 CPU 的大容量内存弥补显存的不足。这类模型的激活参数少，即使部分层在 CPU 上，速度也能接受。具体参数名在不同版本里略有差异，编译完跑--help | grep -i moe查一下当前版本支持什么写法。

4.4 常驻服务与开机自启

命令行跑通之后，要变成“服务”。最省事的办法是用引擎自带的服务端二进制，配合 systemd 托管。

先写服务配置文件/etc/systemd/system/llm.service：

[Unit] Description=Local LLM Inference Server After=network-online.target Wants=network-online.target [Service] Type=simple User=youruser WorkingDirectory=/opt/llama.cpp Environment="GGML_VK_VISIBLE_DEVICES=0" ExecStart=/opt/llama.cpp/build/bin/llama-server \ -m /data/models/model-Q4_K_M.gguf \ -c 16384 \ -ngl 99 \ -ctk q8_0 -ctv q8_0 \ --host 0.0.0.0 --port 8080 \ -np 2 \ --jinja Restart=always RestartSec=10 StandardOutput=append:/var/log/llm.log StandardError=append:/var/log/llm.log [Install] WantedBy=multi-user.target

几个要点解释一下。Restart=always保证进程崩了自动拉起，这是无人值守的底线。RestartSec=10别设太小，模型加载本身就要几十秒，重启太快会陷入死循环。-np 2是并发槽位数，设成 2 意味着可以同时处理两个请求，每个请求分到一半的上下文，按需调整。--jinja让模型自带的对话模板生效，不然格式可能对不上。

启用并检查：

sudo systemctl daemon-reload sudo systemctl enable --now llm.service sudo systemctl status llm.service journalctl -u llm.service -f

status显示 active 且日志里出现“listening on 0.0.0.0:8080”，就说明服务起来了。重启一次机器，再确认服务自动启动，这一步过了，无头部署才算真正完成。

4.5 局域网接口接入：让别的设备用起来

服务端默认提供 OpenAI 兼容的接口，任何支持自定义接口的客户端都能接。先在自己电脑上验证：

curl http://192.168.1.50:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "local", "messages": [{"role": "user", "content": "你好，做个自我介绍"}], "stream": true }'

能流式返回就说明链路通了。客户端配置时，接口地址填http://192.168.1.50:8080/v1，API Key 随便填一个非空字符串（本地服务通常不校验，但有些客户端要求必填），模型名填服务端启动时打印的那个名字。

如果你想让多个服务共用一个入口，可以在前面加一层轻量的转发层做端口统一和路径区分，但别做公网映射。另外记得在系统里开一下防火墙：

sudo ufw allow from 192.168.1.0/24 to any port 8080 sudo ufw enable

只放行局域网网段，比一刀切开放端口安全得多。

5. 实测数据与瓶颈分析

5.1 我在不同配置下的实测记录

下面这组数据是在同一台机器（64GB 内存版本、Vulkan 后端、上下文 8192）上跑出来的，模型名做了模糊处理，但参数量和量化档位是真实的，你可以拿来对照自己的机器。

“提示处理速度”和“生成速度”这两个概念要分清。前者是你贴进去一大段文字、模型读完并开始出字之前的那段等待，它受算力限制；后者是逐字输出的速度，受内存带宽限制。很多人抱怨“慢”，其实是提示处理阶段慢——贴了五千字进去，等半分钟才出第一个字。解决办法是缩短输入，或者接受它。

5.2 瓶颈到底在哪：三个层面依次排查

第一个层面是带宽。这是硬瓶颈，改不了。生成速度上不去，先算理论值：内存带宽除以权重体积。如果你的实测值低于理论值的 50%，说明还有优化空间；如果已经到 70% 以上，那就是到顶了，别折腾了，换更小的模型才是正解。

第二个层面是显存容量。表现是加载时报错，或者日志里出现“offload 到 CPU”的字样。用-ngl逐层下调测试，找到能完整加载的最大层数。注意部分卸载不是不行，只是速度会掉，掉多少要看被卸载的是哪些层——注意力层卸载损失大，专家层卸载损失小。

第三个层面是热降频。连续跑十几分钟之后速度突然腰斩，八成是温度墙。用sensors命令监控温度，或者直接在推理时观察风扇转速。这类迷你主机的散热能力有限，能做的改进是把机器立起来放（增加底部进风）、换相变硅脂、或者在 BIOS 里把功耗墙适当调低换取持续性能。

5.3 常见故障速查表

这张表是我两个多月里攒下来的，按“症状 → 可能原因 → 处理方式”排列，遇到问题先扫一眼。

注意：日志是你的第一手线索。journalctl -u llm.service -n 100看最近一百行，绝大多数问题都能在里面找到直接答案，比在网上乱搜快得多。

6. 长期运行与维护经验

6.1 散热、功耗与“能不能一直开着”

这类迷你主机的 TDP 通常在 45W～65W 之间可调，满载时整机功耗大概 65W～85W。按每天满负荷跑 4 小时算，一个月电费也就十几块钱，不用纠结。真正要关注的是散热能不能扛住长期运行。

我的做法比较粗暴：机器竖放，底部垫四个橡胶脚垫抬高 1.5cm，让进风口有足够空间；BIOS 风扇策略切性能模式；然后在系统里装个温度监控，用sensors定时采样写日志。跑了两周之后回头看曲线，如果温度长期在 85 度以上，就得考虑降压或者限制功耗了。

另一个容易被忽略的是硬盘温度。M.2 固态硬盘在持续读写模型文件时温度不低，有些主机的硬盘位在核显正上方，被烤得很厉害。装的时候顺手贴个薄散热片，成本几块钱。

6.2 升级策略：模型和引擎都要有退路

推理引擎的代码更新非常快，新版本经常带来性能提升或者新特性支持，但也可能引入回归。我的做法是：编译好的二进制按版本号保留两份，服务配置指向其中一份，升级时只改配置里的路径，出问题一条命令切回去。

模型文件同理。新模型下载到一个带版本号的目录里，先用命令行工具测一遍速度和质量，满意了再改服务配置。千万别直接覆盖正在用的模型文件——有一次我覆盖到一半断网，文件损坏，服务反复重启，排查了半小时才发现是文件本身的问题。

# 用校验和验证下载完整性，这一步别省 sha256sum /data/models/model-Q4_K_M.gguf

磁盘空间也要盯着。模型文件体积大，下几个就上百 GB，df -h养成习惯看一眼。我的做法是保留两个常用模型，其余的下完测完就删，需要时再下。

6.3 几条踩坑之后才明白的道理

第一条，别追求一步到位。我见过太多人一上来就想跑最大的模型，结果卡在加载失败，热情直接浇灭。正确的顺序是：4B 跑通 → 8B 调优 → 测速记录基线 → 再考虑更大的。每一步都留下可回退的状态，心里才有底。

第二条，理论速度先算再测。算出理论值，你就知道自己的实测成绩是好是坏，也知道该往哪个方向优化。没有这个基准，所有的“调优”都是瞎试。

第三条，无头部署的可靠性全靠“自愈”设计。服务崩了自动拉起、机器断电自动开机、日志落盘可追溯——这三件事做到位，你才能真的把它当成一台设备而不是一台需要照顾的电脑。

第四条，上下文长度是最容易被滥用的参数。很多人为了“能塞进整本书”把上下文开到最大，结果内存爆掉、速度暴跌，实际用起来还不如分段处理。我现在的习惯是把长文档切成 2000 字左右的片段，逐段处理再汇总，速度快、内存省、结果还更准。

最后分享一个小技巧：给这台机器在路由器里固定一个好记的主机名，然后在所有客户端的配置里用主机名而不是 IP。这样以后换网段、换路由器，都不用挨个改配置。这个习惯我在任何本地服务上都会用，省下的重复劳动远超想象。