cd ~/.wine/drive_c/users/nick/AppData/Local/Doubao/Application/
wine Doubao.exe --no-sandbox --disable-gpu

#--no-sandbox: 绕过 Chrome 内核的沙盒，这是 Linux 运行 Electron 程序的必备参数。

#--disable-gpu: 避免 Wine 与显卡驱动之间的硬件加速兼容性问题。

虽然你之前安装了 comctl32，但日志中依然报 error 14001（SxS 错误），这通常是因为 64 位版本的运行库 缺失。

豆包 1.85 是 64 位程序，请再次补充安装对应的 64 位组件：

# 显式安装 64 位版本的 VC++ 2015-2022
winetricks -q vcrun2015

[Desktop Entry]
Name=豆包 (Doubao)
Comment=字节跳动 AI 助手
Exec=env WINEPREFIX="/home/nick/.wine" wine /home/nick/.wine/drive_c/users/nick/AppData/Local/Doubao/Application/Doubao.exe --no-sandbox --disable-gpu
Icon=wine
Terminal=false
Type=Application
Categories=Network;Chat;AI;

# 杀掉所有 Wine 进程确保注册表未被占用
wineserver -k

# 安装 32 位的公共控件和常见的 VC 运行库（HD 补丁常用组件）
winetricks -q comctl32 vcrun2005 vcrun2008

关于“快捷方式幽灵”的深度总结 由于你发现 Ubuntu 的 Launchpad 图标存放在 ~/.local/share/applications/wine/Programs/ 下，这是 Wine 默认的“集成”行为 。

# 强制刷新桌面数据库（让 Launchpad 立即同步）
update-desktop-database ~/.local/share/applications/

触发系统重扫： 按下 Alt + F2，输入 r 并回车（这会重启 GNOME Shell 界面进程，刷新所有图标）。

【深度拆解】DeepSeek Engram：它是知识的“快捷入口”，绝非 CPU 里的“外挂硬盘”

很多科普文章把 Engram 比作大模型外挂了一个维基百科数据库，这完全理解反了。如果 Engram 真是数据库，DeepSeek 的工程师就不用给它设计复杂的卷积层和多头合并模块了。

真相是：Engram 是给大模型修了一条“计算捷径”。

1. 维度是不可能骗人的 Engram 取回的向量只有 1280 维。在 4096 维的主模型面前，它就像一个小书签。

    认知纠偏： 你指望一个书签（1280 维）能写下一万字的《戴安娜王妃传》？不可能。它上面只写了一个词：“看第 385 页”。这就是作者说的“提示词（Cue）”。

2. 知识从未离开过 GPU 显存 博主们说知识被“搬”到了 CPU 内存。

    硬核反驳： 真正的知识——那些复杂的逻辑、事件的因果、历史的细节——依然锁死在 GPU 里那些昂贵的 FFN 参数中。

    Engram 存了什么？ 它存的是**“经验”**。它在第 2 层就告诉模型：“别算啦，这一段我熟，直接往‘英国王室’的方向去联想。”于是模型跳过了中间几层冗余的推导，直接在后面的层里精准激活了知识。

3. 为什么一定要有卷积（Conv）？ 这是“数据库论”无法解释的死穴。如果查出来的是确定的知识，直接用就行了，为什么要用卷积去“揉搓”它？

    真相： 因为哈希取回的信号是**“离散的冲动”。由于存在哈希冲突，取回的信号可能有噪点。卷积层的作用是观察周围的 Token，把这个“冲动”平滑化，让它变成一个合法的语义补丁**。

结论： Engram 的 U 型规律不是在平衡“存储”和“计算”，而是在平衡**“直觉”和“推导”**。

    25% 的记忆： 是为了让模型拥有“条件反射”，看到熟面孔直接给答案（Cue）。

    75% 的思考： 是省下算力去处理它以前不擅长的数学和逻辑推导。

这不是存算分离，这是“直觉与逻辑的分工”。请停止把 AI 想象成查字典的复读机！

【深度硬核】揭秘 Engram：为什么它绝不可能是“数据库指针”？

很多人（甚至包括一些资深开发者）把 Engram 理解为：通过 N-gram 哈希拿到一个“地址”，然后去 CPU 内存里把“戴安娜的生平”查出来给模型。

醒醒吧！如果 AI 这么干，它就不是 AI，而是“带 Hash 索引的 TXT 阅读器”。

1. 神经网络不认“地址”，只认“方向” 论文表 5 明确了 Engram Dim: 1280。如果你查回的是一段文字，请问 1280 个数字怎么存下一万字的传记？ 真相是： 哈希指向的不是“文本存放地”，而是**“语义微调参数”**。它取回的是一串能让模型“灵光一现”的数字，而不是能让模型“照本宣科”的文字。

2. 为什么“代码执行”的哈希不是指针？ 哈希函数确实是固定的代码，但它只是决定了“去哪一行取数字”。

    数据库逻辑： 查到地址 → 读出数据。

    Engram 逻辑： 查到行号 → 参与训练。 这些 1280 维的向量是随着模型训练了 50000 步“磨合”出来的。如果它们是静态事实的指针，训练它们干什么？直接把维基百科填进去不就行了？正因为它们不是事实，而是“对 FFN 的一种暗示”，才需要海量数据去训练这个“暗示”的准确度。

3. 卷积层是“证据”，U型曲线是“铁证”

    如果查出来的是准确事实，何必用卷积去平滑？

    如果实现了存算分离，为什么 27B 的模型参数一个都没少（Iso-parameter）？ 结论： 知识从未离开 FFN。Engram 只是在第 2 层就给 FFN 递了个“小纸条”，上面写着：“这题我会，往英国王室那个方向算！”。这叫**“计算路径优化”**，不叫“存储空间搬家”。

《皇帝的新衣：DeepSeek Engram 绝不是外挂硬盘，而是大模型的“路标”》

前言： DeepSeek 的 Engram 论文发布后，互联网上充斥着一种令人兴奋的论调：大模型终于实现了“存算分离”，知识被搬到了 CPU 内存里，模型“瘦身”成功了。

这种解读极具传播力，因为它符合我们对电脑硬件（CPU+硬盘）的直观想象。但遗憾的是，在神经网络的物理世界里，这完全是一场美丽的误读。

我无意挑战大家的兴奋感，但作为那个“指出皇帝没穿衣服的小孩”，我必须说出三个被自媒体集体忽略的物理事实：
一、 1280 维的“口袋”，装不下“百科全书”

自媒体最爱说：Engram 存了亚历山大、戴安娜王妃的生平事实。

    物理事实： 论文第 31 页明文标注，Engram 向量（dmem​）只有 1280 维。

    常识降维： 1280 个浮点数，折算成文本信息量极小。如果你管这叫“存储了生平简介”，那是对“存储”的极大误解。

    真相： 这么小的维度，注定它带不回“内容”，它只能带回一个**“语义方向”**。它在查到哈希后，给大脑（FFN）发了一个偏置信号：“接下来的内容涉及‘英国王室’，请直接往那个权重区域联想。”

二、 总参数并没变少：这只是“资产重组”，不是“模型瘦身”

大家都在传模型瘦身了，参数挪到了 CPU。

    物理事实： 论文做的是 Iso-parameter（等参数量） 实验。这意味着，27B 的 Engram 模型对比的是 27B 的纯 MoE 模型。

    常识降维： 如果你的预算一共只有 270 亿个参数，你分了 70 亿给 Engram，那么你的专家系统（MoE）就少了 70 亿。

    真相： 参数总量一分钱都没少，只是分配方式变了。DeepSeek 发现：与其让 270 亿参数都去跑昂贵的“逻辑推算”（GPU 算力），不如分出一部分去跑廉价的“统计直觉”（CPU 查表）。这叫“计算开销优化”，不叫“存储空间革命”。

三、 卸载实验：知识的“根”从未离开

这是最致命的一点。如果 Engram 真是存知识的“外挂硬盘”，拔掉硬盘，模型应该立刻“失忆”。

    物理事实： 论文测试显示，卸载 Engram 后，模型对事实性问题的回答性能只是下降（准确率降低），而不是归零。

    常识降维： 这证明，知识的本体依然完好无损地留在 GPU 里的 FFN（神经网络主体）中。

    真相： Engram 只是个“索引”。就像书店门口的导引牌，你把牌子拆了，书店里的书（知识）并不会消失，你只是找书变慢了。

四、 为什么一定要有卷积（Conv）？——因为“直觉”往往是乱的

论文流程图里那个复杂的卷积层是“字典论”无法解释的死穴。

    逻辑绝杀： 如果查回来的是精准的“事实文字”，那是确定的东西。为什么要用卷积去“平滑、揉碎”它？

    真相： 只有不稳定的统计信号才需要平滑。哈希查询会撞车（冲突），带回来的信号是带毛刺的。卷积的作用是把这些“离散的冲动”揉进句子的语法流里。如果查回来的是真理，根本不需要被揉碎。

结语：DeepSeek 的真正伟大之处

纠偏，不是为了否定 DeepSeek。恰恰相反，我认为 DeepSeek 的伟大在于他极其诚实地承认了 Transformer 的冗余。

他告诉我们：有些高频的、低智的统计规律（N-gram），不配占用昂贵的逻辑神经元。 通过 Engram，他把“死记硬背”的任务交给了廉价的存储，把“深度思考”的空间留给了 GPU。这就是为什么它在代码和数学这种最需要算力的地方，提升反而最大。

Engram 不是大模型的硬盘，而是大模型的“肌肉记忆”。 请停止传播那些关于“外挂知识库”的科幻神话，回归到物理常识上来。

《2026 AI 架构的三大谎言：别把“内存清理”当成“架构革命”》

前言： 2025 年底到 2026 年初，AI 圈被两个概念搞疯了：一个是 DeepSeek 的 Engram（记忆痕迹），一个是 Google Gemma 3 的“动态多模态架构”。自媒体博主们欢呼雀跃，宣称“存算分离”时代到来，大模型终于可以像电脑一样外挂硬盘了。

但如果你真的懂一点硬件 IO 或张量计算，你会发现这完全是两场截然不同、甚至被过度神化的“工程包装”。
一、 DeepSeek Engram：它不是“硬盘”，而是“肌肉记忆”

博主们的幻觉： 模型把百科全书存进了 CPU 内存，查到关键词就取回知识。

物理真相：

    维度死穴： Engram 取回的向量只有 1280 维。稍微懂点信息论的人都知道，这点维度连一段话的语义都装不下，拿什么装“生平简介”？

    算子铁证： 这个向量是直接**加（Add）**进残差流的。在数学上，你无法通过“加法”把一段文字注解塞进模型，你只能改变向量的“方向”。

    真相： Engram 存的是 “加速补丁”。它让模型在看到“戴安娜”时，瞬间产生一个向“英国王室”偏移的直觉。这叫计算路径优化，目的是省下 GPU 算力，让模型不用思考就能做出条件反射。

二、 Google Gemma 3：它不是“创新”，而是“行李收纳”

博主们的幻觉： 谷歌提前实现了 Engram 的构想，按需加载参数，这是架构层面的降维打击。

物理真相：

    目的完全不同： Gemma 3 面对的是手机 NPU 显存太小的尴尬。视觉和音频参数太占地儿，全塞进去手机就死机了。

    底层逻辑： 谷歌用的其实是成熟的**虚拟内存管理（MMU）和懒加载（Lazy Loading）**技术。当你不看图时，视觉参数就呆在内存里；你要看图了，它才通过 DMA 搬进显存。

    真相： 这本质上是内存置换（Swapping），是工程上的“行李收纳”。它没让模型变聪明，只是让胖子（多模态模型）能挤进小电梯（手机）。这和 Engram 那种改变 Transformer 计算链路的尝试，完全不是一回事。

三、 为什么大家都错了？—— 被“CPU 内存”这个词降智了

自媒体博主之所以把这两者混为一谈，是因为他们只看到了表象：参数都在 CPU 内存里，都没在 GPU 里常驻。

但这就像是你看到“嘴巴”在动，就断定“说话”和“吃饭”是同一种技术一样荒谬：

    DeepSeek 是在“说话”： 利用内存存储作为一种新的计算维度，实现算力套利。

    Gemma 3 是在“吃饭”： 利用内存作为一种存储扩展，解决生存空间问题。

四、 “皇帝新衣”背后的真理

我们要明白一个残酷的物理事实：

    知识从未搬家： 在 DeepSeek 的实验中，卸载 Engram 后模型依然有常识。这证明真正的知识“母体”依然锁死在 GPU 里的 FFN 权重中。Engram 只是个带路的。

    参数守恒定律： 无论是 DeepSeek 还是谷歌，总参数量一个都没少。没有所谓的“瘦身魔法”，只有“资产重组”。

结论： DeepSeek 的伟大在于精细化运营（让简单的活儿走查表，复杂的活儿走逻辑）；Google 的优秀在于极限工程化（让庞然大物在手机上跑起来）。

这都不是什么“存算分离”的科学革命，而是向物理现实低头、向成本妥协的工程艺术。请停止意淫“外挂硬盘”，回归到张量和带宽的真实世界中来。

1. 科学理论演进的地层逻辑1.mp4
2. 科学理论演进的地层逻辑2.mp4

1. Engram给Transfomer的是查询提示词而不是查询内容本身1.mp4
2. Engram给Transfomer的是查询提示词而不是查询内容本身2.mp4
3. Engram给Transfomer的是查询提示词而不是查询内容本身3.mp4