最新

如今，许多SaaS和API平台都会发布代理技能。我们也发布了，但我无法判断它们对真实用户的实用性。 我们有评估来测试技能在理想条件下的运行情况，但我对它们在实际环境中的运行时行为更感兴趣。例如： 代理在多大程度上会回退到网络搜索，而不是遵循技能的指示？ 对于普通用户来说，已安装的技能会被触发多少次？ 除了skills.sh等平台报告的安装量之外，是否有人在跟踪实际使用情况？尝试获取这些洞察是否有意义？

建立社交声望：您的动态消息将锁定，直到您手机的摄像头计算出您的俯卧撑次数。支持 iOS 和 Android。socialreps.app

基于 Baileys 构建。目标是处理所有繁琐的工作——打开套接字、身份验证、重新加载——让你能专注于命令逻辑以及你想要机器人实现的功能。

大家好，我们对 Qwen 3.8 27B 模型进行了后训练，通过识别与过度思考相关的 token 并对其进行惩罚，同时不直接“攻击”推理长度，从而提高了效率。然后，我们使用一些“秘密武器”（提示：On-Policy Distillation）来修复了准确性，并取得了优异的成果（长度减少 58%，速度提升 1.95 倍，准确性损失 <1%）。因此，我们希望将其开源，并听取社区的反馈。 模型链接：<a href="https://huggingface.co/ukisai/Swift-Qwen3.8-27b" rel="nofollow">https://huggingface.co/ukisai/Swift-Qwen3.8-27b</a> / 该模型在 3 天内下载量达到 80,000 次，独立评估结果如下：<a href="https://www.reddit.com/r/LocalLLaMA/comments/1wg7dd5/ukisai_swiftqwen3827b_583_thinking_x195_speed/" rel="nofollow">https://www.reddit.com/r/LocalLLaMA/comments/1wg7dd5/ukisai_...</a> 我们还提供了一个免费的研究用途 API（兼容 OpenAI），这得益于 Nvidia 慷慨提供的 GPU。该 API 限制为 5RPM。<a href="https://ukisai.com/api/swift/v1/models" rel="nofollow">https://ukisai.com/api/swift/v1/models</a> 我们还制作了 GGUF 版本（Q1-Q8）：<a href="https://huggingface.co/ukisai/Swift-Qwen3.8-27B-GGUF" rel="nofollow">https://huggingface.co/ukisai/Swift-Qwen3.8-27B-GGUF</a>，社区还提供了其他精度更高/更低的量化版本（Bartowski：<a href="https://huggingface.co/bartowski/ukisai_Swift-Qwen3.8-27b-GGUF" rel="nofollow">https://huggingface.co/bartowski/ukisai_Swift-Qwen3.8-27b-GG...</a>）。社区还创建了令人惊叹的 MLX、NVFP4、W4A16 和未审查版本，您可以在 Huggingface 上找到它们。 重要提示：我们的训练方法并非替代推理设置、聊天模板或 token 限制，而是对其进行补充，并针对一个完全独立的问题（过度思考和“焦虑样”推理循环，之前在 PTQ 中出现过，但据我们所知，在同等规模的 BF16 LLM 中也很普遍）。与普遍看法相反，这些特定的模式在得到妥善处理时，并不会提高答案质量。（我们的论点是：推理长度确实非常重要，不应被强制缩短，而应进行优化）。这一点也在下面的 xhigh 与 medium 努力基准测试中得到了证明。目标是在保持 xhigh 准确性的同时，仅减少不必要的思考部分。 我们思路、研究、训练以及启发我们的 Meta 论文链接的 TLDR 总结在第一个评论中。 基准测试： Swift-27B vs Qwen3.8-27B (BF16，所有基准测试运行 5 次，思考强度 xhigh) GPQA-Diamond：88.4% -> 88.3%，中位数 token 减少 58% LiveCodeBench v6：76.8% -> 81.6% (+4.8pp，由于 LCB 中的默认截断，并非性能提升)，中位数思考 token 减少 46% Terminal-Bench 2.1：66.7% -> 65.8%，中位数 token 减少 39% MMLU-Pro：85.5% -> 85.0%，中位数 token 减少 28% C-Eval：90.0% -> 90.6%，中位数 token 减少 19% IFBench：73.5% -> 71.8%，中位数 token 减少 51% AIME 2026：98.7% -> 94.0%，中位数 token 减少 50% HMMT (2025 年 11 月)：99.3% -> 96.0%，中位数 token 减少 46% ERQA (视觉)：67.5% -> 66.3%，中位数 token 减少 55% 在所有推理强度下，token 节省效果均保持不变（平均思考减少量）：xhigh 41%，medium 23%，low 26%（尽管在 medium 和 low 上准确性损失分别为 1-4% 和 1-2%，这需要我们进一步测试）。 Swift 在 xhigh 下与基础模型自身的努力设置在 GPQA-Diamond 上的对比（198 个问题 x 5 个种子）： 基础 xhigh：88.4%，中位数 6,642 token Swift xhigh：88.3%，中位数 2,771 token 基础 medium：84.1%，中位数 1,753 token 因此，Swift 在 token 量不到一半的情况下保持了 xhigh 准确性，并且在 token 量约为基础 medium 的 1.6 倍时，性能比基础 medium 高出 4pp。 结束语： 尽管我们热衷于完全开源，但作为一个新实验室，我们仍需对部分训练和数据保密。许可证不是 Apache 2.0，但它仅影响年收入超过 100 万美元的公司。我们希望这不会给社区带来问题，并欢迎对此的反馈。 我们希望为社区做出尽可能多的贡献，并非常感谢您对我们的工作、量化或 Swift 模型请求的反馈。我们正在开发 Swift 3.8 Flash Next，到目前为止，思考 token 使用量已减少 53%。我们有强烈的迹象表明我们的方法可以在其他模型系列中重现，并希望社区告知您希望我们接下来优化哪些模型。

在过去的一年里，我们一直在构建 AI 工作空间。随着每个新产品的推出，我们发现自己都在重建相同的上下文层和基础设施。我们尝试了现有的解决方案，但要么需要锁定到一个提供商，要么需要自行管理存储基础设施。 我们想要的是一个有状态且不与特定提供商绑定的 API，这样我们就无需考虑压缩、不同的模式或自行运行基础设施。 由于我们已经构建了大部分组成部分，因此我们决定发布 Twigg。 该 API 设计得非常简单。您创建一个聊天，然后会收到一个 ID。当您有新的提示或工具结果时，将它们与 ID 一起发送。您无需自行存储或管理上下文。它会追加新的提示并为您组装历史记录。要切换模型，只需在下一个请求中更改一个字段。 仪表板涵盖了您想要配置的大部分内容：工具模式、系统提示、上下文窗口限制和保留设置。 我们很想听听所有遇到过同样问题的人的意见。您目前是如何托管上下文的，以及什么会让您不愿意将其交给第三方？