本报告所有数据均通过局域网络凭据只读采集。

一、总览

1.1 结论

1.2 七个最关键的事实

1. 性能非常扎实，且完全稳定。 单流生成稳定在 52.4–52.7 token/s（多次测量标准差仅 0.01–0.17）；5 分钟持续满载 78 个请求、0 错误、吞吐零衰减。对比服务日志中长上下文场景下的 30–43 token/s，可见短上下文性能有明显优势，长上下文会有衰减（见 6.3）。

2. 最大的架构短板是 -np 1（单 slot），不是 GPU。 并发 1→16 时聚合吞吐几乎恒定在 47.5→49.0 token/s，说明请求被严格串行排队。实测一个 10 token 的小请求，在 16,200 token 长请求之后排队时，耗时从 0.40 s 涨到 19.78 s（49 倍）。多人/多 agent 同时使用同一服务时体验会显著恶化。

3. 长上下文预填充是"分钟级"的。 98,304 token 的输入需要 261 秒；按实测速率外推，占满 128K 上下文约需 5.8 分钟。在此期间 /health 仍返回 200，但推理接口完全不可用——健康检查不能代表服务可用性。

4. GPU 功耗正常但温度偏高。 R9700 空闲 12 W、满载 299 W（正好打满 300 W 功耗墙，峰值 304 W，曾观测到 354 W 瞬时尖峰）；结温稳态 89 °C、峰值 97 °C，显存温度稳态 92 °C、峰值 94 °C——显存温度是本机散热的最热点。

5. 数据安全存在真实风险： AI服务器整块 1 TB 物理 NVMe 裸盘直通 （方案：停机备份整块盘）。

6. 访问控制真实风险： 局域网内任何设备都可以直接占用这块 300 W 的 GPU

7. 主机与虚拟机的硬件健康度都很好。 0 次 MCE、0 次 AER、0 次 CPU 节流、内存压力≈0；GPU ECC 零错误。平台本身的可靠性没有问题。

二、评测环境与拓扑

2.1 物理拓扑

        ┌──────────────────────────────────────────────────────────────┐
        │  评测客户端  macOS 工作站   192.168.67.203                    │
        │  网卡 en1：2500Base-T 全双工   （icmp RTT 中位 0.37 ms）        │
        └───────────────────────────┬──────────────────────────────────┘
                                    │  2.5GbE 交换网络（同一广播域）
        ┌───────────────────────────▼──────────────────────────────────┐
        │  PVE 9.2.18 物理主机  192.168.67.251   节点名 R9700            │
        │  Intel Core Ultra 7 265K / 20 核 / 62 GiB DDR5-6400（非 ECC）  │
        │  ASUS TUF GAMING Z890-PRO WIFI  BIOS 3211                     │
        │  启动盘 Samsung 512GB NVMe → LVM(pve-root 467.94G + swap 8G)  │
        │  数据盘 Kingston 1TB NVMe →【整块裸盘直通】                    │
        │  上行 enp135s0 2500Mb/s → vmbr0（无 BMC/IPMI，防火墙已禁用）    │
        └───────────────┬──────────────────────────┬───────────────────┘
                        │ KVM + VFIO 直通          │
        ┌───────────────▼──────────────┐  ┌────────▼─────────┐
        │ VM 102  Ubuntu24.04-desktop  │  │ VM 100 Ikuai8    │
        │ 192.168.67.202               │  │ VM 101 OpenWrt   │
        │ 10 vCPU(host) / 48 GiB       │  │      停止待用     │
        │ 根盘 = Kingston 整块直通      │  └──────────────────┘
        │ GPU 04:00.0 R9700 直通        │
        │ qwen38.service :8080          │
        └──────────────────────────────┘

2.2 PVE 物理主机

2.3 Ubuntu 24.04 推理虚拟机（VM 102）

2.4 llama.cpp 服务配置

/etc/systemd/system/qwen38.service
  Description = Qwen3.8-27B llama.cpp server (R9700 HIP, MTP, 128K)
  User/Group  = magicz890
  Environment = LD_LIBRARY_PATH=/opt/llama.cpp/bin:/opt/rocm/lib
                HIP_VISIBLE_DEVICES=0
  ExecStart   = /opt/llama.cpp/bin/llama-server
                  -m  /opt/llama.cpp/models/Qwen3.8-27B-Uncensored-Q5_K_M.gguf
                  --mmproj /opt/llama.cpp/models/mmproj-Qwen3.8-27B-Uncensored-F16.gguf
                  --alias qwen3.8
                  -c 131072 --override-kv qwen35.context_length=int:131072
                  -ctk q8_0 -ctv q8_0 -fa on --load-mode none
                  --reasoning-effort medium -ngl 99 -np 1
                  --temp 0.3 --top-p 0.9
                  --spec-type draft-mtp --spec-draft-n-max 2
                  --host 0.0.0.0 --port 8080
  Restart     = on-failure / RestartSec=5 / TimeoutStopSec=60

服务启动性能：模型加载耗时约 8.2 秒（20:31:49.898 → 20:31:58），对 18.19 GiB 模型而言非常快。

2.5 评测方法

三、健康度评测

3.1 PVE 主机健康度

3.2 虚拟机健康度

3.3 GPU 健康度

关于直通告警：QEMU 在建立 DMA 映射时出现一次 -22（EINVAL），并提示该卡不支持 BAR 级 P2P 事务。这两条是 VFIO 大 BAR（32 GB）映射的常见提示，在单卡直通、且不需要 GPU 间 P2P（NVLink/XGMI）的场景下不影响功能与稳定性——本次 5 分钟满载 0 错误即为佐证。

3.4 服务健康度

四、稳定性评测

4.1 运行时长与重启历史

PVE 主机：今天的重启全部是我修改参数，不是崩溃。

reboot   system boot  7.0.14-16-pve    Fri Sep 11 20:31 - still running
reboot   system boot  7.0.14-16-pve    Fri Sep 11 10:42 - 20:30  (09:48)
shutdown system down  7.0.14-16-pve    Fri Sep 11 20:30 - 20:31  (00:00)
reboot   system boot  7.0.14-16-pve    Fri Sep 11 09:02 - 10:15  (01:12)
shutdown system down  7.0.14-16-pve    Fri Sep 11 10:15 - 10:42  (00:27)
reboot   system boot  7.0.14-16-pve    Fri Sep 11 07:30 - 07:31  (00:00)
...

每条 reboot 前都对应一条 shutdown ... system down，7 次启动、0 次非正常掉电。journalctl --list-boots 与 last -x 完全一致。

虚拟机：同样全部为正常关机（shutdown system down → reboot system boot），最快一次仅停机 1 分钟。

llama 服务：NRestarts=0，与主机重启时间严格对齐——主机重启时服务随虚拟机自启，未发生任何崩溃重启。

4.2 长稳压测结果

执行了两轮持续满载推理，均在 1 Hz 功耗采样覆盖下完成：

关键结论：约 9.3 分钟累计满载、141 个请求，零错误、零重试、吞吐零衰减。 两轮的单请求速度中位数完全一致（52.46 t/s），说明 GPU 在持续满载下没有出现降频或性能衰减。

请求延迟（192 token/请求）：中位 7.56 s，p99 7.84 s，标准差 0.46 s——排队行为可预测。

4.3 满载后的状态复检

压测结束后立即复检（22:22:44），结果：

4.4 温控稳定性

判定依据：整个压测过程 SCLK 未出现台阶式下降、生成吞吐标准差仅 0.13–0.17、CPU core/package_throttle_count 保持 0。平台没有热降频，但 GPU 显存温度已进入 90 °C 以上的"暖区"。

五、功耗与散热评测

5.1 GPU 功耗与温度实测（AMD R9700）

数据来源：/sys/class/drm/card1/device/hwmon/hwmon0/（power1_average、temp1/2/3_input、fan1_input、freq1/2_input），1 Hz 采样，共 900 + 386 个样本。

GPU 是绝对功耗大头：满载时 GPU 299 W vs CPU 47 W，GPU 占整机功耗约 70%，如家庭使用可降频到270W左右，影响甚微。

空闲温度的测量口径：表中空闲值为开机后长时间无负载状态（本次为启动后 1 小时 33 分、无任何客户端）的实测值。压测结束冷却约 4 分钟后，三路温度回落到 37 / 39 / 38 °C（边缘/结温/显存），功耗回落到 11 W，风扇回到最低档 891 rpm —— 说明散热与功耗回退机制工作正常，只是机箱内部余温使读数略高于冷启动状态。

GPU 功耗/温度时间线

5.2 主机 CPU 功耗与温度实测（Intel RAPL）

数据来源：/sys/class/powercap/intel-rapl:0/energy_uj（package）与 intel-rapl:0:0（core），差分法计算瓦特。

CPU 功耗/温度时间线

由 RAPL 可见，CPU 在推理场景中几乎"闲着"：封装功耗仅从 21 W 升到 47 W（+26 W），远小于 GPU 的 +287 W。这与 llama-server 的 CPU 占用很低这一事实一致 —— CPUUsageNSec 折算其生命周期平均 CPU 占用约 25.4%（累计 1,692 s CPU 时间 / 6,655 s 运行时间 ÷ 10 vCPU ≈ 2.5 个 vCPU 等效），且这部分开销主要来自采样与 HTTP 层，矩阵计算全部在 GPU 上完成。

5.3 整机功耗估算（因消费级主板数据仅供参考）

主机无 BMC/IPMI、无机箱功耗计、无智能插座数据，因此整机瓦特数为基于实测分量的估算：

能耗折算（供参考）

按 0.6 元/kWh 估算，实际混合负载约 2.2 元/天、约 790 元/年。

5.4 散热评价

优点

• GPU 空闲时风扇停在 891 rpm、12 W，功耗控制优秀。
• 满载时核心频率稳定在 2.7–3.1 GHz 且未触发降频，说明散热能力足以支撑 300 W 持续功耗。
• CPU 与 NVMe 温度都很舒服（CPU 51 °C、NVMe ≤52 °C），机箱风道通畅。

需关注

• 显存温度（92 °C 稳态 / 94 °C 峰值）高于 GPU 核心结温（89 °C 稳态），这是典型的风冷 GDDR6 特征，也是本机最热的部件。持续高负载下会加速显存老化。
• 结温峰值 97 °C —— 虽然未触发降频（通常 AMD 结温降频阈值在 100 °C 以上），但已接近"舒适区"边界。
• 5 分钟压测尚不足以验证夏季高温环境或连续数小时满载下的表现；建议补做 1 小时以上满载测试。

散热提升建议（按性价比排序）

1. 提高机箱进风量（前面板风扇），或改善 GPU 与机箱底板间距 —— 显存温度对风量最敏感。
2. 使用 rocm-smi --setperflevel 或 pp_power_profile_mode 切换到 COMPUTE 档（当前为 BOOTUP_DEFAULT），可能获得更激进的风扇曲线（但会增加功耗/噪声）。
3. 若可接受约 5–8% 的性能损失，把功耗墙从 300 W 下调到 250–270 W（rocm-smi --setpoweroverdrive），可显著降低显存温度。
4. 夏季前重做一次散热器硅脂/导热垫维护。

六、推理性能评测

所有测试均由局域网客户端 192.168.67.203 发起，目标 192.168.67.202:8080，属于真实端到端性能（含网络开销）。

6.1 单流生成速度（Decode）

结论：

• 稳态生成速度 52.7 token/s，等价于 每 token 19.0 ms。
• 32 token 档偏低（44.6 t/s）是因为包含了首个 token 的计算与调度开销；长度 ≥128 token 后即进入稳态。
• 稳定性极佳：1024 token 档三次测量标准差仅 0.01 t/s（0.02%）。
• 该成绩显著受益于 MTP 投机解码（日志显示 draft 接受率可达 0.99，mean len = 2.99）。

注意长上下文衰减：服务自身日志显示，当上下文达到 3 万 token 时生成速度降至 30–43 t/s（例如 tg_3s = 29.63 t/s、draft acceptance = 0.60）。上下文越长，MTP 接受率越低、速度越慢，这是本地大模型推理的普遍规律。

6.2 首 token 时延与流式输出

说明：ITL 中位数 0.02 ms 而 p90 为 55 ms，是 llama.cpp 逐 token 推送被 TCP Nagle/缓冲合并的结果——客户端会以约 55 ms 的批次收到 token，但总吞吐完全一致（52.15 vs 51.9 t/s）。对于聊天类应用，体验等同于流式输出；对逐 token 实时性要求极高的场景（如语音），建议在服务端或客户端做 TCP_NODELAY/缓冲调优。

6.3 长上下文预填充能力（关键短板）

结论：

• 预填充速度在 4K token 时达到峰值 949 t/s，随后因注意力计算量随长度平方增长而持续下降。
• 98K token 输入需要 4 分 21 秒；按实测速率外推，占满 128K 上下文约需 5.8 分钟。
• 这是"单 slot 串行"架构下最致命的问题：一个长文档分析请求会让整个服务停摆数分钟。
• 横向参考：n_ctx=131072 的 128K 上下文能力确实可用（无截断、无 OOM），但代价是分钟级的首 token 等待。

6.4 前缀缓存（Prompt Cache）有效性

缓存命中带来约 15 倍加速（3.55 s → 0.24 s）。 这意味着：

1. 客户端必须保证对话前缀逐字节不变，否则缓存全部失效；
2. 多轮对话的追加式调用几乎无预填充开销；
3. 但缓存容量有限——日志显示服务会淘汰旧条目（曾淘汰一条 6.2 GiB 的长上下文缓存），因此多客户端交替使用长上下文时缓存会互相冲刷。

6.5 并发能力（最重要的架构短板，双卡优势大）

并发压测：-np 1 下请求被严格串行化

结论：并发 1 → 16，聚合吞吐几乎不变（47.5 → 49.0 t/s），总耗时与并发数严格成正比。 说明完全没有并行服务能力，每个请求排队串行执行。增加客户端只会等比拉长所有人的等待时间。

公平性实测：小请求被长请求"饿死"

一个正常情况下 0.4 秒完成的问候语请求，因为前面排队了一个 16K token 的预填充任务，实际等待了 19.8 秒。这就是 -np 1 的直接后果。

对"统一可用性"的影响（可用性长跑实测）

在评测窗口内以 2 秒间隔持续探测，共 365 次：

/health 是"进程活着"探针，不是"服务可用"探针。 在 3 次小请求超时 120 秒的同时，/health 依然 100% 返回 200。任何基于 /health 做的负载均衡或健康检查都会失效。

6.6 多模态、工具调用与结构化输出

服务端日志同时给出的一条重要提示：
Qwen-VL models require at minimum 1024 image tokens to function correctly on grounding tasks —— 建议按官方建议增加 --image-min-tokens 1024 参数以改善图像定位任务准确度。

6.7 API 兼容性矩阵

参数校验行为

七、局域网连接与可用性评测（网络环境2.5G）

7.1 网络时延、抖动与丢包

对两台目标各发送 600 个 ICMP 包（间隔 200 ms，总计 2 分钟）：

分析

• PVE 主机 p50 0.374 ms，是纯二层交换的理想值。
• 虚拟机 p50 0.686 ms，比主机多 0.31 ms —— 这就是 虚拟网卡（virtio → tap → fwbr → vmbr0）的固定开销，表现为一个约 0.3 ms 的双峰分布（38 个样本落在 <0.25 ms，说明部分包走了更短路径）。
• 零丢包、最大 1.4 ms，对 LLM 推理（单 token 19 ms）而言，网络时延完全不是瓶颈（占比 <4%）。
• vmbr0 累计 TX dropped 仅 4 个包，可忽略。

HTTP API 层时延（100 次 /health 请求）

7.2 局域网吞吐

使用自建 HTTP blob 服务端进行 1 GiB 定长传输，两个方向各 3 次：

结论：网络链路完全不是瓶颈。 虚拟机 virtio 网卡（单队列、TSO/GSO/GRO 全开）可以打满 2.5GbE 线速，且收发对称。对推理服务而言，即使每 token 都带 100 字节负载，52 t/s 也仅需 5 KB/s —— 带宽余量有 4 个数量级。

MTU 探测

全链路 MTU = 1500，未启用巨帧。对 LLM 推理无影响，无需调整。

7.3 可用性长跑与故障行为

实测可用性指标（评测窗口）

八、补图

8.1 主机图片（闷罐）

8.2 待机功率

8.3 满载功率

九、实测结束

ALL IN ONE · ALL IN BOOM
一台机器，全部搞定 —— 然后，炸裂全场！

ALL IN ONE —— 一机全能

️ 虚拟化 (PVE)
AI 推理 (llama.cpp)
GPU 直通 (R9700)
网络服务
存储中心

一台机器 = 服务器 + AI 工作站 + 存储 + 网关 All in One，All the Power.