Qwen3.8-27B Q4_K_M 跑在单张 RTX 3090 上 + OpenCode:吞吐量、四项编码任务与一次推理预算失败

Reddit r/LocalLLaMA 新闻

摘要

作者搭建了一套本地编码代理环境——在 24GB 的 RTX 3090 上通过 llama.cpp 运行 Qwen3.8-27B Q4_K_M,并接入 OpenCode——报告了吞吐量数据、四个有界 Python 编码任务(三项通过检查),以及一次推理预算失败:模型耗尽了 8K 的输出额度,却没能产出补丁。

我把一张旧的 RTX 3090 用起来作为本地编码代理,搭配 Qwen3.8-27B、llama.cpp 和 OpenCode。以下是环境配置与结果,包括失败的部分。这是我自己博客文章的摘要,原文链接见下方。 **环境配置** RTX 3090 24GB,Ryzen 7 5800X,64GB 内存,Ubuntu。Qwen3.8-27B Q4_K_M 权重(约 16.8GB),所有层放在 GPU 上。llama.cpp b11146,CUDA 12.8,flash attention,q8_0 K/V cache,单个生成槽位。131,072 token 的上下文容量;每次响应 8,192 token 的输出额度。输入和输出共享上下文,推理过程也消耗输出额度。 OpenCode 2.0.20 连接 llama-server 的 OpenAI 兼容 API(http://127.0.0.1:8080/v1)。OpenCode 负责读写文件和运行测试;llama-server 负责推理。在我们的测试中,对话、工具调用往返以及流式工具调用均正常工作。 **速度:全新输入与缓存续写对比** | 实际输入 | 吞吐量 | 首 token(全新) | 首 token(缓存) | | --- | --- | --- | --- | | 2,073 tokens | 36.4 tok/s | 2.75 s | 0.46 s | | 16,378 tokens | 33.5 tok/s | 17.00 s | 0.47 s | | 65,537 tokens | 25.9 tok/s | 83.41 s | 0.51 s | | 120,011 tokens | 20.9 tok/s | 183.01 s | 0.63 s | 这些吞吐量测试关闭了 thinking。2K 那一行是三次全新请求的中位数;更大的行各有一次全新请求和一次续写。缓存续写只处理了 27–28 个新输入 token,几乎复用了整个前缀。亚秒级的数字依赖于这种复用;它们并不描述一个全新的 120K 提示词。 峰值采样 GPU 总显存占用为 22,162 MiB(含桌面占用)。装得下,但余量有限。一次独立的约 120K 合成检索检查通过了,但我们没有评估该长度下的编码质量。 **四项有界 Python 编码任务** 每个任务都使用全新会话、中等 thinking、八分钟截止时间,以及十个保存在代理工作区之外的独立测试方法。首次尝试以串行方式运行,不使用云端回退或网络工具。 | 任务 | 独立检查,修改前 → 修改后 | 结果 | | --- | --- | --- | | 过期 LRU 缓存 | 0/10 → 10/10 | 约 3 分 07 秒完成;表现最佳 | | CSV 账本/退款 | 1/10 → 10/10 | 约 5 分 44 秒完成;后续审查发现缺陷 | | 增量构建规划器 | 1/10 → 1/10 | 无任何修改;耗尽了响应额度 | | 原子 SQLite 转账 | 1/10 → 10/10 | 候选补丁通过,但在最终测试重跑和交接前超时 | 三个候选补丁通过了预定义检查;其中两个在截止时间内完成了整个工作流。总计 31/40 中包含一次构建规划器未改动基线的通过,并不代表通用的编码成功率。 构建规划器是最有意思的失败案例:大约 4,985 个输入 token,随后 8,192 个输出 token 全部消耗在推理上,最终因长度截断结束,没有产出补丁。这是一次远低于上下文上限的输出预算失败。一次关闭 thinking 的独立诊断在 5 分 40 秒内完成,并通过了 10 项独立检查中的 9 项。那只是在 temperature 1 下额外做的一次运行,并不能证明关闭 thinking 普遍更好。 通过测试并不意味着没有缺陷。进一步审查账本后发现在一个较大的数值边界处存在 Decimal 舍入问题,以及一个未处理的 I/O 错误。钱包自带的并发测试实际上是顺序执行的,而一次独立的边界探测发现 SQLite 会把溢出的余额转换为 REAL 类型并记录成功。这些后续探测并未事后纳入那四十项检查中。 对我来说,有用的工作流是:一个有明确验收标准的有界任务,随后进行 diff 审查和独立检查。我会在不同的 thinking 设置和响应预算下重复这些任务,然后再得出更强的结论。 我的完整文章、配置和测量链接。可下载的工具包包含启动器、OpenCode 配置、吞吐量脚本和记录;不包含模型权重和完整的编码任务测试夹具。 对于其他使用 24GB 显卡搭配 OpenCode 的用户:在有界编码任务上,哪种推理设置和每次响应的输出预算效果最好? 声明:我讲中文,并使用 AI 对文章英文摘要进行了本地化改写和润色。所有数据和失败案例均来自链接的实验记录。
查看原文

相似文章