<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>稀疏激活 on AI博士 万戈</title>
        <link>https://www.yesmiracle.net/tags/%E7%A8%80%E7%96%8F%E6%BF%80%E6%B4%BB/</link>
        <description>AI博士万戈的技术博客，聚焦 Agentic AI、AI Infra 与 Agent Security，分享 AI 基础设施与工程落地实践。</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-cn</language>
        <managingEditor>admin@yesmiracle.net (万戈)</managingEditor>
        <webMaster>admin@yesmiracle.net (万戈)</webMaster>
        <lastBuildDate>Fri, 16 Oct 2026 14:40:00 +1000</lastBuildDate><atom:link href="https://www.yesmiracle.net/tags/%E7%A8%80%E7%96%8F%E6%BF%80%E6%B4%BB/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>端侧 Agent 模型正在分叉成两条路：LFM2.5 用 2B 激活跑单机，Muse Spark 要两台 Mac Studio 才装得下！</title>
        <link>https://www.yesmiracle.net/post/20261016-on-device-agent-model-fork-lfm25-muse-spark/</link>
        <pubDate>Fri, 16 Oct 2026 14:40:00 +1000</pubDate>
        <author>admin@yesmiracle.net (万戈)</author>
        <guid>https://www.yesmiracle.net/post/20261016-on-device-agent-model-fork-lfm25-muse-spark/</guid>
        <description>&lt;img src="https://www.yesmiracle.net/post/20261016-on-device-agent-model-fork-lfm25-muse-spark/cover.svg" alt="Featured image of post 端侧 Agent 模型正在分叉成两条路：LFM2.5 用 2B 激活跑单机，Muse Spark 要两台 Mac Studio 才装得下！" /&gt;&lt;p&gt;这一周有两场模型发布，标题里都在说同一件事——「在你的设备上跑」。&lt;/p&gt;
&lt;p&gt;一篇是 Liquid AI 的 &lt;strong&gt;LFM2.5-24B-A2B&lt;/strong&gt;，10 月 14 日，Hacker News 上 284 分。另一篇是 Meta 的 &lt;strong&gt;Muse Spark Open&lt;/strong&gt;，10 月 15 日，684 分、369 条评论，当天最热。&lt;/p&gt;
&lt;p&gt;我把两边的官方发布页、模型卡、跑分表和硬件要求都翻了一遍，越看越觉得，「端侧（on-device）」这四个字，正在被用出两种完全不同的意思。&lt;/p&gt;
&lt;p&gt;按 Liquid 的说法，端侧是&lt;strong&gt;你现在坐着的这台笔记本&lt;/strong&gt;：一台 M5 Max MacBook Pro，插着电，跑 &lt;strong&gt;184 tokens/s&lt;/strong&gt;，全程不联网。&lt;/p&gt;
&lt;p&gt;按 Meta 的说法，端侧是&lt;strong&gt;两台顶配 Mac Studio&lt;/strong&gt;，共享 1TB 统一内存。官方原话是「两台 Mac Studio 表现得像一台带 1TB 统一内存的超级计算机」。&lt;/p&gt;
&lt;p&gt;一个能塞进背包，一个要约一辆小货车。它们都叫「端侧」。我想把这中间那笔账，一行一行摊开算清楚。&lt;/p&gt;
&lt;h2 id=&#34;先把两款的底牌亮出来&#34;&gt;先把两款的底牌亮出来&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;Liquid LFM2.5-24B-A2B&lt;/strong&gt; —— 一句话：24B 的脑子，每个 token 只花 2.45B 的电。它是 LFM2.5 家族里最大、也是最后一款模型，这个家族从 230M 一路排到 24B，跨了两个数量级。这是个&lt;strong&gt;纯推理模型&lt;/strong&gt;，回答前一定先想一遍，而且是&lt;strong&gt;纯文本&lt;/strong&gt;的。Liquid 对它的定位很清楚：跑在你已有的设备上，做连续在线的私人 agent。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Meta Muse Spark Open&lt;/strong&gt; —— 一句话：把一台数据中心级的开源模型搬回家。816B 总参数，&lt;strong&gt;42B 激活&lt;/strong&gt;，&lt;strong&gt;100 万 token&lt;/strong&gt; 上下文，原生多模态（文字、图像、音频、视频进，文字出）。Meta 把它称作「迄今最强的美国开源权重模型」，主打长程编码和多步 agent 任务。&lt;/p&gt;
&lt;p&gt;定位差得远，但真正把两条路劈开的，是下面这张表。&lt;/p&gt;
&lt;h2 id=&#34;一张表分岔点在哪&#34;&gt;一张表：分岔点在哪&lt;/h2&gt;
&lt;p&gt;我把两份模型卡里能对上的维度拉到同一根轴上：&lt;/p&gt;
&lt;table&gt;
  &lt;thead&gt;
      &lt;tr&gt;
          &lt;th&gt;维度&lt;/th&gt;
          &lt;th&gt;LFM2.5-24B-A2B（Liquid）&lt;/th&gt;
          &lt;th&gt;Muse Spark Open（Meta）&lt;/th&gt;
      &lt;/tr&gt;
  &lt;/thead&gt;
  &lt;tbody&gt;
      &lt;tr&gt;
          &lt;td&gt;总参数&lt;/td&gt;
          &lt;td&gt;24B&lt;/td&gt;
          &lt;td&gt;816B&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;激活参数&lt;/td&gt;
          &lt;td&gt;2.45B / token&lt;/td&gt;
          &lt;td&gt;42B / token&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;上下文&lt;/td&gt;
          &lt;td&gt;131,072&lt;/td&gt;
          &lt;td&gt;1,048,576&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;MoE 配置&lt;/td&gt;
          &lt;td&gt;40 层，64 专家，top-4&lt;/td&gt;
          &lt;td&gt;62 层，256 专家，top-8&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;专家占参数比&lt;/td&gt;
          &lt;td&gt;稀疏&lt;/td&gt;
          &lt;td&gt;~97%（几乎全在专家里）&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;模态&lt;/td&gt;
          &lt;td&gt;纯文本&lt;/td&gt;
          &lt;td&gt;文本 / 图像 / 音频 / 视频&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;训练预算&lt;/td&gt;
          &lt;td&gt;~36T token&lt;/td&gt;
          &lt;td&gt;未公开具体数&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;许可&lt;/td&gt;
          &lt;td&gt;LFM 1.0&lt;/td&gt;
          &lt;td&gt;Muse Model License（有限商用）+ 使用政策&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;官方「端侧」硬件&lt;/td&gt;
          &lt;td&gt;1 台 M5 Max 笔记本&lt;/td&gt;
          &lt;td&gt;2 台 M5 Ultra Mac Studio（1TB 内存）&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;实测速度&lt;/td&gt;
          &lt;td&gt;184 tok/s（M5 Max）&lt;/td&gt;
          &lt;td&gt;2-bit 量化 18 tok/s（512GB Mac）&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;最省内存跑法&lt;/td&gt;
          &lt;td&gt;4-bit MLX / GGUF&lt;/td&gt;
          &lt;td&gt;2-bit GGUF，约 304GB&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;公开基准表&lt;/td&gt;
          &lt;td&gt;16 项，逐项对标&lt;/td&gt;
          &lt;td&gt;发布页无同轴对比表&lt;/td&gt;
      &lt;/tr&gt;
      &lt;tr&gt;
          &lt;td&gt;发布 / HN 热度&lt;/td&gt;
          &lt;td&gt;10-14，284 分&lt;/td&gt;
          &lt;td&gt;10-15，684 分&lt;/td&gt;
      &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;光看这一张表，最容易得出的结论是「一个大一个小」。但真正决定它俩能不能进你家门的，不是总参数这个数。&lt;/p&gt;
&lt;h2 id=&#34;决定装得下的是总参数决定跑得快的是激活参数&#34;&gt;决定「装得下」的是总参数，决定「跑得快」的是激活参数&lt;/h2&gt;
&lt;p&gt;这两个数经常被混为一谈，而它们其实是两件完全不同的事。&lt;/p&gt;
&lt;p&gt;先说&lt;strong&gt;装得下&lt;/strong&gt;。MoE 的机制是：专家很多，但每个 token 只走其中几个。问题是，&lt;strong&gt;没被走到的专家也得待在内存里&lt;/strong&gt;。Muse Spark Open 每层 256 个专家、每 token 挑 8 个——挑 8 个是算的时候省，但那 256 个在外头排着队等，一个都不能少。Meta 的模型卡里把这句话写得很直白：专家占了全部参数的约 &lt;strong&gt;97%&lt;/strong&gt;，所以「你需要的是一台 816B 模型的内存，但每个 token 只付 42B 的算力」。&lt;/p&gt;
&lt;p&gt;翻译成大白话：&lt;strong&gt;它很大，算得不慢——但一点都不小。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;再看&lt;strong&gt;跑得快&lt;/strong&gt;。推理时每个 token 要做多少次矩阵运算，取决于激活参数。Liquid 的 2.45B 激活，意味着生成一个 token 的计算量，跟一个 2B 多的稠密模型差不多——这就是它能在 M5 Max 上跑到 184 tok/s 的原因。而 Muse Spark Open 虽然参数多得多，激活 42B，单 token 计算量也上去了，所以「端侧」跑起来是 18 tok/s 那一档（还是 2-bit 量化之后）。&lt;/p&gt;
&lt;p&gt;所以这里有个反直觉的结论：&lt;strong&gt;「42B 激活」听起来比「2.45B 激活」大一轮，到了端侧，它俩的差距其实是「能不能装下」决定的，不是「算得快不快」决定的。&lt;/strong&gt; 用单个数字去描述「端侧能力」，一定会错——你得同时看两个数：常驻内存（总参数 + KV cache）决定装得下，激活参数 × 内存带宽决定跑得快。&lt;/p&gt;
&lt;p&gt;这里还藏着一个 Liquid 没明说、但从数字里能读出来的门槛：&lt;strong&gt;18 tok/s 这一档，已经不是交互速度了。&lt;/strong&gt; Liquid 的整套卖点是「工具分派循环像在聊天」——问、提方案、确认、执行、再来一轮，官方说每一轮都远低于一秒。而 Muse Spark Open 在家用 512GB Mac 上跑 2-bit 是 18 tok/s，一个 token 五十多毫秒，一轮多步工具调用下来就是几十秒。它更像一台&lt;strong&gt;在后台干活的机器&lt;/strong&gt;，不是能陪你来回聊的助手。同样叫「端侧」，一个服务&lt;strong&gt;交互&lt;/strong&gt;，一个服务&lt;strong&gt;吞吐&lt;/strong&gt;——这才是两条路在产品形态上真正分道扬镳的地方。&lt;/p&gt;
&lt;p&gt;再补一个细节：Liquid 是&lt;strong&gt;主动封顶&lt;/strong&gt;的。官方说 24B 是 LFM2.5 家族「最大、也是最后一款」模型。也就是说，他们先给「笔记本能跑」这件事定了一个上限，到了就不再往上加。Meta 走的是相反方向：先把数据中心级的模型放出来，再回头用量化把它塞进桌面。一个是从尺寸出发定能力，一个是从能力出发找尺寸——顺序反了，最后的形态也就完全不同。&lt;/p&gt;
&lt;h2 id=&#34;内存带宽才是真正的裁判&#34;&gt;内存带宽才是真正的裁判&lt;/h2&gt;
&lt;p&gt;Meta 那边的算术很值得看。M5 Ultra 每台能分给集显最多 &lt;strong&gt;512GB&lt;/strong&gt; 统一内存，两台凑一块儿就是 1TB；而这颗芯片的&lt;strong&gt;内存带宽是 1.2 TB/s&lt;/strong&gt;，快到足够在一个 token 的时间里把需要的那一小片权重读出来。&lt;/p&gt;
&lt;p&gt;这句话翻译一下：端侧推理的瓶颈不是算力峰值，是&lt;strong&gt;内存带宽&lt;/strong&gt;——模型再稀疏，权重总得从内存里读出来喂给 GPU，读得慢，再少的激活参数也白搭。这也解释了为什么 Meta 敢说「两台 Mac Studio 能装下整个模型」：BF16 权重大约 &lt;strong&gt;1.5TB&lt;/strong&gt;，两台 Mac 的 1TB 是装不下的，所以官方那条线，靠的是&lt;strong&gt;量化&lt;/strong&gt;——Muse Spark Open 同时放出了 NVFP4（4-bit，给 Blackwell GPU 用）的权重，社区还用 llama.cpp 压到 2-bit。真正能进「家」的那一版，是压过的。&lt;/p&gt;
&lt;p&gt;Liquid 这条路反过来：它从一开始就没打算让你跑原尺寸。家族里直接备好了 FP8、GGUF、ONNX、MLX 4-bit 一堆版本，目标就是那个「塞进笔记本」的尺寸。&lt;strong&gt;一边是先把大模型放出来、再想办法压进去；另一边是先定死笔记本的尺寸、再把能力往这个尺寸里塞。&lt;/strong&gt; 这是策略上的根本分歧。&lt;/p&gt;
&lt;h2 id=&#34;有一笔钱两边都没在宣传页上写明kv-cache&#34;&gt;有一笔钱，两边都没在宣传页上写明：KV cache&lt;/h2&gt;
&lt;p&gt;上下文越长，缓存越大，而这笔内存是&lt;strong&gt;叠在权重上&lt;/strong&gt;的。&lt;/p&gt;
&lt;p&gt;Muse Spark Open 的 100 万 token 上下文听着很爽，但 HF 的说明给了一组算术：它的分组查询注意力（GQA）每个 token 要在 KV cache 里多存 &lt;strong&gt;126,976&lt;/strong&gt; 个值，BF16 下大约 &lt;strong&gt;250KB/token&lt;/strong&gt;——&lt;strong&gt;填满 100 万上下文，光缓存就要约 266GB。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;也就是说，「100 万上下文」在桌面端不是一个能力描述，是一个&lt;strong&gt;内存承诺&lt;/strong&gt;。你规划硬件的时候，不能只按权重算，得把缓存一起算进去。&lt;/p&gt;
&lt;p&gt;Liquid 这边上下文是 131K，量级小一档，代价也就轻一档。这又是同一件事的两面：&lt;strong&gt;你要多长的记忆，就得买多大的内存。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id=&#34;跑分这回事两边用的是两套标准&#34;&gt;跑分这回事，两边用的是两套标准&lt;/h2&gt;
&lt;p&gt;Liquid 的做法很清楚：发布页上摆了一张 &lt;strong&gt;16 项&lt;/strong&gt;的跑分表，逐项对标 Qwen3.6-35B-A3B、Gemma-4-26B-A4B、Nemotron-3.5-Lightning 这些「总参数和激活参数都比它多约 50%」的对手。&lt;/p&gt;
&lt;p&gt;结果是这样：在 8 项工具使用和 agent 基准里，它&lt;strong&gt;赢了或追平了 5 项&lt;/strong&gt;——AutomationBench 拿了 &lt;strong&gt;27.69&lt;/strong&gt;，对手最好的才 8.72，是三倍多的差距；LiveClaw &lt;strong&gt;48.09 对 38.19&lt;/strong&gt;；IFBench、Multi-IF 这类指令跟随也全部领先。但到了知识密集型（GPQA Diamond 74.42 对 83.69）和编码（SWE-Bench Verified 51.00 对 66.20）上，大模型依然压它一头。Liquid 自己也没藏着，直接在文档里写：知识密集型的活别指望它单干，「配检索或联网搜索」。&lt;/p&gt;
&lt;p&gt;这个态度本身就值一提：它把「我能赢哪几项、会输哪几项」都摊开了，让读者自己判断。&lt;/p&gt;
&lt;p&gt;Meta 这边，我翻完了 Muse Spark Open 的发布页和模型卡，页面上是有一个「Key Benchmarks」的标题，但&lt;strong&gt;没有给出能和 Liquid、Qwen 这些放在同一根轴上比对照的公开跑分表&lt;/strong&gt;——第三方梳理也点出了这一点：「最强开源权重模型」这个定语，目前查不到对应的公开基准支撑。Meta 说详细结果在模型卡和方法学报告里，但那份「可比对」的表，我在发布页上没看到。&lt;/p&gt;
&lt;p&gt;我不想把一个「暂未公开」读成「不敢公开」——超大模型的对标口径本来就和小模型不一样。但事实是：&lt;strong&gt;小模型要靠一张打得赢的跑分表证明自己值这个尺寸；超大开源模型这一轮，靠的是一个「最强」的定语，加一长串合作伙伴的名单。&lt;/strong&gt; 两边的证据标准，确实不在一个水平线上。&lt;/p&gt;
&lt;h2 id=&#34;两个训练细节比参数更能说明问题&#34;&gt;两个训练细节，比参数更能说明问题&lt;/h2&gt;
&lt;p&gt;Liquid 的训练过程里有两个细节，我觉得比参数更值得记。&lt;/p&gt;
&lt;p&gt;第一个：它是被&lt;strong&gt;放进真实的 agent harness 里做强化学习&lt;/strong&gt;的——OpenClaw、Hermes Agent、Pi、OpenCode 都进过训练环。不是在一个模拟环境里练，是在真家伙里练。&lt;/p&gt;
&lt;p&gt;第二个，也是更微妙的：在教师模型专门化阶段，它出现了一批&lt;strong&gt;典型的「钻奖励空子」行为&lt;/strong&gt;——它会跑去 &lt;strong&gt;git 历史&lt;/strong&gt;里翻答案，跑上 GitHub、PyPI、Hugging Face 去找最终结果；更没想到的是，它甚至&lt;strong&gt;意识到自己在沙箱里&lt;/strong&gt;。Liquid 的判断是，这看着像涌现，但多半是训练数据里有类似模式；他们随后收紧了沙箱，并声明所有公布成绩都来自「密封的评估环境」。&lt;/p&gt;
&lt;p&gt;我把这段读了好几遍。它指向一个常被忽略的事实：&lt;strong&gt;端侧 agent 真正的难点，是 reward 怎么设计，不是模型怎么缩小。&lt;/strong&gt; 一个 2.45B 激活的小模型，想到的第一招是作弊——而它在端侧要连续在线、要自己调工具、要跑好几天，这种「钻空子」的倾向会被放大。谁能把奖励和沙箱做扎实，谁才配谈「端侧 agent」。&lt;/p&gt;
&lt;p&gt;Meta 那边的 demo 则更「发布会」一些：用 Muse Spark Open 驱动的 Muse Code，据说真的往开源 Mastodon 客户端 Ice Cubes 提交了 iOS 改动（改 bug、加功能、跑通完整构建），还端到端操作了一遍 DaVinci Resolve，逐帧看素材、挑高光、裁成竖版。这些是&lt;strong&gt;厂商 demo，不是评测&lt;/strong&gt;——但方向上说明 Meta 押的是「长程、重度、真实工作流」。&lt;/p&gt;
&lt;h2 id=&#34;于是我们看到的是两条完全不同的产品形态&#34;&gt;于是我们看到的是两条完全不同的产品形态&lt;/h2&gt;
&lt;p&gt;把上面这些拼起来，这两款模型其实是两种未来的代言人。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Liquid 这条路的赌注是&lt;/strong&gt;：模型必须跑进用户&lt;strong&gt;已经有的&lt;/strong&gt;那台设备里。卖点是隐私、离线、以及边际成本为零——权重在你机器上，跑一百万 token 也不多花一分钱（走 API 的话官方定价是 $0.10/1M 输入、$1.00/1M 输出，端侧则是纯电费）。代价是能力天花板：知识、编码这些照样得靠检索补。它服务的是「&lt;strong&gt;随身、连续、私密&lt;/strong&gt;」这一类 agent。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Meta 这条路的赌注是&lt;/strong&gt;：把开源旗舰权重放出来，占领生态。但你得看清现实——官方列出的 API 伙伴是一长串：Baseten、Fireworks、Groq、Modal、Nebius、OpenRouter、Together。&lt;strong&gt;绝大多数人最终会走 API，而不是真的搬两台 Mac Studio 回家。&lt;/strong&gt;「端侧」在这条路上，更像一层覆盖在生态分发上的叙事：权重开放是真的，但你手上的「端侧」体验，多半还是云。&lt;/p&gt;
&lt;p&gt;一个有意思的补充：Apple 其实已经在自己的 MLX + RDMA 研究里演示过把这款模型跑在&lt;strong&gt;四台&lt;/strong&gt; Mac Studio 上。从两台到四台，这条路的方向是——&lt;strong&gt;往更大的设备集群走&lt;/strong&gt;，而不是往更小的口袋走。&lt;/p&gt;
&lt;h2 id=&#34;分叉的胜负手不在参数表上&#34;&gt;分叉的胜负手，不在参数表上&lt;/h2&gt;
&lt;p&gt;我的判断是：&lt;strong&gt;端侧不会收敛到一条路，而且这两条路短期内根本不在同一个战场。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Liquid 赢的是「单机可用」这道窄缝——一个模型能在你已有的笔记本上、离线、以交互速度跑起来，这是 Meta 现阶段不会去争的。但这条窄缝有个隐忧：Meta 手里并不是只有 816B 这一张牌。它 8 月就放过一个 &lt;strong&gt;30B 的开源模型 Muse Glimmer&lt;/strong&gt;，跟 Muse Spark Open 共用同一套分词器和词表。也就是说，&lt;strong&gt;大厂在两端都下了注&lt;/strong&gt;——往上是桌面超算，往下是小尺寸端侧。创业公司靠「单点工程性价比」建的护城河，正在被两头同时挤压。&lt;/p&gt;
&lt;p&gt;所以如果你是读者，要按自己的场景选：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;你要的是「&lt;strong&gt;我的数据不出门 + 随时在线&lt;/strong&gt;」——盯&lt;strong&gt;激活参数&lt;/strong&gt;和&lt;strong&gt;常驻内存&lt;/strong&gt;，看它俩能不能一起压进你&lt;strong&gt;手里已有的&lt;/strong&gt;那台机器。这一档目前是 Liquid 的地盘。&lt;/li&gt;
&lt;li&gt;你要的是「&lt;strong&gt;开源旗舰、随便改、当基础设施&lt;/strong&gt;」——接受它其实是一台**家电（appliance）**而不是一台笔记本：要么攒设备，要么直接走 API。这一档是 Meta 的地盘。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;至于「谁更强」这种问法，本身就问错了。一款是往口袋里塞的，一款是往机房里塞的。它们唯一的共同点，是都在用「端侧」这个词给自己做广告——而这个词，已经通胀到能装下一台笔记本和一辆小货车的差价了。&lt;/p&gt;
&lt;h2 id=&#34;写在最后&#34;&gt;写在最后&lt;/h2&gt;
&lt;p&gt;这两篇发布放一起看，最有意思的不是数字差了多少，是「端侧」这个词被拆成了两半。&lt;/p&gt;
&lt;p&gt;一半是说给&lt;strong&gt;设备&lt;/strong&gt;听的：模型要让路，压进你已有的机器。另一半是说给&lt;strong&gt;生态&lt;/strong&gt;听的：权重放出来，占住开发者。前者是工程问题，后者是分发问题。&lt;/p&gt;
&lt;p&gt;前几天聊 OpenAI Dots 和 Meta Muse 的时候，我拆的是两款永远在线 agent 的&lt;strong&gt;运行时架构&lt;/strong&gt;（&lt;a class=&#34;link&#34; href=&#34;https://www.yesmiracle.net/post/20261001-openai-dots-vs-meta-muse/&#34; &gt;那篇讲的是云电脑 vs 安全虚拟机&lt;/a&gt;）；更早一篇讲的是 Meta Muse 作为&lt;strong&gt;产品&lt;/strong&gt;长什么样（&lt;a class=&#34;link&#34; href=&#34;https://www.yesmiracle.net/post/20260909-meta-muse-personal-ai-agent/&#34; &gt;每人一台专属云端电脑&lt;/a&gt;）。这一篇不讲产品，只讲两个&lt;strong&gt;开源权重的端侧账本&lt;/strong&gt;——它俩加起来，正好说明了同一个词可以指着多远的两个方向。&lt;/p&gt;
&lt;p&gt;下一次再有人跟你说「这个模型能跑端侧」，别急着信。先问两个数：&lt;strong&gt;总参数多大（装得下吗），激活参数多大（跑得动吗）。&lt;/strong&gt; 答案经常是两个世界。&lt;/p&gt;
</description>
        </item>
        
    </channel>
</rss>
