10 月 25 日 · 周日

作者 danluu 认为，借助 AI 工具，开发者现在能完成过去难以实现的大型项目，并呼吁开发者更有雄心。他以 Michael Malis 的 pgrust 项目为例，称其测试相当充分，并借此发现了 Postgres 的多个真实 bug，但性能方面的成果仍需进一步验证。作者自己也在几个小时内做出了正则引擎、ripgrep 分支和 Rust 构建提速等「够用」级别的项目，并指出要达到实用质量仍需大量测试和基准测试。

pgrust 是 Michael Malis 与 Jason Seibel 发起的 PostgreSQL 实验性 Rust 重写项目，以 AGPL-3.0 许可发布，官方称其在 wire 协议和 SQL 方言上与 Postgres 兼容，旨在探索用 2026 年的技术重新构建 Postgres 会是什么样子。项目页面宣称其性能超过 Postgres 和 ClickHouse，这是项目方的说法，尚未经过独立验证。

对开发者而言，AI 显著降低了构建专用工具的成本，但文中强调，可用性取决于测试与基准测试的质量，而非 AI 生成代码本身。在采用此类由 AI 快速生成的项目前，应检查其测试覆盖和基准测试方法，而不是只看宣传的性能数字。

Cerebras 发布技术文章，介绍如何把约 3 万亿参数的开源模型 Kimi K3 拆分到多块 WSE-3T 晶圆上运行，并宣称可达到 1000–2000+ tokens/s。文中示例采用 4-bit 权重量化和 8-bit KV cache，线性注意力层每片晶圆放两层，稠密层每片放一层，晶圆之间以流水线方式只传递激活值，单跳约 2 微秒。按文中假设的 256k 平均请求长度，估算需要 59 片晶圆（35 + 24），并给出并发请求数的计算方法。这些是厂商的设计推演和性能宣称，文中没有提供独立第三方的实测结果。

本文以 Kimi K3 为例说明如何在晶圆级芯片上部署万亿参数模型。Moonshot AI 于 2026 年 7 月 28 日公开了 Kimi K3 的完整开源权重（见 tool-2-3），而各报道对其规模的表述不一，有的称 2.8 万亿参数（见 tool-2-1、tool-2-2），文章则采用约 3 万亿参数。由于单片 WSE-3T 晶圆的片上内存仅 44 GB，模型必须被拆分到多块晶圆上运行，这也是文章的核心内容。

文中的吞吐和并发数字都基于 4-bit 量化与假设的请求长度。评论者指出，文中引用的基准分数来自全精度模型，而实际部署的是量化版本。因此，在将 Cerebras 用于代码或智能体任务前，应在自己的任务上验证输出质量，并确认所部署的具体模型版本与量化方式。

据 r/LocalLLaMA 帖子转引的一条 X 推文称，名为 REA（Reserve Engineer Anything）的逆向工程工具在发布一天后被 Claude 拦截。帖子标题还提到 OpenAI，但正文只给出 Claude 的说法，OpenAI 相关指控缺乏正文支持。标题称该工具用于分析智能电视的监控行为，但正文没有提供被拦截的具体对话、截图或官方回应，因此目前仍是未经证实的二手转述。

此前，安全研究员 log4j 发现自己的三星电视收集大量用户数据（包括音频和屏幕截图，用于广告定向），他在分析过程中被 OpenAI 以“网络滥用”为由封禁，这是此次争议的直接前情。Anthropic 于 10 月 8 日发布了 2026 年使用政策更新，将于 11 月 12 日生效，官方称多数改动是对既有规则的澄清；来源未说明此次拦截是否与该更新有关。

需要分析设备固件或应用的开发者和安全研究人员，可能在使用 Claude 处理逆向工程任务时遇到拒绝回应。评论中有用户报告 ChatGPT 也对类似请求作出拒绝，同时另有评论称询问游戏“逆向”时并未触发拦截，说明拒绝行为可能取决于具体措辞和语境，因此不宜把它当作稳定的工具链组件。

Nanbeige 在 Hugging Face 发布了开源权重模型 Nanbeige4.3-33B，采用 Apache 2.0 许可，模型卡列出 512K 上下文窗口。该团队称其在 Terminal-Bench 2.1 上得分 80.9，高于 Qwen3.8-27B 的 73.0，但在 SWE-Bench Pro 上为 60.3，低于对方的 61.7。这些结果均为发布方自行测试，尚未有独立复现；团队还表示，该模型将作为教师模型，用于蒸馏其计划中的 3B 等小模型。

Nanbeige4.3-33B 是一款于 2026 年 10 月 24 日发布的开源权重稠密模型，参数量约 331 亿，采用 Apache 2.0 许可证，上下文窗口为 512K，主要面向编程和办公类智能体任务。文中提到的 Terminal-Bench 2.1、DeepSWE 等基准属于智能体基准，考察模型在多步任务中自主调用工具并完成执行的能力，而不只是单轮问答。这些分数均为该实验室自行报告的结果，因此与 Qwen3.8-27B 的对比需结合具体测试环境理解。

如果你计划在本地或自有环境中评估该模型，应在相同推理设置下自行验证。评测结果依赖 preserve_thinking=true 设置，模型卡建议将其用于多轮工具调用，而非通用对话，因此比较时需固定该参数，并同时关注任务成功率和生成的总 token 数。

这篇 LocalLLaMA 帖子认为，KL 散度（KLD）是评估量化模型的有用诊断指标，但不能单独用来排名量化模型的质量。作者指出两个主要问题：一是若用维基百科等通用文本计算 KLD，结果可能无法代表模型推理时的实际上下文，更合理的做法是用基础模型生成文本，并只统计生成 token 的 KLD；二是量化校准数据若与评估数据重合，或在同一数据上微调量化参数，KLD 数值会被明显压低，因此数值可能被人为操纵。作者还强调，较高的 KLD 并不等于任务必然失败，帖子正文未提供具体的基准数据。

KL 散度（KLD）衡量两个概率分布的差异。在量化评估中，它通常比较原始模型与量化模型在同一段文本上每个 token 的输出分布，再取平均值，用来反映量化造成的偏离程度。另外，Heretic 这类去审查工具把参数搜索目标设为同时最小化拒答次数和与原模型的 KL 散度，以在去除拒答的同时尽量保留原模型能力，因此 KLD 在社区中被频繁引用。

选择量化模型的用户不应只看模型发布方公布的 KLD 数值，而应检查其使用的校准数据与评估数据是否重合，并尽量用与自己任务相关的测试进行验证。如果要自行比较不同量化版本，应对所有模型使用相同的输入，并尽量采用模型生成的文本来计算 KLD。

ISTA-DASLab 发布了 DeepSeek-V4.1-Flash 的 GSQ-RCO GGUF 量化版本，其中 IQ2_XXS（约 2 bpw）在其基准测试中据称与基础模型持平。但这些基准已接近饱和（多数超过 90%，AIME25 所有版本均为 100 分），难以反映质量退化，且原帖作者未找到该系列模型的 KLD 数据。原帖因此询问社区是否有人实测 KLD 或 PPL，目前帖子中尚无经过独立测量的数值结果。

GSQ-RCO 由 ISTA DASLab 开发，包含两个部分：GSQ 以指定的量化类型对每个张量做精确的低比特标量量化，RCO 则在体积预算下为各张量分配量化类型。因此，这类「2-bit」GGUF 的平均比特数约为 2，但不同张量的精度可以不同，这也是评估其质量时需要考虑的前提。

计划在本地高内存设备上运行该 2-bit 版本的用户，目前不宜仅凭已公布的基准分数判断质量损失。建议用与自身工作负载相近的任务进行对比测试，并关注 KLD 或 PPL 等更能揭示退化的指标，直到出现独立测量结果。

Reddit 用户 /u/McArhony 称，其十多年前购买的三星洗衣机在三星停止支持 Smart Control 后失去了联网控制功能。他借助 Claude 在约两小时内恢复了该功能，使其能在 SmartThings 中设置程序、温度和脱水转速，并联动烘干机。该项目代码已发布在 GitHub 仓库 smartthings-samsung-drc-washer 中，作者称 2014 至 2018 年的部分机型使用相同通信协议。帖子中的兼容性说法和效果均未经独立验证，且自动投放剂功能仍无法工作。

三星的 SmartThings 应用可以远程控制联网的洗衣机和烘干机，用户能在手机上选择洗涤程序，并调整温度、漂洗次数和脱水转速等参数。原帖中的问题是，较早的机型在厂商不再支持“Smart Control”后失去了这一官方远程控制能力，作者借助 Claude 编写的项目试图让旧机器重新接入 SmartThings 生态。

如果你拥有帖子中提到的 2014 至 2018 年间的三星联网洗衣机，该仓库可能可以作为参考，但它只是作者自行尝试的个人项目。安装前应先检查代码，并注意作者本人提出的安全顾虑：启用远程控制会增加设备暴露在网络上的风险。

开发者用 Claude Code 在约两周内开发了 ScreenPlink，这是一款开源（Apache-2.0）、仅支持 Windows 的激光干火射击游戏。玩家用红色激光训练枪射击显示器，摄像头对准屏幕而非玩家，由程序识别激光命中的像素位置并显示弹孔。开发者称代码几乎全部由 Claude Code 编写，并通过一个进程内 MCP 服务器让智能体读取摄像头画面和检测器的中间测量数据来调试。项目要求哑光显示器、支持 60 fps 的摄像头和红色激光训练器，光面屏幕和电视无法使用。

任红外或光学检测类游戏的理解，需要先了解早期光枪的原理。任天堂 NES 的 Zapper 光枪并不是通过摄像头看屏幕，而是在枪管末端放置光传感器，配合依赖 CRT 电视逐行扫描的时序来判断是否命中，因此只能在 CRT 显示器上工作（来源：Adafruit 指南与 Gizmodo 对 Zapper 工作原理的说明）。ScreenPlink 则反过来由摄像头拍摄显示器，识别激光点的位置，并利用应用自身在显示器上绘制的标记来学习摄像头与屏幕之间的坐标映射，因此适用于现代哑光 LCD 显示器。

原文给出的一个可复用做法是：让智能体调试物理测量程序时，MCP 服务器只返回原始测量值，而不返回应用自身的结论，因为作者发现应用的结论曾多次出错。作者还用“故意重新引入已知缺陷并要求对应测试变红”的变异测试来验证测试本身是否有效，首轮有 3 个缺陷未被发现，现在 326 个变异全部被捕获。这些是作者的经验报告，尚未经独立复现。

Reddit 用户 DexterTalks101 在 r/ClaudeAI 发帖，称自己用 Claude Code 能在早上下达指令、去健身后回来得到可用的第一版应用，并经营一家软件开发公司。他担心如果通用应用、CRUD、仪表盘和基础 SaaS 变得很容易构建，传统外包行业将受到冲击，并询问竞争优势会转向行业专业知识、分发渠道、专有数据还是明确知道该做什么。这是一个开放式讨论帖，并非产品发布或经过验证的研究结果，帖子中没有提供新的基准数据。

讨论中有评论引用了彼得·瑙尔（Peter Naur）1985年的论文《Programming as Theory Building》，认为它在AI编程时代比以往更有参考价值。该文主张编程本质上是程序员形成某种理论（即对问题和系统的理解与心智模型）的活动，而不只是产出代码。因此，即使AI能快速生成代码，系统的维护与产品决策仍依赖于人对其的理解。

一位皮肤科医生在 MILK10k 公开数据集中随机抽取了 200 个经活检证实的皮肤病变，对比了 GPT-6 Astra、Claude Fable 5.1 和一个微调过的 Inception v3 CNN（2015 年发布的老架构，在单张 H100 上训练）。在六选一的首选诊断中，CNN 正确率为 62%（125/200），两个大模型分别为 42%（84 和 85）；在前两选中，CNN 为 173，两个大模型为 134 和 138。需要注意，这是作者个人撰写的测试，样本量小（仅 30 例黑色素瘤），大模型每题只运行一次，且 MILK10k 自 2025 年起公开，大模型可能已接触过相关数据；作者也明确表示 Inception v3 只是基线模型，并非最先进方法。

本文的测试图像来自 MILK10k 数据集，它由国际皮肤影像协作组织（ISIC）发布，每个病灶都配有一张临床近距离照片和一张皮肤镜图像，用于辅助诊断疑似恶性皮肤肿瘤。ISIC 档案中的完整 MILK10k 包含 10480 张图像，对应 5240 个病灶。其公开基准子集包含 958 张图像、479 个病灶，覆盖 11 个诊断类别。

对于在医学影像等窄任务上选型的团队，这一结果说明不宜默认通用大模型在专业任务上更优，更稳妥的做法是用任务专属数据做对照评测。但该结论基于单人、小样本、未经同行评审的测试，不能直接外推为临床可用性或大模型整体能力的判断。

Reddit用户在r/LocalLLaMA发布了基于Qwen3.5-4B的独立微调模型预览，目标是兼顾通用编程与3D场景生成。模型提供Q4_K_M和Q8_0两种GGUF量化版本供下载，作者表示训练仍在进行，几天内会更新最终版本并公开训练数据集。帖子附有演示视频，但正文未给出基准测试或3D生成质量的量化数据，效果目前主要依据作者展示。

本帖的微调基座是阿里 Qwen3.5-4B，属于 Qwen 3.5 小型稠密模型系列，检索结果显示该系列覆盖 0.8B 至 9B。Qwen 3.8 据称建立在 Qwen 3.5 架构之上，并在编程和长程智能体任务上有所提升，但本帖并未基于它训练。

对于想在本地运行小模型、生成网页端3D场景代码的开发者，这一版本可以作为试用对象。但训练尚未完成、缺少公开评测，且模型和数据集都将更新，因此现阶段不宜把其效果视为稳定结论，建议等正式版和数据集发布后再评估。

r/LocalLLaMA 上一条帖子呼吁用户备份自己的量化模型，并分享种子文件。帖子中链接的 mradermacher 量化模型页面称，其在 Hugging Face 的存储空间已接近上限，团队可能会通过删除大量仓库来应对，但该页面写的是「很可能」，尚未确定。该页面还说明，改名功能存在缺陷，要重新生成文件通常只能删除仓库，而这也会删除社区讨论区。提供的原文没有明确说明发帖人此次呼吁的直接触发事件，因此不能确定删除计划即是原因。

量化（如 GGUF 格式）把原始大模型压缩成更小的版本，使其能在消费级硬件上运行，而 r/LocalLLaMA 社区有不少本地部署用户依赖 mradermacher 等个人维护者发布的量化模型。Hugging Face 对所有仓库类型（包括模型和数据集）设有存储上限。mradermacher 在其模型请求页面中写道，该账号已接近 Hugging Face 的存储上限，可能需要通过删除大量仓库来应对，这与本帖的备份呼吁有关联，但原帖正文并未说明具体触发原因。

对依赖 Hugging Face 上第三方 GGUF 量化模型的用户来说，主要风险是文件可能无法再获取。mradermacher 的页面称其已接近 Hugging Face 存储上限，可能会通过删除大量仓库来腾出空间，而删除仓库时关联的社区讨论也会一并消失，因此需要长期保留的量化文件应提前备份到本地。Nvidia 以约 129.3 亿美元收购 Hugging Face 的消息已被公布，公开资料称其附有书面的开放承诺，但现有证据并未表明此次收购与仓库删除有关。

开源项目 Zagitta 以 Linux 内核模块形式解锁 Ampere 架构（GA102、GA103、GA104、GA106）GPU 的全速 FP16/BF16 运算能力，无需刷写 vBIOS 或进行硬件改装。作者提供的测试显示，RTX 3090 Ti 的 BF16 密集 GEMM 从约 87.5 TFLOPS 提升到约 157 TFLOPS；在一项长上下文 LLM 测试中，RTX 30 卡的 Prefill 速度提升 33–36%，首词延迟（TTFT）降低约 25%，Decode 性能未受影响。目前该工具仅支持 Linux，Windows 尚不支持，文中提到 RTX 40 也有提升但未给出具体数据。标题中的 30x/40x 等说法在原文中并无依据。

NVIDIA 此前为挖矿专用的 CMP 系列显卡，通过 BIOS 固件和补丁放开了部分算力限制，并有针对 CMP 卡的工具解锁显存容量，但 GeForce 消费级 RTX 30 的 FP16/BF16 指令发射速率仍受固件限制。gpu-unlock 项目将 CMP 解锁工具的 V67/PLM 技术与 UEFI 方案的驱动前时序结合，以 Linux 内核模块的形式在 NVIDIA 驱动绑定前完成解锁，因此无需刷写 vBIOS，也无需修改驱动。

想在 RTX 30 上尝试该方案的用户需要使用 Linux 环境，并注意 GA103 目前尚无成功报告，RTX 3080 Ti 20 GB（OEM，GA102-250）的 BF16 速率也未能恢复。性能数据主要来自个别用户和作者自测，实际收益需结合自身模型和负载验证。

一篇Reddit帖子介绍了Lean-QwenFlash项目，作者将GLM的SSD专家卸载实现改造用于Qwen3.8-Flash-Next（125B）模型，核心是把专家权重直接从NVMe SSD流式读取，而不是全部常驻系统内存。作者自报在RTX 4090上（帖文称16GB显存、分配8GB系统内存），使用3.05bpw量化和Q4 KV缓存，8k上下文下散文解码约28–33 tok/s，100k上下文约20.8 tok/s，262k满上下文约20.0 tok/s；在3080 Laptop（16GB显存、32GB内存）上100k上下文约18–21 tok/s。这些数字均为作者自报且尚未经独立复现，帖文中的硬件描述也存在不一致（4090通常为24GB显存），安装脚本和说明已发布在GitHub仓库中。

这一做法沿用了 sybil-solutions 的 glm-flash-lite 项目思路。该项目让 GLM-5.3-Flash（EXL3 3.05 bpw，约 125 GB）在单张 24 GB RTX 3090 上运行，把放不进显存的专家权重放在主机内存和 NVMe 固态硬盘中。Qwen 3.8 Flash Next 据称是 125B-A6B 的 MoE 模型，原生支持 262K 上下文，本帖将同样的卸载思路移植到了该模型上。

对内存有限但配有高速NVMe SSD的本地用户而言，该方案提供了一条在消费级硬件上尝试大型MoE模型的路径。但其代价是3.05bpw的低比特量化，输出质量相对全精度模型的差距需要使用者自行评估。采用前应核对作者基准测试的条件，包括上下文长度、量化配置和磁盘速度。

Reddit 用户 u/Torturephile 使用 Claude Code 为《Flight Simulator 95》和《Flight Simulator 98》制作了 EXE 补丁工具，使这两款原本无法在 64 位 Windows 上运行的老游戏能够启动。作者最初怀疑崩溃源于 WINDOW.DLL 和 G3D.DLL，但 Claude 在 FS98 中发现问题出在主程序 FLTSIM98.EXE 内处理除零异常的例程，补丁通过在入口点添加 86 字节代码，用 AddVectoredExceptionHandler 注册该例程。FS95 的对应例程位于 DIVTRAP.DLL，因此作者无需修改原始 DLL。作者称两款游戏在其测试中均运行正常，但该结论仅来自作者自测，补丁需用户自行安装游戏并阅读随附说明。

FS95 和 FS98 基于 DirectDraw（DirectX 7 及更早版本）图形接口开发，社区此前常用 DDrawCompat 这一 ddraw.dll 包装器修复其在新系统上的兼容与性能问题，它不做 API 转换，而是在原生 DirectDraw/Direct3D 1-7 之上做兼容修正（tool-1-2）。据报道，FS98 的 EXE 内置了微软编写的除零异常处理例程，位于 try/except 结构中，而 64 位 Windows 无法在窗口回调内部触达这一机制，导致游戏崩溃（tool-1-1）。此前较稳妥的做法是在 32 位 Windows 7 上运行这些游戏（tool-1-3）。

对于想在 64 位 Windows 上重玩这两款老游戏的玩家，这是一个可直接使用的社区补丁工具，但游戏本体需自行从光盘或其他渠道获取。作者推荐配合 DDrawCompat 解决显示问题，说明补丁本身未必能完全消除渲染故障。