单卡部署的新选择：从Qwen3.8到Bonsai的演进

本次测试的核心对象是Prism ML推出的Bonsai 2 27B模型。该系列本质上是Qwen3.8 27B模型的极简化版本，其最大卖点在于能够在12GB或16GB显存的单张GPU上运行。这一特性极大地降低了本地AI部署的门槛，使得无需昂贵硬件的用户也能体验高性能模型。作者指出，虽然之前已测试过基于Qwen3.6的Bonsai版本，但鉴于Qwen 3.8相比3.6在能力上的巨大飞跃，新版本Bonsai预计也能保持这种性能优势。为了直观对比不同量化版本的效果，测试将采用双窗口并列运行（Side-by-side）的方式，分别展示不同压缩率下的模型表现。

量化版本对比与显存占用分析

Bonsai 2提供了两种主要的量化版本，旨在平衡文件大小与信息保留率。原版Qwen3.8的FP16权重高达54 GB，而Bonsai 2通过压缩技术将其大幅缩减。其中，PTQ 1.0版本将权重打包得更小，文件体积仅为5.9 GB；而PQ2_0版本则保留了更多信息，文件体积为7.21 GB。官方宣称该模型保留了FP16版本98.2%的智能水平，但作者提醒需理性看待这一数据。查阅白皮书可知，在编程和智能体（Agentic）相关基准测试中，模型实际保留了约3/4（75%）的全精度性能。尽管存在差距，但在如此显著的体积缩减下仍保留四分之三的能力，被认为是该模型最引人注目的地方。

显存优化策略与实验环境配置

为了在有限资源下实现更长的上下文窗口，测试中启用了FP16 KV Cache（实验性功能）。这一设置虽然可能导致质量轻微下降，但能将10万Token上下文窗口所需的显存从6.3GB降低至约1.8GB，对于内存受限用户至关重要。此外，如果不需要视觉功能，可以移除Vision能力以进一步节省开销。测试环境使用了一块RTX 6000 Pro显卡，该卡因价格波动曾以半价购入。在具体的测试设置中，左侧窗口运行的是1.75 BPW（约5.9GB）的小版本，右侧窗口运行的是2.13 BPW（约7.2GB）的大版本。作者特别提到，早期模型常存在“不知道何时停止”导致过度冗长的问题，因此本次测试将重点观察其输出控制能力与智能体任务的执行效率。

浏览器OS生成测试：陷入死循环与过度思考

在初步尝试让模型编写复杂的“浏览器操作系统”代码时，无论是较大还是较小的版本都未能成功完成。测试过程中，模型表现出明显的实验性不稳定特征，光标闪烁后并未出现预期的加载动画，而是陷入了反复重写整个文件的死循环。作者指出，这种过度思考（overthinking）的行为导致任务彻底失败，甚至无法完成基本的代码写入。> “Neither of them did fully successfully finish writing... it's going to try to rewrite the entire thing again, which is just not what we want.” 这一结果让作者对模型的能力持悲观态度（not feeling very bullish），认为之前的宣传可能存在过度概括的问题。为了验证模型是否具备基本的代码输出能力，作者决定降低任务难度，转而要求生成一个简单的“Steve的电脑维修网站”页面。这一调整旨在排除复杂逻辑干扰，仅测试模型能否在无循环、无死锁的情况下输出有效代码。

简化网页任务：语义理解与基础功能验证

在简化的“Steve的电脑维修网站”测试中，两个模型均成功生成了HTML代码。较大版本在生成过程中展现了链式思考（chain of thought）能力，能够自我检查语法错误并修正。最终生成的网页虽然设计简单，但内容完整且通过了语法检查。值得注意的是，模型在文案中展现了良好的语义理解能力（semantic understanding），例如生成了这样一段用户评价：“我女儿三个月无法启动笔记本电脑... Steve拆下旧硬盘，修复BIOS，40分钟内让其重启。她还在用，而我因浪费买新电脑的钱感到恼火。” 这段内容不仅逻辑通顺，还准确捕捉了“修复旧设备”与“购买新设备的浪费感”之间的因果联系。> “Your PC is slow. Bend it back... I'm still annoyed I wasted the new one.” 尽管较小版本在生成过程中曾出现行数激增（超过5,500行）的异常现象，但经过人工干预添加闭合标签后也能正常渲染。这一阶段验证了模型在低复杂度任务下的可靠性（safe to proceed with a little more complexity），为后续更复杂的3D游戏生成测试奠定了基础。

C++滑板游戏开发：Raylib库缺失与运行崩溃

进入更具挑战性的C++ 3D滑板游戏生成环节，作者特意简化提示词为“创建简单的3D滑板游戏”，并强调不要过度思考。测试发现，两个模型均未使用Raylib库（一种常用的C++游戏开发库），而是尝试用原生代码实现。较大版本虽然编译通过，但程序窗口瞬间打开后立即关闭（opens and closes real quick），表明存在运行时错误。较小版本同样面临编译后的闪退问题，但在多次尝试后，作者发现通过手动点击或等待可能触发渲染。最终，较小版本成功运行了一个纯原生C++实现的3D场景（raw C++），尽管画面简陋且操作不稳定。> “It just opened it itself there... we got one working one.” 这一结果证明模型具备生成基础3D逻辑的能力，但缺乏对现代游戏引擎或库的依赖管理能力。作者不得不中断较小版本的测试，因为其陷入了无意义的文本生成循环中。尽管结果不尽如人意，但至少有一个可运行的实例（one reasonable thing）证明了模型在特定约束下的可用性。

Blender MCP集成测试：多实例并行与场景构建

最后，作者尝试利用MCP（Model Context Protocol）让模型控制Blender进行3D场景构建。测试环境配置了两个独立的Blender实例，分别运行在不同端口上。提示词要求模型创建一个城市街区场景、渲染图像并保存至工作目录。这一测试旨在评估模型在多任务并行处理（separate ports）和外部工具调用方面的能力。虽然字幕片段在此处结束，未展示最终渲染结果，但测试架构本身展示了Bonsai 2模型在复杂工作流集成（complex workflow integration）方面的潜力。通过分离实例，作者试图避免资源冲突，观察模型是否能独立规划并执行从场景搭建到渲染输出的完整链条。这一阶段的测试重点在于系统稳定性与工具调用的准确性（system stability and tool invocation accuracy），而非单纯的代码生成。

图像渲染与坐标定位能力对比

测试首先评估了 Bonsai 27B（大模型）与其较小版本在图像生成及自我审视方面的表现。大模型成功渲染了建筑内部墙壁的特写，并利用多模态能力识别出相机位于室内，甚至给出了相机的坐标数据。尽管生成的图像包含天空或其他非预期元素，导致其自我纠正认为结果不正确，但这被视为一个积极的步骤。相比之下，小模型虽然也完成了渲染任务，但其生成的图像被描述为“平坦的灰色”，且判定相机正对着虚空。这表明小模型在场景构建和语义理解上存在明显缺陷，而大模型至少具备初步的场景感知与坐标映射能力。

Blender 3D场景构建任务执行结果

随后，测试要求两个模型使用 Blender 创建城市街区并放置相机。两者均成功完成了任务，但质量差异显著。大模型生成的场景色彩丰富且包含绿色植被，尽管建筑物存在悬浮在空中的物理错误，但其美学风格（如可见的三角形结构）获得了认可。小模型则生成了一个较为简单的城市街区，虽然功能完整但细节较少。总体而言，两个模型都成功利用 Blender 完成了基础任务，证明了其在特定工具链上的可用性，尽管大模型在视觉表现力上更胜一筹。

Subway FPS 游戏开发测试与调试困境

接下来是更具挑战性的《地铁》第一人称射击（FPS）游戏开发测试，包含敌人波次和列车机制。由于大模型运行时间过长（约1.5小时），测试者强制停止并要求直接交付代码。小模型在运行后生成了前端界面和多种武器指令，但无法进入实际游戏环境。测试者使用 Claude 辅助修复小模型的脚本错误，结果显示虽然能加载出一个相对合格的3D场景，但游戏循环完全失效且按键无响应。对于大模型生成的脚本，Claude 修复了大量语法错误后尝试运行，但仍出现大量其他报错。由于需要额外模型进行过多修补才能勉强运作，该测试被判定为失败。这揭示了当前大模型在生成复杂、可玩性高的完整游戏代码时，仍存在严重的逻辑连贯性和调试依赖问题。

手表展示网站生成的美学与功能缺失

最后的测试是创建一个包含3D模型、电影级平移效果和爆炸视图的手表展示网站。两个模型均在规定时间内完成了网页生成，且整体结构优于之前的“Steve the PC repairman”案例。小模型生成的网页悬停效果良好，外观尚可；大模型则生成了精美的UI元素。然而，两个网站的核心缺陷一致：均未实际显示3D模型。尽管大模型的UI设计与3D展示位匹配度高，但模型本身缺失。测试者认为这是预期的失败点，并计划在中度推理努力下再次尝试。虽然网站在美学选择上值得尊重，但由于缺乏核心的3D交互功能，最终结果被视为“功能性不完整”。

图像转SVG的视觉推理测试

博主首先进行了一项基于图像的矢量图生成任务，要求模型将一张手持“Quendall”玩偶的照片转换为SVG格式。测试中对比了两个不同规模的Bonsai 2模型，均设置为中等推理强度（Medium Reasoning Effort）。较大的5.95 GB版本模型在初期表现出较强的视觉捕捉能力，能够识别出麦克风支架、防喷罩以及背景中的木条墙等细节。博主指出，尽管模型在头发发际线处理上略显乐观（“did give me a pretty favorable hairline”），且Logo还原尚在进行中，但整体完成度在中等推理强度下已属不错。相比之下，较小的模型版本生成的SVG结果更为惊艳，细节处理更加精准。博主在观察后坦言：“I would have to go out on a limb here and say that I think the smaller one did a better job with this to be honest with you.” 这表明在该特定视觉任务中，较小参数量的模型并未因算力限制而表现逊色，反而展现了更优的构图与细节还原能力。

3D滑板游戏的代码生成挑战

在视觉测试后，博主转向了纯代码生成能力的评估，要求模型在一个HTML文件中构建一个简单的3D滑板游戏。为了排除过度思考导致的延迟，博主特意强调“不要尝试测试它”、“保持简单”。两个模型在中等推理强度下均迅速完成了代码编写，速度远超以往的高推理模式。然而，初始结果并不完美：较大模型生成的版本虽然能注册游戏状态（如收集金币），但缺乏实际的游戏交互反馈；较小模型则直接提供了可运行的基础框架。博主对较大版本进行了针对性反馈，指出其存在的问题。经过一次迭代修复后，模型成功输出了包含完整玩法的3D游戏。博主对此表示满意：“Look at that. That is actually, you know, I am okay with this.” 游戏不仅实现了滑板动作，还加入了收集金币等元素。博主认为，这种“简单直接”的指令策略是成功的关键，而模型能在中等强度下完成此类复杂逻辑构建，已具备前沿模型的潜力。 > “I think really including and driving home like make it simple. Don't try to worry about like play testing it too much, I think that may be the difference a lot of times in using these between success and failure.”

云端服务对比与最终评价

最后，博主通过Alibaba Cloud在Open Router上部署了同一模型（Medium Thinking Effort），以对比本地测试与云端服务的差异。云端版本的表现被评价为“更加胜任”（more competent），且具备更丰富的动作细节。博主观察到云端模型能够执行“kick flip”（踢翻）等复杂技巧，尽管操作键位尚未完全掌握。虽然云端版本缺少本地测试版中那种独特的“金币收集”玩法风格，但其在核心滑板机制上的稳定性更强。博主总结道：“This is definitely a bit more competent.” 综合来看，无论是本地小模型的视觉优势，还是大模型经反馈后的代码修复能力，亦或是云端服务的稳定性，Bonsai 2在单卡环境下展现出的综合能力令人印象深刻。博主认为，这种性能水平在过去仅属于最前沿的模型（Frontier state-of-the-art model），如今在中等推理强度下即可实现，标志着显著的进步。

性能对比与市场预期的落差

本次测试的核心在于将 Bonsai 2 模型与同一推理强度（medium reasoning effort）下的完整版大模型进行直接对比。评测者指出，尽管社区关注度极高，但实际测试结果并未完全印证宣传中“能力仅差毫厘”的说法。虽然 Bonsai 2 在体积上实现了大幅缩减，但在性能表现上并未达到宣传所暗示的近乎等效水平。这种营销话术实际上损害了该模型真正的技术亮点。评测者认为，过分强调其与顶级旗舰模型的微小差距，反而掩盖了其作为轻量化模型的独特价值和技术成就。这种宣传策略让公众产生了一种误解，即它只是旗舰模型的廉价替代品，而忽略了其在特定场景下的独特优势。

技术优化与极致压缩潜力

尽管性能对比结果存在落差，Bonsai 2 的技术架构依然令人印象深刻。评测者强调，该模型具备极高的压缩灵活性。除了基础的结构优化外，还有更多进阶的优化空间等待挖掘。例如，用户可以进一步采用 4-bit KV cache 技术来显著降低显存占用；此外，如果应用场景不需要视觉理解能力，还可以直接移除模型的视觉组件。这些优化手段使得 Bonsai 2 能够被压缩至极小的体积 footprint。这种灵活性意味着开发者可以根据具体的硬件限制和应用需求，在性能与资源消耗之间找到最佳的平衡点。这种可定制化的压缩能力是 Bonsai 2 区别于其他固定规模模型的重要特征，也为边缘部署和低资源环境下的 AI 应用提供了更多可能性。

核心能力验证与未来展望

在功能层面，Bonsai 2 的表现超出了评测者的预期。该模型不仅能够生成清晰且可执行的代码（lucid code），还能有效进行工具调用和函数操作。更令人兴奋的是，它在长上下文窗口中能够稳定地在智能体（agentic）框架下运行。评测者对此表示高度赞赏，认为这些能力证明了该模型在复杂任务处理上的成熟度。对于市场上将其简单类比为“家用版 Opus”的观点，评测者明确反对，认为这种类比低估了 Bonsai 2 的技术独特性。它并非简单的缩小版，而是一个在特定优化路径上取得突破的独立产品。评测者表示将继续深入测试 Bonsai 系列模型，并提到社区中有人建议将其与 Qwen3.8 Flash Next 等模型进行对比测试，这将是下一个极具价值的研究方向。目前评测者正在使用相关模型构建应用，并期待看到更多来自该实验室的创新成果。

结论

Bonsai 2 27B在单卡部署上实现了显著突破，能在16GB显存下运行并保留FP16版本约75%的编程与智能体能力。其优势在于极高的压缩灵活性与中等推理强度下的代码生成稳定性，尤其适合低资源环境。然而，测试揭示其在复杂逻辑（如完整游戏开发、多工具并行）中仍存在过度思考、循环死锁及依赖外部调试等短板，视觉与3D渲染质量也逊于旗舰模型。它并非“近乎等效”的廉价替代品，而是具备独特价值的轻量化解决方案，适用于对显存敏感且任务复杂度可控的场景。