AI 开发者日报

• Ornith-1.5 作为重要的新开放模型家族登场：@ornith_ 发布了 Ornith-1.5，提供 9B 稠密、35B MoE 和 397B MoE 三种变体，采用 MIT 许可证，并支持 FP8、GGUF、MLX 和 NVFP4 等量化格式。最引人注目的卖点是端到端的自我改进能力：模型能够自行提出任务、生成脚手架代码，并产生强化学习回滚来创造新的训练经验。在智能体/编程相关基准上的评测结果相当亮眼，包括 Terminal-Bench 2.1: 86.1、SWE-Bench Verified: 86、DeepSWE: 56、HLE: 44.6 以及 Tool Decathlon: 71.2。该模型发布后迅速被 vLLM 和 Ollama 集成到各自的推理服务栈中。
• 压缩技术持续推进，但并未完全牺牲模型效用：@UnslothAI 和 @danielhanchen 使用 Dynamic V3 技术发布了新的 Qwen3.8-27B GGUF 量化版本，声称在相同体积下准确率提升了约 10%，同时推出了 1-bit 量化版本，在 8GB 内存上运行仍能保留约 77% 的 BF16 准确率。他们新提出的 Divergence-300 指标将 top-1% 贪婪准确率的评估扩展到更长的生成序列，使用来自 Terminal Bench、DeepSWE 及相关任务的未见示例进行测试。
• 智能体与法律评测榜单持续洗牌：@arena 发布了 Agent Arena 的帕累托视图，其中 Claude Opus 5 (High) 在质量上领先，但 Kimi K3、GLM 5.2、Grok 4.5 和 GPT-5.6 Luna 等低成本模型定义了大部分价值前沿。另外，@ValsAI 报告 Grok 4.6 在 Legal Research Bench 上排名 #3/49，得分 48.1%，支持 500k 上下文、工具/图像/文件处理，且定价相对较低。在开放权重模型方面，@ValsAI 还指出 GLM 5.3 在开放权重模型中位列 Terminal Bench 第 2 名、Legal Bench 第 3 名、Skills Bench 第 6 名。

• DeepSeek Harness 的极简设计是深思熟虑，而非功能缺失：由 @ZhihuFrontier 放大传播、@TheTuringPost 总结的详细分析，将 DeepSeek Harness（DSH） 定位为一个刻意保持轻薄外壳的插件架构，名为 Cordis。其核心设计理念是一切皆为插件，包括 agent 循环本身。据报道，早期测试用户在不到一周内就提交了 100+ 个插件和 400+ 个 issue；示例涵盖从五子棋模型测试平台到数据库 agent（通过将模型连接到实时查询执行来闭环 SQL 反馈回路）等各种场景。最重要的启示在于架构层面：DSH 与其说是"产品化的助手"，不如说是一个开放的 agent 运行时，专为可扩展的工具、可替换的控制循环和业务规则注入而优化。
• TrueFoundry 开源 TrueForge，并明确阐述了框架成本优势：@truefoundry、@omarsar0 和 @kimmonismus 都报道了 TrueForge 的发布——一个 MIT 许可、可自托管、厂商中立的生产级 agent 框架。该技术栈包括工具编排、上下文管理、子 agent、代码沙箱、人工审批和追踪，支持本地和托管两种部署模式。最引人注目的技术主张是：在14 项企业级基准测试中，TrueForge 在 Opus 4.8 上达到了与 Claude Managed Agents 相当的性能，同时使用的 token 减少了约 30%；而路由到 GLM-5.2 则在保持准确率的同时将成本降低了约 75%。更广泛的行业主题——@bradenjhancock 和 @dbreunig via @rseroter 也呼应了这一观点——是会话/环境/记忆/工具层正在成为差异化和成本节约的主要来源。
• 托管框架也在获得更精细的可观测性和控制能力：@ClaudeDevs 为自托管沙箱增加了记忆支持，为 Web 工具增加了域名允许/阻止控制，并重新设计了多 agent 会话查看器，新增小地图、分组对话记录和每线程/会话成本功能。与此同时，OpenAI 继续推动相反的方向：为团队提供可嵌入到自有产品中的框架原语。@OpenAIDevs 强调了开源的 Codex 框架作为内部工具、运维仪表盘和自定义应用底层的运行时，而 @cursor_ai 则围绕持久目标和长生命周期会话发布了云 agent 用户体验改进。

• 更多证据表明，扩展的重心正从参数量转向训练配方的质量：@kimmonismus 提到了 zAI/GLM 创始人的一个引人注目的观点：进展仍在扩展，但太多讨论聚焦于参数量，而忽略了数据质量、推理计算和后训练。所引用的例子是 GLM-5.3，据报道它基于与 GLM-5.2 相同的核心基座模型/架构，但通过大约一个月的额外强化学习实现了显著提升。
• 微软的 Agent Lightning 将"通过训练框架进行强化学习"视为一种实用的配方：@omarsar0 重点介绍了 Agent Lightning v1.0，它通过端点代理将任意训练框架连接到强化学习，处理诸如重新分词、样本合并、优势计算、归一化以及调度器/后端协调等问题。凭借约 6K 条训练样本和适度的计算资源，据报道它使 Qwen3.5-9B 在 SWE-Bench Verified 上的成绩从 41.8% 提升到 56.4%。
• 中期训练正被更明确地视为一个优化面：@cwolferesearch 阐述了当前从业者对 CPT/中期训练 的看法：优化数据混合、训练时长、阶段排序、序列长度，甚至可后训练性，而不仅仅是"在更好的数据上继续预训练"。这条推文之所以有价值，恰恰在于它将这些问题框定为相互作用的旋钮，而非彼此独立的技巧。
• 强化学习基础设施在研究背后持续改进：@SergioPaniego 重新提及了相关研究，展示了 TRL 中的在策略蒸馏通过生成缓冲区、批量教师调用和二进制对数概率编码实现了 40 倍加速；@mikasenghaas 宣布在 prl 中引入了自适应并发，可在强化学习运行过程中动态调整在途的 rollout 数量。

• Qdrant 的可过滤 HNSW 与 ACORN 对比，是检索系统的一次实质性更新：@qdrant_engine 认为，过滤式 ANN（近似最近邻搜索）应该在索引层面解决，而不仅仅是在查询时处理。他们的可过滤 HNSW 在共享索引负载值的点之间添加边，保持过滤子图的连通性。在他们对 100 万向量上 1% 过滤率的基准测试中，报告显示 99.8% 的召回率仅需 1.0ms，而 ACORN 在 4.7ms 下仅达到 67.7% 的召回率。他们还指出，对于宽泛的值和 AND 过滤器，尤其是在已经针对过滤优化的图之上，ACORN 仍然有帮助。
• Sentence Transformers v6.0 反映了从单向量到多向量检索的实际转变：@tomaarsen 清晰地总结了这一区别：稠密检索将每段文本压缩为一个向量，而多向量检索则保留 token 级别的向量，在聚合最佳匹配之前，将查询 token 与文档 token 进行评分。这一点很重要，因为晚期交互（late-interaction）检索正日益成为对质量敏感的搜索系统的默认权衡方案。
• 生产环境中的 Agent 延迟往往与模型本身关系不大：@dair_ai 总结了一篇对十个 Agent 应用进行插桩分析的论文，发现非大模型组件在其中的一半应用中主导了延迟，其中沙箱内存峰值达到 28GB/会话，各子系统之间的延迟差异高达 32 倍，并且步骤之间会长时间保留空闲状态。优化方案并不出人意料，但很重要：任务感知的服务调度可将延迟降低 29–40%，状态卸载可将内存减少 4.6 倍，而工具结果缓存可消除 35.2% 的冗余搜索调用。
• Linear 和 turbopuffer 表明向量基础设施正在渗透到非搜索的热路径中：@turbopuffer 表示 Linear 将其增量同步读取路径从 Postgres 迁移到了 turbopuffer，使用属性索引来处理权限过滤，将最大的同步操作减少了约 8 秒。

• Gemini 3.7 Flash 在评测和产品集成两方面都表现强劲：@_philschmid 和 @NewsFromGoogle 指出，Gemini 3.7 Flash 在 Artificial Analysis 的 AA-AnalystAgent 评测中登顶 #1，在 80 个以电子表格和文档为主的定量任务中取得了 60.0% pass^5、70.5% pass@1、77.5% pass@5 的成绩，平均每个任务耗时 1.32 秒，平均成本 0.54 美元。Google 还将其更深地整合进产品矩阵：包括 Gemini 聊天和 Spark、AI Mode 中即时生成的基于搜索的交互式模拟（示例），以及面向构建工作流的 AI Studio GitHub 同步。
• OpenAI 正押注低成本部署与隐私定位：@Replit 推出了由 GPT-5.6 Luna 驱动的 免费模式，@kimmonismus 将其视为一次意义重大的效率胜利：一个不久前还处于 SOTA 水平的模型，如今已经便宜到可以大规模免费分发。在企业端，@OpenAI 推出了 Private Safety Processing（私有安全处理），旨在让前沿模型在保持 零数据留存 的同时，仍能检测跨交互的安全风险，且无需人工接触底层内容。
• Anthropic 持续打磨开发者体验闭环：除了上述托管代理的更新之外，@ClaudeDevs 为 Claude Code 新增了 简洁输出风格，这再次表明产品团队现在不仅调优模型能力，还将响应形态本身作为一等 UX 变量来对待。

• Ornith-1.5 发布：@ornith_ 推出了一个 MIT 许可 的开源模型家族，参数量从 9B 到 397B 不等，在编码和智能体基准测试上表现强劲，并支持广泛的量化方案。
• OpenAI 隐私与安全基础设施：@OpenAI 宣布推出 私有安全处理（Private Safety Processing），同时重申前沿模型 零数据留存（Zero Data Retention） 承诺。
• Gemini 学生推广与产品捆绑：@GeminiApp 面向全球学生提供一年期 Gemini 套餐，同时推出多项面向学习场景的新功能。
• Claude Code 用户体验更新：@ClaudeDevs 发布了 简洁模式（Concise mode），这一看似微小的改进却在日常编码智能体交互中获得了广泛关注。
• OpenRouter 被收购：@patrickc 确认 OpenRouter 将加入 Stripe，许多人认为此举印证了 Token 路由/市场 正在从边缘工具演变为核心基础设施。

/r/LocalLlama + /r/localLLM 周报回顾

• 推出 Qwen3.8-27B Dynamic v3 Unsloth GGUF（热度：1428）：该图片是"Dynamic v3.0 Qwen3.8"的技术公告图，展示了 Unsloth 全新的 Qwen3.8-27B Dynamic v3 GGUF 训练后量化方案，并声称在相同 GGUF 体积下，top-1% 准确率比其他方案高出 >10%。图中包含一张内存表，显示该模型可以从约 8GB 内存运行的 1-bit 量化一直扩展到 BF16，另有一张图表对比了不同量化尺寸下的准确率；帖子链接了 Hugging Face 上的 GGUF 发布、Dynamic 3.0 文档/基准测试以及图片本身。Unsloth 强调这些仅是训练后量化发布——"我们不使用 QAT 或 QAD"——并表示 imatrix 校准文件已公开，供独立评估和微调实验使用。评论区总体正面，但有一条技术请求希望 Unsloth 将之前的 UD 2.0 量化版本加入图表，方便用户与本地已有的版本进行对比。另一位评论者请求更深入的诊断数据，特别是按类别和 KV-cache 量化的 KLD 数值，参考了 localbench 风格的报告方式。

多位评论者请求对新版 Qwen3.8-27B Dynamic v3 Unsloth GGUF 进行更详细的量化评估，尤其是与之前 Qwen 3.8 27B UD 2.0 量化版本直接对比的图表曲线。建议的指标包括 KLD 和/或 top-1 一致性，这将帮助用户判断新的动态量化是否在实质上优于许多用户本地已存储的旧版本。

• 有评论者请求提供按类别的 KLD 和 KV-cache 量化 KLD 报告，参考了 localbench.substack.com 的细分风格。这将使量化质量讨论更具可操作性，能够展示在不同 GGUF 量化格式下，哪些基准/任务类别或缓存量化设置退化最严重。
• 用户对量化的实际内存占用很感兴趣：一位用户指出 Q4_K_M 约需 ~15 GB，另一位推断 IQ4_XS 现在可能可以在 16 GB 显存上运行"无需 mtp"。技术上的担忧在于，这些更小的格式能否在保持足够模型质量的前提下，让 27B 级别的模型完全运行在常见的消费级 GPU 上。

在 4× RTX 3060 12GB 上以约 100 tok/s 的提示处理速度运行 DeepSeek V4 Flash Q4_K_XL（热度：1104）：该图片展示了一个 DIY 开放式框架/多 GPU 本地 AI 设备，与标题声称的一致——使用 llama.cpp 在 4× RTX 3060 12GB 上运行 DeepSeek-V4-Flash-0731 UD-Q4_K_XL GGUF——一个约 144 GiB 的 MoE 量化模型。该帖子的技术亮点在于非常规的内存/布局策略：-ncmoe 34 将早期的 MoE 专家保留在系统内存中，-ot 将后续的专家块固定到 GPU 1–3 上，而极端的 -ts 100,1,1,1 将大部分非专家张量/KV 相关分配推送到 GPU0 上，从而在配置约 368k 上下文和 Q8_0 KV 缓存的情况下实现了约 99.4 tok/s 的预填充速度和约 10.1 tok/s 的解码速度。评论大多是对硬件搭建本身的反应而非基准测试：用户开玩笑说这种裸露的 4-GPU、转接电缆、850W 电源的配置"绝对硬核"，并建议它应该属于一个假想的 r/crackheadlocalai 板块。

DFlash 2 现已支持 Qwen 3.8 27B 和 Muse Glimmer（热度：569）：DFlash 2 已由原 DFlash 作者发布，支持 Qwen 3.8 27B 和 Muse Glimmer，GGUF 量化版本已可用，并已提交相应的 llama.cpp PR #27342。链接的 Qwen 3.8 27B 基准图显示 DFlash 2 大幅超越 MTP，至少有一位评论者确认它可以在 Qwen 3.8 8-bit 量化下成功运行。评论者普遍对此次发布感到兴奋，但有一个技术限制被指出：张量分割似乎不受支持，在 ggml-backend-meta.cpp:543 中会触发 GGML_ASSERT(src_ss[0].axis != GGML_BACKEND_SPLIT_AXIS_0) 断言失败。

• 有评论者指出发布的 Qwen 3.8 27B 基准图，注意到 DFlash 2 在报告数据中似乎大幅超越 MTP：https://preview.redd.it/oqmkebcmd7kh1.png?width=645&format=png&auto=webp&s=02fe2114c582819309247b2b45da07f109e4d961。该帖未提供精确数值，但核心技术主张是 DFlash 2 在该模型上相较于 MTP 显著提升了投机/加速解码性能。
• 一位用户报告成功使用 Qwen 3.8 的 8-bit 量化运行 DFlash 2，表明该版本至少在量化部署路径上可用。另一位用户报告张量分割不受支持或当前存在缺陷，触发了 llama.cpp/GGML 断言：GGML_ASSERT(src_ss[0].axis != GGML_BACKEND_SPLIT_AXIS_0) failed（位于 ggml-backend-meta.cpp:543），这表明与分割轴后端元数据处理存在不兼容。

Qwen3.8-27B 在 2× 3090 + vLLM + DFlash2 上：单请求 218 tok/s（热度：395）：一位用户报告在 2× RTX 3090 上运行 Qwen3.8-27B，使用 vLLM v0.26.1rc1、AutoRound INT4 量化（group 128）和 DFlash2 草稿模型，在 Club-3090 标准基准套件上实现了单请求解码叙事文本 120.1 tok/s 和代码 218.3 tok/s。报告的指标包括预填充 1342 tok/s @ 10k 和 628 tok/s @ 90k，投机解码使用 7 个草稿 token，接受长度 3.35，接受率 47.8%，峰值显存 22.3 GB/卡，以及 131k 上下文上限；自定义 vLLM 启动修复链接在 oceanplexian/vllm#1。热门评论大多是非技术性的；唯一实质性的澄清请求是询问使用了哪个模型和量化方案，帖子中已明确说明是 Qwen3.8-27B 搭配 AutoRound INT4。

• 一位评论者分享了一个可用的双 AMD R9700 vLLM 配置，使用 vllm-radiance（Docker 镜像），搭配 Qwen/Qwen3.8-27B-FP8、--tensor-parallel-size 2、--quantization fp8、--max-model-len 262144 以及 ROCm AITER 统一注意力。他们报告常规文本生成约 40-60 tok/s，MTP 辅助的代码生成约 80-120 tok/s，长上下文预填充峰值可达 13k tok/s。
• 提供的启动配置使用了 ROCm 特定的调优标志，如 VLLM_ROCM_USE_AITER=1、ROCM_AITER_UNIFIED_ATTN、RADIANCE_DYNAMIC_DRAFT=1、RADIANCE_AR_QUANT=1，以及通过 --speculative-config '{"method":"mtp","num_speculative_tokens":8,...}' 实现的投机解码。评论者指出模型量化为 fp8；KV 缓存似乎是 16-bit，但他们表示 fp8 KV 量化似乎也能正常工作。

阿里巴巴 RISC-V CPU XuanTie C950 以 30 tps 运行 Qwen-3.8 27B（热度：718）：阿里巴巴的 64 核 RISC-V XuanTie C950 据称可以原生运行 Qwen-3.8 27B，解码速度达到 30 tokens/s，TTFT 为 1.9s，据 Wccftech 报道。这款台积电 5nm 服务器级 CPU 被描述为使用基于 AMBA CHI 的 8 核集群、向量/矩阵加速、可配置缓存、预取、8 宽解码和 16 级流水线，定位为阿里巴巴自家 Qwen 技术栈的免 GPU 推理目标。评论者对仅凭 30 t/s 解码速度作为基准测试表示怀疑，要求提供上下文长度扩展、预填充吞吐量和所使用的量化格式。其他人则认为，如果阿里巴巴将其作为产品推出，该硬件在商业上可能具有吸引力，可作为更便宜的类 DGX Spark 私有/边缘推理设备。

• 多位评论者指出，仅凭报告的 30 tokens/s 解码速度不足以评估真实的 LLM 性能，还需要上下文长度扩展、预填充吞吐量以及 Qwen-3.8 27B 所使用的量化格式。核心担忧在于，解码速度看起来可用，但预填充和更长上下文的 KV 缓存压力可能会大幅降低实际吞吐量。
• 有人对将 XuanTie C950 系统定位为 NVIDIA DGX Spark 类本地 AI 设备的低成本替代方案感兴趣，但评论者强调内存容量/带宽对于 27B 模型至关重要。即使解码速度达到 30 tps，系统的可行性在很大程度上取决于内存大小、量化级别，以及平台能否在不成为瓶颈的情况下维持更大的上下文。

• 别再拟人化中间令牌了：Qwen3.8 并没有"过度思考"（活跃度：862）：该帖认为大模型中间令牌的生成——被营销为"思考"/"推理"——更应该被理解为提示词/上下文增强，而非类人的逐步认知过程。帖子引用了 Kambhampati 等人的研究 以及所链接的 OpenReview 论文。该研究指出：最终答案的正确性与推理痕迹的有效性之间相关性很弱；在被破坏/语义无关的痕迹上训练的模型表现相当甚至更好；强化学习能提升答案准确率，但并不能可靠地改善痕迹的有效性；痕迹长度对问题难度基本不敏感——这些证据都反对将中间痕迹视为语义上忠实的"推理"。评论区有人反驳说，"思考"和"推理"这类术语是有用的计算隐喻，就像把删除文件的存储称为"回收站"一样，并不必然意味着字面意义上的人类认知。另一位评论者从技术角度认同痕迹主要是让模型"梳理"其分布而非给用户看的，但批评了命令式的术语规范做法，认为这在修辞上适得其反。

多位评论者认为，"思考"、"推理"、"幻觉"和"过度思考"等术语是有用的计算隐喻，而非字面意义上的拟人化断言。最技术性的解读是：Qwen 的"过度思考"应被理解为在中间推理痕迹上花费了过多的测试时计算/令牌预算，而非类人的认知状态。

• 一位评论者区分了面向用户的拟人化解读与实际实现行为：中间推理痕迹*"不是给用户看的"*，但可以让模型在给出答案之前更充分地探索其学到的分布。这框架将思维链式令牌视为一种推理时机制，用于改善采样/搜索质量，而非真实内部深思的证据。
• 一位评论者指出，即使是人类的推理也未必是干净的对照案例，因为人类往往先得出直觉结论，然后再事后构建合理化解释。这使得"仅因大模型令牌生成不同于理想化的人类推理就判定其'推理'术语无效"的论点变得复杂。

关于扩展定律的思考 - Z.ai（活跃度：672）：该图片是 Z.ai 创始人/清华教授唐杰在 X 平台上的帖子截图，"关于扩展定律的思考"，认为前沿扩展已不再能简化为参数量：最优分配取决于数据、训练计算量、推理成本、稀疏性/MoE 激活以及后训练/强化学习。该帖将 GLM-5.3 定位为在 GLM-5.2 基础上进行的受控实验——相同的基座架构、总参数量和激活参数量，但增加了大约一个月的规模化长时程环境与强化学习，声称通过转动后训练旋钮而非增大模型规模获得了巨大收益。帖子引用了从 Kaplan 式参数密集型扩展到 Chinchilla 式令牌/参数平衡的转变，然后论证 MoE 模型将"知识容量"与"推理深度"解耦，使得激活参数/有效深度和任务特定训练对漏洞发现等推理密集型领域更为重要。评论者大多将此解读为中国实验室（如 Z.ai/GLM）正在做严肃的前沿研究，而非仅仅蒸馏西方模型。一位更具技术性的评论者将这个想法与小模型架构联系起来——将"世界知识"从计算图中外部化，推测基于 RAM 的知识存储可以让约 8–9B 的模型为推理预留更多显存/计算资源，尽管大规模服务此类系统可能很困难。

• 多位评论者将 GLM 5.3 解读为一项扩展实验，将能力从原始参数量转向推理计算，并将其与 Qwen 3.8 27B 作为相对较小的模型因更重的推理而表现优异的例子进行比较。有推测认为 GLM 5.5 可能瞄准 DeepSeek V4 Pro 级别的规模，暗示其重点是成本效益高的前沿级性能，而非单纯最大化总参数量。
• 一个详细的讨论串探讨了用 DeepSeek 式"Engram"架构重新改造 Llama 8B，将相对静态的"世界知识"与核心计算图分离。该评论者声称这相当于用系统内存换取显存：一个约 8B–9B 的模型可以将活跃模型保留在显存中，同时将完整的外部知识表存储在约 32GB 的内存中，从而可能让较小模型的参数更专注于计算和推理。
• 同一位评论者认为，这种外部化知识设置可能使激进的量化不那么有害，因为受 Q4 式量化影响最大的知识密集型部分仍保留在高精度的内存驻留表中，例如 FP16 或 FP8。他们还指出，在 DDR5 上，取数路径并不明显受 PCIe 瓶颈限制，但大规模服务此类架构在运维上会很困难，因为需要在内存驻留哈希表与显存约束之间取得平衡，这或许可以解释为什么 DeepSeek V4 可能避免广泛部署这种架构。

• 据社区经理透露，新款中型 Qwen 3.8 模型有望下周发布（但愿如此）！（热度：1025）：据称，一位 Qwen 社区经理在 Qwen Ambassador Discord 中表示，一款新的中型开源权重模型计划"下周（但愿如此）"发布，且由于日程安排紧张，不会提供提前访问。具体参数规模和架构尚未披露，但评论者推测其规模可能远超 35B，有人猜测是 80B 的编码器变体，或是 ~100B 级别的 Qwen 3.8 系列模型。评论者认为这款预告模型可能比传闻中的 35B A3B 更重要，并引用了团队的一条评论："35B A3B 不是值得等待的那款。" 有人兴奋地推测，~100B 级别的 Qwen 发布可能会与"dsv4F"形成有力竞争，不过目前尚未提供任何基准测试或技术细节。

评论者重点关注了下一代 Qwen 发布所期望的参数规模，围绕 80B Qwen Coder 和 100B–122B Qwen 3.8 系列模型提出了请求和猜测。有用户认为，一款具备 Qwen 3.8 能力的新 122B 模型将恰好命中"速度与世界知识的甜蜜点"，暗示人们对一个比前沿规模模型更快、同时保留广泛知识的中型密集层级的兴趣。

• 一条被引用的团队/社区评论声称 "…35B A3B 不是值得等待的那款…"，暗示传闻中的 35B A3B 变体可能不是主要的即将发布版本，或者其重要性不如一款更大的模型。该帖子的技术讨论核心在于，一款更大的 Qwen 3.8 模型能否在编码和通用能力方面与 DeepSeek V4/F 风格的模型竞争或超越。

Qwen-3.8-35B-A3B？也许不是……来自 Qwen 联合作者的神秘回复。（热度：521）：图片 是 Qwen 联合作者白帅（Shuai Bai）在 X/Twitter 上回复的截图，回应了关于 Qwen-3.8-35B-A3B 是否会面向硬件有限的用户发布的问题。他神秘地评论道——"35B-A3B 可能不是值得等待的那款 👀"——暗示这款传闻中的 MoE 风格模型可能不是相关的即将发布版本，可能暗示 Qwen 将推出另一款更小或更易获取的模型。评论者将这条回复解读为 35B-A3B 可能不会发布，同时推测 Qwen 可能会推出类似 9B、20B、30B-A3B 或更小的密集模型。有一条热门评论是关于智能手表上不可能存在的 2.3T A200M 模型的玩笑，因此该帖子的部分内容属于非技术性幽默。

• 评论者将 Qwen 联合作者的"不要等待这款"解读为很可能排除了传闻中的 Qwen-3.8-35B-A3B，同时为另一款即将发布的版本留下了空间。技术讨论集中在替代的参数/MoE 配置上，如 30B A3B、9B、20B 或 12B 密集模型，暗示人们预期的是一个更小或结构不同的检查点，而非传闻中的 35B-A3B。
• 有评论者推测，Qwen 可能正在准备一款更大的稀疏 MoE 级发布，被描述为 "122B/a10 级模型"。这表明人们预期一款总参数约 122B、每个 token 激活约 10B 参数的模型，在总容量上高于传闻中的 35B-A3B 级别，同时保留稀疏推理的特性。

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

• 游戏结束？22GB 本地模型在 Pi 上运行，在训练截止日期后发布的真实编码任务上超越 Claude Code Opus 5 High（热度：2485）：基准测试信息图声称，使用作者开发的 Sharp 聊天模板本地运行的 Qwen3.x GGUF 编码代理，在 21 个训练截止日期后的 SWE-bench-Live 风格真实编码任务上超越了 Claude Code Opus 5 High：原版 Qwen3.8-27B Q6 修复了 12/21 个任务，Sharp Qwen3.8-27B 在约 20 分钟内修复了 11/21 个任务，而 Opus 5 High 仅修复了 10/21 个，Sonnet 5 修复了 5/21 个。技术核心主张是：提示词/聊天模板的改动在保持修复质量的同时减少了 token 消耗和延迟。文中链接的本地模型 Dirk-Qwen3.8-27B-GGUF 和 Nail-Qwen3.6-35B-A3B-GGUF 被作为实用的本地编码代理替代方案展示。评论区持怀疑甚至阴谋论态度：有人声称 Anthropic 可能悄悄降低了 Opus 的质量，也有人认为本地模型的主要障碍仍然是速度和价格可承受的 22GB+ 显存硬件。

评论者对标题提出了反驳，指出本地 22GB 模型可能在基准测试中表现良好，但往往受限于推理延迟，一位用户将核心部署问题总结为*"本地模型慢得要命"*。质疑的焦点在于实际吞吐量和用户体验，而非原始任务准确率：本地模型不仅要在编码质量上匹配托管的企业级模型，还要在速度、成本和消费者可及的硬件要求上达到同等水平。

• 一个反复出现的技术注意事项是硬件可负担性和可用性，具体来说就是用户能否以较低成本获得约 22GB 显存的 GPU。多位评论者暗示，在这些模型能在消费级价格硬件上以可接受的速度运行之前，"游戏结束"的说法为时过早——而不仅仅是在相对高显存的本地配置上。
• 一位评论者声称 Anthropic 已经"在幕后悄悄将 Opus-5 切换为 Sonnet-5"，但帖子中没有提供任何证据或基准测试细节。就内容而言，这一说法在技术上与模型对比的有效性相关，但它仍然是一个未经证实的断言，而非有据可查的路由或评估问题。

到底发生了什么……（热度：1053）：一位资深工程师报告称，他被分配了为一个人工智能构思的项目生成的 AI 工单，附带的 AI 编写文档几乎无法使用，随后他在缺乏清晰系统/产品规格的情况下，使用 AI 产出了 3 个各约 20,000 行代码的 PR。核心技术担忧是组织对 Claude 和 ChatGPT 等大模型的过度依赖，将其用于需求发现、代码生成、文档编写和代码审查，形成了一条没有任何人对正在构建的系统有清晰认知的流水线。热门评论质疑在没有理解产品的情况下提交 60,000 行代码 PR 的合理性和治理问题，有人建议先获取实际的产品规格。还有人建议用 Claude 生成文档、用 ChatGPT 进行审计，这反映了帖子中的张力：是将 AI 视为缺失工程流程的权宜之计，还是认为这样做反而加剧了问题。

• 多位评论者聚焦于 3 个各约 20,000 行代码的 PR 在一天内提交所隐含的工程流程失败：此类变更实际上无法审查，且暗示产品规格缺失或被忽略。一条评论明确建议在接受或处理这种规模的代码之前，先获取产品规格。
• 一个反复出现的技术担忧是，让 AI 生成过多代码可能产生结构上不再有清晰人类心智模型的系统。评论者指出，这会形成维护陷阱——未来的修改需要进一步依赖 AI 辅助，因为代码"不再具有直觉上的可理解性"。

用 AI 完全制作钓鱼游戏的第三周（热度：2740）：作者正在使用 Godot 4.7.1、Claude/Claude Code 配合 MCP、专门的 Blender MCP 会话（用于脚本生成低多边形 3D 资产）以及 ChatGPT/OpenAI Playground（用于概念/参考图像）"完全用 AI"构建一款钓鱼游戏；当前成果以 Artifact 1 和 Artifact 2 的形式分享。他们的流水线将角色分离为参考生成、程序化几何/建模、集成/放置、相机内截图审查、以 8+/10 接受阈值的盲测前后评分，以及带来源标记的设计决策——以避免 AI 幻觉被重新引入为需求。最具技术性的批评指出了 AI 生成世界的常见问题：无法进入的门/码头、不合理的建筑布局和地形切割、UI 杂乱/锚定不佳、可能由着色器/多边形数量导致的帧率下降、需要插值的水圈动画突变、诸如*"拉出公共部分"和"船记得路线"*之类的文案痕迹、过度设计的 18 个改装槽位，以及夸张的昼夜光照/灯塔对齐问题。评论者普遍认为，AI 让单人游戏开发变得容易得多，因此差异化将更多取决于刻意的人类品味、迭代和打磨——去除"通用 AI 感"，而非原始的生产速度。一位详细的评论者建议将批评直接反馈到流水线中，强调资产在预告片或远景截图中可能看起来不错，但由于空间不连贯和弱功能暗示，在近距离游戏检查中会失败。

• 一条详细的批评指出了可能损害游戏可读性的常见 AI 生成资产问题：无法进入/被堵塞的门、合并的几何体、围栏封死的码头、悬浮的 NPC、通向虚无的楼梯，以及缺乏合理停靠或居住布局的岛屿/灯塔。技术要点是：AI 生成的环境在预告片中可能看起来很棒，但需要人工检查空间逻辑、导航功能暗示、碰撞/合理性以及面向玩家的可读性。
• 发现了多个 UI/UX 问题：冗余的 purse（钱包）和 debt（债务）数值可能应该合并为一个带符号的货币值；导航数据分散在屏幕相对的两侧边缘；右侧小部件锚定不当；"Harbour Roads"面板对实时游戏来说文字过于密集。评论者建议将非必要文本移到 I 详情面板后面，并将 Mark/Arrives 等相关导航指示器与 KN 速度信息分组。
• 水面/钓鱼序列显示出可能的性能或捕获卡顿，促使建议在添加更多系统之前先对着色器成本和 3D 模型多边形数量进行性能分析，因为迭代很可能会加剧延迟。他们还注意到水波纹内圈"凭空出现"的视觉伪影，建议进行插值处理，并指出了诸如*"拉出公共部分"之类的生硬生成文案，以及"船记得路线"*这种类似 Claude 的拟人化措辞。

• 说到做到：Anthropic的Claude自主设计靶向疾病蛋白，经真实湿实验验证，成功率35% vs 人类平均10–15%（活跃度：1152）：Anthropic 报告称，Claude能够自主生成靶向疾病的蛋白质设计方案，这些方案已在湿实验室检测中得到实验验证，声称成功率高达 35%，而引用的蛋白质设计人类基线约为 10–15%。关键技术主张不仅在于计算机模拟评分，更在于真实的实验验证，这表明Claude可能作为治疗性蛋白质工程工作流中的迭代设计引擎发挥作用。评论者大多对相较于人类平均水平超过2倍的提升印象深刻，部分人甚至将其外推到癌症治疗领域；在提供的热门评论中，几乎没有实质性的技术辩论。

一位评论者强调，所报告的 35% 湿实验成功率 vs 10–15% 人类平均水平，如果比较方法学上公平的话，将意味着 >2倍的提升，同时指出这种关系可能不是线性的，也不一定能在不同任务间直接比较。

@sama 对RL训练暂停的解释：“模型进展现在极其迅速，我们一直说如果模型能力超越安全和对齐的推进速度，我们会采取行动。”（活跃度：893）：该帖引用了Sam Altman（@sama） 对RL训练暂停作为安全/对齐门控决策的解释：“模型进展现在极其迅速……如果模型能力超越安全和对齐的推进速度，[我们]会采取行动。” 一位评论者还附上了更新截图，但帖子摘录中未提供其内容。评论者分为两派：一派是加速主义对暂停的质疑——例如提议建立专注于RSI/AGI/ASI的新前沿实验室；另一派则担忧真正的风险拐点可能出现在未来硬件范式实现约5年内 100×–1000× 更快或更高效的扩展时。

• 一位评论者认为，真正的安全拐点可能出现在下一次重大硬件范式转变时，而非当前的RL训练运行中，并引用了在约5年内模型效率、速度或规模可能实现 100x–1000x 的提升。

• 记者将 AirTag 偷偷放入亚马逊仓库，以证明他们销毁稀有书籍用于训练 AI（热度：3803）：据称 404 Media 的一项调查使用苹果 AirTag 藏在一本通过批量订单售出的稀有书籍中，追踪其流向 拉斯维加斯的一处亚马逊 AI 训练设施，从而支持了实体书籍被送入数字化/销毁流程用于 AI 训练的说法。一位书商评论者对此进行了背景补充，指出大规模粉碎未售出、捐赠、滞销、图书馆淘汰及不可退货的书籍在二手书供应链中已是常规操作，许多书从未被成功转售或捐赠（评论）。评论者们就这份报道是否真的令人意外展开了辩论：有人要求提供更可靠的来源，也有人声称亚马逊的销毁流程与"Project Panama"下的法律义务有关，但该帖文中未提供任何支持性引用。

一位书商认为，亚马逊销毁书籍在出版/二手书供应链中并不罕见：捐赠书籍、图书馆淘汰品、书店未售库存和滞销仓库存货被例行粉碎，因为需求远低于供给。他们声称，书店中约 50% 的新季图书可能一本都卖不出去，之后这些库存会根据出版商的指示被退回、降价处理或粉碎。

• 一位评论者断言，这种销毁可能源于法律/法院强制的义务而非自愿行为，并提到 "Project Panama" 是要求销毁的机制，但帖文中未提供任何支持性来源。
• 另一个技术相关的观点是，许多被销毁的物品很可能是低需求或大批量生产的材料——例如旧教科书或杂志——而非独特的"稀有文化杰作"，因为真正被追捧的书籍通常存在多个印刷版本和流通渠道。

科技巨头筹集数十亿美元阻止全民基本收入（UBI）（热度：2461）：该帖声称美国前商务部长 Gina Raimondo 正在领导 RAISE US，这是一个新成立、资金雄厚的组织，反对将 UBI/基本收入 作为应对 AI 取代就业的方案，并引用了她的话称 UBI 将*"如同美国的终结"*。帖子称 RAISE US 已筹集 >$500M，目标为 $1B，亚马逊、Anthropic、微软和 OpenAI 基金会 是主要合作伙伴，其他支持者还包括 Blackstone、通用汽车、IBM、万事达卡、德勤、思科、UPS 等。评论者们将没有 UBI 的 AI 驱动"奇点"描绘为反乌托邦，并批评科技巨头在可能自动化就业的同时资助反 UBI 的政策工作。一个实质性的讨论线程主张采用 负所得税 式的 UBI，指出 米尔顿·弗里德曼 曾支持这一方案，类似的提案在 1970 年代曾两次通过美国众议院，最终因左右两派的反对而失败。

• 一个实质性的政策讨论线程认为，UBI 可以以 负所得税 的形式实施，并指出米尔顿·弗里德曼在 1970 年代曾倡导这一方案，据报道该提案曾两次通过美国众议院，最终因左右两派意识形态的反对而失败。该评论者强调了相对于经济状况调查式福利的设计优势：更少的官僚资格审核规则、更少的福利悬崖，以及*"工作永远应该是净收益"*或组建双亲家庭的激励。
• 几位评论者认为，在自动化高度普及的未来，反 UBI 游说在经济上是自相矛盾的：如果 AI 驱动的裁员减少了家庭收入，总消费需求就会下降，这就引出了*"当没有人有可支配收入时，谁来买东西？"*的问题。这与其说是技术性的 AI 观点，不如说是对没有再分配或收入支持的自动化的宏观经济批判。

Anthropic 的收入是 OpenAI 的两倍（热度：1131）：该图片是 WSJ 的摘录，声称 Anthropic 的收入翻了一倍多，达到 $11.6B 并实现了小幅运营盈利，而 OpenAI 的季度收入升至 $6.7B，但运营亏损进一步恶化。从背景来看，该帖认为尽管 Reddit/X 上有用户放弃 Claude 的叙事，但企业或更广泛市场的采用可能比可见的消费者情绪所显示的更为强劲；标题略微夸大了"两倍"的说法，因为 $11.6B / $6.7B ≈ 1.7x。评论在品牌/产品情绪与工作流特定评估之间分歧：有人认为 Claude 在软件开发方面"很好用"，而另一位用户则表示 OpenAI 最近在他们的工作中表现更优，现在他们将 Claude 的使用限制在代码审查上，尤其是在对水印技术表示担忧之后。

• 一位同时订阅 OpenAI 和 Anthropic 付费/最高级套餐的用户 报告称，OpenAI 在他们的工作流中已变得更为优秀，而 Claude 现在主要用于 代码审查。他们还表示，Anthropic 宣布的 水印技术 改变了他们的使用模式：他们避免直接使用 Claude 生成的输出，而是只将其输入另一个大模型。
• 一位评论者认为，Anthropic/OpenAI 的盈利能力可能受到 大模型商品化 的压力，特别指出 中国的开源权重模型 是降低差异化的力量。他们认为未来的竞争优势可能从纯粹的前沿研发转向 效率研究、安全性、客户支持、UI/产品集成，以及可能的 硬件。