尧图网页设计 
人工智能大模型模型量化模型压缩本地部署【免费下载链接】Ternary-Bonsai-2-27B-gguf项目地址https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-gguf点击查看免费下载导读本文以本仓库 README.md 为骨架系统讲解Ternary-Bonsai-2-27B这一 27B 级三元ternary推理模型的 GGUF 部署全流程从{−1, 0, 1}三元权重与 Hadamard 旋转的原理到 PTQ1_0 / PQ2_0 两种打包格式的选择再到基于 PrismML llama.cpp fork 的下载、构建、推理命令与采样参数调优。读完本文你将能在一台消费级 GPU 或 Apple Silicon 笔记本上以约 67 GB 显存/内存运行一个保留 98.2% 全精度能力的 27B 推理模型并能正确规避其已知的运行时坑点。本仓库为只读镜像文中所涉文件均为 LFS 指针与文档实际推理前需按文内命令从模型仓库下载真实权重并使用 PrismML 的 llama.cpp fork 二进制详见下文“运行环境”一节。一、模型概览一个 27B 三元推理模型1.1 基本规格项目规格基础模型派生自 Qwen3.8-27B27B 混合注意力因果语言模型架构未改动参数量27.36B 总计 —— 语言主干 24.35B64 层 嵌入/LM head 2.54B 视觉塔 0.46B27 层架构混合注意力约 75% 线性 / 约 25% 全注意力、SwiGLU MLP、RoPE、RMSNorm上下文长度262K token继承自基座模型以线性注意力为主的主干使其在端侧保持实用权重格式Ternary g128{−1, 0, 1}权重 FP16 分组缩放打包为PTQ1_0密集 trits或PQ2_02-bit 槽位权重基分块 Hadamard 旋转块 1024固定 ±1 符号折叠进存储权重运行时对激活施加匹配变换低位覆盖Embeddings、注意力投影、MLP 投影、LM head 全覆盖视觉塔可选的约 0.63 GB mmproj 包Q8_0仅在图像输入时加载部署体积5.95 GBPTQ1_0或7.21 GBPQ2_0后端llama.cppCUDA、Metal、CPU许可证Apache 2.01.2 与基座模型的关系从规格表可以看出Bonsai 2 27B 的架构与 Qwen3.8-27B 完全一致——它没有改动模型拓扑而是把权重表示从 FP16 换成三元格式从而在不牺牲推理能力的前提下把体量压缩约 9 倍。这种“架构不变、表示换底”的设计让它可以无缝复用 Qwen3.8-27B 生态中的提示词模板、生成配置与混合注意力主干约 75% 线性注意力是 262K 长上下文在端侧可行的关键。仓库内的 NOTICE.txt 与 LICENSE 也印证了这一派生关系软件基于 Qwen3.8-27B 构建Qwen 侧同为 Apache 2.0整体以 Apache 2.0 发布公开部署或再分发时建议注明 Created using Bonsai by Prism ML.。二、核心原理Ternary g128 三元权重2.1 三元化的信息论账本每个权重只取{−1, 0, 1}三个值之一一个三元值携带 log₂3 ≈1.585 bits的信息。格式为每 128 个权重共享一个 FP16 缩放因子三元编码128 × 1.585 ≈ 202.9 bits分摊的缩放16 bits / 128 ≈ 0.125 bits/weight合计约1.71 bits/weight再计入少量以更高精度保存的张量线性注意力层的循环状态路径与归一化权重共 26.2M 参数约占语言模型的 0.0976%全模型达到1.72 bits/weight——相对 FP16 的理想压缩比约为9.3x。README 特别强调这是端到端的三元化嵌入层、注意力投影、MLP 投影与 LM head 全部覆盖不存在“低位标签背后藏着高精度逃生通道”的情况只有视觉塔作为独立的 Q8_0 mmproj 包另行发布。2.2 Hadamard 旋转把量化损失摊到每个权重直接对权重做三元量化会产生集中在个别权重的截断误差。Bonsai 2 27B 采用分块 Hadamard 旋转来缓解每个矩阵按块 1024 进行正交 Hadamard 旋转后再做三元赋值旋转在离线阶段折叠进存储权重因此不消耗额外 bit、也不增加权重搬运流量打包模型把旋转声明为元数据prism.hadamard.*运行时要么施加匹配的激活变换要么拒绝加载该文件。这一点直接决定了后文的“必须使用 fork 二进制”要求旋转激活变换只在 PrismML 的 llama.cpp fork 里实现主线 llama.cpp 没有这套运行时。2.3 内存需求对照格式真实 bits/weight体积压缩比FP16基线16.0约 54 GB1.0xTernary g128理想1.725.8 GB约 9.3xGGUF PTQ1_0密集 trits1.755.95 GB约 9.0xGGUF PQ2_02-bit 槽位2.137.21 GB约 7.5x两种打包格式的提出是为了让高效内核能够直接消费三元权重PTQ1_0把 trits 密集打包每权重 1.75 bits几乎贴合理论信息论下限PQ2_0把每个 trit 放进一个 2-bit 槽位每权重 2.13 bits用略大的体积换取更便宜的解包算术。两者并非严格的优劣排序吞吐差异见第六节吞吐量表。三、仓库交付物验证以本仓库实际文件为准均为 Git LFS 指针文件指针内记录了真实大小组件文件LFS 记录大小README 描述语言模型Ternary-Bonsai-2-27B-PTQ1_0.gguf5,946,648,928 B ≈ 5.95 GB常驻语言模型Ternary-Bonsai-2-27B-PQ2_0.gguf7,206,168,928 B ≈ 7.21 GB常驻语言模型参考Ternary-Bonsai-2-27B-F16.gguf53,808,408,928 B ≈ 53.8 GB全精度基线视觉塔Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf629,246,976 B ≈ 0.63 GB可选仅多模态输入时加载视觉塔参考Ternary-Bonsai-2-27B-mmproj-BF16.gguf931,145,856 B ≈ 0.93 GB可选部署要点文本推理只要求语言模型常驻Q8_0 mmproj 通常被卸载offload只有在真正输入图片时才加载因此纯文本服务永远不会为视觉塔买单。四、运行环境这些文件需要 PrismML 的 llama.cpp 构建4.1 为什么主线 llama.cpp 不行三元混合注意力内核位于 PrismML 的 llama.cpp fork 中CUDA Metal。主线 llama.cpp 无法运行这些文件主线将PQ2_0和PTQ1_0当作未知量化类型直接拒绝主线能加载Q2_0却不给任何警告随后产生乱码输出——因为它没有 Hadamard 激活运行时。这一事实同样记录在仓库的 KNOWN_ISSUES.md“Runtimes other than the PrismML build”一节主线 llama.cpp、Ollama、LM StudioGGUF均不能加载PQ2_0/PTQ1_0文件F16文件虽能在主线加载但同样会因缺少 PrismML 构建才会应用的元数据而产生乱码。务必使用 fork 的二进制。4.2 获取或构建二进制# 预编译包按平台选择归档PrismML-Eng/llama.cpp 的 releases 页 tar -xzf llama-tag-bin-platform.tar.gz -C bin --strip-components1 # 或自行构建克隆 PrismML-Eng/llama.cpp 后 git clone PrismML-Eng/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build -j # macOS 上省略 -DGGML_CUDAONMetal 为默认两个版本号提示来自 KNOWN_ISSUES.md首发版本prism-b10687没有附带二进制请改用prism-b10709或更新的发布构建 CUDA 时若报CUDA_ARCHITECTURES is empty需显式传-DCMAKE_CUDA_ARCHITECTURESarchRTX 40 系列为89RTX 5090 可尝试-DCMAKE_CUDA_ARCHITECTURES120a-real。4.3 下载模型hf download prism-ml/Ternary-Bonsai-2-27B-gguf Ternary-Bonsai-2-27B-PQ2_0.gguf --local-dir .五、Quickstart一条命令跑起来./bin/llama-cli -m Ternary-Bonsai-2-27B-PQ2_0.gguf \ -ngl 99 -fa on -c 32768 \ --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.05 \ -p Explain quantum computing in simple terms. -n 16384参数逐项说明参数含义备注-m模型文件路径取PQ2_0或PTQ1_0-ngl 99全部层 offload 到 GPU0为纯 CPU-fa on开启 flash attention-c 32768上下文长度上限 262144-n 16384最大输出 token 数给思维链留空间见下--temp / --top-p / --top-k / --min-p采样参数见第六节推荐值二进制路径解压发布的归档是./bin/llama-cli自行构建则是./build/bin/llama-cli。两个必须注意的“反直觉”点输出上限要留足。这是推理模型默认先思考再作答思维链同样计入输出配额。若上限过小如 256会在想完之前截断得到空回答或残缺回答——这是 KNOWN_ISSUES.md 中“最常见报告”。README 建议-n 16384服务端则设max_tokens配合-c 65536。--min-p 0.05是默认值写出来是为了让命令自明。GGUF 文件内携带top_k、top_p、temperaturegeneral.sampling.*但没有min_pllama.cpp 自身默认即 0.05所以用户无需显式设置也能生效。若使用默认min_p0.0的其他运行时请手动设 0.05。reasoning effort模板默认xhigh也是 README 推荐的长思考档位需要更短回答时用medium换取速度与精度的平衡low不受支持选择后模型行为接近xhigh。注意聊天模板只接受low/medium/xhigh传high会返回 HTTP 500。服务端场景llama-server、工具调用、推理预算--reasoning-budget N、图像输入mmproj、投机解码等更完整的运行脚本以官方 Bonsai-demo 仓库为准——README 明确它才是“运行这些模型的唯一事实来源”source of truth会随内核迭代持续维护各后端的测试环境与固定版本二进制。六、生成参数最佳实践6.1 推荐的采样参数README 原表Thinking Mode思考模式temperature1.0top_p0.95top_k20min_p0.05presence_penalty0.0repetition_penalty1.0Instruct非思考模式temperature0.7top_p0.80top_k20min_p0.0presence_penalty1.5repetition_penalty1.0设计依据README 说明min_p0.05会丢弃远低于最高候选概率的 token测试中它至少不逊于min_p0.0且指令遵循更可靠因此推荐用于思考模式。它同时也是 llama.cpp 的默认值。其余数值与基座模型自身的generation_config.json一致。报告中的基准测试结果即使用上述设置测得唯一例外测试时min_p0.0。6.2 关于min_p与惩罚项的元数据缺口KNOWN_ISSUES.md 补充了两个重要的元数据细节min_p不在 GGUF 中文件只带top_k20、top_p0.95、temperature1.0。llama.cpp 用户因默认值 0.05 自动获得默认 0.0 的运行时需手动设置。模型卡修正元数据的更新已在计划中。presence_penalty与repetition_penalty也不在 GGUF 中因此不带参数的服务器不会自动应用模型卡的数值需要显式传入。6.3 System Prompt一个简单的系统提示即可You are a helpful assistant注意聊天模板要求恰好一条且位于最前的系统消息——多余或位置不当的系统消息会触发 HTTP 500详见 KNOWN_ISSUES.md 工具调用一节。6.4 打包格式怎么选PQ2_0H100、A100 与 Blackwell 系列上 decode 更快所有平台 prompt 处理prefill更快Apple Silicon 上测的就是它。PTQ1_0Ada 世代显卡与 L4 上 decode 更快内存最紧张时的首选。吞吐量对照见第七节。七、跨平台吞吐量实测tg128 生成 128 个 token 的吞吐内存带宽受限的交互阶段pp512 处理 512 个输入 token 的吞吐计算受限阶段。单位为 tokens/s用llama-bench在 batch size 1、depth 0、无视觉塔的条件下测得NVIDIA 能耗为板卡功耗含 HBM/GDDR。平台PQ2_0 TG128PQ2_0 PP512PQ2_0 J/tokPTQ1_0 TG128PTQ1_0 PP512PTQ1_0 J/tokRTX 5090 (32 GB)129.938931.95120.518052.15RTX PRO 6000 Blackwell124.840202.49117.919722.77H100 SXM (80 GB)113.928302.6986.912373.18RTX 6000 Ada (48 GB)82.824312.5190.416572.49RTX 4090 (24 GB)81.231242.9991.116452.58L40S (48 GB)74.428683.2481.815432.82A100 SXM (80 GB)73.913283.4354.77064.28L4 (24 GB, 72 W)29.87772.4232.14672.25笔记本Apple M5 Pro, Metal28.1387————读表要点README 的解释两种打包是真实的权衡PTQ1_0 每步少搬运 17% 的权重数据但解包密集 trits 需要算术开销——因此在内存是瓶颈的 Ada 世代与 L4 上胜出在 H100/A100/Blackwellbatch-1 decode 受指令吞吐与启动开销限制上落败。Prompt 处理是计算受限的PQ2_0 全平台占优。笔记本的意义不在速度比54 GB 的 FP16 基线根本装不进 M5 Pro关键结论是“27B 模型能在日常笔记本上交互式运行”。M5 Pro 实测 decode 流约 204 GB/s 权重证实了低比特表示所针对的内存带宽主导画像。能效对比M5 Pro 在 GPU 轨上 decode 功耗 27.5 WCPUGPU 合计 34.1 W而上表 NVIDIA 卡为 300–455 W 板卡功耗。Apple 行没有每 token 能耗因为两平台仪器测量范围不同nvidia-smi含 HBM/GDDRApplepowermetrics报告 CPU/GPU/ANE 而无 DRAM 轨。7.1 其他 Apple 平台预旋转构建当前栈待重测平台FootprintTG128 (tok/s)PP512 (tok/s)笔记本Apple M5 Max, Metal7.2 GB47.0765笔记本Apple M5 Pro, Metal7.2 GB28.7393笔记本Apple M4 Pro, Metal7.2 GB18.0125M5 Max 可达约 47 tok/sM4 Pro 上极长提示词的实际瓶颈是 prefill约 125 tok/s而非 decode。八、基准测试思考模式下的 14 项能力评估方法EvalScope vLLM统一在 NVIDIA H100 上、相同基础设施、解码与评分流程思考模式下测得该模式下模型完整推理被激活传统方法在 sub-4-bit 下的塌缩最明显。14 项基准覆盖六个技能类别“vs FP16”相对 Qwen3.8-27B FP16 参考比特宽度为真实平均。变体True bpwFootprintThinking avgvs FP16Qwen3.8-27B FP1616.054 GB86.32100%Qwen3.8-27B UD-Q4_K_XL4-bit5.217.6 GB85.1898.7%Qwen3.8-27B IQ2_XXS2-bit2.167.27 GB72.5984.1%Bonsai 2 27B1.725.95 GB84.7898.2%以 5.95 GB 的体积Bonsai 2 27B 比 sub-4-bit 的传统构建IQ2_XXS高出 12 分以上而体积只有其约 82%距 UD-Q4_K_XL 仅差 0.4 分而体积只有其三分之一。“平均分”掩盖了塌缩的形态传统低比特构建的退化是选择性的集中在需要持续推理链的基准上。IQ2_XXS 在 AIME26 只有 57.5、LiveCodeBench 只有 56.4却仍在 MMLU-Redux 拿到 88.93——这正是日常随手测试发现不了塌缩的原因。Bonsai 2 在同样基准上拿到 95.83 与 90.07。上一代 Bonsai 27B 报告在 Gemma-4-31B 家族上也呈现同一模式说明塌缩是方法属性而非单一基座模型的属性。8.1 按技能类别类别基准FP16Bonsai 2 27B知识与推理MMLU-Redux, MuSR85.5579.86数学GSM8K, MATH-500, AIME25, AIME2697.0696.57编码HumanEval, MBPP, LiveCodeBench89.0789.42指令遵循IFEval, IFBench81.2582.66Agentic / 工具调用BFCL v376.7474.92视觉MMMU-Pro, OCR Bench v271.3666.19总体14 项86.3284.78推理主干基本完整保留数学仅从 97.06 降到 96.57编码与基线持平指令遵循甚至略超基线。残余差距集中在最有难度的两类知识与推理、视觉。8.2 逐基准完整结果思考模式展开查看 14 项基准的逐项对比基准FP16UD-Q4_K_XLIQ2_XXSBonsai 2 27BMMLU-Redux91.4693.3588.9389.09MuSR79.6373.0166.9970.63GSM8K97.1996.6689.9096.66MATH-50099.8099.4084.6098.80AIME2596.6792.9166.6795.00AIME2694.5893.0057.5095.83HumanEval93.2995.7391.4695.12MBPP83.8683.8678.8983.07LiveCodeBench90.0587.9656.4090.07IFEval91.5088.8384.0391.31IFBench (prompt-loose)71.0065.6553.7674.00BFCL v376.7475.0570.2874.92MMMU-Pro81.7381.7365.1975.49OCR Bench v260.9965.4561.7056.88平均14 项86.3285.1872.5984.78九、智能密度Intelligence Density智能密度刻画“单位部署体积能换回多少能力”定义D -log2(1 - score/100) / size_GB变体体积 (GB)基准均分智能密度 (1/GB)Bonsai 2 27B5.9584.780.457Ternary Bonsai 27B上一代5.7580.980.416Qwen3.8-27B IQ2_XXS7.2772.590.257Qwen3.8-27B UD-Q4_K_XL17.5685.180.157Qwen3.8-27B FP1654.6686.320.053Bonsai 2 27B 的密度约为表中“最密”传统构建IQ2_XXS0.257的1.8x、FP16 的9x相对上一代 Bonsai 27B0.416提升 9.9%。注上一代行是在同一 14 项基准上重算的保证同口径可比。十、典型使用场景笔记本本地 27B Agent标准笔记本上约 28 tok/s 运行完整 27B 推理与工具调用262K 上下文支撑长文档分析、整库代码任务等依赖大工作集驻留内存的场景。隐私敏感与离线环境端侧执行从构造上保证提示词与数据不离开设备可在间歇性或无网络环境下工作。单 GPU / 消费级 GPU 服务单张消费级或入门级数据中心 GPU 即可获得 27B 级质量——RTX 5090 约 130 tok/s72 W 的 L4 约 30 tok/s——并为更大 batch、更长上下文或模型共存留出余量。质量优先的低比特部署以约九分之一的体积保留全精度模型基准均分的 98.2%。十一、已知问题与排查速查本仓库附带 KNOWN_ISSUES.md最近核验 2026-09-23覆盖PQ2_0/PTQ1_0/F16与 MLX 构建。以下为高频问题的速查现象对策空回答、或“一直思考不回答”给足输出上限-n 16384以上API 对应max_tokens配合-c 65536想缩短思考则发reasoning_effort: mediumreasoning_effort: high返回 HTTP 500改用xhigh默认或medium——模板不接受high在 AMD Zen 4/Zen 5 等 AVX-512 CPU 上加载崩溃用当前prism分支源码构建已在源码修复其他值得提前知道的运行时坑采样元数据min_p、presence_penalty、repetition_penalty均不在 GGUF 中需显式传入见第六节。工具调用工具arguments为空或非 JSON 时可能 HTTP 500/400无参调用请发{}系统消息必须唯一且置顶工具循环中不要向会话回写思维链会导致每轮重处理大部分对话、提示缓存失效。加载与平台CUDA 13.3 构建在某些系统崩溃Linux 用 CUDA 12.8、Windows 用 12.4 构建ROCm/HIP 在消费级 RDNA2 上中止可试 Vulkan 构建--split-mode tensor/row暂不能跨双 GPU 加载自己用llama-quantize量化普通模型到PQ2_0/PTQ1_0会产生乱码两类型仅对带prism.hadamard.*旋转元数据的导出检查点有效。性能KV cache 避免用q5_0改用f16/q8_0/q4_0单用户服务建议-np 1 --cache-ram 24576避免长对话反复重算 prompt--spec-type ngram-*对此模型无效果。视觉小图“指物/接地grounding”类任务效果差时以--image-min-tokens 1024启动服务器。十二、限制声明质量与体积的权衡三元模型保留全精度均分的 98.2%差距适中且可预测——推理核心数学、编码与基线相差仅数分差异集中在最具难度的类别。原生低比特内核仍在演进密集 PTQ1_0 打包1.75 bits/weight5.95 GB已可用但解包 trits 消耗算术——它在 Ada 级及更小加速器上更快在 Ampere/Hopper/Blackwell 上更慢这些平台上 batch-1 decode 并不受带宽饥饿“在每个目标上都把体积优势兑现为延迟优势”是正在进行的工程目标。十三、许可与引用本仓库以 Apache 2.0 发布LICENSE派生自 Qwen3.8-27B同样 Apache 2.0见 NOTICE.txt。公开部署或再分发时建议注明 Created using Bonsai by Prism ML.。若在研究中引用 Bonsai 2 27B推荐techreport{bonsai2_27b, title {Bonsai 2 27B: A 27B Ternary Reasoning Model}, author {Prism ML}, year {2026}, month {September}, url {https://prismml.com} }进一步阅读本仓库内的 README.md本文主体文档、KNOWN_ISSUES.md问题与 workaround 全集、LICENSE 与 NOTICE.txt许可信息模型运行脚本与多后端方案见官方 Bonsai-demo 仓库README 明确其为运行这些模型的唯一事实来源。赞分享人工智能大模型模型量化模型压缩本地部署【免费下载链接】Ternary-Bonsai-2-27B-gguf项目地址https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-gguf点击查看免费下载相关推荐破解三元比特流Ternary-Bonsai-2-27B-mlx-2bit的PTQ1_0/PQ2_0到MLX 2-bit无损转码算法详解破解三元比特流Ternary Bonsai 2 27B mlx 2bit的PTQ1_0/PQ2_0到MLX 2 bit无损转码算法详解 在开源项目 Terna大模型模型量化本地部署模型优化推理模型人工智能PQ2_0还是PTQ1_0Bonsai 2 27B打包格式横评基于9款真机测速的硬件选型攻略PQ2_0还是PTQ1_0Bonsai 2 27B打包格式横评基于9款真机测速的硬件选型攻略 Bonsai 2 27B 是 Prism ML 推出的三值t人工智能大模型模型量化模型压缩本地部署如何在NVIDIA GPU上运行Ternary-Bonsai-2-27B-mlx-2bitGGUF双打包与定制llama.cpp部署完整指南如何在NVIDIA GPU上运行Ternary Bonsai 2 27B mlx 2bitGGUF双打包与定制llama.cpp部署完整指南 Ternary大模型模型量化本地部署模型优化推理模型人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Bonsai 2 27B GGUF 部署指南：三元权重、PTQ1_0/PQ2_0 打包与 llama.cpp 推理实战
人工智能大模型模型量化模型压缩本地部署【免费下载链接】Ternary-Bonsai-2-27B-gguf项目地址https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-gguf点击查看免费下载导读本文以本仓库 README.md 为骨架系统讲解Ternary-Bonsai-2-27B这一 27B 级三元ternary推理模型的 GGUF 部署全流程从{−1, 0, 1}三元权重与 Hadamard 旋转的原理到 PTQ1_0 / PQ2_0 两种打包格式的选择再到基于 PrismML llama.cpp fork 的下载、构建、推理命令与采样参数调优。读完本文你将能在一台消费级 GPU 或 Apple Silicon 笔记本上以约 67 GB 显存/内存运行一个保留 98.2% 全精度能力的 27B 推理模型并能正确规避其已知的运行时坑点。本仓库为只读镜像文中所涉文件均为 LFS 指针与文档实际推理前需按文内命令从模型仓库下载真实权重并使用 PrismML 的 llama.cpp fork 二进制详见下文“运行环境”一节。一、模型概览一个 27B 三元推理模型1.1 基本规格项目规格基础模型派生自 Qwen3.8-27B27B 混合注意力因果语言模型架构未改动参数量27.36B 总计 —— 语言主干 24.35B64 层 嵌入/LM head 2.54B 视觉塔 0.46B27 层架构混合注意力约 75% 线性 / 约 25% 全注意力、SwiGLU MLP、RoPE、RMSNorm上下文长度262K token继承自基座模型以线性注意力为主的主干使其在端侧保持实用权重格式Ternary g128{−1, 0, 1}权重 FP16 分组缩放打包为PTQ1_0密集 trits或PQ2_02-bit 槽位权重基分块 Hadamard 旋转块 1024固定 ±1 符号折叠进存储权重运行时对激活施加匹配变换低位覆盖Embeddings、注意力投影、MLP 投影、LM head 全覆盖视觉塔可选的约 0.63 GB mmproj 包Q8_0仅在图像输入时加载部署体积5.95 GBPTQ1_0或7.21 GBPQ2_0后端llama.cppCUDA、Metal、CPU许可证Apache 2.01.2 与基座模型的关系从规格表可以看出Bonsai 2 27B 的架构与 Qwen3.8-27B 完全一致——它没有改动模型拓扑而是把权重表示从 FP16 换成三元格式从而在不牺牲推理能力的前提下把体量压缩约 9 倍。这种“架构不变、表示换底”的设计让它可以无缝复用 Qwen3.8-27B 生态中的提示词模板、生成配置与混合注意力主干约 75% 线性注意力是 262K 长上下文在端侧可行的关键。仓库内的 NOTICE.txt 与 LICENSE 也印证了这一派生关系软件基于 Qwen3.8-27B 构建Qwen 侧同为 Apache 2.0整体以 Apache 2.0 发布公开部署或再分发时建议注明 Created using Bonsai by Prism ML.。二、核心原理Ternary g128 三元权重2.1 三元化的信息论账本每个权重只取{−1, 0, 1}三个值之一一个三元值携带 log₂3 ≈1.585 bits的信息。格式为每 128 个权重共享一个 FP16 缩放因子三元编码128 × 1.585 ≈ 202.9 bits分摊的缩放16 bits / 128 ≈ 0.125 bits/weight合计约1.71 bits/weight再计入少量以更高精度保存的张量线性注意力层的循环状态路径与归一化权重共 26.2M 参数约占语言模型的 0.0976%全模型达到1.72 bits/weight——相对 FP16 的理想压缩比约为9.3x。README 特别强调这是端到端的三元化嵌入层、注意力投影、MLP 投影与 LM head 全部覆盖不存在“低位标签背后藏着高精度逃生通道”的情况只有视觉塔作为独立的 Q8_0 mmproj 包另行发布。2.2 Hadamard 旋转把量化损失摊到每个权重直接对权重做三元量化会产生集中在个别权重的截断误差。Bonsai 2 27B 采用分块 Hadamard 旋转来缓解每个矩阵按块 1024 进行正交 Hadamard 旋转后再做三元赋值旋转在离线阶段折叠进存储权重因此不消耗额外 bit、也不增加权重搬运流量打包模型把旋转声明为元数据prism.hadamard.*运行时要么施加匹配的激活变换要么拒绝加载该文件。这一点直接决定了后文的“必须使用 fork 二进制”要求旋转激活变换只在 PrismML 的 llama.cpp fork 里实现主线 llama.cpp 没有这套运行时。2.3 内存需求对照格式真实 bits/weight体积压缩比FP16基线16.0约 54 GB1.0xTernary g128理想1.725.8 GB约 9.3xGGUF PTQ1_0密集 trits1.755.95 GB约 9.0xGGUF PQ2_02-bit 槽位2.137.21 GB约 7.5x两种打包格式的提出是为了让高效内核能够直接消费三元权重PTQ1_0把 trits 密集打包每权重 1.75 bits几乎贴合理论信息论下限PQ2_0把每个 trit 放进一个 2-bit 槽位每权重 2.13 bits用略大的体积换取更便宜的解包算术。两者并非严格的优劣排序吞吐差异见第六节吞吐量表。三、仓库交付物验证以本仓库实际文件为准均为 Git LFS 指针文件指针内记录了真实大小组件文件LFS 记录大小README 描述语言模型Ternary-Bonsai-2-27B-PTQ1_0.gguf5,946,648,928 B ≈ 5.95 GB常驻语言模型Ternary-Bonsai-2-27B-PQ2_0.gguf7,206,168,928 B ≈ 7.21 GB常驻语言模型参考Ternary-Bonsai-2-27B-F16.gguf53,808,408,928 B ≈ 53.8 GB全精度基线视觉塔Ternary-Bonsai-2-27B-mmproj-Q8_0.gguf629,246,976 B ≈ 0.63 GB可选仅多模态输入时加载视觉塔参考Ternary-Bonsai-2-27B-mmproj-BF16.gguf931,145,856 B ≈ 0.93 GB可选部署要点文本推理只要求语言模型常驻Q8_0 mmproj 通常被卸载offload只有在真正输入图片时才加载因此纯文本服务永远不会为视觉塔买单。四、运行环境这些文件需要 PrismML 的 llama.cpp 构建4.1 为什么主线 llama.cpp 不行三元混合注意力内核位于 PrismML 的 llama.cpp fork 中CUDA Metal。主线 llama.cpp 无法运行这些文件主线将PQ2_0和PTQ1_0当作未知量化类型直接拒绝主线能加载Q2_0却不给任何警告随后产生乱码输出——因为它没有 Hadamard 激活运行时。这一事实同样记录在仓库的 KNOWN_ISSUES.md“Runtimes other than the PrismML build”一节主线 llama.cpp、Ollama、LM StudioGGUF均不能加载PQ2_0/PTQ1_0文件F16文件虽能在主线加载但同样会因缺少 PrismML 构建才会应用的元数据而产生乱码。务必使用 fork 的二进制。4.2 获取或构建二进制# 预编译包按平台选择归档PrismML-Eng/llama.cpp 的 releases 页 tar -xzf llama-tag-bin-platform.tar.gz -C bin --strip-components1 # 或自行构建克隆 PrismML-Eng/llama.cpp 后 git clone PrismML-Eng/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build -j # macOS 上省略 -DGGML_CUDAONMetal 为默认两个版本号提示来自 KNOWN_ISSUES.md首发版本prism-b10687没有附带二进制请改用prism-b10709或更新的发布构建 CUDA 时若报CUDA_ARCHITECTURES is empty需显式传-DCMAKE_CUDA_ARCHITECTURESarchRTX 40 系列为89RTX 5090 可尝试-DCMAKE_CUDA_ARCHITECTURES120a-real。4.3 下载模型hf download prism-ml/Ternary-Bonsai-2-27B-gguf Ternary-Bonsai-2-27B-PQ2_0.gguf --local-dir .五、Quickstart一条命令跑起来./bin/llama-cli -m Ternary-Bonsai-2-27B-PQ2_0.gguf \ -ngl 99 -fa on -c 32768 \ --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.05 \ -p Explain quantum computing in simple terms. -n 16384参数逐项说明参数含义备注-m模型文件路径取PQ2_0或PTQ1_0-ngl 99全部层 offload 到 GPU0为纯 CPU-fa on开启 flash attention-c 32768上下文长度上限 262144-n 16384最大输出 token 数给思维链留空间见下--temp / --top-p / --top-k / --min-p采样参数见第六节推荐值二进制路径解压发布的归档是./bin/llama-cli自行构建则是./build/bin/llama-cli。两个必须注意的“反直觉”点输出上限要留足。这是推理模型默认先思考再作答思维链同样计入输出配额。若上限过小如 256会在想完之前截断得到空回答或残缺回答——这是 KNOWN_ISSUES.md 中“最常见报告”。README 建议-n 16384服务端则设max_tokens配合-c 65536。--min-p 0.05是默认值写出来是为了让命令自明。GGUF 文件内携带top_k、top_p、temperaturegeneral.sampling.*但没有min_pllama.cpp 自身默认即 0.05所以用户无需显式设置也能生效。若使用默认min_p0.0的其他运行时请手动设 0.05。reasoning effort模板默认xhigh也是 README 推荐的长思考档位需要更短回答时用medium换取速度与精度的平衡low不受支持选择后模型行为接近xhigh。注意聊天模板只接受low/medium/xhigh传high会返回 HTTP 500。服务端场景llama-server、工具调用、推理预算--reasoning-budget N、图像输入mmproj、投机解码等更完整的运行脚本以官方 Bonsai-demo 仓库为准——README 明确它才是“运行这些模型的唯一事实来源”source of truth会随内核迭代持续维护各后端的测试环境与固定版本二进制。六、生成参数最佳实践6.1 推荐的采样参数README 原表Thinking Mode思考模式temperature1.0top_p0.95top_k20min_p0.05presence_penalty0.0repetition_penalty1.0Instruct非思考模式temperature0.7top_p0.80top_k20min_p0.0presence_penalty1.5repetition_penalty1.0设计依据README 说明min_p0.05会丢弃远低于最高候选概率的 token测试中它至少不逊于min_p0.0且指令遵循更可靠因此推荐用于思考模式。它同时也是 llama.cpp 的默认值。其余数值与基座模型自身的generation_config.json一致。报告中的基准测试结果即使用上述设置测得唯一例外测试时min_p0.0。6.2 关于min_p与惩罚项的元数据缺口KNOWN_ISSUES.md 补充了两个重要的元数据细节min_p不在 GGUF 中文件只带top_k20、top_p0.95、temperature1.0。llama.cpp 用户因默认值 0.05 自动获得默认 0.0 的运行时需手动设置。模型卡修正元数据的更新已在计划中。presence_penalty与repetition_penalty也不在 GGUF 中因此不带参数的服务器不会自动应用模型卡的数值需要显式传入。6.3 System Prompt一个简单的系统提示即可You are a helpful assistant注意聊天模板要求恰好一条且位于最前的系统消息——多余或位置不当的系统消息会触发 HTTP 500详见 KNOWN_ISSUES.md 工具调用一节。6.4 打包格式怎么选PQ2_0H100、A100 与 Blackwell 系列上 decode 更快所有平台 prompt 处理prefill更快Apple Silicon 上测的就是它。PTQ1_0Ada 世代显卡与 L4 上 decode 更快内存最紧张时的首选。吞吐量对照见第七节。七、跨平台吞吐量实测tg128 生成 128 个 token 的吞吐内存带宽受限的交互阶段pp512 处理 512 个输入 token 的吞吐计算受限阶段。单位为 tokens/s用llama-bench在 batch size 1、depth 0、无视觉塔的条件下测得NVIDIA 能耗为板卡功耗含 HBM/GDDR。平台PQ2_0 TG128PQ2_0 PP512PQ2_0 J/tokPTQ1_0 TG128PTQ1_0 PP512PTQ1_0 J/tokRTX 5090 (32 GB)129.938931.95120.518052.15RTX PRO 6000 Blackwell124.840202.49117.919722.77H100 SXM (80 GB)113.928302.6986.912373.18RTX 6000 Ada (48 GB)82.824312.5190.416572.49RTX 4090 (24 GB)81.231242.9991.116452.58L40S (48 GB)74.428683.2481.815432.82A100 SXM (80 GB)73.913283.4354.77064.28L4 (24 GB, 72 W)29.87772.4232.14672.25笔记本Apple M5 Pro, Metal28.1387————读表要点README 的解释两种打包是真实的权衡PTQ1_0 每步少搬运 17% 的权重数据但解包密集 trits 需要算术开销——因此在内存是瓶颈的 Ada 世代与 L4 上胜出在 H100/A100/Blackwellbatch-1 decode 受指令吞吐与启动开销限制上落败。Prompt 处理是计算受限的PQ2_0 全平台占优。笔记本的意义不在速度比54 GB 的 FP16 基线根本装不进 M5 Pro关键结论是“27B 模型能在日常笔记本上交互式运行”。M5 Pro 实测 decode 流约 204 GB/s 权重证实了低比特表示所针对的内存带宽主导画像。能效对比M5 Pro 在 GPU 轨上 decode 功耗 27.5 WCPUGPU 合计 34.1 W而上表 NVIDIA 卡为 300–455 W 板卡功耗。Apple 行没有每 token 能耗因为两平台仪器测量范围不同nvidia-smi含 HBM/GDDRApplepowermetrics报告 CPU/GPU/ANE 而无 DRAM 轨。7.1 其他 Apple 平台预旋转构建当前栈待重测平台FootprintTG128 (tok/s)PP512 (tok/s)笔记本Apple M5 Max, Metal7.2 GB47.0765笔记本Apple M5 Pro, Metal7.2 GB28.7393笔记本Apple M4 Pro, Metal7.2 GB18.0125M5 Max 可达约 47 tok/sM4 Pro 上极长提示词的实际瓶颈是 prefill约 125 tok/s而非 decode。八、基准测试思考模式下的 14 项能力评估方法EvalScope vLLM统一在 NVIDIA H100 上、相同基础设施、解码与评分流程思考模式下测得该模式下模型完整推理被激活传统方法在 sub-4-bit 下的塌缩最明显。14 项基准覆盖六个技能类别“vs FP16”相对 Qwen3.8-27B FP16 参考比特宽度为真实平均。变体True bpwFootprintThinking avgvs FP16Qwen3.8-27B FP1616.054 GB86.32100%Qwen3.8-27B UD-Q4_K_XL4-bit5.217.6 GB85.1898.7%Qwen3.8-27B IQ2_XXS2-bit2.167.27 GB72.5984.1%Bonsai 2 27B1.725.95 GB84.7898.2%以 5.95 GB 的体积Bonsai 2 27B 比 sub-4-bit 的传统构建IQ2_XXS高出 12 分以上而体积只有其约 82%距 UD-Q4_K_XL 仅差 0.4 分而体积只有其三分之一。“平均分”掩盖了塌缩的形态传统低比特构建的退化是选择性的集中在需要持续推理链的基准上。IQ2_XXS 在 AIME26 只有 57.5、LiveCodeBench 只有 56.4却仍在 MMLU-Redux 拿到 88.93——这正是日常随手测试发现不了塌缩的原因。Bonsai 2 在同样基准上拿到 95.83 与 90.07。上一代 Bonsai 27B 报告在 Gemma-4-31B 家族上也呈现同一模式说明塌缩是方法属性而非单一基座模型的属性。8.1 按技能类别类别基准FP16Bonsai 2 27B知识与推理MMLU-Redux, MuSR85.5579.86数学GSM8K, MATH-500, AIME25, AIME2697.0696.57编码HumanEval, MBPP, LiveCodeBench89.0789.42指令遵循IFEval, IFBench81.2582.66Agentic / 工具调用BFCL v376.7474.92视觉MMMU-Pro, OCR Bench v271.3666.19总体14 项86.3284.78推理主干基本完整保留数学仅从 97.06 降到 96.57编码与基线持平指令遵循甚至略超基线。残余差距集中在最有难度的两类知识与推理、视觉。8.2 逐基准完整结果思考模式展开查看 14 项基准的逐项对比基准FP16UD-Q4_K_XLIQ2_XXSBonsai 2 27BMMLU-Redux91.4693.3588.9389.09MuSR79.6373.0166.9970.63GSM8K97.1996.6689.9096.66MATH-50099.8099.4084.6098.80AIME2596.6792.9166.6795.00AIME2694.5893.0057.5095.83HumanEval93.2995.7391.4695.12MBPP83.8683.8678.8983.07LiveCodeBench90.0587.9656.4090.07IFEval91.5088.8384.0391.31IFBench (prompt-loose)71.0065.6553.7674.00BFCL v376.7475.0570.2874.92MMMU-Pro81.7381.7365.1975.49OCR Bench v260.9965.4561.7056.88平均14 项86.3285.1872.5984.78九、智能密度Intelligence Density智能密度刻画“单位部署体积能换回多少能力”定义D -log2(1 - score/100) / size_GB变体体积 (GB)基准均分智能密度 (1/GB)Bonsai 2 27B5.9584.780.457Ternary Bonsai 27B上一代5.7580.980.416Qwen3.8-27B IQ2_XXS7.2772.590.257Qwen3.8-27B UD-Q4_K_XL17.5685.180.157Qwen3.8-27B FP1654.6686.320.053Bonsai 2 27B 的密度约为表中“最密”传统构建IQ2_XXS0.257的1.8x、FP16 的9x相对上一代 Bonsai 27B0.416提升 9.9%。注上一代行是在同一 14 项基准上重算的保证同口径可比。十、典型使用场景笔记本本地 27B Agent标准笔记本上约 28 tok/s 运行完整 27B 推理与工具调用262K 上下文支撑长文档分析、整库代码任务等依赖大工作集驻留内存的场景。隐私敏感与离线环境端侧执行从构造上保证提示词与数据不离开设备可在间歇性或无网络环境下工作。单 GPU / 消费级 GPU 服务单张消费级或入门级数据中心 GPU 即可获得 27B 级质量——RTX 5090 约 130 tok/s72 W 的 L4 约 30 tok/s——并为更大 batch、更长上下文或模型共存留出余量。质量优先的低比特部署以约九分之一的体积保留全精度模型基准均分的 98.2%。十一、已知问题与排查速查本仓库附带 KNOWN_ISSUES.md最近核验 2026-09-23覆盖PQ2_0/PTQ1_0/F16与 MLX 构建。以下为高频问题的速查现象对策空回答、或“一直思考不回答”给足输出上限-n 16384以上API 对应max_tokens配合-c 65536想缩短思考则发reasoning_effort: mediumreasoning_effort: high返回 HTTP 500改用xhigh默认或medium——模板不接受high在 AMD Zen 4/Zen 5 等 AVX-512 CPU 上加载崩溃用当前prism分支源码构建已在源码修复其他值得提前知道的运行时坑采样元数据min_p、presence_penalty、repetition_penalty均不在 GGUF 中需显式传入见第六节。工具调用工具arguments为空或非 JSON 时可能 HTTP 500/400无参调用请发{}系统消息必须唯一且置顶工具循环中不要向会话回写思维链会导致每轮重处理大部分对话、提示缓存失效。加载与平台CUDA 13.3 构建在某些系统崩溃Linux 用 CUDA 12.8、Windows 用 12.4 构建ROCm/HIP 在消费级 RDNA2 上中止可试 Vulkan 构建--split-mode tensor/row暂不能跨双 GPU 加载自己用llama-quantize量化普通模型到PQ2_0/PTQ1_0会产生乱码两类型仅对带prism.hadamard.*旋转元数据的导出检查点有效。性能KV cache 避免用q5_0改用f16/q8_0/q4_0单用户服务建议-np 1 --cache-ram 24576避免长对话反复重算 prompt--spec-type ngram-*对此模型无效果。视觉小图“指物/接地grounding”类任务效果差时以--image-min-tokens 1024启动服务器。十二、限制声明质量与体积的权衡三元模型保留全精度均分的 98.2%差距适中且可预测——推理核心数学、编码与基线相差仅数分差异集中在最具难度的类别。原生低比特内核仍在演进密集 PTQ1_0 打包1.75 bits/weight5.95 GB已可用但解包 trits 消耗算术——它在 Ada 级及更小加速器上更快在 Ampere/Hopper/Blackwell 上更慢这些平台上 batch-1 decode 并不受带宽饥饿“在每个目标上都把体积优势兑现为延迟优势”是正在进行的工程目标。十三、许可与引用本仓库以 Apache 2.0 发布LICENSE派生自 Qwen3.8-27B同样 Apache 2.0见 NOTICE.txt。公开部署或再分发时建议注明 Created using Bonsai by Prism ML.。若在研究中引用 Bonsai 2 27B推荐techreport{bonsai2_27b, title {Bonsai 2 27B: A 27B Ternary Reasoning Model}, author {Prism ML}, year {2026}, month {September}, url {https://prismml.com} }进一步阅读本仓库内的 README.md本文主体文档、KNOWN_ISSUES.md问题与 workaround 全集、LICENSE 与 NOTICE.txt许可信息模型运行脚本与多后端方案见官方 Bonsai-demo 仓库README 明确其为运行这些模型的唯一事实来源。赞分享人工智能大模型模型量化模型压缩本地部署【免费下载链接】Ternary-Bonsai-2-27B-gguf项目地址https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-gguf点击查看免费下载相关推荐破解三元比特流Ternary-Bonsai-2-27B-mlx-2bit的PTQ1_0/PQ2_0到MLX 2-bit无损转码算法详解破解三元比特流Ternary Bonsai 2 27B mlx 2bit的PTQ1_0/PQ2_0到MLX 2 bit无损转码算法详解 在开源项目 Terna大模型模型量化本地部署模型优化推理模型人工智能PQ2_0还是PTQ1_0Bonsai 2 27B打包格式横评基于9款真机测速的硬件选型攻略PQ2_0还是PTQ1_0Bonsai 2 27B打包格式横评基于9款真机测速的硬件选型攻略 Bonsai 2 27B 是 Prism ML 推出的三值t人工智能大模型模型量化模型压缩本地部署如何在NVIDIA GPU上运行Ternary-Bonsai-2-27B-mlx-2bitGGUF双打包与定制llama.cpp部署完整指南如何在NVIDIA GPU上运行Ternary Bonsai 2 27B mlx 2bitGGUF双打包与定制llama.cpp部署完整指南 Ternary大模型模型量化本地部署模型优化推理模型人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考