研路炼钢 | Jetson 的 8GB 到底算内存还是显存？和 Mac 对照后，我终于想明白了
研路炼钢 | Jetson 的 8GB 到底算内存还是显存？和 Mac 对照后，我终于想明白了
统一内存省掉了 CPU 和 GPU 之间的一部分数据搬运，但没有凭空多出一块显存。Jetson 标称的 8GB，不是“8GB 内存再加 8GB 显存”，而是整台机器共同争抢的一笔预算。
前几天我在看 Jetson Orin Nano 8GB 的资源状态，脑子里一直有一个很朴素的问题：这台机器写着 8GB 内存，GPU 跑模型时，到底还有没有自己单独的一块显存？
这个问题之所以容易绕，是因为我平时同时在用 Mac 和带独立显卡的机器。Mac 经常说“统一内存”，显卡机器又习惯把系统内存和显存分开算。把这几套经验直接套到 Jetson 上，很容易得到一个错误预期：系统还有 5GB 可用，GPU 应该还能再拿出一块显存。
我把一次空载采样、官方内存架构说明和本地模型的实际占用逻辑放在一起看后，才真正想明白：看一台边缘设备能不能跑模型，不能只看包装盒上的容量，必须看任务启动前后，公共内存池里还剩多少预算。
01｜我一直把“内存”和“显存”想成两个账户
在传统台式机上，这种理解大体没问题。
CPU 使用主板上的系统内存，独立 GPU 使用显卡上的显存。一个模型从 CPU 侧准备好数据，再搬到 GPU 显存里计算。两个账户彼此独立，所以我们会同时问“电脑有多少内存”和“显卡有多少显存”。
Jetson Orin Nano 不是这种结构。
它把 CPU、集成 GPU、DLA 和部分多媒体单元放在同一颗 SoC 上，共享同一块 LPDDR5 物理内存。系统标称的 8GB，既要承担 Linux、桌面和普通进程的开销，也要装模型权重、推理运行时和 GPU 计算缓存。
所以正确的账本只有一本：
1 | 8GB 总预算 |
某一项多拿一点，其他项就少一点。这里不存在另一张可以继续透支的“8GB 显存卡”。
02｜空载还有 5.5 GiB，才是这台机器真正的起跑线
我在 2026 年 8 月 3 日晚上做了一次资源采样。当时 Ollama 服务已经启动，但没有加载模型；GPU 占用是 0%，CPU 总占用大约在 0% 到 4% 之间。
这时系统可见内存约为 7.4 GiB，已经使用约 1.7 GiB，可用约 5.5 GiB。GNOME Shell、GNOME Software、Xorg、JupyterLab 和 Docker daemon 等常驻进程，都在安静地分这笔预算。芯片温度约 55 到 56℃，整机功耗约 5.3W。
这组数据不是性能基准，只是这台设备、这个系统环境下的一次空载快照。但它比包装盒上的 8GB 更接近真实起点：模型还没加载，预算已经先被系统和服务拿走了一部分。
系统为什么显示 7.4 GiB 而不是完整的 8 GiB？一部分来自十进制 GB 和二进制 GiB 的换算差异，另一部分来自系统与硬件保留。看到这个数字并不意味着内存“丢了”。
设备还有约 11 GiB Swap，当时使用量为 0。但 Swap 只能在内存压力下暂存部分 CPU 内存页，速度远低于物理内存，也不能被理解成给 GPU 增加了 11 GiB 高速显存。把模型硬塞进去并不等于它能稳定、低延迟地运行。
NVIDIA 的 CUDA for Tegra 文档也明确说明，Tegra 上的 device、host 和 unified memory 最终都落在同一块 SoC 物理 DRAM 上。统一的是物理内存池，不是无限的可用容量。
03｜Mac 也用统一内存，但“原理相似”不等于“体验相同”
把 Jetson 和 Mac 放在一起看，最容易理解统一内存。
Apple Silicon 同样让 CPU、GPU 和神经网络引擎访问一个统一的物理内存池。Apple 对 M1 的官方说明强调的核心收益，也是不同计算单元可以访问同一份数据，减少在多个内存池之间复制。苹果在 WWDC 的架构讲解里也展示了 CPU 与 GPU 共享资源、避免经由 PCIe 来回搬运的思路。
所以从高层概念看，两者很像：
| 对比项 | Jetson Orin Nano | Apple Silicon Mac |
|---|---|---|
| 传统独立显存 | 没有 | 没有 |
| 内存使用者 | CPU、GPU、DLA 等 | CPU、GPU、神经网络引擎等 |
| 主要生态 | CUDA、TensorRT、JetPack | Metal、Core ML、macOS |
| 常见场景 | 机器人、视觉与边缘 AI | 开发、创作与本地 AI |
但“都是统一内存”不能推出“同样容量就有同样体验”。内存带宽、缓存与一致性规则、系统预留、推理框架、量化方式和算子支持都会影响最终表现。Jetson 更强调 CUDA 和边缘部署链路，Mac 更深地绑定 Metal、Core ML 与桌面系统。
统一内存只回答了“数据放在哪里”，没有替我们回答“这个模型跑得多快、能开多长上下文、能不能同时跑三套服务”。
04｜跑本地模型前，我现在先做一张内存预算表
以前我判断模型能不能跑，第一反应是看量化后的模型文件有多大。现在我知道，这个数字只代表了账单中的一项。
模型真正运行时，还要同时容纳推理框架、CUDA 上下文、中间张量、KV Cache、系统服务和输入输出模块。上下文越长，KV Cache 越大；如果再同时跑语音识别、语言模型和语音合成，三套运行时会一起进入同一个内存池。
按照这次空载约 5.5 GiB 可用内存的快照，我会把 1B 到 4B 的量化模型视为更稳妥的起点。7B 的低比特量化模型可能能够启动，但可用上下文、并发能力和稳定余量都会更紧。这里不能只问“能不能跑起来”，还要问“跑起来以后还有没有余地”。
我现在会按这个顺序做部署：
- 先记录空载时的 CPU、GPU、内存、温度和功耗；
- 关闭暂时不用的桌面与后台服务，确认真实可用内存；
- 估算模型权重、推理运行时和 KV Cache，而不是只看模型文件；
- 先加载单一模型，再逐个加入视觉、语音或其他服务；
- 观察峰值和持续占用，并给系统留下安全余量。
这个流程看起来比“直接启动模型”麻烦一点，但它能更早暴露问题：究竟是容量不够、上下文太长、后台服务太多，还是模型和硬件生态没有匹配好。
写在最后｜统一内存减少的是搬运，不是约束
这次把 Jetson 和 Mac 放在一起对照，我最大的收获不是记住了一个硬件概念，而是改掉了一种很常见的估算方式。
标称参数适合做第一轮筛选，运行快照才决定具体方案。8GB、16GB 或 24GB 只是总盘子；系统拿走多少、模型权重占多少、上下文缓存长到什么程度、还要并发哪些服务，才决定项目最后能不能稳定落地。
统一内存的优势是真实的。它减少复制，让 CPU、GPU 和加速单元协作得更直接。但工程里没有免费的容量：少了一次搬运，不代表多了一块内存。
以后再判断一台设备能不能跑某个模型，我不会先问“它标了多少 GB”，而会先问“任务启动以后，还剩多少可以验证的预算”。
研路炼钢，记录一个计算机研究生的真实成长。
