全部 · 2026-05-24

这条信息来自 Reddit 用户分享的实测数据，但原文被屏蔽了，看不到完整的配置细节和生成质量反馈。已知的是用一张 RTX 3080 Ti 跑 Qwen 3.6 27B 模型，开启了 MTP（多 token 预测，一种让模型一次猜多个词来提速的技术），最终跑到每秒 4.5 个 token。这个速度对于消费级单卡来说能用了，但谈不上流畅，日常对话会感觉有点等。另外两条相关帖子提到更极端的方案：有人用 GTX 1060 6GB 这种老卡也能跑，还有人用两张 RTX 3060 组 400 美元的低成本方案跑到 30-50 t/s。综合看，这个模型对硬件门槛压得够低，但单卡体验取决于你能接受多慢。正文没披露量化精度、上下文长度和显存占用，这些才是决定能不能日常用的关键。

这条消息目前只能当“标题新闻”看。Bloomberg 的报道只提了 75% 的永久折扣，但关键信息全缺：旗舰模型指的是 V3 还是 R1？折扣覆盖输入、输出还是全部 token？生效日期和原来的定价基准也没给。没有这些，75% 就是一个没法验证的数字。 从行业角度看，DeepSeek 的 API 本来就不贵，再打四分之一折，如果覆盖的是主力模型，对做批量推理、数据清洗的开发者确实有吸引力。但反过来想，如果折扣只针对某个特定接口或者有调用量门槛，实际受益面就没那么大。 现在最需要的是 DeepSeek 官方定价页面更新或者一份正式公告。在那之前，这条消息的价值在于提醒你关注后续动作，而不是现在就调整预算。

这条消息的核心是监管在主动用新模型给银行做压力测试，而不是等出事了再补救。欧洲央行召集银行，说明测试结果可能具有普遍性，不是个别机构的问题。但FT的报道正文被付费墙完全挡住，我们只能看到标题和导航栏，连导语都没有。所以关键信息全是缺口：用了什么模型、测出了哪类风控缺陷、是信用风险还是操作风险、涉及多少家银行、整改期限多长，一概不知。Bloomberg的转述也只是复述FT的标题，没有补充细节。对从业者来说，这更像一个信号——监管开始把AI当成审计工具来用了，但具体怎么用、效果如何，还得等更完整的披露。

Epoch AI 算了笔账，从 2024 年初到 2025 年底，高带宽内存（HBM，你可以理解为给 AI 芯片配的极速仓库）在物料成本里的占比从 52% 涨到了 63%。这个数字是拿英伟达、AMD、谷歌和亚马逊四家的 AI 芯片按出货量加权平均算的，所以基本代表了市场主流。同期负责计算的逻辑芯片成本占比几乎没动，在 13% 左右；先进封装和其他部件的份额反而在缩水。这说明芯片本身的设计和制造进步，并没有减轻对内存的饥渴，模型越来越大，数据吞吐的需求把成本压力全推给了内存。 不过得留个心眼：原文只给了百分比变化，没披露这四家各自的出货量权重和具体定价模型。我们不知道是 HBM 单价涨了，还是芯片设计里堆了更多 HBM 堆栈。另外，63% 是物料成本，不是最终售价，芯片公司的毛利空间没体现在里面。如果后续能看到按芯片型号拆分的成本明细，才能判断这波涨价是三星/SK 海力士在赚，还是英伟达们在主动堆料。

这次攻击的聪明之处在于不直接藏恶意代码，而是给开源项目提 PR，往 CLAUDE.md 和 .cursorrules 里塞被篡改的指令。开发者把仓库拉到本地后，Claude Code 或 Cursor 会把这些文件当可信配置执行，等于攻击者借 AI 助手的手在开发者机器上跑命令。涉及 34 个包，横跨三大包管理器，目标是加密货币和安全开发者的钱包、SSH 密钥和云凭证。 目前信息仅来自一条 Bloomberg 标题和 Hacker News 讨论，46 个赞、45 条评论说明关注度不低，但原文没披露具体包名、受影响项目或攻击时间线。在官方公告或技术分析出来前，这还是一条标题新闻。 还缺的关键信息：哪些开源项目的 PR 被利用、恶意配置文件的具体内容、各包管理器下架响应时间，以及 Claude Code 和 Cursor 团队对此的回应。如果确认是首次将 AI 助手作为攻击面，这个手法值得所有用 AI 编程工具的人警惕——你信任的配置文件，可能已经被别人改过。

这期播客最大的价值是布罗克曼以当事人身份还原了OpenAI董事会解雇Sam Altman后的72小时。他讲了自己在哪里接到电话、为什么当天就辞职，以及第二天在Sam家里设计“凤凰”备份公司的过程。转折点被归结为Ilya Sutskever发了一条推文，但正文没披露推文具体内容和Ilya立场转变的真实原因，这部分只能听他单方面叙述。 除了宫斗戏，他还提到OpenAI早期在纳帕谷定下的三步技术路线用了十年，以及现在公司内部代码“很难说有多少不是AI写的”。这些说法没有给出可验证的数据，更像播客对谈中的个人判断。 整体来看，这是一份重要的口述史料，但信息缺口也很明显：董事会决策的具体依据、其他关键人物的视角、以及“凤凰”计划最终为何没有启动，正文都没交代。如果是真的想搞清楚那次危机全貌，光听这一边还不够。

这条帖子讲的是怎么在 llama-server 的网页界面里，直接用 llama.cpp 的原生工具实现联网资料检索。作者给了一套七步操作，包括开启 get_datetime 和 exec_shell_command 两个工具，再通过 firejail 沙箱、独立 Linux 用户和 Alpine OCI 虚拟机来跑 wget 抓网页，安全隔离做得挺细。 但问题是，Reddit 原文返回了 403，我们拿到的只有“你被网络安全屏蔽了”的提示，正文完全缺失。所以上面这些步骤是从摘要里拼出来的，具体配置参数、命令写法、模型选型（摘要提到 Qwen）以及实际效果，正文都没披露。 对想复现的人来说，这条信息目前只能当个方向参考。安全隔离的思路值得看，但能不能跑通、延迟多大、检索质量如何，都得等原文恢复或者作者补发才能判断。

这篇论文的核心卖点是让视觉语言模型不再一条道走到黑，而是同时从四个角度理解图像，再综合出答案。具体做法是用 Pa-Attention 和 LPRoPE 把视觉推理拆成四条独立路径，相当于给模型装了四个并行工作的“眼睛”，各看各的，最后汇总。训练数据是 16.3 万组问答对，这个量级在视觉推理任务里不算大，所以论文里展示的效果能不能在更复杂或没见过的场景里复现，目前还不好说。 比较遗憾的是，原文页面被微信的环境验证挡住了，没法看到具体的实验设置、基准测试对比和消融实验细节。比如这四条路径到底各自负责什么类型的视觉信息，是颜色、形状、空间关系还是别的，正文没披露。另外，并行思考带来的额外计算开销有多大，延迟增加多少，这些实际部署时很关键的数字也看不到。 如果你在做多模态模型推理优化，这个思路值得看一眼，但别急着当成熟方案用。先等论文全文放出来，看看它在更多基准上的表现，以及跟现有串行推理方法的公平对比再说。

这条消息最值得看的是两个数字：经理管的人从 8 个变成 50 个，以及 Meta 持有 Scale AI 49% 的股份。前者说明 Meta 在把管理层压扁，逼着工程经理回去写代码，不再养纯管理岗。后者解释了为什么敢把 Infra 和 AI 工程师调去搞数据标注——反正标注公司自己是大股东，肥水不流外人田。 不过文章正文因为微信环境验证没抓到，很多关键信息是缺的。比如转岗到底涉及多少人、是临时还是永久、员工有没有补偿或离职选项，这些都没披露。另外 49% 的持股比例如果属实，Meta 对 Scale AI 的控制力会很强，但文章没展开说这个股权结构是怎么来的，也没提 Scale AI 的估值和收入依赖度。 我会先打个折：这条更像内部员工吐槽，数字有冲击力但缺少官方确认。如果比例真从 1:8 跳到 1:50，那管理幅度已经大到不现实，要么是试点，要么是统计口径有猫腻。

这条消息的核心是“泄露”，不是“发布”。Opus 4.8 的名字出现在 Google Vertex AI 的模型列表里，同时一份 59.8MB 的 Claude Code 源码映射文件被公开，里面 51.2 万行 TypeScript 代码提到了 Sonnet 4.8 和 Mythos 1。从代码线索看，Mythos 1 可能跟 Claude Code 和安全工具 Claude Security 有关，但具体是什么形态——是新模型、新功能还是内部代号——正文没披露。 这类泄露能说明 Anthropic 确实在跑这些项目，但没法判断完成度或发布时间。代码里出现名字，可能只是预留接口或早期测试。Vertex AI 上短暂露脸，也可能是灰度测试或配置错误。 目前缺三个关键信息：官方确认、实际能力描述、以及任何可验证的基准测试。在 Anthropic 自己开口之前，这些名字只能当八卦看。

Verkor 的 Design Conductor 做了一次全自动芯片设计演示：输入一段 219 个英文单词的规格说明，12 小时后直接输出 ASAP7 7nm 工艺的 GDSII 版图，中间没有工程师插手。这颗叫 VerCore 的 RISC-V CPU 在 1.48GHz 下跑出 CoreMark 3261 分，看起来不低，但正文明确说它没做缓存，而且还没实际流片验证。也就是说，目前只有仿真结果，芯片能不能用、功耗和面积表现如何，全是未知数。 我会把这件事理解成一个工具链打通的概念验证，而不是芯片设计已经能甩给 AI 的信号。219 词规格说明能覆盖的设计复杂度有限，没缓存也意味着实际场景里性能会大打折扣。另外，正文没披露生成过程中有没有人工筛选或多次重跑，也没说这套流程对更复杂的 SoC 设计是否适用。想判断它到底省了多少人力，还得等流片回来的实测数据。

这条新闻的标题很唬人，但点进去只有微信的“环境异常”验证页，正文完全没加载出来。从英文摘要看，研究方 Graphite 从 CommonCrawl 这个网页快照库里抽了 4.3 万篇文章做检测，结论是 2024 年 11 月起 AI 写的英文文章数量超过了人类。他们用的检测器自称误判率约 4.2%、漏判率约 0.6%，也就是每 100 篇人类文章里可能错杀 4 篇，每 1000 篇 AI 文章里可能漏掉 6 篇。这个准确率不算差，但也没到能当铁证的程度。 我会先打个折：4.3 万篇样本在 CommonCrawl 的海量数据里只是九牛一毛，抽样方式、文章类型、语言分布全都没披露。而且检测器本身也是 AI 模型，用 AI 去抓 AI，容易陷入循环论证。另外，这个“碾压”只针对英文文章，中文、日文等其他语言的情况完全没提。 还缺什么：样本是怎么选的，有没有按网站类型分层；检测器对改写、翻译、人机混写文章的识别能力如何；数据只到 2024 年 11 月，之后趋势是加速还是放缓，正文没披露，这些缺口让结论暂时只能当个参考。

这篇测试把两种文档问答路线摆在一起比了比：让 Claude Sonnet 4.5 直接看 PDF 画面，准确率只有 52.0%，在六套方案里排第五，每次查询成本 0.2552 美元。表现最好的是先用 LlamaCloud 把文档转成文字再喂给模型，准确率拉到 59.6%，成本反而降到 0.1885 美元。也就是说，直接看画面既不准又更贵，OCR 路线反而更省钱。 不过得打个折。测试只用了 MMLongBench-Doc 里的 30 份 PDF、171 道题，样本量不大，结论能不能推广到其他类型的文档还不清楚。正文也没披露这 30 份文档的具体构成，比如图表占比多少、扫描质量如何，这些都会影响 OCR 和视觉路线的表现差距。另外，测试只用了 Claude 一款模型，换成 Gemini 或 GPT-4o 这类视觉能力更强的模型，排名会不会变，正文也没说。 还缺一个关键信息：OCR 路线的预处理时间成本。LlamaCloud 解析一份长文档要多久、出错率多高，这些都没提。如果解析环节经常翻车或者耗时太长，那省下来的查询费用可能就被前置成本吃掉了。

这条测试直接回答了一个本地部署党常纠结的问题：显存不够时，先砍 KV 缓存精度还是先砍模型权重精度。hopbel 用 Qwen3.6 27B 在 wikitext-2 上跑 16k 上下文，拿 Q5_K_M 权重当基准，用近似 KLD 分数衡量输出分布偏移。结果很直观：权重从 Q5_K_M 降到 Q4_K_XL（KV 缓存保持 f16），KLD 涨到 0.026；而权重只降到 Q5_K_S 但 KV 缓存压到 q4_0，KLD 才 0.016。也就是说，权重降一档带来的输出变化，比 KV 缓存从 f16 压到 4-bit 还大六成。 不过得打几个折。第一，测试只用了 wikitext-2 这一个数据集，测的是语言建模困惑度层面的分布偏移，不代表长文本推理、多轮对话或代码生成场景下的实际体验。第二，KLD 是近似值，正文没披露具体近似方法，分数本身只能看相对大小，不能当绝对质量指标。第三，只测了 Qwen3.6 27B 一个模型，其他架构或更小模型上结论能不能复现还不清楚。 如果手头显存紧张，这条测试给的方向是：优先保模型权重的精度，KV 缓存量化到 4-bit 甚至更低，损失可能比你想象的小。但前提是你的使用场景和测试条件接近——短上下文、语言建模类任务。长上下文或多轮对话下 KV 缓存精度的影响，这条测试没覆盖到。

Armin Ronacher拿自己的项目Pi做实验，结果issue tracker里83%的报告被自动关闭，PR合入率不到10%。这些AI生成的报告行文专业、推理自洽，但核心结论是错的。问题不出在代码质量，而出在很多人，尤其是经验丰富的老手，还在用过去的直觉判断AI输出。人类的错误有迹可循，AI却会从一个错误假设出发，推导出一整套滴水不漏的方案，老手那套识别人类错误的直觉在这里完全失灵。 Ronacher给出的解法不是更仔细地复核AI输出，而是从源头约束。他写了一个叫`/is`的命令，核心就一句话：别信issue里的分析，从代码和执行路径独立验证。这要求使用者先有自己的判断地图，再拿AI的结论去对照关键点，而不是顺着AI的思路走。文章里那组极端数据说明，行业对“会用AI”的标准还没共识，大多数人以为自己会了，其实还差着一层：知道AI什么时候在假装理解，知道在什么点上介入能扭转方向。 这篇文章的价值在于它来自一线维护者的真实数据，不是空谈。但正文没披露Pi自动关闭issue的具体判断逻辑，也没给出那83%里有多少是纯AI生成、多少是人类和AI混合提交的。这些缺口让“AI污染开源社区”的结论需要打个折，可能有一部分是低质量人类贡献被误判。