1. 先把边界说清楚迷你主机跑本地推理到底图什么迷你主机做无头部署、跑本地 AI 推理服务器这件事在最近一年从小众折腾变成了挺正经的方案。标题里提到的这台 EVO-X3本质上是一台把统一内存做到百 GB 级别的 x86 小盒子配上 DeepSeek-V4 这一代模型的量化版本能在一张巴掌大的主板上跑出一个对内网开放的推理接口。听起来很唬人但我先把话放在前面它能干什么、不能干什么边界比参数表重要得多。无头部署指的是不装桌面环境机器开机只跑服务靠 SSH 和 API 打交道本地推理服务器指的是模型权重、推理进程、请求队列全在你自己的机器上一个 token 都不出去。先说我为什么要在这个时间点折腾它。很多人对本地推理的第一印象是有张显卡就行但真正卡住落地的从来不是显卡而是三件事数据能不能出去、断网还能不能用、长期跑下来电费和折旧划不划算。三件事里只要有一件是硬约束本地推理就从玩具变成了必需品。我做过的几个场景里一类是内部文档要过模型做结构化抽取文档本身不能离开机房一类是工地、船舱、展会这种网络时有时无的环境需要现场就能问答的知识库还有一类是团队天天在调提示词走云端接口一天几百上千次调用账单看着心疼。这三类需求指向的硬件形态其实是同一个低功耗、能长期开着、噪音小、不占机架。迷你主机恰好卡在这个生态位上。台式机功耗高、噪音大服务器噪音直接劝退办公室场景笔记本又没法长期满载。而这种统一内存架构的小盒子满载功耗控制在两百瓦上下放在书架角落风扇声比空调还轻。这是它能进办公室、进实验室工作台、甚至进家里的核心原因跟性能参数关系不大。1.1 三类需求对应三种完全不同的部署姿势我把常见需求拆成三类因为它们的部署姿势差别很大搞混了会白折腾。第一类是隐私刚需型。这种场景下你不需要模型有多聪明需要的是数据绝对不出去这个事实本身。典型做法是把模型跑在内存里关闭所有出网能力接口只监听内网地址日志里连请求体都不落盘。这类部署对性能的要求其实很低一个 30B 级别的量化模型就够用重点在权限、审计和隔离。第二类是离线可用型。网络不稳定不是慢一点而是完全停摆。这类场景要重点考虑的是启动速度和断电恢复机器必须能在没人操作的情况下自己爬起来、自己加载模型、自己恢复服务。我在一个临时搭建的现场环境里踩过坑机器断电重启后服务没起来因为模型加载要等磁盘预热systemd 的超时设置太短进程被杀。后来把TimeoutStartSec调到 600 秒才解决。第三类是成本敏感型。这类用户其实有网络也有 API 可用只是调用量太大。这时候要算的不是能不能跑而是跑得值不值。一台机器一次性投入按三年折旧加上电费对比云端按 token 计费的账单盈亏平衡点大概在每天几千到上万次中等长度请求之间。低于这个量老老实实用 API 更省心高于这个量本地部署的优势才开始显现。提示在动手买机器之前先老实统计一周的真实调用量。很多人凭感觉估的量和实际差十倍结果买了一台跑不满的机器或者买了一台不够用的机器。1.2 无头部署省下的不只是内存无头这两个字经常被轻描淡写地带过但它对推理性能的实际影响比想象中大。一个完整的桌面环境光是窗口管理器、合成器、浏览器后台进程空载就要吃掉 1.5 到 2.5 GB 内存。在统一内存架构上这部分内存和推理可用内存是同一块池子省下来就是实打实的可用空间。更要命的是合成器会占用一部分 GPU 资源虽然不多但在显存本来就紧张的情况下每一百兆都是钱。第二个好处是不会被打断。桌面系统有休眠、有锁屏、有自动更新、有通知弹窗这些东西在跑长任务的时候全是干扰源。无头系统没有这些开机进 multi-user.target跑完就算了。我见过最离谱的一次是桌面环境自动进入休眠把一个跑了四十分钟的批量任务直接冻住第二天早上才发现。第三个好处是可复现。无头部署的所有配置都在配置文件里机器挂了换一台把配置和模型拷过去十分钟就能恢复。带桌面的机器你永远不知道是哪次手动点击改变了某个状态。代价也要说清楚排障全靠日志。没有图形界面你看不到弹了个错误框只能journalctl -u 服务名 -f一行行看。所以无头部署的第一课不是装模型是把日志体系先搭好。1.3 硬件底子统一内存是优势也是天花板这类机器的架构特点值得单独讲因为它决定了你能跑多大的模型。它用的是统一内存架构CPU 和核显共享同一块 LPDDR5X 内存池容量能做到 128 GB 这个级别。对比传统独显方案好处是显存可以按需分配今天跑 30B 模型给 40 GB明天跑 70B 给 90 GB改个参数重启就行不用换硬件。坏处是内存带宽被焊死了这一代 LPDDR5X 的实测有效带宽大概在 200 GB/s 上下而一张高端独显的显存带宽是它的五倍。这个差距直接决定了推理速度。大模型解码阶段也就是一个 token 一个 token 往外蹦的阶段是典型的内存带宽受限任务每生成一个 token都要把参与计算的权重从内存搬到计算单元一遍。所以速度上限约等于理论 tokens/s ≈ 有效内存带宽 ÷ 每 token 需要读取的字节数每 token 需要读取的字节数约等于参与计算的参数量乘以每参数字节数。举个具体的一个稠密 32B 模型用 4 bit 量化权重约 19 GB按 200 GB/s 带宽算理论上限大概 10 tokens/s。实测通常会打到 7 到 9因为还有 KV cache 读写、调度开销、采样开销。如果是 MoE 架构混合专家情况会好很多因为每个 token 只走一部分专家实际读取的权重远小于总参数量。这就是为什么有些总参数上百 B 的 MoE 模型在这类机器上反而比稠密 70B 跑得快。所以判断一台机器能不能跑某个模型别只看总参数量要看激活参数量和量化后的实际体积。这两个数才是决定速度的关键。2. 从开箱到能 SSH 登录无头化的第一步新机器到手绝大多数人的第一反应是接显示器装系统。我建议换个顺序先接一次显示器把 BIOS 和启动盘搞定之后就再也不接显示器了。这不是为了省一根线而是强迫自己从第一天就用远程方式管理避免养成反正能接屏幕的依赖。这一步的核心目标有三个让机器能自己开机、能自己联网、能被远程登录。三个都做到了后面才有得谈。2.1 BIOS 里那几个必须改的选项统一内存架构的机器BIOS 里会有一个显存分配的选项不同厂商叫法不一样常见的是 UMA Frame Buffer Size、iGPU Memory、Shared Memory 之类。默认值通常很小比如 512 MB 或者 2 GB因为厂商预设你是拿来接显示器办公的。跑推理必须把这个值调大。但也不是越大越好这里有个容易踩的坑这块被划走的显存操作系统是看不见的。你划 64 GB 给核显系统里free -h就只剩 64 GB 可用而这 64 GB 只能用给图形和计算不能给普通进程用。如果你的推理框架是通过某种方式吃系统内存的划太多反而浪费。我的建议是分两步走。先把 Frame Buffer 设成一个中等值比如 16 GB 到 32 GB保证系统能正常启动、能跑基础图形。剩下的大头交给 GTTGraphics Translation Table也就是让核显可以动态借用系统内存。Linux 下这个上限可以通过内核参数调# 编辑 GRUB 配置 sudo nano /etc/default/grub # 在 GRUB_CMDLINE_LINUX_DEFAULT 里追加单位是 MB # 96 GB 的 GTT 上限 GRUB_CMDLINE_LINUX_DEFAULTquiet amdgpu.gttsize98304 # 更新并重启 sudo update-grub sudo reboot重启后用dmesg | grep -i gtt确认生效。这个做法的好处是内存分配灵活坏处是动态借用有额外开销而且部分框架对 GTT 的支持不如对固定显存好。还有一个必须改的断电恢复策略。BIOS 里找 Restore on AC Power Loss 或者类似选项设成 Power On。这台机器大概率是放在角落里长期无人值守的停电恢复后如果还要人去按电源键那它就不算服务器。顺手把风扇策略也看一眼。默认策略通常是安静优先跑推理的时候温度会顶到墙然后降频。有些机器的 BIOS 里有性能模式或者可以在系统里通过platform_profile切换。这个后面第 5 章细说。2.2 系统选择轻量发行版比你想的重要无头服务器的系统选择我倾向两条路一条是服务器发行版的最小化安装另一条是滚动更新的轻量发行版。服务器发行版的好处是内核和驱动经过充分测试包管理保守不会某天早上一更新就把推理环境搞崩。缺点是内核版本可能偏旧对新硬件的核显支持不够及时。这类统一内存的新平台往往需要比较新的内核才能正确识别核显和内存拓扑。滚动更新的发行版好处是硬件支持跟得快新版内核和 Mesa 一出就能用上。缺点是你得管住手别在跑着生产任务的时候pacman -Syu。我的实际做法是装最小化系统不装任何桌面环境然后在安装时勾选 SSH 服务。装完第一件事是升级到最新内核确认lspci能看到核显、lsmod能看到amdgpu模块加载、dmesg里没有一堆报错。这三件事确认完硬件层就算通了。系统装好之后有几个必做的收尾动作# 确认核显被正确识别 lspci | grep -i vga # 确认驱动模块加载 lsmod | grep amdgpu # 查看显存和 GTT 情况 sudo dmesg | grep -iE amdgpu|gtt|vram如果amdgpu没加载大概率是内核太旧或者被 nomodeset 之类的参数挡住了。这个坑很常见尤其是用旧镜像装系统的时候。2.3 无头环境的四件套配置能 SSH 登录只是开始要让它像个服务器一样活着还得配四样东西。固定地址。动态分配地址在路由器重启后会变每次都要去查 IP非常烦。给机器配静态地址或者在路由器上做地址绑定。我偏好后者因为配置集中在路由器上换机器不用改系统配置。SSH 加固。至少做三件事禁用密码登录只留密钥、改掉默认端口不是为了安全是为了少看日志噪音、开启ClientAliveInterval防止长连接被中间设备掐断。第三点在做长时间日志跟踪的时候特别有用。时间同步。听起来无关紧要但日志时间戳不准会让排障变成灾难。启用systemd-timesyncd或者 chrony确认timedatectl输出里 System clock synchronized 是 yes。温度与风扇的基础监控。装lm-sensors跑一次sensors-detect确认能读出 CPU 温度和风扇转速。这是后面调优的基础数据。注意不要在无头机器上装任何带图形依赖的监控面板。有些面板看着方便实际会拉起一整套 X 或者 Wayland 依赖白白吃掉几百兆内存和一部分核显资源。命令行监控工具够用了。3. 推理栈怎么选三条路线和它们的真实代价模型跑起来之前先要选一个推理框架。这一步的选择会直接影响后面所有的调优空间而且换框架的成本比想象中高因为模型格式、参数命名、接口协议都不一样。市面上主流的路线大致三条通用的 C/C 推理引擎、打包好的一体化服务、面向高并发的批处理框架。三条路线的适用场景差别很大不是哪个先进用哪个。3.1 三条路线的取舍路线典型代表上手难度显存控制粒度多并发能力适合谁底层推理引擎llama.cpp 系列中等极细逐层可调一般想榨性能、要精细控制一体化服务Ollama 这类封装低中等一般快速验证、单人或小团队批处理框架vLLM 这类高较粗强多人共享、要求高吞吐我自己的路径是先用一体化服务验证硬件能不能跑通再换到底层引擎做性能调优最后看并发需求决定要不要上批处理框架。这个顺序的好处是每一步都有明确的退出点不会在一开始就陷入编译和依赖地狱。底层引擎的优势在于控制力。它能让你指定把模型的多少层放到 GPU 上算、多少层留给 CPU能控制 KV cache 的量化精度能调批处理大小和线程数。在这类统一内存机器上这些参数直接决定速度差一档可能就是 30% 的差距。一体化服务的优势在于省事。一条命令拉模型一条命令起服务自带 OpenAI 兼容接口前端工具直接能连。缺点是它在底层引擎之上又包了一层有些参数没法透传出问题的时候排查链条更长。批处理框架的优势在于吞吐。它用 PagedAttention 这类技术管理 KV cache多人同时请求的时候效率高得多。缺点是对硬件后端的要求高在这类核显平台上支持往往不完整编译一次能耗掉半天。提示如果你的使用场景是我一个人用偶尔两三个人同时问别上批处理框架。它的复杂度换来的吞吐优势在你这个量级完全体现不出来。3.2 量化格式省下来的每一 bit 都是速度模型量化是本地部署绕不开的话题。简单说就是把原本 16 位浮点的权重压成更低精度体积变小、读取变快代价是精度损失。常见的几档我用一张表说清楚差别量化档位每参数位数约32B 模型体积质量感受适用场景Q8_08.534 GB几乎无损内存充裕、要求高保真Q6_K6.626 GB很难察觉差异性价比均衡Q5_K_M5.723 GB细微差异通用推荐Q4_K_M4.819 GB可感知但不影响任务内存紧张时的首选Q3_K_M3.916 GB明显退化只求能跑体积的算法很简单体积(GB) ≈ 参数量(B) × 每参数字节数 每参数字节数 ≈ 每参数位数 ÷ 8以 32B 模型配 Q4_K_M 为例32 × 4.8 ÷ 8 ≈ 19.2 GB。这个数只是权重实际加载还要加上输出头、嵌入层有些量化方案对这两部分保留高精度、以及运行时开销实测通常要多 10% 到 15%。我的经验是能上 Q5 就别上 Q4能上 Q6 就别上 Q5前提是内存装得下并且速度可接受。因为量化损失在长上下文和复杂推理任务上会被放大短问答看不出来一让模型做多步推理就开始胡说。反过来如果内存刚好卡在临界点宁可降一档量化也别去动上下文长度——上下文不够导致的失败比量化损失严重得多。3.3 上下文长度的隐形成本这是最容易被低估的一块。很多人算模型体积只算权重结果一跑就爆内存因为忘了 KV cache。KV cache 是模型在处理上下文时缓存的历史键值对长度随上下文线性增长。粗略估算公式每 token 的 KV 占用 2 × 层数 × KV头数 × 每头维度 × 每元素字节数拿一个典型的 32B 模型举例64 层、8 个 KV 头GQA、每头 128 维、fp16 存储2 × 64 × 8 × 128 × 2 262144 字节 ≈ 256 KB / token32K 上下文全填满256 KB × 32768 ≈ 8 GB。这个数字相当惊人等于又加了一个小模型进去。对策有三个一是把 KV cache 量化成 8 位或 4 位体积直接砍半或砍到四分之一二是限制最大上下文别默认开 128K三是开启 Flash Attention 类优化减少中间激活的内存峰值。我在实际配置里通常这么定默认上下文 16K需要长文档时手动开到 32KKV cache 用 8 位量化。这样 32B 模型的总内存占用能压在 30 GB 以内给系统和并发留足余量。4. 动手部署从拉模型到接口跑通前面都是铺垫这一章开始动手。我把整个过程拆成环境准备→加载模型→服务化三段每一段都给出可以直接抄的配置。4.1 环境准备与后端选择在这类核显平台上后端选择是个关键决策。常见的有三种纯 CPU 后端、Vulkan 后端、ROCm/HIP 后端。纯 CPU 后端最省事编译不出错但速度慢一大截因为没用上核显的并行能力。Vulkan 后端兼容性好对这类新核显支持往往比 ROCm 更快跟进实测性能也不错。ROCm 后端在支持的平台上性能最好但版本匹配挑剔环境变量配错就直接 fallback 到 CPU而且不会报错只会慢。我的建议是先上 Vulkan 后端跑通拿到基准数据再考虑要不要折腾 ROCm。编译命令大致如下# 安装基础依赖以 Debian 系为例 sudo apt install -y build-essential cmake git libcurl4-openssl-dev # Vulkan 开发包 sudo apt install -y libvulkan-dev vulkan-tools glslc # 拉源码 git clone https://example.com/llama.cpp.git cd llama.cpp # 配置开启 Vulkan 后端 cmake -B build -DGGML_VULKANON -DCMAKE_BUILD_TYPERelease # 编译核数按实际 CPU 核心填 cmake --build build -j16编译完之后先跑一次设备探测确认 Vulkan 能看到核显./build/bin/llama-bench --list-devices如果输出里能看到你的核显名字和可用内存说明后端通了。看不到的话先检查vulkaninfo --summary再检查用户是否在render和video用户组里。如果要用 ROCm 路线还要额外设置环境变量告诉运行时把这块核显当成支持的型号# 强制指定目标架构具体值按实际芯片代号填 export HSA_OVERRIDE_GFX_VERSION11.5.1 export GGML_HIP_ROCWMMA_FATTN1这两个变量配错是 ROCm 路线最常见的问题症状是编译能过、运行也能跑但速度跟纯 CPU 差不多。4.2 加载模型与关键参数模型文件拿到之后通常是 GGUF 格式第一件事是确认它能被正确读取./build/bin/llama-cli \ -m /models/deepseek-v4-distill-Q4_K_M.gguf \ -p 你好简单介绍一下你自己 \ -n 128 \ -ngl 999 \ -c 16384 \ --flash-attn几个参数必须解释清楚因为它们直接决定成败-ngl 999表示把全部层都放到 GPU 上。在这类统一内存机器上全放和不全放的速度差别很大能全放就全放。如果内存不够这个值要往下调调到刚好不 OOM 为止。-c 16384是上下文长度。别一上来就开最大值先用 16K 跑通确认内存占用再往上加。--flash-attn开启注意力优化能显著降低长上下文下的内存峰值。有些模型架构不支持开了会报错报错就关掉。如果要控制 KV cache 精度加--cache-type-k q8_0 --cache-type-v q8_0跑通之后看输出末尾的性能数据三个指标最重要prompt eval time预填充速度影响长文档处理体验、eval time解码速度决定打字机效果快不快、total time。这三个数记下来后面调优全靠对比。4.3 服务化让它自己活着命令行跑通只是验证真正要用起来得做成服务。这一步的核心要求是开机自启、崩溃自愈、日志可查、接口固定。用 systemd 是最省事的方案。写一个 unit 文件# /etc/systemd/system/llm-server.service [Unit] DescriptionLocal LLM Inference Server Afternetwork-online.target Wantsnetwork-online.target # 模型加载慢给足超时 TimeoutStartSec600 [Service] Typesimple Userllm Groupllm WorkingDirectory/opt/llm # 关键环境变量 EnvironmentGGML_VULKAN_DEVICE0 EnvironmentLLAMA_ARG_HOST0.0.0.0 EnvironmentLLAMA_ARG_PORT8080 EnvironmentLLAMA_ARG_CTX_SIZE16384 EnvironmentLLAMA_ARG_N_GPU_LAYERS999 EnvironmentLLAMA_ARG_FLASH_ATTN1 ExecStart/opt/llm/llama-server \ -m /models/deepseek-v4-distill-Q4_K_M.gguf \ --parallel 2 \ --cont-batching # 崩溃自动重启 Restartalways RestartSec10 # 日志走 journald StandardOutputjournal StandardErrorjournal # 基础加固 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target启用并检查sudo systemctl daemon-reload sudo systemctl enable --now llm-server sudo systemctl status llm-server # 看实时日志 journalctl -u llm-server -f # 验证接口 curl http://127.0.0.1:8080/v1/models接口起来之后安全上还有两件事要做。第一别把服务监听在公网可达的地址上只监听内网网段。第二加一层访问控制至少用一个固定的 token 做校验因为这机器上跑的东西可能包含内部资料。# 用防火墙只放行内网网段 sudo iptables -A INPUT -p tcp --dport 8080 -s 192.168.0.0/16 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 8080 -j DROPWeb 前端工具那种带对话框的界面可以装也可以不装。我自己的习惯是不装在这台机器上而是从别的机器通过内网地址连过来这样这台机器的内存全部留给推理。5. 性能实测把 tokens/s 一点点榨出来跑通了不等于跑得好。这一章讲实测方法和调优优先级这也是整个折腾过程里最有意思的部分。5.1 一套可复现的基准测试方法调优的前提是有一组可比的基准数据。随便问几句话看速度误差极大因为问题长度、生成长度、是否命中缓存都会影响结果。我一直用的方法是固定三组测试用例每组跑三次取中位数用例输入长度输出长度测的是什么短问答50 token200 token解码速度最影响交互体验长文档摘要8000 token500 token预填充速度最影响等待时间连续对话 20 轮累计 4000 token每轮 150 token上下文变长后的衰减情况前两个用固定的命令行参数跑第三个用脚本模拟。记录下来的核心指标是解码 tokens/s 和预填充 tokens/s。我在这类统一内存机器上的实测数据大概是这样32B 稠密模型Q4_K_M16K 上下文Vulkan 后端指标数值说明解码速度7~9 tok/s单人使用接近带宽理论上限预填充速度120~180 tok/s长文档首次响应约 45 秒2 路并发解码各 4~5 tok/s总吞吐略有提升满载功耗180~200 W含整机这些数字跟理论计算基本吻合32B 模型 Q4 约 19 GB 权重按有效带宽 200 GB/s 算理论 10 tok/s实测打到 7 到 9损耗在合理范围。如果你跑的是 MoE 架构的模型数字会好看很多因为每 token 只读激活的那部分专家。同样体积的 MoE 模型速度可能是稠密模型的两三倍。这也是为什么 MoE 在这类带宽受限的硬件上特别受欢迎。5.2 调优的优先级顺序调优不要乱试按影响大小排个序从上往下做第一优先级全部层放进 GPU。任何一层留在 CPU 上那一层的计算就会被 CPU 内存带宽拖死速度断崖式下跌。先确保-ngl调到能全放。第二优先级开启 Flash Attention 和 KV 量化。这两个直接影响内存峰值峰值降下来才能开更大的上下文或者更多并发。实测能省 20% 到 40% 的 KV 内存。第三优先级批处理大小。--parallel设成 1 到 2 通常最优。设太大每个请求的 KV cache 都要预留内存吃紧反而变慢。单人使用设 1两三个人共用设 2。第四优先级线程数。这个容易被误解。在 GPU 承担主要计算的场景下CPU 线程数只影响预填充和采样设成物理核心数就行别开超线程数量多了反而抢资源。第五优先级内存分配策略。如果用 mmap 加载模型首次加载会慢但内存占用更省。如果模型体积远小于可用内存可以关掉 mmap 让它全量加载速度略快。这里有个反直觉的点很多时候调参带来的提升远不如换一个更合适的量化档位。从 Q4 换到 Q5 可能损失 15% 的速度但模型质量提升明显从 Q5 换到 Q6 同理。如果你发现回答质量不行先别急着调参数先看看是不是量化太狠了。5.3 散热和功耗长期运行的隐形杀手短时间跑分和连续跑八小时是两回事。这类小体积机器的散热设计本来就吃紧满载时间一长温度顶到阈值就开始降频速度肉眼可见地掉。我的实测经验刚启动跑分能到 9 tok/s连续跑一小时后掉到 6 到 7。这不是模型的问题是热的问题。几个应对手段。第一检查风扇曲线。系统里通过platform_profile可以切到性能模式让风扇更早介入。第二物理摆放。别把它塞进密闭的书架格子里前后留出十厘米空间。第三限制并发。与其让它满载降频不如限制在 80% 负载反而总吞吐更高。功耗方面这类机器整机满载大概在 180 到 200 W。按每天跑 12 小时算一个月电费在几十块这个量级。对比云端按量计费的账单这个成本几乎可以忽略。但要提醒一句长期满载对电源适配器和散热都是考验选机器的时候要看它的持续功耗设计不是峰值。监控脚本很简单写个定时任务记录温度和频率# 每 5 分钟记录一次 */5 * * * * sensors | grep -E Tctl|fan /var/log/thermal.log跑一周之后看曲线如果发现温度长期贴着阈值说明散热余量不足要么降并发要么换个摆放位置。6. 常见问题与排查速查表折腾这类部署八成的时间花在排障上。我把踩过的坑整理成一张表遇到问题先对照着看。6.1 典型故障现象与定位方法现象最可能的原因排查方法解决速度只有 1~2 tok/s没走 GPUfallback 到 CPU 了启动日志里找 offloaded X/Y layers检查后端编译选项和设备可见性加载到一半 OOMKV cache 预留过大看日志里的内存分配明细降上下文、开 KV 量化首次响应极慢之后正常模型首次加载走磁盘iostat看磁盘读预热脚本或换 NVMe跑一小时速度掉一半温度顶墙降频sensors看温度和频率改风扇策略、限制并发接口能连但返回空模型路径或格式不对手动跑命令行验证确认 GGUF 完整性和版本匹配并发时随机崩溃内存超卖看 OOM killer 日志减--parallel加 swap 兜底ROCm 路线速度和 CPU 一样架构变量没配对看是否有 fallback 警告修正HSA_OVERRIDE_GFX_VERSION断电重启后服务没起systemd 启动超时systemctl status看失败原因加大TimeoutStartSec表格之外还有几个高频坑值得单独说。模型文件不完整。下载中断留下的残缺文件加载时报的错五花八门可能是张量形状不对可能是 magic number 错误。养成习惯下载完先校验哈希。用户组权限。核显设备节点通常在render组下服务以专用用户跑的时候如果不在这个组里会静默降级到 CPU。这个坑特别阴因为不报错只是慢。日志把磁盘写满。推理服务的访问日志如果不做轮转一天能写几个 G。配好logrotate或者干脆把访问日志级别调低。swap 的取舍。给机器配一块 swap 能防止 OOM 直接杀进程但 swap 一旦被用上速度会掉到没法用。我的做法是配一个小的 swap 只做兜底同时配监控一旦 swap 使用超过 1 GB 就告警。6.2 长期运行要盯的几件事机器跑起来之后日常维护其实很少但有四件事必须定期看。磁盘空间。模型文件动辄几十 G加上日志和缓存256 G 的盘很快见底。建议模型单独放一块盘日志设上限。内存泄漏。有些推理框架长时间跑会有缓慢的内存增长表现是跑一周后可用内存少了几个 G。用systemd的MemoryMax做硬限制超了就重启比人工盯着强。模型更新。新版模型出来了想换别直接覆盖旧文件。保留旧版本新版本用不同端口起一份对比测试满意了再切换。这个习惯能救命我见过换模型之后效果变差、想回滚却发现旧文件被删的情况。备份配置。整台机器的价值其实在配置文件里模型随时能重下。把/etc/systemd/system/、模型加载脚本、防火墙规则这几个地方定期打包备份到别的地方机器挂了半小时就能重建。注意不要在这台机器上跑任何与推理无关的服务。它就是一个专用的推理节点角色越单一出问题的概率越低排障也越简单。7. 我自己的几点体会折腾这套东西大半年有几个判断跟一开始的想法不太一样说出来供参考。第一个判断别追求跑最大的模型。一开始我也想着把能装下的最大参数往里塞后来发现一个 30B 级别的模型配上好的提示词和检索增强在实际任务上的表现比硬塞进去的 70B 低量化版本好得多。量化损失对复杂任务的影响比参数量差距更致命。现在的做法是固定用中档量化把省下来的内存留给上下文长度和并发。第二个判断预填充速度比解码速度更影响体验。解码 7 tok/s 看着慢但打字机效果还能接受预填充 150 tok/s 处理一份八千字的文档要将近一分钟那个等待才叫难受。所以调优的时候我把更多精力放在减少输入长度、做结果缓存、拆分长文档上而不是死磕解码速度。第三个判断这类机器的真正价值不在性价比在于形态。论每 token 成本它打不过云端论绝对性能它打不过独显台式机。它的优势是能安静地待在办公室角落、能塞进任何空间、能断电自恢复、能让非技术同事直接通过网页用上。这个形态上的适配性才是它从折腾玩具变成生产力工具的关键。最后一个实操小技巧给这台机器配一个带开关的智能插座远程能断电重启。听起来很土但当你半夜发现服务卡死、SSH 也连不上的时候这是唯一能救命的手段。比跑去现场按电源键强一万倍。