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 AttentionKV 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 V224GB 显存。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_CUDAON这个开关一定要开否则跑起来是 CPU 推理速度会惨不忍睹。git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES120 cmake --build build --config Release -j$(nproc)这里CMAKE_CUDA_ARCHITECTURES120是针对 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 约 16GBQ5_K_M 约 19GBQ6_K 约 22GBQ8_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 上下文可以稳定跑起来。如果你把上下文降到 64KQ6_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 的量化类型。默认是 f16128K 上下文下 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 参数速查表参数推荐值作用-c131072128K 上下文Agent 编程必须--n-gpu-layers999全部层卸载到 GPU--flash-attnon长上下文注意力加速--cache-type-kq8_0KV Cache K 量化省显存--cache-type-vq8_0KV Cache V 量化省显存--temp0.2代码生成更稳定--top-p0.9降低发散--top-k40保持生成质量-np1串行请求省显存启动之后日志里会打印模型加载信息、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 dmonnvidia-smi dmon -s pucm -d 1这个命令会持续输出 GPU 的功耗、利用率、显存等信息。在 Decode 阶段你应该能看到pwr gpu sm mem enc dec mclk pclk 548 98 98 86 0 0 7001 2400sm到 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 指向本地 serverKey 随便填一个非空值即可。如果你是通过 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 三件套配置检查清单不管用哪种客户端接入本地或远程模型服务时这三件套必须配全配置项本地 llama-serverTaoToken 接入Base URLhttp://127.0.0.1:8080/v1https://taotoken.net/apiAPI Key任意非空值控制台生成的 KeyModel IDqwopus对应 --alias平台支持的模型 ID少任何一个都会报错。特别是 Model ID本地 server 要和你--alias设的一致远程接入要填平台文档里写的模型 ID。6. 从本地调优到稳定开发的接入建议本地 llama-server 跑通之后接下来就是把它接到 Claude Code 里做实际开发。这里给几个实操建议。Claude Code 的配置里把ANTHROPIC_BASE_URL指向http://127.0.0.1:8080/v1ANTHROPIC_API_KEY填一个非空字符串模型名填qwopus。这样 Claude Code 就会把请求发到本地 server由 Qwopus3.6-27B-Coder 来处理。如果你不想在本地维护模型和显卡或者需要更稳定的 Coding Plan 和 Agent 能力可以走 TaoToken 的接入方式。Base URL 用https://taotoken.net/apiKey 在控制台生成模型 ID 按文档填。接入文档里有详细的配置步骤模型对话页面可以直接验证模型是否可用。对于长期编码和 Agent 场景Coding Plan 更适合不用自己管显卡和显存也不用担心模型更新和量化选择。本地调优适合你想完全掌控推理过程、对延迟和隐私有要求的场景平台接入适合你想快速开始、不想折腾环境的情况。最后说一个实际踩过的坑Claude Code 在 Agent 模式下会频繁发请求每次请求都带很长的上下文。如果你的 server 只开了 32K 上下文大型项目里会不断报400 Bad Request。所以 128K 不是可选项是 Agent 编程的刚需。配合 Prompt Cache多轮对话时只有新增部分需要重新计算体验会流畅很多。这套配置在 RTX 5090 单卡上跑下来128K 上下文加 52 Tokens/s 的 Decode 速度做仓库级代码修改和多文件重构已经够用了。