2.4 万亿参数，每步只激活 950 亿

这组数字的命名已经写明了规格：「2.4T」代表模型总参数量达到 2.4 万亿；「A95B」代表每次前向计算只为单个词元激活 950 亿参数。实现这一点的，是混合专家（MoE）结构：模型共 92 层，每层拥有 512 个专家，每个词元只路由到其中 10 个路由专家加 1 个共享专家。底层采用 Qwen3.5 架构，并混合了门控 DeltaNet 与门控注意力机制。

相比训练一个 2.4 万亿参数的稠密模型，MoE 让「模型很大、跑起来却只需算一小部分」成为可能，大幅压低了推理成本。原生上下文长度为 262144 个词元，最长可扩展至约 101 万词元，足以覆盖长文档与长周期智能体任务。

和云端 Max 版不是一回事

需要区分的是，放权的开源版与早先上线的云端版 Qwen3.8-Max 并不完全相同。云端 Max 于 8 月初发布，额外支持视觉输入、可关闭的思考模式、默认 100 万词元上下文，以及官方内置工具；而开源版 Qwen3.8-2.4T-A95B 目前只有文本输入，且思考模式默认开启、无法关闭——模型在给出最终回答前会先生成推理过程，并通过 preserve_thinking 标记在多次对话间保留推理上下文，适合需要跨步骤保持「草稿」的智能体循环。

在官方公布的基准中，同架构的云端版本 Qwen3.8-Max 在论文复现基准 PaperBench 取得 93.0 分、在计算机操作基准 OSWorld-Verified 取得 86.1 分、在参数化 CAD 基准取得 91.5 分，均居参评模型前列；不过在 TerminalBench 2.1（86.6）与 SWE-bench Pro（67.7）上仍略低于部分对手。整体定位被千问团队形容为「除 Fable 5 外最强的模型之一」。

自己跑起来要多少硬件

开源权重意味着可以本地部署。官方支持通过 Hugging Face Transformers、SGLang、vLLM、TokenSpeed 等推理框架加载，正式部署时需使用各框架针对 Qwen3.8 的最新配方，并按权重精度与 GPU 数量选择并行策略。

全精度权重体积可观，但开源社区已经给出了瘦身方案。Unsloth 团队用动态 1-bit 分层选择性量化技术，把原始约 4.9TB 的模型压到 397GB，存储空间缩减约 91%；借助其 Unsloth-Desktop 工具，只要设备的内存与显存合计达到 410GB 以上，就能在本地把模型跑起来。对没有数据中心的中小团队而言，这意味着前沿级能力第一次能以自托管的形式落在自己手里。

许可证与价格

开放不等于完全自由。Qwen3.8-2.4T-A95B 采用千问自定义许可证，而非早先常见的 Apache 2.0：个人下载、修改、部署不受限，但大规模商业使用需要另行取得授权。配套发布的还有一颗约 270 亿参数的稠密伴随模型 Qwen3.8-27B，面向算力有限的场景，不过在开源权重放出时尚未同步上线。

云端 Qwen3.8-Max 的国内 API 定价为每百万词元输入 12 元、输出 36 元，海外为每百万词元输入 2 美元、输出 6 美元。

为什么这件事值得关注

把旗舰级权重交到社区手中，意义不只在「又大了一点」。过去一年，西方实验室谈开源时往往只放出 200 亿到 300 亿参数量级的中等模型，而阿里这次直接把自家最强旗舰摆上了桌面。无论动机如何，实际效果是：当前能完全自托管、可离线运行的最强模型之一，来自于中国的开源阵营，且差距明显。

对开发者与研究者来说，这意味着不必再为前沿能力向专有 API 持续付费，也能在本地做微调、评测与私有化部署；对下游应用，则把竞争拉回了「在模型之上能做出什么」这一层。

来源：Hugging Face 模型页 / 千问团队（经 Hacker News 收录）

该项目由 Antigma Labs 开发，以 Apache 2.0 协议开源，近日出现在 Hacker News 首页并获得 90 分推荐。开发方给它的定位相当直白：功能对标 Claude Code 与 Codex，但不带这两者的依赖负担和模型限制。

跑分公开可查，资源占用只有零头

多数智能体项目都会自称性能优秀，Ante 的做法是把评测过程直接摊开。项目在官方排行榜约束条件下持续运行 Terminal-Bench 2.1 基准测试——89 项任务，每项跑 5 次。最新一轮完整测试的成绩为 82.7%，共 368 次通过、总计 445 次试验，使用的模型是开源权重的 DeepSeek V4 Flash 0731，对应版本为 Ante 0.preview.71，整轮推理开销约 68 美元。作为交叉印证，DeepSeek 官方用其尚未公开的 Harness 在最简模式下测试同一模型，给出的分数同样是 82.7。

每条评测结果都会锁定可下载的具体构建版本，并附上原始运行记录的链接，供外部独立复核，而不是只丢出一个数字。

资源开销的差距更为直观。在 Docker 环境中执行同样的 20 项并行任务，Ante 的峰值内存占用约为 Claude Code 的七分之一，平均 CPU 占用约为九分之一，磁盘读写量约为五分之一。

这套数字背后是一个具体的工程取舍：整个程序用 Rust 手写，把 Grep（经过完全重写和定制）与 git 这类高频组件直接嵌进同一个二进制、同一个进程内运行，不再向外调起子进程，也就不存在资源泄漏的问题。本地推理则交给一个版本固定、由项目自行管理的 llama.cpp。

断网跑完整流程，不需要 API 密钥

原生离线是 Ante 最有辨识度的一点。内置推理引擎让整个工作循环可以完全留在本地：指向一个 GGUF 格式的模型文件，不需要 API 密钥，不需要注册账号，也不需要网络连接。

ante --offline-model ~/.ante/models/Qwen3.5-9B-Q4_K_M.gguf \
  -p "add error handling to src/main.rs"

联网使用时，Ante 开箱支持 12 家以上的模型供应商，包括 Anthropic 的 Claude Sonnet 4.5 与 Opus 4.6、OpenAI 的 GPT-5 系列、谷歌 Gemini 3 系列、xAI 的 Grok 4、OpenRouter，以及 Vertex AI 等兼容 OpenAI 接口的服务。切换供应商没有绑定成本，自带密钥、订阅账号或本地模型均可，官方明确表示不要求注册任何账号。

运行方式分为四种：ante 进入交互式终端界面处理日常工作；ante -p 以无头模式执行一次性任务，适合脚本与持续集成流程；ante serve 通过 JSONL 协议对外提供服务，供编辑器插件调用；ante gateway 则可以把它挂成 Slack 或 Discord 机器人。多智能体编排、自定义技能、MCP 支持与跨会话记忆也都在功能清单内。

开源了哪些部分，又有哪些没开

需要说清楚的是，Ante 目前处于 Alpha 预览阶段，官方提示会有破坏性变更和功能缺失，且仅支持 macOS 与 Linux，Windows 用户建议通过 WSL 使用。

仓库开源的内容包括：完整文档站、ante serve 使用的协议定义与 Rust SDK、支撑 Terminal-Bench 成绩的评测适配器（任何一轮结果都可据此复现），以及已经稳定的核心库如独立进程执行模块。核心的 harness 本身在 Alpha 期间仍在私有仓库开发，以预编译二进制形式随版本发布，稳定一块开放一块。

项目名字本身是个双关：既是「Another Terminal agent」的缩写，也指牌桌上入局要先押的底注。开发方给出的长期设想是所谓「细胞原生」智能体——像生物体内的细胞那样微小、可随时丢弃、能大规模复制。按这个思路，可验证、够便宜、随处能跑三件事其实是同一个设计决策：只有轻到能成千上万地铺开，智能体才谈得上自组织。

对于关注本地化部署、注重数据不出机器，或者单纯受够了动辄数百 MB 客户端的开发者，这个只有 15MB 的选项值得关注一下。

来源：Hacker News / GitHub（AntigmaLabs/ante）

开放权重模型一多，围观者就习惯把它们摆成一场赛马：谁排名靠前谁就该用，落后的那个自动被归为“慢”或者“不能用”。How-To Geek 编辑 Jorge A. Aguilar 在 8 月 9 日发表的一篇文章里指出，这套逻辑一旦落到真实使用场景中就会立刻散架——因为有些模型压根不是为同一份工作而生的。

谷歌 DeepMind 的 Gemma 4 和阿里巴巴的通义千问 3.6，恰好是最典型的一对例子。

一个装进设备，一个住在云上

Gemma 4 的设计目标是在尽可能多的终端上高效运行：手机、笔记本、台式机。它的 12B 变体可以直接吃进原始音频和图像数据，不需要额外挂载独立的编码器模型。

千问 3.6 则是奔着云端基础设施和长链条分析任务去的。它采用混合注意力结构，能在不撑爆内存的前提下吞下巨量文本。用一句话概括这组差异：前者想当一个快速、私密、跑在本机上的助手；后者想当一个坐在云端、有耐心跟难题死磕的工程师。

两个模型的档位划分也印证了各自的取向。Gemma 4 于 4 月 2 日发布，提供从端侧优化的 E2B、E4B，到 12B、26B 混合专家、31B 稠密模型在内的多个尺寸。千问 3.6 的开放权重版本走的是另一条路线：35B-A3B 混合专家模型每个词元只激活约 30 亿参数，另有一款 27B 稠密模型，原生上下文达到 262144 个词元。两个家族目前都采用 Apache 2.0 许可，这一项上并不构成差异。

上下文窗口决定了能干什么活

真正把两者拉开距离的，是上下文容量和推理方式。

云端的千问 3.6 Plus 拥有 100 万词元的上下文窗口，并且搭配一个常驻运行的推理模式——模型会先把问题想一遍再作答。在部分会话中它还会启用思考保留模式，记住此前几轮的推演过程，从上一次的结论继续往下走，而不是每次都从零开始、重复踩同一个坑。

这个能力在特定场景里价值极高。调试一个庞大的代码库时，100 万词元的窗口可以一次性装下整个仓库、接口文档和错误日志，让模型在几百个文件之间追踪同一个缺陷而不丢线索。

Gemma 4 的上下文上限则视变体而定，落在 128K 到 256K 之间，装不下那么多东西。在较长的会话里，它还容易丢失被指定的角色设定，陷入需要整段重启才能跳出的重复循环。

成本与隐私的账要分开算

许可与账单的差异同样值得留意。千问 3.6 的部分本地变体以免费开放许可发布，企业可以自行部署而无需申请授权；但更高端的云端版本跑在付费租用的算力上，用得越狠账单越长。

Gemma 4 走的是相反的路径：拿到一份副本部署在自己的硬件上，一次配置完成后没有持续开销，输入的任何内容都不必离开本机——对隐私敏感的场景，这一点的分量远大于跑分。想先试一试的用户可以在 AI Studio 上体验 Gemma 4，本地部署则通常经由 Ollama 完成。Gemma 早期版本曾附带较多使用限制，如今这一层顾虑已经解除，小团队和独立开发者不必再为许可条款专门请教律师。

别再评“史上最强”了

Aguilar 在文章结尾给出了一个明确判断：把 Gemma 4 和千问 3.6 当成争夺同一顶王冠的对手，本身就理解错了题目。依据排行榜名次或品牌认知度二选一，大概率会选错——因为它们要解决的根本是两类问题。同样的道理也适用于 ChatGPT、DeepSeek 背后的模型。

会不会有一天出现一个足够大的模型，把端侧任务和深度仓库分析统统吃下？他认为这个设想并不离谱，但短期内看不到。一个能在 100 万词元的代码里做推理的模型，放到本地跑必然带来明显延迟；能撑起这种上下文窗口的云端模型，背后需要真金白银的服务器集群，还要面对网络延迟、隐私顾虑和运维成本——对普通用户来说很难承受。

所以结论不是“哪个更好”，而是“哪个不适合当前这项任务”。把它们当成两把用途不同的工具对待，两者都会变得更好用。

来源：How-To Geek

一、下载安装并选择模型

1. 到 GitHub 的 eigent-ai/eigent 仓库下载安装包，按提示完成安装。它采用 Electron 前端加 Python 后端的架构，开箱即用，无需自己搭环境。
2. 打开设置页选模型：本地方案可选 Ollama、LM Studio、vLLM、SGLang、LLaMA.cpp；云端则填入自备密钥，支持 Gemini、Anthropic、OpenAI、Grok、Qwen、DeepSeek、Moonshot 等。切换只是下拉框里选一下，小显卡跑本地模型卡顿时也能随时退回云端。

二、用内置智能体与技能干活

1. 开箱自带五类专用智能体：Developer（拥有终端、代码执行、文件操作）、Search、Document、Multi-Modal、Social Media，各自带着工具箱，不必从零搭工作流。
2. 系统内置 200 多个 MCP 工具（Notion、Google Calendar、Slack、GitHub 等），也能自行接入更多。
3. 用 Skills 沉淀个人流程：新建一个文件夹，写入 SKILL.md 描述触发条件与行为（结构与 Claude Skills 一致），之后一条命令就能触发。例如写一个读取心愿单、比价本地零售商并生成带日期报告的任务。

三、隔离浏览器与访问本机文件

1. 浏览器工具会在应用内通过 Playwright 拉起独立的 Chromium 实例，每次任务都从全新无痕会话开始，不携带本机浏览器的 Cookie、登录态和历史，避免身份泄露。
2. 默认每个任务被沙箱到自己工作目录；若要操作目录外的文件夹，在应用里新建一个指向该文件夹的 Space（下拉一次即可），否则会拒绝访问。

注意事项：Eigent 基于 CAMEL-AI 多代理框架，适合做知识管理、调研和自动化，并非只给开发者用。首次访问沙箱外目录记得先建 Space，否则任务会被拒。

来源：XDA Developers

它叫 Soup，最近登上 Hacker News 首页，标题很直白：在 4GB 笔记本显卡上微调 80 亿参数模型。项目采用 Apache-2.0 开源协议，目前在 GitHub 上有 147 颗星、23 个分支，累计 605 次提交。

一个配置文件，一条命令

Soup 想解决的是老问题。项目自述里写道，即便是有经验的团队，也要把 30% 到 50% 的时间花在跟基础设施较劲上，而不是改进模型。它的做法是把整套流程压成一个配置文件加一条命令：安装 `pip install “soup-cli[train]”`，然后 `soup init –template chat` 生成配置、`soup train` 开跑。批大小、显卡识别、量化全部自动处理，不需要远程登录服务器，也不需要云端资源。

真正让它能在 4GB 显卡上跑起来的是「层流式加载」：冻结的基座模型不常驻显存，而是按解码层逐层喂给显卡，配合 4bit NF4 量化把模型体积压到约四分之一，80 亿参数模型就能塞进 4GB 显卡。

新版本把偏好训练也拉了进来

最新的 v0.72.4 版本把这套机制扩展到了偏好对齐训练——也就是让模型学会「这个回答比那个好」的调优阶段。以往层流式加载只支持监督微调，现在直接偏好优化（DPO）以及 ORPO、SimPO、KTO 三种方法也能跑。

其中 DPO 需要一个参考模型做对照，常规做法要再加载一份权重、内存直接翻倍，那样省显存的意义就没了。Soup 的处理是复用同一份流式基座、把适配器关掉，等于一份权重、一条数据流。在 RTX 3050 4GB 显卡上实测，流式 DPO 的显存峰值是监督微调峰值的 0.914 倍；而强行加载真正的第二份模型，同样测试下多吃 730MB，正好是一份权重的大小。

难得的是把代价也写清楚了

这个项目最值得留意的地方，不是省显存，而是它把账算给你看。文档明确写出：参考模型省的是内存不是时间，DPO 每步读取层栈的次数是监督微调的 1.52 倍；GRPO 和 PPO 两种强化学习方法被有意排除在外，因为生成阶段每输出一个词都要重读所有层，流式加载省不出来。作者还标注训练结果与非流式版本逐位一致（差异为 0），并说明整个项目是在一台 4GB 笔记本上开发维护的，因此多显卡、更大模型和苹果芯片的支持都还没验证，相关功能都挂着明确的前置条件说明。该特性目前仍标注为测试版。

官方给出的显存对照是：8GB 约能带 70 亿参数、16GB 约 140 亿、24GB 约 340 亿、48GB 约 700 亿。项目内置 100 多个现成配方，覆盖通义千问、Llama 3、Gemma 3、Mistral、DeepSeek R1/V3、Phi-4 等模型，模板涵盖对话、代码、工具调用、推理、视觉、长上下文等场景。

我的判断是，这类工具的价值在于把「能不能跑」变成「值不值得跑」。手上这块小显卡，你打算拿它微调点什么？

来源：GitHub / Soup 项目页，Hacker News

一台笔记本，跑万亿级模型

WASTE 全称 Weight-Aware Streaming Tensor Engine（权重感知流式张量引擎），用 C 语言编写，运行时不依赖任何第三方库，没有 BLAS，没有 ONNX，推理路径里也没有 Python。

它给出的成绩单是：Kimi K3 转换后形成一个 982 GiB 的容器文件，引擎启动的内存下限为 29.05 GB，在 64GB 内存的机器上实测速度为每秒 0.45 到 0.62 个词元。项目文档里贴出的一次实际运行记录显示，回答”意大利的首都是哪里”这个问题，输出 16 个词元耗时 25.78 秒。

这个速度确实慢。但开发者认为，慢不是重点：目前没有找到另一份公开的、在消费级机器上通过磁盘流式运行万亿级模型的演示，而业内记录最完整的 6710 亿参数方案，前提是一台配备 1TB 内存的服务器。

原理：把闲置的权重放回硬盘

这套方案能成立，靠的是混合专家架构的稀疏特性。Kimi K3 每处理一个词元，只会从 896 个路由专家中激活 16 个，实际参与运算的权重约占总量的 4%。绝大部分权重在任一时刻都处于闲置状态，而闲置的权重不需要待在内存里，只需要”能及时取到”。

WASTE 的做法是把模型主干常驻内存，专家权重留在硬盘上，并按特定布局排列——每条专家记录按 4KiB 对齐，门控、上投影、下投影三个矩阵相邻存放，因此路由到一个专家只需要一次读取操作，而不是三次。剩余内存全部用作有界的专家缓存。

真正拉开差距的优化有两项。一是把专家读取与算术运算重叠执行，收益约 1.6 倍。二是”抢跑”：下一层的专家编号本来要等隐藏状态算出来才知道，但路由器本身是常驻内存的，于是引擎在每层结束时，直接用当前层的隐藏状态去跑下一层的路由器，提前把它点名的专家取回来。这个提前一个残差块的猜测，排名第一的命中率为 92%，前六名合计 81%，把缓存命中率从 14% 拉到 38%，而总读取字节数完全不变。

专家权重采用残差矢量量化存储，三级 256 条目码本作用于 8 维向量，平均每个权重 3.00 比特；模型主干则保持 4 比特和 8 比特精度。开发者试过把主干也压到 3 比特，结果输出直接崩溃。

硬盘速度决定一切

文档反复强调，存储速度不是细节问题。处理一个词元需要读取 17GB 的专家数据，走内部固态硬盘的实测带宽是每秒 12.78GB，模型能流畅串起来；换成 USB 外置硬盘只有每秒 0.94GB，同一个词元要等 13 秒。结论很直接：外置硬盘只用来下载，转换后的容器必须放在机器内置的 NVMe 上。

内存预算也存在反直觉的现象。在 64GB 的机器上，46GB 预算跑出 0.53 到 0.55 词元每秒，是曲线最高点；而预算调到 52GB 时结果在 0.04 到 0.46 之间剧烈跳动，完全不可复现；调到 58GB 更是稳定跌到 0.02 至 0.03。原因不是缓存失效，而是引擎虽然守住了自己的预算，机器整体却已经放不下，操作系统开始换页。

对于不想拿出一整块 TB 级硬盘的人，同一套引擎和格式可以运行 Kimi-Linear-48B，容器只有 19GB，内存门槛 1.87GB，速度能到每秒 10.7 个词元。

意义在哪

开发者对项目名字的解释是：每一个由云端服务生成的词元都被付费了两次，一次是账单，一次是数据中心的电费——而那个模型本可以（勉强、别扭但确实可以）跑在已经摆在桌上的硬件里。

这套方案指向的场景很明确：一个前沿规模的模型，回答问题时不需要联网，没有按词元计费的账单，也没有任何数据离开本机。对于”这些数据不能发给外部接口”的场合，差别就是能做和不能做。

作为验证对象的 Kimi K3 于 7 月 27 日由月之暗面公开权重，总参数量 2.8 万亿，支持 100 万词元上下文与原生视觉理解，是目前参数规模最大的开放权重模型。WASTE 项目方称，引擎和格式本身并不特别针对 K3，选它只是因为它是当下最难啃的一块骨头——能流式跑通 2.78 万亿参数，跑 480 亿参数自然轻松。

来源：GitHub 开源项目 sqliteai/waste 项目文档、Hacker News；Kimi K3 参数信息来自月之暗面官方发布

核心是阿里开源的千问语音模型

Qwen Scribe 的底层是阿里巴巴开源的 Qwen3-ASR 语音识别模型，通过 mlx-qwen3-asr 项目跑在 Mac 的 Metal GPU 上。Qwen3-ASR 是目前最强的开源语音识别模型之一，有第三方移植测试显示，它在多语言和嘈杂环境下的识别表现优于 OpenAI 的 Whisper-large-v3。

工具提供两档模型可选：追求准确率可以用 17 亿参数版本，占用约 3.4GB 统一内存；追求速度可以用 6 亿参数版本，只占约 1.2GB 内存。模型权重在首次使用时自动下载，之后即使断网也能正常转写。

两种用法：拖文件转写，或全局听写

Qwen Scribe 的功能分两块。第一块是文件转写：在本地网页界面里把音频或视频文件拖进去，工具会自动识别语言，支持强制指定语言、专有词汇提示、逐词时间戳，还能直接导出 SRT 字幕文件。所有转写记录自动保存在本地，可以随时重新打开或删除。

第二块是系统级听写，这也是最实用的部分：在任意应用的文本输入框里，按住右侧 Command 键说话，松开后文字就会在光标处自动粘贴出来——全程在本地完成识别。屏幕上会显示一个不抢焦点的悬浮提示，标明「聆听中」「转写中」以及成功或失败状态。

隐私设计上，这款工具做得相当细致：本地服务只监听 127.0.0.1，并做了 Host 和浏览器来源校验；听写助手只响应右 Command 键，粘贴文字前会在内存里暂存剪贴板内容，粘贴后如果剪贴板没被改动就自动恢复原状。

上手门槛：目前需要自己动手编译

想尝鲜的用户需要注意几个条件：必须是搭载 Apple Silicon 芯片的 Mac，系统要求 macOS 14 或更新版本，还需要安装 Python 3.12 以上版本和 ffmpeg。

目前的测试版只提供源码，没有现成的安装包——因为应用还没有经过苹果的开发者签名和公证，开发者不希望用户绕过系统安全警告安装未签名程序。用户需要克隆代码仓库后用 make app 命令自行编译。按照路线图，签名和公证过的正式安装包计划在 v0.2 版本推出。

另外要说明的是，Qwen Scribe 是独立的社区项目，与阿里云、千问团队以及苹果公司均无官方关联。

对于经常需要整理录音、写字幕，又不放心把敏感内容传到云端的用户来说，这类「模型在本地、数据不出门」的工具正在变成一个值得关注的方向——大厂的开源模型加上社区开发者的打磨，免费方案的体验已经越来越接近付费云服务。

来源：GitHub – VladUZH/qwen-scribe（via Hacker News）