苹果刚刚发布了一个奇怪但有趣的编码语言模型
苹果悄悄地在 Hugging Face 上发布了一个有趣的新人工智能模型。它不像传统的大语言模型(LLMs)那样从左到右、从上到下地编写代码,而是可以打乱顺序编写代码,并同时改进多个代码块。
这使得代码生成速度更快,性能可与顶级开源编程模型相媲美。以下是其工作原理。
技术细节
以下是一些(为了效率而过度简化的)概念,理解这些概念对于继续探讨至关重要。
自回归
传统上,大多数大语言模型(LLMs)都是自回归的。这意味着,当您向它们提问时,它们会处理您的整个问题,预测答案的第一个符号,用第一个符号重新处理整个问题,预测第二个符号,以此类推。这使它们生成的文本与我们大多数人阅读的文本一样:从左到右,从上到下。
温度
大语言模型(LLMs)有一个称为“温度”的设置,用于控制输出的随机性。在预测下一个令牌时,模型会为所有可能的选项分配概率。较低的温度使模型更可能选择最可能的令牌,而较高的温度则使其更有自由选择可能性较小的令牌。
扩散
与自回归模型相对应的是扩散模型,这类模型常被图像生成模型如Stable Diffusion采用。简而言之,模型从一张模糊、噪声较大的图像开始,通过迭代去除噪声并始终考虑用户请求,逐步引导生成的图像越来越接近用户所期望的样式。
扩散模型在数据与噪声之间进行处理。图片来源:NVIDIA
还跟得上吗?太棒了!
最近,一些大型语言模型开始采用扩散架构来生成文本,结果相当令人鼓舞。如果你想更深入地了解其工作原理,这里有一个很好的解释:
我为什么告诉你这些?因为现在你可以明白为什么基于扩散的文本模型比自回归模型更快,因为它们基本上(再次强调,基本上)可以并行地迭代精炼整个文本。
这种行为在编程中尤为有用,因为编程中全局结构比线性令牌预测更重要。
终于搞定了。苹果发布了一个模型吗?
是的。他们发布了一个开源模型,名为DiffuCode-7B-cpGRPO,该模型基于一篇名为 DiffuCoder:理解和改进用于代码生成的遮罩扩散模型构建,该论文仅在上个月发布。
该论文描述了一种采用扩散优先方法进行代码生成的模型,但有一个关键区别:
“当采样温度从默认的 0.2 增加到 1.2 时,DiffuCoder 在令牌生成顺序上变得更加灵活,摆脱了严格的从左到右的约束”
这意味着通过调整温度,它可以表现得更像(或更不像)一个自回归模型。本质上,更高温度使其在生成令牌时具有更多灵活性,而较低温度则使其更接近严格的从左到右解码。
通过一个额外的训练步骤称为耦合GRPO,它学会了在更少的迭代中生成更高质量的代码。结果如何?生成速度更快、全局一致且与一些最好的开源编程模型相媲美的代码。
来自研究: “(a) DiffuCoder-Instruct 解码过程的真实示例,采样温度为 1.2。 (b) 编码基准测试结果。 (c) 当解码步骤减半时,采用耦合 GRPO 训练的 DiffuCoder-Instruct 性能下降幅度小于 Instruct 本身。”
基于阿里巴巴的开源大语言模型(LLM)构建
更有趣的是,苹果的模型是基于阿里巴巴的开源基础模型 Qwen2.5‑7B 构建的。阿里巴巴首先对该模型进行了微调,以实现更好的代码生成(作为 Qwen2.5‑Coder‑7B),然后苹果将其拿来进行了自己的调整。
他们将其转化为一个基于扩散解码器的全新模型,如 DiffuCoder 论文中所描述的,随后再次调整以更好地遵循指令。完成这些步骤后,他们使用超过 20,000 个精心挑选的编码示例对该模型进行了进一步训练。
所有这些努力都取得了成效。DiffuCoder-7B-cpGRPO 在一个流行的编码基准测试中获得了 4.4% 的提升,并且它保持了对从左到右严格生成代码的较低依赖性。
当然,还有很大的改进空间。尽管 DiffuCoder 的表现优于许多基于扩散的编码模型(而这还是在 DiffuCoder-7B-cpGRPO 带来 4.4% 的提升之前),但它仍未达到 GPT-4 或 Gemini Diffusion 的水平。
尽管有人指出70亿参数可能存在局限性,或其基于扩散的生成过程仍类似于顺序流程,但更关键的是:苹果正通过一些颇具创新性的想法,逐步为其生成式人工智能项目奠定基础。
这些努力是否(或何时?)能真正转化为用户和开发者可用的实际功能与产品,则是另一个值得探讨的问题。
简要版本:一个被转换为扩散模型的Qwen-2.5 7B模型。
值得注意的几点:首先,这种转换本身就很有趣(从左到右的模型通过微调转换为无序扩散模型)。其次,最终版本在某些基准测试中比原版略胜一筹。第三,其性能与Gemini扩散模型处于同一量级,尽管尚未达到竞争水平——这对于任何7B参数模型而言均属预期之内。
扩散模型在并行化方面具有显著优势,从而提升速度;在我看来,其架构更适合编码而非严格的从左到右生成。
总体而言,这很有趣。未来某一时刻,这些本地模型将足够成熟以用于“实际工作”,并迅速被API提供商采用。苹果的策略是设备端部署;我认为这些模型的衍生版本将在未来一年内作为编码体验的一部分随Xcode发布。
尽管尚未亲自尝试,但我始终感到惊讶的是,看似截然不同的架构(以及在其他情况下不同的训练数据)竟能产生非常相似的结果。我原本预期结果会差异更大。
我预计许多尝试会失败,而这些失败案例往往不会被发表,或获得较少关注。因此,如果我们已达到局部最优解,任何接近当前基准的技术都值得发表,只要结果达到该水平。所有相差过大的方案会被舍弃。最终,你看到的论文都接近当前的行业标准。
可能有些新架构/优化方案能让我们超越当前基准分数,但可能需要更多训练数据和资金。但要获得资金,你需要展示成果,这就是你今天所看到的。扩展性依然是关键;也许其中一种技术是2025年的“注意力”论文,但即使是那篇论文,也需要大量扩展才能从2017年版本升级到ChatGPT。
遗憾的是,它似乎没有被推动太多。文章称他们只在最后添加了2万个示例进行微调,但扩散模型的上限可能高得多?
但确实,RWKV也最终在类似的性能区域和规模下表现相似——我希望有人终于开始大规模使用它……
但如果限制因素是模型训练所用的数据而非实际“计算能力”,那么这种情况正是预料之中的吧?
数据可能是当前变压器架构的限制因素,但没有理由认为这是任何语言模型的普遍限制因素(例如,人类大脑在训练数据量上比当前任何模型少几个数量级,但仍能表现得更好)
这取决于这些当前学习模型是否真的能够泛化,还是只能在训练集内进行插值
当我们查看适合本地运行的较小模型时,目前最佳的编程模型是DeepSeek-R1-0528-Qwen3-8B。即使与更大规模的模型相比,它在实际应用中的表现也相当出色。
您方便分享一下得出这一结论的依据吗?是否有某个基准测试中它表现特别突出?还是个人使用场景?
与哪些更大规模的模型可比?
> 扩散模型在并行化方面具有诸多优势,因此在速度上更具优势;在我看来,这种架构更适合编程,而非严格的从左到右生成。
我也有类似的看法,并对这项研究感到兴奋。我编写代码的经验是,整个系统的结构会影响每个部分,这始终让我觉得更适合扩散型模型。
我怀疑这是一个7B模型,因为这是个实验,但我喜欢看到苹果在尝试较小的模型——我认为谷歌的“没有护城河”备忘录在根本上是正确的,无论是通过更好的架构还是摩尔定律,而苹果似乎也持相同观点。
“无护城河”备忘录远比谷歌承认一个令人不适的真相复杂得多。从看似内部文件泄露中获益良多,这些文件揭示了竞争环境的公平性。
> 在我看来,架构更适合编码
我们需要看看它是否能产生更好的结果。人类有一个规划阶段,随后是分阶段的实施阶段。这在一定程度上可以通过计划/架构师 + 代码生成工具来模拟。
认为大多数软件项目可以提前规划到“有开始、中间和结束”的程度是妄想。人们确实这样做,但根据我的经验,一旦实施开始,这些努力通常会被忽视。
软件规划并非单纯遵循计划,而是规划一条可行的路径以避免可预见的问题。随着项目推进,你对项目的了解会不断深入,因此应持续更新计划。
这一点在项目层面确实成立。但当你实际坐下来工作几小时时,你肯定会先思考要做什么,然后主要执行这些计划。
根据我的经验,情况更具分形性。任何子目标,无论多么微小,都可能遇到自己的规划/思考和执行序列,甚至迫使你重新考虑更高层次的计划。当然,这在一定程度上取决于整体任务的常规程度。
在瀑布下 nervously laughs
> 终有一天这些本地模型会足够好,可以用于‘实际工作’
这些小型模型除了自动完成功能外,还能用于其他用途吗?
既然这占了我使用它的99%,光这一点就让我很满意。
难道这不是它们的设计初衷吗?
它们不仅预测你正在输入的单词的后半部分,但归根结底,它们只是在预测人类会输入的内容。
我感到失望,因为我不使用自动完成功能。
大型模型的“魔法”大多只是函数调用,只要小型模型能访问相同函数就能正常工作。他们通过将“草莓中有多少个R”的问题交给函数处理,而非耗费巨资/精力训练另一个模型,解决了该问题。
哦,抱歉“工具”。必须保持这些基于统计的无损文本压缩酷炫技巧的“思考”状态。
我认为苹果最终会摧毁数据中心,希望他们成功。
也许在计算方面,但不是在存储方面。
为什么我不能像使用Time Machine一样,将iOS设备备份到本地NAS?(修辞问题;显然,答案是他们想卖更多iCloud存储空间,以获得那至关重要的服务收入)。
> 为什么我不能像使用Time Machine一样,将iOS设备备份到本地NAS?
当我将iPhone连接到iMac时,它会将数据备份到本地文件,然后通过Time Machine(以及SuperDuper/CarbonCopyCloner)进行备份。
“如何使用Mac备份iPhone、iPad和iPod touch”:
* https://support.apple.com/en-ca/108796
还有一个“Wi-Fi同步”复选框,因此不一定需要数据线。
这正是我的观点:为什么我需要一台单独的电脑来中介备份?
iOS原生支持通过任何网络连接(包括有线以太网)使用SMB协议,以及以10 Gbps速度挂载加密的APFS卷到USB存储设备等功能。
苹果明确的愿景是iPad Pro可以替代Mac,甚至对于部分专业用户也是如此。为什么这些设备不值得拥有本地备份?
有多少人拥有NAS,但没有PC或Mac?
苹果已经提供了官方软件来处理iDevice在Windows或Mac上的备份。
将Android设备备份到PC使用adb要困难得多,尤其是对技术不太熟悉的人来说。
> 有多少人拥有NAS,但没有PC或Mac?
这可能是个错误的问题:我敢打赌,如果能轻松将iOS设备备份到NAS,拥有NAS的人会多得多。
愿意购买NAS而非每月支付5美元存储费的人数远低于1%,而如果再加上不拥有PC/Mac的限制,最终人数可能仅有数百人……
愿意购买某家公司设备却不信任该公司处理其数据的人并不多
你的数据可能没错,但苹果已通过一些小众功能(甚至需要昂贵的设备级硬件)实现了类似功能,且成本远低于此。
你有例子吗?
所有新款iPhone型号均支持通过USB-C接口原生输出DisplayPort,但我怀疑连1%的用户都未配备所需的线缆/适配器。
部分用于罕用频段的功率放大器可能也符合条件(尤其是毫米波频段)。
在软件方面我需要深入研究,但估计iOS系统中许多代码路径的使用率都低于1%的用户。
我敢打赌,如果谷歌提供一个用户友好的工具,允许用户将安卓设备备份到本地电脑,会有更多人愿意备份自己的安卓设备。
>为什么我无法将iOS设备备份到本地NAS
你可以使用Finder备份iPhone。
Finder -> 位置 -> 你的iPhone -> 将此iPhone上的所有数据备份到你的Mac。
完成后,你可以在“管理备份”中找到备份,右键点击条目并选择“在Finder中显示”。从那里你可以将其复制到NAS。
虽然不如Time Machine备份流畅,但确实可行。
> 虽然不如Time Machine备份流畅,但确实可行
我个人认为这简直是“荒谬地笨拙且故意对苹果用户群体的大部分人来说不实用”。
Synology 支持这种功能,我相信他们不是唯一一家。
直接将 iOS 备份到本地外部存储,无需另一台电脑参与?如果这是真的,我会非常惊讶。
这是一个第三方工具的示例。
> 分步指南:如何将 iPhone 备份到 Synology NAS
https://www.ubackup.com/phone-backup/backup-iphone-to-synolo…
> 准备工作。如何在电脑上设置 Synology NAS
这是一份关于如何使用电脑将 iPhone 备份到 NAS 的指南。
不出所料,一个功能强大的通用操作系统能够以对应用程序透明的方式支持网络文件系统,但这并不能帮助仅使用 iOS 设备的用户。
你真的读过你链接的内容,还是只是从搜索引擎中随机复制了一个链接?
文中提到了两种方法:一种仅备份相机胶卷;另一种需要连接到电脑并手动操作,此时你不如直接使用Finder内置的官方备份功能(或Windows上的iTunes?那还存在吗?),无需使用任何第三方应用。我对他们声称的“备份所有内容”也表示严重怀疑。
这篇文章显然是为该第三方应用程序做的隐晦营销,遵循常见的SEO策略:先提供一个敷衍了事的解决方案来捕获热门搜索词(例如“将iPhone备份到Synology”),然后将他们自己的可疑产品包装成更优方案。
> 我认为苹果最终会摧毁数据中心
我认为电动汽车摧毁超大型集装箱船的可能性更高,而两者都极不可能发生。苹果无法克服的数据中心优势:计算密度、散热、廉价电力、物理安全以保护软件、规模+带宽、通过使用合同制造商和/或通用硬件降低客户成本。
在任何情况下,大型企业都不会放弃其地理位置固定的机架。更不用说超大规模企业了,尤其是现在它们正在四处寻找能源,违背可再生能源承诺,并支付巨额资金来启动核电站
这让人联想到20世纪80年代的苹果与IBM之争。我迫不及待想看到《1984》广告的重现。
除非他们根本改变对计算的认知方式,否则这不可能实现。而他们的领导层似乎完全没有这种意愿。事实上,他们似乎更倾向于将业务迁移到数据中心内部。这就是我做空他们的原因。
我认为这只是一个方便的过渡步骤,而非长期战略。
Jetbrains为其IDE提供了100MB的语言模型,可实现单行代码的自动补全。这不错,但我认为本地代码自动补全还能做得更好。希望苹果在设备端AI尝试中取得成功。
Jetbrains 的任何产品都具备竞争力吗?我从 Pycharm 跳槽过来,自发布以来尝试过他们的 AI 功能几次,但每次都对他们与竞争对手的差距之大感到震惊。
Junie 真是太棒了。它消耗积分的速度快得惊人,但我只见过 Claude-Code 和 OpenCode 勉强能与之匹敌。
你使用的是 Jetbrains 的普通 AI 助手,还是 Junie?
我在Java和Kotlin等核心语言上使用Junie和AI助手的体验不错。不过我还没在实际项目中测试过。
如果你想的话,现在就可以本地运行Qwen3。它可以生成完整文件(尽管延迟无法达到亚秒级,而亚秒级延迟是实现交互式编辑器补全功能所需的,这需要使用小于1GB的模型)。
这是他们撰写的研究论文:https://arxiv.org/pdf/2506.20639
值得注意的是,这是一个实习生项目。
要么这篇,要么https://huggingface.co/apple/DiffuCoder-7B-cpGRPO应该被当前的文章替换。
我的意思是,坦白说,行业研究实验室之所以能产出大量优质研究,正是因为这些项目大多由实习生完成(也就是说,你拥有一支充满热情的实习生队伍)
看来这更侧重于“更好的自动完成功能”,而非“驱动你的下一代智能助手”。考虑到苹果对设备端体验的重视,这合乎逻辑。
扩散算法是否支持“尺寸编辑”?我不确定该如何提出这个问题,或者这(很可能)暴露了我对该技术的根本误解,但:对于一张图像,其尺寸是固定的(例如256×256)。对于文本,如果每个令牌是一个像素,那么它非常小。文章中的图像显示了按生成顺序颜色编码的文本。如果需要插入另一行来完成评论句子的其余部分,该怎么办?它如何在事先就知道大小,就像图像大小一样?
是的,块扩散模型例如会生成固定大小的文本块,但可以动态调整块的数量。
Zed团队最近发布了一篇关于文本扩散模型的不错入门文章:https://www.youtube.com/watch?v=oot4O9wMohw
这很有趣,尽管不清楚为什么Zoom里只有另外一个人。不过,我后来很高兴有那个人在,因为他们问了我关于扩散与提示之间相互作用的问题<https://www.youtube.com/watch?v=oot4O9wMohw&t=977>这让我明白为什么会使用这种扩散设置来实现代码补全。这里的“提示”是指当前文件或行状态,然后通过扩散将文本填充到相应位置
如果我们能从本地运行的模型(尤其是苹果擅长设计和批量生产的专用芯片上运行的模型)获得几乎相当的结果,我认为我们很快就会迎来一个转折点。这是一个实习生项目,希望他们现在能投入更多资源:一台运行在我的笔记本电脑上的70亿参数模型,如果能达到Gemini或Claude的标准,我每天都会为它买单。
从纯技术角度而言,我并未参与人工智能研究的前沿工作,但没想到扩散模型在文本处理领域已取得如此多进展——且具备如此潜力。这值得深入研究,因为看起来非常有趣。
很想在ollama/llama.cpp中尝试这个。使用llama.cpp在VsCode中生成文本非常痛苦,因为(现实中)我每次只能生成大约<100个令牌。
我对模型本身其实不太在意。我真正困扰的是与IDE的集成以及如何轻松为模型提供正确上下文(Visual Studio Code在最近的101更新后勉强可用)。我发现Copilot中的大多数模型性能都差不多。
我一直在寻找与 Docker Python/FastAPI 后端和 Vue 前端配合使用的良好/最佳实践工作流程设置……但尚未找到太多。
如果有人有建议,告诉我该去哪里寻找,我将不胜感激!
我尝试了所有与代码相关的 Frontier 模型,Claude Code 明显是最好的。
不过,其他与编程无关的任务则另当别论了。
这样的文章真的让我希望当前一代的大语言模型(LLMs)能更经常地被描述为“无限猴子定理”的可行实现——本文中的描述/图像特别值得向那些想要了解人工智能模型如何“创造”图像的人展示。
我认为有趣的几点:
> 苹果的模型基于阿里巴巴的开源基础模型Qwen2.5-7B构建。阿里巴巴首先对该模型进行微调以提升代码生成能力(即Qwen2.5-Coder-7B),随后苹果在此基础上进行了自有调整。
> 它仍未达到GPT-4或Gemini Diffusion的水平。
> 结果是代码生成速度更快,性能可与顶级开源编码模型媲美
所以尽管它更快(比什么更快?),但仍未超越顶级模型?
这是一个7B模型…
Zed 正在使用其模型进行非顺序编辑,我不确定这里有什么新东西。我强烈怀疑他们的模型直接与编辑器使用的 CRDT 配合工作,因为它能够继续为用户执行类似的删除操作(这些删除操作对大多数自动完成模型来说是不可见的)。
苹果的模型是开放权重的,所以这很重要。
我经常进行无序编辑,因此看到有模型也能实现这一点让我感到有趣。