11 月 2 日 · 周一

开发者 HearMeOut-13 在 Strata 推理引擎的 dsv41-kv-splice 分支中加入两项改动，针对 DeepSeek V4.1 Flash 在本地运行时的长系统提示词读取瓶颈。第一项是 KV splice：对比新提示词与已保存的会话，剔除其中每会话不同的行（如工作目录、日期、项目 CLAUDE.md），复用已缓存的 KV 状态，只读取变化的行和用户消息。第二项是“仅驻留路由”：提示词读取阶段只从已在显存或内存中的专家里选择，避免从 SSD 流式读取大量专家权重（原文示例中，1.2K 词元的提示词曾导致约 58GB 的 SSD 读取）。测试平台为 RX 9070 XT 16GB、64GB DDR4 与 PCIe 3.0 NVMe，原帖称约 37K 词元的 OpenCode 系统提示词首词元等待时间从约 100 秒大幅缩短，标题声称提速 20 倍，但具体数字仅见于帖内图片，且作者只测了一次，尚未独立验证。作者也明确说明：目前仅支持 HIP（gfx1201），CUDA、SYCL 和 Metal 未测试；KV splice 是近似方案，没有正式评测；仅驻留路由会轻微改变回答，编码测试套件的结果为 12/13 前后一致，但也只跑了一次。两项功能默认开启，可通过 STRATA_DS4_REORDER=0 和 STRATA_DS4_PROMPT_RESIDENT=0 关闭。

OpenAI CEO Sam Altman 曾表示，让每个人在自己的电脑里占用全球有限的 DRAM 供应，而这些内存只有约 5% 的时间被使用，从全球资源分配角度看是“相当糟糕的”，他主张应追求最大化利用率。本地运行大模型时，智能体每次新会话都会把工作目录、日期等动态文本插入系统提示词，使前缀缓存（prefix cache）失效，模型因此要重新读取整段提示词，首个 token 输出可能需要等待很久。

目前该改动只在非主线分支中，尚未合并。如果你在 AMD HIP 平台上用 Strata 运行 DeepSeek V4.1 并配合 OpenCode，需要从该分支构建，并在模型配置中添加 "interleaved": { "field": "reasoning_content" }，否则 OpenCode 会丢弃早期推理内容，缓存命中率下降。如果输出质量对你很关键，应在关闭和开启两种设置下自行对比结果，因为仅驻留路由会改变生成内容。

开发者在2张RTX 5070 Ti上运行本地量化模型，与Claude模型在9个来自其私有C++/CUDA推理引擎历史的真实回归bug上对比，智能体需在无法编译或运行代码的条件下定位原因并编写补丁。Claude Opus 5.5以0.74分居首，本地最好的Qwen3.8-Flash-Next NVFP4为0.50分，与Claude Haiku 5.5（0.47分）接近。3-bit量化对分数影响不明显（Flash-Next差值为-0.02，27B为+0.05，均在噪声范围内），但27B每个任务生成的token约多40%，说明量化损失主要表现为推理更长而非得分下降。作者明确指出这只是9个任务、置信区间约±0.2、评分由Claude模型作为盲审裁判完成，且Claude与本地模型使用的框架不同，结论不宜外推为通用排名。

Qwen 3.8 Flash-Next 是 Qwen 在其 API 中作为生产模型使用的版本，也已上架 Ollama。文中的 NVFP4 版本并非 Qwen 官方发布，而是第三方 vcruz305 基于其 GGUF 量化系列打包的 NVFP4 checkpoint，若 Qwen 日后官方发布 NVFP4 版本，该仓库会予以镜像。NVFP4 是一种 4 位量化格式，可在消费级显卡上压缩模型权重。

对于在消费级显卡上运行本地模型的开发者，只看tok/s可能误判效率：文中3-bit版27B解码更快（153 vs 132 tok/s），但每个任务耗时18分钟，而非量化版的13分钟。选择量化等级时，应同时统计每个任务的token数和完成时间，并结合实际任务而非仅看困惑度。

Reddit用户Parking-Beyond4499在r/ClaudeAI发帖，质疑“Claude + Obsidian”的流行做法。他表示试用后觉得Obsidian增加了不必要的界面和功能负担，转而让所有Claude会话指向一个本地文件夹，并要求Claude把它当作Obsidian来组织，只用Markdown文件保存文本、记忆和上下文，效果很好。该帖子是个人观点和使用经验分享，没有提供新的技术测试或量化数据。

Obsidian 是一款基于本地 Markdown 文件夹（称为 vault）的笔记应用，MCP（Model Context Protocol，模型上下文协议）则是让 Claude 等 AI 工具连接外部数据与应用的接口。社区已出现多款 Obsidian MCP 插件：有的在 Obsidian 内运行本地 MCP 服务器，供外部工具读取当前上下文并在应用内执行操作；有的为 Claude Desktop 和 Claude Code 提供语义搜索与文件管理；还有的可将 Claude Code 生成的报告和代码审查直接保存进 vault。讨论中的“Obsidian + MCP”工作流正是建立在这类插件之上。

一篇博客文章称，前沿大模型 Astra 能直接阅读神经网络原始权重，推断其训练目标，并在不使用梯度的情况下编辑或从头编写权重。在 Qwen3.5-0.8B 上，Astra 通过修改约 0.016% 的权重修复了推理循环问题，据称在相同采样设置下将 MATH-500 从 7.9% 提高到 48.1%，IFEval 约提高 3 倍。这些均为作者披露的早期结果，提供的材料中没有独立复现，也无法验证 Astra 的可用性。

Weight-Space Programming 建立在机械可解释性研究之上，文中提到的归纳头（copying head）等结构分析方法来自 Elhage 等人的工作，研究者此前已用这类方法理解小模型的计算。本文的新意在于让通用大语言模型直接读写权重，而不是依赖梯度下降或专门训练的优化器。第三方的一篇技术解读（2026 年 9 月）讨论了 GPT-6 Astra 与开放权重模型循环架构的关系，可作为理解该模型的补充背景，但它并未验证本文的性能结论。另外，GitHub 上的 LyoAI/Astra 是一个同名但无关的项目。

如果这一结果成立，开发者可以在不依赖梯度训练的情况下，针对小型开源模型中的特定缺陷（如循环输出）做定向修正。但目前证据仅来自单篇博客，不应将其视为可靠的微调替代方案。若想评估，建议在相同采样设置下用 MATH-500 和 IFEval 独立复测。

Subvocal（YC F26）发布了一款智能眼镜原型，用户可以无声地用嘴型“默说”，设备通过射频（RF）感知口腔、舌头和软腭的运动，再由基础模型解码为文字，团队称速度可达说话速度。团队表示计划在2027年第一季度出货，目前已开放首批500台的预购，预购价较最终售价优惠200美元。以上速度、准确率等表现主要来自团队自述和演示视频，尚未有独立测评或公开基准数据支持。

无声语音接口（silent speech interface）通过感知与发音相关的口部、舌部或唇部动作来识别语言，相关研究已有多年积累，维基百科的“Subvocal recognition”条目对此有概述。与本项目最直接相关的前身是麻省理工学院媒体实验室的 AlterEgo，该项目始于 2018 年，2025 年初分拆为营利性公司，其可穿戴系统允许用户在无声、几乎没有可见动作的情况下与设备交互。Subvocal 团队表示，他们在斯坦福 TreeHacks 黑客松上受 AlterEgo 启发，用肌电（EMG）电极做出了粗糙原型，后因电极易受汗水和电磁干扰影响、且用户不愿在脸上贴电极，转而采用射频方案。

对于需要在图书馆、办公室或公共场所进行语音输入、又不便出声的用户，这类设备若能落地将提供一种免提且相对隐蔽的输入方式。不过目前产品仍处于研发阶段，且团队称每位用户需要约20句的校准，跨用户的泛化效果是否稳定仍有待验证，潜在买家应将预购视为早期投资而非成熟产品。

据原文，Linux 内核 TCP 代码中的漏洞 CVE-2026-98432 被评为 CVSS 9.8 分的严重漏洞，可远程利用，且自 2016 年起就已存在。原文转述 Anthropic 的说法，称其已构造出能在服务器上获取 root 权限的可用利用程序，但原文未提供验证细节。原文作者称 Debian 已于 10 月 16 日发布修复，而截至 2026 年 11 月 2 日，Ubuntu 仍未发布补丁，其安全页面将所有受支持版本（包括 LTS）标为「Vulnerable」。

根据 Ubuntu 安全公告，CVE-2026-98432 涉及 Linux 内核 IPv4 TCP 代码。公告描述显示，tcp_v4_syn_recv_sock() 会把 ireq->ireq_opt 的所有权转交给子套接字（newinet->inet_opt）而不做复制，修复方案则是在 RCU 宽限期之后再释放 inet_opt 和 ireq_opt。公告页面的完整技术细节有限，因此这里只能依据其中可见的描述说明问题的大致位置。

对仍在运行 Ubuntu 服务器的用户而言，原文并未给出官方补丁，因此应先通过 Ubuntu 安全页面核对自己的内核版本和该 CVE 的状态。评论区有人称修复内核已进入 Ubuntu 的 proposed 仓库，并于 10 月 28 日进入 26 LTS 的 updates/security 仓库，这一说法与原文相矛盾，需自行核实后再依赖。

据报道，欧洲多地超市的冷冻柜和冷藏柜被疑似网络攻击干扰而失效，这是第二起类似事件。与之相关的报道称，爱尔兰超市 SuperValu 已从 13 家门店撤下冷冻和冷藏食品。目前攻击来源和具体技术手段仍属于疑似，尚未得到官方确认。

此次事件被称为欧洲超市冷柜遭受的第二起疑似网络攻击。维基百科已有对应条目《2026年法国超市冷柜入侵事件》，记录了此前的同类事件。《卫报》也称这是两周内第二次出现类似的疑似网络攻击。

对依赖联网制冷控制器的零售商来说，远程管理和设备网络连接可能成为攻击面，需要重新检查这类设备的访问控制和网络隔离。SuperValu 的下架事件表明，控制系统故障会直接造成库存损失和食品安全处置问题。

Reddit帖子称，Qwen负责人在一份公开表态中明确，未来的Qwen 4.0和Qwen 5.0将继续开源，以回应此前「Qwen4将是最后一个开放权重系列、之后仅提供API」的传闻。该表态的核心立场是让AI能力被更多人获取、使用和参与创造，但目前仅是官方声明，未附带任何发布时间、许可证或具体权重细节。帖子中的累计下载量超过30亿次、已发布460多个开源模型、衍生模型超过30万个等数据，目前尚未经独立核实。

社区此前流传 Qwen4 可能是最后一个开放权重系列、之后版本只提供 API 的传闻，本条声明即是对这一说法的回应。LLMCheck 2026 年 9 月的开源本地模型盘点也将 Qwen 4 列为传闻中的模型，并指出厂商的开放权重承诺若缺乏明确日期和许可证，只有在权重实际发布于主要来源后才可作为可用模型计入。

如果该承诺兑现，依赖本地自托管的开发者在Qwen4及之后版本发布时仍可获取开放权重，可以据此规划迁移或部署。但在具体版本发布前，应以官方发布的许可证条款和模型卡为准，确认商用与再分发条件，不宜仅凭此声明作出长期技术选型。

开发者 ConfidentDinner6648 发布了 Qwen3.5-4B-GLB-3D-Coder 的首个可用检查点，这是一个 4B 开源权重的编程模型，可以编写 Three.js 场景并导出 GLB 3D 资产，供 Godot 等游戏引擎使用。作者建议使用模型卡中的系统提示词，并用英文发出简单请求（如“Create a mana potion”），推荐采样参数为 temperature 0.8、top-k 40、top-p 0.95、min-p 0。作者称多数生成结果首次即可使用，但仍有部分需要重试或小幅修改代码，训练仍在进行，预计下一天结束，完成后将公开完整 Safetensors 权重和训练数据集；这些效果均为作者自测，尚无独立评测。

该模型基于 Qwen3.5-4B 微调，原本用于编写 Three.js 场景代码，本版的新方向是让它生成可导出为 GLB 格式的 3D 资源。GLB 是 glTF 的二进制格式，Godot 等引擎可直接导入；Three.js 是常用的 Web 3D 库，因此模型输出的是可运行的 Three.js 代码，而非直接生成网格文件。帖子称这是作者此前发布的 3D 编程模型的后续版本，作者表示前一版收到的反馈直接促成了本版专注于游戏资产生成的方向。搜索结果中还有一个名为 Qwen3.5-4B-3D-Coder 的 GGUF 模型卡（作者为 prithivMLmods），名称相近，但无法据此确认它与本帖模型或作者的前一版本是否有关。

作者于 2026 年 11 月 2 日 04:50 UTC 更新了 Q4_K_M 和 Q8_0 两个 GGUF 版本，使用 2 日之前下载的用户需要删除旧权重并重新下载，因为文件名没有变化，否则可能仍在加载旧版本。

ISTA DASLab 发布了 DeepSeek-V4.1-Flash-1017 的编程（Coder）版本，采用 GSQ 与 RCO 进行压缩，并删除了一半的路由专家（每层从 384 个中保留 192 个）。该 GGUF 的 Transformer 权重为 72.1 GB，未剪枝的 IQ2_XXS 版本为 138.2 GB。按原始 5519 亿个 Transformer 参数计算，平均约为 1.05 比特/参数，但这一数字把被删除的专家计为 0 比特，保留下来的参数平均约为 2.06 比特。官方报告 LiveCodeBench v6 得分为 88.57（基础模型 89.71，保留 98.7%），SWE-bench Verified 得分为 77.00（基础模型 81.20，保留 94.8%），这些均为厂商自报结果。该版本需要 llama.cpp b11870 或更新版本或 Strata 才能运行，官方定位为实验性发布。

ISTA 此前已把 GSQ 与 RCO 用于 Qwen 3.8 27B 的量化发布，第三方报道称其可压缩到约 2 比特，并能通过 llama.cpp 在本地运行。在那一工作中，RCO 的作用是在总体大小预算下为每个张量分配量化类型；本次 DeepSeek-V4.1-Flash Coder 则把同一类优化用于选择保留哪些路由专家，并要求每层的专家数预算精确满足。

对本地部署者而言，文件体积仍然很大：Coder 版 GGUF 约 72.1 GB，还需下载与未剪枝版本共享的 110.6 GB Engram 文件，合计约 183 GB（不含视觉投影器）。因此“1 比特”应理解为平均值，实际保留的专家仍约为 2 比特，部署前需要确认硬件容量和推理框架版本是否满足要求。

一位Reddit用户报告，在单张RTX 3090 Ti（24 GB显存）加128 GB DDR4内存的Gentoo系统上，运行DeepSeek-V4.1-Flash-1017（552B MoE，约39B活跃参数）达到约35 tok/s的解码速度，运行Qwen3.8-Flash-Next（125B MoE）达到约130至140 tok/s。这些数字由作者自行测得，所用推理引擎为其分支项目Xolotl，依赖NVMe上的专家表流式加载、推测解码（MTP/DSpark）、路由偏置（route-bias）以及一个第三方内核模块gpu-unlock，但帖子未提供独立的质量评测。模型采用的是量化版本，且包含未审查（Uncensored）变体，因此速度结果不能直接推断为与未量化基线相同的输出质量。

原文使用的 gpu-unlock 是一个开源 Linux 内核模块，可在早期启动阶段解除 RTX 30 系列（GA102、GA103、GA104、GA106）GeForce 显卡的 FP16/BF16 张量核心速率限制，且无需刷写自定义 VBIOS 或修改闭源驱动，相关项目也已出现针对 Ada 卡的版本 [tool-1-1][tool-1-2][tool-1-3]。原文的 DSpark 推测解码依托 Xolotl 引擎，其推测解码的基本思路是用较小的草稿模型先猜测多个 token，再由完整模型一次性校验 [tool-2-2]；Xolotl 文档（2026-10-14）称其 DSpark 在一次性贪婪解码测试中快于普通解码 [tool-2-1]。

想复现该配置的开发者需要注意，这套方案依赖未经独立验证的自定义分支、从单一上传者获取的量化权重，以及需要以root权限安装的内核模块。在采用前，应在自己的任务上与参考实现对比输出质量，并在安装内核模块前审查其源码，而不是仅凭帖子中的速度数字做决定。

据 r/ClaudeAI 的这则帖子及评论区讨论，Claude 的 5 小时用量限制似乎已被取消。帖子正文只有一句感叹并附带链接，未提供官方公告或具体细节，因此该变更尚未得到确认。讨论者普遍认为，这一限制此前起到了缓冲作用，取消后用户可能在一两天甚至数小时内耗尽每周额度。

Claude 订阅的用量限制通常包括滚动的5小时窗口和每周总量上限，5小时窗口内的用量会随时间逐步恢复，起到缓冲作用。据外部报道，Anthropic 于2026年10月30日宣布将原Max 20x更名为每月200美元的Ultra套餐，并移除该套餐的5小时用量窗口，每周上限保持不变。其中一篇报道称此次变更适用于已通过验证的Claude及Claude Code订阅用户，但其他报道对新账户是否适用的表述不一，具体范围仍应以官方说明为准。

如果该变更属实，频繁使用编程代理的开发者可能会比以往更快用完每周额度，需要提前规划用量。这一判断目前主要基于社区反馈，尚未经过官方证实。

一位 Reddit 用户借助 Claude Code 和用于保存项目上下文的 CLAUDE.md 文件，把 NordicTrack Commercial 2250 跑步机 Android 9 平板上的 iFit 界面替换为无广告、无需登录的自定义主屏，主屏上有 Netflix 和 Crunchyroll 的大图标入口。他还通过 ADB 与 iFit 电机服务通信，客户端参考开源项目 QZ（qdomyos-zwift）的协议自行实现，并在播放画面上叠加显示速度、坡度、时间和距离，称 Netflix 启动时间从近一分钟缩短到约 21 秒。这些都是作者的自述，尚未经独立验证；作者提到的限制包括 Netflix 只能以标清播放（Widevine L3）、平板性能较慢，以及恢复出厂设置可能清除所有改动。项目已发布在 GitHub 上。

开源项目 QZ（qdomyos-zwift）是一个为智能跑步机等设备提供 Zwift 等应用桥接的工具。它连接 NordicTrack 或 iFIT 设备有两种方式：gRPC 版本依赖已安装、运行并登录的 iFIT 应用，由 iFIT 再与控制台通信；FitPro 版本则通过 USB-HID 直接访问控制台，但要求关闭 iFIT 应用，并兼容所有 iFIT 版本。本文项目借鉴了 QZ 的通信思路，但选择继续依赖 iFIT 的电机服务，而不是直接访问电机控制板。

该案例表明，iFit 等订阅服务的功能限制可以在用户本地被绕过，但操作风险较高：作者称一次尝试禁用应用时导致电机服务崩溃，恢复耗时约半小时，且评论区有用户报告跑步机因系统更新而无法启动。修改前应先备份，并优先选择可撤销的方式，同时注意改装可能使保修失效。由于改动涉及可以带动跑步带的电机控制，作者也提到测试时设置了速度上限，并保留了安全钥匙和控制台的停止按钮作为真正的停机手段。

据 Reddit 用户 u/ploz 对 Steam 公开数据约 63,600 款游戏的分析，2026 年 10 月发布的新游戏中有 49.9% 披露了使用 AI 生成内容，高于 2025 年同期的 26.4%，也高于 2024 年 1 月 Valve 引入强制披露规则时的 1.7%。分开看，2024 年披露率为 13.2%，2025 年为 24%，2026 年截至 10 月为 40.1%；小型游戏（评论数少于 10 条）披露率为 47%，而评论数超过 1,000 条的游戏仅为 14%。需要注意，这些数据依赖开发者自行披露，未披露的 AI 使用不计入其中；Valve 已于 2026 年 1 月将披露要求调整为只针对玩家能看到或听到的 AI 生成内容，不再包括开发过程中的幕后工具。

Valve 在 2024 年 1 月为 Steam 引入强制性的 AI 披露要求，开发者需要申报游戏中的部分生成式 AI 用途。2026 年 1 月，Valve 调整了披露口径，重点改为要求披露玩家能看到或听到的 AI 生成内容，不再包括开发过程中幕后使用的工具。因此，统计数据的变化可能部分反映规则调整，而且所有数据都依赖开发者自行申报，未披露的 AI 使用不在统计范围内。

由于 Valve 的披露规则已改为只针对玩家可见的 AI 生成内容，开发者若在代码或开发流程中使用 AI 工具，无需按现行规则披露，因此这一统计反映的是可见 AI 内容的披露情况，而非 AI 在开发中的实际普及程度。

DeepSeek Harness团队于10月31日发布了设计文章《Exploring Super-agent Design》，并附带MIT许可的研究原型dsh-superagent-prototype。该方案并非新的基础模型，而是围绕现有模型驱动工具的编排层，目前针对单个GitHub仓库构建：一个持久的Router会话负责接收对话和分派任务但不亲自执行，每个被接受的工作项各自拥有独立的Worker会话和目录，从而并行运行且互不共享上下文。原型可监听GitHub事件（可选接入飞书消息），并通常以Pull Request形式将结果返回原对话，本地网页面板只列出需要人工决策的事项。需要说明的是，这是研究代码而非正式产品，团队称其未达到生产可用标准，可能存在缺陷，且与其内部系统有所不同；其中部分构想仍属未来方向。团队自称的评测显示，在约300条合成消息、每轮约20个真实工作请求的模拟测试中，最慢5%的任务耗时从单会话基线的29.5分钟降至15.7分钟，但这些数据为团队自报，使用的是合成消息和模拟工具，并未衡量真实编码质量，也没有与Claude Code或Codex的已验证对比。

dsh-superagent 是 DeepSeek Harness 团队的打包组件，其 README 将它描述为面向单个 GitHub 仓库的主动式编程智能体。项目以 MIT 许可证公开在 deepseek-ai 的 GitHub 账号下，README 还注明文章中的部分设计只是未来方向，并未在该原型中实现。

对于考虑让智能体自动处理代码任务的团队，该原型提供了可检视的参考设计：默认仅观察、不执行，写入权限需由人工明确授予，并支持按团队规则允许的范围主动工作。若要试用，应先在沙箱或个人项目中以草稿PR形式运行，并在授予合并权限前评估其拆分任务的准确性，因为拆分不当会增加需要人工审阅的PR数量。