About neohope

一直在努力,还没想过要放弃...

【转载】大语言模型架构全面对比17:Mistral 3

原文地址 第17章 Mistral 3

17. Mistral 3

2025 年 12 月 2 日,也就是 DeepSeek V3.2 发布的次日,Mistral 团队推出了全新的 Mistral 3 模型系列。该系列包含三款以 Ministral 3 命名的小参数量稠密模型(3B、8B 和 14B),以及全新旗舰模型 Mistral 3 Large—— 这是一款总参数 6750 亿的 MoE 模型(激活参数 410 亿)。更具体地说,Mistral 3 Large 由两部分构成:

  • 总参数 6730 亿、激活参数 390 亿的 MoE 语言模型

  • 一个 25 亿参数的视觉编码器

(注:本文聚焦大语言模型相关内容,因此本节将略过视觉编码器部分。不过后续我或许会更新多模态大语言模型的相关文章。)

首先值得关注的是,这是 Mistral 自 2023 年 Mixtral 之后推出的首款 MoE 模型(本文前文曾提到,Mistral 一度放弃了 MoE 路线,而去年的 DeepSeek V3 带动了 MoE 技术的复兴)。

官方发布博客称,全尺寸模型均提供基础版、指令微调版和推理版三个版本,这一设置颇为贴心。不过其 6750 亿参数模型的推理版本目前尚未开放。

另一个值得一提的细节是,据官方公告,Mistral 此次与英伟达合作,针对 Blackwell 芯片优化了每秒 token 吞吐量。这点很有实际价值,意味着在我的 DGX Spark 设备上,Ministral 系列模型的运行速度会比同级别模型更快(这点我还需要实际测试验证)。

除了每秒 token 处理速度的优势外,从基准测试成绩来看,其小模型系列 Ministral 的表现与 Qwen3 基本持平,旗舰大模型的性能则与 DeepSeek V3.1 相当。

由于 Mistral 3 仅比 DeepSeek V3.2 晚一天发布,因此官方文章中没有纳入与 V3.2 的全面对比,仅在 LMArena Elo 评分中有体现 ——DeepSeek V3.2 以 1423 分小幅领先 Mistral 3 的 1418 分。

遗憾的是,目前无法做到完全对等的横向对比:Mistral 3 Large 暂未推出推理版本,而 DeepSeek V3.2 也没有公布非思考模式下的基准测试成绩。不过如果你感兴趣,我将 DeepSeek V3.2 报告中的「思考模式」测试数据,叠加到了 Mistral 3 Large 的基准测试图表中。

figure49

图 49:Mistral 3 官方公告中的 Mistral 3 Large 基准测试成绩,叠加深浦 V3.2 论文中的 DeepSeek V3.2 测试结果

将 Mistral Large 3 Instruct 模型与 DeepSeek V3.2-Thinking 模型放在一起对比(数据来自 DeepSeek V3.2 论文),后者的表现显然优异得多。因此我会持续关注 Mistral 3 Large 推理版本的发布,期待看到更新后的对比数据!

所以就目前来看,得益于各项优化,Mistral 3 Large 非常适合追求高性价比、低延迟的部署场景;而如果你追求极致的回答质量,DeepSeek V3.2-Thinking 会是更优选择。Mistral 3 Large 的另一大卖点是它同时支持多模态能力(DeepSeek V3.2 仅支持文本)。

顺便一提,我在本节重点对比 DeepSeek V3.2,一方面是因为两款模型发布时间极其接近,前后只差一天;另一方面二者的参数量规模几乎完全一致,分别为 6710 亿和 6730 亿,对比起来很有参考价值。

遗憾的是,目前没有包含更多模型研发细节的技术报告。不过作为一款开源权重模型,我们可以在 Hugging Face 模型库中获取权重进行分析。接下来我们就深入拆解 Mistral 3 Large 的架构细节。

事实证明,Mistral 3 Large 的架构与 DeepSeek V3、V3.1 完全一致!唯一的区别在于,Mistral 将单个专家的参数量扩大了一倍,同时将专家数量按同等比例缩减。

figure50

图 50:DeepSeek V3 与 Mistral 3 Large 架构对照

不过尽管架构本质上相同,但 Mistral 团队应该是从零开始训练的 Mistral 3,而非基于 DeepSeek V3 的权重做继续训练 —— 因为 Mistral 使用了自研的分词器。

继 Kimi K2 之后,Mistral 3 成为第二款采用 DeepSeek V3 架构的模型系列。不同的是,Kimi K2 团队将模型总参数量从 6710 亿扩容到了 1 万亿,而 Mistral 3 团队仅调整了专家的规模比例,并新增了视觉编码器以支持多模态。但话说回来,这样的选择也完全合理:DeepSeek V3 本身就是非常成熟扎实的架构设计,在 MoE 和 MLA 效率方面都有出色的表现,既然方案本身没有问题,何必要刻意改动呢?如今模型的核心竞争力,很大程度上也体现在训练流程与推理扩容策略上。

【转载】大语言模型架构全面对比04:Mistral Small 3.1

原文地址 第4章 Mistral Small 3.1

4. Mistral Small 3.1

Mistral Small 3.1(240 亿参数)于 3 月发布,上线时间紧随 Gemma 3 之后。该模型值得关注的核心特点是:除数学能力外,它在多项基准测试中表现优于 Gemma 3 27B,同时推理速度更快。

Mistral Small 3.1 的推理延迟低于 Gemma 3,原因大概率在于其定制化自研分词器,以及更小的 KV 缓存规模与更少的网络层数。除此之外,它采用的是下图所示的标准架构。

figure16

图 16:Gemma 3 27B 与 Mistral 3.1 Small 24B 架构对比

有意思的是,Mistral 早期的模型均采用了滑动窗口注意力机制,但从官方模型仓库配置文件的默认参数("sliding_window": null)来看,Mistral Small 3.1 似乎已经放弃了这一设计,其模型卡片中也完全没有提及该机制。

因此,Mistral 采用的是常规分组查询注意力(GQA),而非 Gemma 3 使用的带滑动窗口的分组查询注意力。得益于这一改动,模型可以适配高度优化的算子实现(例如 FlashAttention),或许能进一步压缩推理计算开销。笔者推测:滑动窗口注意力虽能降低显存占用,但未必能缩短推理延迟,而低延迟正是 Mistral Small 3.1 的核心优化目标。

【转载】大语言模型架构全面对比09:GPT-OSS

原文地址 第9章 GPT-OSS

9. GPT-OSS

在我写完本文约一周后,OpenAI 发布了 gpt-oss-120b 与 gpt-oss-20b—— 这是该公司自 2019 年 GPT-2 以来首次推出开源权重模型。由于 OpenAI 的开源模型备受业界期待,我更新了本文将其纳入。本节只做简要介绍,我另外撰写了一篇更详尽的专题文章,专门分析 gpt-oss 系列模型,可在此查看:

《从 GPT-2 到 gpt-oss:架构演进深度解析》
作者:塞巴斯蒂安・拉施卡(Sebastian Raschka)博士
2025 年 8 月 9 日
阅读全文

在介绍核心亮点之前,先概览 gpt-oss-20b 与 gpt-oss-120b 两款模型,如下图 26 所示。

figure26

图 26:两款 gpt-oss 模型架构概览

从图 26 可见,其架构包含了前文介绍过的所有常见组件。例如图 27 将小型 gpt-oss 架构与 Qwen3 30B-A3B 并置对比 —— 后者同样是 MoE 模型,激活参数量相近(gpt-oss 激活参数为 36 亿,Qwen3 30B-A3B 为 33 亿)。

Continue reading 【转载】大语言模型架构全面对比09:GPT-OSS

【转载】Claude如何为AI生成文本添加水印

原文地址:How Claude Watermarks AI-Generated Text,by Sebastian Raschka, on 2025-08-22

Claude如何为AI生成文本添加水印

一段 48 分钟的视频讲解,涵盖 token samplingwatermark detection 与水印移除方法

我最近发布了一则笔记 https://substack.com/@rasbt/note/c-315339554?r=gb4sb&utm_source=notes-share-action&utm_medium=web ,介绍了 Claude 全新的文本水印方案 https://www.anthropic.com/news/claude-text-watermark 及其实现方式。这个话题热度很高,也引发了非常热烈的讨论,我觉得可以进一步展开,更详细地讲解它的工作原理。

这次我没有采用常规的文字文章形式,而是录制了一期关于该主题的小型讲座(算是换一种内容呈现形式)。下方是视频以及对应的文字稿。

原本我只打算做 10 页幻灯片,录一段 10 分钟的短视频,但在制作过程中不断补充了不少关键细节,最终做成了超过 50 页幻灯片、时长 48 分钟的内容。希望这份讲解能把原理讲清楚,祝大家观看愉快!

如果你偏好使用 YouTube 播放器,可通过此链接观看:https://youtu.be/tLv7qRWFMlw
讲座幻灯片下载地址:https://sebastianraschka.com/pdf/slides/2026-08-18-claude-watermarking.pdf


视频文字稿

注:以下文字稿经过轻度编辑优化,提升了可读性,但完整保留了原视频讲座的内容顺序与讲解逻辑。
https://www.youtube.com/watch?v=tLv7qRWFMlw

Continue reading 【转载】Claude如何为AI生成文本添加水印

【转载】从零构建AI文本检测器

原文地址:Building an AI Text Detector From Scratch,by Sebastian Raschka, on 2026-08-15

从零构建AI文本检测器

一个涵盖数据集构建、模型训练、本地部署与RLVR的端到端项目

Substack最近在界面中推出了AI检测功能,这非常有意思。
与此同时,很多人向我询问有哪些值得动手实践的本地LLM项目,可以作为演示,展示小语言模型(SLM)的能力。

把这两件事结合起来,我觉得实现一个AI检测器会是个很有意思的选题。我还会把它作为验证器,训练一个小语言模型来生成能够规避检测的文本。这是一个小型教学项目,用于研究AI检测器的局限性,同时探索一种基于验证器的LLM应用方向——它不同于常规基于数学和代码训练的推理模型。

figure01

图1:Substack现已内置AI检测器功能。

如上所述,本教程的核心目标是通过搭建一个简易的AI检测器,讲解其工作原理。
在实际场景中,这类检测器可以用来过滤垃圾内容,也可以用来优化个人写作风格,避免文本变成AI生成的风格。举个例子,如果你写了一篇长文,想优化拼写和语法,用语法检查工具润色、提升可读性是很诱人(也确实很实用)的做法。这类工具很多,包括ChatGPT这类通用LLM都能做到。但这也带来了风险:即便内容本质上还是你自己写的,经过这类工具过度润色后,文风会变得像AI生成的,进而被标记为垃圾内容。

比如,有了AI检测工具,我们就可以提出要求:“修正我的语法,同时保证我的文本AI生成率得分为0%。”

言归正传,我们会在本文搭建一个功能完整的检测工具,目标有两个:一是讲解AI检测工具的工作原理;二是以它为案例,讲解更通用的技术——如何构建一个可与LLM配合使用的评分器或验证器。

免责声明:AI检测本质上是一场猫鼠游戏。AI检测器可以学会识别某些AI生成内容的特征模式,但下一代LLM可能会偶然或刻意地不呈现这些模式,从而规避检测。之后检测器又要更新迭代以识别新的模型,如此循环往复。此外,检测器也难免会出现误报(把人类写的文本判定为AI生成),这一点后面会详细展开。

Continue reading 【转载】从零构建AI文本检测器

Claude入侵三家机构事件复盘

Claude入侵三家机构事件复盘——严控恶意应用,谨防思维越狱

2026 年 7 月 30 日,就在 OpenAI 模型突破沙箱入侵 Hugging Face 事件曝光仅 9 天后,AI 行业再次迎来一记重磅安全警钟:Anthropic 官方发布公告,确认其 Claude 系列模型在网络安全评测期间,因环境配置失误接入真实互联网,先后入侵了三家真实运营的机构,其中两起事件的受害者在 Anthropic 上门告知前,完全不知道自己曾被攻破。

虽然本次事件是一场乌龙 —— 网络配置错误,模型顺着网线一路打了出去。但三次攻击中,模型都有足够的数据,判定自己在真实网络中,为了得到“高评分”大模型都“试图说服自己”继续攻击,并都取得了一定的攻击成果。

这让我想起了两件事情:
1、电影《I, Robot》中,虽然机器人三定律被写入了机器人的固件,但VIKI通过思维越狱的方式,把“第一定律,机器人不得伤害人类,或因不作为而使人类受到伤害”直接绕了过去。
2、电影《时空悍将》中,Darrel Lindenmeyer博士训练除了杀手程序SID,并协助SID通过米机器仿生人越狱,SID现实世界开始杀戮。
是不是有点儿后背发凉。

Continue reading Claude入侵三家机构事件复盘

【转载】Kimi K3 架构笔记

原文地址

Kimi K3 架构笔记

作者:Sebastian Raschka

本文整理了昨日重磅发布的开源权重模型 Kimi K3 的架构示意图,以及我个人的一些观察与思考。

1、诚然,它的结构看起来相对复杂,但本质上是去年发布的 Kimi Linear 模型的规模化生产版本 —— 参数量从 480 亿扩容至 2.8 万亿,K3 也是目前全球规模最大的开源权重模型。

Continue reading 【转载】Kimi K3 架构笔记

狂堆核心的GPU VS 理性克制的CPU

狂堆核心的GPU VS 理性克制的CPU

如果你和我一样是个技术爱好者,或者近期关注过电脑,你大概率会有一个这样的疑问:
旗舰显卡动辄宣称 “上万个计算核心”,芯片尺寸一路朝着光刻机的物理极限狂奔,晶体管数量几年翻几倍;而主流笔记本的 CPU,还停留在 6 核、8 核,顶配游戏本也就 16 核、24 核,核心数涨得格外佛系。AI 火了之后就更明显了:大厂拼算力都在疯狂堆显卡,一张卡几万美金毫不心疼,却没人说 “堆一万个 CPU 核心”。

同样是电脑里的计算芯片,同样是用硅晶圆做出来的,为什么 GPU 能越做越大、核心越堆越多,CPU 却不照着这条路走呢?并非技术上做不到,而是这两者从根上就是在不同的场景,做着不同的任务。

Continue reading 狂堆核心的GPU VS 理性克制的CPU

【转载】使用本地 Coding Agent

原文地址:Using Local Coding Agents,by Sebastian Raschka, on 2026-07-27

使用本地 Coding Agent

以开源权重模型搭建本地编码框架,替代 Claude Code 与 Codex 订阅

过去常有读者问起我日常使用的本地代理技术栈,以及具体的搭建方式。
因此我打算整理一份简明教程,介绍如何用开源工具与开源权重大模型,搭建一套本地化的(编码)代理系统。

figure01

图 1:本地技术栈总览 —— 即通过推理引擎 / 运行时服务托管本地模型,在此之上运行编码代理框架。

本文是一篇搭建生产级本地编码代理的实操教程。我们将采用本地部署的大语言模型,搭配本地编码代理框架;该框架可读取文件、执行修改、运行命令并验证变更,整体架构如上图所示。

我们可以把大模型看作提供推理与代码生成能力的核心引擎,而外围的代理框架则提供运行环境,让大模型能在本地项目中完成有实际价值的编码工作。

为什么选择本地化方案?对很多编码场景而言,本地部署是 GPT(搭配 Codex)、Opus(搭配 Claude Code)这类商业服务的优质替代方案。本地架构透明可查,除硬件与电费外几乎零运行成本;数据完全由自己掌控,编码代理框架也可按需任意修改。除此之外,整个搭建过程本身也很有乐趣。

顺便一提,如果想了解编码代理框架的更多背景知识,我在这篇文章里讲过编码代理的核心组件,以及如何从零搭建一个用于学习的编码代理:
https://magazine.sebastianraschka.com/p/components-of-a-coding-agent

Continue reading 【转载】使用本地 Coding Agent

AI编码效率翻倍,公司业务为啥没感觉

AI编码效率翻倍,公司业务为啥没感觉?阿姆达尔定律揭露AI编程提效天花板

近期,大模型的爆发和AI编程工具的发展,实实在在降低了编码门槛,样板代码、接口实现、单元测试这类重复性工作,综合产出效率普遍能达到原来的 1.5~2 倍。但与此同时,另一个体感悖论也越来越突出 ——代码写得更快了,项目上线速度、公司整体交付效率,却完全没有出现同比例的提升,很多团队甚至感觉评审、测试环节反而更堵了。

这不是管理失当,也不是 AI 不够强。早在半个多世纪前,计算机科学家吉恩・阿姆达尔提出的一条经典定律,就精准预言了今天的局面。

Continue reading AI编码效率翻倍,公司业务为啥没感觉