Claude Code + llama.cpp + RTX 5090 实战调优：Qwopus3.6-27B-Coder 跑出 52 Tokens/s，128K 上下文稳定开发

1. 为什么 27B Dense 模型在 RTX 5090 上只能跑 15 Tokens/s

先说结论：如果你直接把 Qwopus3.6-27B-Coder 的 GGUF 丢进 llama.cpp 默认参数里跑，大概率只能看到 15 Tokens/s 左右的输出速度，然后你会开始怀疑显卡是不是没插好、CUDA 是不是没编译对、驱动是不是版本不对。我一开始也是这么想的，折腾了半天才发现问题根本不在硬件。

Qwopus3.6-27B-Coder 是一个 27B 的 Dense 模型，不是 MoE。这一点非常关键。之前很多人测 Qwen3-Coder-30B-A3B 能跑到 90 Tokens/s，那是因为它虽然标称 30B，但实际每个 Token 只激活大约 3B 参数，属于 MoE 架构，计算量小得多。而 Qwopus 是实打实的 27B Dense，每个 Token 都要完整过一遍全部参数，计算量差了将近一个数量级。所以 15 Tokens/s 到 52 Tokens/s 这个区间，才是 Dense 模型在单卡 RTX 5090 上的真实表现范围。

那为什么标题里写的是 52 Tokens/s？因为默认参数下你连 Dense 模型的正常水平都跑不到。默认启动时 llama.cpp 不会自动开 Flash Attention，KV Cache 用的是 f16，上下文一开大显存直接爆，GPU Layers 也可能没全部卸载到显卡上。这几个因素叠加起来，速度就被压到了 15 Tokens/s。把参数调对之后，52 Tokens/s 是可以在 128K 上下文下稳定复现的。

这篇文章面向的场景很具体：你想在 RTX 5090 单卡上本地跑 Qwopus3.6-27B-Coder，用 Claude Code 做 Agent 编程，需要 128K 长上下文来容纳整个仓库的上下文，同时希望输出速度能到 50 Tokens/s 以上，让多轮对话和工具调用不至于卡到没法用。下面我会把完整的启动参数、量化选择、KV Cache 配置、验证步骤和常见报错排查都写清楚，你可以直接复制跟着做。

先明确一下硬件和软件基线。我用的卡是 RTX 5090 D V2，24GB 显存。llama.cpp 需要是比较新的版本，因为 Flash Attention 在较新版本里才默认支持得比较好，老版本可能编译选项都不一样。CUDA 版本建议 12.4 以上，驱动用较新的生产分支驱动即可。模型文件用的是 Qwopus3.6-27B-Coder-Q5_K_M.gguf，这个量化在代码质量和显存占用之间比较平衡，后面会讲为什么选 Q5_K_M 而不是 Q4 或 Q8。

还有一个容易被忽略的点：mmproj。很多人看到日志里报image input is not supported就以为模型缺了视觉模块，然后去折腾 mmproj 文件。但 Claude Code 的 Agent 编程场景根本不需要图像输入，加载 mmproj 只会额外占显存、拖慢推理。所以第一步就是把视觉相关的加载全部关掉，Coding 服务和 Vision 服务分开部署，不要混在一起。

2. llama.cpp 编译与 Qwopus3.6-27B-Coder 模型准备

在调参之前，得先把 llama.cpp 编译好、模型文件准备好。这一步如果出问题，后面所有调优都是白搭。

2.1 编译 llama.cpp 并确认 CUDA 后端

先拉最新代码，然后按 CUDA 后端编译。注意-DGGML_CUDA=ON这个开关一定要开，否则跑起来是 CPU 推理，速度会惨不忍睹。

git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120 cmake --build build --config Release -j$(nproc)

这里CMAKE_CUDA_ARCHITECTURES=120是针对 RTX 5090 的 Blackwell 架构。如果你不确定自己的卡对应哪个架构，可以先不指定，让 CMake 自动探测，但显式指定能避免编译出一堆用不上的架构，编译更快。编译完成后，build/bin/下面会有llama-server、llama-cli等可执行文件。

编译完之后建议先跑一下./build/bin/llama-server --version，确认输出里有 CUDA 相关的信息。如果只显示 CPU，说明 CUDA 后端没编进去，需要检查 CUDA Toolkit 路径和 cmake 的报错。

2.2 模型文件与量化选择

Qwopus3.6-27B-Coder 的 GGUF 量化版本有好几种，常见的是 Q4_K_M、Q5_K_M、Q6_K、Q8_0。在 24GB 显存、128K 上下文的约束下，量化选择不是越高质量越好，而是要算总账。

显存占用大致分三块：模型权重、KV Cache、计算中间激活。27B 模型在不同量化下的权重大致是：Q4_K_M 约 16GB，Q5_K_M 约 19GB，Q6_K 约 22GB，Q8_0 约 28GB。Q8_0 直接超过 24GB，单卡放不下，除非你接受部分层跑 CPU，但那样速度会掉得厉害。Q6_K 的 22GB 权重加上 128K 的 KV Cache，基本没有余量，很容易 OOM。Q4_K_M 权重小，但代码生成质量在长上下文下会有可感知的下降，尤其是工具调用和结构化输出的时候。

所以 Q5_K_M 是这张卡上比较合适的甜点：权重约 19GB，留出约 4-5GB 给 KV Cache 和计算缓冲。配合 q8_0 的 KV Cache 量化，128K 上下文可以稳定跑起来。如果你把上下文降到 64K，Q6_K 也可以考虑，但既然目标是 128K 长上下文开发，Q5_K_M 更稳妥。

下载模型的时候注意校验文件完整性，GGUF 文件很大，下载中断导致文件损坏的话，加载时会报各种奇怪的错。可以用sha256sum对一下官方提供的哈希值。

2.3 确认 GPU 被正确识别

在正式启动 server 之前，先用一个简单命令确认 llama.cpp 能看到你的 RTX 5090：

./build/bin/llama-cli -m ~/work/models/Qwopus3.6-27B-Coder-Q5_K_M.gguf -ngl 1 -p "hello" -n 1

-ngl 1表示只卸载 1 层到 GPU，主要是为了看日志里有没有正确加载 CUDA 后端、有没有识别到显卡。如果日志里出现ggml_cuda_init: found 1 CUDA devices并且列出了 RTX 5090，说明环境没问题。如果报no CUDA devices found，那就是编译或者驱动的问题，先解决这个再往下走。

这一步还会告诉你模型加载需要多少显存、有多少层。记下这个层数，后面--n-gpu-layers要设成比它大的值，确保全部层都卸载到 GPU。

3. 可复制的 llama-server 启动参数与 KV Cache 配置

这一节是核心，直接给你可以复制运行的启动命令，然后逐项解释每个参数为什么这么设。

3.1 完整启动命令

./build/bin/llama-server \ -m ~/work/models/Qwopus3.6-27B-Coder-Q5_K_M.gguf \ --host 0.0.0.0 \ --port 8080 \ -c 131072 \ --alias qwopus \ --n-gpu-layers 999 \ --flash-attn on \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --temp 0.2 \ --top-p 0.9 \ --top-k 40 \ -np 1

把这段保存成一个start_qwopus.sh，加上执行权限，以后直接跑脚本就行。下面逐项说明。

3.2 关键参数逐项说明

-c 131072是上下文长度，131072 就是 128K。Claude Code 在 Agent 模式下会自动把 System Prompt、历史对话、文件 Diff、当前文件、相关文件、Tool 返回结果全部塞进上下文，很容易超过 32K。如果你把上下文限制在 32768，大型项目里会频繁报request exceeds context size。所以直接开 128K，不要为了省显存去压上下文。

--n-gpu-layers 999表示把所有层都卸载到 GPU。999 是个足够大的数，实际会被模型层数截断。全部卸载是速度的关键，只要有层留在 CPU，推理时就要在 CPU 和 GPU 之间来回传数据，速度会断崖式下跌。

--flash-attn on是 Flash Attention 开关。新版 llama.cpp 已经支持，开启后长上下文下的注意力计算效率明显提升，这是从 15 Tokens/s 提到 50 Tokens/s 的关键之一。不开的话，128K 上下文下注意力计算会成为瓶颈。

--cache-type-k q8_0 --cache-type-v q8_0是 KV Cache 的量化类型。默认是 f16，128K 上下文下 KV Cache 会占掉十几 GB，直接爆显存。改成 q8_0 之后，KV Cache 显存占用大约减半，同时对代码生成质量的影响很小，实测下来工具调用和结构化输出都还稳定。如果你显存特别紧张，可以试 q4_0，但代码质量下降会更明显，不太推荐。

--temp 0.2 --top-p 0.9 --top-k 40是采样参数。代码生成场景温度要低，0.2 能让输出更确定、更少发散。top-p 0.9 和 top-k 40 是配合使用的，避免采样到太离谱的 Token。这套组合在 Agent 编程里比较稳，工具调用的 JSON 格式不容易崩。

-np 1是并行请求数，设成 1。Claude Code 一般是串行发请求，设大了反而会占额外显存。如果你同时跑多个客户端，可以适当调大，但要注意显存。

3.3 等价的 JSON 配置片段

如果你习惯用配置文件而不是命令行参数，llama-server 也支持通过 JSON 传参。下面是一个等价的配置片段，路径和参数与上面命令一致：

{ "model": "/home/user/work/models/Qwopus3.6-27B-Coder-Q5_K_M.gguf", "host": "0.0.0.0", "port": 8080, "ctx_size": 131072, "alias": "qwopus", "n_gpu_layers": 999, "flash_attn": true, "cache_type_k": "q8_0", "cache_type_v": "q8_0", "temp": 0.2, "top_p": 0.9, "top_k": 40, "parallel": 1 }

注意model路径要换成你自己的实际路径。这个 JSON 可以通过--config参数传给 llama-server，或者在你的启动脚本里用环境变量注入。

3.4 参数速查表

启动之后，日志里会打印模型加载信息、KV Cache 大小、Flash Attention 状态等。确认没有报错，并且看到prompt cache is enabled、context checkpoints enabled、graphs reused这些字样，说明 Prompt Cache 已经默认开启，多轮对话会明显更流畅。

4. 验证请求与 52 Tokens/s 成功结果

参数配好之后，得验证两件事：服务能不能正常响应，以及速度是不是真的到了 52 Tokens/s。

4.1 用 curl 发一个基础请求

先确认 server 起来了，用最简单的 curl 测一下：

curl http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwopus", "messages": [ {"role": "user", "content": "用 Python 写一个快速排序函数，并解释时间复杂度。"} ], "max_tokens": 256, "temperature": 0.2 }'

如果返回了正常的 JSON，里面有choices字段和生成的代码，说明服务通了。注意model字段要填--alias设的qwopus，填错了会报模型不存在。

4.2 观察日志里的 Prompt Eval 与 Decode 速度

发完请求后，回到 llama-server 的终端看日志。你会看到类似这样的输出：

prompt eval time = 3288.45 ms / 1024 tokens (3.21 ms per token, 311.42 tokens per second) eval time = 4923.08 ms / 256 tokens (19.23 ms per token, 52.01 tokens per second)

这里有两个速度，很多人会混淆。prompt eval是读取 Prompt 的速度，也就是模型处理你输入的那一大段上下文的速度，这里能到 3000 Tokens/s 以上。eval才是模型真正生成 Token 的速度，也就是 Decode 速度，这里显示 52.01 Tokens/s，就是我们要复现的目标。

Prompt Eval 快是因为它是一次性并行计算，Decode 慢是因为它要一个 Token 一个 Token 自回归生成，每生成一个都要完整过一遍模型。所以看到 Prompt 3000+ Tokens/s、Decode 52 Tokens/s，是完全正常的，不要以为哪里出问题了。

4.3 用 nvidia-smi dmon 确认 GPU 真实利用率

很多人跑起来之后用nvidia-smi看，发现 GPU Util 显示 0%，以为 GPU 没工作。其实这是采样问题。nvidia-smi的 GPU-Util 是瞬时采样，而 llama.cpp 的推理是 GPU 计算和 CPU 采样交替进行的，很容易采样到 CPU 阶段，显示 0%。

正确的做法是用nvidia-smi dmon：

nvidia-smi dmon -s pucm -d 1

这个命令会持续输出 GPU 的功耗、利用率、显存等信息。在 Decode 阶段，你应该能看到：

pwr gpu sm mem enc dec mclk pclk 548 98 98 86 0 0 7001 2400

sm到 98%，mem到 86%，功耗 548W，说明 GPU 已经接近满载。显存占用大约 23.5GB，基本把 24GB 用满了。这才是判断 llama.cpp 有没有吃满 GPU 的正确方式。

4.4 128K 上下文下的稳定性验证

光跑一个短请求不够，要验证 128K 上下文下是否稳定。可以构造一个长 Prompt，比如把一段几万 Token 的代码文件塞进去，然后让它做重构。观察日志里 Prompt Eval 是否正常完成，Decode 速度是否还能维持在 50 Tokens/s 左右。

如果上下文接近 128K 时速度明显下降，或者报显存不足，那就要检查 KV Cache 量化是否生效、Flash Attention 是否真的开了。正常情况下，128K 上下文下 Decode 速度应该和短上下文差别不大，因为 KV Cache 已经量化，注意力计算也被 Flash Attention 优化过了。

5. 本篇常见报错排查：401、local proxy failed、reading choices、OAuth

调优过程中会遇到一些报错，这里把常见的几个列出来，对照排查。

5.1 401 Unauthorized

如果你在 Claude Code 里配置了本地 llama-server，但报 401，通常是 API Key 没配对。llama-server 默认不校验 Key，但 Claude Code 会带一个 Key 发请求。你需要在 Claude Code 的配置里把 Base URL 指向本地 server，Key 随便填一个非空值即可。

如果你是通过 TaoToken 这类平台接入，401 通常是 Key 无效或过期。这时候去控制台重新生成一个 Key，然后更新配置。注意 Base URL 和 Key 要配套，不要混用不同环境的。

5.2 local proxy failed

这个报错一般出现在 Claude Code 尝试连接本地 server 但连不上的时候。先确认 llama-server 是不是真的在跑，端口是不是 8080，--host 0.0.0.0有没有设。如果 server 在另一台机器上，还要确认防火墙有没有放行端口。

另一个常见原因是 Claude Code 配置里的 Base URL 写错了。本地 server 的 Base URL 应该是http://127.0.0.1:8080/v1，注意结尾的/v1不能少。如果写成http://127.0.0.1:8080，请求路径会不对，报 proxy failed。

5.3 reading choices 报错

这个报错通常是 server 返回的 JSON 格式不符合 OpenAI 兼容格式，或者返回了错误信息但客户端还在尝试解析choices字段。先看 llama-server 的日志，确认请求有没有正常处理完。如果日志里有报错，比如context size exceeded，那就是上下文超了，需要检查-c参数和实际请求的 Token 数。

还有一种情况是模型加载失败，server 虽然起来了但模型没加载成功，请求进来直接返回错误。这时候日志里会有模型加载相关的报错，检查模型路径和文件完整性。

5.4 OAuth 相关报错

如果你用的是 Claude Code 官方客户端，它可能会走 OAuth 流程。本地 llama-server 不支持 OAuth，所以需要把 Claude Code 配置成用 API Key 模式，而不是 OAuth 模式。具体是在配置里指定ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY，指向本地 server。

如果你是通过 TaoToken 接入，OAuth 报错通常是回调地址配错了。检查 deep link 里的回调地址和你在控制台配置的是否一致。模型对话、Coding Plan、API Keys 这些页面都有对应的配置说明，对照着检查。

5.5 三件套配置检查清单

不管用哪种客户端，接入本地或远程模型服务时，这三件套必须配全：

少任何一个都会报错。特别是 Model ID，本地 server 要和你--alias设的一致，远程接入要填平台文档里写的模型 ID。

6. 从本地调优到稳定开发的接入建议

本地 llama-server 跑通之后，接下来就是把它接到 Claude Code 里做实际开发。这里给几个实操建议。

Claude Code 的配置里，把ANTHROPIC_BASE_URL指向http://127.0.0.1:8080/v1，ANTHROPIC_API_KEY填一个非空字符串，模型名填qwopus。这样 Claude Code 就会把请求发到本地 server，由 Qwopus3.6-27B-Coder 来处理。

如果你不想在本地维护模型和显卡，或者需要更稳定的 Coding Plan 和 Agent 能力，可以走 TaoToken 的接入方式。Base URL 用https://taotoken.net/api，Key 在控制台生成，模型 ID 按文档填。接入文档里有详细的配置步骤，模型对话页面可以直接验证模型是否可用。

对于长期编码和 Agent 场景，Coding Plan 更适合，不用自己管显卡和显存，也不用担心模型更新和量化选择。本地调优适合你想完全掌控推理过程、对延迟和隐私有要求的场景；平台接入适合你想快速开始、不想折腾环境的情况。

最后说一个实际踩过的坑：Claude Code 在 Agent 模式下会频繁发请求，每次请求都带很长的上下文。如果你的 server 只开了 32K 上下文，大型项目里会不断报400 Bad Request。所以 128K 不是可选项，是 Agent 编程的刚需。配合 Prompt Cache，多轮对话时只有新增部分需要重新计算，体验会流畅很多。这套配置在 RTX 5090 单卡上跑下来，128K 上下文加 52 Tokens/s 的 Decode 速度，做仓库级代码修改和多文件重构已经够用了。