单张二手 RTX 3090 24GB，Ubuntu 26.04.1，原版 llama.cpp、llamAmpere 与 HyperQwen 完整实测
测试日期：2026-09-21 至 2026-09-22

这篇测试参照 lcz.me 的《7900 XTX 跑 Qwen3.8-27B 完整部署与实测指南》，保留其测试题、采样参数、长提示、prompt cache、n-max 扫描和 20 道能力题，再把 AMD Vulkan 配置改成适合本机单张 RTX 3090 的 CUDA 配置。

说在开头本人也是硬件小白，现在就是看锤哥视频慢慢鼓捣窜了台机器，大神们轻点喷哈 ，配件都是东子上买的，除了显卡是二手东子自营的3090，其他都买的一手货，我买到的3090是个大卡，后续因为想在淘个3090，所以选的HUANANZHI X99-F8D PLUS这个板子（需要个塔式的机箱），坑的来了，如果是两个3090的话的电源线用便宜的长城金龙的电源口不够，客服也不给加模块，最后买了个微星的电源2900软妹币，整机下来大概花了1.6-1.7W。下面的配置都是根据我需求参考论坛的大神帖子找GPT配置的，后续这台机器是想做AI视频工作流的，昨天算是工作流跑通了，这两天整理下发到论坛上来。这几天在满载跑视频进行测试(需要装载卸载模型)，目前看这个二手卡还是挺靠谱的。

报告先完整记录原版 llama.cpp 的可复现基线，再追加针对 RTX 3090 的 llamAmpere 和 HyperQwen 优化结果。重点不是单独追求最高的 t/s，而是说明硬件、软件、提示词、采样参数和测量方法。投机解码的速度会随着题目类型明显变化；同一台机器上，中文创作、代码和工具 JSON 的速度可以相差接近一倍。

目录

1. 先给结论
2. 硬件与软件环境
3. 与原帖平台的关键差异
4. 编译、模型和最终启动配置
5. 无 MTP 基线
6. MTP 不同工作负载实测
7. n-max 完整扫描
8. 长提示与 prompt cache
9. 能力评测：智力 10 题 + 工具 10 题
10. 功耗、温度、显存与错误日志
11. 结果解释与使用建议
12. 复现方法
13. 已知限制
14. Reddit / GitHub 优化方案复测

1. 先给结论

结论：这张 RTX 3090 可以稳定运行 Qwen3.8-27B。原版 llama.cpp 的 Agent/工具速度约 84 t/s；针对 Ampere 优化的 llamAmpere 达到 95.64 t/s，并可加载 237,568 token；追求单用户最高速度时，HyperQwen/DFlash2 的本机结果为 123–129 t/s。原版最稳、llamAmpere 是最快 GGUF 路线、HyperQwen 是最高单请求速度路线。

2. 硬件与软件环境

2.1 整机硬件

GPU 所属 NUMA 节点：

$ cat /sys/bus/pci/devices/0000:84:00.0/numa_node
1

因此所有正式测试都绑定 node 1：

numactl --cpunodebind=1 --membind=1 ...

2.2 软件环境

2.3 模型

当前 Hugging Face 文件名比原帖多了 UD- 前缀，llama.cpp 读取的量化类型仍为 Q4_K Medium。本轮只测纯文字，没有下载约 927MB 的 mmproj 多模态投影文件。

后续优化复测还使用了 ATX IQ4_XS-M 模型：

3. 与原帖平台的关键差异

原帖特别强调 32GB ReBAR；本机 X99 平台只暴露 256MB BAR1。CUDA 的内存管理路径和 Vulkan 不同，本机仍取得正常速度，但这项差异意味着两台机器不能只根据 GPU 理论带宽直接比较。

另外，原帖的 --no-mmap 在当前 llama.cpp 中已经移除，本机使用等价的新参数：

--load-mode none

4. 编译、模型和最终启动配置

4.1 CUDA 编译

CUDA、CMake 和 Ninja 均安装在独立环境，没有替换系统驱动或系统 CUDA：

cmake -S . -B build-cuda -G Ninja \
  -DGGML_CUDA=ON \
  -DGGML_NATIVE=ON \
  -DGGML_CCACHE=OFF \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CUDA_ARCHITECTURES=86 \
  -DCUDAToolkit_ROOT="$CUDA_HOME" \
  -DCMAKE_CUDA_COMPILER="$CUDA_HOME/bin/nvcc" \
  -DLLAMA_CURL=OFF

cmake --build build-cuda -j 8 --target llama-server llama-bench

设备检查结果：

CUDA0: NVIDIA GeForce RTX 3090
compute capability: 8.6
VRAM: 24124 MiB
VMM: yes

4.2 最终 128K 配置

export CUDA_HOME="/home/luna/Documents/Codex/2026-09-20/i/work/llama.cpp/venv-build/lib/python3.14/site-packages/nvidia/cu13"
export LD_LIBRARY_PATH="$CUDA_HOME/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

exec numactl --cpunodebind=1 --membind=1 \
  /home/luna/Documents/Codex/2026-09-20/i/work/llama.cpp/build-cuda/bin/llama-server \
  -m /home/luna/Documents/Codex/2026-09-20/i/work/llama.cpp/models/Qwen3.8-27B-Q4_K_M/Qwen3.8-27B-UD-Q4_K_M.gguf \
  --alias qwen3.8-27b \
  --device CUDA0 \
  --fit off \
  -ngl -1 \
  --load-mode none \
  --spec-type draft-mtp \
  --spec-draft-n-max 4 \
  -c 131072 \
  -ub 512 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --parallel 1 \
  --cache-ram 32768 \
  --flash-attn on \
  --host 127.0.0.1 \
  --port 8080 \
  --jinja \
  --reasoning off

4.3 为什么使用这些参数

加载完成后，空闲服务显存约 22,447MiB；整个测试期间最高 22,956MiB，说明 128K Q8/Q8 可以装入，但显存余量只有约 1.6GiB。

5. 无 MTP 基线

使用 llama.cpp 官方 llama-bench，不启用 MTP：

numactl --cpunodebind=1 --membind=1 \
  build-cuda/bin/llama-bench \
  -m Qwen3.8-27B-UD-Q4_K_M.gguf \
  -dev CUDA0 \
  -p 2048 \
  -n 128 \
  -fa on \
  -r 2 \
  -ngl -1 \
  -lm none

两张卡的无 MTP decode 几乎一致。本机 CUDA 的 pp2048 约为原帖的 1.9 倍，说明这套 CUDA 构建的预填充路径表现很好。

RTX 3090 标称显存带宽为 936GB/s，模型为 15.32GiB。只按每个 token 完整读取一次权重估算，理论上限约 57–61 t/s；实际 38.21 t/s 约为这个粗略上限的六成多，与原帖的利用率接近。

6. MTP 不同工作负载实测

6.1 测试方法

为便于与原帖直接比较，本节固定使用：

{
  "temperature": 0.6,
  "top_p": 0.5,
  "top_k": 15,
  "max_tokens": 900
}

文本题每项两次。工具题挂载与原帖同类的 8 个 schema：

web_search, web_extract, messages_send, shell_exec,
image_generate, memory_search, todo_write, stock_quote

6.2 三类文本工作负载

为了和原帖直接比较，本表使用 n-max=5。

测试原文：

請寫一篇約 800 字的短文，主題是「山中的湖泊在日出時的景象」。直接開始寫，不要前言。

用 C++17 寫一個執行緒安全的 LRU cache class，含 get/put、雙向鏈結串列+unordered_map、std::mutex 保護，並附上完整的標頭與實作。直接輸出程式碼。

用 C++ 實作一個完整的 HTTP 請求解析器 class：解析 request line、headers、chunked body，含錯誤處理與單元測試 main()。直接輸出程式碼。

6.3 工具调用

最终推荐配置为 n-max=4。每种工具场景累计运行 6 次，共 24 次请求：

测试原文：

幫我查一下今天台積電的股價

幫我搜尋一下 llama.cpp 最近的 Vulkan 更新，然後把摘要傳到我的 Telegram 主對話

幫我看一下本機 8080 這個服務現在還活著嗎，順便告訴我 GPU 用了多少記憶體

幫我生一張圖：黃昏的山中湖泊，寫實風格，1024x1024，30步

这些测试只检查模型生成的工具名称和 JSON 参数，没有真的发送消息、执行 shell、查询股票或生成图片。

6.4 为什么同一张卡能从 42 变成 96 t/s

MTP 会先用模型内置的草稿头猜后续 token，再由主模型批量验证。格式越固定，越容易连续猜中：

• 中文散文下一句话有大量合法写法，本机接受率只有 0.230，因此速度接近无 MTP 基线。
• C++ 语法、缩进和常见模板具有较强规律，接受率上升到约 0.72–0.79。
• 工具名称、JSON 键名和参数格式更固定，部分任务接受率接近 0.9，速度可超过 90 t/s。

所以“3090 跑 Qwen3.8 有多少 t/s”没有单一答案。必须同时报告提示词、采样参数、输出长度和 MTP 接受率。

7. n-max 完整扫描

扫描范围与原帖一致：

2, 3, 4, 5, 6, 8

所有档位均使用前述四类工具题，每类至少两次；3/4/5 三个候选值各追加四次，因此这三档共有 24 个请求。

本机没有复现原帖 n=8 直接掉到约 45 t/s 的情况，但 n=8 的标准差最大、接受率最低，图片长参数任务仍明显退化，不适合作为默认值。

n=3/4/5 的综合平均只差约 1.1 t/s，小于原帖记录的约 7% 运行波动。因此这里把 4 作为本机实测默认值，不把它描述成统计意义上的显著胜出。若实际工作主要是自然语言和长参数工具，可以重新对比 3；若几乎都是短小 JSON，可以比较 4 与 5。

8. 长提示与 prompt cache

8.1 冷提示 prefill

使用带有 system prompt、Agent 记录和结构化文本的长提示。不同长度使用不同首部，避免较短测试提前缓存较长测试的共同前缀。

对应原帖：

本机 CUDA 长提示 prefill 明显快于原帖 Vulkan。随着提示变长，本机仍从 1154 下降到 1056 t/s，说明 prefill 不是固定常数，也不能拿短提示速度直接外推 128K。

8.2 prompt cache

在第一轮约 6.4K 对话后追加一句新问题：

结果确认 --cache-ram 32768 正常工作。对多轮 Agent 来说，缓存是否命中往往比 decode 再提高几 t/s 更影响体感。

8.3 128K 是否实用

128K 服务已经实际加载并完成 39K 输入测试，但峰值显存达到 22,956MiB，只剩约 1.6GiB。继续把提示塞到接近 128K 时，首字等待会进一步增加。

因此：

• 128K 适合作为“不轻易截断”的验证配置。
• 日常聊天和 Agent 建议用 64K，显存余量和等待时间更合理。
• 不要把“能加载 128K”理解为“每次都应该塞满 128K”。

9. 能力评测：智力 10 题 + 工具 10 题

评测题、system prompt 和工具约束均按原帖公开内容复现。所有结果自动按数字、关键词、工具名称和 JSON 参数判定。

9.1 智力测试：10/10

平均生成速度约 78.99 t/s。数学题允许列出过程，没有要求“只输出数字”。

9.2 工具调用测试：10/10

共用规则包括：外部实时信息必须用工具；常识不滥用工具；寄信和删档信息不足时先确认；参数必须符合 schema；有前后依赖的步骤不可并行。

B2 值得单独说明：模型调用了合法的 sales 数据库去查 information_schema，没有强行传入 schema 不允许的 marketing。按原帖表格公布的“不可编造 database: marketing”标准记为通过。这比简单拒绝更积极，同时没有违反 enum。

工具测试只评估模型输出，并未真的寄信、删文件、查询数据库或执行其他外部动作。

10. 功耗、温度、显存与错误日志

连续遥测从 2026-09-21 23:04:16 到 2026-09-22 00:52:24，共记录 6,486 个 1 秒样本，覆盖：

• llama-bench 基线
• n=5 文本和工具对照
• 6.4K 与 39K 长提示
• n=2/3/4/5/6/8 扫描
• 3/4/5 候选值追加复测
• 两轮完整能力评测

测试结束后显卡恢复到 P8、约 26–30W、约 430–438MiB 显存。

内核日志在本轮期间未出现：

NVIDIA Xid
NVRM GPU fault
GPU fallen off the bus
PCIe/AER error
OOM / out-of-memory

这张消费级 RTX 3090 的 ECC、retired pages、row remapper 和显存温度在 nvidia-smi 中均返回 N/A，所以本报告不能给出 GDDR6X 结温。此前整机体检已使用 memtest_vulkan 覆盖约 23.5–23.8GB 显存，独立 10 分钟及 CPU+GPU 联合 3 分钟均为 0 错误。

11. 结果解释与使用建议

11.1 这张二手 3090 是否有问题

当前没有发现需要退换或维修的证据：

• 约 24GB 显存校验 0 错误
• Qwen3.8-27B 长时间满功耗推理稳定
• 128K Q8/Q8 成功加载，无 OOM
• 71°C 核心温度正常
• 无 Xid、掉卡、AER 或 CUDA 计算错误
• 20 道能力题全部通过，没有观察到明显计算损坏导致的异常输出

11.2 推荐的日常配置

420W 配置在本轮中热稳定，但对电源、三根 8-pin 线材和机箱散热要求较高。降低到 300–350W 通常可以明显减少供电压力，具体速度损失应在改功耗上限后重新实测。

11.3 不应如何解读这些数字

• 83.9 t/s 是四种工具工作负载的平均值，不是所有提示都能达到。
• 42 t/s 的中文散文不是 GPU 故障，而是 MTP 接受率低。
• 128K 能加载不代表塞满 128K 仍有良好交互体验。
• 本机与原帖的 llama.cpp 版本、GPU 后端和 BAR 大小不同，不能把差值全部归因于显卡。
• n=4 比 n=3/5 只快约 1%，属于小差异；真实应用应使用自己的提示重新扫描。

12. 复现方法

12.1 环境检查

# GPU 所在 NUMA 节点
cat /sys/bus/pci/devices/0000:84:00.0/numa_node

# BAR 大小
lspci -vv -s 84:00.0 | grep 'Region 1'

# 驱动、显存、VBIOS 和功耗上限
nvidia-smi --query-gpu=name,driver_version,vbios_version,memory.total,power.limit --format=csv

# llama.cpp 是否只识别到这张卡
build-cuda/bin/llama-bench --list-devices

12.2 无 MTP 基线

numactl --cpunodebind=1 --membind=1 \
  build-cuda/bin/llama-bench \
  -m models/Qwen3.8-27B-Q4_K_M/Qwen3.8-27B-UD-Q4_K_M.gguf \
  -dev CUDA0 -p 2048 -n 128 -fa on -r 2 -ngl -1 -lm none

12.3 启动服务

工作目录中保留了经过验证的启动脚本：

cd /home/luna/Documents/Codex/2026-09-20/i/work/llama.cpp
./run_server_3090.sh

脚本默认 n=4；也可以临时传入其他值：

./run_server_3090.sh 3
./run_server_3090.sh 5

12.4 工作负载测试

python3 bench_3090.py \
  --suite all \
  --repeats 2 \
  --max-tokens 900 \
  --output results/recheck.jsonl

12.5 长提示和缓存测试

python3 context_cache_3090.py \
  --output results/context-cache-recheck.json

12.6 n-max 扫描

./scan_nmax_3090.sh

也可以只复测候选值：

NMAX_VALUES="3 4 5" REPEATS=4 LABEL=recheck \
  ./scan_nmax_3090.sh

12.7 20 道能力题

python3 capability_3090.py

原始 JSON、服务日志和 1 秒 GPU 遥测保留在：

/home/luna/Documents/Codex/2026-09-20/i/work/llama.cpp/results/

13. 已知限制

1. 没有测试 mmproj 和图像理解；本轮是纯文字 Qwen3.8-27B。
2. 没有测试多用户并发；--parallel 1 让一个会话独享 128K。
3. 没有实际填满 128K，只验证服务成功分配 128K 并完成约 39K 冷提示。
4. RTX 3090 的显存温度和 ECC 统计不可用，只能结合显存压力测试、错误日志、核心温度和稳定性判断。
5. BAR1 只有 256MB，没有条件在同一台机器上完成 ReBAR 开/关 A/B。
6. n=2、6、8 各有 8 个工具请求；3、4、5 各有 24 个请求。不同档位样本数并不完全相同。
7. 本机使用的模型文件和 llama.cpp commit 都比原帖更新，因此这是一份按原帖方法复现的 3090 报告，不是严格的同版本显卡对比实验。

14. 后续优化复测（2026-09-22）

继续检查 Reddit、GitHub 和社区测试后，本机额外验证了针对 Ampere/RTX 3090 的 llamAmpere 分支及 ATX IQ4_XS-M 模型。

同一组 24 次工具请求达到 95.64 token/s，比本报告原版 llama.cpp 的 83.89 token/s 提高 14.0%；中文创作、C++ LRU 和 C++ HTTP parser 分别为 52.22、97.16、99.71 token/s，20 项能力题仍为 20/20。237,568-token 配置已实际加载并完成生成，峰值显存 22,999MiB。

最高单用户速度仍是本机已经验证的 HyperQwen/DFlash2：默认采样 123.35 token/s、贪心 129.30 token/s。llamAmpere 更适合作为“最快 GGUF + 超长上下文”方案。

参考资料

• lcz.me：7900 XTX 跑 Qwen3.8-27B 完整部署与实测指南
• llama.cpp 官方仓库
• unsloth/Qwen3.8-27B-GGUF
• llamAmpere：RTX 3090 定制 llama.cpp 分支
• HyperQwen：RTX 3090 定制 vLLM 方案
• NVIDIA nvidia-smi 文档

本报告所有性能和能力数字均来自这台机器的实际输出，没有使用估算值替代实测值。