Q2.8量化下的Flash模型：128GB内存极限挑战

本片段首先展示了DeepSeek V4 Flash在Q2.8实验性量化下的运行表现。作者指出，Flash模型此前已在单台Mac Studio上成功生成HTML贪吃蛇游戏，消耗95GB内存并占用2000 tokens上下文窗口。为了验证更极端的压缩效果，作者测试了Q2.8量化版本在生成5000 tokens代码时的稳定性。结果显示，该配置下模型以24.5至25 tokens/秒的速度输出了完整的俄罗斯方块游戏代码，且内存占用稳定在95.6GB，完全符合128GB系统的预算限制。作者强调，尽管量化会损失连贯性，但能输出可运行的代码是模型保持智能的关键标志。作者甚至亲自试玩并通关，证明该量化版本在基础游戏逻辑上依然具备极高的可用性。

"I was actually playing this game before I recorded this video. And I did really well... The fact that it works at 2.8 bit quantization is amazing goals."

Pro模型分布式计算：双Mac集群与内存瓶颈

针对参数量高达1.6万亿的DeepSeek V4 Pro，单台设备无法承载其Q2量化需求。作者采用分布式计算策略，将Mac Studio与MacBook Pro连接协同工作。测试数据显示，主系统（Mac Studio）内存占用达456GB至457GB，而辅助系统（MacBook Pro）占用近70GB内存。尽管作者不得不关闭浏览器标签页以腾出空间，系统仍实现了约12至13 tokens/秒的推理速度。这种“记忆池化”方案使得在本地运行超大规模模型的Q2版本成为可能，尽管其性能远低于云端全精度模型。

"We're going to be using a bit of distributed compute... so we can pool our memories."

代码生成质量对比：基础逻辑与复杂3D渲染的界限

在Pro模型的测试中，生成的贪吃蛇游戏代码无运行时错误但存在逻辑Bug。作者指出，虽然代码结构完整（包含上下左右控制），但在实际运行中出现了逻辑混乱。相比之下，Flash模型不仅能生成可运行的2D游戏，还尝试了3D俄罗斯方块。尽管Flash输出了4600 tokens的代码且表面看似完整，但实际运行结果为黑屏。这一对比揭示了极端量化下的能力边界：基础2D逻辑尚可维持，但涉及复杂3D渲染或高级功能时，模型会出现严重幻觉或失效。作者建议若需处理复杂任务，应使用更大系统或更宽松的量化精度。

Tetris代码生成与量化版本性能实测

在分布式集群运行下，模型成功生成了约 5000个token 的俄罗斯方块代码。尽管平均生成速度维持在 12.5 tokens/秒，且Mac Studio内存占用为456MB，但代码最终出现 运行时错误 无法执行。作者强调，2.8-bit量化版本因压缩过度导致精度下降，仅能维持响应连贯性，不适合用于编程任务。目前上传了三个量化版本供用户测试：9-bit Flash版（代码质量高）、2.8-bit Pro版及2.8-bit Flash版。

逻辑推理能力与创造性写作表现

尽管代码编译失败，模型在 纯文本逻辑测试 中表现出色。面对“电车难题”变体（五死一活是否切换轨道），模型准确识别出这是经典伦理困境，并基于后果主义给出正确推理：拉动杠杆导致一人死亡优于不行动导致的更多潜在风险。作者通过添加空格测试随机性，发现模型在 99%的确定性 下仍坚持正确逻辑，证明其智能已内化于基础模型中。此外，在创造性写作方面，2.8-bit量化版生成的故事（如寻找猫却找到神秘门的周二下午）文笔优美，显示其在 创意写作领域 仍有较高可用性。

分布式计算社区构想与未来展望

作者提出构建 多机联网分布式计算系统 的愿景，计划开发“大厅”功能允许用户注册电脑加入集群。通过 互联网组网 实现大规模多人在线分布式计算，以运行更大参数模型。当前系统受限于硬件配置（Mac Studio + MacBook Pro），未来若获得更多设备支持，将推动本地AI集群向 去中心化协作 方向演进。

分布式计算带来的隐私风险与加密对策

在利用多台计算机进行分布式推理时，核心挑战在于数据隐私的安全隐患。由于提示词（prompts）会被分片传输到不同的设备上，如果这些设备由不可信或具有攻击性的用户控制，他们有可能通过监控网络流量来窥探并重组原始令牌（tokens）。为了应对这一风险，必须设计一种机制来伪装数据传输内容。潜在的解决方案包括在令牌发送过程中实施加密处理，但这通常会以牺牲部分推理性能为代价。因此，系统可能需要提供不同的运行模式，例如一个追求速度的“快速运行模式”和一个注重安全的加密保护模式。这种权衡需要进一步的技术探索，以在性能与隐私之间找到平衡点。

"If the multiple computers are like bad people or, you know, aggressive people, they can try to [snorts] spy on finding out what the tokens is."

基于 Apple Silicon 的集群连接与模型部署流程

在具体的硬件实施层面，该方案依赖于 Mac Studio 作为核心服务器节点。用户首先在 Mac Studio 上启动服务并启用“允许分布式计算”选项，随后在 MacBook Pro 客户端通过连接功能选择该服务器。这种架构具有动态感知能力：当 Mac Studio 上的服务被禁用时，MacBook Pro 会立即检测到节点消失；反之，一旦重新启用，该设备便会自动出现在可用列表中。连接建立后，客户端即可访问 Mac Studio 上的所有模型资源。以 DeepSeek V4 Pro 为例，用户只需在下拉菜单中选择该模型并点击分布式计算按钮，系统便会自动在各节点上加载模型分片。这种无缝的集群协同机制使得本地运行超大参数模型成为可能，尽管受限于硬件条件采用了 2.8-bit 量化方案导致体验并非完美，但仍成功实现了本地化推理。

"So, when I selected DeepSeek V4 Pro, I click on that distributed compute button and then that starts loading the models on each of the system."

结论

视频测试表明，2.8-bit量化在本地Apple Silicon集群上实现了1.6万亿参数DeepSeek V4 Pro的可行运行，但存在显著能力边界。其优势在于纯文本逻辑推理（如电车难题）与创意写作表现稳定，且通过分布式内存池化解决了单设备容量瓶颈。然而短板突出：代码生成虽能输出完整结构，但基础2D游戏存在逻辑Bug，复杂3D渲染直接失效（黑屏），且Pro版代码最终出现运行时错误。该方案仅适用于对隐私敏感、能容忍性能折损（约12-13 tokens/秒）及非关键代码任务的场景。对于需要高可靠性编程或复杂渲染的任务，2.8-bit量化因精度损失导致幻觉严重，并不适用；若需处理此类任务，必须采用更高比特量化或更大规模硬件集群。