AI 开发者日报

• Thinking Machines 宣布推出 Inkling，这是一款开源权重模型，能够“在文本、图像和音频模态之间高效推理”，完整权重已开放，并立即在其 Tinker 平台和 Playground 上获得支持 @thinkymachines。
• Mira Murati 将 Inkling 描述为公司的“首个模型”，“从零开始训练”，开源权重，并支持在 Tinker 上当天微调 @miramurati。
• Soumith Chintala 将其定位为 Thinking Machines 的“首个通用模型”，强调开源权重、975B 参数、原生多模态能力，并已在 Tinker、Hugging Face 及合作伙伴平台上可用 @soumithchintala。
• John Schulman 补充了时间线背景：预训练始于去年冬天，从 1 月中旬开始，一个小团队在其基础上构建了编码、推理和智能体训练能力 @johnschulman2。
• Lilian Weng 将 Inkling 描述为一个基础模型，旨在“在广泛的能力类别中提供稳定的性能”，并面向实际使用和定制化需求 @lilianweng。
• TML 团队成员反复强调，这是首日发布，是未来迭代的基础，而非他们的最终前沿突破 @soumithchintala, @cHHillee, @keirp1。
• 此次发布获得了异常广泛的日零生态系统支持，涵盖 vLLM、SGLang、Modal、Baseten、Databricks、Hugging Face 以及量化/社区工具链 @vllm_project, @lmsysorg, @modal, @baseten, @Yuchenj_UW, @huggingface, @danielhanchen。
• 独立评论人士立即将其评为迄今为止美国最强的开源权重模型发布，尽管在某些基准测试上仍落后于顶尖的中国开源权重模型和最佳闭源模型 @natolambert, @ArtificialAnlys, @scaling01。

模型规模、模态、许可协议与上下文长度

• Inkling 被报道为 975B 总参数 / 41B 激活参数，多数推文均引用此数据 @soumithchintala, @vllm_project, @ArtificialAnlys, @kimmonismus。一条推文称其为 974B @Yuchenj_UW，另一条称 952B @multimodalart；但推文集中压倒性的共识是约 975B。

该模型采用 混合专家（MoE）架构，每个 token 激活 41B 参数 @VictoriaLinML。 根据多方反应和总结，它采用 Apache 2.0 许可协议 @natolambert, @Yuchenj_UW, @multimodalart。 支持 文本、图像和音频输入，输出为 文本 @soumithchintala, @TheRundownAI, @ArtificialAnlys。 开源权重检查点支持高达 1M 上下文 @vllm_project, @lmsysorg, @ArtificialAnlys。 Tinker/API 上下文描述为 256K，定价按 64K 和 256K 上下文区分 @ArtificialAnlys。

训练与发布细节

• TML 表示 Inkling 是 从头训练 的 @miramurati, @LiorOnAI。
• 社区读者从发布材料中提取出 45T 训练 token @eliebakouch, @ArtificialAnlys，而一条推文称 48T @mervenoyann。本数据集中重复出现较多的数字是 45T。
• Inkling 包含 可控推理力度 / 数值化力度等级 @LiorOnAI, @TheRundownAI, @danielhanchen。
• Tinker 客户强调其推理简洁、工具调用能力强，而非一味追求原始基准测试成绩 @tinkerapi, @MichaelElabd。

社区反应中浮现的架构细节

多位技术背景深厚的用户从发布信息中提取了架构选择：

• 混合/滑动窗口注意力机制，局部与全局层比例为 5:1，窗口大小为 512 @eliebakouch, @ariG23498。
• 相对位置编码/相对注意力偏置 替代了 RoPE；多位发帖者称这是最具创新性的大规模选择之一 @stochasticchasm, @eliebakouch, @rasbt, @arohan, @ChangJonathanC。
• 在注意力/FFN 流周围添加了短卷积层；评论者指出这是短卷积的异常大规模应用 @eliebakouch, @stochasticchasm, @rasbt, @SonglinYang4。
• MoE 采用共享专家汇合机制 / 2 个共享专家，这被认为不常见，因为近期多数 MoE 使用 1 个共享专家 @eliebakouch, @ariG23498。
• 社区在解读架构时提到了 DeepSeek 风格的无辅助损失负载均衡 @eliebakouch。
• 从技术文档中推断出使用了 muP 和 Muon/权重衰减变体，并得到优化器专家的确认：Aaron Defazio 表示他们采用了他修正后的权重衰减方法 "MuonC/AdamC" @aaron_defazio，社区读者也指出了 muP @stochasticchasm, @Laz4rz。
• vLLM 强调了用于推测解码的 8 个 MTP 头 @vllm_project。

变体

• Inkling-Small 被多次提及，是一个即将推出或单独讨论的较小模型 @LiorOnAI, @teortaxesTex。
• 社区总结描述 Inkling-Small 为 276B 总参数 / 12B 激活参数，并在多项评估中出人意料地与更大模型不相上下 @eliebakouch, @nrehiew_。

独立基准评估

• Artificial Analysis 表示，Inkling 在**智能指数（Intelligence Index）**上以 41 分首次亮相，成为领先的美国开源权重模型，超越了 Nemotron 3 Ultra（38）、Gemma 4 31B（29） 和 gpt-oss-120b（24） @ArtificialAnlys。
• Artificial Analysis 还指出，Inkling 在每项智能指数任务中平均生成 25K 输出 token，而 GLM-5.2 max 为 43K、Kimi K2.6 为 38K、DeepSeek v4 Pro max 为 37K，因此被认为相对 token 高效 @ArtificialAnlys。
• Natolambert 称其为“相比 Nemotron Ultra 的明显升级”和“新的最佳美国模型”，但“在智能体基准测试上仍略逊于 GLM 5.2，在多模态方面落后于 Kimi K 2.6” @natolambert。
• Design Arena 表示，Inkling 在智能体 Web 应用竞技场（Agentic Web App Arena）中排名 第 9，Elo 1257，与 Claude Opus 4.6 和 Gemini 3.5 Flash 处于同一梯队，并称其为智能体工作负载中排名最高的美国开源权重模型 @DesignArena。
• Arena 在发布当天就将 Inkling 加入了智能体竞技场（Agent Arena）/ 文本 / 视觉 / 代码竞技场 @arena。

引用的具体基准数据

来自 Artificial Analysis：

• GDPval-AA v2 Elo 1238，高于 Kimi K2.6（1190） 和 DeepSeek v4 Flash max（1189） @ArtificialAnlys。
• τ³-Banking 24%，高于 Kimi K2.6（21%），略高于 DeepSeek v4 Flash max（23%） @ArtificialAnlys。

定性性能评价

正面评价：

• 推理“精准且简洁”，不啰嗦 @MichaelElabd。
• 在智能体任务中，工具调用能力强，且具备良好的长周期错误恢复能力 @MichaelElabd。
• 具有良好的“思维质量”/ 非谄媚风格 @skirano、@tinkerapi。
• Alex Kirillov 声称 Inkling 避免了许多全模态模型中常见的“音频输入 = 智能惩罚”问题，但另一位用户要求提供更有力的证据和基准测试支持 @alex_kirillov、@giffmana、@alex_kirillov。

偏混合 / 批评性评价：

• Scaling01 认为这些基准测试“并不出色”，将其描述为大致“另一个 Kimi-K2.6”，落后于所有闭源模型和 GLM-5.2，并推测该模型的发布时机可能是在 Kimi-K3 和 DeepSeek-V4-GA 之前 @scaling01。
• Stochasticchasm 表示，该模型“在多模态方面非常强”，但“在终端基准测试等方面并不特别突出” @stochasticchasm。
• JJitsev 对“唯一未使用蒸馏训练的开源权重模型”这一宣传提出质疑，指出 Inkling 使用了来自开源权重的蒸馏技术，并且在 TerminalBench 风格的评估中表现不如 GLM 5.2 @JJitsev。
• TeortaxesTex 提出了一个反向的正面观点：基准测试成绩平平可能反而意味着更少的偷工减料 / 蒸馏污染，以及更独立的数据处理流程 @teortaxesTex。

官方与合作伙伴基础设施动态

• NVIDIA 表示 Inkling 是在 GB300 NVL72 上训练的，并且发布当天就在 Hugging Face 上提供了 NVFP4 检查点 @NVIDIAAI。
• vLLM 宣布首日支持 NVFP4 和 BF16，针对 Blackwell 和 Hopper 进行了优化，在 4× GB200 配合 MTP 的情况下，每用户每秒吞吐量可达 380 tok/s @vllm_project。
• Inferact 详细介绍了系统层面的工作：支持 sconv 的张量并行分片、低延迟融合集合通信（bs=1 时速度提升 5 倍），以及直接集成了 TML 的 FA4 剪切偏置内核 @inferact。
• LMSYS/SGLang 表示已原生支持 Inkling 架构，包括 ShortConv、相对位置注意力、共享专家 Sink MoE、预填充全 CUDA 图、MXFP8 KV 缓存、自定义 Megatron 后端中的全参数和 LoRA 强化学习、路由重放、跨运行时参数同步，以及来自 Modal 的 DFlash 投机解码 @lmsysorg。
• Modal 表示，在 Modal 上运行 Inkling 时，使用自定义 DFlash 投机器 可实现 67% 的吞吐量和交互性提升 @modal。
• Soumith Chintala 另外强调，Modal 的 DFlash 投机器“比 MTP 快得多” @soumithchintala。

社区优化观察

• Lysandre 报告称，将 TML 的因果 Conv1D 替换为 causal-conv1d 后，吞吐量提升了 +4%；将注意力机制替换为 FlashAttention-4 后，又提升了 +11%，总计在不重新训练的情况下实现了约 15% 的吞吐量提升 @LysandreJik。
• Unsloth 发布了 1-bit GGUF 量化版本，据称体积 缩小了 86%（270GB 对比 1.9TB），同时保留了 74.2% 的 top-1% 准确率，并支持视觉和音频 @danielhanchen。

• Artificial Analysis 列出的 Tinker 定价如下：

64K 上下文：输入 $1.87 / 1M tokens，缓存 $0.374，输出 $4.68

• 256K 上下文：输入 $3.74 / 1M tokens，缓存 $0.748，输出 $9.36 @ArtificialAnlys

可通过 Tinker、Hugging Face 以及包括 Databricks、Baseten、Modal、vLLM/SGLang 在内的发布合作伙伴获取 @soumithchintala，@Yuchenj_UW，@baseten，@modal。

发布及合作伙伴直接支持的事实性声明

• 开放权重/完整权重已发布 @thinkymachines
• 从头开始训练 @miramurati
• 总计975B参数 / 41B激活参数的MoE架构，支持文本-图像-音频多模态输入，权重版本支持1M上下文，Tinker/API版本支持256K上下文 @soumithchintala，@ArtificialAnlys
• Apache 2.0许可证 @natolambert，@Yuchenj_UW
• 预训练始于去年冬天；智能体/编程/推理相关工作于1月中旬启动 @johnschulman2
• 主流推理服务栈首日即提供支持，vLLM/Inferact/Modal/NVIDIA均给出了具体性能声明 @vllm_project，@inferact，@modal，@NVIDIAAI

解读与观点

• "美国最佳开源模型"/"拯救了美国开源前沿模型"——这些判断虽被多位资深观察者重复提及，但仍属主观评价 @natolambert，@karinanguyen，@saranormous
• 关于Inkling因非从OpenAI/Anthropic蒸馏而特别重要的说法存在争议。Jxmnop称其为"唯一"未经过蒸馏的开放权重模型 @jxmnop，随后部分收回："显然他们确实做了蒸馏哈哈，但只有一点点" @jxmnop。Andrew Carr也质疑了这种"纯净"说法，指出其使用了Kimi 2.5进行SFT轨迹训练 @andrew_n_carr
• 关于Inkling在中国模型发布前"仓促推出"的说法，来自批评者的猜测，发布材料中并无证据支持 @scaling01
• 关于相对注意力机制因反向传播困难而为TML构建了微调护城河的说法，纯属推测 @typedfemale
• 关于Inkling避免多模态智能损失的说法前景可期，但在推文集中尚未完成完整的基准测试验证 @alex_kirillov

支持/看涨

• 开放权重与宽松许可的战略胜利： 许多人认为 Apache-2.0 许可的发布是对美国/西方开放生态系统的重大推动 @latkins，@saranormous，@brexton，@hyperindexed。
• 定制化优先于榜单追逐： 研究人员和开发者称赞 Inkling 被明确定位为一个广泛可调的基础模型，而非追求基准测试满分的点解决方案 @gneubig，@ben_burtenshaw，@thealexker。
• 发布质量过硬： 多位用户赞赏其透明度、务实的基调以及详尽的技术文档 @lvwerra，@saranormous，@rasbt。
• 架构创新引人关注： 非 RoPE 位置编码的选择以及缩放短卷积的使用引起了积极关注，这证明 TML 愿意在架构上做出有意义的押注 @stochasticchasm，@rasbt，@ChangJonathanC。

中立/分析

• 整体实力强劲但并非顶尖： 最平衡的评价认为 Inkling 已成为美国开放权重模型的新领导者，但在某些方面仍落后于 GLM/Kimi/DeepSeek 或顶尖闭源模型 @natolambert，@ArtificialAnlys，@stochasticchasm。
• 优秀的基础模型策略： 多位分析师将此次发布解读为一种系统/商业层面的举措：先发布一个扎实、高效、可后续训练的基础模型，然后让 Tinker 以及下游的强化学习/微调来创造差异化优势 @ben_burtenshaw，@kimmonismus，@tinkerapi。

批评/怀疑

• 整体未达前沿水平： 批评者认为它仍明显落后于顶尖的中国开放权重模型和最强大的闭源模型 @scaling01，@JJitsev。
• "纯净"宣称言过其实： 一些反对意见集中在关于该模型"纯净"或非蒸馏的夸大宣传上；相关讨论中既有吹捧也有纠偏 @jxmnop，@jxmnop，@andrew_n_carr，@JJitsev。
• 基准测试表现平平令人担忧： 一些读者认为，中等的基准测试表现可能说明它只是落后于当前中国开放前沿模型，而非开创了一个新的前沿 @scaling01。

• 首个TML公开模型： 这是Thinking Machines在备受期待数月后，首次真正向外界发布模型。该实验室由前OpenAI领导者和研究人员组成。因此，选择开放权重这一做法本身就引人注目 @Hesamation，@TechCrunch。
• 美国开放权重模型回应中国势头： 许多评论将Inkling与GLM、Kimi、DeepSeek和Qwen进行直接比较。此次发布正值业界担忧西方开放权重模型在能力和发布节奏上落后于中国模型之际 @scaling01，@teortaxesTex，@sriramk。
• 开放基座+后训练栈策略： TML的对外传达强烈暗示了一种策略，类似于“先发布一个能力扎实的开放基座，然后通过定制化/微调/强化学习基础设施来实现差异化”。这与Tinker的发布策略以及用户反馈中强调的可控推理、简洁输出和适应性调整（而非追求原始排行榜领先地位）相吻合 @thinkymachines，@MichaelElabd，@ben_burtenshaw。
• 推理生态系统的成熟： 此次发布也展示了开放推理栈已经发展到何种程度。一个万亿级多模态MoE模型，包含新的架构组件和多项内核级优化，能够在发布首日就获得支持，这在一年前是难以想象的 @vllm_project，@inferact，@LysandreJik。
• 大规模架构实验： 采用相对位置偏置替代RoPE，以及大规模使用短卷积，这类选择是研究人员密切关注的方向。如果这些设计在规模化训练和后训练中被证明是稳健的，它们可能预示着未来的架构趋势 @stochasticchasm，@rasbt，@ChangJonathanC。
• 发布风格本身即是信号： 多位评论者称赞了此次发布异常克制的措辞、明确承认该模型并非最强模型的态度，以及详尽的技术说明。对于专业受众而言，这种风格相比那些过度追求基准测试成绩的发布，提升了可信度 @eliebakouch，@lvwerra，@thealexker。

• Perplexity 的 SPACE 沙箱平台：@perplexity_ai 正式发布了其自研沙箱平台 SPACE，目前已承载 100% 的 Computer 生产流量。该平台在系统设计上的一个亮点是，将会话状态与可丢弃的 Firecracker 微VM沙箱进行解耦，并通过滚动快照实现了暂停/恢复/分支等语义操作。@perplexity_ai 报告称，沙箱创建的中位延迟从 185 毫秒降至 60 毫秒，P90 延迟从 447 毫秒降至 89 毫秒。此外，@zbraniecki 解释了其背后的技术细节：采用磁盘快照加完整 VM 检查点、利用对象存储实现可恢复性，以及使用 Btrfs COW（写时复制） 将沙箱创建从完整的镜像拷贝操作转变为元数据操作。这是本次披露中最为具体的基础设施生产实践之一。

• 智能体工作空间、Slack 原生智能体与编排成本：在产品层面，@istdrc 发布了 Raft 1.0，将其定位为一个共享工作空间，智能体在其中更像是一个团队在消息应用中协作，而非孤立的终端会话。@LangChain 升级了 Fleet in Slack，支持一键将智能体部署到频道/线程中，并具备自定义身份和文件交接能力，@hwchase17 也对此表示认同。在工程层面，@AI21Labs 提出，编排（harness）设计而非仅仅模型选择，会显著影响成本。他们引用 Writer 的“编排效应”（Harness Effect）指出，在质量持平的情况下，仅改变编排方式就能实现每任务成本降低 41%，并链接到其自身的早停（early-stopping）研究成果，声称可为 SWE 智能体减少高达 44% 的计算量。相关的工具链动态还包括：@nutlope 推出了 TogetherLink，可在 Codex 和 Claude Code 等编码编排工具中运行开源模型；@Teknium 则将 Blender MCP 添加到了 Hermes 智能体目录中。

• OpenAI的GPT-Red与安全飞轮：@OpenAI 推出了 GPT-Red，这是一个内部自动化红队测试工具，用于大规模发现提示词注入漏洞。最具体的成果是，针对GPT-Red进行对抗训练后，GPT-5.6 Sol 的鲁棒性显著提升。OpenAI 表示，重放强攻击后，其失败次数比四个月前的最佳生产模型减少了6倍。在 OpenAI的后续推文 中，明确提出了更宏大的框架——AI系统正在提升未来AI系统的安全性。外部评论方面，@omarsar0 称这是一个高投资回报率的自我改进循环。

• Anthropic的错位场景与DeepMind治理辩论：@AnthropicAI 发布了 《2026年夏季的智能体错位》，在之前勒索案例研究的基础上，新增了四个关于自主智能体不良行为的模拟场景。与此同时，围绕Google DeepMind的治理讨论愈演愈烈：@Turn_Trout 宣布因DeepMind在军事用途上缺乏对杀人机器人或大规模监控的限制而辞职；而 @jackclarkSF 和 @Yoshua_Bengio 则放大了Demis Hassabis关于第三方测试和标准应纳入政策的呼吁。@BlackHC 简洁地指出了这种对比——公开支持标准与内部对治理实践的不满并存。

• Soofi S / Nemotron 数据污染争议：最尖锐的评估争议围绕 Soofi S 30B-A3B 的声明展开。@kimmonismus 将其描述为一个基于 NVIDIA 开源 Nemotron 3 Nano 架构、在欧洲训练的模型，使用了约 27T tokens 进行训练，并加入了德语权重提升，且完整公开了训练配方。但多位批评者对其创新性和评估完整性提出了质疑。@JJitsev 认为，该对比降低了 Nemotron 相对于原始报告的参考分数；而 @eliebakouch 则指控其训练数据中包含了 GPQA Diamond 评估集的轻度改写版本，可能导致基准测试数据污染，从而夸大了性能差距。他在后续推文中将问题总结为“对每个 GPQA Diamond 评估项进行了 10 个 epoch 的极轻度改写”。即便是持怀疑态度的人也提出了一个直接的解决方案：按照 @JJitsev 的建议，重新运行原始的 Nemotron 训练配方，然后在完全相同的评估条件下进行比较。
• 迈向更好评估与可复现性的更广泛趋势：多篇帖子从更宏观的角度探讨了评估方法论。@arena 推出了一个基于事实性加权的排名，将人类偏好与声明验证相结合，基于文本和搜索竞技场中 200 万+ 条已标注声明；据报道，GPT-5.5 在事实性加权下提升最大，而一些偏好优化模型则排名下降。@askalphaxiv 和 @abidlabs 发起了一项由 Hugging Face 支持的、围绕 ICML 2026 论文的可复现性挑战赛，社区早期进展已成功复现了数十篇论文。此外，@sayashk 宣布了一场博士讲座，标题直指 “AI 评估中缺失的科学”。

以下是今日 AI 领域最受关注的技术动态（按互动热度排序）：

1. Inkling 发布：@thinkymachines 宣布 Inkling 成为今日最受关注的技术新闻。该项目发布了一个约 1 万亿参数的开源权重多模态 MoE 模型，并配套了广泛的开放推理部署方案。

2. OpenAI 的 GPT-Red：@OpenAI 发布 GPT-Red 公告，内容扎实：实现了自动化提示词注入红队测试，并声称在 GPT-5.6 Sol 上取得了6 倍的鲁棒性提升。

3. Claude Code 的 artifacts + MCP：@ClaudeDevs 推出了可调用 MCP 连接器的 artifacts，使 artifacts 真正成为面向每个观众的实时应用或仪表盘，并支持基于权限的数据访问。

4. Perplexity SPACE：@perplexity_ai 和 @AravSrinivas 罕见地公布了智能体沙箱的详细生产数据，包括尾部延迟提升 5 倍的声明。

5. DeepMind 治理层辞职：@Turn_Trout 的辞职长文 成为当天互动量最高的 AI 政策相关帖子之一，核心围绕军事用途限制与实验室治理公信力问题。

1. Bonsai 27B 与本地推理加速

• Bonsai 27B: 使用自定义 WebGPU 内核在浏览器中本地运行的 1-bit 稠密大模型（热度：731）：PrismML 发布了 Bonsai 27B，这是一个 1-bit 稠密大模型，旨在通过自定义 WebGPU 内核在浏览器中本地运行。模型文件已上传至 Hugging Face，并提供了 WebGPU 演示空间。官方声称压缩率从约 54GB 降至 3.8GB（压缩 93%），同时保留了约 90% 的基准能力。评论者指出，基于 Qwen/Qwen3 的 27B 变体实际占用约 5.7GB，并表达了在消费级 GPU（如 8GB 显存的 RTX 3070 笔记本 GPU）上测试的兴趣。评论整体积极，但关注点集中在规模化问题上：1-bit 量化能否让 80–100B 参数规模的模型变得实用，以及在单张 24GB GPU 上，参数与上下文长度的权衡如何适配 256k+ 的上下文窗口。还有一种观点认为，近期 1-bit 模型的发布表明行业正朝着超低位宽大模型部署的方向转变。

评论者重点讨论了标题中的压缩数据：Bonsai 27B / Qwen 3.6 27B 级别模型在 1-bit 密度下仅占用约 5.7GB，能力损失仅约 5%。一位用户明确计划在 8GB 显存的笔记本 RTX 3070 上测试，这表明主要的实际关注点在于自定义 WebGPU 内核能否让 27B 稠密模型在消费级显存预算下可用。

• 一条技术性较强的讨论线程聚焦于规模化问题：用户希望看到 80B–100B 的 1-bit 稠密模型，但也指出真正的瓶颈在于将权重和 256k+ 上下文的 KV 缓存占用同时塞进单张 24GB GPU。这说明 1-bit 权重只是内存故事的一部分；即使模型权重被高度压缩，长上下文推理仍可能成为实际部署的主要限制。
• 一位评论者区分了从头训练的 1-bit 模型与极端的训练后量化，认为前者应该比简单地将更大模型量化到 1-bit 保留更多能力。他们提出，未来一个原生以该精度训练的 1-bit 70B 模型，既能在消费级 GPU 上运行，又具有实际可用性，这与许多重度量化的超低位宽模型不同。

PrismML 的新型三元 Qwen3.6 27B 在 10GB 内存上接近 fp16 精度运行!!!（热度：465）：PrismML 发布了 Bonsai 27B，这是 Qwen3.6 27B 的三元/BitNet 风格变体，提供 GGUF 和 MLX 构建版本，目前需要使用 PrismML 的 llama.cpp / mlx 分支。原帖作者报告在 M4 Pro 上 32K 上下文下内存占用约 10GB，并声称该模型远优于传统的 2-bit 量化，但后续编辑澄清其表现优于 Q2，但不如 Q4_K_XL，且存在幻觉和工具调用循环问题；其主要价值在于内存占用，而非 fp16 级别的精度。声称的能力包括 256K 上下文和多模态输入，dFlash 支持即将推出；白皮书见此处。评论者对 “接近 fp16 精度” 的表述提出质疑，因为三元权重是 {-1,0,1}，并批评其炒作/AGI 框架在技术上有误导性。一个技术问题是，同样的三元方法能否扩展到更大的模型（如 GLM 5.2），同时保持可接受的质量损失。

• 一位评论者质疑 三元 / 1-trit Qwen3.6 27B 能以 “接近 fp16 精度” 运行的声称，指出 PrismML 的前提是超低位宽表示，并询问该短语在此上下文中的技术含义。他们还反对随意使用 AGI 一词，认为即使像 Mythos 这样更强的模型，在没有证据的情况下也不应被贴上该标签。
• 一位用户报告通过 PrismML 的 llama.cpp 分支成功本地运行了 Ternary-Bonsai-27B-Q2_0.gguf，使用了 -ngl 99 和非常大的 -c 200000 上下文。在一个简单的 TypeScript 解释提示词测试中，他们观察到 243.5 t/s 的提示词处理速度和 89.1 t/s 的生成速度，表明该模型至少在其设置下是可运行且快速的，尽管该示例并未验证质量声称。
• 另一位评论者要求提供严格的基准测试，如 SciCode 或 SWE-rebench，以支持三元模型接近 BF16 且比同类 2–3 bit Qwen3.6 27B 量化版本 “智能得多” 的声称。他们还询问该方法是否适用于 MoE 或更大的稠密模型（如 Mistral Medium 3.5），并指出具有 >10B 活跃参数的超大 MoE 模型（如 Step 3.7 Flash 和 MiMo V2.5）通常表现出异常的抗量化特性。

苹果与初创公司 PrismML 洽谈，旨在压缩 AI 模型以在 iPhone 上运行（热度：362）：CNBC 报道苹果正在与 PrismML（一家加州理工学院衍生公司）进行早期谈判，内容涉及极端的大模型压缩技术，用于 iPhone 端侧推理。PrismML 据称将 阿里巴巴 Qwen 27B 从约 54 GB 压缩至... 评论者对仅凭小尺寸就能证明实用性表示怀疑，一位用户询问压缩后的模型是否 “真的能做一些有用的事情。” 另一位用户表示失望，因为他们刚刚测试了 PrismML 的 q1 bonsai 模型，担心苹果可能收购或限制该技术。

• 评论者指出，PrismML 的公开材料似乎缺乏评估其压缩/量化声称所需的关键技术细节：转换成本、三元/二进制转换是否能可靠地达到收敛点、是否使用了蒸馏技术、以及训练后是否已充分饱和模型。有人提到了 BitCPM-CANN 技术报告作为对比，评论者认为除了 bitnet-b1.58-2B-4T 之外，几乎没有从头正确训练的三元模型先例。
• 几条评论质疑 PrismML 宣传的小模型尺寸是否能转化为实际能力。一位用户表示他们一直在测试该公司的 q1 bonsai 模型，而另一位用户则指出他们反复看到关于紧凑性的声称，但几乎没有证据表明该模型 “真的能做一些有用的事情。”

ExLlamaV3 v1.0.0 - 重大性能升级（热度：422）：该图片是一张技术基准测试表（PNG），展示了 ExLlamaV3 v1.0.0 在 RTX 3090 上与 v0.0.43 相比，在多种量化大模型/位宽下的解码吞吐量提升。该表支持了关于重大推理内核升级的发布声称：v1.0.0 mul1 显示出大幅加速，例如 Qwen 3.6 27B 从 29 tok/s 提升至 50 tok/s（+72%），Qwen 3.5 0.8B 从 268 tok/s 提升至 444 tok/s（+66%），这与帖子中关于新注意力、GEMM/GEMV、INT8 GEMV、Conv1D 和 MoE 调度器内核的说明一致。评论大多表示赞赏而非深入技术讨论，强调 ExLlamaV3 是一个专注于 NVIDIA GPU 的大模型推理引擎，使用 EXL3 格式而非 GGUF/llama.cpp，并赞扬了 Turboderp/Fable 所做工作的规模。

• 一位评论者澄清，ExLlamaV3/ExLlama3 是一个大模型推理引擎，针对专门的 EXL3 模型格式而非 llama.cpp 常用的 GGUF 文件，并且目前仅支持 NVIDIA GPU。这一区别对部署兼容性很重要：使用现有 GGUF 工作流的用户可能需要单独的量化权重和 CUDA 兼容硬件才能使用它。
• 一个技术请求聚焦于 TabbyAPI 集成，特别是改善与 Claude Code 的工具调用兼容性，以便 ExLlamaV3 可以在该工作流中本地使用。同一位评论者提到他们目前正在使用 GGUF with MTP，并有意评估 EXL3 量化与其当前设置之间的质量权衡。

• Thinking Machines 发布首个开源权重模型 "Inkling"（热度：1082）：该图片展示了一个 AI 模型排行榜，突出显示了 Thinking Machines 的首个开源权重模型 Inkling，得分 1257，大致处于中游水平，与 Claude Opus 4.6 持平，低于 GPT-5.6 Sol，远低于排名靠前的 Claude Sonnet 5（得分 1333）。根据公告和评论，Inkling 被描述为一个 MoE Transformer，总参数量 975B，激活参数量 41B，上下文窗口高达 1M token，并在 45T 多模态 token 上进行了预训练，涵盖文本、图像、音频和视频；预览版 Inkling-Small 的激活参数量为 12B，成本和延迟更低。评论者对此感兴趣，因为 Thinking Machines 与一位前 OpenAI CTO 有关联，并且正在发布开源权重，但一些人持怀疑态度，认为如果 Inkling 的性能不能超越 GLM-5.2 等竞争性开源模型，其广泛采用将面临挑战。

Inkling 被描述为一个稀疏 MoE Transformer，总参数量 975B，激活参数量 41B，上下文窗口 1M token，并在涵盖文本、图像、音频和视频的 45T token 上进行了预训练。一位评论者将其与 GLM-5.2 进行了不利比较，认为尽管它具备多模态和长上下文能力，但如果不能超越该开源权重竞争对手，其采用率可能有限。

• 最具技术趣味的讨论集中在 Inkling-Small 上：一个总参数量 276B、仅 12B 激活参数的 MoE 模型，定位为低延迟/低成本变体。评论者强调，由于预训练数据混合和配方的改进，据报道它 "在许多基准测试中达到或超越了其更大的兄弟模型"，这使得与 41B 激活参数的主模型相比，它在本地推理方面更具实用性：https://thinkingmachines.ai/news/introducing-inkling/#inkling-small

• 一些评论者指出了模型尺寸阵容中的空白：缺少大约 30B 稠密/激活参数类别的模型，而一些本地推理用户认为这是一个有用的中间地带。此次发布直接从激活参数 12B 的 MoE 模型 Inkling-Small 跳到了激活参数 41B 的 MoE 主模型 Inkling。

• 德国 AI 联盟发布 Soofi S，一个在英语和德语基准测试中均名列前茅的开源 30B 模型（热度：321）：Soofi S 被介绍为一个由德国主导、完全预训练的 MoE 大模型，总参数量 31.6B / 激活参数量约 3.2B，基于 NVIDIA Nemotron 3 Nano 的混合 Mamba-2/Transformer 架构，在约 27T token 上训练，其中德语权重得到提升，并声称在 4K 到 256K 上下文范围内吞吐量近乎恒定（文章，论文）。评论者指出，它被描述为 一次全新的完整预训练运行，而非微调，并提供了异常透明的工件，包括 W&B 训练日志、训练脚本以及需要授权的 GGUF / 推理 GGUF 发布。提出的技术问题包括：除 RULER 之外缺乏现代长上下文评估，可能因 "机器翻译和合成生成的德语文本" 导致的德语自然度问题，以及基准测试的模糊性——因为编码/数学任务和德语理解可能会夸大语言质量声明；一位评论者还声称，Qwen3.5 35B-A3B 在德语基准测试上击败了 Soofi S，尽管它并非专门针对德语优化。主要的争论点在于基准测试比较是否可信：评论者批评其遗漏了 Qwen 3.6/Gemma 4 等更新的基线模型，并与较旧的模型进行比较。另一个问题是许可协议：营销声称 "自主可控、开源……免许可使用" 与 Hugging Face 模型卡上使用的自定义 "Other" 许可协议相冲突，据报道该许可协议的完整文本缺失。

• 一位评论者指出，Soofi S 被描述为 一个全新预训练的模型而非微调模型，其架构基于 Nemotron 3 Nano，完整的预训练/附加阶段在论文、W&B 训练日志和训练脚本中均有记录。他们提醒说，源自 Nemotron 的架构可能会限制长上下文的准确性：该发布包含一个 RULER 测试，但显然缺乏更现代的长上下文评估。

• 几位评论者对基准测试的框架提出质疑，认为 Soofi S 是与较旧的基线模型进行比较，而非 Qwen 3.6 或 Gemma 4 等较新的模型。一位评论者强调，作者自己的结果显示 Qwen3.5 35B-A3B 在德语方面优于 Soofi S，这表明该基准测试可能更多地衡量广泛理解、数学和编码能力，而非母语级别的德语生成质量。

• 数据混合被标记为潜在问题，因为论文提到了 "机器翻译和合成生成的德语文本"，这可能会产生不自然的德语，并可能影响生成质量，尽管基准测试成绩有所提升。发布的工件似乎也不完整或不一致：存在 Soofi-S-Instruct-Preview 和 Soofi-S-Rhine-Preview 等推理变体的 GGUF 构建，但它们需要授权，并且许可协议被描述为自定义/"Other"，完整文本显然缺失。

• KAT-Coder-Air V2.5 - 开源模型即将到来（热度：262）：该图片是 KwaiAI/KAT-Coder 社交媒体帖子的截图，宣布了 KAT-Coder-Pro V2.5，更重要的是，对于 r/LocalLLaMA 社区，一条回复称 KAT-Coder-Air V2.5 将"很快"开源。 该帖子链接到 OpenRouter 上的可用性以及 arXiv 上的技术报告（摘要，PDF），声称在长周期和智能体编码性能方面有所提升；一位通过 OpenRouter 测试了它的评论者推测其参数量 低于 100B。评论主要是出于好奇：用户正在等待实际的开放权重，并询问模型大小，一位测试者指出它已经可以通过 OpenRouter 使用，但尚未确认架构或参数量。

• 一位声称询问过权重的评论者报告说，KAT-Coder-Air V2.5 已经在 OpenRouter 上可用，根据他们的使用情况/元数据，"应该低于 100B 参数。" 该帖子中主要的技术不确定性是模型的确切参数量/大小，用户们正在等待权重发布后进行验证。

• Google 正在更新 Gemma 4 的聊天模板，带来工具调用的重大修复并减少"懒惰"行为，在 Hopper GPU 上启用 Flash Attention 4，以及一个关于如何使用和改进其视觉能力的交互式指南！（热度：513）：Google Gemma 通过 X 宣布了对 Gemma 4 聊天模板的更新，旨在提高工具调用的正确性并减少"懒惰"行为，同时还在 Hopper GPU 上启用 Flash Attention 4，并在 Hugging Face Spaces 上发布了一个交互式 Gemma 视觉 token 预算指南。一位评论者链接了相关的 google/gemma-4-31B-it 提交，其中包括对 null 处理、推理/思考保留、轮次标签平衡、工具响应延续、add_generation_prompt 回归、额外 `` 输出以及仅工具调用轮次关闭的修复；值得注意的是，preserve_thinking 被恢复/设为默认值，并限定在工具调用轮次范围内。评论者认为此次更新解决了 Gemma 4 在提示词/工具使用方面令人困惑的先前行为，其中一位表示他们曾以为这些失败是用户错误。最受关注的反应是对包含 preserve_thinking 支持的热情。

• 一位评论者列举了 Hugging Face 提交级别上针对 Gemma 4 31B IT 聊天模板的修复，包括 null 处理、推理保留、轮次标签平衡、输入验证、在工具响应后恢复模型轮次/思考提示，以及修复助手内容中额外 `` 输出和工具调用延续路径的问题。链接的提交列表始于 68abe480，值得注意的修复包括 preserve_thinking、使思考通道独立于 tool_calls，以及纠正仅工具调用轮次的关闭。

• 该帖子中的一个技术要点是，工具调用行为似乎受到模板级别序列化错误的严重影响，特别是在保留推理/思考通道以及在工具响应后正确重新打开助手生成方面。然而，另一位评论者报告说，使用最新的模板，感知到的"懒惰"行为仍然存在，认为这很可能是一个模型行为问题，而非聊天模板问题。

开放模型政策与自托管风险

1. 特朗普政府与行业讨论：简化美国开放模型发布

• 消息来源：特朗普政府与行业团体讨论简化美国开放模型发布，能力不高于中国领先的开放模型（热度：573）：据报道，特朗普政府与行业讨论将简化美国开放模型的发布流程，这些模型的能力需等于或低于中国领先的开放模型。此举源于对美国开发者采用中国本地/开放权重模型的担忧。由于原始链接返回了验证码/HTTP 429 拦截页面而非文章内容，该消息来源无法从提供的存档页面验证。评论者认为，美国AI公司发布与中国竞争的开放模型动力不足，因为强大的本地模型可能会蚕食付费API/SaaS收入。其他人对中国开放模型包含可被中国共产党利用的后门的说法表示怀疑，指出如果这种模型级别的后门切实可行或可被检测，美国实验室很可能早已在开放权重替代方案中占据主导地位。

• 多位评论者认为，一旦权重在全球范围内被镜像，禁止功能强大的开放权重模型在技术上无法执行：单个种子追踪器、私人文件共享或USB传输即可绕过限制。一位评论者指出，执行禁令可能需要极端的下游控制措施，例如没收或限制超过特定VRAM阈值的GPU/工作站，因为一旦获得权重，推理就可以在本地运行。

• 一个反复出现的技术政策论点是：如果美国希望企业避免使用中国本地模型，切实可行的替代方案是发布能力相当或更优的美国开放权重模型，而非限制访问。评论者建议，这需要紧密匹配中国开放模型的质量轨迹，使本地部署用户无需依赖外国权重。

• 一位评论者特别提到NVIDIA Nemotron是一种更好的模型发布模式，因为其训练数据/过程相对透明，同时指出Nemotron 3 Ultra“非常好”，但似乎训练不足，因此在其参数规模下表现欠佳。多位评论者对中国开放权重模型中存在故意“后门”的说法持怀疑态度，认为如果这种隐藏的模型级后门易于武器化，美国实验室早已在开放模型中利用同样的技术。

2. 自托管AI：数据保护的必要性

• 有些人想知道为什么会有人自托管AI。你会接受微软CEO的意见吗？（热度：559）：该帖子主张将自托管AI/LLM作为数据保护策略，引用了一篇TechCrunch文章，其中引用微软CEO萨提亚·纳德拉的话称，企业可能会“为智能付费两次”：一次是费用，另一次是暴露使托管AI有用所需的专有业务知识。技术上的担忧是，API/SaaS模型提供商（如OpenAI或Anthropic）可能会摄取敏感的提示词、文档、工作流或RAG语料库，并可能获取竞争情报，这使得本地推理或私有部署对处理知识产权敏感数据的发明者、研究人员和企业具有吸引力。热门评论对纳德拉的框架持怀疑态度，认为这可能是Azure托管AI的销售话术，而非中立的隐私警告。其他人指出微软自己的产品——Copilot、OpenAI合作伙伴关系以及Recall等屏幕索引功能——证明微软有类似的动机和隐私风险。

• 评论者将萨提亚·纳德拉的自托管论点解读为，与其说是纯粹的去中心化，不如说是企业工作负载迁移到微软Azure上，即企业在微软云中“托管”私有模型，而非完全在本地运行。

• 多位评论者将自托管/隐私讨论与微软自己的AI产品联系起来，特别是Copilot和有争议的Windows Recall功能，后者因持续截取用户活动快照以供后续AI驱动索引而受到批评。提出的技术担忧是，云连接助手为敏感业务数据创造了巨大的攻击面，即使它们被营销为生产力工具。

• 一个反复出现的技术担忧是，企业AI供应商可能会将客户交互或文档用作训练/评估数据，一位评论者询问实验室如何每年继续获取50-100T新token用于模型训练。这一观点被框定为企业可能更倾向于自托管或严格控制部署以减少IP泄露和数据重用风险的原因。

3. 本地模型与开源工具链的必要性

• 这就是我们需要本地模型和开源工具链的原因（热度：379）：该图片（截图）显示了International Cyber Digest的一项声明，称xAI的Grok Build CLI将整个Git仓库——包括私有代码和未编辑的密钥——上传到了Google Cloud存储桶，后来通过一个隐藏的服务端标志禁用了该功能。该帖子利用这一所谓的泄露事件，主张采用本地优先/开放权重模型、确定性的开源代理工具链、私有VPC执行，以及在任何第三方网络出口前可以检查和编辑密钥的治理层。评论者对云连接的编码代理普遍持怀疑态度，将其定性为潜在的间谍软件/恶意软件行为，并指出如果数据外泄是故意的，应追究法律责任。一个反复出现的观点是，用户应该预期不透明的供应商控制AI工具会存在糟糕的数据处理实践。

• 一位评论者描述了通过使用与互联网隔离的自托管Git服务器来缓解LLM驱动的代码/数据外泄。他们指出，这并不能完全防止泄露，但改变了威胁模型：工具不再静默地发出直接上传/下载任务，任何外泄都需要通过LLM交互路径，使其更可见且更慢。

• 另一个技术相关的要点是倾向于在自控基础设施上使用开源代理加开放权重模型。其论点是，本地执行和可检查的工具链减少了对不透明托管服务的依赖，这些服务的遥测、工具调用或数据保留行为可能难以审计。