Swift1.5-Qwen3.8-Flash-Next 相较于基础3.8-Flash令人惊叹！

总结：Swift Flash 是一款出色的模型，能大幅减少过度推理。试用一下！如果您看过我之前的比较文章，您会知道我是 Swift Qwen3.8 模型的忠实粉丝。自发布以来，我一直在使用 27B 版本，对其性能和质量印象深刻（v1.5 版本更佳）。减少过度思考是一个巨大的优势，实际使用和基准测试中质量基本等同。时间节省是巨大的。当 UkisAI 告诉我他们计划发布 Swift Flash 模型时，我非常兴奋。那是我日常使用的最佳本地模型，但在非常困难的问题上，它的思考甚至比 3.8-27B 更多。我下载了 Q5_K_L（带 Q8_0 嵌入）与 Unsloth 的 Q5_K_XL 基础模型（同样带 Q8_0 嵌入）进行比较。这是在 128GB 内存和 SSD 嵌入及 262k 上下文下安全运行的最高质量配置，我认为这是我能进行的最公平的比较。通常，我运行相同的 Aider 代理编码基准测试。我从中获得了大量好数据，包括首次尝试通过率、重试通过率、中位令牌使用量、墙钟时间、每次解决令牌数和格式良好的差异率。以下是图表： | 模型 | 首次通过率 | 重试通过率 | 每案例令牌数 | 每案例秒数 | 每解决令牌数 | 格式良好的差异率 | |------|------------|------------|--------------|------------|--------------|------------------| | Qwen3.8-Flash-Next (xhigh) | 40.2% | 90.7% | 17646 | 1542 | 24.8K | 98.1% | | Swift-1.5-Qwen3.8-Flash-Next (xhigh) | 41.1% | 86.9% | 6991 | 608 | 10.5K | 100.0% | 如您所见，Swift 的表现几乎与基础模型完全相同。在如此规模的数据集上，考虑到基准测试结果中的固有噪声，差异未达到统计显著性。实际上，这里约 5% 的差异是显著的，而我们看到的差异小于 4%。从首次尝试通过率可以看出，Swift 在处理较简单任务时与基础模型速率相同，但在需要第二次尝试的最难任务上略有落后。基础模型恢复了 84% 需要重试的案例，而 Swift 只有 78%。对于令牌使用量和墙钟时间，没有可比性。Swift 实现了 UkisAI 所声称的——它只使用中位令牌的 40%，并在中位时间的 40% 内完成任务，质量几乎相同。这令人难以置信，这是他们 RL/OPD 工作的证明。一个特别有价值的见解：基础模型经常进行长时间的推理狂欢，反复循环。Swift 几乎从不这样做。在基础模型令牌消耗最高的 20 次运行中，Swift 使用了 29% 的令牌，并解决了 16/20 个案例，而基础模型解决了 17/20。即使在基础模型思考最努力的最具挑战性问题上，它也几乎保持了所有质量。Swift 在任何案例上使用的最大令牌数为 44k，而基础模型为 203k。以下是前三种编程语言的细分： | 模型 | C++ | JavaScript | Python | |------|-----|------------|--------| | Qwen3.8-Flash-Next (xhigh) | 23.1% / 84.6% | 37.5% / 91.7% | 57.6% / 93.9% | | Swift-1.5-Qwen3.8-Flash-Next Q5_K_L (xhigh) | 30.8% / 73.1% | 41.7% / 93.8% | 48.5% / 87.9% | 配对比较基础模型（n=107）：99 个一致，2 个提升，6 个损失（净损失 4），McNemar 精确 p ≈ 0.29（不显著）。再次说明，它们在质量上统计上无法区分。C++ 是压缩最明显的，仅使用基础模型令牌的 29%（相比之下，Python/JavaScript 约 46%），并且它也占了 6 次损失中的 3 次。如果您经常用 C++ 编程，这值得注意。总之，我认为这篇文章已经够长了。我相信你们中的一些人希望我现在有 Swift 版本。希望你们从中有所收获。感谢 u/Secure_Recording_472 和 UkisAI 团队与社区分享如此有用的模型！