Llama.cpp on KnightLi的博客

GTX 1060 跑 Qwen 35B 实战：llama.cpp 从 3 tok/s 优化到 17 tok/s

Wed, 24 Jun 2026 10:07:45 +0800

6GB 显存的 GTX 1060 能不能跑 35B 级别的大模型？

如果按传统理解，第一反应多半是“不太现实”。35B 参数量太大，显存只有 6GB，哪怕模型已经量化，也很容易遇到速度慢、内存爆、上下文上不去、跑一会儿就不稳定的问题。

但如果模型是 MoE 架构，再配合 llama.cpp 的分层卸载、CPU 内存承接和参数调优，事情就会变得有意思：它不一定能变成高端显卡那种体验，但可以从“勉强能跑”优化到“日常测试能用”。

这篇按实操思路整理：目标不是神化 GTX 1060，而是讲清楚低显存显卡跑 Qwen 35B 这类模型时，应该先看哪里、调哪里、怎么判断瓶颈。

先说结论

低显存显卡跑 35B 模型，关键不是把所有东西都塞进显存，而是让 GPU 只承担最值得加速的部分。

大致思路是：

先能跑起来
-> 看默认速度为什么慢
-> 调整 GPU 卸载层数
-> 利用 MoE 特性减少不必要负担
-> 修复内存和缓存瓶颈
-> 再拉上下文长度
-> 最后处理稳定性

如果一开始就盯着“显存不够怎么办”，很容易走偏。更实际的目标应该是：让显存、内存、CPU、磁盘和上下文缓存配合起来，而不是只看显卡型号。

准备环境

这种玩法建议先准备好几个条件：

一张 6GB 显存左右的 NVIDIA 显卡，例如 GTX 1060 6GB；
足够的系统内存，越低越容易卡在 swap 或 OOM；
已经编译好 CUDA 版本的 llama.cpp；
一个适合低显存尝试的量化模型文件；
能接受速度不是云端 API 级别；
会查看显存、内存和进程占用。

可以先用下面这些命令确认环境：

1
2
3

nvidia-smi
free -h
./llama-cli --help

如果 nvidia-smi 看不到显卡，或者 llama.cpp 没有 CUDA 支持，后面再怎么调参数都不会有理想效果。

第一步：先让模型跑起来

不要一上来就追求 17 tok/s。第一步只看一件事：模型能不能正常加载并输出。

一个基础命令通常长这样：

./llama-cli \
  -m /path/to/model.gguf \
  -p "用三句话解释什么是 MoE 模型" \
  -n 128

如果这一步都失败，先不要急着加 GPU 参数，优先检查：

模型文件路径是否正确；
模型量化格式是否被当前 llama.cpp 支持；
系统内存是否足够；
是否下载了错误版本的模型；
当前二进制是否支持对应模型架构。

能跑起来以后，再开始优化速度。

为什么默认速度可能只有 3 tok/s

低显存环境下，默认参数慢通常不是一个原因造成的。

常见瓶颈有这几类：

瓶颈	表现	处理方向
GPU 卸载太少	显卡很闲，CPU 很忙	增加可承受的 GPU offload
卸载太激进	显存爆掉或频繁报错	降低卸载层数
内存带宽不够	CPU 占用高但 token 慢	减少无效开销，换更合适量化
上下文太大	一开始就很慢或内存暴涨	先用小上下文测试
swap 介入	系统卡顿明显	增加内存或降低参数
批处理参数不合适	prompt 处理慢	调整 batch 相关参数

所以调优时不要只看一个 tok/s 数字。建议同时开着：

1
2

watch -n 1 nvidia-smi
htop

观察 GPU 显存、GPU 利用率、CPU 占用和系统内存是否同步变化。

第二步：调整 GPU 卸载

llama.cpp 里最常见的加速思路是把部分层卸载到 GPU。

常用参数是：

-ngl 20

或者完整一点：

./llama-cli \
  -m /path/to/model.gguf \
  -p "写一个本地大模型调优 checklist" \
  -n 256 \
  -ngl 20

这里的 20 不是固定答案。低显存显卡要一点点试：

-ngl 10
-ngl 15
-ngl 20
-ngl 25

每次调整后看三件事：

是否能正常启动；
显存是否接近打满；
tok/s 是否真的提升。

如果显存已经顶满，再继续加 -ngl 只会让程序更不稳定，不一定更快。

第三步：理解 MoE 为什么重要

MoE 模型和普通 dense 模型不太一样。

MoE 的核心特点是：模型参数总量很大，但每次推理不一定激活全部专家。也就是说，标称 35B 并不代表每个 token 都要完整跑一遍 35B 的全部计算。

这也是低显存显卡有机会尝试的关键原因。

但要注意两点：

MoE 不是免费魔法，模型文件仍然很大；
显存不够时，仍然需要 CPU 内存承担大量数据。

所以优化 MoE 模型时，重点是把真正高频、值得加速的部分交给 GPU，把显存放在刀刃上。

第四步：处理内存瓶颈

很多人以为低显存跑不动，只是显存问题。实际更常见的是显存、内存、缓存一起卡。

如果运行时系统内存接近耗尽，或者 swap 开始大量使用，速度会明显下降。可以用：

free -h

或者：

`1`	`vmstat 1`

观察是否出现频繁 swap。

优化方向包括：

换更小的量化版本；
降低上下文长度；
降低 batch；
减少并发任务；
关闭不必要的后台程序；
确保模型放在速度较快的 SSD 上；
给系统留足内存余量。

如果系统内存本身太小，6GB 显卡再怎么调也很难舒服。

第五步：上下文长度不要一开始拉满

很多模型默认宣传支持很长上下文，但低显存机器不要一开始就拉满。

建议先从较小上下文开始：

-c 4096

确认稳定后再尝试：

-c 8192

再往上加时，要观察内存和速度变化。

上下文越长，KV cache 压力越大。低显存设备上，长上下文通常比单纯生成短回答更容易暴露问题。

如果你的目标只是本地问答、代码片段解释、短文本总结，没必要一开始追求特别大的上下文。

第六步：关注 batch 参数

llama.cpp 的 batch 参数会影响 prompt 处理和生成表现。不同版本参数名称可能略有变化，可以先看帮助：

`1`	`./llama-cli --help`

常见思路是：

prompt 很长时，适当调 batch 可能改善处理速度；
显存紧张时，batch 太大可能导致不稳定；
不要照抄别人的数值，按自己机器测试。

调参时建议一次只改一个参数。

比如先固定模型、上下文和 -ngl，再尝试 batch。否则你很难判断到底是哪一个参数带来了变化。

第七步：记录自己的五个关键参数

低显存本地推理最怕“今天能跑，明天忘了怎么配”。

建议每次测试都记录这几个参数：

参数	记录什么
模型文件	模型名称、量化版本、文件大小
GPU 卸载	`-ngl` 或相关卸载参数
上下文长度	`-c` 数值
batch	batch / ubatch 等相关设置
结果	tok/s、显存、内存、是否稳定

可以简单写成：

model: Qwen-xx-35B-xxx.gguf
gpu: GTX 1060 6GB
ngl: 20
ctx: 4096
batch: 默认
speed: 约 17 tok/s
status: 短文本稳定，长上下文需继续测试

这样下次换模型或换机器时，就能快速对比。

一个更稳的测试流程

推荐按这个顺序做：

不加 GPU 卸载，确认模型能加载；
加较低 -ngl，确认能输出；
逐步提高 -ngl，找到显存临界点；
固定 -ngl，调整上下文长度；
固定上下文，再测试 batch；
用同一段 prompt 对比 tok/s；
跑 10 到 20 分钟，观察是否稳定；
记录最终参数。

不要每次换一个 prompt 测速度。prompt 不同，结果没有可比性。

可以准备一个固定测试提示词：

`1`	`请用 800 字解释 MoE 模型为什么适合低显存推理，并给出三个注意事项。`

每轮都用同一个提示词，才方便判断优化是否真的有效。

常见失败尝试

低显存调大模型时，这几类操作很容易浪费时间：

1. 盲目拉高 GPU 卸载层数

看到 -ngl 提升速度，就一直往上加。

问题是 GTX 1060 只有 6GB 显存，越过临界点后，程序可能直接报错，或者看似启动了但运行不稳定。

2. 一开始就拉超长上下文

长上下文对内存和 KV cache 压力很大。先用短上下文把模型跑稳，再扩上下文更实际。

3. 只看平均 tok/s

tok/s 是重要指标，但不是唯一指标。

你还要看：

首 token 延迟；
prompt 处理速度；
显存是否溢出；
长时间运行是否稳定；
系统是否卡到影响其他操作。

4. 不记录参数

本地推理调优经常需要反复试。没有记录，很容易陷入“刚才那个能跑的参数是多少来着”的循环。

适合 GTX 1060 的预期

GTX 1060 这类老显卡适合做什么？

适合：

学习 llama.cpp；
测试 GGUF 模型；
跑短文本问答；
做本地模型参数实验；
体验 MoE 模型的低资源运行方式；
验证某个模型是否值得换更好硬件部署。

不太适合：

高并发服务；
超长上下文重度使用；
多用户同时推理；
大规模 RAG 生产环境；
对延迟非常敏感的实时应用。

把 GTX 1060 当成实验机器，它很有价值。把它当成生产级大模型服务器，就容易失望。

一句话总结

6GB 显存跑 Qwen 35B 这类模型，真正的重点不是“硬塞进显卡”，而是用 llama.cpp 把 GPU 卸载、MoE 特性、系统内存、上下文长度和 batch 参数协调起来。

如果你手里刚好有 GTX 1060 这种老显卡，可以按这个顺序试：

`1`	`先跑通 -> 调 -ngl -> 看显存 -> 控上下文 -> 查内存 -> 测 batch -> 记录 tok/s`

从 3 tok/s 到 17 tok/s，不靠玄学，靠的是一步步把瓶颈拆开。

Holo 3.1 本地部署教程：用 llama.cpp 接入 OpenClaw 跑 Computer Use Agent

Fri, 12 Jun 2026 23:03:15 +0800

Holo 3.1 是 H Company 发布的本地 computer-use Agent 模型系列，定位是视觉语言模型与电脑操作代理。根据官方模型卡，Holo3.1 支持网页、桌面和移动环境，提供 0.8B、4B、9B、35B-A3B 等尺寸，并有适合本地运行的 GGUF 量化版本。

它适合想把 AI Agent 跑在自己电脑上的用户：不走云端 API，不按 token 计费，也更容易把浏览器自动化、桌面操作和本地文件流程控制在自己的机器里。

下面记录一套比较直接的本地部署流程：用 llama.cpp 启动 Holo 3.1 的 OpenAI-compatible 服务，再把 OpenClaw 指向本地地址。

准备条件

建议准备：

Windows、macOS 或 Linux 电脑。
一张显存足够的独立显卡，或 Apple Silicon Mac。
llama.cpp 的 llama-server。
Holo 3.1 的主模型 GGUF 文件和视觉 mmproj 文件。
OpenClaw。

模型大小可以按硬件选择：

硬件配置	推荐模型
RTX 4090 / RTX 3090 24GB	35B-A3B Q4_K_M
RTX 5070 Ti / RTX 4060 Ti 16GB	9B
Apple Silicon	9B GGUF
12GB 显存	4B
8GB 显存	0.8B

如果只是体验浏览器自动化和简单桌面任务，9B 会更容易跑起来。35B-A3B 更适合 24GB 显存以上机器，但也更吃上下文、显存和加载时间。

1. 下载 llama.cpp

可以从 llama.cpp releases 下载预编译版本，也可以自己编译。Windows 用户下载后解压，确认目录里有：

`1`	`llama-server.exe`

然后在 llama.cpp 目录下新建：

models

后续把 Holo 3.1 的主模型和 mmproj 文件都放进这个目录。

2. 下载 Holo 3.1 模型

Holo 3.1 的官方 Hugging Face 组织为 Hcompany。如果使用 llama.cpp，需要选择 GGUF 格式。

以 35B-A3B 为例，需要下载：

主模型，例如 Q4_K_M 量化的 GGUF。
对应的视觉投影模型，例如 mmproj.f16.gguf。

放入目录后，可以整理成类似结构：

llama.cpp/
  llama-server.exe
  models/
    q4_k_m.gguf
    mmproj.f16.gguf

文件名可以自定义，但启动脚本里的路径必须对应修改。

3. 启动 Holo 3.1 本地服务

下面是一个 Windows 批处理脚本示例，可以保存为 start-holo31.bat，放在 llama-server.exe 同级目录。

@echo off
chcp 65001 >nul
title Holo 3.1 VLM Launcher

set LLAMA=llama-server.exe

:MENU
cls
echo ==========================================
echo          Holo 3.1 VLM Launcher
echo ==========================================
echo.
echo 1. 8GB GPU  (0.8B)
echo 2. 12GB GPU (4B)
echo 3. 16GB GPU (9B)
echo 4. 24GB GPU (35B-A3B)
echo 5. CPU mode (4B)
echo 0. Exit
echo.
set /p CHOICE=Choose:

if "%CHOICE%"=="1" goto GPU8
if "%CHOICE%"=="2" goto GPU12
if "%CHOICE%"=="3" goto GPU16
if "%CHOICE%"=="4" goto GPU24
if "%CHOICE%"=="5" goto CPU
if "%CHOICE%"=="0" exit
goto MENU

:GPU8
"%LLAMA%" ^
-m models\holo-0.8b.gguf ^
--mmproj models\holo-0.8b-mmproj.gguf ^
-ngl 999 ^
-c 8192 ^
-fa ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--temp 0.2 ^
--top-p 0.9 ^
--host 127.0.0.1 ^
--port 1234
pause
goto MENU

:GPU12
"%LLAMA%" ^
-m models\holo-4b.gguf ^
--mmproj models\holo-4b-mmproj.gguf ^
-ngl 999 ^
-c 16384 ^
-fa ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--temp 0.2 ^
--top-p 0.9 ^
--host 127.0.0.1 ^
--port 1234
pause
goto MENU

:GPU16
"%LLAMA%" ^
-m models\holo-9b.gguf ^
--mmproj models\holo-9b-mmproj.gguf ^
-ngl 999 ^
-c 24576 ^
-fa ^
--cache-type-k q8_0 ^
--cache-type-v q8_0 ^
--temp 0.2 ^
--top-p 0.9 ^
--host 127.0.0.1 ^
--port 1234
pause
goto MENU

:GPU24
"%LLAMA%" ^
-m models\q4_k_m.gguf ^
--mmproj models\mmproj.f16.gguf ^
-ngl 999 ^
-c 65536 ^
--flash-attn on ^
--cache-type-k q8_0 ^
--cache-type-v q8_0 ^
--temp 0.2 ^
--top-p 0.9 ^
--repeat-penalty 1.05 ^
--host 127.0.0.1 ^
--port 1234
pause
goto MENU

:CPU
"%LLAMA%" ^
-m models\holo-4b.gguf ^
--mmproj models\holo-4b-mmproj.gguf ^
-ngl 0 ^
-c 4096 ^
--threads 16 ^
--temp 0.2 ^
--host 127.0.0.1 ^
--port 1234
pause
goto MENU

运行脚本后选择对应显存档位。成功后，llama-server 会在本地提供 OpenAI-compatible API：

`1`	`http://127.0.0.1:1234/v1`

如果启动失败，优先检查三件事：

模型文件名是否和脚本一致。
mmproj 文件是否存在。
显存是否足够当前模型和上下文长度。

4. 安装 OpenClaw

Windows 以管理员身份打开 PowerShell，执行：

`1`	`powershell -c "irm https://openclaw.ai/install.ps1 \| iex"`

macOS / Linux 执行：

`1`	`curl -fsSL https://openclaw.ai/install.sh \| bash`

安装完成后进入 OpenClaw 设置，把模型提供商配置为本地 OpenAI-compatible 服务：

1
2

API Base URL: http://127.0.0.1:1234/v1
API Key: 留空或填写任意占位值

启动模式可以选择浏览器启动。进入 OpenClaw 可视化界面后，应能在底部看到本地模型已加载。

如果界面里有思考模式开关，可以先关闭。Holo 3.1 这类 computer-use Agent 场景更看重动作规划和界面执行，开启额外思考过程可能显著拖慢响应。

5. 安装浏览器自动化 skills

为了让 OpenClaw 更好地操作浏览器，可以安装两个常用 skills：

1
2

openclaw skills install agent-browser-cli
openclaw skills install use-my-browser

安装完成后重启 OpenClaw gateway：

`1`	`openclaw gateway`

也可以在 OpenClaw 对话框里输入：

/new

让它开启新会话并重新加载能力。

6. 测试一个简单任务

可以先用低风险任务测试：

`1`	`打开浏览器，搜索 Holo 3.1 的官方模型页面，总结它支持的模型尺寸和部署方式。`

观察重点不是回答是否漂亮，而是：

能否正确打开浏览器。
能否识别页面内容。
能否连续执行搜索、点击、阅读和总结。
是否频繁卡住或重复操作。
本地模型响应速度是否能接受。

如果浏览器动作正常，再尝试更复杂的任务，例如整理资料、比较模型页面、生成 Markdown 摘要、分析网页表格等。

使用建议

本地 Agent 的优点是成本低、隐私边界清楚、没有云端 token 账单。但它也有现实限制：

小模型适合轻量浏览器任务，不适合高难推理。
视觉模型对界面识别能力很关键，不能只下载主模型。
上下文开太大容易吃显存，建议从保守参数开始。
自动化操作有误点风险，不要一开始就让它处理支付、删除、生产系统等高风险任务。
本地模型不会自动等于安全，浏览器权限、文件权限和命令执行权限仍然要控制。

如果只是做日常网页资料整理、轻量自动化和本地实验，Holo 3.1 + llama.cpp + OpenClaw 是一个值得尝试的组合。它的关键价值不是“免费无限 token”这个口号，而是把 Agent 的运行环境、模型和数据流尽量留在本机。

常见问题

Holo 3.1 是什么？

Holo 3.1 是 H Company 发布的本地 computer-use Agent 模型系列，用于网页、桌面和移动环境中的视觉理解与操作代理任务。

Holo 3.1 可以本地部署吗？

可以。常见做法是下载 GGUF 量化模型，用 llama.cpp 启动 OpenAI-compatible 本地服务，再让 OpenClaw 连接这个 API 地址。

Holo 3.1 需要什么硬件？

取决于模型尺寸和量化版本。小模型更容易本地实验，35B-A3B 这类版本对显存、内存和推理性能要求更高。

Holo 3.1 适合什么任务？

适合本地网页资料整理、轻量浏览器自动化、computer-use Agent 实验和隐私敏感的本地工作流。不建议一开始就用于支付、删除或生产系统操作。

参考链接

Holo 3.1 官方页面：https://hcompany.ai/holo3.1
H Company Hugging Face：https://huggingface.co/Hcompany
Holo 3.1 35B-A3B GGUF：https://huggingface.co/Hcompany/Holo-3.1-35B-A3B-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
OpenClaw + llama.cpp 设置参考：https://openclawlaunch.com/guides/openclaw-llamacpp

Gemma 4 MTP 实测调参：用 assistant 草稿模型冲 120 tokens/s

Fri, 12 Jun 2026 09:07:09 +0800

如果主模型、assistant 草稿模型和推理框架都配对正确，MTP 可以让 Gemma 4 在本地显卡上明显提速。一些 12GB 显存的显卡，例如 RTX 4070，在合适量化和参数下，有机会看到接近 120 tokens/s 的生成速度。

但这不是一个“复制命令就必然得到”的数字。它更适合作为调参目标：跑得起来、显存够、草稿命中率高、采样参数稳定，速度才会漂亮。

MTP 在这里做什么

MTP 是 Multi-Token Prediction，也就是多 Token 预测。

普通自回归模型一次生成一个 token。assistant-MTP 则先替主模型草拟未来几个 token，再由主模型并行验证。如果草稿猜对，主模型就能一次接受多个 token，减少逐 token 等待。

这套机制常叫：

Speculative Decoding
投机解码
草稿模型加速
draft model / drafter

它的目标是加速，不是提升模型能力。最后是否接受某个 token，仍然由主模型决定。

命令行示例

下面是一个偏进阶的 llama-cli 参考命令：

./llama-cli \
  -m gemma-4-12b-it-qat-GGUF.gguf \
  --draft-max 2 \
  -md gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf \
  -ngl 99 \
  -p "<|think|>\n写一篇关于量子计算的短文。"

这条命令的意思是：

用 gemma-4-12b-it-qat-GGUF.gguf 作为主模型。
用 gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf 作为草稿模型。
每轮最多让草稿模型预测 2 个 token。
尽量把模型层卸载到 GPU。
直接传入一个 prompt 测试生成速度。

注意：不同 llama.cpp 版本的参数名可能不同。有的版本用 -md，有的版本更推荐 --model-draft；有的版本用 --draft-max，有的版本用 --spec-draft-n-max。实测前先看：

`1`	`./llama-cli --help`

或者：

`1`	`./llama-server --help`

参数解释

`-m`

`1`	`-m gemma-4-12b-it-qat-GGUF.gguf`

这是主模型。最终输出由它验证和决定。

assistant-MTP 必须和主模型匹配。不要随便拿一个 assistant 模型去配另一个尺寸或版本的主模型，否则轻则没有速度收益，重则直接加载失败或输出异常。

`-md`

`1`	`-md gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf`

-md 用来挂载 draft model，也就是 assistant-MTP 草稿模型。

可以把它理解成“预测候选答案的小助手”。它先猜接下来几个 token，主模型再决定是否接受。

如果你的 llama.cpp 版本不认识 -md，试试：

`1`	`--model-draft gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf`

`--draft-max`

`1`	`--draft-max 2`

它控制草稿模型一次最多预测多少 token。

建议从 2 开始，而不是一上来拉很大。草稿 token 越多，不代表越快；如果猜错率上升，主模型会频繁拒绝，反而浪费计算。

可以这样试：

`1`	`--draft-max 1`

`1`	`--draft-max 2`

`1`	`--draft-max 4`

观察 tokens/s 和输出质量，再决定保留哪个值。

`-ngl 99`

-ngl 99

这个参数表示尽量把模型层卸载到 GPU。对 12GB 显存来说，如果模型量化足够小，可能可以把大部分甚至全部层放进显卡。

但 8GB 显存通常不要照抄。因为 MTP 会多加载一个 assistant 模型，显存压力比只跑主模型更高。

如果 OOM，可以按这个顺序降：

-ngl 80

-ngl 60

-ngl 40

真正稳定的值要看模型量化、上下文长度、显卡剩余显存和系统桌面占用。

`-p`

`1`	`-p "<\|think\|>\n写一篇关于量子计算的短文。"`

-p 是直接传入 prompt。

这里的 <|think|> 是否需要，取决于当前 GGUF 模型的聊天模板和模型说明。它不是所有 Gemma 4 模型的通用开关。为了做速度测试，可以先用更简单的 prompt：

`1`	`-p "写一篇关于量子计算的短文。"`

先确认 MTP 本身能跑，再讨论模板和特殊 token。

更稳的测试命令

第一次测试建议把参数写保守一点：

./llama-cli \
  -m gemma-4-12b-it-qat-GGUF.gguf \
  -md gemma-4-12b-it-qat-assistant-MTP-Q8_0-GGUF.gguf \
  --draft-max 2 \
  -ngl 60 \
  -c 8192 \
  -n 512 \
  --temp 0.7 \
  -p "用三段话解释量子计算。"

如果能稳定跑，再逐步提高 -ngl：

-ngl 80

再试：

-ngl 99

不要第一次就把 -ngl 拉满。MTP 多了一个 draft 模型，显存余量比普通运行更重要。

为什么 120 tokens/s 不一定复现

120 tokens/s 很诱人，但它依赖很多条件。

影响因素	说明
显卡	RTX 4070 这类 12GB 显卡比 8GB 显卡更容易跑高 `-ngl`
量化	QAT / Q4 / Q8 draft 模型组合会影响显存和速度
draft 命中率	草稿猜得越准，主模型一次接受的 token 越多
prompt 类型	结构化文本、代码、固定格式通常更容易加速
temperature	越随机，草稿越难猜中
上下文长度	上下文越长，KV cache 压力越大
llama.cpp 版本	MTP 支持仍在演进，参数和性能可能变化

因此，文章里更建议把它当成“可以冲的速度目标”，而不是承诺值。

适合用来测速的 prompt

MTP 最容易在结构化、低随机性的输出里体现价值。测速时别只让模型自由写散文，可以多试这些：

`1`	`写一个 Python 函数，把 Markdown 表格转换成 CSV，只输出代码。`

1
2

修复下面 JSON，只输出合法 JSON：
{"name":"demo","items":[{"id":1,"tags":["a","b",],},]}

`1`	`用固定格式输出 10 条 Linux 故障排查步骤，每条包含：问题、命令、判断标准。`

如果这些任务的 tokens/s 明显提升，并且输出结构没有变差，说明 assistant-MTP 在你的机器上是有价值的。

常见问题

加了 `-md` 反而 OOM

正常。assistant-MTP 也要占显存或内存。

先降：

-ngl 60

再降上下文：

-c 4096

如果还不稳，就换更小量化，或者先不用 MTP。

参数不识别

说明 llama.cpp 版本和文章里的命令不一致。先看帮助：

`1`	`./llama-cli --help`

重点搜索：

draft

spec

如果当前版本没有 MTP / draft 支持，需要更新 llama.cpp。

输出变奇怪

先去掉 <|think|>，用普通 prompt 测试。再把 temperature 降低：

`1`	`--temp 0.4`

然后把 draft 数量降到：

`1`	`--draft-max 1`

如果这样恢复正常，说明之前的模板、采样或 draft 参数太激进。

小结

Gemma 4 assistant-MTP 的高速度玩法，本质是主模型加草稿模型的投机解码。-md 挂载草稿模型，--draft-max 控制一次草拟多少 token，-ngl 决定 GPU 卸载程度。

12GB 显存机器可以尝试冲更高速度，120 tokens/s 可以作为调参目标；8GB 显存机器则要更保守，因为 draft 模型会额外占资源。

最稳的做法是先跑通，再加速：先低 -ngl、短上下文、低 draft 数量，确认稳定后再逐步提高。

8GB 显存跑 Gemma 4 12B：llama-cli 混合卸载参数怎么配

Fri, 12 Jun 2026 08:58:53 +0800

8GB 显存想跑 Gemma 4 12B，最大的问题不是硬盘空间，而是运行时显存。

以 Q4_K_M 这类 GGUF 量化版为例，模型文件本身可能已经接近 8GB。真正跑起来时，还要额外放 KV cache、临时计算缓冲、系统桌面占用和驱动开销。结果就是：模型看起来“差一点能塞下”，实际一开长上下文就 OOM。

如果机器只有 8GB 显存，更合理的思路不是硬塞全 GPU，而是走显存和系统内存混合卸载：把尽量多的层放进 GPU，剩下的层留在内存里由 CPU 参与计算。

为什么要混合卸载

-ngl 是这套配置里最关键的参数。它控制有多少层卸载到 GPU。

-ngl 26

对于 8GB 显存，目标不是把模型全部塞进显卡，而是留出足够余量给 KV cache 和运行时缓冲。-ngl 26 可以作为一个起步值：显存放一部分模型层，内存接住剩余层。

调参方法很简单：

现象	调整
启动 OOM 或生成时崩溃	把 `-ngl 26` 降到 `22`、`20`
显存只占 6GB 左右	把 `-ngl 26` 提到 `28`、`30`
速度慢但稳定	换更低 bit 量化，或继续提高 `-ngl`
长上下文时 OOM	先降低 `-c`，再降低 `-ngl`

8GB 显存的机器不要只盯着模型大小。真正要看的，是模型层、KV cache、显存碎片和桌面占用加起来是否还有余量。

`--flash-attn`：8GB 显存建议打开

`1`	`--flash-attn`

这个参数对小显存很有帮助。它可以降低注意力计算的显存压力，并改善长上下文推理效率。

如果你的 llama.cpp 构建版本、GPU 后端或显卡架构不支持 Flash Attention，启动时可能会报错。遇到这种情况可以先去掉 --flash-attn 跑通，再更新 llama.cpp 或检查 CUDA / Metal / Vulkan 后端支持。

对 8GB 显存来说，能开就开；开不了，就先降上下文。

`-c 8192`：先把上下文压到 8K

-c 8192

上下文越长，KV cache 越大。很多模型标称支持很长上下文，但小显存机器不能直接按上限开。

8GB 显存上，8192 是比较稳的起点。它足够日常聊天、代码片段分析和中短文处理，又不会像 32K、64K 那样迅速吃光显存。

如果仍然 OOM，可以继续降：

-c 4096

如果你换成更小体积的量化版，并且显存还有明显富余，再尝试：

`1`	`-c 12288`

不要一开始就追求最大上下文。先稳定，再扩容。

`--mlock`：减少内存换出

--mlock

如果系统内存比较充裕，这个参数的作用是尽量把模型驻留在物理内存中，避免被操作系统换到慢速 swap 或页面文件里。

在混合卸载模式下，部分层会留在内存中。如果这些内存页被换出，响应会明显变慢，甚至出现卡顿。--mlock 能减少这种情况。

注意两点：

Linux 上可能需要调整 ulimit -l 或相关权限。
Windows 下不一定需要默认开启，先跑通模型更重要。

如果开启 --mlock 后启动失败，可以先删掉它。它是稳定性和速度优化项，不是必须项。

`-t 8`：CPU 线程数别盲目拉满

-t 8

-t 控制 CPU 线程数。混合卸载时，没放进显存的层需要 CPU 参与计算，所以线程数会影响速度。

建议设置为 CPU 物理核心数，而不是逻辑线程数。比如：

CPU	建议
6 核 12 线程	`-t 6`
8 核 16 线程	`-t 8`
12 核 24 线程	`-t 10` 或 `-t 12`

线程数不是越高越好。拉太满可能导致系统调度、内存带宽和桌面响应都变差。可以从物理核心数开始，再用实际 tokens/s 微调。

关于 `-p "<|think|>\n"`

原始脚本里有这一段：

`1`	`-i -p "<\|think\|>\n"`

这里建议谨慎使用。不同模型、不同 GGUF 转换、不同模板，对思考标记的支持并不一样。把 <|think|> 强行塞进 prompt，不一定会稳定开启所谓“深度思考”，还可能污染输出格式。

更稳妥的做法是先只开交互模式：

-i

如果你确认当前 Gemma 4 GGUF 的聊天模板需要特定系统提示或特殊 token，再按模型卡说明添加。不要把某个标记当成通用开关。

第一次运行建议用保守版

如果担心 8GB 显存不稳，可以先用更保守的脚本：

#!/usr/bin/env bash
set -e

MODEL_PATH="./models/gemma-4-12b-it-Q4_K_M.gguf"

./llama-cli \
  -m "$MODEL_PATH" \
  -ngl 20 \
  -c 4096 \
  -t 8 \
  --flash-attn \
  --mlock \
  -n 512 \
  --color \
  -i

这个版本牺牲了上下文和 GPU 卸载层数，但更容易跑起来。确认稳定后，再调回：

-ngl 26

以及：

-c 8192

想提速，优先换量化

如果 Q4_K_M 在 8GB 显存上只能卸载二十多层，速度会受 CPU 和内存带宽影响。想明显提速，最直接的方法是换更小的量化版本。

可以尝试：

量化	特点
`Q4_K_M`	质量更稳，显存压力较大
`Q3_K_L`	体积更小，可能能卸载更多层
`Q3_K_M`	更省显存，质量会继续下降

换到 Q3_K_M 或 Q3_K_L 后，可以尝试：

-ngl 34

甚至：

-ngl 38

如果模型大部分层都能进 GPU，速度会明显改善。但量化越低，输出质量越可能下降。建议同一组 prompt 对比，不要只看 tokens/s。

内存带宽也很关键

混合卸载不是免费午餐。没进显存的层会走 CPU 和系统内存，速度受内存带宽影响很大。

建议检查：

系统内存是否双通道。
DDR5 是否开启 XMP / EXPO。
后台是否有大量占用内存带宽的程序。
笔记本是否处于高性能电源模式。

如果内存是单通道，混合卸载速度会明显差。对于 8GB 显存 这种配置，系统内存容量够用只是第一步，带宽也要跟上。

排障顺序

遇到 OOM，不要一次改一堆参数。按这个顺序排：

降低上下文：

-c 4096

降低 GPU 卸载层数：

-ngl 22

再不行：

-ngl 20

去掉 --mlock：

`1`	`# 删除 --mlock`

如果 --flash-attn 报错，先去掉它确认是否是后端支持问题：

`1`	`# 删除 --flash-attn`

换更低 bit 量化模型。

每次只改一个参数，记录 tokens/s、显存占用和是否 OOM。这样才知道真正的瓶颈在哪里。

一个调参表

目标	参数
最稳启动	`-ngl 20 -c 4096 -n 512`
日常平衡	`-ngl 26 -c 8192 -n -1`
尽量提速	换 `Q3_K_M`，再试 `-ngl 34` 以上
长上下文	先保留 `--flash-attn`，逐步从 `-c 8192` 往上试
防止内存换出	Linux 上尝试 `--mlock`

8GB 显存最忌讳一步到位。更好的方式是先用保守参数跑通，再把 -ngl 和 -c 一点点往上推。

小结

8GB 显存 跑 Gemma 4 12B Q4_K_M，重点是混合卸载。推荐从 -ngl 26、-c 8192、--flash-attn、--mlock、-t 8 开始；如果 OOM，就先降上下文，再降 GPU 层数。

如果追求速度，换 Q3_K_M 或 Q3_K_L 往往比死磕 Q4_K_M 更有效。系统内存能兜住混合卸载的一部分压力，但真正决定体感速度的，还是 GPU 卸载层数、KV cache 大小和内存带宽。

Hermes Agent 桌面版发布：Windows、macOS、Linux 都能图形化上手

Wed, 10 Jun 2026 00:04:01 +0800

Hermes Agent 过去更像是给开发者和重度 AI 用户准备的 Agent 工作台：能力很强，可以接多种模型和消息平台，但安装、依赖和配置对普通用户并不算友好。现在官方桌面版 Hermes Desktop 发布后，这个门槛明显降低了。

根据零度博客的整理，Hermes Desktop 已经提供 Windows、macOS 和 Linux 版本。用户不再需要先折腾命令行环境、依赖包和一串配置文件，而是可以通过图形界面完成安装、模型接入、语言设置和主题切换。对于只是想先把 AI Agent 用起来的人，这比原来的部署方式直观很多。

如果你还不了解 Hermes Agent 的定位，可以先看之前这篇：Hermes Agent 是什么：简介、优点、快速上手与 OpenClaw 对比。这篇主要聊桌面版带来的变化。

桌面版解决了什么问题

Hermes Agent 本身不是简单聊天壳子，它更像一个可以接模型、接工具、接消息平台的 Agent 运行环境。问题在于，越是这类工具，初次安装越容易劝退普通用户。

过去用户通常要面对这些步骤：

安装运行环境；
处理命令行启动和依赖问题；
手动配置模型提供商；
填写 OpenAI-compatible endpoint；
再接 Telegram、微信、QQ、飞书等消息平台。

桌面版把其中一部分步骤收进了图形界面。安装完成后，用户可以先选择模型服务提供商，再进入设置中心修改显示语言、主题风格和后续配置。它没有改变 Hermes Agent 的能力边界，但把“第一步跑起来”的难度降了下来。

安装和基础设置

官方入口是：

`1`	`https://hermes-agent.nousresearch.com`

从桌面版下载页面选择对应系统版本后，按普通桌面软件的方式安装即可。源文提到，如果网络环境不在海外，下载和初始化过程可能需要稳定的全局网络代理，并建议开启 TUN 模式。

首次启动后，Hermes Desktop 会要求选择模型服务提供商。你可以接云端模型，也可以接本地 OpenAI-compatible 服务。界面默认语言可能是英文，可以在设置中心切换成中文；主题也提供多组风格，适合不想长期盯着终端窗口的用户。

桌面版还保留了图像相关能力。对接支持多模态或图像生成的模型后，可以在 Hermes Agent 里进行图片修改和图片生成。实际效果取决于你接入的模型能力，而不是桌面壳本身。

接入本地模型：Ollama 和 llama.cpp

Hermes Desktop 最值得关注的一点，是它仍然可以接本地模型。也就是说，你可以用图形界面管理 Agent，同时把推理服务放在本机。

如果使用 Ollama，默认 OpenAI-compatible base 地址通常是：

`1`	`http://127.0.0.1:11434/v1`

如果使用 llama.cpp 的 server 模式，常见 base 地址是：

`1`	`http://127.0.0.1:8080/v1`

配置思路很简单：先确保 Ollama 或 llama.cpp 本地服务已经正常运行，再在 Hermes Desktop 里把模型提供商配置为自定义 OpenAI-compatible endpoint，并填入对应 base 地址。API Key 对很多本地服务来说只是占位字段，可以按工具要求填一个本地用的字符串。

站内之前也整理过更偏命令行和 WSL 的方案：Windows 用 WSL + Ollama 本地部署 Hermes Agent，并接入 Telegram。如果你想完全本地化、可控性更高，可以把那篇和这篇结合看。

消息平台接入仍然是重点

Hermes Agent 的一个核心价值，是可以接到常用消息平台。源文提到，它可以对接 Telegram、微信、QQ、WhatsApp、飞书等第三方聊天工具，让用户在不同入口远程调用模型。

这类能力适合几种场景：

把本地模型变成随时可唤起的个人助手；
在手机端通过聊天软件远程触发任务；
给固定工作流做自动化入口；
把 Agent 当成跨设备的任务中转层。

不过消息平台接入通常比桌面安装更复杂，尤其涉及 token、回调地址、消息网关和权限配置。建议先把桌面端和模型调用跑通，再逐步接入外部消息平台。

适合谁使用

Hermes Desktop 更适合下面几类用户。

第一类，是想试 AI Agent，但不想从命令行开始折腾的人。桌面版可以更快完成安装和基础配置。

第二类，是已经在用 Ollama 或 llama.cpp 的本地模型用户。只要本地模型提供 OpenAI-compatible API，就可以把 Hermes Agent 当作更完整的 Agent 操作层。

第三类，是想把 Agent 接到 Telegram、微信、QQ、飞书等入口的人。桌面版降低了本机侧管理成本，但消息平台配置仍需要耐心。

第四类，是需要跨平台的人。Windows、macOS、Linux 同时支持，意味着同一套工作流更容易在不同设备间迁移。

使用时要注意什么

首先，桌面版降低的是安装门槛，不等于所有复杂配置都消失。模型服务、API 地址、本地端口、消息平台授权这些问题仍然需要理解。

其次，本地模型是否好用，取决于模型本身、显存、量化格式和推理后端。Hermes Desktop 只是调用入口，不会自动让小模型具备大模型能力。

第三，不建议把“越狱模型”当成默认选择。它们可能放宽安全约束，但也可能带来输出不可控、许可证不清晰、数据泄露和滥用风险。普通用户优先选择来源清楚、许可证明确的模型更稳。

第四，如果你把 Agent 接到消息平台并开放远程调用，一定要控制权限和访问范围。不要让它默认拥有过高的本机文件、命令执行或网络访问权限。

小结

Hermes Desktop 的意义，不是让 Hermes Agent 变成另一个普通聊天客户端，而是把原本偏开发者的 Agent 工作台做成了更容易上手的桌面产品。

如果你只是想快速体验 AI Agent，它可以省掉大量初始部署成本；如果你已经有本地模型，它可以作为图形化控制层接入 Ollama 或 llama.cpp；如果你想做更复杂的远程助手，还可以继续接 Telegram、微信、QQ、WhatsApp、飞书等消息平台。

对普通用户来说，推荐路径是：先安装 Hermes Desktop，接一个稳定的云端或本地模型，确认基础对话和工具调用正常，再考虑消息平台和更复杂的自动化工作流。

参考来源：零度博客：Hermes Agent 桌面版正式发布

RTX 3060 也能跑 35B？llama.cpp 的 --n-cpu-moe 让老电脑继续本地大模型

Tue, 26 May 2026 21:27:21 +0800

最近看到一篇很有意思的本地大模型实测：同一台大约 3000 元的老电脑，硬件没有变，只是换了新版 llama.cpp 和一组参数，35B MoE 模型的体验直接上了一个台阶。

测试机器并不夸张：

硬件	配置
CPU	AMD Ryzen 7 3700X
GPU	RTX 3060 12GB
内存	32GB DDR4
系统	Windows 11
模型	Qwen3.6-35B-A3B GGUF Q4_K_M

结论很直接：过去同样硬件只能勉强跑低量化版本，现在用新版 llama.cpp，在 Q4 量化、64K 上下文下也能进入“可日常使用”的状态。

关键不是换显卡，而是 MoE 调度

这次优化里最关键的参数是：

`1`	`--n-cpu-moe 32`

Qwen3.6-35B-A3B 属于 MoE（Mixture of Experts，混合专家）模型。它的总参数规模看起来很大，但每次推理并不会激活全部专家，而是只激活其中一部分。

这就给本地推理留下了空间：并不是所有东西都必须塞进 GPU。llama.cpp 的 --n-cpu-moe 参数可以调整 MoE 专家层在 CPU 和 GPU 之间的分配，让显存有限的消费级显卡也能跑更大的模型。

在 RTX 3060 12GB 上，--n-cpu-moe 32 是一个值得优先尝试的平衡点：GPU 负责它擅长的 CUDA 计算，CPU 分担部分专家层。相比全部压给 GPU 或过度依赖 CPU，这种混合调度更快。

速度变化有多明显？

一组典型对比可以这样理解：

项目	旧方案	新方案
生成速度	约 15 tok/s	约 33-36 tok/s
量化	Q2_K_M	Q4_K_M
上下文	4K	64K
显存占用	约 5GB	约 7GB
体验	能跑，但质量不稳	更流畅，回答质量明显提升

这里最值得注意的不是单纯速度翻倍，而是量化精度和上下文长度同时提升。

过去很多 12GB 显存用户为了把 30B+ 模型跑起来，只能选择 Q2 这种压缩很重的量化。模型能启动，但推理质量容易变差。现在能切到 Q4，意味着本地模型从“能体验”更接近“能干活”。

一个可参考的 Windows 启动命令

下面是一个 Windows 批处理启动模板，路径按自己的机器替换：

@echo off
chcp 65001 >nul

cd /d C:\Users\你的用户名\llama-b9297-bin-win-cuda-13.1-x64

llama-server.exe ^
 -m "D:\Qwen3.6-35B-A3B-UD-Q4_K_M.gguf" ^
 -ngl 99 ^
 --n-cpu-moe 32 ^
 --flash-attn on ^
 --jinja ^
 -c 65536 ^
 -t 8 ^
 -b 512 ^
 -ub 128 ^
 --cache-type-k q4_0 ^
 --cache-type-v q4_0 ^
 -np 1 ^
 --cache-ram 0 ^
 --host 127.0.0.1 ^
 --port 8080

pause

几个重点参数：

-ngl 99：尽量把能 offload 的层放到 GPU；
--n-cpu-moe 32：控制 MoE 专家层调度，是这次提速的关键；
--flash-attn on：开启 Flash Attention，降低长上下文压力；
-c 65536：设置 64K 上下文；
--cache-type-k q4_0 / --cache-type-v q4_0：量化 KV cache，减少长上下文显存占用；
-np 1：单并发，适合 32GB 内存机器；
--cache-ram 0：关闭 prompt cache，进一步控制内存。

需要注意的是，b9297 只是一个测试时点。截至 2026-05-26，llama.cpp Release 页面已经继续更新到更高版本，所以实际使用时不必拘泥于 b9297，可以优先尝试更新的 CUDA 构建。

不同显卡怎么调？

这类 MoE 模型的思路不是“显存不够就放弃”，而是通过 CPU/GPU 分工去找平衡点。

硬件	建议
RTX 3060 12GB / 3080 10GB	可以先试 `--n-cpu-moe 32`
RTX 3070 8GB / 4060 8GB	可以把 `--n-cpu-moe` 调大，例如 128 或 256
RTX 3050 6GB / GTX 1650 4GB	可以尝试更高的 CPU offload，但速度会明显下降
Apple Silicon Mac	用 Metal 后端，统一内存对大模型更友好

不要把这些数值当成绝对答案。--n-cpu-moe 的最佳值和模型、量化、显卡、CPU、内存带宽都有关系。更稳妥的做法是从几个典型点测试：

`1`	`0 / 16 / 32 / 64 / 128 / 256`

看 tok/s、内存占用、首 token 延迟和回答稳定性，再决定最终配置。

32GB 内存够不够？

结论是：能跑，但余量不大。

这类配置下，llama-server 进程工作集可能来到 20GB 以上，系统还要保留内存给浏览器、编辑器、驱动和后台服务。如果只是单人本地使用，32GB 可以尝试；如果想长期挂服务、多并发调用，64GB 会舒服很多。

建议：

尽量单并发测试；
关闭不必要的后台程序；
浏览器标签别开太多；
先确认 CUDA 后端正常加载；
不要一开始就把上下文拉到 128K。

为什么这件事值得关注？

本地大模型的门槛一直被“显存焦虑”放大。很多人默认认为 35B 级别模型必须 24GB 显存，最好还得 4090。

这次实测说明了另一个方向：模型结构和推理框架的优化，能让旧硬件继续释放价值。MoE、KV cache 量化、Flash Attention、CUDA kernel 优化、CPU/GPU 混合 offload，这些进步叠加起来，可能比单纯升级显卡更影响实际体验。

当然，它不是魔法。8GB、12GB 显卡跑 35B MoE 仍然需要取舍：速度、上下文、量化质量、内存占用不可能全都拉满。但如果目标是个人知识库、代码助手、长文档问答、离线测试，这类方案已经很值得折腾。

我的结论

如果你手里有 RTX 3060 12GB、RTX 3080 10GB，甚至 8GB 显卡，不妨重新看一眼新版 llama.cpp。

重点不是照抄某一个参数，而是理解这套思路：

MoE 模型不一定要把所有专家都塞进 GPU，合理的 CPU/GPU 分工，可能比“显存够不够”更重要。

老电脑不一定只能跑小模型。只要框架持续优化、量化方案继续进步，很多原本被判定“跑不动”的本地模型，会重新变得可用。

参考链接

llama.cpp Releases

Qwen3.6-35B-A3B 越狱版本地部署：无审查 GGUF、llama.cpp 与安全边界

Sun, 24 May 2026 23:52:16 +0800

零度博客最近介绍了一款热度很高的本地模型：Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive。原文把它称为“越狱版”“无审查”开源模型，并给出了 GGUF 量化包、llama.cpp 启动方式和 Agent 对接思路。

这类模型值得关注，但更适合冷静理解：它的重点不只是“限制少”，而是把几个本地 AI 关键能力放到了一起：

MoE 架构下的 35B 级模型。
GGUF 量化后可在消费级显卡上运行。
通过 llama.cpp 提供 OpenAI API 兼容接口。
搭配 mmproj 支持多模态视觉输入。
可以接入 Hermes、OpenClaw 等本地 Agent 工具。

如果你关心本地模型，这篇更值得看的不是“越狱”噱头，而是它代表的趋势：本地模型正在从“能聊天”走向“能接入工具、能看图、能做 Agent 后端”。

这个模型是什么

原文提到的模型全名是：

`1`	`Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive`

从名字可以拆出几个关键信息：

Qwen3.6：基于 Qwen 系列模型。
35B：总参数规模约 35B。
A3B：每次推理激活参数约 3B，属于 MoE 思路。
Uncensored / Aggressive：经过更少安全限制或更激进风格调整的版本。
GGUF：面向 llama.cpp 等本地推理工具的量化格式。

这里要特别注意：Uncensored 并不等于“更可靠”。它通常意味着模型更少拒答，也更可能生成不受约束、未经事实核验或有风险的内容。对技术研究来说可以实验，但不适合直接接入公开服务、生产系统或无人值守任务。

为什么 35B 模型还能在本地跑

很多人看到 35B 会以为必须用服务器或高端多卡机器。原文强调的关键点是：这个模型采用 MoE 架构。

MoE 可以简单理解为：模型总参数很大，但每次推理不会激活全部参数，而是只激活其中一部分专家。原文称它每次实际运行大约激活 3B 参数，因此在一定量化下，速度和显存压力会比传统 dense 35B 模型低很多。

再叠加 GGUF 量化后，它就有机会在消费级显卡上运行。原文提到最小量化版本约 11GB，6G/8G 显存也能尝试，但更建议至少 8G 显存。

更现实的理解是：

6G 显存：可以尝试低比特量化，但上下文和速度都要降低预期。
8G 显存：更适合入门测试，建议选更小量化。
16G 显存：体验会明显宽松，适合更长上下文和更多 GPU offload。
24G 显存：更适合 Q4_K_M、Q4_K_P 这类质量更好的量化版本。

本地模型能不能“好用”，不能只看能不能启动，还要看上下文长度、生成速度、显存余量、KV cache、是否启用多模态、并发需求和实际任务类型。

llama.cpp 部署思路

原文推荐使用 llama.cpp，原因是它支持 Windows、Linux、macOS，也支持 NVIDIA CUDA、AMD、Intel、Vulkan 和纯 CPU 等多种后端。

一个典型启动方式类似：

llama-server.exe ^
  -m "模型路径.gguf" ^
  --mmproj "mmproj.gguf" ^
  -ngl 999 ^
  -c 131072 ^
  -n 8192 ^
  --host 127.0.0.1 ^
  --port 8080 ^
  --jinja

几个参数值得单独理解：

-m：主模型 GGUF 文件路径。
--mmproj：多模态投影文件，启用视觉能力时需要。
-ngl：尽量把层 offload 到 GPU，具体效果取决于显存和后端。
-c：上下文长度，越大越吃内存和显存。
-n：单次生成 token 上限。
--host 127.0.0.1：只监听本机，安全性比暴露公网高。
--port 8080：本地 API 服务端口。
--jinja：新版 Qwen 模型常需要正确聊天模板，否则可能出现格式错乱、重复或中文异常。

这里最容易踩坑的是上下文长度。-c 131072 看起来很诱人，但长上下文会显著增加 KV cache 占用。低显存机器不建议盲目拉满，应该先用较小上下文跑通，再逐步增加。

多模态能力怎么用

原文提到这个版本支持多模态视觉识图，可以分析图片、截图、OCR、复杂 UI 和代码截图。

在 llama.cpp 里，多模态通常需要主模型和 mmproj 文件配套。没有正确加载 --mmproj 时，前端里的图片上传能力可能不可用，或者模型无法正确理解图像。

多模态本地模型的实用场景包括：

分析截图里的 UI。
OCR 识别图片文本。
阅读代码截图或报错截图。
给本地 Agent 提供视觉输入。
在不上传云端的情况下处理隐私图片。

但它也有边界：视觉理解不等于严格 OCR，不适合作为唯一事实来源。涉及账单、合同、证件、医疗图像等高风险内容时，仍然需要人工复核。

OpenAI API 兼容接口

llama.cpp 的 llama-server 可以提供类似 OpenAI API 的本地接口。原文给出的本地 base URL 是：

`1`	`http://127.0.0.1:8080/v1`

这意味着很多支持自定义 OpenAI-compatible provider 的工具，可以把请求转到本地模型上。API key 通常可以随便填一个占位值，具体取决于客户端是否强制校验。

这类能力的意义很大：

不需要云端 API key。
不产生按 token 计费。
数据可以留在本机。
可以接入本地 Agent、代码助手或聊天前端。
可以作为 OpenAI API 的本地替代后端做实验。

但不要把本地接口直接暴露到公网。即使模型在本地，API 一旦开放到局域网或公网，也可能被别人滥用，导致机器资源被打满，甚至让模型输出你不希望生成的内容。

对接 Hermes 和 OpenClaw 的意义

原文提到，将这个本地模型接入 Hermes 或 OpenClaw，才能真正体现它的价值。

这句话的意思是：模型本身只是推理核心，Agent 工具才负责把它接到真实任务里。比如：

写代码。
调用工具。
读取文件。
分析图片。
联网搜索。
执行多步骤任务。
维护长上下文工作流。

本地模型如果只用来聊天，价值有限；如果能稳定作为 Agent 后端，才更接近“本地 AI 工作站”。

不过，无审查模型接入 Agent 时要更谨慎。Agent 能操作文件、运行命令、访问网页、调用工具时，模型的输出会转化为真实动作。模型越少限制，越需要外层权限控制、人工确认和审计日志。

无审查模型的风险边界

这类模型最大卖点通常是“少拒答”。但少拒答也意味着更大的风险。

需要注意几件事：

它可能更容易输出违法、危险或误导性内容。
它可能不会主动提醒安全边界。
它可能在高风险问题上给出过度自信的建议。
它可能被提示词诱导执行不合适的任务。
它不适合直接面向公众开放。

更稳妥的做法是：

只在本机或受控局域网内测试。
不把它接入高权限工具。
不让它自动执行删除、支付、发帖、批量提交等不可逆操作。
给 Agent 工具设置文件、命令、网络和浏览器权限边界。
对高风险输出保持人工复核。

换句话说，越是“自由”的模型，越需要外层系统约束。

适合谁尝试

这类模型适合以下用户：

想研究本地大模型部署的人。
有 8G 以上显存，愿意折腾 GGUF 和 llama.cpp 的用户。
想把本地模型接入 OpenAI-compatible 客户端的人。
关注本地多模态、截图分析和 Agent 后端的人。
想离线处理部分隐私数据的开发者。

不太适合以下场景：

完全不想调参数的新手。
需要稳定生产 SLA 的服务。
对安全合规要求高的团队。
需要严格事实可靠性的业务流程。
想把模型直接公开给外部用户的人。

简单结论

Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive 这类模型的出现，说明本地 AI 的能力边界正在快速往前推：消费级显卡可以跑更大模型，GGUF 量化让部署门槛下降，llama.cpp 让本地模型具备 OpenAI API 兼容接口，多模态和 Agent 工具又把它从聊天推进到任务执行。

但不要把它只理解成“越狱模型”。更有价值的角度是：本地 AI 正在成为可组合的基础设施。模型、推理引擎、API 服务、前端、Agent 工具、权限控制，会一起决定最终体验。

如果你要尝试，建议先从低风险本地测试开始：选合适量化，降低上下文长度，确认 --jinja 和 --mmproj 配置正确，再接入客户端。等稳定后，再考虑接入 Agent 工作流。

参考资料：

零度博客原文：https://www.freedidi.com/24284.html
llama.cpp GitHub：https://github.com/ggml-org/llama.cpp

RTX 3070 8GB 本地运行 Qwen3.6-35B：llama.cpp 部署要点与优化参数

Fri, 22 May 2026 22:44:16 +0800

8GB 显存能不能跑 35B 级别模型，关键不只看模型总参数量，还要看模型结构、量化格式和推理框架的调度方式。

这次案例的核心思路是：使用 Qwen3.6-35B-A3B 这类 MoE 模型的 GGUF 量化版本，再通过 llama.cpp 的 CUDA 加速、CPU Offload、MoE 参数调度和 KV Cache 量化，把显存压力分摊到 GPU 与内存之间。这样一来，RTX 3070 8GB 这类老显卡也有机会跑起 35B 级别的本地多模态模型。

需要先说明一点：这不是“8GB 显存完整装下 35B 模型”。更准确的理解是，显卡负责更适合 GPU 的计算部分，部分专家层和缓存压力由系统内存承担。实际体验会受到内存容量、CPU 性能、模型量化格式、上下文长度和参数设置影响。

测试环境

这类配置对内存比较敏感。参考环境如下：

CPU：Intel Core i7-12700 级别
GPU：NVIDIA RTX 3070 8GB
内存：64GB
系统：Windows 11
推理框架：llama.cpp CUDA 版本
模型格式：GGUF

如果只有 16GB 或 32GB 内存，也不是完全不能尝试，但 35B MoE 模型在加载和长上下文推理时更容易触发内存压力。想要稳定使用，64GB 内存会更稳。

为什么 8GB 显存也有机会跑 35B

Qwen3.6-35B-A3B 的关键点在于 MoE 架构。它的总参数规模是 35B，但每次推理并不是所有参数都同时激活，而是只激活其中一部分专家参数。

这会带来两个结果：

总模型文件仍然很大，需要足够磁盘和内存承载。
单次推理的活跃计算量低于完整 35B Dense 模型。

llama.cpp 的 CPU Offload 和 MoE 相关参数可以进一步降低显存门槛。GPU 主要承担注意力和部分高收益计算，CPU 与内存承担一部分专家层权重。代价是速度、响应延迟和稳定性会更依赖整机配置，而不是只看显卡型号。

准备 llama.cpp

Windows 用户可以直接下载 llama.cpp 的预编译 CUDA 版本。需要注意三点：

显卡驱动要足够新，CUDA 运行环境要和下载的 llama.cpp 包匹配。
下载后建议放在一个不含中文和特殊字符的路径下，方便批处理脚本调用。
模型文件统一放到 models 目录，避免命令里写太长路径。

如果是 AMD、Intel 显卡或纯 CPU 环境，也可以选择 Vulkan、HIP、SYCL 或 CPU 版本，但参数和性能表现会不同。本文重点仍然是 NVIDIA 显卡上的 CUDA 路线。

下载模型和多模态投影文件

本次使用的模型是：

Qwen3.6-35B-A3B-UD-Q4_K_M.gguf

量化格式选择 Q4_K_M，主要是为了在精度、体积和速度之间取得平衡。显存较小的机器不建议一开始就尝试更高精度版本，否则加载失败或系统频繁换页的概率会明显上升。

如果要使用图片理解能力，还需要同时准备多模态投影文件，例如：

mmproj-BF16.gguf

这个文件非常重要。只下载主模型通常只能完成文本推理；如果缺少 mmproj，网页 UI 里可能看不到正常的图片上传能力，或者上传后无法完成视觉理解。

建议目录结构保持简单：

llama.cpp/
├─ llama-server.exe
└─ models/
   ├─ Qwen3.6-35B-A3B-UD-Q4_K_M.gguf
   └─ mmproj-BF16.gguf

RTX 3070 8GB 启动参数

下面是一份面向 RTX 3070 8GB 的启动脚本示例。路径需要改成你自己的 llama.cpp 所在目录。

@echo off
chcp 65001 >nul
cd /d D:\AI\llama.cpp

llama-server.exe ^
  -m "models\Qwen3.6-35B-A3B-UD-Q4_K_M.gguf" ^
  --mmproj "models\mmproj-BF16.gguf" ^
  -ngl 99 ^
  --n-cpu-moe 999 ^
  --flash-attn on ^
  --jinja ^
  -c 32768 ^
  -t 12 ^
  -b 512 ^
  -ub 128 ^
  --cache-type-k q4_0 ^
  --cache-type-v q4_0 ^
  --mlock ^
  --host 127.0.0.1 ^
  --port 8080

pause

启动后在浏览器访问：

`1`	`http://127.0.0.1:8080`

如果页面可以打开，并且模型能正常回复，就说明服务已经启动成功。首次加载模型可能会比较慢，期间不要急着重复运行多个实例，否则更容易把内存占满。

关键参数怎么理解

-ngl 99 表示尽量把可放到 GPU 的层放到显卡上。实际能放多少，取决于模型结构、量化格式和显存占用。

--n-cpu-moe 999 用来让 MoE 专家层更多走 CPU 侧，降低显存压力。它是这类小显存运行大 MoE 模型的关键参数之一。

--flash-attn on 开启 Flash Attention，有助于降低注意力计算的开销。是否可用取决于当前 llama.cpp 版本和显卡支持情况。

-c 32768 设置上下文长度。长上下文会显著增加 KV Cache 压力，如果启动失败或推理很慢，可以先降到 8192 或 16384。

--cache-type-k q4_0 和 --cache-type-v q4_0 用于量化 KV Cache，能节省内存和显存，但可能对输出质量和速度有轻微影响。

-b 512 与 -ub 128 控制批处理相关参数。小显存环境下，不要一开始就把批量参数设得太激进。

常见问题

如果启动时报显存不足，可以先降低上下文长度，例如把 -c 32768 改成 -c 8192，再尝试减小 -b 和 -ub。

如果图片上传按钮不可用，优先检查 --mmproj 路径是否正确，以及使用的 mmproj 是否和模型匹配。

如果模型加载后响应很慢，通常不是显卡完全没工作，而是大量权重或专家层由 CPU 与内存承担。可以观察任务管理器里的 GPU、CPU、内存和磁盘占用，判断瓶颈在哪里。

如果输出格式异常，确认是否启用了 --jinja，并检查当前模型是否需要对应聊天模板。

如果服务启动后浏览器打不开，检查 --host 和 --port 设置，确认 8080 端口没有被其他程序占用。

适合谁尝试

这套方案适合手上已有 RTX 3070、RTX 4060 Laptop、RTX 3060 8GB 这类 8GB 显存设备，但又想尝试更大 MoE 模型的用户。

它不适合追求极致速度的人。小显存运行 35B MoE 本质上是在用内存和 CPU 换显存门槛，能跑起来是一回事，是否足够流畅是另一回事。

如果目标是日常高频聊天，7B、8B、14B 模型可能更舒服。如果目标是体验更大 MoE 模型、多模态能力和本地部署边界，那么 RTX 3070 8GB 加 64GB 内存仍然有尝试价值。

小结

RTX 3070 8GB 能运行 Qwen3.6-35B-A3B 的关键，不是显存突然变大，而是 MoE 架构、GGUF 量化、llama.cpp CPU Offload 和 KV Cache 优化共同降低了门槛。

这类方案最值得关注的地方，是它让旧显卡仍然能参与本地大模型实验。只要接受速度和稳定性上的取舍，8GB 显存机器也可以成为本地 AI 模型测试平台，而不只是运行小模型的入门设备。

llama.cpp b9196 更新：Windows 预编译版支持 CUDA 13.1、Vulkan、HIP 和 SYCL

Mon, 18 May 2026 23:20:00 +0800

llama.cpp 最近的 Windows 版本对本地大模型用户更友好了。以前在 Windows 上跑 GGUF 模型，很多人卡在环境问题上：CUDA 版本不匹配、DLL 缺失、驱动不兼容、CMake 编译失败、环境变量错误，或者 Vulkan / HIP / SYCL 配置太麻烦。

现在官方 Release 已经提供多种 Windows 预编译包。很多场景下，用户不再需要从源码编译，下载对应版本、解压、放入模型文件后，就可以直接启动本地推理服务。

llama.cpp 适合做什么

llama.cpp 是目前最常用的本地 GGUF 模型推理框架之一。它的特点是轻量、跨平台，既能跑 CPU，也能利用 GPU，并且围绕 GGUF 生态积累了大量模型资源。

常见模型路线包括：

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

随着 GGUF 量化模型越来越普及，很多开源模型都会提供适合本地部署的 GGUF 版本。对普通用户来说，llama.cpp 的价值主要在于：不用搭一整套复杂推理框架，也能在本机跑一个可用的聊天服务。

Windows 预编译版本怎么选

目前 Windows 用户可以根据硬件选择不同构建版本：

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

如果是 NVIDIA 显卡，通常优先考虑 CUDA 版本。RTX 3060、4060、4070、4080、4090 这类显卡都更适合走 CUDA 路线。

如果是 AMD 显卡，可以尝试 HIP 或 Vulkan。实际体验里，Vulkan 的兼容性有时比 HIP 更省心，尤其适合不想折腾完整 ROCm 环境的用户。

如果是 Intel 核显或 Arc 独显，可以尝试 SYCL 或 Vulkan。性能通常不如 NVIDIA CUDA 路线，但跑一些中小型 GGUF 模型已经足够测试。

CPU 版本适合没有独显、只是想验证模型或跑小参数模型的用户。速度不会太快，但部署最简单。

启动普通 GGUF 模型

假设你已经下载好 llama.cpp Windows 预编译包，并把模型放到 models 目录。进入 llama.cpp 解压目录后，可以用类似命令启动：

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

这里的 -m 指向 GGUF 模型文件，-ngl 999 表示尽量把模型层加载到 GPU。实际能加载多少，取决于显存容量、模型大小和量化格式。

启动成功后，在浏览器打开：

`1`	`http://127.0.0.1:8080`

就可以进入本地网页聊天界面。

如果显存不足，可以换更小的模型，或者换更低量化版本，例如 Q4、Q5 这类 GGUF 文件。不要只看模型参数量，也要看量化格式和上下文长度设置。

启动多模态视觉模型

多模态视觉模型通常不只需要一个主模型文件，还需要一个 mmproj 视觉投影文件。启动时要同时指定主模型和 mmproj：

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

常见用途包括：

OCR 识别
截图理解
网页截图分析
图片问答
简单视觉内容判断

例如 Qwen2-VL / Qwen2.5-VL 这类视觉模型，在中文截图理解、OCR 和图文问答上比较实用。使用时要注意主模型和 mmproj 文件是否匹配，版本不匹配很容易导致加载失败或效果异常。

用 bat 脚本管理多个模型

如果本地同时放了多个模型，可以写一个简单的 .bat 脚本做菜单切换。下面是一个示例，路径和模型名需要改成你自己的：

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

保存时建议使用 UTF-8 编码，再把文件后缀改成 .bat。这样双击脚本后，就可以通过数字选择不同模型。

模型选择要看三件事

第一，看硬件。显存越大，能跑的模型越大；显存不足时，不要硬上大模型，可以先从 7B、8B 或更低量化版本开始。

第二，看用途。如果只是日常问答、总结、改写，小模型和中等量化通常够用。如果要做代码、长文档分析或多模态理解，就需要更强模型和更多显存。

第三，看许可证和安全边界。网上有很多社区改版模型，能力、限制和许可证都不一样。下载前要确认来源、授权、适用场景和风险，不建议把生产任务直接交给来源不明的模型。

常见问题

如果启动时报 DLL 缺失，先确认下载的包和显卡路线是否匹配。例如 NVIDIA 用户不要误下载 HIP 版本，AMD 用户也不要下载 CUDA 版本。

如果模型加载很慢，可能是模型太大、硬盘速度慢，或者显存不足导致部分层回落到 CPU。

如果网页打不开，先看命令行是否已经成功启动服务，再确认端口是不是 8080。如果端口被占用，可以查阅 llama-server 参数换端口。

如果多模态模型效果不对，优先检查 mmproj 文件是否和主模型配套，而不是只换提示词。

小结

这次 Windows 预编译包的价值在于降低了本地 AI 的入门门槛。以前很多用户卡在编译和依赖环境，现在可以更快进入“下载模型、启动服务、测试效果”的阶段。

对 Windows 用户来说，选择路线可以简单理解为：

NVIDIA：优先 CUDA。
AMD：优先尝试 Vulkan，再看 HIP。
Intel：尝试 SYCL 或 Vulkan。
没有独显：用 CPU 版本跑小模型。

真正使用前，仍然要确认模型来源、许可证、显存需求和实际效果。本地 AI 的好处是可控、离线、低延迟，但它不等于没有成本：模型管理、硬件资源和输出质量都需要自己负责。

参考来源：https://www.freedidi.com/24211.html

llama.cpp 多 GPU 性能实测思路：2x V100 16GB 会比单卡 32GB 快吗？

Sat, 09 May 2026 15:05:41 +0800

大概结论：llama.cpp 多 GPU offload 不是“多一张卡就白捡一倍性能”。如果模型本来能完整放进一张 32GB 显卡，2x V100 16GB 通常不如单张 32GB 显卡省心，甚至可能更慢；如果模型单张 16GB 放不下，双卡的主要价值是“能把模型放进 GPU”，这时收益会很明显。

先分清 split mode

llama.cpp 的多 GPU 主要围绕 --split-mode 和 --tensor-split 使用。实际讨论性能时，先要区分几种模式：

layer：按层切分到不同 GPU，兼容性较好，也是多数人优先尝试的方式。
tensor：把张量计算拆到多张 GPU 上，更接近并行计算，但更依赖 GPU 之间的互联带宽和后端支持。
row：旧的行切分方式，在不少场景里仍能看到，但新部署通常不建议优先从它开始。

简单说，layer 更像“把不同楼层放在不同卡上”，单 token 生成时不一定能让两张卡同时满负载；tensor 更像“同一层两张卡一起算”，理论上更能并行，但跨卡通信会成为关键瓶颈。

单卡 32GB 能放下时：双 16GB 不一定更快

如果模型和 KV cache 能完整放进一张 32GB 显卡，那么单卡通常更稳，也常常更快。对 1x V100 32GB 和 2x V100 16GB 这类同代硬件来说，后者未必能赢。

比较保守的预期是：2x V100 16GB 可能比单张 V100 32GB 慢 10% 到 40%，尤其是单人聊天、Continue Agent、代码问答这类一次主要生成一个回答的场景。

原因不复杂：多 GPU 不是简单合并显存。按层切分时，推理会在不同 GPU 之间流转，单 token 生成阶段经常是部分 GPU 等另一部分 GPU；按张量切分时，两张卡可以一起算，但中间结果需要跨卡同步，互联带宽和延迟会直接影响吞吐。

所以如果你的选择是：

1x V100 32GB
2x V100 16GB

并且目标模型单张 32GB 已经能完整放下，那么单张 32GB 往往是更舒服的选择。

单卡 16GB 放不下时：双卡价值很大

另一种情况完全不同：模型单张 16GB 放不下，但两张 16GB 合起来可以放下。

这时双卡的价值就很直接：

单张 16GB：可能需要大量 CPU offload，速度明显变慢。
2x 16GB：权重尽量留在 GPU 上，速度可能比 CPU/GPU 混跑快很多。

这种场景下，2x V100 16GB 不一定比单张 32GB 快，但它可能比“单张 16GB 加大量系统内存 offload”快几倍。也就是说，双卡的第一价值不是加速，而是避免模型被迫落到更慢的系统内存里。

V100 PCIe 和 V100 SXM2 差别很大

多 GPU 推理最容易被忽略的是互联。

如果是 V100 SXM2，并且机器里有 NVLink，跨卡通信带宽高很多。NVIDIA 的 V100 资料里，NVLink 互联最高可到 300GB/s。这种环境下，tensor 或更高 batch 的场景才更有机会接近甚至超过单卡表现。

如果是 V100 PCIe，情况就保守得多。V100 PCIe 的互联主要走 PCIe Gen3，资料里标的 interconnect bandwidth 是 32GB/s。这个带宽和 NVLink 不是一个量级，所以双卡经常出现“显存够了，但速度没有翻倍”的情况。

因此判断 2x V100 16GB 值不值得，不能只看显存相加是 32GB，还要看它们是 PCIe 版还是 SXM2/NVLink 版。

怎么选更实际

如果模型能放进单张 32GB 显卡，优先选单卡。它的延迟、稳定性和调参成本通常更好。

如果模型单张 16GB 放不下，而两张 16GB 能放下，双卡值得用。此时重点是让权重尽量留在 GPU，而不是期待性能线性翻倍。

如果是 V100 PCIe 双卡，优先尝试 --split-mode layer，把目标放在“能稳定跑”和“少走 CPU”上。

如果是 V100 SXM2/NVLink，才更值得测试 tensor 相关模式，尤其是 prefill、大 batch 或并发请求场景。

什么时候买 2x16GB，什么时候买 1x32GB

如果你只服务一个人，主要做聊天、代码补全、Continue Agent、长上下文问答，并且目标模型能放进 32GB，那么 1x32GB 通常更值得。它少了跨卡调度，延迟更稳定，排查问题也简单。

如果你已经有一张 16GB 卡，想用较低成本扩到能跑 30B、32B 或更高量化模型，2x16GB 就有意义。它不一定让 token/s 翻倍，但可以把原本必须 CPU offload 的权重留在 GPU 上。

如果你准备重新采购，优先级可以这样排：

单模型、单用户、重视响应延迟：优先 1x32GB。
模型单卡放不下、预算有限：可以考虑 2x16GB。
有 NVLink 或 SXM2 机器：2x16GB 的可玩性明显高于普通 PCIe 双卡。
未来想跑更长上下文：不要只看权重大小，还要预留 KV cache 显存。

layer split 和 tensor split 怎么用

实用建议是：先用 layer，再测 tensor。

layer 适合作为默认起点。它按层分配模型，兼容性较好，对 PCIe 双卡更友好。缺点是生成阶段可能更像流水线，某些时刻只有一张卡在忙，另一张卡在等。

tensor 更适合互联带宽好的机器，例如 V100 SXM2/NVLink。它把同一层的部分计算拆到多张卡上，理论上更有并行空间，但跨卡同步更频繁。如果是 PCIe 双卡，tensor 可能会被通信开销吃掉收益。

实际测试时可以从这几组开始：

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

第三条不是为了长期使用，而是给单卡结果做一个参照。这样才能看出双卡到底是更快，还是只是把显存压力分摊出去了。

prefill 和 decode 为什么表现不同

本地大模型性能通常要分成两个阶段看：

prefill：处理输入 prompt，典型指标是 pp512 这类 prompt processing 吞吐。
decode：逐 token 生成回答，典型指标是 tg128 这类 token generation 吞吐。

prefill 更像大批量矩阵计算，batch 较大时更容易把 GPU 喂饱，也更可能从多 GPU 并行里受益。decode 是一个 token 接一个 token 生成，batch 小、同步频繁，跨卡通信和调度延迟更容易暴露出来。

所以你可能会看到一种结果：双卡的 pp512 更好，但 tg128 没明显提升，甚至更慢。对聊天和 Agent 来说，用户体感更接近 tg128；对长文档导入、批量预填充、并发服务来说，pp512 也很重要。

KV cache 会不会成为第二个显存瓶颈

会。很多人只算模型权重，忘了 KV cache。

模型权重决定“能不能加载模型”，KV cache 决定“能不能开足上下文”。上下文越长、并发越高、batch 越大，KV cache 占用越明显。你可能遇到这种情况：模型本体能放进 32GB，但一开 32K 或 64K 上下文，显存又不够了。

判断时至少要留出几块显存余量：

KV cache
CUDA graph 或后端运行时开销
prompt batch 和 ubatch
系统桌面、驱动和其它进程占用

如果你用的是 2x16GB，显存不是一个完全等价的 32GB 大池子。某些缓冲区、KV cache 或中间张量仍然会受单卡剩余显存影响。测试长上下文时，最好直接用目标 --ctx-size 和目标并发数测，而不是只看模型能不能启动。

用 llama-bench 做自己的双卡测试

llama-bench 比直接聊天更适合做硬件对比，因为它会把 prompt processing 和 token generation 拆成可比较的指标。官方 README 的默认示例就是：

`1`	`llama-bench -m model.gguf`

对双 V100，可以至少测这几组：

# 单卡基线
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# 双卡 layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# 双卡 tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

重点看两列：

pp512：prompt processing，长输入和批量预填充更相关。
tg128：token generation，单人聊天和 Agent 体感更相关。

测试时尽量固定模型、量化格式、上下文、batch、驱动版本和 llama.cpp 版本。每组多跑几次，取中位数，比只看一次结果可靠。最后再用真实工作流跑一遍，例如 Continue Agent、OpenAI-compatible server 或你自己的 RAG 请求，因为 benchmark 好看不代表交互体验一定更好。

一句话结论

2x V100 16GB 的优势主要是显存容量，而不是必然的生成速度。模型单卡能放下时，单张 32GB 往往更快、更稳；模型单卡放不下时，双 16GB 的价值就很大，因为它能避免大量 CPU offload。至于能不能更快，关键看 split mode、batch、模型大小，以及两张 V100 之间到底是 PCIe 还是 NVLink。

参考资料：

适合 RTX 3060 显卡运行的本地 LLM 模型推荐

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 最常见的是 12GB 显存版本。它不是顶级 AI 显卡，但用来跑本地 LLM 很合适，尤其适合 7B、8B、9B、12B 级别模型。

如果只想快速选型，可以先记住一句话：

RTX 3060 12GB 优先选 8B 左右模型的 Q4_K_M 或 Q5_K_M 量化；想要更稳就选 Q4，想要更好质量再试 Q5。

不要一上来就追 32B、70B。它们即使用低比特量化和 CPU offload 能跑，速度和体验通常也不适合日常使用。

先看显存边界

RTX 3060 12GB 跑本地 LLM，真正限制是显存。

大致可以这样理解：

模型规模	推荐量化	3060 12GB 体验
3B / 4B	Q4、Q5、Q8	很轻松，速度快
7B / 8B / 9B	Q4_K_M、Q5_K_M	最推荐，质量和速度平衡好
12B / 14B	Q4_K_M	可以尝试，注意上下文不要太大
30B 以上	Q2 / Q3 或部分 offload	能折腾，但不推荐日常使用
70B 以上	极低量化或大量 CPU/RAM 参与	更像实验，不适合普通使用

本地 LLM 不只是模型文件大小占显存。上下文长度、KV cache、批处理大小、推理框架和显卡驱动都会占资源。

所以 12GB 显存并不等于可以直接加载 12GB 模型文件。更稳的做法是给系统和上下文留余量。

推荐一：Qwen3 8B

如果你主要用中文，Qwen3 8B 是 RTX 3060 上很值得优先尝试的模型。

适合场景：

中文问答。
摘要和改写。
日常知识助手。
简单代码解释。
本地 RAG。
轻量 Agent 流程。

建议选择：

1
2
3

Qwen3 8B GGUF
Q4_K_M：优先推荐
Q5_K_M：质量更好，但显存压力更高

Qwen 系列对中文更友好，日常写作、资料整理和中文指令理解通常比较顺。如果你不知道第一款本地中文模型选什么，可以先从它开始。

推荐二：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct 是一个很稳的通用模型，英文能力和工具生态都比较成熟。

适合场景：

英文问答。
轻量代码辅助。
通用聊天。
文档摘要。
提示词测试。
对比不同推理工具。

建议选择：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度和显存更稳
Q5_K_M：回答质量更好

如果你主要处理英文资料，或者想要一个生态成熟、教程多、兼容性好的模型，Llama 3.1 8B 仍然是很好的基准选择。

推荐三：Gemma 3 12B

Gemma 3 12B 更接近 3060 12GB 的上限选择。

它比 8B 模型更吃显存，但在 Q4 量化下仍然有机会在 3060 12GB 上跑起来。适合想在单卡上尝试更大一点模型的人。

适合场景：

更高质量的通用问答。
英文内容处理。
较复杂的总结和分析。
对 8B 模型不满意时的升级尝试。

建议选择：

1
2
3

Gemma 3 12B GGUF
Q4_K_M 或官方 QAT Q4
上下文不要开太大

如果运行时爆显存，可以先降低上下文长度，或者换回 8B 模型。对 3060 来说，12B 是“能试”，不是“无脑推荐”。

推荐四：DeepSeek R1 Distill Qwen 8B

如果你想在本地体验推理风格模型，可以试 DeepSeek R1 Distill Qwen 8B 一类 8B 蒸馏模型。

适合场景：

简单推理题。
分步骤分析。
学习推理模型输出风格。
本地低成本实验。

建议选择：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

需要注意，这类模型有时会输出更长的推理过程，速度和上下文占用可能比普通指令模型更明显。日常聊天不一定比 Qwen3 8B 更舒服，但用来做推理实验很合适。

推荐五：Phi / MiniCPM / 小尺寸模型

如果你的 3060 不是 12GB 版本，而是 8GB 版本，或者电脑内存也比较小，可以优先考虑 3B、4B 级别模型。

适合场景：

快速问答。
简单摘要。
嵌入到本地小工具。
低延迟聊天。
老电脑测试。

这类模型质量不一定能和 8B、12B 相比，但胜在轻、快、部署简单。

量化怎么选

本地模型常见格式是 GGUF，常见量化包括 Q4、Q5、Q6、Q8。

简单选择：

量化	特点	适合谁
Q4_K_M	体积小，速度好，质量够用	3060 首选
Q5_K_M	质量更好，占用更高	8B 模型可以试
Q6 / Q8	更接近原始质量，占用更大	小模型或显存宽裕时
Q2 / Q3	很省显存，但质量下降明显	大模型折腾用

对 RTX 3060 12GB 来说，最实用的是：

1
2
3

8B 模型：Q4_K_M 或 Q5_K_M
12B 模型：优先 Q4_K_M
更大模型：不建议作为日常主力

用什么工具运行

新手可以从 Ollama 开始，优点是安装和运行简单。

常见命令形式：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

如果想更细地控制 GGUF 文件、GPU layers、上下文长度，可以用 llama.cpp 或基于 llama.cpp 的图形工具。

常见选择：

Ollama：最省心，适合新手。
LM Studio：图形界面友好，适合手动下载和切换模型。
llama.cpp：控制最细，适合折腾性能。
text-generation-webui：功能多，适合测试不同后端。

如果只是本地聊天和简单问答，Ollama 或 LM Studio 就够了。

上下文不要开太大

很多模型宣传支持很长上下文，但 RTX 3060 运行时不要盲目开到最大。

上下文越长，KV cache 占用越高，显存压力也越大。即使模型能加载，长上下文也可能导致速度下降。

建议：

1
2
3

普通聊天：4K 到 8K
文档摘要：8K 到 16K
长文档 RAG：优先切片，不要硬塞全文

3060 更适合“中等上下文 + 好模型 + 好检索”，不适合把几十万 token 一次性塞进去。

不同用途怎么选

如果你主要写中文：

1
2

优先：Qwen3 8B Q4_K_M
备选：DeepSeek R1 Distill Qwen 8B

如果你主要写英文：

1
2

优先：Llama 3.1 8B Instruct Q4_K_M
备选：Gemma 3 12B Q4_K_M

如果你想跑得快：

1
2
3

3B / 4B 模型
8B Q4_K_M
上下文控制在 4K 到 8K

如果你想质量更好：

1
2
3

8B Q5_K_M
12B Q4_K_M
接受速度变慢

如果你想写代码：

1
2

8B 代码模型可以辅助解释和小改动
复杂工程任务仍建议用云端强模型

本地 3060 模型适合做代码解释、函数补全、小脚本生成和离线辅助；大型项目重构、复杂 bug、跨文件 Agent 任务，不要期待它达到 Claude Sonnet 或 GPT-5 级别。

3060 本地 LLM 的合理预期

RTX 3060 12GB 的定位很清楚：它适合把本地 LLM 从“玩具”变成“日常可用工具”，但不是让你在家里复刻顶级云端模型。

它的优势是：

成本低。
显存比 8GB 卡宽裕。
8B 模型体验不错。
可以离线使用。
适合隐私敏感资料的本地处理。

它的限制是：

大模型很难流畅。
长上下文会吃显存。
推理速度不如高端卡。
本地小模型复杂推理能力有限。
多模态和 Agent 工作流会更吃资源。

所以最稳的路线是：用 8B 模型做日常本地助手，用 12B 模型做质量尝试，复杂任务交给云端模型。

小结

RTX 3060 12GB 最推荐的本地 LLM 选择是：

中文通用：Qwen3 8B Q4_K_M
英文通用：Llama 3.1 8B Instruct Q4_K_M
更高质量尝试：Gemma 3 12B Q4_K_M
推理实验：DeepSeek R1 Distill Qwen 8B Q4_K_M
低显存快速体验：3B / 4B 小模型

量化优先选 Q4_K_M，8B 模型可以尝试 Q5_K_M。工具优先从 Ollama 或 LM Studio 开始。

不要把 3060 当成大模型服务器。把它当成本地知识助手、隐私文档处理器、轻量代码助手和模型实验卡，会更符合它的实际能力。

参考链接

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

Hermes + Qwen3.6：本地 Agent 的一套低成本部署方案

Mon, 04 May 2026 06:40:30 +0800

用 llama.cpp 在 WSL2 中运行 Qwen3.6 GGUF 模型，再把 Hermes Agent 接到本地 OpenAI-compatible API。这样可以在自己的电脑上获得一个可长期在线的本地 AI 助手，不再按在线服务的 Token 额度计费。

这套方案适合想体验本地 AI Agent、又希望保留数据隐私和长期可控性的用户。它可以用于日常问答、写作、代码辅助、资料整理和简单自动化任务。需要注意的是，模型规模越大，对显存要求越高；原文示例使用的是 Qwen3.6-27B，显存 24GB 更稳。如果显存较小，应选择更小尺寸或更低量化的模型。

方案结构

整体链路很简单：

Windows 上安装 WSL2 和 Ubuntu 24.04。
在 WSL2 中安装 CUDA Toolkit、编译 llama.cpp。
下载 Qwen3.6 GGUF 模型。
用 llama-server 启动本地模型服务。
安装 Hermes Agent，并把它配置到 http://localhost:8080/v1。
可选：写启动脚本，让 WSL2 打开时自动启动模型服务。

Hermes 负责 Agent 能力，Qwen3.6 负责本地大模型能力。两者组合后，可以把电脑变成一个本地私有 AI 助理。

安装 WSL2 和 Ubuntu

在 Windows PowerShell 管理员窗口中执行：

1
2

wsl --install
wsl --set-default-version 2

重启后安装 Ubuntu 24.04：

`1`	`wsl --install -d Ubuntu-24.04`

安装完成后，Ubuntu 会提示设置用户名和密码。进入 Ubuntu 后，先检查 NVIDIA GPU 是否能在 WSL2 中正常识别：

`1`	`nvidia-smi`

如果无法识别 GPU，通常需要先更新 Windows 端的 NVIDIA 显卡驱动。WSL2 会继承 Windows 驱动，但 CUDA Toolkit 仍需要在 WSL2 内单独安装。

安装 Python 和基础工具

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

后续还需要编译工具、Git 和 CMake：

`1`	`sudo apt install -y cmake build-essential git`

编译 llama.cpp

先拉取源码：

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

如果 WSL2 中已经有可用 CUDA 环境，可以直接编译：

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 适合 Ada 架构显卡，例如 RTX 40 系列。其他显卡应按实际架构调整。

如果编译时报 CUDA Toolkit 缺失，先在 WSL2 中安装 CUDA Toolkit：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

安装完成后配置环境变量：

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

然后重新编译：

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

下载 Qwen3.6 GGUF 模型

原文示例使用 unsloth/Qwen3.6-27B-GGUF 中的 Qwen3.6-27B-UD-Q4_K_XL.gguf：

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

这个文件约 17GB。如果 Hugging Face 下载慢，可以换 ModelScope 等国内镜像。显存不足时不要硬上 27B，可以换更小模型或更低量化版本。

启动本地模型服务

根据自己的模型文件名启动 llama-server：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

启动成功后，在 Windows 浏览器访问：

`1`	`http://localhost:8080`

如果要让 Hermes Agent 或其他 OpenAI-compatible 客户端调用，API 地址通常是：

`1`	`http://localhost:8080/v1`

Thinking 模式取舍

Qwen3.6 默认可能启用 Thinking 模式。它适合复杂推理、复杂代码问题、多步骤分析，但速度会慢一些。

如果想关闭 Thinking 模式，可以停止服务后增加 --chat-template-kwargs 参数：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

关闭 Thinking 后，简单问答、写作、代码补全和解释代码会更快；但复杂算法设计、疑难 Debug 和架构分析仍建议开启 Thinking。

安装 Hermes Agent

保持 llama-server 运行，再新开一个 WSL2 终端安装 Hermes Agent：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

安装脚本会处理 Python、Node.js、ripgrep、ffmpeg 等依赖。配置模型端点时选择自定义 endpoint：

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自动识别

API Key 对本地 llama-server 来说可以随便填一个占位值。配置完成后，可以继续接 Telegram、微信、QQ、Discord 等聊天工具，让 Hermes Agent 通过这些入口调用本地模型并执行任务。

自动启动模型服务

可以写一个启动脚本，让 WSL2 终端打开时自动启动模型服务。

创建脚本：

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

写入 .bashrc：

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

这样每次打开 WSL2 终端时，如果 llama-server 没有运行，就会自动启动；如果已经在运行，就会跳过，避免重复启动。

注意事项

27B 模型对显存要求较高，24GB 显存体验更稳；显存较小时应换小模型。
--ctx-size 65536 会显著增加显存和内存压力，不稳定时先降到 32768 或更低。
WSL2 中 CUDA Toolkit 和 Windows 显卡驱动都要正常，缺一边都可能导致 CUDA 编译或运行失败。
Hermes Agent 接本地服务时，本质上是调用 OpenAI-compatible API，关键是 http://localhost:8080/v1 能正常响应。
如果要从手机或其他设备访问，需要额外处理 Windows 防火墙、局域网地址和安全隔离，不要把本地模型服务直接暴露到公网。

8G 显存跑 llama.cpp 怎么调：32K 更稳，64K 要开 KV Cache 量化

Thu, 23 Apr 2026 12:13:04 +0800

8G 显存到底还能不能把本地大模型跑顺，尤其是在长上下文场景下还能不能保住速度，这是很多人在折腾 llama.cpp 时都会遇到的问题。

核心结论可以先记住三条：

对 8G 显存来说，32K 上下文通常是更稳的平衡点
如果一定要跑 64K，KV Cache 量化基本是必选项
在全显卡运行场景里，盲目拉高 CPU 线程数，反而可能让速度明显下降

一、先解释清楚：32K、64K 和 KV Cache 是什么

很多人第一次看这类调优文章，最容易卡住的就是这三个词。

32K 和 64K 说的是上下文长度，也就是模型一次最多能处理多少 token。这里的 K 就是千，32K 大约是 32000 token，64K 大约是 64000 token。上下文越长，模型一次能看到的历史内容越多，适合长文档问答、长对话和多轮分析。

KV Cache 则是模型为了加速连续生成而保留的一份中间结果缓存。你可以把它理解成：模型已经读过、算过的一部分内容，不会每次都从头重算，而是把关键结果先存起来，后面继续接着用。这里的 K 和 V，来自 Transformer 里的 Key 和 Value。

为什么这三个词总是一起出现？因为：

32K、64K 决定你想让模型一次记住多长内容
KV Cache 决定为了维持这段记忆，要额外占多少显存
上下文越长，KV Cache 通常越大，显存压力也越高

所以很多长上下文变慢的问题，本质上并不是模型“不会算”，而是缓存太大，把显存挤到了临界点。

二、为什么 32K 和 64K 的速度会差这么多

这里用《三体》大约 3 万字的文本做压力测试，对比 32K 和 64K 两种上下文设置。结果很夸张：在文档长度接近的情况下，64K 模式的速度显著下降，总耗时也明显拉长。

问题不在模型突然变笨，而在显存边界被撞到了。

当 32K 模式下，模型权重加缓存还能基本塞进 8G 显存里，数据大多走显卡显存带宽，速度还能维持在比较可用的区间。但一旦切到 64K，缓存体积继续上涨，总占用逼近甚至超过显存上限，系统就会把部分数据挤到内存里。

这时候真正掉下去的，不是算力，而是带宽。

也就是说，很多人看到的是“上下文翻倍后速度暴跌”，本质上其实是数据路径从显存掉到了共享内存或系统内存，推理链路不再跑在高速通道上。

三、64K 还能不能跑，关键在 KV Cache 量化

第二个很关键的结论，是 KV Cache 量化对 8G 显存用户特别重要。

如果不改变模型本身，只针对缓存做量化，长上下文下最直接的收益就是把缓存占用压缩下来，让原本已经溢出的那部分重新回到显存里。这样一来，64K 模式虽然依然比 32K 更吃资源，但至少不会直接跌进最慢的区间。

换句话说：

32K 更像是 8G 显存的默认推荐区间
64K 不是完全不能跑
但如果不上缓存量化，性能很容易从“能用”直接掉到“很难用”

如果你的目标是尽量稳定地跑长上下文，那优先级通常应该是：

先确认显存是否已经逼近上限
再决定是否开启 KV Cache 量化
最后才去继续尝试更激进的吞吐量参数

四、GPU 占用不高，不代表显卡没干活

这是一个很容易打破直觉的点。

很多人看到任务管理器里 GPU 使用率只有二三十，就会怀疑：

是不是参数没设对
是不是模型没真正跑到显卡上
是不是显卡根本没吃满

但这组测试给出的判断是，llama.cpp 这类推理很多时候首先卡的不是核心算力，而是显存读写速度。

也就是说，显卡核心可能很快就把一批计算做完了，但后面还得等下一批权重和缓存数据搬过来。于是你看到的现象就会变成：

核心占用不算高
但整体速度还是上不去

这不是显卡在偷懒，而是数据通路太窄。

所以看本地大模型速度时，不能只盯着 GPU Usage。显存容量、显存带宽、缓存是否溢出，往往更影响最终体验。

五、调大吞吐量参数，确实可能再快一截

这里还做了一个思路很清晰的测试：既然显卡核心并没有完全忙满，那能不能通过调大吞吐量相关参数，让显卡一次处理更多数据，把并行能力进一步压出来。

测试结果表明，这种做法确实有机会把速度再往上拉一段。

但这里也有一个前提：显存还得扛得住。

因为吞吐量相关参数调大之后，往往会带来额外显存占用。如果你本来就在 64K、高缓存、显存见底的状态下继续往上推，就很容易出现两种情况：

直接崩溃
没崩，但被迫进入更慢的共享内存模式

所以更稳妥的顺序通常不是“先把参数拉满”，而是：

先守住显存边界
再考虑吞吐量优化
每调一步都重新看速度和稳定性

六、CPU 线程不是越多越好

这也是整篇内容里最值得记住的坑点之一。

很多人做本地推理调优时，容易下意识觉得线程越多越快，既然机器有那么多线程，不用满就像浪费。但实测给出的结果恰恰相反：在模型已经主要跑在显卡上的情况下，强行把 CPU 线程拉高，性能反而会明显变差。

原因不复杂。

在全显卡运行时，CPU 更像是调度者和预处理协作者，而不是主力计算单元。这时候如果开太多线程，CPU 端的线程竞争、调度切换和上下文切换开销都会变重，最终把本来应该更流畅的数据流打乱。

结果就是：

CPU 更忙了
但整体速度变慢了

所以在这种场景下，默认设置或者较低线程数，往往比一味拉满更靠谱。

七、对 8G 显存用户更实用的一套思路

如果把上面的结论压成一套更容易执行的思路，大概可以整理成这样：

1. 先把 32K 当成默认目标

如果你用的是 8G 显存显卡，先别急着追 64K。32K 往往是速度、稳定性和显存占用之间更现实的平衡点。

2. 想上 64K，先处理缓存问题

不要先想“还能不能再榨一点速度”，而是先确认 KV Cache 有没有量化、显存是不是已经压线。

3. 不要用 GPU 占用率判断一切

低占用不一定代表设置错了，也可能只是显存带宽在拖后腿。

4. 吞吐量优化可以做，但别越过显存边界

这类参数确实能带来收益，但前提是显存还有余量。

5. CPU 线程先保守，再逐步测试

如果模型已经基本跑在显卡上，CPU 线程并不是越高越好。先用默认值或低线程值测试，再看是否值得继续调整。

结语

这组内容最有价值的地方，不只是给出几个测试数字，而是把一个经常被忽略的事实讲清楚了：

本地大模型调优，很多时候拼的不是“有没有把所有参数开到最大”，而是你有没有搞清楚瓶颈到底在算力、显存容量、显存带宽，还是在 CPU 调度。

对 8G 显存用户来说，真正更稳的思路通常不是硬冲最长上下文，而是先守住显存边界，再决定要不要继续往上加。

如果只记一句话，那就是：

32K 往往是 8G 显存更稳的工作区间；64K 不是不能跑，但前提是你已经把 KV Cache 和显存占用管住了。

llama.cpp ollama 显卡性能天梯：CUDA、ROCm、Vulkan

Thu, 23 Apr 2026 09:58:11 +0800

先看懂这些参数

`Q4_0` 是什么

Q4_0 是一种 4-bit 量化格式。它的意义不是“模型更强”，而是“模型更小、更省显存、更容易塞进更多设备里”。这些榜单大多统一用 Llama 2 7B, Q4_0，核心目的是减少变量，让不同 GPU 的成绩更容易横向比较。

`pp512` 是什么

pp512 一般可以理解为 prompt processing 512 tokens，也就是处理 512 个输入 token 时的吞吐。

pp = prompt processing
512 = 输入长度是 512 token
t/s = tokens per second

它更像“吃提示词的速度”，通常能并行得更充分，所以数字往往很高。

`tg128` 是什么

tg128 一般可以理解为 text generation 128 tokens，也就是连续生成 128 个 token 时的速度。

tg = text generation
128 = 连续生成 128 token
t/s = tokens per second

它更接近我们平时感受到的“模型回答快不快”。因为生成阶段是逐 token 递推，所以通常明显低于 pp512。

`FA` 是什么

FA 是 Flash Attention。简单理解就是注意力计算的一种优化开关。

with FA 表示启用了 Flash Attention
no FA 表示关闭 Flash Attention

在不少卡上，FA 对 pp512 的提升比对 tg128 更明显；但不同后端、不同驱动和不同架构之间，提升幅度并不一致，个别设备甚至会出现 PP 升、TG 变化很小，或者 PP 反而下降的情况。

`t/s` 怎么看

t/s 就是 tokens per second。它不是帧率，也不是 FLOPS，而是模型吞吐表现的直接结果。

读榜单时最重要的一点是：先确认你在比的是不是同一种测试。

不要把 pp512 和 tg128 直接混着比
不要把 no FA 和 with FA 混着比
不要把 CUDA、ROCm、Vulkan 的结果当成完全等价的同一条曲线

先说结论

从这几条讨论串当前可见的数据看，大致可以先记住这几个结论：

CUDA 仍然是目前 llama.cpp GPU 跑分里最强、样本也最密集的一条线，特别是高端 Nvidia 卡在 pp512 上优势很大。
ROCm 在高端 AMD 卡和 Instinct 卡上已经能给出非常像样的成绩，MI300X、7900 XTX、W7900 这些条目都不弱。
Vulkan 的优点不是“绝对最快”，而是覆盖面最广，Nvidia、AMD、Intel、Apple Asahi / MoltenVK，甚至很多老卡和核显都能找到条目。
tg128 往往更接近日常体感，pp512 更适合看吞吐能力。很多“榜一”卡，在两项里领先幅度并不完全一样。

CUDA 完整榜单

Llama 2 7B, Q4_0, no FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
RTX 5090	32 GB / GDDR7 / 512 bit	14073.41 ± 115.16	290.02 ± 1.10	8cf6b42	@totaldev
RTX PRO 6000 Blackwell	96 GB / GDDR7 / 512 bit	14854.63 ± 22.73	274.20 ± 0.14	79c1160	@Tom94
H100 80 GB	80 GB / HBM3 / 5120 bit	9918.34 ± 176.97	267.81 ± 1.54	5143fa8	@Hedede
A100 80 GB	80 GB / HBM2e / 5120 bit	4849.53 ± 8.94	190.88 ± 0.33	5143fa8	@Hedede
RTX 4090 D	24 GB / GDDR6X / 384 bit	10293.86 ± 134.72	189.33 ± 0.19	79c1160	@autonomous-AI-lab
RTX 4090	24 GB / GDDR6X / 384 bit	11992.70 ± 107.99	186.21 ± 0.13	2241453	@lhl
RTX 5080	16 GB / GDDR7 / 256 bit	8297.36 ± 9.50	181.99 ± 0.42	8a4280c	@Hedede
RTX 5070 Ti	16 GB / GDDR7 / 256 bit	6952.38 ± 13.73	176.85 ± 0.07	933414c	@TinyServal
RTX 6000 Ada	48 GB / GDDR6 / 384 bit	9229.23 ± 101.78	176.07 ± 0.26	b8e09f0	@Hedede
RTX 3090 Ti	24 GB / GDDR6X / 384 bit	6567.49 ± 20.30	171.19 ± 3.98	9c35706	@slaren
RTX 3090	24 GB / GDDR6X / 384 bit	5174.69 ± 21.83	158.16 ± 0.21	c76b420	@m18coppola
L40	48 GB / GDDR6 / 384 bit	8870.49 ± 378.76	152.01 ± 0.28	ee09828	@Hedede
RTX 4080 SUPER	16 GB / GDDR6X / 256 bit	8125.15 ± 41.05	148.33 ± 0.20	81086cd	@zacharyarnaise
RTX 4080	16 GB / GDDR6X / 256 bit	8031.64 ± 26.49	142.49 ± 0.16	20638e4	@Ristovski
RTX 3080	10 GB / GDDR6X / 320 bit	5013.86 ± 24.80	139.65 ± 0.99	9c35706	@slaren
RTX A6000	48 GB / GDDR6 / 384 bit	4913.93 ± 6.79	138.73 ± 2.75	4795c91	@Hedede
RTX 4070 Ti SUPER	16 GB / GDDR6X / 256 bit	6924.53 ± 13.87	132.26 ± 0.16	9c35706	@Ristovski
RTX PRO 4000 Blackwell	24 GB / GDDR7 / 192 bit	4992.83 ± 113.52	131.66 ± 0.20	7d77f07	@Hedede
RTX A5000	24 GB / GDDR6 / 384 bit	4028.16 ± 19.14	130.07 ± 2.74	e5155e6	@Hedede
Tesla V100	32 GB / HBM2 / 4096 bit	3042.64 ± 40.71	129.08 ± 0.05	51f5a45	@Hedede
RTX 5070	12 GB / GDDR7 / 192 bit	5184.75 ± 18.70	127.54 ± 0.46	@Spyro000	-
A40	48 GB / GDDR6 / 384 bit	4609.01 ± 10.67	124.11 ± 0.17	3470a5c	@Hedede
A30	24 GB / HBM2e / 3072 bit	2767.10 ± 1.88	124.81 ± 0.16	583cb83	@Hedede
Titan V	12 GB / HBM2 / 3072 bit	2617.46 ± 2.10	108.79 ± 0.05	e56abd2	@Hedede
RTX 2080 Ti	11 GB / GDDR6 / 352 bit	2890.66 ± 2.42	107.51 ± 0.21	9c35706	@ariya
Quadro RTX 6000	24 GB / GDDR6 / 384 bit	2751.18 ± 19.43	102.77 ± 0.04	b8e09f0	@Hedede
Quadro RTX 8000	48 GB / GDDR6 / 384 bit	2709.95 ± 3.35	102.68 ± 0.03	b8e09f0	@Hedede
RTX A4500	20 GB / GDDR6 / 320 bit	2827.20 ± 66.43	97.32 ± 2.80	5cdb27e	@aleksyx
RTX 5060 Ti 16 GB	16 GB / GDDR7 / 128 bit	3737.25 ± 6.79	90.94 ± 0.02	89d1029	@mike-llamacpp
RTX 2070 SUPER	8 GB / GDDR6 / 256 bit	2088.34 ± 1.94	88.06 ± 0.28	bc07349	@phstudy
RTX A4000	16 GB / GDDR6 / 256 bit	2684.06 ± 15.28	83.77 ± 0.37	65349f2	@TinyServal
Titan Xp	12 GB / GDDR5X / 384 bit	1154.96 ± 1.46	76.08 ± 0.08	c4510dc	@Hedede
RTX 3060	12 GB / GDDR6 / 192 bit	2137.50 ± 10.12	75.57 ± 0.07	baa9255	@QuantiusBenignus
Quadro RTX 4000	8 GB / GDDR6 / 256 bit	1536.89 ± 0.90	65.62 ± 0.62	7d77f07	@Hedede
RTX 4060 Ti 8 GB	8 GB / GDDR6 / 128 bit	3394.63 ± 7.44	63.86 ± 0.01	89d1029	@mike-llamacpp
GTX 1080 Ti	11 GB / GDDR5X / 352 bit	1084.41 ± 3.01	62.49 ± 0.06	9c35706	@ariya
RTX A4000 Ada	20 GB / GDDR6 / 160 bit	2779.77 ± 9.91	61.83 ± 0.04	a74a0d6	@sdwolfz
RTX 2060 SUPER	8 GB / GDDR6 / 256 bit	1420.24 ± 1.95	60.04 ± 0.01	5c0eb5e	@ggerganov
Tesla P100	16 GB / HBM2 / 4096 bit	760.80 ± 2.92	58.35 ± 0.00	b8372ee	@Hedede
DGX Spark	128 GB / LPDDR5x	3062.31 ± 11.02	57.21 ± 0.06	5acd455	@ggerganov
Tesla P40	24 GB / GDDR5 / 384 bit	1007.42 ± 1.23	54.74 ± 0.07	c76b420	@m18coppola
RTX 2000 Ada	16 GB / GDDR6 / 128 bit	1956.22 ± 7.74	50.62 ± 0.04	756cfea	@DigitalRudeness
Tesla T4	16 GB / GDDR6 / 256 bit	1219.06 ± 4.18	46.38 ± 0.73	d32e03f	@pt13762104
RTX 4050 Laptop	6 GB / GDDR6 / 96 bit	1725.85 + 17.85	43.72 + 0.41	d79d8f3	@TimCabbage
GTX 1660	6 GB / GDDR5 / 192 bit	148.91 ± 0.01	41.35 ± 0.02	9515c61	@ariya
Tesla M40	24 GB / GDDR5 / 384 bit	282.65 ± 0.15	38.04 ± 0.02	97d5117	@Hedede
GTX 1070 Ti	8 GB / GDDR5 / 256 bit	714.44 ± 2.04	37.82 ± 0.02	79c1160	@pebaryan
Jetson AGX Orin	64 GB / LPDDR5 / 256 bit	991.31 ± 1.15	33.58 ± 0.14	c1b1876	@TinyServal
Tesla P4	8 GB / GDDR5 / 256 bit	514.53 ± 3.06	33.29 ± 0.00	c76b420	@m18coppola
P106-100	6 GB / GDDR5 / 192 bit	406.94 ± 0.25	30.40 ± 0.02	5fd160b	@pebaryan
GTX 1060	6 GB / GDDR5 / 192 bit	416.85 ± 1.75	27.79 ± 0.02	5fd160b	@pebaryan
Quadro T1000	4 GB / GDDR5 / 128 bit	79.44 ± 0.01	27.82 ± 0.18	f6da8cb	@hanabu
Quadro P2000	5 GB / GDDR5 / 160 bit	309.30 ± 0.05	23.63 ± 0.00	baa9255	@TinyServal
Quadro P1000	4 GB / GDDR5 / 128 bit	183.40 ± 0.11	13.99 ± 0.13	1e74897	@aleksyx
Tesla K80	12 GB / GDDR5 / 384 bit	133.14 ± 0.55	13.80 ± 0.02	32732f2	@pebaryan

Llama 2 7B, Q4_0, with FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
RTX 5090	32 GB / GDDR7 / 512 bit	14970.15 ± 381.06	300.40 ± 0.28	8cf6b42	@totaldev
RTX PRO 6000 Blackwell	96 GB / GDDR7 / 512 bit	16618.98 ± 20.66	281.11 ± 0.41	5143fa8	@Tom94
H100 80 GB	80 GB / HBM3 / 5120 bit	11263.29 ± 98.34	280.74 ± 1.17	5143fa8	@Hedede
A100 80 GB	80 GB / HBM2e / 5120 bit	5285.96 ± 6.58	200.90 ± 0.12	5143fa8	@Hedede
RTX 4090 D	24 GB / GDDR6X / 384 bit	12506.97 ± 11.51	191.57 ± 0.03	79c1160	@autonomous-AI-lab
RTX 4090	24 GB / GDDR6X / 384 bit	14770.63 ± 102.93	188.96 ± 0.05	2241453	@lhl
RTX 5080	16 GB / GDDR7 / 256 bit	9487.70 ± 21.89	184.68 ± 0.05	8a4280c	@Hedede
RTX 5070 Ti	16 GB / GDDR7 / 256 bit	8419.56 ± 35.50	182.43 ± 0.09	933414c	@TinyServal
RTX 6000 Ada	48 GB / GDDR6 / 384 bit	10576.85 ± 530.21	179.47 ± 0.32	b8e09f0	@Hedede
RTX 3090 Ti	24 GB / GDDR6X / 384 bit	6924.01 ± 10.76	172.26 ± 1.31	9c35706	@slaren
RTX PRO 4500 Blackwell	32 GB / GDDR7 / 256 bit	7251.66 ± 92.40	168.90 ± 0.20	becc481	@Hedede
RTX 3090	24 GB / GDDR6X / 384 bit	5560.06 ± 16.28	161.89 ± 0.18	c76b420	@m18coppola
L40	48 GB / GDDR6 / 384 bit	10097.64 ± 671.22	153.76 ± 0.12	ee09828	@Hedede
RTX 4080 SUPER	16 GB / GDDR6X / 256 bit	9439.01 ± 56.75	147.48 ± 1.41	81086cd	@zacharyarnaise
RTX 4080	16 GB / GDDR6X / 256 bit	9205.93 ± 22.31	143.47 ± 0.02	20638e4	@Ristovski
RTX A6000	48 GB / GDDR6 / 384 bit	5662.39 ± 13.87	144.87 ± 0.18	4795c91	@Hedede
RTX 3080	10 GB / GDDR6X / 320 bit	5569.56 ± 14.04	139.95 ± 0.95	9c35706	@slaren
RTX PRO 4000 Blackwell	24 GB / GDDR7 / 192 bit	5674.44 ± 139.53	136.38 ± 0.13	7d77f07	@Hedede
RTX A5000	24 GB / GDDR6 / 384 bit	4552.15 ± 9.68	135.83 ± 0.11	e5155e6	@Hedede
Tesla V100	32 GB / HBM2 / 4096 bit	2973.78 ± 3.62	134.76 ± 0.02	51f5a45	@Hedede
RTX 4070 Ti SUPER	16 GB / GDDR6X / 256 bit	7612.32 ± 37.35	132.85 ± 0.31	9c35706	@Ristovski
A30	24 GB / HBM2e / 3072 bit	3068.72 ± 0.63	131.93 ± 0.18	583cb83	@Hedede
RTX 5070	12 GB / GDDR7 / 192 bit	5783.44 ± 36.95	128.21 ± 2.52	@Spyro000	-
A40	48 GB / GDDR6 / 384 bit	5256.38 ± 19.39	126.24 ± 0.06	3470a5c	@Hedede
Titan V	12 GB / HBM2 / 3072 bit	2481.25 ± 1.31	112.17 ± 0.01	e56abd2	@Hedede
RTX 2080 Ti	11 GB / GDDR6 / 352 bit	3107.61 ± 4.34	109.17 ± 0.07	9c35706	@ariya
Quadro RTX 6000	24 GB / GDDR6 / 384 bit	3053.96 ± 1.37	104.38 ± 0.04	b8e09f0	@Hedede
Quadro RTX 8000	48 GB / GDDR6 / 384 bit	3052.35 ± 5.64	103.63 ± 0.02	b8e09f0	@Hedede
RTX A4500	20 GB / GDDR6 / 320 bit	3453.10 ± 49.19	103.00 ± 0.25	5cdb27e	@aleksyx
RTX 5060 Ti 16 GB	16 GB / GDDR7 / 128 bit	4195.53 ± 1.98	93.46 ± 0.01	89d1029	@mike-llamacpp
RTX 2070 SUPER	8 GB / GDDR6 / 256 bit	2293.29 ± 5.91	87.71 ± 0.29	bc07349	@phstudy
RTX A4000	16 GB / GDDR6 / 256 bit	2807.83 ± 52.44	85.17 ± 0.66	65349f2	@TinyServal
RTX 3060	12 GB / GDDR6 / 192 bit	2407.67 ± 3.73	76.92 ± 0.03	baa9255	@QuantiusBenignus
Titan Xp	12 GB / GDDR5X / 384 bit	1218.12 ± 1.82	73.84 ± 0.04	c4510dc	@Hedede
Quadro RTX 4000	8 GB / GDDR6 / 256 bit	1662.80 ± 2.04	67.62 ± 0.67	7d77f07	@Hedede
RTX 4060 Ti 8 GB	8 GB / GDDR6 / 128 bit	3803.45 ± 70.80	64.03 ± 0.53	89d1029	@mike-llamacpp
Tesla P100	16 GB / HBM2 / 4096 bit	787.36 ± 3.27	61.99 ± 0.00	b8372ee	@Hedede
GTX 1080 Ti	11 GB / GDDR5X / 352 bit	1138.14 ± 2.02	61.38 ± 0.03	9c35706	@ariya
RTX A4000 Ada	20 GB / GDDR6 / 160 bit	3171.86 ± 4.34	61.37 ± 0.01	a74a0d6	@sdwolfz
RTX 2060 SUPER	8 GB / GDDR6 / 256 bit	1563.77 ± 0.51	61.13 ± 0.05	5c0eb5e	@ggerganov
DGX Spark	128 GB / LPDDR5x	3661.37 ± 38.66	56.74 ± 0.03	5acd455	@ggerganov
Tesla P40	24 GB / GDDR5 / 384 bit	1079.66 ± 0.18	53.73 ± 0.05	c76b420	@m18coppola
RTX 2000 Ada	16 GB / GDDR6 / 128 bit	2250.14 ± 5.91	50.71 ± 0.01	756cfea	@DigitalRudeness
Tesla T4	16 GB / GDDR6 / 256 bit	1309.73 ± 1.02	44.03 ± 0.57	d32e03f	@pt13762104
GTX 1660	6 GB / GDDR5 / 192 bit	154.45 ± 0.52	41.43 ± 0.01	9515c61	@ariya
Tesla M40	24 GB / GDDR5 / 384 bit	290.17 ± 0.11	39.98 ± 0.01	97d5117	@Hedede
GTX 1070 Ti	8 GB / GDDR5 / 256 bit	790.52 ± 2.39	37.87 ± 0.00	79c1160	@pebaryan
Jetson AGX Orin	64 GB / LPDDR5 / 256 bit	1171.96 ± 4.70	35.88 ± 0.18	c1b1876	@TinyServal
Tesla P4	8 GB / GDDR5 / 256 bit	529.53 ± 2.12	33.12 ± 0.03	c76b420	@m18coppola
P106-100	6 GB / GDDR5 / 192 bit	438.49 ± 0.38	30.64 ± 0.06	5fd160b	@pebaryan
GTX 1060	6 GB / GDDR5 / 192 bit	446.19 ± 0.81	28.18 ± 0.01	5fd160b	@pebaryan
Quadro T1000	4 GB / GDDR5 / 128 bit	27.46 ± 0.23	27.46 ± 0.23	f6da8cb	@hanabu
Quadro P2000	5 GB / GDDR5 / 160 bit	311.55 ± 0.19	23.76 ± 0.01	baa9255	@TinyServal
Tesla K80	12 GB / GDDR5 / 384 bit	133.36 ± 0.60	14.27 ± 0.32	32732f2	@pebaryan
Quadro P1000	4 GB / GDDR5 / 128 bit	173.82 ± 0.02	13.65 ± 0.14	1e74897	@aleksyx

Apple Silicon 参考口径

#4167 这条讨论和后三条最大的区别，是它更早建立了统一口径，除了 Q4_0，还会顺带放 F16 和 Q8_0。它对理解 PP / TG / t/s 很有帮助。

讨论里直接给出的说明是：

PP 表示 prompt processing
TG 表示 text-generation
t/s 表示 tokens per second

文中可见的一个时间对比样例，是 M2 Ultra 在同一台机器上随着版本和 FA 演进后的成绩：

时间	设备	版本/说明	带宽 GB/s	GPU 核心	F16 PP	F16 TG	Q8_0 PP	Q8_0 TG	Q4_0 PP	Q4_0 TG
2023-11-21	M2 Ultra	8e672ef	800	76	1401.85	41.02	1248.59	66.64	1238.48	94.27
2024-11-12	M2 Ultra	86ed72d + FA	800	76	1525.95	43.15	1368.18	73.11	1391.78	108.80
2025-08-02	M2 Ultra	5c0eb5e + FA	800	76	1561.35	43.24	1386.97	73.35	1412.42	109.41

讨论正文前部还给了几台 Apple Silicon 设备的统一样例：

设备	Q4_0 PP	Q4_0 TG	Q8_0 PP	Q8_0 TG	F16 PP	F16 TG
M1 Pro 16 GPU	266.25	36.41	270.37	22.34	302.14	12.75
M2 Ultra 76 GPU	1238.48	94.27	1248.59	66.64	1401.85	41.02
M3 Max 40 GPU	690.99	65.85	749.37	43.00	794.26	25.27

Apple 这条线这里不展开全文搬运，后面重点看你指定的三类独显后端榜单。

ROCm / HIP 完整榜单

Llama 2 7B, Q4_0, no FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
Instinct MI300X	192 GB / HBM3 / 8192 bit	11476.40 ± 72.79	232.92 ± 0.53	ee3a9fc	@yeahdongcn
RX 7900 XTX	24 GB / GDDR6 / 384 bit	3552.27 ± 101.96	167.11 ± 0.50	2f0c2db	@Diablo-D3
Instinct MI210	64 GB / HBM2e / 4096 bit	2486.22 ± 9.58	124.51 ± 0.04	8160b38	@65a
Pro W7900	48 GB / GDDR6 / 384 bit	3213.17 ± 80.47	121.18 ± 0.06	8160b38	@65a
RX 7900 XT	20 GB / GDDR6 / 320 bit	3098.38 ± 24.02	116.15 ± 0.06	1e15bfd	@AdamNiederer
RX 9070	16 GB / GDDR6 / 256 bit	2381.77 ± 3.68	114.48 ± 0.60	d0660f2	@andj1210
Instinct MI100	32 GB / HBM2 / 4096 bit	2732.83 ± 1.98	110.48 ± 0.14	9c35706	@firefox42
RX 9070 XT	16 GB / GDDR6 / 256 bit	5055.19 ± 109.58	101.27 ± 0.27	583cb83	@Hadrianneue
RX 7800 XT	16 GB / GDDR6 / 256 bit	2151.81 + 17.94	100.94 + 0.10	00131d6	@olegshulyakov
Instinct MI50	32 GB / HBM2 / 4096 bit	1057.24 ± 0.53	98.95 ± 0.25	97d5117	@wtarreau
RX 7900 GRE	16 GB / GDDR6 / 256 bit	1456.98 ± 12.39	96.07 ± 0.10	6fa3b55	@MihaiBojescu
AI PRO R9700	32 GB / GDDR6 / 256 bit	4443.54 ± 339.25	93.84 ± 0.26	bd4ef13	@gogich77
Instinct MI60	32 GB / HBM2 / 4096 bit	1289.11 ± 0.62	91.46 ± 0.13	504af20	@Said-Akbar
RX 6900 XT	16 GB / GDDR6 / 256 bit	1889.84 ± 31.21	88.49 ± 0.00	a972fae	@notgood
Pro VII	16 GB / HBM2 / 4096 bit	1064.99 ± 1.18	87.45 ± 0.04	2739a71	@8XXD8
RX 6800 XT	16 GB / GDDR6 / 256 bit	1447.07 ± 1.36	83.92 ± 0.03	79c1160	@MrLavender
Pro V620	32 GB / GDDR6 / 256 bit	1803.65 ± 2.54	74.66 ± 0.01	5c0eb5e	@samteezy
RX 9060 XT	16 GB / GDDR6 / 256 bit	1419.67 ± 3.64	67.58 ± 0.24	a0e13dc	@lcy0321
RX 5700 XT	8 GB / GDDR6 / 256 bit	354.17 ± 0.18	67.55 ± 0.04	c05e8c9	@daniandtheweb
Instinct MI25	16 GB / HBM2 / 2048 bit	409.83 ± 0.23	63.94 ± 0.06	2739a71	@8XXD8
AI Max+ 395	128 GB / LPDDR5	911.36 ± 1.79	50.01 ± 0.07	e60f241	@firefox42
RX 7600 XT	16 GB / GDDR6 / 128 bit	1099.64 ± 2.05	48.58 ± 0.06	9c35706	@wbruna
RX Vega 64	8 GB / HBM2 / 2048 bit	240.68 ± 0.09	48.46 ± 0.09	ec428b0	@davispuh
Radeon 8060S	System Shared / DDR5	351.36 ± 0.67	47.97 ± 0.33	1d0125b	@hspak
Radeon 880M	System Shared / DDR5	163.25 ± 13.86	12.97 ± 1.63	c55d53a	@Hedede

Llama 2 7B, Q4_0, with FA

Chip	Memory	pp512 t/s	tg128 t/s	Commit	Thanks to
Instinct MI300X	192 GB / HBM3 / 8192 bit	11945.97 ± 54.29	218.53 ± 0.09	ee3a9fc	@yeahdongcn
RX 7900 XTX	24 GB / GDDR6 / 384 bit	3874.25 ± 11.92	170.12 ± 0.56	2f0c2db	@Diablo-D3
Pro W7900	48 GB / GDDR6 / 384 bit	3472.86 ± 52.86	127.43 ± 0.12	8160b38	@65a
Instinct MI210	64 GB / HBM2e / 4096 bit	2571.82 ± 2.89	130.18 ± 0.06	8160b38	@65a
RX 9070	16 GB / GDDR6 / 256 bit	2452.68 ± 1.33	115.32 ± 0.52	d0660f2	@andj1210
RX 7900 XT	20 GB / GDDR6 / 320 bit	3261.75 ± 9.09	112.30 ± 0.06	1e15bfd	@AdamNiederer
Instinct MI50	32 GB / HBM2 / 4096 bit	1129.43 ± 0.15	105.82 ± 0.07	97d5117	@wtarreau
Instinct MI100	32 GB / HBM2 / 4096 bit	2755.00 ± 3.68	104.71 ± 0.10	9c35706	@firefox42
AI PRO R9700	32 GB / GDDR6 / 256 bit	4773.07 ± 49.30	97.98 ± 0.13	bd4ef13	@gogich77
RX 7900 GRE	16 GB / GDDR6 / 256 bit	1598.79 ± 11.48	97.53 ± 0.06	6fa3b55	@MihaiBojescu
RX 9070 XT	16 GB / GDDR6 / 256 bit	4903.51 ± 96.36	97.28 ± 0.13	583cb83	@Hadrianneue
RX 7800 XT	16 GB / GDDR6 / 256 bit	2304.63 + 2.85	95.99 + 0.21	00131d6	@olegshulyakov
RX 6900 XT	16 GB / GDDR6 / 256 bit	1948.31 ± 13.51	85.04 ± 0.02	a972fae	@notgood
Pro V620	32 GB / GDDR6 / 256 bit	1256.86 ± 0.55	70.83 ± 0.02	5c0eb5e	@samteezy
RX 9060 XT	16 GB / GDDR6 / 256 bit	1479.27 ± 0.71	65.42 ± 0.19	a0e13dc	@lcy0321
RX 5700 XT	8 GB / GDDR6 / 256 bit	314.17 ± 0.29	62.02 ± 0.05	c05e8c9	@daniandtheweb
AI Max+ 395	128 GB / LPDDR5	1003.53 ± 2.91	49.87 ± 0.02	e60f241	@firefox42
Radeon 8060S	System Shared / DDR5	366.08 ± 1.44	48.97 ± 0.15	1d0125b	@hspak
RX 7600 XT	16 GB / GDDR6 / 128 bit	1199.16 ± 1.07	47.65 ± 0.06	9c35706	@wbruna
RX Vega 64	8 GB / HBM2 / 2048 bit	153.17 ± 0.72	42.46 ± 0.40	ec428b0	@davispuh
Radeon 880M	System Shared / DDR5	213.31 ± 14.05	16.16 ± 1.41	c55d53a	@Hedede

Vulkan 完整榜单

Llama 2 7B, Q4_0, no FA

Chip	pp512 t/s	tg128 t/s	Commit	Comments
Nvidia RTX 5090	10381.64 ± 508.84	263.63 ± 0.91	ca71fb9	coopmat2
AMD Radeon RX 7900 XTX	3531.93 ± 31.74	191.28 ± 0.20	2f0c2db
Nvidia RTX 4090	9452.03 ± 187.70	187.97 ± 0.21	4ae88d0	coopmat2
Nvidia RTX 5080	7444.99 ± 20.11	185.10 ± 0.54	f6b533d	coopmat2
Nvidia A100	6389.86 ± 4.83	160.78 ± 0.16	2257758	coopmat2
Nvidia RTX 3090	4298.97 ± 10.59	160.13 ± 0.25	4ae88d0	coopmat2
Nvidia RTX 4080 Super	7101.18 ± 269.79	147.13 ± 5.64	81086cd	coopmat2
Nvidia RTX 3080	4287.11 ± 55.50	139.15 ± 0.05	7c7d6ce	coopmat2
Nvidia RTX A5000	3641.55 ± 9.05	139.89 ± 0.69	4ae88d0	coopmat2
AMD Radeon RX 9070 XT	5036.04 ± 88.16	137.11 ± 0.02	e9fd8dc
Nvidia RTX 5070 Ti	6213.63 ± 27.72	135.63 ± 0.18	d13d0f6	coopmat2
AMD Radeon AI Pro R9700	4036.04 ± 34.58	130.19 ± 0.39	3191462
Nvidia Tesla V100	1391.39 ± 1.19	129.58 ± 0.58	7d77f07
Nvidia RTX 4070 Ti Super	6099.18 ± 154.30	129.45 ± 0.18	4ae88d0	coopmat2
AMD Radeon RX 7900 XT	2941.58 ± 17.17	123.18 ± 0.40	71e74a3
AMD Radeon RX 9070	3164.10 ± 66.84	119.71 ± 3.40	21c17b5
AMD Radeon RX 7800 XT	2017.33 ± 19.30	118.27 ± 0.27	4fdbc1e
AMD Radeon RX 7900 GRE	2336.31 ± 7.52	116.11 ± 0.26	4b2a477
Apple M3 Ultra	1116.83 ± 0.55	115.54 ± 0.78	2d451c8	MoltenVK
Intel Arc Pro B70	3379.00 ± 47.92	112.02 ± 1.08	b863507
Nvidia Titan V	984.36 ± 4.13	108.86 ± 0.28	e56abd2
AMD Radeon Pro VII	1078.54 ± 0.86	107.82 ± 0.14	N/A
AMD Radeon RX 6900 XT	1837.21 ± 25.44	104.60 ± 0.30	a972fae
Intel Arc Pro A60	2261.11 ± 9.53	104.25 ± 0.07	97d5117
AMD Radeon RX 6800 XT	1752.92 ± 1.71	100.32 ± 0.97	N/A
AMD Radeon VII	1059.14 ± 0.56	101.19 ± 0.53	77d6ae4
Nvidia RTX 2080 Ti	1888.24 ± 9.20	97.58 ± 6.60	N/A
AMD Radeon RX 6800	1698.69 ± 0.80	95.61 ± 0.19	4b385bf
AMD Radeon Pro W6800X Duo	687.71 ± 4.33	94.82 ± 0.12	N/A
Nvidia RTX 5060 Ti	3460.92 ± 7.16	93.51 ± 0.15	89f10ba	coopmat2
Nvidia RTX 4070	3179.37 ± 46.16	92.29 ± 0.28	9a48399
AMD Radeon Pro W6800X	510.80 ± 0.13	86.47 ± 0.46	13b4548	MoltenVK
AMD Radeon RX 6700 XT	1051.20 ± 0.98	83.88 ± 0.08	6d75883
AMD Radeon RX 6750 XT	1040.58 ± 0.35	81.98 ± 0.03	228f34c
AMD Radeon Pro V620	1595.32 ± 1.59	81.78 ± 0.06	03d4698
Nvidia RTX 3070	2113.02 ± 7.38	78.71 ± 0.13	1b8fb81
AMD Radeon Instinct MI60	369.26 ± 2.48	78.16 ± 1.40	504af20
Nvidia RTX 3060	1815.70 ± 5.85	75.94 ± 0.80	92c0b38	coopmat2
Apple M4 Max	724.77 ± 20.93	75.02 ± 0.14	1ece0cb6
Nvidia Tesla T10	1692.70 ± 2.05	75.01 ± 0.21	7f76692	coopmat2
Nvidia RTX A4000	2248.14 ± 7.59	73.74 ± 0.08	f5245b5	coopmat2
AMD Radeon RX 5700 XT	529.69 ± 0.26	70.73 ± 0.04	4fdbc1e
AMD Radeon RX 9060 XT	2141.67 ± 6.87	70.54 ± 0.74	ed52f36
Intel Arc B580	620.94 ± 15.33	70.14 ± 0.28	7f76692
AMD Radeon Pro V540	583.88 ± 6.56	69.64 ± 0.24	9da3dcd
AMD Radeon Pro W5700	449.85 ± 0.46	68.55 ± 0.15	23bc779
Intel Arc Pro B60	522.36 ± 3.60	68.55 ± 0.01	516a4ca
Nvidia GTX 1080 Ti	540.69 ± 0.71	64.99 ± 0.08	360d653
Nvidia RTX 2070 Super	1199.13 ± 7.70	64.64 ± 0.20	b7552cf
Nvidia RTX 3070 Mobile	1689.40 ± 19.57	63.64 ± 0.39	ceff6bb	coopmat2
Nvidia Tesla P100	678.14 ± 1.40	63.16 ± 0.06	eec1e33
AMD BC-250	370.66 ± 0.04	62.32 ± 0.32	5886f4f
AMD Radeon RX 6650 XT	1029.52 ± 1.21	62.14 ± 0.02	dbb852b
Nvidia RTX 4060 Mobile	2135.66 ± 23.18	59.53 ± 0.03	a5c07dc	coopmat2
Nvidia Tesla P40	488.06 ± 0.27	59.36 ± 0.16	N/A
Nvidia GTX 1660 Ti Mobile	511.67 ± 2.85	56.60 ± 0.07	b43556e
AMD Radeon Instinct MI25	439.42 ± 0.34	54.69 ± 0.03	2739a71
AMD Radeon RX 6600 XT	574.65 ± 0.86	53.92 ± 0.11	091592d
AMD Ryzen AI Max+ 395	1288.96 ± 6.49	53.59 ± 0.38	7f76692
AMD Radeon RX 7600 XT	840.85 ± 3.02	53.02 ± 0.01	01d8eaa
Intel Arc A770	1073.85 + 29.68	52.56 + 0.11	a69d54f
Nvidia GB10	2737.79 ± 19.56	52.28 ± 0.03	b9da444	coopmat2
AMD FirePro S9300 x2	247.26 ± 0.43	51.86 ± 0.11	eec1e33	Split across two GPUs
AMD Radeon RX 6600	761.89 ± 1.76	50.63 ± 0.02	b1c70e2
AMD Radeon RX Vega 56	439.87 ± 0.61	50.23 ± 0.14	92c0b38
Intel Arc B570	913.95 ± 0.90	49.64 ± 0.03	7f76692
Nvidia RTX 3060 Mobile	1059.76 ± 3.54	49.03 ± 0.13	dbb3a47
AMD Radeon RX 6800M	861.99 ± 7.67	48.71 ± 0.71	8e6f8bc
AMD Radeon RX 6600M	605.59 ± 0.65	48.21 ± 0.07	fe5b78c
Intel Arc A770M	875.92 ± 2.16	47.69 ± 0.16	eeee367
Nvidia P104-100	311.90 ± 0.22	46.18 ± 0.05	eec1e33
AMD Radeon RX Vega 64	356.08 ± 0.09	45.73 ± 0.18	ec428b0
Nvidia RTX A2000	1245.19 ± 8.76	45.52 ± 0.54	b1afcab	coopmat2
AMD Radeon RX 7600M XT	459.39 ± 2.34	45.28 ± 0.10	b9ab0a4	eGPU
AMD Radeon Pro V340	375.41 ± 0.24	45.16 ± 0.06	9da3dcd	Split across two GPUs
Nvidia GTX 1070 Ti	297.50 ± 0.54	42.86 ± 1.20	860a9e4	eGPU
Intel Arc A750	1075.94 ± 13.89	42.66 ± 0.18	c1b1876
Nvidia RTX 4050 Mobile	1154.28 + 15.76	41.89 + 0.10	d79d8f3
Nvidia GTX 1070	321.57 ± 0.93	41.48 ± 0.09	eec1e33
Intel Arc Pro B50	193.50 ± 0.24	39.99 ± 0.10	7b43f55
Nvidia Tesla M40	92.48 ± 0.02	39.35 ± 1.22	b8372ee
AMD Radeon RX 580	258.03 ± 0.71	39.32 ± 0.03	de4c07f
AMD Radeon RX 470	218.07 ± 0.56	38.63 ± 0.21	e288693
AMD Radeon Pro W5500	315.39 ± 3.76	36.82 ± 0.38	860a9e4
AMD Radeon RX 480	248.66 ± 0.28	34.71 ± 0.14	3b15924
Apple M2 Ultra	205.98 ± 0.02	34.34 ± 0.12	dbb852b	Asahi Linux
Nvidia GTX 980	186.24 ± 0.09	33.90 ± 0.51	860a9e4
Nvidia P106-100	183.78 ± 0.26	29.77 ± 0.04	23bc779
AMD FirePro W8100	155.22 ± 0.17	29.52 ± 0.05	4536363
Nvidia Tesla P4	265.54 ± 0.21	28.03 ± 0.14	24d2ee0
AMD Radeon RX 6500 XT	255.25 ± 0.35	27.81 ± 0.10	g9fdfcd
Apple M3	263.70 ± 0.02	26.39 ± 0.14	b9ab0a4	MoltenVK
AMD FirePro S10000	94.78 ± 0.02	25.32 ± 0.02	914a82d	Split across two GPUs
Nvidia Quadro P2000	169.55 ± 0.17	23.05 ± 0.03	63f8fe0
Intel Core Ultra 200 Series	544.95 ± 4.15	22.49 ± 0.09	cea560f
AMD Ryzen AI 9 300 Series	479.07 ± 0.41	22.41 ± 0.18	N/A
AMD Ryzen 6000 Series	240.89 ± 0.52	21.26 ± 0.08	ee09828
Apple M2 Pro	62.70 ± 0.03	20.95 ± 0.11	1fe0029	Asahi Linux
Nvidia GTX 1050 Ti	136.42 ± 0.67	20.96 ± 0.21	2f0c2db
AMD Ryzen 8000 Series	266.19 ± 1.36	20.53 ± 0.08	a5c07dc
AMD Ryzen 7000 Series	281.62 ± 1.56	19.91 ± 0.07	ebce03e
AMD Ryzen Z1 Extreme	199.36 ± 7.02	18.77 ± 0.02	53ff6b9
AMD FirePro D700	69.95 ± 0.04	16.62 ± 0.01	d3bd719	MoltenVK, running in FP16 mode on FP32 only chip
AMD Radeon Pro WX 4100	78.79 ± 0.10	16.05 ± 0.07	860a9e4
Apple M2	50.79 ± 0.16	13.50 ± 0.02	8c0d6bb	Asahi Linux
Apple M1	38.29 ± 0.00	12.47 ± 0.03	2370665	Asahi Linux
AMD Ryzen 5000 Series	90.55 ± 0.08	10.98 ± 0.07	d84635b
Intel Core 1100 Series	187.20 ± 1.78	10.39 ± 0.04	abb9f3c
AMD Radeon RX 550	52.66 ± 0.49	10.20 ± 0.01	N/A
AMD Ryzen 4000 Series	103.87 ± 0.02	9.63 ± 0.01	4b385bf
Nvidia Tesla K80	89.46 ± 0.10	9.39 ± 0.06	5d46bab	Running on single GPU
Nvidia Tesla K40	64.37 ± 0.09	9.30 ± 0.19	eec1e33
MediaTek Dimensity 9400	38.36 ± 15.15	8.92 ± 0.06	b9ab0a4	GPU supports coopmat but pp512 is faster with it turned off
Intel Core Ultra 100 Series	185.51 ± 0.22	8.21 ± 0.07	1d72c84
AMD Ryzen 3000 Series	48.63 ± 0.10	8.49 ± 0.01	1fe0029
CIX CD8180	2.80 ± 0.01	5.51 ± 0.00	4dca015
Intel Core 1000 Series	25.58 ± 0.00	4.25 ± 0.18	N/A
Intel Core 8000 Series	25.43 ± 0.17	3.35 ± 0.03	c4df49a
Intel N150	28.84 ± 0.02	2.93 ± 0.00	4f63cd7

Llama 2 7B, Q4_0, FA enabled

Chip	pp512 t/s	tg128 t/s	Commit	Comments
Nvidia RTX 5090	11796.38 ± 601.36	273.68 ± 0.52	ca71fb9	coopmat2
AMD Radeon RX 7900 XTX	3332.90 ± 11.47	195.30 ± 0.23	2f0c2db
Nvidia RTX 5080	8054.59 ± 35.68	192.17 ± 0.21	f6b533d	coopmat2
Nvidia RTX 4090	10830.41 ± 36.25	190.10 ± 0.31	4ae88d0	coopmat2
Nvidia A100	7064.40 ± 1.63	170.56 ± 0.02	2257758	coopmat2
Nvidia RTX 3090	4732.33 ± 4.80	162.28 ± 0.21	4ae88d0	coopmat2
Nvidia RTX 4080 Super	8007.37 ± 46.03	150.20 ± 0.26	81086cd	coopmat2
Nvidia RTX 3080	4913.83 ± 21.52	145.74 ± 0.16	7c7d6ce	coopmat2
Nvidia Tesla V100	1411.25 ± 2.12	142.13 ± 0.03	7d77f07
Nvidia RTX A5000	4071.22 ± 13.13	140.43 ± 0.22	4ae88d0	coopmat2
AMD Radeon RX 9070 XT	4911.74 ± 28.52	138.20 ± 0.18	e9fd8dc
Nvidia RTX 5070 Ti	6764.53 ± 11.95	135.65 ± 0.02	d13d0f6	coopmat2
AMD Radeon AI Pro R9700	4333.83 ± 29.36	130.90 ± 0.12	3191462
AMD Radeon RX 7900 XT	3043.93 ± 10.42	124.20 ± 0.09	71e74a3
AMD Radeon RX 7800 XT	2094.64 ± 14.38	119.63 ± 0.13	4fdbc1e
AMD Radeon RX 9070	3277.24 ± 18.17	119.55 ± 0.06	21c17b5
AMD Radeon RX 7900 GRE	2402.07 ± 22.50	116.77 ± 0.08	4b2a477
Apple M3 Ultra	1115.55 ± 0.75	115.99 ± 0.12	2d451c8	MoltenVK
Intel Arc Pro B70	3314.53 ± 17.95	111.63 ± 0.05	b863507
Nvidia Titan V	792.74 ± 4.30	109.21 ± 0.72	e56abd2
AMD Radeon Pro VII	783.94 ± 0.77	108.45 ± 0.48	N/A
AMD Radeon RX 6900 XT	1761.93 ± 4.75	106.15 ± 0.04	a972fae
Nvidia RTX 2080 Ti	1936.25 ± 32.08	100.99 ± 0.24	N/A
AMD Radeon RX 6800 XT	1704.79 ± 0.71	100.50 ± 0.06	N/A
AMD Radeon Pro W6800X Duo	795.28 ± 0.72	100.08 ± 0.02	N/A
Nvidia RTX 5060 Ti	3912.65 ± 5.86	97.01 ± 0.14	89f10ba	coopmat2
AMD Radeon RX 6800	1749.46 ± 3.36	96.65 ± 0.48	4b385bf
Nvidia RTX 4070	4293.57 ± 27.70	91.49 ± 0.89	9a48399	coopmat2
AMD Radeon RX 6750 XT	997.05 ± 0.45	82.29 ± 0.06	228f34c
AMD Radeon RX 6700 XT	1010.90 ± 12.89	81.86 ± 0.19	6d75883
Nvidia RTX 3060	2012.88 ± 10.12	80.59 ± 0.02	92c0b38	coopmat2
AMD Radeon Pro V620	1556.31 ± 2.82	79.24 ± 0.09	03d4698
Nvidia RTX A4000	2482.74 ± 26.05	76.07 ± 0.08	f5245b5	coopmat2
Nvidia Tesla T10	1840.14 ± 1.22	76.05 ± 0.13	7f76692	coopmat2
AMD Radeon RX 5700 XT	538.31 ± 0.35	74.43 ± 0.03	4fdbc1e
Intel Arc B580	419.49 ± 3.37	72.00 ± 0.24	7f76692
Apple M4 Max	557.46 ± 26.87	71.79 ± 4.16	1ece0cb6
AMD Radeon Pro W5700	446.98 ± 0.39	71.30 ± 0.24	23bc779
Intel Arc Pro B60	274.76 ± 0.27	70.54 ± 0.03	516a4ca
AMD Radeon RX 9060 XT	1915.41 ± 7.90	70.52 ± 0.16	ed52f36
Nvidia Tesla P100	685.51 ± 0.88	66.48 ± 0.02	eec1e33
AMD Radeon RX 6650 XT	1088.90 ± 0.40	64.53 ± 0.75	dbb852b
Nvidia GTX 1080 Ti	529.96 ± 0.38	64.63 ± 0.10	360d653
AMD BC-250	356.87 ± 1.24	63.14 ± 0.09	5886f4f
Nvidia RTX 3070 Mobile	1832.07 ± 57.14	62.92 ± 0.37	ceff6bb	coopmat2
Nvidia RTX 4060 Mobile	2358.03 ± 12.17	60.01 ± 0.08	a5c07dc	coopmat2
Nvidia Tesla P40	484.37 ± 0.27	59.22 ± 0.15	N/A
Nvidia GTX 1660 Ti Mobile	514.34 ± 0.88	57.30 ± 0.42	b43556e
AMD Radeon RX 7600 XT	1024.38 ± 7.56	56.11 ± 0.02	01d8eaa
AMD FirePro S9300 x2	243.33 ± 0.22	55.64 ± 0.06	eec1e33	Split across two GPUs
Nvidia GB10	3279.89 ± 26.78	53.64 ± 0.05	b9da444	coopmat2
AMD Radeon RX 6600	808.76 ± 0.15	53.24 ± 0.03	b1c70e2
Intel Arc A770	1119.68 + 30.25	53.07 + 0.09	a69d54f
AMD Ryzen AI Max+ 395	1357.07 ± 10.94	53.00 ± 0.13	7f76692
AMD Radeon RX Vega 56	428.54 ± 0.50	52.66 ± 0.03	92c0b38
Intel Arc B570	288.51 ± 0.09	50.49 ± 0.05	7f76692
Nvidia P104-100	325.30 ± 0.25	48.64 ± 0.04	eec1e33
AMD Radeon Pro V340	360.23 ± 0.74	47.54 ± 0.06	9da3dcd	Split across two GPUs
AMD Radeon RX 6800M	784.16 ± 2.76	49.06 ± 0.34	8e6f8bc
AMD Radeon RX Vega 64	320.12 ± 0.22	47.06 ± 0.01	ec428b0
Nvidia RTX A2000	1361.85 ± 3.26	45.69 ± 0.20	b1afcab	coopmat2
Intel Arc A770M	384.74 ± 0.78	45.68 ± 0.06	eeee367
Intel Arc A750	303.37 ± 1.44	43.96 ± 0.03	c1b1876
Nvidia GTX 1070 Ti	292.85 ± 0.23	43.42 ± 0.34	860a9e4	eGPU
Nvidia GTX 1070	330.84 ± 1.02	43.33 ± 0.06	360d653
Nvidia Tesla M40	93.35 ± 0.01	41.68 ± 0.01	b8372ee
Intel Arc Pro B50	132.48 ± 0.04	41.02 ± 0.04	7b43f55
AMD Radeon RX 470	197.26 ± 0.27	37.28 ± 0.11	3769fe6
AMD Radeon RX 480	194.52 ± 0.61	37.23 ± 0.09	0bcb40b
Apple M2 Ultra	198.83 ± 0.85	198.83 ± 0.85	dbb852b	Asahi Linux
Nvidia GTX 980	180.97 ± 0.74	34.16 ± 0.10	860a9e4
Nvidia P106-100	183.40 ± 0.34	30.79 ± 0.32	23bc779
AMD FirePro W8100	140.52 ± 0.34	29.28 ± 0.14	4536363
Nvidia Tesla P4	287.14 ± 0.29	28.37 ± 0.24	24d2ee0
Nvidia Quadro P2000	181.71 ± 0.12	23.77 ± 0.02	63f8fe0
Intel Core Ultra 200 Series	536.48 ± 1.27	23.05 ± 0.04	cea560f
AMD Ryzen AI 9 300 Series	532.59 ± 3.55	22.31 ± 0.06	N/A
AMD Ryzen 6000 Series	277.91 ± 0.37	21.15 ± 0.09	ee09828
Apple M2 Pro	58.86 ± 0.02	20.97 ± 0.03	1fe0029	Asahi Linux
AMD Ryzen 8000 Series	297.39 ± 1.22	20.59 ± 0.38	a5c07dc
AMD Ryzen 7000 Series	312.85 ± 2.51	20.09 ± 0.35	835b2b9
Nvidia GTX 1050 Ti	127.54 ± 1.03	20.08 ± 0.17	2f0c2db
AMD Radeon Pro WX 4100	75.59 ± 0.19	16.56 ± 0.04	860a9e4
Apple M1	35.93 ± 0.00	12.85 ± 0.02	2370665	Asahi Linux
Apple M2	46.81 ± 0.08	12.25 ± 2.30	8c0d6bb	Asahi Linux
AMD Ryzen 5000 Series	79.06 ± 0.01	10.75 ± 0.00	5d195f1
Intel Core 1100 Series	174.77 ± 4.47	10.58 ± 0.03	abb9f3c
Nvidia Tesla K40	64.37 ± 0.02	9.92 ± 0.06	eec1e33
AMD Ryzen 4000 Series	113.32 ± 0.01	9.87 ± 0.01	4b385bf
Nvidia Tesla K80	88.26 ± 0.19	9.49 ± 0.01	5d46bab	Running on single GPU
AMD Ryzen 5 3000 Series	47.41 ± 0.14	8.47 ± 0.01	1fe0029
Intel Core Ultra 100 Series	77.66 ± 2.75	7.75 ± 0.05	2e89f76
Intel Core 8000 Series	25.55 ± 0.04	3.35 ± 0.02	c4df49a
Intel N150	25.59 ± 0.00	2.91 ± 0.00	4f63cd7

这些表格该怎么用

如果你只是想买卡或者看手里机器大概在哪个档位，最实用的读法其实是这三步：

先看你关心的是 tg128 还是 pp512。
日常对话、写代码、聊天体感，优先看 tg128；长上下文吞吐、批处理、服务端压 prompt，更应该看 pp512。
再看你实际跑的后端。
Nvidia 通常看 CUDA 更贴近真实上限；AMD 机器更应该先对照 ROCm 和 Vulkan；跨平台兼容场景则更适合参考 Vulkan。
最后再看 FA。
很多卡开启 FA 后 pp512 会涨得更明显，但 tg128 不一定同步大涨，所以不能只看单个最高分。

一句话总结

同样是 llama.cpp 跑分，pp512、tg128、Q4_0、FA、CUDA / ROCm / Vulkan 分别代表的是完全不同的维度。把口径先分清，再看数字，榜单才有意义。

如果你只想记一个最短结论，那就是：

CUDA 目前整体最强
ROCm 在高端 AMD 卡上已经很能打
Vulkan 覆盖最广，老卡、核显、Intel Arc、Apple Asahi 都能找到可比条目
tg128 比 pp512 更接近日常真实体感

原始来源

CUDA discussion #15013: https://github.com/ggml-org/llama.cpp/discussions/15013
Apple Silicon discussion #4167: https://github.com/ggml-org/llama.cpp/discussions/4167
ROCm discussion #15021: https://github.com/ggml-org/llama.cpp/discussions/15021
Vulkan discussion #10879: https://github.com/ggml-org/llama.cpp/discussions/10879

显卡推理速度测试的常用指标具体含义：FA、pp512、tg128、Q4_0 都是什么意思

Thu, 23 Apr 2026 00:15:00 +0800

看显卡推理速度测试时，最容易把人看晕的不是分数本身，而是这些缩写：

1
2
3

CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA)
pp512 t/s
tg128 t/s

下面直接按最常见的问题拆开解释。

这行标题整体是什么意思

CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA) 通常包含四层信息：

CUDA：说明跑分是在 NVIDIA GPU 的 CUDA 路径上完成的
Llama 2 7B：说明测试对象是 Llama 2 的 7B 参数版本
Q4_0：说明模型用了 4-bit 量化格式
no FA：说明这次测试关闭了 Flash Attention

一句话理解：这是某个量化版模型在 NVIDIA 显卡上的推理速度测试，而且没有开启 Flash Attention。

FA 是什么：Flash Attention

FA 就是 Flash Attention，它是注意力计算的加速技术。核心作用可以直接记成三点：

更快
更省显存
在数学上和普通注意力等价，不是“牺牲精度换速度”

no FA 是什么意思

no FA 就是没开 Flash Attention。它通常出现在跑分表里，主要是为了：

做对照组，方便看出开启 FA 后到底提升了多少
兼容某些不支持 FA 的硬件或软件环境
避免不同测试项混在一起，导致数据不可比

Q4_0 是什么：量化格式

Q4_0 是一种 4-bit 量化格式，可以先这样记：

Q：Quantization，量化
4：4-bit
_0：某一种具体量化方案的标识

它的作用是：

减少模型体积
降低显存需求
让本来装不下的模型变得能跑起来

pp512 t/s 是什么意思

pp512 一般是 Prompt Processing 512 tokens，测的是输入处理速度。

pp：prompt processing
512：测试输入长度是 512 token
t/s：每秒多少 token

它测的不是模型吐字速度，而是模型“先把输入读完”的速度。这个阶段并行度高，所以数值通常会很大，比如：

`1`	`pp512 ≈ 14000 t/s`

tg128 t/s 是什么意思

tg128 一般是 Text Generation 128 tokens，测的是输出生成速度。

tg：text generation
128：测试连续生成 128 token
t/s：每秒多少 token

它更接近我们平时感受到的“模型回答快不快”。因为生成是逐 token 递推的，所以它通常会明显低于 pp512，例如：

pp512 是上万 t/s
tg128 却只有几百 t/s

为什么 pp512 和 tg128 会差这么多

核心原因就一句话：

pp512 测的是并行吞吐，tg128 测的是逐 token 生成。`

具体来说：

输入阶段更容易并行
输出阶段更依赖逐步递推
生成阶段通常更吃显存带宽和缓存效率
所以生成速度远低于输入处理速度是正常现象

t/s 到底怎么理解

t/s 就是 tokens per second。它表示模型每秒能处理或生成多少 token。

但 token 不是“字”也不是“单词”，所以 t/s 更适合做这些对比：

同模型下不同显卡对比
同环境下不同参数设置对比
同一框架里开启或关闭某个优化项前后的对比

一页记住

Q4_0：模型被压缩成了 4-bit 量化版本
FA：是不是启用了 Flash Attention 加速
pp512：处理 512 token 输入时有多快
tg128：生成 128 token 输出时有多快
t/s：速度单位，每秒多少 token

结语

看这类显卡推理速度测试时，最重要的不是只看分高不高，而是先分清：

模型和量化格式
有没有开 FA
测的是输入处理还是文本生成
单位是不是 t/s

把这几件事分清楚，绝大多数 scoreboard 都不会太难读。

llama-cli -hf 下载 Hugging Face 模型默认保存在哪里

Fri, 17 Apr 2026 14:48:04 +0800

如果你使用的是 llama-cli 直接从 Hugging Face 下载并运行模型，例如：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

这是 llama.cpp 自带的 Hugging Face 下载能力。新版 llama.cpp 会把 -hf 下载的模型放进标准 Hugging Face Hub 缓存目录。

默认缓存位置

llama-cli -hf 下载的模型缓存位置优先由 LLAMA_CACHE 环境变量控制。如果没有设置 LLAMA_CACHE，则会继续检查 Hugging Face 相关缓存变量，例如 HF_HUB_CACHE、HUGGINGFACE_HUB_CACHE 和 HF_HOME。

如果这些变量都没有设置，常见默认路径如下：

系统	默认缓存目录
Linux	`~/.cache/huggingface/hub`
macOS	`~/.cache/huggingface/hub`
Windows	`%USERPROFILE%\.cache\huggingface\hub`

在 Windows 上，%USERPROFILE% 通常对应：

`1`	`C:\Users\用户名`

所以默认缓存目录大致是：

`1`	`C:\Users\用户名\.cache\huggingface\hub`

想修改 llama-cli 的缓存目录怎么办

可以设置 LLAMA_CACHE，把模型缓存放到指定磁盘或目录。也可以按 Hugging Face 的习惯设置 HF_HOME，此时实际 Hub 缓存目录会是 $HF_HOME/hub。

Windows 临时设置示例：

1
2

set LLAMA_CACHE=D:\models\llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

PowerShell 临时设置示例：

1
2

$env:LLAMA_CACHE="D:\models\llama-cache"
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Linux / macOS 临时设置示例：

1
2

export LLAMA_CACHE=/data/models/llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

小结

llama-cli -hf ... 使用的是 llama.cpp 下载逻辑，但新版默认落到 Hugging Face Hub 缓存。
Linux / macOS 默认：~/.cache/huggingface/hub
Windows 默认：%USERPROFILE%\.cache\huggingface\hub
想换目录：设置 LLAMA_CACHE，或设置 HF_HOME / HF_HUB_CACHE

Windows 下 llama-cli 直连 Hugging Face 报 SSL 证书验证失败怎么办

Fri, 17 Apr 2026 14:20:29 +0800

如果你在 Windows 下运行下面这条命令：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

并看到类似报错：

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

通常不是 CUDA 或 llama.cpp 本身有问题，而是程序在当前环境里没有正确拿到系统证书链，导致 HTTPS 校验失败。

从报错来看，ggml-rpc.dll 和 ggml-cpu-alderlake.dll 都已经正常加载，说明运行环境本身大体可用，问题主要集中在模型下载阶段。

最省事的办法：先手动下载模型

如果你只是想尽快跑起来，本地手动下载通常最稳。

打开对应的 Hugging Face 仓库页面。
在 Files and versions 里下载需要的 .gguf 文件。
下载完成后，直接用本地文件路径运行：

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

这样可以绕过 -hf 下载阶段的 SSL 校验问题，适合先验证模型能不能正常推理。

如果还想继续用 `-hf` 自动下载

可以手动指定证书文件路径，让程序在当前会话里找到可用的 CA 证书。

cacert.pem 可以从 curl 官方维护的 CA Extract 页面获取：

页面地址：https://curl.se/docs/caextract.html
直接下载：https://curl.se/ca/cacert.pem

如果用浏览器下载，打开上面的直接下载地址后保存为 cacert.pem 即可。也可以在 PowerShell 里下载到固定目录，例如：

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

下载完成后，在命令行里设置：

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

再重新执行原命令：

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

如果问题确实来自证书链，这种方式通常能直接解决。

llama-quantize 怎么用：GGUF 模型量化入门

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize 是 llama.cpp 里的量化工具，用来把高精度的 GGUF 模型转换成更小的量化版本。

它最常见的用途，是把类似 F32、BF16 或 FP16 这样的高精度模型，转换成 Q4_K_M、Q5_K_M、Q8_0 等更适合本地运行的格式。量化后模型体积会明显变小，推理通常也会更快，但精度会有一定损失。

基本用法

一个典型流程通常是先准备原始模型，再转换为 GGUF，最后执行量化。

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

量化完成后，就可以直接用 llama-cli 加载新的 GGUF 文件：

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

常见参数

--allow-requantize：允许对已经量化过的模型再次量化，但通常不推荐，质量可能掉得比较明显
--leave-output-tensor：保留输出层不量化，体积会更大，但有时能换来更好的质量
--pure：关闭混合量化，让更多张量使用同一量化类型
--imatrix：使用重要性矩阵优化量化效果，通常值得优先考虑
--keep-split：保留输入模型的分片结构，而不是合并成单个文件

如果只是想先跑起来，最实用的起点还是：

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

量化怎么选

可以先把不同量化等级理解成“体积、速度和质量之间的交换”：

Q8_0：体积较大，但质量通常更稳
Q6_K / Q5_K_M：常见的平衡型选择
Q4_K_M：很常见的默认档，体积和效果通常比较均衡
Q3 / Q2：适合资源非常紧张的场景，但质量下降会更明显

从给出的示例数据看，量化等级越低，模型通常越小；而在实际推理里，更高精度并不一定总是更快，所以选型重点通常不是“越大越好”，而是“在你的硬件上够稳、够省、效果也能接受”。

实用建议

优先从 Q4_K_M 或 Q5_K_M 开始试
如果更看重质量，再往 Q6_K 或 Q8_0 提升
如果机器资源比较紧，再尝试 Q3 或 Q2
最好始终用同一批测试问题比较不同量化版本

一句话总结：llama-quantize 的核心价值，不是单纯把模型变小，而是让 GGUF 模型在本地设备上更容易跑起来。

llama.cpp 如何从 Hugging Face 获取 GGUF 模型

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp 可以直接配合 Hugging Face 上的 GGUF 模型使用，不一定要先手动把文件下载到本地。

如果模型仓库本身已经提供了 GGUF 文件，可以直接在命令行里使用 -hf 参数，例如：

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

默认情况下，这个参数会从 Hugging Face 下载模型。
如果你使用的是其他兼容 Hugging Face API 的模型托管服务，也可以通过环境变量 MODEL_ENDPOINT 切换下载端点。

需要注意的是，llama.cpp 只能直接使用 GGUF 格式。
如果拿到的是其他格式的模型文件，就需要先用仓库里的 convert_*.py 脚本转换成 GGUF。

Hugging Face 还提供了一些和 llama.cpp 相关的在线工具，常见用途包括：

把模型转换为 GGUF
对模型做量化，减小体积
转换 LoRA 适配器
在线编辑 GGUF 元数据
直接托管 llama.cpp 推理服务

如果只想记住一个最实用的结论：优先找已经提供 GGUF 的模型仓库，然后直接用 llama-cli -hf <user>/<model>，通常是最省事的做法。

Gemma 4 本地调用指南：从一键运行到开发集成

Fri, 10 Apr 2026 22:54:17 +0800

如果你想在本地调用 Gemma 4（Google 2026 年发布的新一代开源模型），可以按需求从这四类方案里选。

1) 最快上手：Ollama（推荐）

这是门槛最低的方式，适合快速测试、日常对话和本地 API 调用。

`1`	`ollama run gemma4`

特点：

Win/Mac/Linux 都可用
自动处理硬件加速
提供兼容 OpenAI 风格的本地 API

2) 图形界面：LM Studio / Unsloth Studio

如果你更习惯桌面 GUI（类似 ChatGPT），这两类工具更顺手。

LM Studio：可直接搜索和下载 Hugging Face 上的 Gemma 4 量化模型（如 4-bit、8-bit），并查看资源占用。
Unsloth Studio：除了推理，也支持低显存微调。对 6GB-8GB 显存机器更友好。

3) 低配与极致控制：llama.cpp

适合老机器、纯 CPU 场景，或希望深度控制推理参数的用户。

你可以使用 .gguf 模型文件配合量化版本，在更低硬件门槛下运行 Gemma 4。

4) 开发集成：Transformers / vLLM

如果你要把 Gemma 4 接进自己的应用：

Transformers：适合 Python 项目内直接加载模型
vLLM：适合高性能 GPU 场景和高吞吐推理服务

快速选型

需求	推荐工具	硬件门槛
我只想马上跑起来	Ollama	低（自动适配）
我更喜欢图形界面	LM Studio	中
显存很紧张（6GB-8GB）	Unsloth / llama.cpp	低
我要做本地 AI 应用开发	Ollama / Transformers / vLLM	中到高
我要做微调训练	Unsloth Studio	中到高

模型尺寸建议

Gemma 4 有多种尺寸（如 E2B、E4B、31B）。

普通办公本优先选量化后的 E2B / E4B
显存更充足时再尝试更大版本

Llama.cpp on KnightLi的博客

GTX 1060 跑 Qwen 35B 实战：llama.cpp 从 3 tok/s 优化到 17 tok/s

先说结论

准备环境

第一步：先让模型跑起来

为什么默认速度可能只有 3 tok/s

第二步：调整 GPU 卸载

第三步：理解 MoE 为什么重要

第四步：处理内存瓶颈

第五步：上下文长度不要一开始拉满

第六步：关注 batch 参数

第七步：记录自己的五个关键参数

一个更稳的测试流程

常见失败尝试

1. 盲目拉高 GPU 卸载层数

2. 一开始就拉超长上下文

3. 只看平均 tok/s

4. 不记录参数

适合 GTX 1060 的预期

一句话总结

Holo 3.1 本地部署教程：用 llama.cpp 接入 OpenClaw 跑 Computer Use Agent

准备条件

1. 下载 llama.cpp

2. 下载 Holo 3.1 模型

3. 启动 Holo 3.1 本地服务

4. 安装 OpenClaw

5. 安装浏览器自动化 skills

6. 测试一个简单任务

使用建议

常见问题

Holo 3.1 是什么？

Holo 3.1 可以本地部署吗？

Holo 3.1 需要什么硬件？

Holo 3.1 适合什么任务？

参考链接

Gemma 4 MTP 实测调参：用 assistant 草稿模型冲 120 tokens/s

MTP 在这里做什么

命令行示例

参数解释

-m

-md

--draft-max

-ngl 99

-p

更稳的测试命令

为什么 120 tokens/s 不一定复现

适合用来测速的 prompt

常见问题

加了 -md 反而 OOM

参数不识别

输出变奇怪

小结

8GB 显存跑 Gemma 4 12B：llama-cli 混合卸载参数怎么配

推荐脚本

为什么要混合卸载

--flash-attn：8GB 显存建议打开

-c 8192：先把上下文压到 8K

--mlock：减少内存换出

-t 8：CPU 线程数别盲目拉满

关于 -p "<|think|>\n"

第一次运行建议用保守版

想提速，优先换量化

内存带宽也很关键

排障顺序

一个调参表

小结

Hermes Agent 桌面版发布：Windows、macOS、Linux 都能图形化上手

桌面版解决了什么问题

安装和基础设置

接入本地模型：Ollama 和 llama.cpp

消息平台接入仍然是重点

适合谁使用

使用时要注意什么

小结

RTX 3060 也能跑 35B？llama.cpp 的 --n-cpu-moe 让老电脑继续本地大模型

关键不是换显卡，而是 MoE 调度

速度变化有多明显？

一个可参考的 Windows 启动命令

不同显卡怎么调？

32GB 内存够不够？

`-m`

`-md`

`--draft-max`

`-ngl 99`

`-p`

加了 `-md` 反而 OOM

`--flash-attn`：8GB 显存建议打开

`-c 8192`：先把上下文压到 8K

`--mlock`：减少内存换出

`-t 8`：CPU 线程数别盲目拉满

关于 `-p "<|think|>\n"`