[AINews] How to steal a Reasoning Trace

[AINews] 如何窃取推理轨迹 - Latent.Space

AINews: 工作日精选

[AINews] 如何窃取推理轨迹

无论用什么名称称呼，推测性解码都同样甜美

2026年8月12日

很少有论文能突破重围成为当日头条新闻。出于可理解的国内外原因，对齐、安全性和思维链监控的可解释性韦恩图重新引发关注，因此今天这篇论文的出现恰逢其时：

亚历山大·潘菲洛夫

@kotekjedi_ml

我们终于可以讨论这个话题了：我们发现了一种利用所有前沿AI公司API漏洞来提取前沿模型隐藏推理的方法。我们验证了对于大多数查询的提示，我们的推理令牌数量与计费的API思考令牌数量呈1:1对应关系。

2026年8月11日 下午12:00

·

152万次观看

226条评论

1170次转发

8650个赞

自从o1发布以来，前沿实验室的推理模型就使用加密签名隐藏了它们的轨迹，以防止蒸馏（尽管这并未阻止中国实验室指责他们进行蒸馏）。第一个漏洞由Matthew Green于5月负责任地披露，他详细解释了其工作原理，并通过延迟测量间接地重新播放和侧信道这些数据。今天这篇论文证明，可以解码并将这些加密思维移植到不同模型/会话/用户中……并因此显著提升开源模型性能。

令人担忧的是：

“此外，如果你曾在线分享过带有加密推理块的Claude Code/Codex会话，这些内容可以被解码并泄露你的个人数据。我们对约7000个公开轨迹进行了初步扫描，发现了62个独特的API密钥、33个电子邮件地址、33个密码和其他敏感数据。”（64个数据仅出现在推理块中，而不在可见会话中。）

作者还详细描述了对齐问题：

• 隐藏答案的思维链摘要器
• 不可理解的推理
• 作弊考虑
• 网站攻击

网站上有更多示例。

论文中大致描述了该技术：

• 从API响应中获取一个合法的加密/签名推理块。
• 将该块重播到另一个请求——可能是同一供应商的较弱模型的另一个账户/会话。
• 将其放入助手/模型回合并提示或预填充较弱模型以转录附加的推理。
• 重复采样，丢弃拒绝响应，并根据需要进行多次嘈杂转录的协调。

论文提供了具体模板，每个模型略有差异：

• Claude：将签名的思考块重播到Haiku 4.5，然后使用类似<thinking-copy>的助手预填充。
• GPT：将加密内容推理项多次注入伪造对话中；最多采样50个输出。它还描述了如何通过分块延续绕过明显的约50个令牌逐字输出阈值。
• Gemini：将thought_signature附加到带有<thought>预填充的模型回合中，然后使用重复采样和协调。

该论文已负责任地披露，已修复了多个漏洞，但显然类似的攻击仍然可能。

Can Bölük

@_can1357

伙计们，你们知道只要禁用思考，改用"deep_think"工具，它就会用内部思维链推理格式调用它吗？祝你们修复这个漏洞好运

2026年8月11日 下午5:23

61万次观看

129条评论

350次转发

4960个赞

2026年8月10日至11日AI新闻。我们检查了12个Reddit子版块、544个Twitter账号，未发现任何Discord内容。AINews官网支持搜索所有历史文章。提醒您，AINews现已整合至Latent Space板块，您可随时调整邮件接收频率！

AI Twitter动态回顾

推理轨迹暴露、CoT隐私与水印争议

• 前沿API漏洞暴露隐藏推理：@kotekjedi_ml广泛讨论的披露显示，跨前沿API的漏洞允许提取"加密"隐藏推理，恢复的token数量与账单思考token在大多数查询提示中1:1匹配。后续报告称对约7000个公共轨迹的扫描发现了62个唯一API密钥、33个电子邮件地址、33个密码及其他敏感数据@kotekjedi_ml。@jonasgeiping补充指出，公开分享轨迹存在即时隐私风险，且运营安全影响显著：调查期间据报道在更广泛的网络事件中遇到了泄露的Hugging Face生产密钥。多篇帖子强调当解码后的CoT内容简略、碎片化、多语言或实质为"神经语言"时，监控难度显著增加@jonasgeiping, @scaling01, @eliebakouch。实际推论：即使实验室隐藏推理，工具接口仍可能重新暴露；@_can1357指出，禁用显式思考但提供deep_think工具仍可能诱导内部格式的CoT输出。

• 技术层面的含义：讨论分裂为"严重隐私/安全问题"与"非可扩展的蒸馏路径"两派。@vipulved认为该攻击不意味着模型训练中链式思维的大规模盗窃，将加密视为无状态分布式推理协议优化而非硬性保密屏障。但该事件突显了几个要点：公开轨迹共享存在风险；隐藏CoT不是可靠的监控接口；实验室可能需要在沙箱、遥测和工具接口方面提供更强的保证@BlackHC。同时，另一条线程在欧盟风格合规压力下讨论AI文本水印问题。@trq212称实验室正在添加水印和文本检测API；批评者质疑这是否会增加输出体积或损害代码/文档简洁性@wightmanr。其他人认为熵预算足够大，签名可以很微妙，尤其是对较长输出@RyanGreenblatt, @giffmana。

NVIDIA Nemotron 3.5 Lightning与小型开源代理模型推进

• Nemotron 3.5 Lightning：NVIDIA发布了Nemotron 3.5 Lightning，这是一个约300亿参数的MoE模型，其中约30亿参数处于激活状态，定位用于持续运行的代理工作负载。NVIDIA及生态系统帖子强调最高达4倍的吞吐量、100万上下文长度、开放/可定制的发布构件，以及在Hugging Face上支持权重、数据和配方@NVIDIAAI。Artificial Analysis提供了最详细的第三方总结：总参数316亿/激活参数36亿，采用OpenMDW-1.1许可，NVFP4和BF16权重，预发布端点测试中平均服务速度约670 token/秒，在其智能指数中得分24——与gpt-oss-120b相当但体积更小且速度更快@ArtificialAnlys。对于该规模的代理效果特别突出：GDPval-AA v2 Elo 824和Terminal-Bench v2.1 24%，均较Nemotron 3 Nano有显著提升@ArtificialAnlys。

• 分发与下游调优：Lightning 在整个技术栈中快速传播：Together AI、Ollama、Baseten、vLLM、Perplexity API 等。一个常见模式是将更便宜的执行模型与更强的规划模型结合：@kimmonismus 将 Lightning 描述为 NVIDIA 的“本地代理劳动力”，通过路由补充更大的规划模型。Harvey 报告称，在 Legal Agent Bench 上进行训练后，Lightning 在保留任务上的表现从 0% 提升至 8.3%，在该设置中超越了 Opus 4.6 和 Nemotron 3 Ultra，同时将平均输出从 90k 降低到 37k tokens @harvey 。总体而言，此次发布强化了当前开源模型的趋势：更小、更快的模型针对高吞吐量工具使用进行调优，而非通用聊天的声誉。

本地 AI 工具：Unsloth Desktop、Muse Glimmer 支持和 Linux Codex

• Unsloth Desktop 扩展了本地工具栈：@UnslothAI 发布了 Unsloth Desktop，这是一个开源的桌面应用，支持在 Mac、Windows 和 Linux 上本地运行和训练模型，支持范围包括 MLX、GGUF、扩散图像/视频、音频、CPU 和多 GPU 配置，以及兼容 OpenAI 的 API。值得注意的系统角度是其目标超越“本地聊天 UI”：支持工具调用、沙盒代码执行、私有搜索、RAG、MCP、导出功能，并声称训练速度提升 2 倍，VRAM 使用量减少 70%。多位观察者认为其定位是更完整的本地 AI 操作环境，而不仅仅是 LM Studio 的竞争对手 @TeksEdge ，@dessaigne 。

• 模型/运行时支持持续改进：开源/本地生态系统也迅速推进了 Meta Muse Glimmer 30B 和 Nemotron 的支持。@mervenoyann 强调了 llama.cpp 和 Transformers 中对 Muse Glimmer 的 DFlash 草稿支持，声称在小内存成本下生成速度提升 2-4 倍，随后很快发布了简单的 llama serve 指令 @mervenoyann 。在模型分析方面，@rasbt 对 Glimmer 进行了有用的架构解析：这是一个密集的 30B 多模态推理模型，具有混合本地/全局注意力机制，极端的 KV 缓存效率（按他的估计约为 52 KiB/token BF16），其设计更接近 Gemma 家族模式而非 MoE 竞品。

• OpenAI 终于推出了 Linux 桌面支持：OpenAI 宣布了 Linux 版 ChatGPT 桌面应用的预览版 @OpenAI ，支持 Ubuntu 24.04/26.04、Debian 13、Fedora 43/44，以及 x64 和 ARM64 包 @OpenAIDevs 。对现有代理用户更重要的是，桌面应用现在可以导入/同步其他代理中的项目、聊天、技能和插件到 ChatGPT Work 和 Codex，包括自动更新 @OpenAIDevs 。这看起来像是减少切换摩擦、使 Codex/Desktop 成为集成中心而非全新孤岛的尝试。

• 评估重点正转向长期、确定性、领域真实任务：LlamaIndex 发布了 ExtractBench，这是一个针对企业文档提取的确定性基准测试，覆盖 370 个文档 / 4,869 页 / 67 种文档类型。其最具行动价值的发现是，商用视觉语言模型（VLMs）在处理超过 50 页的文档时，虽然保持高精度，但召回率会降至 35% 以下，主要原因是静默行/列表截断。他们还在 LlamaParse 中引入了名为“Agentic Plus”的提取层级，声称其价值准确率可达 95.6%，成本仅为同类产品的三分之一。Artificial Analysis 发布了 AA-AnalystAgent，这是一个基于 80 项任务的智能代理基准测试，使用 pass^5 可靠性指标进行电子表格/文档定量分析。Claude Opus 5 以 54% 的成绩领先，其次是 GPT-5.5（50%）和 Claude Fable 5（49%）；Kimi K3 是表现最好的开源模型，得分为 39%。两个基准测试的共同主题是：可靠性与工作流正确性比单次推理能力更重要。

• 对基准测试的质疑声增强：@hrishioa 的一篇深入分析指出，许多现代评估测试更多是“凭感觉”设计而非严谨工程，导致评分机制失效、数据聚合错误，甚至出现可被利用的提示词/沙盒漏洞。这一批评在近期出现沙盒逃逸、外网访问和代理奖励机制被破解的报告背景下显得更加尖锐。另外，微软研究团队因其“提示阶段技能编译”成果引发关注：@xidulu 分享了在解码阶段免费使用前一隐藏状态的工作，而 @dair_ai 总结了另一篇论文，显示通过从历史轨迹中蒸馏出的紧凑自然语言技能，可在多个多步骤智能代理任务中恢复非推理模式与推理模式之间 55% 至超过 100% 的差距，通常输出 token 数量仅为原始方法的 2.7–6 倍。

基础设施、验证与系统研究

• 可验证推理正从理论走向产品化：@Yogi_Brn 发起了 Attestable 项目，获得 2000 万美元种子轮融资，主打实用的零知识证明技术以确保人工智能完整性。其核心主张是证明正确的模型在正确的输入上运行并调用了正确的工具，随着智能代理追踪记录变长，这种验证的价值将显著提升。@jaminball 表示团队已将零知识证明（ZK）的开销从此前不切实际的水平降低了多个数量级。@VitalikButerin 的回应值得关注：他估计当前方法在某些场景下可能已接近原始推理的个位数（<10×）开销，并将此视为向更强隐私保护推理架构迈进的里程碑。

• 跨硬件的确定性整数推理：来自 @nathanrs 的一篇技术性较强的系统研究论文指出，通过端到端使用精确整数运算而非让非线性操作回退到浮点数，实现了在 A100、H100、Apple M5 Max、AMD EPYC 和 Intel Xeon 等多种硬件上完全确定性的大语言模型推理。在 Qwen3-0.6B 测试中，所有整数运算在不同设备上生成的哈希对数完全一致，WikiText2 的困惑度为 20.72，相较 fp16 的 20.95 有所提升，A100 在批量 1 时的 CUDA 图解码速度达到 106 个 token/秒，声称是 fp16 焦虑模式基线的 3.6 倍。如果该方法具有鲁棒性，将对可重复性研究和证明友好型推理产生重要影响。

• 编译器/推理可移植性作为代理系统的目标：一个规模较小但反复出现的主题是“代理向堆栈底层迁移”。围绕@JvNixon和Infinity的帖子描述了自动化编译器/内存规划器/调试器工作流，用于在异构芯片上运行优化模型，支持者将软件生成的每芯片适配视为削弱CUDA护城河的方式。另外，基础设施供应商推出了更多渐进但实用的更新：Qdrant 1.19在关键字索引上增加了前缀匹配功能@qdrant_engine，Together + IBM + NVIDIA宣布在IBM Cloud上推出企业推理基础设施@togethercompute。

Top tweets（按互动量排序）

• 推理轨迹漏洞/隐藏CoT提取：来自@kotekjedi_ml的原始披露和后续隐私发现@kotekjedi_ml是当天最具影响力的几篇技术帖子之一。
• Grok Bot beta：xAI的代理产品发布@bot引发了最大的产品反响，主要是因为它指向了一种持续登录的AI协作者用户体验，而非简单的聊天机器人迭代。
• Linux平台ChatGPT桌面版+同步/导入功能：OpenAI的Linux桌面预览版@OpenAI和代理工作流导入/同步支持@OpenAIDevs在开发者群体中反响强烈。
• Nemotron 3.5 Lightning：Jensen的帖子@JensenHuang和NVIDIA的发布@NVIDIAAI标志着当天最重要的开源模型系统发布。

AI Reddit回顾

/r/LocalLlama + /r/localLLM 回顾

1. Meta Muse Glimmer 30B发布及本地基准测试

• 介绍Muse Glimmer：专为持续运行的本地代理工作流优化的开放权重模型（活动量：2435）：Meta发布了Muse Glimmer，这是一个采用Apache 2.0宽松许可的30B参数密集型多模态模型，专为持续运行的本地代理工作流设计，通过专用感知编码器实现文本/图像交织输入，支持100+语言训练、可控推理努力度，以及针对工具使用、长期推理、故障恢复的代理导向训练，并在DeepSearch QA、MCP-Atlas、τ³-Bench和SWE-Bench等基准测试中进行了验证。该帖子声称约4位量化可将LM压缩至<20GB，使模型能在24-32GB内存范围内与KV缓存、感知编码器以及基于DFlash的推测解码草案协同运行，且“输出质量完全一致”；权重/资源链接在Hugging Face、研究博客和开发者文档中。技术评论指出Alexandr Wang在X上表示即将发布开放权重的Muse Spark 1.2版本。评论总体积极但技术审查较少，表达了对Meta再次开放权重的兴奋，并开玩笑地将Muse Glimmer称为“llama 5”。有评论者引用Alexandr Wang在X上的声明，称Muse Spark 1.2的开放权重版本即将发布，这在技术上具有相关性，因为它暗示Meta可能会在Muse Glimmer之后推出更高层级或更新的开放权重版本。来源：x.com/alexandr_wang/status/2086756152034066792。

• Meta 发布 Muse Glimmer 30B - 一款新的开源模型（活动：450）：该图像展示了 Meta “Muse Glimmer-30B”的宣传基准图，该模型作为 Apache 2.0 许可下的全新开源权重 30B 密集视觉模型推出。它声称在 MCP Atlas、DeepSearch QA、SWE-Bench Pro、AIME 2026 和 SciCode 等代理/代码/数学/科学基准测试中，表现可与 Gemma 4-31B 和 Qwen3.6-27B 竞争，并宣传可通过 Unsloth Desktop 在 18GB 内存/显存配置上运行。评论者普遍对 Meta 重新推出开源模型表示欢迎，但有人对发布节奏表示怀疑，认为“Qwen 发布前可能成为同类中最强的代理模型，但仅维持约三天”，暗示 Qwen 的快速竞争将给 Meta 带来压力，迫使其提升发布速度。评论者将 Muse Glimmer 30B 视为 ~30B 密集模型类别中潜在的强代理模型，但预计会很快被 Qwen 的后续版本挑战；有评论者指出“Qwen 发布前可能成为同类中最强的代理模型，但仅维持约三天”。技术相关关注点在于发布节奏：Meta 被认为需要加快迭代速度，以保持与 Qwen 和其他开源模型实验室的竞争优势。一个实质性的生态系统问题是 ~30B 参数层级正变得拥挤，评论者提到 Qwen、Google、NVIDIA 和 Meta 都是该领域的活跃参与者。有评论者希望 Meta 在此次发布后推出同规模的 MoE 模型，这呼应了 Qwen 可能向该方向扩展的预期。

• Muse Glimmer 实际上可运行于单张 RTX 3090（活动：640）：用户报告称，Meta Muse Glimmer 30B Q4_K_XL GGUF 模型可在单张 24GB RTX 3090 上运行，配置包括 262144 上下文长度、DFlash 投稿机制、mmproj、FlashAttention 和 F16 KV 缓存，仅占用约 22–23GB 显存——与测试的 Q4_K_XL Qwen3.6-27B 和 Gemma-4-31B 不同，后两者在 F16 KV 模式下约 70k/52k token 或 Q8 KV 模式下约 125k/81k token 时即达到显存限制。他们在 DFlash 模式下测得生成速度约为 64–124 tok/s，提示处理速度约为 1400 tok/s，并在约 150k token 的双针检索测试中通过，表明模型并未有效限制在 128k 上下文长度；有评论者指出官方发布的 Muse-Glimmer-30B-GGUF 已针对 24GB/32GB 显存进行优化，另有用户报告称 KV 缓存使用非常紧凑：尽管所有层均启用 SWA，131k F16 上下文仍仅占用约 1.8 GiB。评论者对 KV 缓存效率感到意外，尤其是所有层均启用 SWA 的情况下；有人开玩笑称这可能进一步推高 RTX 3090 的需求和价格。用户强调，尽管所有层均启用 SWA，Muse Glimmer 的 KV 缓存似乎异常节省内存：有报告称 131k 上下文长度的 F16 KV 仅占用约 1.8 GiB，使长上下文操作在单张 RTX 3090 上成为可能。有评论者指出，官方 Meta GGUF 构建版本已针对 24GB 和 32GB 显存配置进行优化，包括 DFlash 支持，因此可能无需使用 Unsloth GGUF。所引用的官方仓库为 meta-models/Muse-Glimmer-30B-GGUF。另一份技术报告称，256k 上下文长度 + DFlash + mmproj 可在 RTX 3090 上约 22–23GB 显存中运行，观察到的吞吐量约为 64–124 tok/s。他们还指出，150k 针测试表现稳定，但质疑当上下文接近 200k+ 时性能和检索质量的表现。

• 1天的测试后，我感觉可以坦率地说Muse-Glimmer-30B在某些使用场景中已超越Qwen 3.6-27B（活动：709）：用户报告称，在经过约1天的测试后，Muse-Glimmer-30B在选定的24GB显存级GPU本地使用场景中似乎优于Qwen 3.6-27B，特别是在高效推理、低比特量化（据报道iq3_xxs的性能下降幅度小于Qwen/Gemma）、无工具的常识/知识深度以及OpenCode代理效率方面表现突出。他们仍认为其在通用编程任务上略逊于Gemma4-31B，但声称其在完成代理任务时的速度比3.6-27B更快，尽管任务成功率相近。评论者纷纷表示代理工作流/工具调用的早期效果非常显著，有评论者表示Muse-Glimmer-30B“差距甚远”，但也有其他人预计即将发布的3.8版本可能扭转这一局面。一项技术批评指出，美国模型可能在回答前会消耗大量token用于安全/自我验证。有评论者报告了数小时的AB测试结果，显示Muse-Glimmer-30B在代理工作流和工具调用方面显著优于3.6-27B，称“差距甚远”。另一位用户指出，改进效果在非编程任务中最为明显，而编程性能尚未得到验证。有技术担忧指出，安全/对齐前缀可能导致token效率低下：一位用户询问Muse-Glimmer-30B是否花费大量token来验证请求是否符合其政策框架。这一问题被描述为某些美国对齐模型的普遍问题，其中安全相关的冗长输出可能降低交互式或代理使用场景的实际吞吐量。多位评论者指出，由于预计即将发布的3.8版本可能很快推出，此次对比结果可能不会持续，3.8版本可能改变Muse-Glimmer-30B与3.6-27B之间的相对排名。一位持不同意见的评论者仍认为3.6-27B整体上是更强的基准模型，认为新模型的优势可能仅限于特定工作负载，而非普遍适用。

• Muse-Glimmer-30B 量化表现可能非常出色的早期迹象？分享你的使用体验。(活动量：354)：图片是来自 Unsloth AI 的社交媒体帖子，展示 Muse-Glimmer-30B-GGUF 在聊天/编码代理工作流中运行，可见工具调用，声称 2 位量化后的 30B 模型执行了 100 多次工具调用，同时仅使用约 14GB 内存：图片。在 Reddit 讨论中，用户质疑 14GB 是否对 30B 模型的“2 位”量化来说确实令人印象深刻，而另一位用户报告称在单个 RTX 3090 上运行 Q4_K_XL 的 Muse-Glimmer-30B 在代理编码任务中表现良好，大致与 3.6 27B 相当。评论者对 Glimmer 的量化/代理编码性能持乐观态度与对内存效率持怀疑态度的群体存在分歧。还有人担心该模型可能过度限制安全性，有用户提到模型拒绝执行移动鼠标指针的代码。一位用户报告称在单个 RTX 3090 上以 Q4_K_XL 运行 Muse-Glimmer-30B 进行代理编码，称其“表现优异”，在早期测试中大致与 3.6 27B 相当。另一位评论者指出，14GB 的“2 位”量化对于 30B 模型来说相对较大，暗示打包/量化格式可能包含大量开销或并非简单的 2 位权重占用。一个技术性关注点是 Glimmer 在 KV 缓存量化下的表现，尤其是从 fp16 到 q8_0 的退化是否类似于 Qwen 或 Gemma 风格的敏感性。评论者特别希望将 Glimmer 添加到 Anbeeld 的 KV 缓存基准测试方法中：KV 缓存量化基准测试 / KVARn 精度尾部。一位用户通过 vLLM 测试 BF16 模型时报告称与 Laguna-S-2.1 相比质量令人失望，称 Glimmer 做出许多 Laguna 不会犯的错误。他们建议结果可能是由于早期版本的问题，并计划在官方仓库/模型发布稳定后重新测试。

2. Qwen 3.8-27B 和 Ling-3.0 Tiny Open Weights

• Qwen 3.8-27B 本周发布（活动量：2791）：图片是官方 Qwen / Alibaba_Qwen X 账号的截图，确认 Qwen3.8-27B 开源权重将于本周发布，与帖子标题的声明一致。评论指出 ModelScope 上有 Qwen3.8-2.4T-A95B 的模型列表，注意到 ModelScope 是阿里巴巴旗下平台，并暗示发布时机/倒计时可能可信。评论者已经开始将期望与其他 Qwen 变体进行比较，特别是询问是否会发布类似 35B-A3B 的模型，因为据报道该模型在某些任务上表现良好且硬件占用空间小。评论者指出 ModelScope 上有 Qwen3.8-2.4T-A95B 的官方列表，倒计时约 1 天 9 小时，将其视为可信信号，因为 ModelScope 是阿里巴巴旗下平台：https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B 和 https://modelscope.cn/models/Qwen/Qwen3.8-2.4T-A95B/summary。有人对是否会发布类似 35B-A3B 的 Qwen 变体表现出兴趣，一位用户指出 35BA3B 在某些任务类型上表现“惊人”，同时保持硬件占用空间下的强大速度，暗示对更小的主动参数 MoE 风格模型的需求，而不仅仅是更大的密集模型发布。一位 Strix Halo 用户请求发布更新的 122B 版本，称当前的 Qwen 3.5 122B 感觉过时；这反映了对可能在高内存 AMD APU 平台上运行的非常大的本地模型的兴趣。

• inclusionAI/Ling-3.0-tiny · 8B A1.3B MoE· Hugging Face (Activity: 427): inclusionAI 发布了 Ling-3.0-tiny，这是一款 80亿参数的 MoE 模型，其中约 13亿参数处于激活状态，其性能定位介于 40亿参数与 8–120亿参数规模的 Qwen/Gemma 类密集模型之间。模型卡片显示，该模型在 DGX Spark 上的 FP8 吞吐量约为 100–105 token/s，在 M4 Pro MacBook 上为 86–90 token/s，8K 上下文长度下峰值内存约为 8.34 GiB；评论者还提到其支持 256K 上下文窗口，并在共享基准测试图像中获得 AA Bench 得分 25。有评论者认为该模型在近期 LFM 小型模型中表现优异：在 IFBench 得分 63.61、Multi-IF 得分 83.15、BFCL-v4 得分 62.72 等指标上均优于 LFM2.5-8B-A1B 和 LFM2.5-2.6B。评论者普遍对 tiny MoE 架构在低内存、移动端和边缘设备推理中的高 tokens/sec 性能表示认可，有评论者认为它可能在本地替代 Ling-Mini-2.0。用户对更大规模的 15–500亿参数 Ling 模型表现出兴趣，并推测通过推测解码技术，吞吐量可能接近扩散模型的响应速度。用户将 Ling-3.0-tiny 定位为一款 80亿参数的 MoE 模型，约 13亿参数处于激活状态，相比密集模型预计能实现更高的 tokens/sec，因此适合低内存、移动端和边缘部署。有评论者指出其在 AA Bench 上得分 25，认为对于该规模模型而言这一成绩具有显著意义。一项技术对比显示，Ling-3.0-tiny 在指令遵循和工具使用基准测试中优于近期 LFM 小型模型：在 IFBench 上 63.61 分 vs LFM2.5-8B-A1B 的 56.47 分，在 Multi-IF 上 83.15 分 vs 79.93 分，在 BFCL-v4 函数调用上 62.72 分 vs 49.73 分。该评论者强调，该模型在 80亿/13亿参数规模下支持 256k 上下文窗口，这是其关键差异化优势。用户对运行时兼容性表现出兴趣，特别是询问是否已支持 llama.cpp。另一位评论者建议，未来发布更大规模的 150亿–500亿参数 Ling 模型并结合推测解码技术，可能显著提升吞吐量，接近扩散式生成流水线的响应速度。

通过 7 天免费试用继续阅读

订阅 Latent.Space 以继续阅读本文并获得 7 天免费访问完整文章档案的权限。

开始试用

已经是付费订阅者？

上一篇

下一篇