RTX 5090 实测 Qwen 3.8 27B：VRAM 容量够不代表跑得动，软件与推理引擎才是瓶颈
阿里巴巴的 Qwen 3.8 27B 开源权重模型几周前刚刚发布，凭借如此体量下出色的智能基准测试成绩，立刻在本地 AI 圈掀起了一波热潮。
四比特量化后权重总量约 17GB，兼具通用能力与内置多模态支持，Qwen 3.8 27B 迅速吸引了所有持有 RTX 5090、RTX 4090、RTX 3090（以及 Radeon RX 7900 XTX、Radeon AI Pro R9700、Arc Pro B70）用户的目光。
一张显卡跑四比特量化就能触及前沿级智能？任何本地 AI 配置够用的用户都能直接取消 Claude 或 ChatGPT 订阅了？
答案当然是——和每一次开源权重模型的热潮一样——远不止拿模型权重体积跟自己的 VRAM 容量做个粗略对比那么简单。你的显卡或系统在模型跑起来之后，还剩多少 VRAM 给上下文用？你的主机系统和 LLM 推理引擎在 time-to-first-token 上是否够用，吞吐量能否脱离空上下文的刷分场景、达到实际可用的水平？
如果只是跟模型闲聊看看效果，那还说得过去；但如果你想真正让它干活，尤其是不耐烦的 agent 把人类感知极限完全排除在外之后，那就完全是另一回事了。
我们想知道 Qwen 3.8 27B 到底需要怎样的软硬件栈才能跑出稳定表现，于是把它跑在了从独立显卡台式机到 DGX Spark、Mac Studio、Ryzen AI Halo 等统一内存架构系统的各种平台上。
我们的独立 GPU AI 测试平台包含以下组件：
左右滑动查看Tom’s Hardware 本地 AI 测试平台 |
Row 0 - Cell 1 |
CPU |
Ryzen 7 9800X3D |
内存 |
64GB (4x16GB) DDR5-5200 |
主板 |
Asus TUF Gaming X670E-Plus Wifi |
SSD |
Corsair MP600 Pro XT 4TB |
电源 |
MSI MPG Ai1600TS |
操作系统 |
Ubuntu 26.04 LTS |
在条件允许的情况下，我们分别在开启和关闭 Qwen 3.8 27B 内置多 token 预测（MTP）功能的状态下测试了性能。部分模型运行器在我们某些平台可用的显存范围内无法支持 MTP，我们会在各平台的分析和图表中注明是否启用了 MTP。
RTX 5090 性能
我们先从 RTX 5090 开始。它拥有 32GB GDDR7 显存和 1.8 TB/s 的内存带宽，照理说应该能轻松跑出这款稠密模型的最佳本地推理性能。（混合专家模型对 DGX Spark、AMD Strix Halo 这类低端硬件反而更友好，因为激活参数量少，推理时的数据搬运也少。）
作为基准测试，我们沿用了惯常的本地 AI 评测流程：从 GitHub 拉取最新版 llama.cpp 并编译，从 Hugging Face 下载该模型的 Unsloth 量化版本，然后运行。但测试很快就遇到了阻碍。
图 1 / 4
查看原图
图 2 / 4
查看原图
图 3 / 4
查看原图
图 4 / 4
查看原图
虽然 llama.cpp 在 RTX 5090 上跑这个模型时能轻松分配完整的 262K 上下文长度，但长上下文下的处理速度却惨不忍睹。
单张 5090 的首 token 生成时间竟然拖到约 30 分钟，说明这里肯定有东西坏了。每秒 token 吞吐量更是远低于你手握全球最快显卡之一时应有的水平。怎么算都不合适，llama.cpp 目前并不是适配这块硬件的推理引擎。
接下来我们试了 vLLM。这是一款面向生产环境的推理引擎，通常更常见于数据中心而非桌面，但它两个场景都能胜任——前提是宿主机硬件跟得上。我们的测试机配备了 64GB 主内存，但仍需额外分配 64GB swap，vLLM 才能首次成功加载 Qwen 3.8 27B。这绝对算不上轻量级方案。
vLLM 维护团队提供了 Qwen 3.8 27B 的 NVFP4 量化版本，以及单卡和双卡 RTX 5090 的部署方案。TH 实验室恰好有两块 RTX 5090，所以两种配置我们都实测了一遍。
用单块 5090 跑 vLLM 来服务 Qwen 3.8 27B 当然能凑合用，但长上下文推理并不理想，因为默认方案只支持 32K 上下文。要跑满 262K 上下文，你最好用一张显存更大的单卡（比如 48GB 或 72GB 的 RTX Pro Blackwell），或者像我们实测的那样上两块 5090。
单卡显存也不足以启用 Qwen 3.8 27B 内置的多 token 预测（MTP），而这个功能对提升该方案的 decode 速度非常关键。不开 MTP 时，整体只有 20 tokens/s，对这张级别的卡来说算不上出色的基线。
图 1 / 共 2 张
查看原图
图 2 / 共 2 张
查看原图
不过，如果上两张 5090，vLLM 的解码速度就会大幅飙升（尽管 prefill 代价不小）。在整个上下文长度测试中保持 70–80 tokens/s，对本地部署来说已经是非常亮眼的成绩，TTFT 也还算合理。但我们还能更快。 在 vLLM 上启用 MTP 后，解码速度能达到 100–110 tokens/s，而提示词处理速度只略受影响。这套配置性能稳定，提示词处理速度也不会让人怀疑是不是哪里出了严重问题。不过它也理应够快——按本文测试的双 RTX 5090 平台，目前价格要超过 13,000 美元。 我们还在 RTX 5090 上测试了 SGLang 推理引擎，配置与 vLLM 大致相同。 Image 1 of 2
查看原图
Image 2 of 2
查看原图
不知为何，SGLang 在单张 5090 上要快得多——比 vLLM 的单卡方案快了近 3 倍——可用上下文（37,740）也比 vLLM 略多。但如果你想用满模型原生支持的 262K 上下文，仍然需要第二张卡，或者换一张显存更大的卡。
图 1/2
查看原图
图 2/2
查看原图
和 vLLM 一样，SGLang 支持多 GPU 张量并行，双卡推理只需多加一个启动参数。同样地，你还可以像 vLLM 那样引入多种 speculative decoding 策略来进一步提升输出性能。
这一轮测试的结论是：如果你只有一张 RTX 5090，且不需要长上下文推理，跑这个 dense 模型确实能拿到可用的性能。但模型运行器的选择要仔细。
而如果你希望同时兼顾完整的上下文窗口、合理的 prompt 处理速度和高吞吐量，起步至少得一张显存超过 32GB 的显卡（或更多）。
RTX 3090 与 RTX 4090 表现
摸清了 RTX 5090 的行为之后，我们转向了几张更老的消费级显卡，看看它们跑 Qwen 3.8 27B 如何。凭借 24GB 的大显存和二手市场上相对实惠的价格，RTX 4090 和 3090 一直是本地 LLM 爱好者的常青热门选择，但正如前文反复强调的，能加载模型权重远非全貌。
这两张卡用 llama.cpp 加载 Qwen 3.8 27B 的 Q4_K_M GGUF 量化版完全没有问题，但一开始就得把 KV cache 量化为 Q8_0 才能塞进较小的显存，同时上下文长度也得控制在远低于模型原生 262K 上限的水平。实测下来，上下文大约在 112K token 左右就是显存的极限了。
与 32GB 显存的 RTX 5090 不同——后者通常还能让 Linux 桌面窗口管理器和 LLM 基础设施共享显存——这些 GPU 的每一点 VRAM 都得全部留给 AI 负载，不余分毫。所以如果你不是跑无头服务器，这两张卡最好额外配一张独立显卡。但这么做又会引出新的配置麻烦：你得先摸清自家主板怎么处理 PCIe 插槽拆分（bifurcation）以及主显卡设备的枚举顺序。
Image 1 of 8
查看原图
Image 2 of 8
查看原图
第 3 张图，共 8 张
查看原图
第 4 张图，共 8 张
查看原图
第 5 张图，共 8 张
查看原图
第 6 张图，共 8 张
查看原图
第 7 张图，共 8 张
查看原图
第 8 张图，共 8 张
查看原图
克服这些障碍、让 Qwen 3.8 27B 在这些显卡上跑起来之后，我们发现 llama.cpp 在 RTX 4090 上同样存在长上下文时的性能断崖，和 RTX 5090 上的表现一致。但奇怪的是，RTX 3090 却不受影响，这说明某处可能存在 bug。
我们没来得及测试 SGLang 和 vLLM 在这些产品上的表现，不过考虑到 RTX 5090 的上下文空间本来就紧张，我们怀疑这两个推理引擎在这类 24GB 显卡上未必是运行该模型的好选择——除非你手头正好囤了几张 3090 或 4090 可以组多卡。
DGX Spark 性能
硬核本地 LLM 玩家可能会嫌弃 DGX Spark 只有 27 GB/s 的内存带宽，还跑 Qwen 3.8 27B 这种稠密模型。确实，我们过去的测试也表明，这个平台跑稠密模型并不是最快的。
不过现在像 Qwen 3.8 27B 这样的模型已经支持 MTP，只需在服务器启动时多加一个参数就行，因此对于内存带宽有限的平台，解码速度往往能获得一份额外的、零成本的显著提升。
图 1/4
查看原图
图 2/4
查看原图
图 3/4
查看原图
图 4/4
查看原图
在实际测试中，Spark 的 prefill 阶段表现相当扎实，因此在较长上下文长度下，它往往能比使用 llama.cpp 的 RTX 5090 更快地完成每一轮推理。
除了 llama.cpp，Spark 同样获得 SGLang 和 vLLM 的良好支持，如果这些推理引擎更合你心意，完全可以拿来用。另外，单台 Spark 的售价仍在 5000 美元左右，它是一套即开即用的系统，后续还可以按需扩展为小型集群。因此，即使是用来部署这个稠密模型，Spark 也值得考虑，不应被排除在外。
Apple Mac Studio with M4 Max performance
我们实验室里搭载 M4 Max 的 Mac Studio 在现有统一内存系统中拥有最高的内存带宽，但正如我们之前测试中提到的，内存带宽只是本地 AI 推理中需要关注的指标之一。
图 1 / 4
查看原图
图 2 / 4
查看原图
图 3 / 4
查看原图
图 4 / 4
查看原图
这个平台的提示词处理速度比 Spark 慢，所以即使 Mac Studio 在解码阶段能产出比 GB10 更多的 token，长上下文时它的单轮推理耗时依然更长——因为大部分处理时间都花在了这个环节上。
而且至少在 llama.cpp 里，Mac Studio 上启用 MTP 会在短上下文时拖慢解码速度，换取长上下文时的小幅提升，而在其他平台上它通常是全面带来收益的。这正说明实际跑分测试比纸面参数对比更有价值。
Ryzen AI Halo (Strix Halo) 性能
AMD 的 Ryzen AI Halo 在这款稠密模型上表现最差：内存带宽较低，提示词处理性能也偏弱。
Image 1 of 4
查看原图
Image 2 of 4
查看原图
Image 3 of 4
查看原图
Image 4 of 4
查看原图
虽然 MTP 在这套系统上用 llama.cpp 能稍微拉高每秒 token 的生成速度，但无法弥补长上下文下漫长的 prompt 处理时间。如果 Strix Halo 是你手头唯一的设备，跑这个模型当然没问题；但如果你要做交互式长上下文任务，建议找性能更强的硬件。
总结
刚开始测试 Qwen 3.8 27B 的性能时，我原以为流程会很简单：插一张显卡、加载模型、出 token，完事。实际操作下来，调试工作量远超预期。一些我们最初认为跑不动这个稠密模型的系统，最终证明出乎意料地好用。
总体来说，那些吹嘘空上下文窗口下每秒能跑几百 token 的说法，远没有覆盖 LLM 在特定推理配置下可能出现的各种行为。
举一个例子：不管是 llama.cpp 本身的 bug 还是预期行为，在 RTX 5090 上跑 Qwen 3.8 27B 的长上下文时，等上三十分钟甚至更久才能拿到响应，这完全不可接受。但如果你现在直接用 llama.cpp 朴素地加载 Qwen 3.8 27B，得到的体验就是如此。
换用其他推理引擎是很自然的下一步，但同样存在取舍。用 vLLM 或 SGLang 确实可以在单张 5090 上加载 Qwen 3.8 27B，但这些引擎对可用上下文长度要保守得多。我们最终使用的方案在单张 5090 上只能拿到 32K token 的上下文窗口。
要启用完整的 262K 上下文长度，我们不得不从 TH 的测试资源里再拿一张 RTX 5090。之后两个推理框架都能提供出色的吞吐量，TTFT 一直到最大上下文长度都保持在可交互的范围内。但如果你想复刻这套配置，目前花费会超过 1.3 万美元。
你可能觉得 DGX Spark 只有 273 GB/s 的内存带宽，跑这种 dense model 不太够用，但实际上 Spark 的 prefill 速度足够快，即便 MTP 模式下 decode 吞吐量仅 20 tokens/s 左右，TTFT 依然保持在可交互的水平，而且这个表现一直能撑到模型的完整原生上下文长度。
搭载 M4 Max 的 Mac Studio 内存带宽绰绰有余，decode 完全不在话下，但这颗较老的 Apple Silicon 芯片 prompt 处理速度偏慢，导致整个推理轮次的时间几乎全耗在 prefill 阶段。更新的 M5 Max 和全新的 M5 Ultra 无疑表现会更好，只是这次测试手头没有这几颗芯片。而 AMD 的 Ryzen AI Halo 则是最吃瘪的——prompt 处理速度低，又受限于内存带宽，TPS 也上不去。
抛开这些不谈，我们真的需要退一步重新审视本地 AI 的经济学。花 5000、1 万甚至 1.5 万美元以上买本地 AI 硬件，这笔钱在 Anthropic 或 OpenAI 的前沿模型上能换来海量 tokens（找提供国产开源模型的服务商，能换得更多）。海量。如果你也觉得时间就是金钱，且没有算力合规方面的限制，那些 tokens 返回给你或你的 agent 的速度，比家里能跑起来的任何东西都快——除非你直接上那台搭载 GB300 GPU 的DGX Station。
所以，除非你在处理需要本地部署的敏感数据，或者你纯粹是折腾爱好者，又或者你出于某种原因担心开源模型分发和推理生态的未来，否则大概率没必要为了跑这一个模型就急着攒一台机器。
但如果你确实要折腾，请记住：实际跑出来的性能远不止 VRAM 容量或内存带宽说了算，而且用 llama.cpp 这类最主流的推理框架，未必能榨干你这套配置的全部潜力。多动手实验、认真跑 benchmark，才能找到最适合你自己配置的最优解。