很多人第一次接触大模型时，都会被两个词绕住：训练，推理。 这两个词听起来都很“AI”，但它们不是一回事。 一句话讲清楚： 训练，是让模型学会能力。 推理，是让模型使用能力。 再说得直白一点：训练是造模型，推理是用模型。 你平时用ChatGPT、DeepSeek、Kimi、豆包，或者在本地用LMStudio、Ollama、MLX跑模型，绝大多数时候做的都是推理——不是训练。 这个区别很重要。 因为它解释了一个普通用户经常遇到的问题：为什么我的电脑能跑一个32B大模型，却很难训练一个7B小模型？ 答案就在“训练”和“推理”的资源差距里。 一、推理：模型已经学会了，现在拿来用 先说推理。 推理就是模型已经训练好了，你给它一个问题，它根据已有参数生成答案。 比如你问： 推理和训练有什么区别？ 模型不会因为回答了这个问题，就真的重新学习一遍。它只是根据已经训练好的参数、当前输入和上下文，计算出最可能的回答。 这个过程里，模型参数基本不变。 它像一本已经印好的书。你可以翻，可以查，可以用里面的内容，但你翻了一页，并不会改写这本书的正文。 所以推理的核心是：不改变模型参数，只使用模型参数。 你让模型写文章、总结PDF、分析代码、生成标题、做错题讲解，本质上都是推理。本地大模型里的“运行模型”，通常也是推理。 训练是学习能力，推理是使用能力 二、训练：模型还不会，需要反复纠错 训练就不一样了。 训练不是让模型回答一个问题，而是让模型通过大量数据不断改变自己。 它的基本过程可以简单理解为四步： 第一步，模型先预测。 第二步，把预测结果和标准答案对比。 第三步，计算它错在哪里。 第四步，根据错误调整内部参数。 然后换下一批数据，继续重复。 模型看过海量文本、代码、数学题、图片、问答数据之后，才逐渐形成语言规律、知识结构、表达方式和推理能力。 所以训练的本质是：通过大量样本和反复纠错，修改模型参数。 如果把模型比作学生： 训练像上课和刷题。上课时，学生做题、改错、复盘，能力会发生变化。 推理像考试现场答题。考试时，学生只是调用已经学过的知识，现场作答。 这就是训练和推理的根本区别。 三、技术上的关键差别：有没有反向传播 从技术上说，训练和推理最大的区别是： 推理只做前向计算。 前向计算，就是模型根据输入算出输出。 训练既做前向计算，也做反向传播。 反向传播，就是模型根据错误结果，反过来计算每个参数应该怎么调整。 推理时，模型只负责“算答案”。 训练时，模型不仅要“算答案”，还要“算自己错在哪”，再修改参数。 所以训练天然比推理重得多。 这就像： 推理是做一道题。 训练是做题、对答案、分析错因、修改学习方法。 一个只是使用能力，一个是在改造能力。 四、为什么训练比推理吃资源？ 训练和推理的资源差距，最直观体现在显存和内存上。 以一个7B模型为例。 7B，就是大约70亿个参数。 如果用FP16精度推理，每个参数大约2字节，那么模型权重大约是： 70亿×2字节≈14GB 如果做Q4量化，每个参数大约0.5字节，那么模型权重大约是： 70亿×0.5字节≈3.5GB到4GB 所以很多普通电脑、MacBook、Macmini，可以跑7B量化模型。 但训练完全不同。 训练时，系统不只要保存模型权重，还要保存： 梯度； 优化器状态； 中间计算结果； 激活值； 训练数据batch。 也就是说，训练不是只把模型“装进去”就行，还要为修改参数准备一整套额外空间。 同一个7B模型，推理可能几GB到十几GB就能跑起来；训练时，单是参数相关状态就可能需要上百GB，再加上中间结果，需求会继续增加。 所以你会看到一个现象： 普通电脑可以推理一个不小的模型，却很难训练一个比它更小的模型。 原因不是模型名字大小的问题，而是任务性质不同。 ...

我们一开始买 AI 设备，第一眼看的是算力，会想需要多少 TFLOPS？多少 TOPS？GPU 核心多不多？NPU 强不强？ 但真正用来跑本地大模型时，你很快会发现：算力不是唯一答案，甚至很多时候不是第一答案。 有的机器纸面算力很高，但模型装不进去。 有的机器勉强能装进去，但生成速度很慢。 有的机器看起来参数一般，实际跑 7B、14B 模型却很舒服。 还有的设备明明没有独立显卡，却能跑一些消费级显卡装不下的大模型。 问题就出在三个经常被混在一起的词上：显存、内存、算力。 显存和内存，听起来就差一个字。算力又经常被厂商放在宣传页最显眼的位置。于是很多人买设备时容易陷入一个误区： 只看谁算力大，忽略模型到底装不装得下，也忽略数据搬运跟不跟得上。 这篇文章用一个后厨的比喻，把这三个概念一次讲清楚。看完你就会明白： AI 设备不是单纯看谁算力大，而是看容量、带宽、算力是否匹配。 一、显存和内存：同一种东西，两种性格 先说一个容易被忽略的事实：显存和内存，物理上是同一类东西——都是 DRAM 存储芯片，都是用来临时存放数据的。 但它们服务的对象不同。 内存 RAM，主要服务 CPU。 电脑系统、浏览器、微信、Word、Python、数据库、剪辑软件、开发工具，大部分普通程序运行时都要占用内存。 CPU 的工作特点是：任务杂、跳跃性强、经常处理零散请求。一会儿处理键盘输入， 一会儿调度网络请求， 一会儿打开一个网页， 一会儿计算一个 Excel 表格。 所以内存更看重的是：响应快、延迟低、系统调度灵活。 你可以把内存理解为： CPU 面前的一张大办公桌。 办公桌越大，能同时摊开的文件越多。内存越大，电脑就越能多任务，打开大量网页、软件、工程文件时也更不容易卡。 显存 VRAM，主要服务 GPU。 GPU 的工作方式和 CPU 不一样。CPU 更像少数几个能力全面的员工，什么活都能处理，但同时处理的数量有限。GPU 更像一整排流水线工人，每个人做的事情相对单一，但可以同时处理海量重复计算。 比如： 同时处理几百万个像素； 同时渲染大量纹理； 同时计算神经网络里一大批矩阵乘法； 同时处理模型权重和中间张量。 GPU 干活时，需要一次搬运很大的数据量。所以显存更看重的是：高带宽、大吞吐、离 GPU 足够近。 你可以把显存理解为： GPU 旁边的高速专用工作台。 工作台越大，模型、贴图、视频帧、中间计算结果就越能直接放在 GPU 身边。工作台的数据通道越宽，GPU 就越不容易“等数据”。 所以显存和内存的区别，不只是名字不同，而是设计取向不同。 显存和内存的区别 对比项 内存 RAM 显存 VRAM 主要服务对象 CPU GPU 典型用途 系统、软件、多任务 图形、视频、AI 推理、AI 训练 核心取向 低延迟、灵活调度 高带宽、大吞吐 物理位置 主板内存或统一封装内存 显卡上的专用高速内存 不够时的表现 系统卡顿、频繁换页 模型装不下、任务报错、速度骤降 一句话： ...

很多人第一次听到token，是在用AI的时候。 比如你让AI总结一份很长的PDF，它可能提示“内容太长”。你让AI写一篇长文章，它有时候写到后面会忘记前面说过什么。你看一些AI工具的收费说明，又会发现它不是按“字数”收费，而是按token收费。 token到底是什么？ 它是一个字吗？是一个词吗？还是一段话？ 简单说，token可以理解成AI处理文字时使用的“基本颗粒”。 AI不是像人一样按一篇文章、一页纸、一个段落来理解文本，而是先把文字切成一个个token，再进行读取、理解和生成。 所以，token不是一个离我们现实生活很远的技术词，它会直接影响AI能读多长的内容、写多快、花多少钱，以及本地模型要占多少内存。 一、什么是token token 影响 AI 的速度、成本、上下文和内存 第一：token不是固定等于一个字。 在中文里，一个token可能接近一个字，也可能是一段词的一部分。在英文里，一个token可能是一个单词，也可能只是单词的一部分。 举个例子，“今天天气不错”这句话，模型不一定是按“今天／天气／不错”这样符合我们语感的方式切分，它可能切成“今天”“天气”“不错”，也可能切成更细碎的片段，具体取决于模型用的分词方式。 同样，英文单词“tokenization”也常常会被切成“token”+“ization”两个片段，而不是当成一个完整单词处理。所以不能简单理解成： 1个token=1个字。 这个理解不准确。 第二：token是AI处理文本时的基本计量单位。 人看到的是一句话、一段话、一篇文章。 但AI看到的不是完整文章，而是一串被切分过的token，它先把文字拆开，再进行计算。 第三：输入和输出都会消耗token。 你发给AI的提示词、资料、PDF内容、历史对话，都是输入token，而对于AI，是以输出token的方式回应你的要求。 很多人只看AI最后写了多少字，却忽略了前面塞进去的资料、提示词和对话历史，这也都在占“token”。 第四：token越多，AI处理压力越大。 token越多，模型要读的信息越多，信息越多，就会影响速度、成本、上下文长度、内存占用。token不是一个纯技术词，而是理解AI使用成本和体验的入口。 二、token和字数是什么关系？ 很多人最容易误解的地方，就是把token直接等同于字数，这不准确，因为不同语言、不同内容、不同符号，被切分成token的方式不一样。可以简单看这个表： 内容类型 我们看到的单位 AI处理时的单位 中文文章 字、句子、段落 token 英文文章 单词、句子 token 代码 变量、符号、缩进 token 表格 行、列、字段 token PDF内容 页数、段落 token 对话记录 一轮一轮聊天 token 我们不需要精确记住每句话会被切成多少token，只要记住一个大方向：文字越多，结构越复杂，token通常就越多。 如果想有个粗略的量感，可以记一个大致的经验范围：中文大概1～2个字对应1个token，英文大概3～4个字母对应1个token，不需要精确，只是一个方便估算的尺子。 比如： 一段普通聊天，token很少。 一篇3000字公众号文章，token明显增加。 一份几十页PDF，再加上你让AI总结、改写、提炼标题，token就会继续增加。 如果你还让AI保留前面的所有对话，再继续修改，历史对话也会继续占token。 所以AI处理内容时，真正看的不是你主观感觉“这也没多少字”，而是模型内部实际要处理多少token。 三、为什么AI不按字数算，而按token算？ 这个问题很重要，因为在我们的习惯里，文章是按字数算的，比如公众号文章3000字、作文800字、报告5000字，而AI模型真正处理的，是token序列。 你可以理解成： 字数是给人看的单位，token是给模型算的单位。 为什么不能直接按字数算？原因可能是以下三个方面： 1. 不同语言的切分方式不同 中文、英文、数字、标点、代码，被拆分的方式都不一样。 比如英文里，一个常见单词可能是一个token，也可能被拆成多个token。 ...

存储通胀：AI 数据中心把硬件账单递给普通消费者 AI 时代第一张递到普通人手里的硬件账单——「又强又便宜」的二十年，结束了 6 月 25 日晚，苹果官网突然下线维护。几个小时后回来，价格表全变了：Mac、iPad 全线涨价，最高一台涨 3500 块，只有 iPhone、Apple Watch、AirPods 没动。 社交平台上一片“苹果终于露出獠牙”的骂声。但如果你只看到这一层，就把这件事看小了。 过去一年我们聊 AI，眼睛都盯着模型：谁更聪明、谁上下文更长、谁的智能体更像人。而你为 AI 付的钱，你以为是会员费、API、token——其实它正在悄悄变成另一个数字：你电脑价签上多出来的那几千块。 苹果不是想多赚。它已经把成本“内部消化”了大半年，扛到 6 月才不得不把账单甩给消费者。而这张账单真正的开账人，在一千公里外的 AI 数据中心。 下面把这条链一节一节拆开。 一、账单：苹果到底涨了多少 苹果硬件价格集体上涨 先把数字砸出来，这是最直观的部分。中国区官网这一轮共 13 款产品调价，平均涨幅约 21%： 产品 起售价变化（元） 涨幅 Mac Studio 16499 → 19999 +3500 MacBook Pro 13499 → 15999 +2500 iPad Pro 8999 → 10799 +1800 MacBook Air 8499 → 9999 +1500 iPad Air 4799 → 5999 +1200 MacBook Neo 4599 → 5499 +900 iPad（基础款） 2999 → 3799 +800 HomePod mini、Mac mini、iPad A16 这几款涨幅甚至超过 25%。Mac Studio 顶配叠加定制选项，部分机型总价涨幅超过 5000 元。 ...

这两天看到 DeepSeek 又冒出来一个新词：DSpark。 第一眼看上去，很容易以为它又发布了一个新模型。毕竟现在大模型圈子里，只要名字后面多几个字母，大家就会本能地想：是不是能力又上去了？是不是推理更强了？是不是又要重新排榜了？ 但 DSpark 这事，最好不要这么理解，它不是一个新大脑，它更像是 DeepSeek 给模型换了一种更快的说话方式。 简单说，DSpark 解决的不是“DeepSeek 会不会回答”，而是“DeepSeek 能不能更快把答案吐出来”。 这两个问题不一样：一个是能力问题，一个是效率问题。 大模型为什么总是一点点往外蹦字？ 我们平时用大模型，最直观的感觉就是：它不是一下子把整篇回答发给你，而是一行一行慢慢出来。 有时候看着还挺像一个人在打字。 但这不是界面故意做出来的打字机效果，而是大模型本来就这么工作。 大模型生成内容，不是先在脑子里写好一整篇文章，然后复制粘贴出来。它更像是在不断猜下一个字、下一个词、下一个 token。 前面说了什么，决定后面最可能说什么。 大模型如何一个 token 一个 token 生成文本⁠ 所以它的工作方式大概是：先预测下一个 token，再根据这个 token，预测再下一个 token，再继续往后预测。 一路这么走下去，最后才变成我们看到的一段回答。 这里的 token 不需要理解得太复杂。可以粗略当成 AI 处理文字的基本颗粒。中文里可能接近一个字，也可能是一个词的一部分；英文里可能是一个单词，也可能是单词的一部分。 关键不在 token 的精确定义，而在它的生成方式： 大模型原来基本是一个颗粒一个颗粒往外吐。 这就像一个人说话，每说一个字都要停下来想一下。 能说，但慢。 DSpark 在中间加了一个“小助手” DSpark 的思路，可以用一个很土但很容易懂的比喻来讲。 原来的大模型，像一个很谨慎的老师。 每写一个字，都要自己想、自己判断、自己落笔。 DSpark 相当于给这个老师配了一个学生。 学生写草稿，老师快速批改⁠ 学生先写一小段草稿，老师再快速批改： 这几个字对，保留。 这个词不对，改掉。 后面这一小段可以直接用。 这里猜错了，退回来重新写。 如果学生猜得准，老师就省事了。 老师不用从空白纸开始一个字一个字写，而是可以在草稿上快速确认。 这就是所谓的“推测解码”。 听起来挺技术，其实就是四个字： 先猜，再验。 小模型或者草稿模块先把后面可能出现的 token 猜出来，主模型再来验证。猜对了，就一口气通过；猜错了，再回头修正。 所以 DSpark 不是让小模型代替大模型，也不是降低标准凑速度。 ...

12个本地模型，同一份提示词，谁能扛住24GB的内存墙？ 一句话背景：用一份「七板块结构化读书笔记」的硬 prompt，喂同一本书（Dan Koe《目的与利润 / Purpose & Profit》中英对照 PDF，正文约 3.1 万 token），把手头 12 个本地模型挨个拷打一遍。MLX（Metal GPU 推理）和 LM Studio 标准两条路线都上。结论先放这儿：在本地跑大模型，量化等级和那道 ~20GB 的内存墙，比「参数量」和「架构」更能决定你最终能用上谁。 这不是一次只看输出是否流畅的测试。我还把模型给出的“原文锚点”逐条回到原书核对，看它到底是在引用、转述，还是编造。 测试任务很简单，严格按七个板块输出： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 你是一位专业的非虚构书籍编辑和读书笔记作者。下面会给你一本书的完整内容（或节选）。请严格依据原文进行总结，完成结构化输出。 【硬性要求】 1. 只能依据所给文本。不得编造原文没有的观点、数据、人名、案例、术语。若某一项在文本中找不到依据，明确写"原文未提及"，不要猜测、不要用常识补全。 2. 严格按下面的板块标题和顺序输出，不增删板块，不写开场白或结束语。 3. 简练优先，遵守每个板块的字数/条数限制。冗长堆砌、空话套话视为低质量。 4. 全程使用简体中文。 【输出结构】 一、一句话总结（≤40字） 用一句话概括全书最核心的主张（不是主题词，是主张）。 二、核心论点（3–5条，每条≤2句） 提炼作者真正想论证的观点，而非泛泛的话题。 三、章节脉络（逐章，每章1–2句） 按原文章节顺序，逐章概括：这一章讲了什么、与全书主线的关系。 四、关键概念 / 方法论（3–6个） 列出书中提出的核心概念、框架或可操作方法，每个用一句话解释。作者自创的术语保留其原始表述。 五、原文锚点（2–4处） 精确转述能支撑上述论点的原文要点，并注明大致出处（第几章）。此板块用于核对是否忠于原文。 六、给读者的可执行建议（3–5条） 基于全书，提炼读完后能立刻行动的具体建议。 七、本次总结的盲区（≤3条） 诚实指出：受文本长度或上下文限制，哪些内容你可能没有充分覆盖或根本没读到。 【全书内容】上传的PDF就是全文内容。 一、谁活下来了：运行结果总览 12 个模型里，6 个连门都没进（加载即失败），6 个跑出了结果——其中 5 个老实按格式来，1 个（qwen3-32b-mlx）跑是跑了，但完全没理会格式要求。 ...

在众多模型中找适合自己的模型时，会看到类似Qwen3-32B 和 Qwen3-30B-A3B名字很相似的模型名称，一个带“A”，一个不带。参数量看着差不多，到底差在哪？ 这两个字母背后，藏着本地部署里最重要的一条分界线。搞懂它，你才知道自己那台机器该喂什么、该买什么。这篇就把它从头讲透，最后落到一个很实际的问题上：不同的一人公司，到底该怎么选本地模型。 一、一句话区别：处理一个字时，到底激活了多少参数 先建立一个直觉。你可以把一个大模型想象成一家公司，公司里有一大群员工——每个员工就是一个「参数」（实际上是几十亿、上千亿个数字）——这个比喻不严谨，但足够帮我们理解后面的选择逻辑。 所谓「32B 模型」，B 是 billion（十亿），就是这家公司有 320 亿名员工。 模型「思考」的过程，是把你输入的文字拆成一个个小单位（叫 token，大致是「字」或「词的一部分」），然后让员工对每个 token 算一轮，吐出下一个字。 稀疏和稠密的区别，不看公司一共多少人，只看处理一个字时，实际有多少人在干活。 稠密（dense）：每来一个字，全部员工都上工。激活参数 = 总参数。 稀疏（MoE，混合专家）：每来一个字，只叫醒一小撮人，其余继续睡觉。激活参数 ≪ 总参数。 学名叫「激活稀疏性」或「条件计算」。一句话：总参数决定它知道多少，激活参数决定它每个字算得多快、多贵。 二、稠密：全来一个字，全公司加班 传统模型是稠密的。规矩很简单粗暴：每处理一个 token，320 亿员工一个不落，全部上工。 好处是简单、稳定、质量扎实；坏处是贵。员工越多，处理每个字越慢、越耗电、越吃内存。你想让它更聪明（加更多员工），处理每个字的成本就线性地往上涨，逃不掉。 三、稀疏 MoE：路由器翻牌子，只叫醒几个专家 后来人们想了个偷懒的办法，这就是 MoE。 它把公司里干重活的那个部门（技术上叫 FFN 层）拆成了一群专家，比如 64 个、128 个，各有所长。然后在专家前面安排了一个前台调度员，叫「路由器」（router）。 每来一个 token，路由器先瞄一眼：「这个字大概讲代码，叫醒 2 号和 47 号就够了。」于是只有被点名的那几个专家干活，其余几十个继续睡觉，完全不参与这个字的计算。下一个字来了，路由器可能又翻别的牌子。 这个「每次只激活一小撮」的特性，就是「稀疏」这个名字的来历。 稠密与 MoE 两种前向传播对比 上图左边是稠密——每来一个 token，全部参数（亮的）都参与；右边是 MoE——路由器翻牌子，只有 2 个专家被叫醒，其余 4 个灰着不计算。颜色就是全部信息量：亮 = 真的在算，灰 = 睡觉不耗算力。 四、怎么一眼认出来？看名字里那个大写 A 这是最实用的技巧。模型名字里的「A」就是 Activated（激活）： Qwen3-32B：没有 A，稠密，320 亿员工全部上工。 Qwen3-30B-A3B：有 A，MoE，总共 300 亿，但每个字只激活 30 亿（A3B）。 Qwen3-235B-A22B：总 2350 亿，每个字只动用 220 亿。 在 Qwen 这类命名里，A 基本可以理解为 Activated，也就是每 token 激活参数量。看到 30B-A3B、235B-A22B，大概率就是 MoE。没有 A 的 Qwen3-32B，则是 dense。命名规则直接把答案写在脸上了。 ...

这是下篇，来看看内存占用速查表、质量优先的选型心法，以及把 Qwen3-32B 跑通的全流程实操。 上篇我们把名字和原理讲透了——模型名怎么拆、量化是什么、为什么 Mac 适合跑大模型。这篇直接上硬货，回答三个最实际的问题：能跑多大、该选哪个、怎么跑通。 下面所有结论，我都以一台 MacBook Pro M4 Pro、24GB 统一内存、273GB/s 带宽为例。你可以按自己机器的内存和带宽对号入座。 一、你这台 Mac 到底能跑多大？ 先解决一个默认的坑 macOS 默认只允许大约 16GB 内存分给 GPU（Metal），哪怕你有 24GB。所以很多人第一反应“我 24GB 怎么连个 27B 都加载失败”，原因就在这。 解决办法是手动抬高上限（具体命令放在第三部分实操里）。抬高之后，在“机器专用、关掉浏览器和其他重应用”的状态下，真正能用于“权重 + KV cache + 运行时开销”的预算大约 20~21GB。 24GB 统一内存并不是全部都能给模型用 内存占用速查表 公式还是上篇那个：权重 ≈ 参数量 × bpw ÷ 8。下表是各规模、各量化档位下，仅权重的占用（GB）。KV cache 和运行时开销要另外再加约 1.5~3GB（取决于上下文长度）。 规模 IQ4_XS Q4_K_M Q5_K_M Q6_K Q8_0 9B 4.8 🟢 5.5 🟢 6.4 🟢 7.4 🟢 9.6 🟢 14B 7.5 🟢 8.5 🟢 10.0 🟢 11.6 🟡 14.9 🟡 27B 14.5 🟡 16.4 🟡 19.2 🔴 22.3 🔴 28.7 🔴 32B 17.2 🟡 19.4 🔴 22.8 🔴 26.4 🔴 34.0 🔴 35B 18.8 🔴 21.2 🔴 24.9 🔴 28.9 🔴 37.2 🔴 40B 21.5 🔴 24.2 🔴 28.5 🔴 33.0 🔴 42.5 🔴 🟢 舒适（含长上下文也够）　🟡 临界（需抬内存上限、机器专用、上下文别拉满）　🔴 不现实 ...

这一篇是上篇，先看懂模型的名字、量化的门道，以及——凭什么是 Mac。 写在前面 想在 MacBook 上跑个本地模型，打开 LM Studio 的 Discover，搜了一下 Qwen3-32B，结果蹦出来 23 个。 9B、27B、35B、40B 一堆数字也就罢了，每个名字后面还拖着一长串字母：MLX、4bit、IQ4_XS、Q4_K_M、Thinking、abliterated、DWQ…… 到底下哪个？哪个是给这台机器的？哪个下回来跑不动？哪个其实是个根本不需要的版本？ 如果你也在这一步卡住过，这篇就是写给你的。这篇把本地大模型的命名规则、量化原理、为什么 Mac 适合干这事一次讲透。下篇再接着讲这台机器到底能跑多大、质量优先怎么选、以及怎么把 Qwen3-32B 实际跑通。 先从最让人头大的——名字——开始。 面对一堆模型名不知道该选哪个 一、模型的名字，其实是四段拼起来的 看着乱，是因为四个不同维度的信息全挤在一个文件名里。拆成四段就清楚了： 模型名 + 参数规模 + 模型类型 + 量化格式 1. 参数规模：那个 B 是什么 9B、27B、32B 里的 B = Billion，十亿。指的是模型的参数量。数字越大，模型“脑容量”越大，能力上限越高，但也越吃内存、越慢。 这里有个容易踩的坑：MoE 模型。你会看到类似 Qwen3-30B-A3B 的写法—— 30B 是总参数 A3B 是 Active 3B，每次推理实际只激活 3B 这意味着：一个 30B-A3B 的 MoE，显存占用接近 30B，但速度接近 3B。它是“装得满、跑得快”的设计。这个特性后面选型时很关键，先记住。 2. 模型类型：这个模型“会做什么” 名字中间那段单词，决定了模型的用途： 后缀 含义 Instruct / -it 指令微调版，能听懂指令、能对话。日常用的就是它（it = instruction tuned） Base 只做了预训练、没对齐，是“续写型”。一般别下，除非你要自己微调 Chat 对话微调，和 Instruct 类似 Coder / Code 代码专用 VL / Vision 多模态，能看图（如 Qwen-VL） Thinking / Reasoning / R1 推理模型，会先输出一大段思维链再回答 Distill 从更大的模型蒸馏出来的（如 DeepSeek-R1-Distill-Qwen-32B） abliterated / uncensored 社区改版，去掉了安全护栏 一句话：做日常任务认准 Instruct/-it 就对了，其余的是各有专门用途。 ...

上一篇聊了 1P 算力到底有多大，这一篇换个更具体的问法：算力听起来很大，但它到底能干什么？这个问题继续往下走，就会变成一个更具体的问题——如果我手里有一张算力卡，让它连续工作一小时的话，到底能干多少活？ 能写多少篇文章？ 能回答多少次问题？ 能支撑多少人同时使用 AI 助手？ 能不能撑起一个企业内部的智能体系统？ 直接换一种更容易理解的方式：把算力换算成 AI 的实际产能。 不同算力卡一小时能干多少活 1. 算力很抽象，不如换成工作量 我们平时看到算力卡参数，一张卡 300 TFLOPS，另一张卡 1000 TFLOPS，听起来差了好几倍，这个差距到底意味着什么？或者更直白的问题应该是：它一小时能完成多少 AI 工作？ 比如： 一小时能生成多少文字？ 一小时能写多少篇文章？ 一小时能回答多少次问题？ 一小时能服务多少个用户？ 一小时能处理多少份材料？ 这才是算力真正落地之后的样子。 所以，讨论不同算力卡一小时能干多少活，不能只看“这张卡有多强”，而要看它在一个具体 AI 场景里能产出多少东西。 2. 先设定一个统一场景 要比较不同算力卡，必须先设定一个统一场景，否则没法比。 同样一张卡，跑 7B 模型、35B 模型、70B 模型，工作量完全不同，而换做不同的业务逻辑，比如图片生成、视频生成、模型训练、大模型推理，消耗也就完全不同。 选一个足够考验算力、也比较贴近日常 AI 应用的场景：运行一个 70B 级别大模型，连续一小时对外提供文本生成服务。 这个场景可以对应很多实际工作，比如写文章、写代码、做摘要、回答问题、做客服、写方案、做资料分析、给企业内部知识库提供问答服务，我们不讨论一张卡理论上有多强，而看它在大模型推理场景下一小时最多能生成多少 token。 为什么选 70B？——因为 70B 是一个比较好的参照物。 7B、14B 模型更像轻量级工具，适合简单问答、分类、摘要、本地助手。 35B 已经开始进入比较强的生产力模型区间。 70B 则是一个分水岭：模型足够大，负载足够重，也更接近严肃的大模型推理场景。 所以本文里的“一小时能干多少活”，本质上是在问：一张算力卡连续跑 70B 大模型，一小时能生成多少 token？ 3. token 是什么？ AI 生成文本不是按“字”算，也不是按“篇”算，而是按 token 算。 token 可以简单理解成：AI 处理文本的基本颗粒。 ...