# 本地 AI 升级账本：容量、带宽、上下文与完整任务成本 Canonical: https://growthyoung.com/blog/usb-c-hub-display-compatibility Author: 策略研究室（个人独立研究） Published: 2026-10-05 Updated: 2026-10-05 用 Qwen 模型配置、Apple 与 NVIDIA 的官方规格，算清权重、KV 缓存和并发的内存需求；再把 SSD、扩展坞、人工复核放进完整流程，判断升级究竟节省了什么。 ---

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

## 一、把“我要用 AI”改成一份任务说明 {#workload} 先写下你要处理的材料、希望得到的结果、多久做一次、最晚何时需要完成。两千字文章的润色、一小时录音转写后校对、几十份报告的检索问答、同时运行多个编码会话，对硬件提出的问题并不相同。仅凭一个模型名字或者“AI 电脑”标签，无法给这些任务排预算。 还要定义结果怎样算合格。录音里的姓名是否必须准确，报告里的数字是否必须附出处，代码是否必须通过已有测试？模型输出速度是过程指标，合格结果才是用途。如果更快的生成带来更多人工复核，采购收益可能被后面的工作抵消。 一个适合用来测试的任务说明可以是：“每周处理四段一小时中文访谈，先转写，再用本地文本模型校对术语，最后由人核对人物和数字；希望每段在两小时内完成。”这里的频率和期限是假设，但已经足以让我们追问：音频模型与校对模型是否同时驻留？是否批量处理？人工核对占多少时间？ | 阶段 | 要观察的现象 | 首先相关的资源 | | --- | --- | --- | | 获取与保存 | 下载失败、文件放不下、版本重复 | 网络、磁盘容量、目录管理 | | 加载 | 首次启动久、频繁换模型久 | 存储读取、反序列化、内存与设备传输 | | 处理输入 | 长材料迟迟没有第一个输出 | 提示词处理、计算、上下文与缓存 | | 生成 | 已开始回答，但逐字输出慢 | 模型计算、内存带宽、软件实现 | | 并发与排队 | 单个任务正常，多任务失速 | 总内存、调度、共享资源和队列 | | 交付 | 文本很快生成，却需要大量返工 | 任务设计、模型适配和人工验证 | 将一个任务分成阶段后，很多购买建议就可以检验了。“换 SSD 会快”必须说清是下载、加载还是生成；“加内存就好”必须说明瓶颈是总量不足，还是每秒能读出的数据不够。没有阶段边界的快慢描述，很容易变成不同人各自说着正确但不相干的话。
本地 AI 从文件到加载、处理输入、生成、复核交付的阶段链，存储、内存、计算和人工分别影响不同阶段。本地 AI 任务的五阶段排查路径及各阶段要记录的时间。
图 1｜任务分解框架，属于分析示意。记录每一阶段的时间，比只记录一个 token/s 更接近最终体验。
## 二、权重文件只是内存预算的起点 {#weights} 可以先用一个理想化公式理解模型规模：权重字节数约等于参数数量乘以每参数位数，再除以 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 显卡。权重本身已经接近这个名义容量，缓存和临时区还没有位置；不同量化格式的真实占用又不同。较稳妥的做法是查具体模型版本和后端，记录加载后以及长输入时的峰值，而不是在采购时把剩余空间假设成零。 量化还需要验收结果质量。文件变小与任务可用，是两个判断。对访谈转写后的术语纠错，可以准备姓名、产品型号、时间和数字密集的样本，检查更低精度是否影响这些关键点；对代码任务，测试通过率比几段看起来流畅的输出更有说服力。 混合专家模型又引入一种不同的误读：每步激活的参数量影响计算工作，但通常不能直接替代全部权重的存放需求。要判断内存，仍需查看总权重和具体的加载、卸载机制。只看到较小的“激活参数”数字就决定显存容量，可能从第一步就算错了账。 ## 三、上下文与并发，会把一个能运行的模型推到容量边界 {#context} 长对话需要保留供后续生成使用的状态。对于常见 Transformer 注意力结构，可以用一个明确限定的例子看出量级。Qwen3-8B 的公开配置列出 36 层、8 个 KV 头、每头维度 128；这里只讨论普通全长、未量化、每元素 2 字节的 K/V 缓存，且单个会话、不共享前缀。[Qwen 官方配置](https://huggingface.co/Qwen/Qwen3-8B/blob/main/config.json)。 计算公式是：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 之间搬运状态，量化缓存也可能改变延迟表现。[缓存策略文档](https://huggingface.co/docs/transformers/en/kv_cache)。这说明节省内存可以交换出额外工作，不能把所有省内存选项都当作免费提速。 Ollama 的文档则指出，上下文增加会提高内存需求，并可用 `ollama ps` 检查分配；其 FAQ 说明并发会话会增加上下文相关内存。[上下文文档](https://docs.ollama.com/context-length)、[并发说明](https://docs.ollama.com/faq)。这些是版本相关的行为，使用时应记录当前版本和实际设置，不照抄别人一年前的默认值。 在访谈例子里，一种可检验的选择是分段校对并保留必要的术语表，而不是每次都把全部历史重新塞入上下文。但分段会损失跨段信息，需要额外设计人名一致性和合并检查。省下内存的同时，如果增加大量人工回看，就应把这部分代价写进预算。 多人共用设备时，还要定义排队规则。一个单会话测试通过，并不意味着四个人同时请求也能维持相同延迟。测试至少应覆盖普通输入、最长常见输入，以及预计的同时请求数。否则购买时确认的只是实验室里最舒服的时刻。 ## 四、Apple 与 NVIDIA 的规格，揭示了三种不同取舍 {#hardware} 下面不是推荐榜单，也不比较当前售价，而是用官方可核验的数据说明容量与带宽为何必须同时看。完整系统、集成芯片平台和独立显卡的成本边界不同，不能把一张显卡的价格与一台整机直接对齐。 | 代表配置 | 公开容量和带宽 | 对预算问题的启发 | | --- | --- | --- | | 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 技术规格](https://support.apple.com/en-us/122211)、[DGX Spark 官方规格](https://www.nvidia.com/en-us/products/workstations/dgx-spark/)、[NVIDIA Blackwell 白皮书，第 15 页](https://images.nvidia.com/aem-dam/Solutions/geforce/blackwell/nvidia-rtx-blackwell-gpu-architecture.pdf)。以上为厂家规格，并非本文实测；不同架构的“带宽”数字不可直接兑换成相同比例的 token/s。
三种代表配置的容量与名义带宽对照：M3 Ultra256GB与819GB每秒，DGX Spark128GB与273GB每秒，RTX5090显存32GB与1792GB每秒。容量和带宽分为两个面板比较，不合成性能评分。
图 3｜官方规格的两轴对照。统一内存与专用显存的使用范围不同；图中没有价格、实际可分配容量或任务速度排名。
这些规格对应着不同的客户需求。有人需要将较大的模型与工作集留在一台机器里；有人愿意把模型压到较小容量中，优先追求吞吐；有人更在意已有软件栈能否直接运行。容量、带宽、软件和系统集成，是几种可以分别收费的能力。评价产品竞争力时，也就不能只围绕一个最大值排队。 对用户，问题于是变成：自己的任务首先撞到哪堵墙？如果权重和缓存无法容纳，再高的纸面带宽也不能替代缺少的空间。如果模型已经稳定驻留，则继续购买未使用的容量，未必改善生成时间。若必需的软件缺少相应后端，优秀的硬件规格也可能暂时用不上。 “统一内存”需要同样具体地理解。它描述某种访问和组织方式，不代表操作系统不占空间，不代表所有框架都能自由使用标称总量，也不代表它与专用显存拥有相同延迟、带宽或软件优化。购买前仍应核对可用的后端、版本、模型格式和实际分配。 多卡扩展也不应只看显存相加。模型如何分片、卡与卡之间如何通信、主板插槽带宽、电源和散热，都会进入结果。Ollama 对跨 GPU 加载的说明就强调了数据转移的影响。若没有同一模型和任务的验证，把两块卡视为一块双倍容量且双倍速度的卡，是把计算图最重要的部分省略了。 规格还有时间边界。发布新闻、历史配置和当前支持页可能不完全一致，地区与在售组合也可能不同。本文采用上表核查时可见的明确配置，并未调查当地库存。采购时应保存具体报价与完整配置，不能仅凭文章里的一个最大值下单。 ## 五、带宽能给出一个边界，不能给出完整跑分 {#bandwidth} 对于某些单会话、自回归、稠密模型的生成阶段，可以建立一个极简模型：如果每生成一个 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 很重要，但需要说明它在哪个阶段重要 {#storage} 磁盘空间不足时，更大 SSD 直接解决文件容纳问题；频繁切换大型模型时，读取和加载路径可能影响等待；长期驻留的生成任务，则需要证明磁盘访问确实进入了瓶颈，才能把更快 SSD 的费用归因到输出速度。 操作系统交换空间、框架权重卸载和 KV 缓存卸载，也不是同一个机制。它们移动的数据、触发条件和访问粒度不同。把“软件可以使用磁盘”概括成“SSD 能当同速显存”，省略了最关键的速度差异和实现约束。实际能否接受，应由完整任务测试回答。 一个可以直接观察的实验是：固定模型版本、上下文和输入，记录第一次加载时间；在模型保持驻留时再次提交不同但相近长度的任务，分别记录生成时间。然后改变模型文件所在存储，重复同样条件。若改善主要出现在加载，结论就应限定为加载收益，而不是宣称模型整体性能翻倍。 外置存储还带来运维上的小问题。路径是否稳定挂载，休眠后是否仍可用，后台服务是否有读写权限，拔下设备时程序怎样处理？Ollama FAQ 中的 `OLLAMA_MODELS` 可以指定模型存放位置，但路径改好并不自动解决这些条件。[模型存储说明](https://docs.ollama.com/faq)。在日常使用中，一次不可预期的断连可能抵消很多次快几秒的加载。 存储价格的产业背景也值得分开看。AI 数据中心对存储的采购，与个人本地推理的硬件需求并不一一对应。前者可能推高某类供应的重要性，后者仍要按实际工作选择容量。关于公司数据、零售价格传导和容量预算，见[AI 存储涨价与 SSD 购买判断](/blog/portable-ssd-interface-capacity-workflow)。 ## 七、扩展坞的价值要放进整条连接路径 将电脑、扩展坞、线材和 SSD 连起来之后，限制不再只属于某一个产品。一个扩展坞标有多个高速数据口，也不代表所有口在同时工作时都能独占同等上行带宽。需要核对的是主机端、上行连接、各下行端口与共享关系。 | 连接项目 | 购买前记录什么 | 验收时检查什么 | | --- | --- | --- | | 主机端口 | 完整电脑型号、端口对应协议 | 系统识别的连接方式，直连基线 | | 扩展坞上行和数据口 | 上行速率、下行规格、共享条件 | SSD 单独使用与同时接其他设备的差别 | | 线材 | 数据速率与供电能力分别核对 | 换用符合规格的线是否改变结果 | | 外接显示器 | 分辨率、刷新率、独立扩展需求 | 每块屏的实际模式与稳定性 | | 主机供电 | 充电器、坞的主机输出功率、线材条件 | 真实工作负载下能否维持充电和稳定连接 | USB-IF 的线材说明区分数据能力与供电标识，PD 协议能力也不能代替每台设备的实际功率。[线材说明](https://compliance.usb.org/index.asp?Format=Standard&UpdateFile=Cables+and+Connectors)、[USB PD 说明](https://www.usb.org/usb-charger-pd)。商品页写 100W 输入时，还应找到它实际能给主机提供多少；缺少这条信息，就不应自行把两个数字视为一样。 显示器则要核对具体电脑和连接方式。Apple 的说明要求按 Mac 型号、显示器数量和模式判断支持情况。[Apple 显示器连接说明](https://support.apple.com/en-ie/102555)。两个 HDMI 插口并不能独立证明两块屏一定可以扩展；依赖驱动的方案还涉及系统支持、安装权限与更新维护。 最有信息量的验收通常很简单：同一个文件集、同一块盘，先直连，再经过扩展坞，分别记耗时与异常；然后增加第二个共享设备，看看变化是否符合预期。不要同时换线、换盘、换文件又更新系统，否则差异无法归因。 扩展坞可以带来整洁、插拔便利和端口集中，这些价值完全合理，只是应与模型运行性能分开记账。如果直连已经满足工作速度，可以为便利付费；没有证据时，不应把这笔便利支出包装成 AI 性能升级。 ## 八、完整任务成本，往往会改变升级顺序 {#cost} 下面沿用访谈工作流，设定两个纯假设的方案。每次都得到符合相同质量要求的一份结果，软件费用暂相同。原流程花 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 延迟和最低结果质量，再比较具体后端上的完整测试。硬件选择可能涉及大统一内存、专用显存、多卡或云端资源，但不能只按最大参数量排行。运行所需工具链、升级维护和失败时的替代方案，在这种工作里尤其重要。 这三个情境没有固定品牌答案。它们提供的是购买顺序：先确认软件与模型能完成任务，再补限制任务的容量和性能，最后处理便利性。若结果不可靠，升级不能替代验证；若流程已经可靠，升级则应当有可以测量的收益。 ## 十、用一页验收记录，结束无休止的参数比较 {#test} 测试前固定模型标识和文件版本、量化格式、上下文设置、软件版本、操作系统和电源模式。输入可以准备短、中、长三个实际会遇到的样本，另设一组预期并发。这里的目的不是建立公共跑分榜，而是让采购前后的差异具有解释力。 | 记录项 | 最少应该留下什么 | 它帮助排除的误判 | | --- | --- | --- | | 身份与条件 | 模型版本、后端、精度、上下文、设备配置 | 其实换了模型或设置，却归因于硬件 | | 冷启动 | 从未加载状态到首个可用结果的时间 | 把常驻缓存的成绩当作首次体验 | | 稳态 | 新输入的首 token、生成速度、总时间 | 只看 token/s，忽略长输入等待 | | 资源 | 峰值内存、显存、磁盘空间、并发数 | 只验证了最小任务或单用户 | | 结果质量 | 同一检查清单中的错误与人工修正时间 | 用更差结果换快，却称作净提升 | | 异常 | 断连、失败、降速、重试及版本信息 | 只展示成功运行的一次 | 对重要任务，重复几次并说明差异，比只留下最快值更可信。温度、后台任务和缓存状态不同，结果自然可能波动。无法控制的条件应记录下来；不要为了数字好看，悄悄删掉失败样本或把重试时间移出总耗时。 验收也要有结束条件。比如“最长常见材料能完成、关键数字检查通过、连续三次没有断连、总耗时低于工作期限”。满足之后，就可以使用设备，而不是因为网上又出现一个更高峰值不断重做采购决定。没有结束条件的比较，会把节省时间的目标变成新的时间消耗。 这份记录还会帮助下一次升级。模型更新后变慢，你能检查是输入更长、缓存设置改变、后端回退还是任务变复杂；设备换代时，你有自己的工作基线。相比从陌生人的一句“非常流畅”重新开始，这些记录更接近你真正购买的东西。 ## 十一、产业正在提供更多选择，预算仍应追随工作 Apple、NVIDIA 等公司的规格说明，容量、带宽与软件集成正在形成不同产品路径。它们让个人能够接触过去难以在桌面上容纳的工作，也让选型更加复杂：一个维度明显领先，不能消除其他维度的约束。 供应商会展示自己有优势的指标，读者则需要把它们还原成任务时间、质量、运行边界和总支出。本文所有算式都可以替换输入重新计算。你可以不同意假设的工作频率、时间价值或模型规模，只要把不同的数字放进去，结论就能跟着变化。 最后把购买要求缩成一段具体的话：“我要在这台电脑上，用这个版本的模型处理这种长度的材料，同时允许几个任务；希望在多久内交付、接受怎样的人工检查；新增设备最多花多少。”当这句话写得清楚时，SSD、内存、显卡和扩展坞才各自有了位置。 ## 来源与方法 资料核对至 2026 年 10 月 5 日。本文没有进行设备实测，不提供购买价格或品牌性能排名。权重表为理想存储载荷；缓存表限定为 Qwen3-8B 配置下的假设缓存方式；任务时间和设备支出均为示例。GB 使用十进制，GiB 使用二进制，避免混算。 - 模型与软件：[Qwen3-8B 配置](https://huggingface.co/Qwen/Qwen3-8B/blob/main/config.json)、[Hugging Face 缓存策略](https://huggingface.co/docs/transformers/en/kv_cache)、[Ollama 上下文](https://docs.ollama.com/context-length)、[Ollama FAQ](https://docs.ollama.com/faq)。 - 公司规格：[Mac Studio 2025](https://support.apple.com/en-us/122211)、[DGX Spark](https://www.nvidia.com/en-us/products/workstations/dgx-spark/)、[NVIDIA Blackwell 白皮书](https://images.nvidia.com/aem-dam/Solutions/geforce/blackwell/nvidia-rtx-blackwell-gpu-architecture.pdf)。 - 连接规范：[USB-IF 线材](https://compliance.usb.org/index.asp?Format=Standard&UpdateFile=Cables+and+Connectors)、[USB PD](https://www.usb.org/usb-charger-pd)、[Mac 显示器支持](https://support.apple.com/en-ie/102555)。 - 阅读时间按正文中文约每分钟 350 字估算，图表与计算复核另需时间。