← 返回博客

设备与工作流

本地 AI 升级账本:容量、带宽、上下文与完整任务成本

用 Qwen 模型配置、Apple 与 NVIDIA 的官方规格,算清权重、KV 缓存和并发的内存需求;再把 SSD、扩展坞、人工复核放进完整流程,判断升级究竟节省了什么。

同样想在电脑上跑 AI,有人缺磁盘空间,有人加载模型时内存不足,也有人模型能跑却每次都要等很久。购物清单上都写着“升级”,要买的东西可能完全不同。本文用模型容量计算、Apple 与 NVIDIA 的官方规格,以及一份完整任务成本表,追问每一笔升级费究竟解决了什么。

一、把“我要用 AI”改成一份任务说明

先写下你要处理的材料、希望得到的结果、多久做一次、最晚何时需要完成。两千字文章的润色、一小时录音转写后校对、几十份报告的检索问答、同时运行多个编码会话,对硬件提出的问题并不相同。仅凭一个模型名字或者“AI 电脑”标签,无法给这些任务排预算。

还要定义结果怎样算合格。录音里的姓名是否必须准确,报告里的数字是否必须附出处,代码是否必须通过已有测试?模型输出速度是过程指标,合格结果才是用途。如果更快的生成带来更多人工复核,采购收益可能被后面的工作抵消。

一个适合用来测试的任务说明可以是:“每周处理四段一小时中文访谈,先转写,再用本地文本模型校对术语,最后由人核对人物和数字;希望每段在两小时内完成。”这里的频率和期限是假设,但已经足以让我们追问:音频模型与校对模型是否同时驻留?是否批量处理?人工核对占多少时间?

阶段 要观察的现象 首先相关的资源
获取与保存 下载失败、文件放不下、版本重复 网络、磁盘容量、目录管理
加载 首次启动久、频繁换模型久 存储读取、反序列化、内存与设备传输
处理输入 长材料迟迟没有第一个输出 提示词处理、计算、上下文与缓存
生成 已开始回答,但逐字输出慢 模型计算、内存带宽、软件实现
并发与排队 单个任务正常,多任务失速 总内存、调度、共享资源和队列
交付 文本很快生成,却需要大量返工 任务设计、模型适配和人工验证

将一个任务分成阶段后,很多购买建议就可以检验了。“换 SSD 会快”必须说清是下载、加载还是生成;“加内存就好”必须说明瓶颈是总量不足,还是每秒能读出的数据不够。没有阶段边界的快慢描述,很容易变成不同人各自说着正确但不相干的话。

本地 AI 从文件到加载、处理输入、生成、复核交付的阶段链,存储、内存、计算和人工分别影响不同阶段。本地 AI 任务的五阶段排查路径及各阶段要记录的时间。
图 1|任务分解框架,属于分析示意。记录每一阶段的时间,比只记录一个 token/s 更接近最终体验。

二、权重文件只是内存预算的起点

可以先用一个理想化公式理解模型规模:权重字节数约等于参数数量乘以每参数位数,再除以 8。它忽略量化分组的比例因子、部分保留高精度的张量、索引和运行时开销,因此只能作为最简单的容量基线。实际模型文件和运行占用必须另行测量。

假设参数规模 16 位权重 8 位权重 4 位权重
8B,80 亿参数 16GB 8GB 4GB
14B,140 亿参数 28GB 14GB 7GB
32B,320 亿参数 64GB 32GB 16GB
70B,700 亿参数 140GB 70GB 35GB

表中全部是十进制 GB,只计假设的权重载荷,不是某个下载文件的大小,也不是“配这么多显存就一定能运行”的配置表。8B 这样的名称有时还是近似规模,实际参数数量要查模型文件。把营销名称当成精确字节数,会让接近容量边界的计划产生误差。

真正要分配的内存还包括 KV 缓存、计算中的临时张量、运行框架、操作系统与其他应用。独立显卡的显存和 CPU 的系统内存,也不是把两个数字相加就变成同速的池子。若程序需要在两者之间移动数据,连接路径就会进入性能问题。

因此,一个“4 位 32B 约 16GB”的算式,不足以推出它适合任何 16GB 显卡。权重本身已经接近这个名义容量,缓存和临时区还没有位置;不同量化格式的真实占用又不同。较稳妥的做法是查具体模型版本和后端,记录加载后以及长输入时的峰值,而不是在采购时把剩余空间假设成零。

量化还需要验收结果质量。文件变小与任务可用,是两个判断。对访谈转写后的术语纠错,可以准备姓名、产品型号、时间和数字密集的样本,检查更低精度是否影响这些关键点;对代码任务,测试通过率比几段看起来流畅的输出更有说服力。

混合专家模型又引入一种不同的误读:每步激活的参数量影响计算工作,但通常不能直接替代全部权重的存放需求。要判断内存,仍需查看总权重和具体的加载、卸载机制。只看到较小的“激活参数”数字就决定显存容量,可能从第一步就算错了账。

三、上下文与并发,会把一个能运行的模型推到容量边界

长对话需要保留供后续生成使用的状态。对于常见 Transformer 注意力结构,可以用一个明确限定的例子看出量级。Qwen3-8B 的公开配置列出 36 层、8 个 KV 头、每头维度 128;这里只讨论普通全长、未量化、每元素 2 字节的 K/V 缓存,且单个会话、不共享前缀。Qwen 官方配置。

计算公式是:2(K 与 V)×36(层)×8(KV 头)×128(每头维度)×2(字节)×token 数。于是每个 token 需要 147456 字节,即 144KiB。这里的“上下文”指实际保存的 token 数量或框架为它预留的容量,不是中文字数。

缓存 token 数 一个会话的理论 KV 大小 两个独立会话合计
4096 0.5625GiB 1.125GiB
8192 1.125GiB 2.25GiB
16384 2.25GiB 4.5GiB
32768 4.5GiB 9GiB
依据 Qwen3-8B 配置计算的缓存大小,32768 token 单会话4.5GiB,两个独立会话9GiB。上下文与并发对理论 KV 缓存的影响,非实际内存测试。
图 2|计算示例,单位为二进制 GiB。未包括模型权重、临时张量和分配器开销;不代表所有模型都采用相同缓存结构。

这个例子没有把上下文无限外推。配置、位置编码方法、实现支持和模型在长材料上的准确性,都限制实际可用范围。缓存装得下,只解决了资源上的一个问题;模型是否能可靠找到材料里的关键事实,仍需要任务评测。

框架行为也会改变测量结果。有的按需要增长,有的预留固定区域,有的支持缓存量化或卸载。Hugging Face 文档说明缓存卸载会在 CPU 与 GPU 之间搬运状态,量化缓存也可能改变延迟表现。缓存策略文档。这说明节省内存可以交换出额外工作,不能把所有省内存选项都当作免费提速。

Ollama 的文档则指出,上下文增加会提高内存需求,并可用 ollama ps 检查分配;其 FAQ 说明并发会话会增加上下文相关内存。上下文文档、并发说明。这些是版本相关的行为,使用时应记录当前版本和实际设置,不照抄别人一年前的默认值。

在访谈例子里,一种可检验的选择是分段校对并保留必要的术语表,而不是每次都把全部历史重新塞入上下文。但分段会损失跨段信息,需要额外设计人名一致性和合并检查。省下内存的同时,如果增加大量人工回看,就应把这部分代价写进预算。

多人共用设备时,还要定义排队规则。一个单会话测试通过,并不意味着四个人同时请求也能维持相同延迟。测试至少应覆盖普通输入、最长常见输入,以及预计的同时请求数。否则购买时确认的只是实验室里最舒服的时刻。

四、Apple 与 NVIDIA 的规格,揭示了三种不同取舍

下面不是推荐榜单,也不比较当前售价,而是用官方可核验的数据说明容量与带宽为何必须同时看。完整系统、集成芯片平台和独立显卡的成本边界不同,不能把一张显卡的价格与一台整机直接对齐。

代表配置 公开容量和带宽 对预算问题的启发
Mac Studio,M3 Ultra 819GB/s;截至核查日支持页列 96GB 基础、可配 256GB 统一内存 大容量由 CPU、GPU 等共享;总容量不能全部承诺给单个模型
NVIDIA DGX Spark,128GB 配置 128GB 统一系统内存,273GB/s 较大的容量与较低的名义带宽可以同时存在
GeForce RTX 5090 32GB GDDR7,1792GB/s 显存带宽高,但单卡容量可能先成为约束;还需主机与电源等

来源:Apple 技术规格、DGX Spark 官方规格、NVIDIA Blackwell 白皮书,第 15 页。以上为厂家规格,并非本文实测;不同架构的“带宽”数字不可直接兑换成相同比例的 token/s。

三种代表配置的容量与名义带宽对照:M3 Ultra256GB与819GB每秒,DGX Spark128GB与273GB每秒,RTX5090显存32GB与1792GB每秒。容量和带宽分为两个面板比较,不合成性能评分。
图 3|官方规格的两轴对照。统一内存与专用显存的使用范围不同;图中没有价格、实际可分配容量或任务速度排名。

这些规格对应着不同的客户需求。有人需要将较大的模型与工作集留在一台机器里;有人愿意把模型压到较小容量中,优先追求吞吐;有人更在意已有软件栈能否直接运行。容量、带宽、软件和系统集成,是几种可以分别收费的能力。评价产品竞争力时,也就不能只围绕一个最大值排队。

对用户,问题于是变成:自己的任务首先撞到哪堵墙?如果权重和缓存无法容纳,再高的纸面带宽也不能替代缺少的空间。如果模型已经稳定驻留,则继续购买未使用的容量,未必改善生成时间。若必需的软件缺少相应后端,优秀的硬件规格也可能暂时用不上。

“统一内存”需要同样具体地理解。它描述某种访问和组织方式,不代表操作系统不占空间,不代表所有框架都能自由使用标称总量,也不代表它与专用显存拥有相同延迟、带宽或软件优化。购买前仍应核对可用的后端、版本、模型格式和实际分配。

多卡扩展也不应只看显存相加。模型如何分片、卡与卡之间如何通信、主板插槽带宽、电源和散热,都会进入结果。Ollama 对跨 GPU 加载的说明就强调了数据转移的影响。若没有同一模型和任务的验证,把两块卡视为一块双倍容量且双倍速度的卡,是把计算图最重要的部分省略了。

规格还有时间边界。发布新闻、历史配置和当前支持页可能不完全一致,地区与在售组合也可能不同。本文采用上表核查时可见的明确配置,并未调查当地库存。采购时应保存具体报价与完整配置,不能仅凭文章里的一个最大值下单。

五、带宽能给出一个边界,不能给出完整跑分

对于某些单会话、自回归、稠密模型的生成阶段,可以建立一个极简模型:如果每生成一个 token 都要从主存层读取约 W 字节权重,而有效带宽是 B 字节每秒,那么只考虑这次读取,速度上限约为 B÷W。它的意义是帮我们发现量级,不是精确预测。

假设权重需要搬运 16GB,有效带宽分别为 100、300、800GB/s,对应这个简化边界是 6.25、18.75、50 token/s。这些带宽是人为选择的例子,不是把上一节三台设备直接代入;真实程序还要进行计算、读取缓存、调度内核,并受量化解码等影响。

情形 简化模型遗漏的因素 应补充的测量
首次处理很长输入 提示词处理的并行计算与注意力开销 首 token 延迟、输入 token/s
单会话持续输出 缓存读取、有效带宽、内核和计算 稳态输出 token/s 与峰值内存
多会话批量生成 权重复用、批量调度与排队 总吞吐,以及每个请求的完成时间
混合专家或卸载 实际激活权重、专家调度、传输路径 分阶段时间与设备间数据移动

这也解释了为什么产品页面的 TOPS 或 FLOPS 很难单独回答本地使用体验。峰值计算能力必须依赖相应精度、算子和利用率;某个工作负载如果主要等数据,增加纸面计算能力可能没有同比收益。另一个批量计算密集的任务,却可能非常需要它。

预填充和生成最好分开记录。预填充处理已有输入,生成则逐步产生后续 token。一个模型先沉默三分钟,再快速输出,与另一个十秒后开始但输出较慢,可能有相同的平均数字,却有不同的使用体验。对交互式工作,首个有用结果到达时间往往比总字符数更直接。

缓存还会让第二次运行看起来格外漂亮。如果拿已经加载、已有相同前缀的一次请求,与新机器的冷启动比较,就把设备和状态一起换了。至少保留冷启动、已加载的新请求、允许重复前缀三种标签,不把其中最快的一次当成每天都能得到的表现。

这个简化模型也必须接受反证。如果原先认为时间主要花在读取权重,测量却发现大部分等待来自预处理或 CPU 回退,就需要修改解释。模型有用的前提是能看清假设。给同一个未经验证的速度预测增加小数位,不会让它变成一次设备测试。

六、SSD 很重要,但需要说明它在哪个阶段重要

磁盘空间不足时,更大 SSD 直接解决文件容纳问题;频繁切换大型模型时,读取和加载路径可能影响等待;长期驻留的生成任务,则需要证明磁盘访问确实进入了瓶颈,才能把更快 SSD 的费用归因到输出速度。

操作系统交换空间、框架权重卸载和 KV 缓存卸载,也不是同一个机制。它们移动的数据、触发条件和访问粒度不同。把“软件可以使用磁盘”概括成“SSD 能当同速显存”,省略了最关键的速度差异和实现约束。实际能否接受,应由完整任务测试回答。

一个可以直接观察的实验是:固定模型版本、上下文和输入,记录第一次加载时间;在模型保持驻留时再次提交不同但相近长度的任务,分别记录生成时间。然后改变模型文件所在存储,重复同样条件。若改善主要出现在加载,结论就应限定为加载收益,而不是宣称模型整体性能翻倍。

外置存储还带来运维上的小问题。路径是否稳定挂载,休眠后是否仍可用,后台服务是否有读写权限,拔下设备时程序怎样处理?Ollama FAQ 中的 OLLAMA_MODELS 可以指定模型存放位置,但路径改好并不自动解决这些条件。模型存储说明。在日常使用中,一次不可预期的断连可能抵消很多次快几秒的加载。

存储价格的产业背景也值得分开看。AI 数据中心对存储的采购,与个人本地推理的硬件需求并不一一对应。前者可能推高某类供应的重要性,后者仍要按实际工作选择容量。关于公司数据、零售价格传导和容量预算,见AI 存储涨价与 SSD 购买判断。

七、扩展坞的价值要放进整条连接路径

将电脑、扩展坞、线材和 SSD 连起来之后,限制不再只属于某一个产品。一个扩展坞标有多个高速数据口,也不代表所有口在同时工作时都能独占同等上行带宽。需要核对的是主机端、上行连接、各下行端口与共享关系。

连接项目 购买前记录什么 验收时检查什么
主机端口 完整电脑型号、端口对应协议 系统识别的连接方式,直连基线
扩展坞上行和数据口 上行速率、下行规格、共享条件 SSD 单独使用与同时接其他设备的差别
线材 数据速率与供电能力分别核对 换用符合规格的线是否改变结果
外接显示器 分辨率、刷新率、独立扩展需求 每块屏的实际模式与稳定性
主机供电 充电器、坞的主机输出功率、线材条件 真实工作负载下能否维持充电和稳定连接

USB-IF 的线材说明区分数据能力与供电标识,PD 协议能力也不能代替每台设备的实际功率。线材说明、USB PD 说明。商品页写 100W 输入时,还应找到它实际能给主机提供多少;缺少这条信息,就不应自行把两个数字视为一样。

显示器则要核对具体电脑和连接方式。Apple 的说明要求按 Mac 型号、显示器数量和模式判断支持情况。Apple 显示器连接说明。两个 HDMI 插口并不能独立证明两块屏一定可以扩展;依赖驱动的方案还涉及系统支持、安装权限与更新维护。

最有信息量的验收通常很简单:同一个文件集、同一块盘,先直连,再经过扩展坞,分别记耗时与异常;然后增加第二个共享设备,看看变化是否符合预期。不要同时换线、换盘、换文件又更新系统,否则差异无法归因。

扩展坞可以带来整洁、插拔便利和端口集中,这些价值完全合理,只是应与模型运行性能分开记账。如果直连已经满足工作速度,可以为便利付费;没有证据时,不应把这笔便利支出包装成 AI 性能升级。

八、完整任务成本,往往会改变升级顺序

下面沿用访谈工作流,设定两个纯假设的方案。每次都得到符合相同质量要求的一份结果,软件费用暂相同。原流程花 3 分钟加载、12 分钟转写、8 分钟校对生成、20 分钟人工检查,共 43 分钟。方案 A 只把加载变成 1 分钟,总计 41;方案 B 把转写变成 8 分钟、校对生成变成 5 分钟,其他不变,总计 36。

假设访谈工作流总耗时43分钟,改善加载后41分钟,改善转写和校对计算后36分钟;人工检查均为20分钟。三种假设方案按加载、转写、校对、人工检查分解耗时,不是硬件跑分。
图 4|情境计算,单位:分钟。所有输入均为假设,用来说明完整任务收益;不对应任何品牌或实测性能。
方案 每次总耗时 每次节省 假设每月 20 次时节省
原流程 43 分钟 — —
A:仅改善加载 41 分钟 2 分钟 40 分钟
B:改善主要计算阶段 36 分钟 7 分钟 140 分钟

即使某一阶段提速很明显,总流程收益也会被其他阶段限制。这个例子里,人工检查始终占二十分钟;若换用更小模型后校对输出需要多核对十分钟,计算节省可能被反向抵消。因此时间表需要与质量标准一起保存,不能只留下最好看的性能项。

再加一组明确标注的价格假设:A 的新增支出 600 元,B 为 3000 元。每月二十次,A 一年省 8 小时,B 一年省 28 小时;对应首年每节省一小时的设备支出约 75 元与 107 元。B 更快,但这个量尺上并不更便宜。它们都不是市场报价,也没有考虑残值、电费和维护。

如果一年后工作量翻倍,计算会改变;如果设备还能服务其他高价值任务,也应单列用途;如果只是学习爱好,则预算可以体现兴趣而不必假装全部能回本。清楚承认购买的用途,比用一个统一的“生产力提升百分比”更诚实。

比较云端方案时,成本边界还应包括订阅或调用费、传输、任务可用性、数据处理要求和人工验证。不能拿云端峰值模型的能力与本地较小模型作同质价格比较,也不能假设本地运行天然消除全部数据风险。资料是否允许上传、插件是否联网、输出如何保存,都需要按工作环境具体确认。

企业端还有部署和维护成本。驱动更新、框架兼容、模型版本回退、故障处理,可能由使用者自己承担,也可能由供应商支持。如果一个更贵的方案让关键软件可靠运行,这种集成价值应当被计入;但同样需要记录实际节省了什么,而不是默认所有“一体化”产品都更合算。

还要区分任务经过的时间与人被占用的时间。一项任务可以整夜无人值守,虽然运行很久,却未必妨碍白天工作;两分钟的等待反复出现二十次,则可能持续打断注意力。上面的算式统计的是经过时间。将它转换成经济价值,还需要判断这些分钟在真实流程中如何被使用。

九、三个预算情境:先问缺口,再选设备

第一种:现有电脑,小规模文字任务。 先用小而固定的测试集比较模型与量化版本,确认输出质量和上下文需求。若能够稳定完成,磁盘也够用,暂时没有硬件采购的必要。应优先改善提示、资料组织、结果核对和版本记录。把基础流程跑顺,日后出现瓶颈时才有可比较的基线。

第二种:访谈、素材与中型本地模型混合使用。 先记录音频处理与文本校对是否需要同时驻留,再核对内存峰值和存储增长。若改成串行处理可满足期限,就不必为偶尔出现的并发峰值永久购买大量闲置资源;如果交付时间不允许串行,较大容量的价值才有了明确依据。

第三种:长上下文、多会话或大型模型工作。 明确可接受的排队、首 token 延迟和最低结果质量,再比较具体后端上的完整测试。硬件选择可能涉及大统一内存、专用显存、多卡或云端资源,但不能只按最大参数量排行。运行所需工具链、升级维护和失败时的替代方案,在这种工作里尤其重要。

这三个情境没有固定品牌答案。它们提供的是购买顺序:先确认软件与模型能完成任务,再补限制任务的容量和性能,最后处理便利性。若结果不可靠,升级不能替代验证;若流程已经可靠,升级则应当有可以测量的收益。

十、用一页验收记录,结束无休止的参数比较

测试前固定模型标识和文件版本、量化格式、上下文设置、软件版本、操作系统和电源模式。输入可以准备短、中、长三个实际会遇到的样本,另设一组预期并发。这里的目的不是建立公共跑分榜,而是让采购前后的差异具有解释力。

记录项 最少应该留下什么 它帮助排除的误判
身份与条件 模型版本、后端、精度、上下文、设备配置 其实换了模型或设置,却归因于硬件
冷启动 从未加载状态到首个可用结果的时间 把常驻缓存的成绩当作首次体验
稳态 新输入的首 token、生成速度、总时间 只看 token/s,忽略长输入等待
资源 峰值内存、显存、磁盘空间、并发数 只验证了最小任务或单用户
结果质量 同一检查清单中的错误与人工修正时间 用更差结果换快,却称作净提升
异常 断连、失败、降速、重试及版本信息 只展示成功运行的一次

对重要任务,重复几次并说明差异,比只留下最快值更可信。温度、后台任务和缓存状态不同,结果自然可能波动。无法控制的条件应记录下来;不要为了数字好看,悄悄删掉失败样本或把重试时间移出总耗时。

验收也要有结束条件。比如“最长常见材料能完成、关键数字检查通过、连续三次没有断连、总耗时低于工作期限”。满足之后,就可以使用设备,而不是因为网上又出现一个更高峰值不断重做采购决定。没有结束条件的比较,会把节省时间的目标变成新的时间消耗。

这份记录还会帮助下一次升级。模型更新后变慢,你能检查是输入更长、缓存设置改变、后端回退还是任务变复杂;设备换代时,你有自己的工作基线。相比从陌生人的一句“非常流畅”重新开始,这些记录更接近你真正购买的东西。

十一、产业正在提供更多选择,预算仍应追随工作

Apple、NVIDIA 等公司的规格说明,容量、带宽与软件集成正在形成不同产品路径。它们让个人能够接触过去难以在桌面上容纳的工作,也让选型更加复杂:一个维度明显领先,不能消除其他维度的约束。

供应商会展示自己有优势的指标,读者则需要把它们还原成任务时间、质量、运行边界和总支出。本文所有算式都可以替换输入重新计算。你可以不同意假设的工作频率、时间价值或模型规模,只要把不同的数字放进去,结论就能跟着变化。

最后把购买要求缩成一段具体的话:“我要在这台电脑上,用这个版本的模型处理这种长度的材料,同时允许几个任务;希望在多久内交付、接受怎样的人工检查;新增设备最多花多少。”当这句话写得清楚时,SSD、内存、显卡和扩展坞才各自有了位置。

来源与方法

资料核对至 2026 年 10 月 5 日。本文没有进行设备实测,不提供购买价格或品牌性能排名。权重表为理想存储载荷;缓存表限定为 Qwen3-8B 配置下的假设缓存方式;任务时间和设备支出均为示例。GB 使用十进制,GiB 使用二进制,避免混算。