24G 显卡能跑本地 AI 吗？M6000 实测

Quadro M6000 全模型实测 · 2026-10-09 · 9 个模型 / 7 个维度 / 3 类图像任务 / dsh 端到端实证

一、为什么要折腾一张 10 年前的卡

手上这台推理机插着一张 Quadro M6000 24GB——2015 年的 Maxwell 架构（算力 5.2），
显存带宽 317 GB/s，功耗上限 250W。它的唯一优势是 24G 显存足够便宜，
而 24G 恰好是”能跑 27B 级模型”的门槛。目标是把它变成一台本地 AI Agent 服务器
（跑 DeepSeek Harness，下称 dsh：一个会读写文件、执行命令的 agent 运行时）。
要求很具体：

• 工具调用可靠——agent 每轮都要调工具，调错一次整轮作废
• 上下文要长——dsh 没有自动上下文压缩，多轮工具结果会迅速吃满窗口
• 速度尽量快——5 t/s 和 40 t/s 是完全不同的产品体验

网上”老卡跑大模型”的资料大多是把新卡数据套用过来，于是干脆自己做一轮完整实测：
横向铺开模型，纵向打穿指标。

二、测试方法

2.1 环境

2.2 七个自动化测试维度

三、横向评测：9 个模型同台

3.1 总表

注：解码/prefill 单位 tokens/秒；显存为实测占用；
「检索」= 4k 长文里的密码能否找回；「工具」= 4 场景工具调用正确数；「质量」= 数学/推理/中文写作三项。

四、竖向打穿：四个反直觉的发现

4.1 发现一：量化格式决定生死，差 6 倍

同一个 27B 模型，只换打包格式，在这张卡上速度差了 6 倍：

判据（怎么自己判断踩没踩坑）：跑起来看 nvidia-smi——
GPU 利用率 100% 但显存带宽利用率只有 6%、功耗仅 112W/250W，
说明卡在计算路径而不是数据搬运，那就是 kernel 没走对。

4.2 发现二：标准量化在这张卡上是纯带宽问题

实测两组标准量化的数字很有意思：

27B Q4_K  ：7.96 t/s × 16.8 GB ≈ 131 GB/s
 9B Q4_K_M：22.34 t/s × 5.6 GB ≈ 131 GB/s

两者的有效带宽完全一致（131 GB/s，占卡峰值 317 GB/s 的 41%）。
结论：标准量化解码在本卡是纯带宽游戏，模型文件越小越快；
至于为什么只用到 41% 带宽——那是 Maxwell 老架构的 kernel 效率天花板，
软件层面已经无解（换更新的卡才有质变）。

4.3 发现三：MoE 是这类老卡的最优解

MoE（混合专家）模型每个 token 只激活一部分参数，权重搬得少，速度就快：

• gpt-oss-20b：21B 总参数 / 3.6B 激活 → 39.9 t/s
• Qwen3.5-35B-A3B：35B 总参数 / 3B 激活 → 30.6 t/s
• Qwen3.5-27B 稠密：27B 全激活 → 8.0 t/s

同样”27B 级”的能力，MoE 方案速度是稠密的 4~5 倍。
这也解释了为什么同样体积下，参数更多的 MoE 反而更快。

4.4 发现四：MTP / 投机解码在这张卡上是死路

投机解码（让一个小模型/预测头先猜几个 token，大模型批量验证）本是最有希望的提速手段，
但在 Maxwell 上全军覆没：

• MTP 预测头：加载成功，一推理就 CUDA error: an illegal memory access 崩溃
  （内核需要更新的 CUDA 架构）
• 4B 草稿模型投机解码：技术上完全打通（需要给模型打 4 个 gguf 补丁），
  但接受率只有 30%，速度从 12 t/s 掉到 5.3 t/s，反而慢一倍

五、长上下文：能装多少，以及装下了能不能用

dsh 这类 agent 工作台最吃上下文，所以单独测了 gpt-oss-20b 的上下文上限：

关键数字：-c 131072 全量开启时显存只占 13.1 GB（KV 用 q8_0），
和 Bonsai 27B 三值（8.3 GB）还能同卡共存（实测 21.1 GB / 23 GB）。

六、图像能力实测

用三张自制的可验证测试图（中英文报告截图 / 柱状图 / 网络拓扑图），
考察多模态模型的 OCR、图表理解与图形推理能力：

七、dsh 实战：同一任务 × 不同模型

用同一句任务指令（建文件 → 写 Python 脚本 → 运行 → 列目录 → 总结）实测各模型的 agent 完成度：

八、结论与推荐配置

llama-server -m gpt-oss-20b-mxfp4.gguf -ngl 99 -np 1 
  -c 131072 -ctk q8_0 -ctv q8_0 --jinja --reasoning-budget 0 
  --host 0.0.0.0 --port 8092

部署四条铁律（少走弯路）

1. 必加 --reasoning-budget 0：思考会吃光输出预算，表现为”回答为空”
2. Qwen3.5 混合架构要加 --cache-reuse 0：llama.cpp 下该架构 KV 缓存不能跨轮复用，
   不加会出诡异问题
3. 上下文两个旋钮要对齐：服务端 -c 与 dsh 的 defaultContextWindow
   必须一致，且 dsh 的值不能更大
4. 老卡避开 IQ 系量化与 PTQ1_0：优先 MXFP4 / PQ2_0 / 标准 K 量化

九、附录：复现命令

# 1) 硬件确认
nvidia-smi --query-gpu=name,driver_version,compute_cap,memory.total --format=csv

# 2) 起主力模型（64k 上下文，KV 用 q8_0 省显存）
llama-server -m gpt-oss-20b-mxfp4.gguf -ngl 99 -np 1 
  -c 65536 -ctk q8_0 -ctv q8_0 --jinja --reasoning-budget 0 --port 8092

# 3) 验证速度
curl -s http://127.0.0.1:8092/completion -H 'Content-Type: application/json' 
  -d '{"prompt":"请解释光合作用","n_predict":200,"temperature":0}' | python3 -m json.tool | grep -A5 timings

# 4) 跑 dsh agent 任务
export DSH_HOME=~/.dsh OLLAMA_API_KEY=local
dsh --profile headless "在当前目录创建 hello.txt 并写入当前时间"

本文所有数据均为在同一台机器、同一批次、同一提示词下实测所得，脚本与原始 JSON 结果保留在本地仓库。
测试硬件：Quadro M6000 24GB（2015）/ 驱动 580.178.04 / llama.cpp PrismML fork b10743 / dsh 0.1.7-rc.2。

延伸阅读：

• 把 ComfyUI 做成局域网出图服务：API 调用与队列管理
• 本地 RAG 知识库搭建：Ollama + 向量库 + 文档切片实践