好的，现在没事了。我讲完了。今天我们要来看看新发布的 Bonsai 270亿参数模型，这些非常有趣。它们来自 Prism ML，我之前已经介绍过这个 Bonsai 家族中的一些模型。本质上，这些是对原始模型的巨大规模缩减，这里的基准是 Qwen 3.6 27B模型，它通过几种不同的方式被缩小了，具体取决于您希望将其部署在哪个特定的目标设备上。
因此，在该公告帖子中，他们提到了在这台电脑上运行它，无论是 Linux 电脑、PC还是其他设备，或者是 Mac。此外，他们还讨论了在手机上运行这些模型的情况。具体来说，他们提到对于 iPhone 17 Pro，它能够以不错的速度运行。我目前在这台 Asus ROG Phone something Pro上正在运行它。因此，我们不仅将能够检查专为 PC 设计的模型的性能，还将能够查看在手机上运行的那个。
事实上，我都在这里设置好了这两个并正在运行。所以这个是在 PC 上运行的模型，正如我们可以从令牌速度推测的那样。而这个标签页里的是在移动手机上运行的那个。所以，通过 Llama server 的网络聊天界面与运行在我笔记本电脑旁边的手机上的东西进行对话，这实际上挺酷的。在我们深入之前，请随时订阅以让我获得那个 10万粉丝奖牌。
就此而言，让我们先快速看一下今天这些 Bonsai 模型的选项。Bonsai 27B有两种变体。第一种是三元 Bonsai 27B，这就是在这个标签页中端口8080上以每秒约65个令牌速度运行的那个。这是一个更聪明但更大的 Bonsai 模型版本，它使用三元权重和 FP16 组缩放，每个权重的有效位数为1.71。
大小为5.9 GB，这是注重质量的变体。它可以在日常笔记本电脑上运行，具备完整的推理、工具调用和智能代理能力。因此，在进行一些比较时，我们主要想看看这个特定的三元模型如何与其基于的 FP16 版本 Qwen 3.6 27B相比。这个 Bonsai 27B的下一个模型版本是1位（1-bit），这是在手机上运行的那个，我们可以看到它在端口8081上运行得有点慢。
然而，它使用具有相同组缩放的二进制权重，每个权重的有效位数为1.125，大小为3.9 GB。因此，考虑到它基于的 Qwen 模型的全精度权重如他们在此处所说的那样是54 GB左右时，这是一个巨大的规模缩减。所以它可以容纳在 iPhone 17 Pro的内存预算内，首次将270亿参数级别的模型带入手机。
我不知道我是否要说“第一次”，基于我几个月前发的这条 X 帖子，但无论如何，我只是在开一点玩笑。所以我不想深入探讨这些模型如何工作的技术细节，因为它们非常复杂，我不确定在尝试解释时会有多大帮助。不过我要说的是，在这个公告帖子底部，他们有一个指向其白皮书的链接，它将在 GitHub 中为您打开，您可以去查看一下。
其中包含更多复杂的信息。不，他们具体用于缩小这些模型规模的方法并不是开源的。所以也请注意这一点，但它确实告诉了你这里发生的一切的一些更相关的信息。此外，快速提及一下，我可能有点生疏了，但根据我之前制作关于他们模型的视频的记忆，本质上，权重被缩小为128一组，无论是三元还是二进制，然后这组128个权重有一个块缩放因子是 FP16，我相信是这样。
再次强调，不要完全相信我的说法，但基本上他们取像128个权重一组这样的组，并根据具体是哪个模型变成三元或二进制。然后对每组128个权重应用一个比三元或二进制更高精度的缩放因子。嗯，大概就是这样。现在这些模型在 Hugging Face 上以多种不同格式提供，这里还有一些其他有趣的事情需要注意。
他们还附带了兼容的推测解码设置，因此正如我们在此处所见的那样，它将加速 CUDA 服务路径上的1.34倍解码速度。此外，他们向 MLX致敬，因此 Apple 设备也具有兼容性。现在 Hugging Face模型卡中也包含一些有趣的事情，因为我发现对于这些模型来说，有时会很令人困惑，比如，“好吧，如果模型是5.9 GB，那么如果我在这里打开 NVTop，为什么我的电脑要使用10.7 GB来服务这个模型？”
他们提到并解释了这一点，有几种不同的方式。其中之一是内核以比理想大小（即5.9 GB）稍大的空间存储三元值。所以他们说的部署大小约为7.2 GB。此外，就为什么这比人们预期的甚至包括部署规模使用了更多的权重或 VRAM 而言，他们在这里有一个图表，显示了该模型在不同上下文长度下的实际内存占用情况。
因此我们可以看到，对于这个我们正在运行的模型，10K 上下文大约需要8.7 GB的 VRAM，而100则会上升到14.7。所以请记住这一点，如果您想在绝对完整的26万以上的上下文中运行它，它会比这更高。所以请记住这些不会使用那6 GB的 VRAM来运行这个27B模型，但这已经是迈向那里的一步了。
所以我想要做一个非常恰当的比较测试来展示这些模型，因为很多人的兴趣在于它们实际上如何与这个模型的原始全精度版本相比。因此在这个标签页里，我们正在运行该模型的二进制版本。这完全在手机上运行，手机只是连接到这台电脑上以便获取电源等东西。给定一个非常简单的提示。
在中间的标签页里，这是在控制整个演示的笔记本电脑上运行的。这是一台5090移动版笔记本，它使用的是该模型的三元版本。所以更
正如我们在此所见，这是最具性能的表现形式。中间选项卡使用的是三元模型（ternary），最左侧选项卡使用的是二进制模型（binary）。而在最右侧，运行的是该模型的完整精度版本。它未经过任何量化处理，并且是在我身后的计算机上通过 RTX 6000 Pro Blackwell GPU 运行的。因此，我们将能够看到这两个 Bonsai 模型版本以及完整的全精度原始模型的并排对比结果。这样，我们可以通过观看这些演示获得更多的教育价值。
对于第一个测试，我已经禁用了所有模型的推理功能（reasoning），因为手机端的运行速度极慢。在 Blackwell 上运行的版本虽然不算特别慢，但有时也会花费相当长的时间；而在这台计算机上运行的版本则相对较快。我没有使用随附的 MTP（推测为某种加速或辅助工具）功能，虽然那会加快一些速度，但此刻我们只查看针对简单的“Steve's PC Repair”网站生成的结果。
好了，所有简单网站的对比测试已经结束。我必须说，我有点后悔选择在手机上运行 1-bit 二进制模型，因为生成这个网站花费了将近 3 个小时。在该结果的最高总 token 数下，整体速度为每秒 1.56 个 token。也许我们不必过于关注该特定手机和模型的速度指标。尽管如此，中间选项卡中的三元版本在 5090 Mobile GPU（未使用额外的草稿模型）上运行，耗时 4 分 23 秒，速度为每秒 58.68 个 token。
最后，我们拥有完整的全精度版本，它在 RTX 6000 Pro Blackwell（非 Max-Q 的非功率受限版）上以每秒 28.73 个 token 的速度运行。由于该版本生成的 token 数量显著较少，我需要确保采样参数设置正确。不过我已经保存了所有结果，让我们来看看它们吧。首先从二进制版本开始，我想先感受一下最小规模模型的效果。
说实话，对于 1-bit 二进制版本来说效果并不差。这实际上在视觉上相当美观。是的，其中有一些奇怪之处，比如随机散布的“受超过 10,000 名客户信赖”字样，这相当令人印象深刻。按钮具有悬停效果。你有没有注意到这些指标在达到最终数值时产生的动态效果？那其实相当不错。卡片也具有悬停效果。“Steve 的电脑维修，15年专家”，理想情况下这里应该是 Steve 的照片。还有“预约”、“我们如何修复您的电脑”、“客户评价”和“透明定价”。
这些定价卡片看起来相当不错。“准备好修复您的电脑了吗？”我们还有一个干净美观的联系信息卡。页脚也做得很好。好吧，这挺酷的。我的意思是，整个网站都是仅使用运行该模型二进制版本的手机生成的，这非常棒。尽管如此，让我们现在看看三元版本（中间选项卡），它是中等智能和规模的模型。
哦！我们会注意到 throughout 过程中存在相似之处，因为它们是同一个模型，但在“努力程度”上有所不同。这个版本仅显示“受 2,000 名客户信赖”，而不是超过 10,000 名，所以这里的 Steve 是一家规模较小的企业。背景中实际上有一些交互式粒子效果。这里有悬停效果，以及一种更偏向霓虹风格的合成波美学（synthwave aesthetic），我个人非常喜欢。
我们的定价卡片……哦不，这些只是服务及其具体价格。还不错，悬停效果很好，并且它们都具有一定的透明度。“关于我们”，成立于 2009 年。好吧，我不知道为什么突然想到这个，但作为一个随机的旁注：很久以前，我一直以为“EST”的意思是“估计”，我总是想：“他们怎么不知道这些企业成立的具体日期？”后来我才意识到它代表“Established”（成立于）。这澄清了我的疑惑。只是一个小旁注而已。
我们有一个外观良好的简单维修流程页面。我在寻找像二进制版本那样美观的定价卡片，但我们只有虚假的客户评价，这很好。好吧，页面一直滚动到联系信息卡结束。有趣的是，没有……页脚看起来不错。“用爱与咖啡设计”。另一个版本则是“用爱与焊锡设计”。
最后，再次强调我需要检查采样参数，因为这个版本的总体生成长度相比其他两个版本显得过于可疑地短。天哪。好吧，这是全精度版本。“Steve 的电脑维修”，系统优化，“启动修复”。悬停效果良好。服务模块，它们都有类似的内容。“已修复 2000 台系统”。所以这个版本的统计数据与三元版本相同。
现在，有些不对劲。不可能吧？肯定有什么地方出错了，因为全精度版本不应该表现得这么差。接下来，我为所有模型启用了思考（thinking）功能。我认为我们之前观察到的行为——即全精度版本的模型实际上生成了更短的脚本——是因为当时关闭了思考功能。因此，有可能 Bonsai 模型为了保留其智能，在训练过程中被赋予了包含大量美观元素的前端示例，这或许可以解释为什么它们生成了更长的内容。
不过别引用我的话，我只是想提供一些思考，关于这是否是正常行为。现在开启思考功能后，我希望我们能看到全精度模型在此方面展现出更有利的差异，但这会更具挑战性，并为我们提供更有趣的演示。这当然是一个 3D 地铁站第一人称射击测试。二进制和三元模型都在这台搭载 RTX 5090 Mobile GPU 的笔记本电脑上运行。如果速度不快，是因为它同时处理这两个模型。
全精度版本则在 RTX 6000 Pro Box 上运行，所以我们会稍后看到结果。不过我很高兴看到一点，这也是我有点担心的：较小模型是否会倾向于过度思考（overthink）。幸运的是，我们没有看到这种情况。推理过程实际上相当简洁，这确实是一个风险点。
我相信吧，好的，我刚看到你已经死了。好吧，这很好。很高兴看到这些模型没有过度思考太多。好的，让我们从二进制地铁FPS开始吧。好吧，地铁站生存感染危机。现在，鼠标一进入页面就消失了。有时发生这种情况时，我们只需要找到“进入地铁站”按钮，它仍然会让我们进去。所以，我们先暂时搁置这个。让我们看看三元版本模型吧。好的，地铁站僵尸版。同样的奇怪光标故障问题。以及开始按钮完全无法工作的同样彻底失败的情况。好吧，这比我预期的要快得多。最后，让我们尝试全精度版本，希望它不像那些那样是一场灾难。哦，好的。好吧，所以是的，这个
确实有点令人印象深刻哇，这相当不错。这个模型真的可以说是远超其性能预期，程度非常高。至少在我的测试中是这样。好的，我们遇到了一些相当严重的延迟问题，但这没关系。这台电脑目前确实拥有大约20GB的显存等一下。好的，所以这是唯一真正起作用的一个。肯定向我们展示了一些差异。实际上，看看这些
这些模型甚至没那么糟糕。这个模型从未让我失望过。有传言说可能会有Qwen 3.8发布，别引用我的话，但这对我们本地爱好者来说将是非常令人兴奋的。很好。好吧，所以让我们看看这些模型具体有哪些错误。好的，那个只是语法错误，那是三元版本。让我们检查二进制
版本。它也有一个语法错误。所以，这两个模型都似乎有点问题，而16位版本显然没问题。好的，接下来我们将尝试使用这些模型进行代理式编码测试，因为我想知道我们会得到什么结果。我认为这将比我们要做的单文件零样本生成提供更多见解，尽管那些
也很有趣。然而，我将仅基于二进制和三元这两个模型在地铁FPS测试中出现的错误来进行我们的代理式编码测试。所以，我将把它们各自生成过程中显示的具体错误提供给他们，从二进制模型开始，我们遇到了这个未捕获的语法错误，看看它会怎么做。我需要修改它。那
目前是三元版本。所以，如果我们进入模型设置，我确实已经在这里配置好了所有配置文件。而且我没有特别告诉它脚本在哪里，因为它在专用目录中，只有该脚本在那里。所以，这本身也是一个额外的测试，看看它是否理解：好的，我需要修复在这个目录中运行的脚本中出现的问题。忽略
那个Q1术语吧，那对于我们要表示的方式来说并不一定准确。在第953行找到了问题。哦，然后它在之前已经修改过了。是的，好吧。那很可能能解决问题，假设除此之外没有其他错误了。好的，它正在压缩大量数据。它以64K上下文长度运行，但目前我们暂且假设因为它似乎
确实解决了那个问题。好的，所以我们不幸地又遇到了另一个错误。但至少它修复了之前出现的问题，至少这个问题不再在这里出现了。好吧，所以我把上下文长度最大化到262144，并从同一个目录中重新打开它，使用相同的模型，并给它新的错误信息，我们看看。我
担心我们可能只是一遍又一遍地处理一堆错误，就像它之前做的那样修复一个，然后出现另一个，然后我们必须再修复那个。但无论如何，我们会给它一些时间，看看能否让它达到功能正常的状态。那非常快。所以让我们刷新一下。好的，我们又有另一个错误了，就像我说的，我确实有些担心它
可能最终只是一堆这样的过程，但我们会坚持直到不能再继续为止。我要说的是，即使我们不能让它达到功能正常的状态，看到它能识别这些错误并快速修复它们，而且没有陷入循环或过度思考，我觉得这相当令人印象深刻。好吗？
好的，我们没有任何错误了。很好。它让我们达到了实际上可以进入游戏的程度。现在，是的，它还不完全起作用，我们现在遇到了更多错误，但关键是它让我们跨过了第一个障碍，我很高兴。所以我会继续粘贴这些错误进去。理想情况下，我认为最好的做法是告诉它：“好吧，听着，我受够了粘贴
这些错误了。我需要你为自己构建一个小管道，以便你可以自主地从开发者工具中提取这些错误，修复它们，然后再次测试，然后再修复，再迭代，直到它不再给我们报错为止。”还没有错误。好的。所以看起来这可能就是我们要结束的地方了。如果我们实际上重新启动它，看右上角，让我暂时关闭
开发者工具。你会看到我们的弹药从50开始，如果我把扬声器音量调到最大，然后点击一下，它会降到49，我们会听到声音。不幸的是，之后似乎什么也没发生。尽管如此，它确实把我们带到了一个修复所有问题的阶段，而剩下的问题是实际游戏实现中的问题，而不是仅仅通过
开发者工具控制台就能显示给我们的东西。所以我对在那里看到的结果感到满意，而且它确实处理了来自同一线程的许多不同错误，没有惊慌失措也没有开始过度思考。它是一个一个修复它们的，考虑到这是什么情况，我认为这相当令人印象深刻。好吧，接下来我在Open Code中加载了三元
模型，这是使用131K的上下文长度变化，因为呃，我觉得在这里不需要达到完整的那个。此外，它也会耗尽显存。我忘记实际上告诉它“修复这个错误”了。我只是把它粘贴进去了，但情况是一样的：它只在一个包含特定
脚本的存储库中。所以它很可能会理解：“好的，我需要基于这个仓库或文件夹中的内容来解决这个问题。”找到错误并修复了。我猜可能还会有几个，大概吧。我需要记得我把文件夹移动过了。好的，现在没有了。
我完成了。 >> [笑声] [喷鼻息声] >> 嗯，那真是不愉快。好吧。我的意思是，是的，我们哦，哇。好的。呃，嗯，我只是要把它粘贴进去，因为坦率地说，如果没有可能使用不适合这个平台的语言的话，我甚至找不到词语来描述这里的具体问题。所以让我们看看会发生什么。尽管如此，它确实有一个
特定的错误，然后它修复了该错误。我们确实让游戏运行起来了。因此，与二进制版本相比，这是一个更快且更完整的结果。嗯，但也更加突兀和令人焦虑。好吧，不幸的是，我们似乎在这里遇到了一点僵局。尽管如此，我对我们所看到的结果感到满意，因为它确实修复了那个阻止游戏实际显示的单一错误，而且这个游戏比一比版本更具可玩性。所以，这非常恰当地展示了：一比版基本上什么都没做；三元版勉强能运行；而全精度版本考虑到其体积，可以说是非常出色的。
因此很有趣，我想在二进制和三元版中加入一些智能体编码（agentic coding），看看它们能否处理开源代码，结果是可以的。好吧，接下来我做了一点不同的尝试，但我知道大家经常想知道这些模型在处理现有代码库时的表现。所以我让它们各自访问一个简单的扩散演示项目，其中本质上是一个键盘的3D模型，以及一个小型训练好的扩散模型，用于预测潜在的键盘布局（如QWERTY、德沃夏克等）。我曾在我的Gemini扩散模型视频中使用过它。
这里的提示主要是让它们在隔离副本中通过开源代码回答关于此特定代码库的一些问题，使用相同的采样参数，并向它们提出一些针对该仓库的具体问题，然后根据质量和深度对它们的回答进行评分。显然，它们全部通过了五项测试中的五项。然而，在实际提出的具体问题以及出现错误答案的地方，我们有一些更细粒度的细节需要分析。让我们逐一查看每个问题的详情。
第一个问题是描述从训练到浏览器的完整流程，以及当导出的权重验证失败时会发生什么。这是我们的预期答案：在HUD中报告故障，演示继续在精确分析基础上运行。所以，确切地说这里有一个回退机制，它会模拟拥有正确训练模型时的情景，这正是我们要找的答案。完整的链条还识别出了正确的行号以及超出评估标准之外的单独获取故障回退路径。
这是Qwen 27B模型的全精度版本。三元版完整的链条包括确切的HUD故障消息，没有错误的预测，只有回退调用JS引擎。200行源代码注释为100个琐碎内容，而二进制版正确的链条和最大错误阈值。回退正确但关于UI报告的内容细节最少。所以，所有这些实际上都答对了，这很有趣。
第二个问题：确切有多少训练序列？它们是什么？64的批次是如何构建的？预期答案是恰好四个序列，即通过torch随机整数以替换方式采样的40字符布局字符串到64行。每行独立获得每个位置最多此掩码，并强制执行该掩码位置的概率。所以，BF16引用了所有四个确切字符串，描述了钳制（clamp）但略有错误。这里的钳制创建了一个点质量，而非均匀分布，仅建模以做出足够精确的错误声明。
有趣的是，三元版引用了所有四个确切字符串，注意了一个质量守卫和一个T等待，但没有提到钳制。好吧，这些……我是说，这不一定是我衡量事物的最佳方式，但对于这类模型来说，看看这一点很重要。二进制版命名了四种布局，没有引用字符串，得到了以替换方式采样、质量守卫。好吧，所以它们总体上都答对了这很有趣，但有趣的是全精度版本仅建模以做出足够精确的错误声明。
第三个问题：为什么probs在提交循环内重新计算？没有它会破坏什么？JS在哪里处理它？预期答案是祖先采样，每个提交的令牌必须条件化后续值采样。模型是双向的，拒绝步骤硬边缘，让我们从不相容的布局中进行位置采样，产生不连贯的输出和演示的确切后验归零。JS对应部分然后我们在这里有一些额外信息。
BF16：教科书式答案，正确的引用。很好，明确命名了提交键（commit key）。三元版：正确的机制并唯一地命名了提交键，额外添加了磁盘缓存基于提交状态进行密钥设置，因此自我失效。这是真实的且超出评估标准，但引用了第304行的提交键和第217行 elsewhere 的错误位置。然后二进制版：正确的概念带有具体的双位置示例，识别了JS机制，但从未命名提交键。所以我们看到了不同的水平。有趣的是三元版看起来相当稳健，即使它搞错了一些行号。
第四个问题：保持掩码不出现在生成输出中的每个机制，然后是预期答案，我们这里有一堆Python信息以及什么具体的数学运算会导致这种情况发生。在softmax中跳过掩码ID，仅枚举真实字符。奖励：分析基础路径只能构造性地提议布局字符。BF16所有必需的守卫带有正确的行号加上分析路径奖励，五个问题中最干净的答案。三元版两个必需守卫正确关于提交流顶部的额外声明在实质上是正确的但行号再次错误。有趣的是这似乎是一个一致的问题，它搞错了行号。
最后二进制版两个必需守卫正确但归因于后验来自的守卫，该函数计算布局后验而非字符分布。分析字符路径位于get distributions中，归因错误。好吧。最后第五个问题：当网络激活时为什么布局后验面板会与悬停工具提示不一致？预期答案是面板始终计算精确的分析基础后验作为 ground truth。工具提示幽灵使用get distributions，它切换到训练网络。不一致的点是比较网络等于基础。
好吧。所以BF16完整的正确引用并阐述了布局级别与字符级别的区分，以及什么揭示了发散。三元版完整地追溯了网络基础提交注释到sample.py。对学习的近似与精确参考的良好框架。二进制版正确且简洁引用了设计注释行90实际上是89但微不足道。好吧，非常有趣。它们实际上在这个方面表现得相当强劲。现在这不是一个超级复杂的代码库。我的意思是如果我们在这里看它
在扩散文件夹中，我们可以看到内容并不多，但它是一个微小的扩散模型，旨在基于可能出现的布局预测键盘的排列。随后它会重新掩码，并根据已解掩的部分做出新的猜测，这涉及扩散机制等。因此，它并不像简单的 Three.js 场景或前端代码那样 trivial（微不足道）。看到这一点很有趣。
接着我们有一些关于它们表现的信息，包括只读合规性测试：该模型将 answer.txt 写入文件夹。我相信二进制版本也做到了，尽管这通常会发生。它避免了转储 weights.json 文件，这点很好。引用精度方面：高（行级准确），中（函数正确但几行错误），低（主要是文件级别）。事实性错误验证显示：一处轻微的描述误差，将“均匀”描述为其他；三处行号错误；两处归因错误加上错误的代码行及指令违规（即向目录写入答案）。
总结来看，所有三个模型都展示了真正的跨文件理解能力。关于系统工作原理的每一个实质性声明都是正确的，包括那个需要连接 Python 注释与其 JavaScript 对应部分的微妙祖先采样点。量化带来的梯度差异并未表现为理解错误，而是精度的侵蚀。全精度模型行级准确并发现了 Bonus 机制；两位量化模型保留了这些机制，三元模型则保留了一切见解并贡献了最佳原创观察，但捏造了具体的行号。一位量化（二进制）模型在较粗粒度上保持正确，且是唯一违反只读指令的模型。
这一排序与 PrismML 自身的基准测试增量一致：100、94 和 89.5，远优于之前测试的网站。这些增量指的是从全精度版本到三元再到二进制版本的品质退化对比。我觉得这其实挺有意思的，希望你也觉得有趣。我确实觉得很感兴趣。
接下来作为最后一项测试，我们要做一些对大脑负担较轻的事情，即为“Slap Ass Watch Co”公司进行前端网页设计测试。这不仅要创建一个良好的前端，还需要生成手表的 3D 模型，并在英雄区域（首屏）展示类似 KeyShot 软件那样的电影级平移镜头效果。
像往常一样，最左侧窗格运行二进制版本，中间是三元版本，右侧是全精度版本。我们将看看它们在简单前端任务中的表现。“你在开玩笑吗？”好吧，让我们试着让它重新运行起来。好了，不错。好处是这次会快得多，因为它不与三元版本并发运行。预计只需五六分钟。
让我们先看看全精度的结果。“这……这个模型真是个怪物。”我们会注意到一些细节，实际上它把所有小时标记都放在了正确的位置。只是中间那两个是逆时针方向的，但这没关系。那些标记确实存在。说实话，这做得相当好。如果你看过我们最近用此任务进行的模型测试，它的表现与那些大得多的模型不相上下。
“为定义时间的人打造。”它甚至把这个标语放在了这部分区域，我从未见过这样的设计。接着我们有两个不同颜色的系列：Meridian 和 Aethon（埃森）。别问为什么叫这个。它们非常昂贵，两者之间的价格差异很大。“哦，原来如此，因为这个有特殊的机芯。”有意思。
还有更多：“每一件 Slap City 时计都是过去与未来的对话。”非常好。接着是一个制作精良的页脚：“2026，瑞士制造，始于 1984。”做得很好。现在让我们看看三元模型的结果。“这……这将突出显示不同版本模型与原始版本之间在原生能力上的差异。是的，这里有一些相似之处，但与此同时……”嗯，“不言自明”是我想到的词。
希望它能比预期更快完成，只要它不再崩溃。现在我们有了二进制结果进行比较。“这是二进制的结果。”是的，这确实展示了随着不同量化级别（无论你怎么称呼它）的能力下降。不过我会说，二进制版本至少有一个像样的后续部分。三元模型相当混乱，二进制模型也相当混乱，但它们各自的强项不同。
总体而言，这大概结束了这次测试。我想做一些更科学的对比，通过并排比较二进制和三元模型与全精度版本的表现来展示真正的能力。我还想进行代码生成、理解代码库，以及像那个差点让我心脏病发的 Subway 游戏那样的趣味视觉对比。
这就是全部内容了，我没太多要说的。我认为考虑到这些模型在体积大幅缩减的同时仍保留了如此多的智能，它们令人印象深刻。真正 standout（突出）的是二进制模型在 Open Code 中运行，它反复出现错误直到全部修复。游戏最终并未完全正常工作，但它消除了所有阻碍我们发现问题的错误。
我认为这很令人印象深刻：它们没有陷入思维循环，也没有崩溃（虽然三元模型在修复 Subway 游戏结果的后续错误时有点卡住）。但看到能力在如此大幅度的缩减中得以保留，这依然很酷。这对于本地 AI 爱好者来说非常令人兴奋。
即使是 Q8（或类似量化）的 27B Qwen，也是一个非常强大且能干的本地模型。有时看到有人说“本地 AI 没用”，我会觉得好笑：嘿，你用它做过任何事吗？好了，这就是全部内容。我想测试这些模型，因为人们对它们有很多兴趣，而且这是有充分理由的。我相信有一些谣言……
可能正在尝试将这一方法应用到一个规模大得多的开源权重模型上。看到并测试这一点将会非常令人兴奋。好了，到此为止。
如果有任何问题，请随时在评论区留言。别再让我去评测 Kimmy K3 了，原因有二：首先，在我说这话的时候它还没发布；其次，当然等它发布了我会去评测的。
所以，感谢观看，保重。