1716 字
5 分钟
Ternary-Bonsai-2-27B-PTQ1_0 性能测试报告
Ternary-Bonsai-2-27B-PTQ1_0 性能测试报告
日期：2026-09-20
服务器：139.196.207.146（KVM，2× RTX 4090 48GB，无 NVLink）
测试方式：SSH 远程调用 :8188 的 OpenAI 兼容 API（/v1/chat/completions），全部在服务器本地执行，消除网络误差；单并发/多并发的吞吐数字以 llama.cpp 服务器日志的 print_timing 为准。
1. 部署信息
| 项 | 值 |
|---|---|
| 引擎 | llama.cpp（PrismML 分支）llama-server，容器 bonsai-2-27b |
| 模型文件 | Ternary-Bonsai-2-27B-PTQ1_0.gguf，5.6 GB |
| 量化 | PTQ1_0，1.75 bit 三值化（ternary，group 128） |
| 参数量 | 26.896 B（n_params 26,895,998,464） |
| GPU | RTX 4090 #1，显存占用 23.0 GB，-ngl 99 全量上卡 |
| 并行 | --parallel 4：4 个独立 slot，每 slot 64K 上下文（总 KV 预算 256K token） |
| Flash Attention | on |
| 采样 | temp 0.7 / top-p 0.95 / top-k 20 |
| 多模态 | 无（纯文本） |
上下文配置（回答用户问题）
| 项 | 值 | 说明 |
|---|---|---|
| compose 请求 | -c 262144（262K） | 目标值 |
| 实际生效 | n_ctx_slot = 65536（64K） | 显存装不下 262K，llama.cpp 自动降档 |
| 模型训练长度 | n_ctx_train = 262144 | 模型本身支持 262K |
| 全服务总容量 | 4 slot × 64K = 256K token | 单请求最大 64K |
结论：本部署下单请求上下文上限 = 64K。“拉满”即 ~60K（64K 减去生成余量）。
2. 测试方法
- 中文填充文本精确构造 prompt（每单位 ~17 token），档位：~130 / ~860 / ~5.7K / ~32K / ~40K token
- 生成长度 128 / 256 token
- 并发档位：短上下文 1、4；长上下文 1、2（llama.cpp 只有 4 个 slot，更高并发只会被 LRU 抢占排队，无额外并行收益）
- 指标来源：API
usage（prompt/completion tokens）+ 服务器日志print_timing（prompt eval / token eval 真实速率）
3. 结果汇总
3.1 单并发
| 场景 | prompt (tok) | 生成 | prefill 速度 | decode 速度 | TTFT(≈prefill) | 总耗时 |
|---|---|---|---|---|---|---|
| 短上下文 A（~130 tok） | 159 | 128 | 834 t/s | 27.3 t/s | 1.49 s | 6.04 s |
| 短上下文 B（~860 tok） | 863 | 128 | 821 t/s | 34.7 t/s | 2.54 s | 5.6 s |
| 中上下文（~5.7K tok） | 5,663 | 256 | 1,554 t/s | 87.7 t/s | 3.62 s | 6.52 s |
| 长上下文（~32K tok） | 32,063 | 256* | 1,531 t/s | 75.4 t/s | 20.92 s | 22.41 s |
| 拉满（~40K tok） | 40,063 | 128 | 1,377 t/s | 72.2 t/s | 6.19 s | 7.94 s |
* 该请求模型实际生成 113 token 后 EOS 结束（对重复填充文本提前总结完毕）。
3.2 多并发（4 路）
| 场景 | 并发 | 每路 prompt | 聚合 decode | 每路 decode 范围 | 批耗时 |
|---|---|---|---|---|---|
| 短上下文（~130 tok） | 4 | 159 | 39.7 t/s（=4 路全并行） | 27.3 → 34.7 t/s | 12.91 s |
| 短上下文（~860 tok） | 4 | 863 | 80.9 t/s | 33.7 ~ 35.1 t/s（几乎无损） | 6.33 s |
| 中上下文（~5.7K tok） | 4 | 5,663 | 40.1 t/s（未全并行，含抢占） | 8.1 ~ 38.1 t/s | 16.08 s |
| 长上下文（~32K tok） | 2 | 32,063 | 15.4 t/s（排队为主） | 5.9 ~ 57.1 t/s | 22.39 s |
| 拉满（~40K tok） | 2 | 40,063 | 26.6 t/s | 16.3 ~ 44.3 t/s | 9.63 s |
3.3 关键行为：slot LRU 抢占
4 个 slot 各自独占 64K KV。当进行中的请求数 > 4，或新请求比占坑的大时，llama.cpp 按 LRU + LCP 相似度 抢占最久未用的 slot，被抢占请求从头重算。实测案例：
- 5.7K 并发 4 路中，一路任务（slot 0）被后来的 32K 任务抢占，prompt 重算到 5,316 token 后中止，decode 被压到 8.1 t/s，最终 115 token 用了 12.6 s（正常应 2.9 s）。
- 32K 双并发中，一路 22K 的旧任务在 100 token 处被抢，decode 只剩 4.9 t/s。
含义：llama.cpp 的”并发”是固定 slot 池，不是真正的连续批处理（continuous batching）。大请求会踢掉小请求，混规模负载下尾延迟不可控。
4. 与其他引擎的对比（同机 GPU1 48GB）
| 指标 | Bonsai（1.75-bit 三元） | NInfer Qwen3.8-27B（~10-bit，GPU1 曾部署） | sglang Qwen3.8-27B AWQ W4A16（GPU0） |
|---|---|---|---|
| 权重显存 | 5.6 GB | 16.7 GB | ~17.8 GB |
| 部署总显存 | 23.0 GB | 23.5 GB | 42.5 GB |
| 单流 decode（短） | 27 ~ 35 t/s | 89 ~ 97 t/s | 53 t/s |
| 单流 decode（~5.7K） | 87.7 t/s | ~101 t/s | 52.5 t/s |
| 单流 decode（32K） | 75 t/s | ~86 t/s | ~52 t/s |
| prefill 速度 | 821 ~ 1,554 t/s | 1,300 ~ 2,990 t/s | —（chunked 16K） |
| 最大上下文/请求 | 64K | 262K | 262K |
| 并发模型 | 4 固定 slot，LRU 抢占 | 串行调度（max-concurrency 4） | 连续批处理（16 并发 336 t/s） |
| 16 并发聚合吞吐 | 不适用（4 slot 上限） | 125 ~ 162 t/s | 336 ~ 341 t/s |
解读：
- 1.75-bit 权重让 Bonsai 在小上下文（KV 短、decode 受权重带宽限制）时只有 27 ~ 35 t/s——比 NInfer 慢 2.5~3 倍，甚至比 sglang 的 4-bit AWQ 还慢。三元量化的反量化/带宽路径是瓶颈。
- 长上下文（KV 读取占大头）时三者差距收敛到 1.2~1.5 倍，Bonsai 75 t/s @32K 属于可用水平。
- prefill 是 Bonsai 的强项：1,531 ~ 1,554 t/s 的 prompt 处理速度，40K 上下文 TTFT 可低至 6 s（KV 命中时）。
- 高并发服务能力 sglang 完胜（连续批处理 vs 固定 slot）。
5. 内容质量观察
- 回答连贯、无乱码，能正确完成”总结重复文本”的任务；
- 对纯重复填充文本，模型会提前 EOS（32K 档只生成 113 token），属正常行为；
- 1.75-bit 三元量化下未见明显语言退化（本次测试样本均为结构化任务，未做开放式创作/数学推理抽检）。
6. 结论与建议
- 上下文：当前部署单请求上限 64K（请求的 262K 被显存限制自动降档）。如需真正 262K，需把
-np降到 12 并减少单 slot 竞争，或换更大显存/量化更省的方案——但 5.6GB 三元权重下 262K 单请求 KV 约 1015GB，理论可行，需要重启容器调整-c与-np组合（本次为只读测试，未修改）。 - 定位：Bonsai 适合长文档单用户分析（高 prefill + 75 t/s decode + 64K 上下文 + 极低权重占用），不适合多用户服务（4 slot 抢占机制尾延迟差）和高频短对话（decode 偏慢）。
- 与现有服务分工：GPU0 sglang 继续承担多用户/多模态主力；GPU1 上 Bonsai 与 NInfer 二选一——追求速度选 NInfer（Qwen），追求”最小显存占用跑长上下文”选 Bonsai。
- 量化代价明确：1.75-bit 换来了 1/3 的权重体积，但 decode 在小上下文下比 4-bit 还慢，属于”省显存、费带宽”的路线，选型时按显存紧张程度决定。
附录：原始数据
- 本地：
F:\ds-harness-workspace\bonsai_bench_results.json（API 层 usage/wall） - 服务器：
/tmp/bench_bonsai.py（压测脚本）、docker logs bonsai-2-27b（print_timing 原始速率）
分享
如果这篇文章对你有帮助，欢迎分享给更多人！
Ternary-Bonsai-2-27B-PTQ1_0 性能测试报告
https://blog.goodnightan.com/posts/ternary-bonsai-2-27b-ptq1_0-test-report/ 部分信息可能已经过时
相关文章 智能推荐
1
两张 4090、一条 PCIe：本地部署 27B 大模型的全记录
教程 两张 4090、一条 PCIe：本地部署 27B 大模型的全记录
2
使用docker部署 SGLang并在本地部署 Qwen3.5-35B-A3B
教程 使用docker部署 SGLang并在本地部署 Qwen3.5-35B-A3B
3
Hermes 的安装
教程 在Ubuntu 25.10 中安装 Hermes 并对接飞书
4
OpenClaw docker部署
教程 在Ubuntu-25.10-Desktop 系统上使用docker安装 OpenClaw 全流程
5
OpenClaw 全流程部署指南
教程 在Ubuntu-25.10-Desktop 系统上安装 OpenClaw 全流程