单张 5090 跑四款大模型的部署对照

单张 RTX 5090 能跑多大的本地模型？作者用 128 GB 内存，把四个大型开源模型放到同一台工作站上，测了生成速度、长上下文和日常任务。结论很直接：模型能装进去，只是起点；响应速度、输出长度和整机占用，才决定它能不能成为每天用的工具。

这组实测最有用的地方，是把模型、推理运行时和硬件一起看。Qwen 是作者的日常首选，更大的 DeepSeek 则适合等得起的任务。不过，这是一台机器、一天测试和两轮工作题，不能直接当成模型能力排行榜。

单卡跑大模型，靠的是整台机器搬运专家

四个模型都是混合专家模型（MoE）：每生成一个 token，只激活部分参数。不过，其余权重仍然需要存放，运行时会把常用专家放进显存，其他专家放进内存；Maya 运行 DeepSeek 时，还会在生成过程中从 SSD 读取部分模型。

能在单卡上运行，不等于模型全部装进了显存。

作者的机器配置是 RTX 5090，32 GB 显存，同时负责桌面显示；CPU 为 Ryzen 9 9950X3D，16 核、32 线程；内存为 4×32 GB DDR5，速率 5,600 MT/s；磁盘是一块 NVMe。系统使用 Arch Linux（Omarchy），NVIDIA 驱动为 615.78，CUDA 为 13.4。

测试组合分别是 Qwen3.8-Flash-Next 配 Strata 296b59d，GLM-5.3-Flash 和 DeepSeek-V4.1-Flash 配 Project Maya 1.1.17，以及 Ornith-1.5-122B 配 TabbyAPI d6e6227、ExLlamaV3 1.6.2。

每次只启动一个模型，所有运行时都预留 3 GiB 显存。进程分别运行在没有内存上限的 systemd slice 中，避免 shell 限制或 systemd-oomd 干扰。

内存占用尤其容易看错。Strata 和运行 GLM 的 Maya 几乎锁定全部内存；Ornith 的量化文件为 65.5 GB，留下的余量最多。DeepSeek 则依赖文件页缓存，free 显示约 100 GiB available，也不能理解成可以随便分给其他程序。其他程序挤掉缓存后，专家权重就得重新从 SSD 读取。

对准备边开 IDE、浏览器、Docker 边跑模型的人，这个限制比参数量更实际。

为什么 Qwen 更快，还不能只归功于模型

作者在 2026 年 10 月 21 日依次测试四组配置。生成速度通过兼容 OpenAI 的端点做客户端流式测量：交替使用约 400 词的荷兰语提示和带测试的二分查找编程题，共跑 8 次，采用贪心解码，输出 512 tokens，取中位数；首 token 延迟也取这 8 次的中位数。

长上下文使用约 31K 和约 125K tokens 的大海捞针测试，把暗号藏在荷兰语填充文本中，每次更换随机种子，避免前缀缓存帮忙。四组都找到了暗号。

长提示经过不同 tokenizer 后，实际长度分别为 Qwen 124.6K、DeepSeek 125.4K、GLM 127.9K、Ornith 131.5K tokens。处理对应请求耗时分别为 29、182、53、103 秒。作者所谓的 prefill 速度，是提示 token 数除以整个请求耗时，其中包含简短回答，不能直接等同于纯预填充阶段的吞吐量。

Qwen 的生成速度达到第二名的 2.4 倍。作者给出的解释是，Qwen 每 token 激活约 6B 参数，GLM 约 18B，前者需要经 CPU 和 PCIe 搬运的权重更少；专门面向该模型家族的 Strata 也可能有贡献。但两者各贡献多少，没有分离测量。

运行方式也不一致：Qwen 使用 MTP head，GLM 使用 MTP block，DeepSeek 使用 DSpark drafter，三者默认启用推测解码；Ornith 没有草稿模型。因此，结果更适合回答「哪套组合好用」，无法单独证明「哪个模型更快」。

原文提供的正文没有完整结果表。它明确写出 GLM 本次为 27.5 tok/s、前一天为 30.8 tok/s，DeepSeek 约为 21 tok/s；系列文章标题中的 Qwen 79 tok/s 对应 Strata 和 5-bit 量化，不能直接补成这次横测的数值。

日常编程任务里，少输出也能更快完成

作者用工作中的 9 个任务测可用性，包括两个 Astro JavaScript 辅助函数、两个放进 PHP 沙箱执行的 WordPress 片段、SEO meta JSON、LocalBusiness JSON-LD、Search Console 工具调用、机会分析，以及荷兰语博客开头。

每轮满分 54 分，共跑两轮，第二轮倒序运行。各服务保留默认采样，reasoning effort 设为 medium。

Qwen 两轮满分。GLM 第一轮在 Search Console 机会分析中丢掉全部 3 个检查点，第二轮满分。Ornith 的问题分散在不同任务中，包括 Node 无法加载的 Astro import、PHP 语法错误，以及 JSON-LD、分析和文案检查未通过。

这些题会检查代码能否加载、语法能否执行、结构是否符合要求，比只看回答是否流畅更接近日常交付。但作者也承认，它们奖励的是准确和细致，不能据此判断谁最擅长深度推理。

耗时进一步拉开了差距。Qwen 和 GLM 完成一轮约需两分钟；DeepSeek 每轮生成约 15,700 tokens，以约 21 tok/s 输出，耗时 13 分钟；Ornith 每轮约 20,700 tokens，多数用于推理，接近 10 分钟。GLM 每轮仅约 3,200 tokens，所以即使生成速度较慢，完成任务仍然很快。

评估编程模型，要看拿到可用结果需要多久，不能只看 tok/s。

我的判断

这篇最可信的结论，是在作者这台机器和这批任务上，Qwen 配 Strata 最适合交互式编程与 agent 工作。Qwen 和 GLM 都支持 512K 上下文，作者把 GLM 当第二意见，把 DeepSeek 留给可以等待的难题，这种分工有实测支撑。

但「更大的模型适合更难的问题」在这里仍是使用判断。文章没有提供难题对照数据，无法证明 DeepSeek 等待更久就能换来更好的答案。大海捞针全部通过，也只说明能找回暗号，不能证明复杂代码库分析同样可靠，更没有验证完整 512K 上下文。

版本和波动同样不能忽略。Maya 1.1.17 让 DeepSeek 的长提示处理比 1.1.16 快约 8 倍；GLM 同版本、同配置的生成速度却从前一天 30.8 tok/s 变成 27.5 tok/s，原因没有查明。加上只有两轮任务、各模型采样未单独调优，质量排序应当视为有限样本下的经验结果。

和只比较参数规模相比，这种整套方案的评估更有参考价值；若要决定团队采购什么，还缺少更广的任务、稳定性和成本对照。

能拿来做什么

• 给本地编程助手准备一组自己的验收题，优先放入 Node 能否加载、测试能否通过、JSON 是否符合结构等自动检查，并记录完成全部任务的时间。
• 复现配置时，同时记录模型量化、运行时版本、推测解码和 reasoning effort；升级后先重跑常用任务，别沿用旧版本的速度结论。
• 规划工作站容量时，把 IDE、浏览器和容器一起算进去，尤其不要把 DeepSeek 使用的页缓存当作闲置内存。作者这套配置一次只能运行一个模型，切换需要停止和启动脚本。