32GB 显存，凭什么跑 56GB 大模型？从 Shared Memory 到 AI 异构内存架构

从 Shared GPU Memory、CPU Offload 到 GGUF，看懂消费级硬件如何突破显存限制。

作者：吴佳浩（Alben）

撰稿时间：2026.7.28

更新时间：2026.8.1

前几天，一位读者问了我一个问题。

Qwen3.6-27B 的 FP16 权重，算下来大概需要 54~56GB 的存储空间，我的 RTX5090 只有 32GB 显存，为什么还能跑？

更奇怪的是，Windows 任务管理器里，GPU Memory 居然显示：

vbnet 复制代码

Dedicated：31.5GB
Shared：46.8GB
GPU Memory：78.3GB

难道我的 RTX5090 一夜之间变成了 78GB 显存？

当然不是。

今天，我们就来拆开这个很多 AI 开发者第一次接触时容易误解的问题。

一、32GB 显存，为什么能跑 56GB 模型？

这条消息发到群里，出现了五种答案：有人说是量化，有人说是 Windows 自动扩容显存，有人说 RTX5090 有隐藏显存，有人说其实是内存交换、慢到没法用，还有人干脆觉得是驱动虚标。

这五种答案，没有一个完全对，但每一个都摸到了真相的一角。 这里先纠正一个常见误解：模型权重的存储体积，不等于推理实际占用的显存。除了权重本身，还有 KV Cache、激活值（activation）、CUDA kernel 运行时工作区，以及 allocator 本身的碎片开销------所以 54~56GB 只是权重的"底价"，实际推理时通常需要更多。这也是为什么 32GB 显存"差得更多"，而它依然能跑起来，就更值得深挖了。

真正的答案，不是 Shared GPU Memory 这一个机制，而是现代 AI 推理框架已经开始支持异构内存管理------量化、CPU Offload、GGUF 的层级卸载，这几种机制共同让模型突破了单卡显存的物理限制，Shared GPU Memory 只是其中一种、也是 Windows 用户最容易在任务管理器里"亲眼看到"的一种。

具体拆开看，让 Qwen3.6-27B 在 32GB 显卡上真正跑起来的，通常是下面几种情况的组合：

情况一：量化。 FP16 权重 27B × 2 字节 ≈ 54GB；量化到 Q4 之后，27B × 0.5 字节 ≈ 13.5GB，直接就能塞进显存，压根用不上 Shared Memory。

情况二：CPU Offload。 用 Transformers 的 device_map="auto"，框架会自动把权重拆成两部分，比如 GPU 上放 20GB 的层，剩下 34GB 的层放到 CPU 内存里，需要时再传给 GPU 计算。

情况三：GGUF / llama.cpp。 主动用 -ngl 40 这样的参数，手动指定放进 GPU 的层数，其余层留在 CPU，权重常驻 DDR5。

这三种情况，任何一种（或几种叠加）都可能是你看到"模型能跑"背后的真实原因，Shared GPU Memory 只是 Windows 系统层面的一种资源统计和调度方式，并不是所有 CUDA 程序都会主动利用它------PyTorch 的 CUDA Tensor 默认不会自动"溢出"进系统内存，CUDA OOM 之前也不会自动把显存内容迁移过去。这一点很重要，下一章会具体展开。

这里还要提前避开一组容易混淆的概念------而且不止一个，一共有三个名字里都带"共享/统一"字样、但完全不同的东西。除了前面提到的 Windows Shared GPU Memory 和 CUDA Unified Memory，很多 CUDA 开发者第一次看到"Shared Memory"这个词，脑子里冒出来的其实是第三个：CUDA kernel 编程里的那个 Shared Memory。三者放在一起看会更清楚：

名称	所属层级	作用
CUDA Shared Memory	GPU 片上高速 SRAM	同一个 kernel 内，线程块（thread block）之间共享数据，用来加速计算
CUDA Unified Memory	NVIDIA 编程模型（`cudaMallocManaged`）	让 CPU 和 GPU 共用同一段虚拟地址空间，由驱动自动做数据迁移
Windows Shared GPU Memory	Windows WDDM	把一部分系统内存划给 GPU 用，任务管理器里能看到的那个数字

三者分属三个完全不同的层级：CUDA Shared Memory 是 GPU 芯片内部的一块缓存，快到夸张，但容量很小（每个 SM 通常只有几十到上百 KB）；CUDA Unified Memory 是编程模型层面的抽象，需要开发者主动调用相应 API；Windows Shared GPU Memory 是操作系统层面的资源调度，跟前两者都没有直接关系。本文接下来讲的，是最后这一个------任务管理器里看到的那个 Windows Shared GPU Memory。

要理解这件事，第一步是搞清楚：显存装不下的那部分，到底去哪了。

二、模型到底放哪了？（Shared GPU Memory）

先分清两个完全不同的东西：

Dedicated（独立显存）：真正焊在显卡上的 GDDR7，物理上就是 32GB，一颗晶体管都不会多。
Shared（共享显存）：不是显存，是操作系统从你电脑的系统内存 DDR5 里，临时"借"给 GPU 用的一块区域。

这里要先纠正一个容易被过度简化的说法：不是"56GB 权重被精确切成 32GB 和 24GB 两半"。实际情况取决于推理框架、CUDA allocator、驱动版本、Windows WDDM 的调度策略，以及是否启用了 CPU Offload------具体哪些数据留在显存、哪些落到系统内存，是动态决定的，不是一次性的静态切分。更准确的说法是：

在显存不足的情况下，部分模型权重、激活值或运行时数据可能会落到系统内存，由 GPU 通过 PCIe 访问。

这里要特别强调一点：它不是把系统内存变成了显存，而是 GPU 获得了一块它可以访问的系统内存资源。当 GPU 显存不足时，部分数据可以驻留在系统内存里，由驱动负责调度访问------这和"32GB 显存 + 46GB 系统内存 = 78GB 显存"完全是两回事，后者是任务管理器数字相加造成的错觉，前者才是真实发生的事情。用图示意大致是这样：

markdown 复制代码

Qwen3.6-27B  ≈56GB（FP16 原始精度）

        ↓ 按需分布

GPU 显存（GDDR7）  +  系统内存（DDR5）

超出显存容量的那部分，并没有消失，而是被 Windows 的显示驱动模型（WDDM）映射到了系统内存里，GPU 可以通过 PCIe 访问这块区域------注意，是"访问"，不是"当成显存用"，这个区别在第四章会决定你的推理速度快还是慢。

打个比方：这和电脑内存不够时，操作系统把一部分硬盘空间当"虚拟内存"用，思路上有相似之处。但严格来说，Shared GPU Memory 不等于显存的虚拟内存 ------它是 WDDM 的一种资源管理机制，更准确的理解是：GPU 内存体系里的一层"扩展容量层"，本质上是 GPU 可以访问的系统内存区域，而不是简单的显存换入换出。

这块"借来的"内存，上限是多少？Windows 默认允许 GPU 借用系统内存的约一半：

RAM	Shared GPU Memory（通常）
32GB	≈16GB
64GB	≈32GB
96GB	≈48GB
128GB	≈64GB
192GB	≈96GB
256GB	≈128GB

内存越大，能借的越多。

到这里，可以把整套体系画成一张总图------这也是理解本文后面所有内容的"底图"：

图里四个角色，分工很清楚：GPU 负责高速计算，DDR 负责扩展容量，PCIe 负责数据传输，CPU 负责调度与部分计算。 这四者共同构成了一套"异构内存系统"，后面几章讲的 OOM、速度下降、GGUF vs vLLM、DDR5 涨价，本质上都是这张图里某一个环节在起作用。

顺着这张图，还可以提炼出一个更直接的判断标准------大模型能不能部署、部署得好不好，看的从来不是单一的显存容量：

可用模型容量＝ GPU 显存＋系统内存＋ Offload 能力＋带宽

推理速度 ≈ GPU 计算能力 × 内存访问效率 × 数据传输效率

前一个公式决定了"能不能跑"，后一个公式决定了"跑得快不快"。记住这两行，后面几章的内容基本都是在给这两个公式里的每一项做展开。

这也直接引出一个衍生问题：既然容量是"拼凑"出来的，为什么这一路"借"下去，程序没有崩溃？

三、为什么没有 OOM？

正常来说，显存不够，程序应该直接报错 CUDA out of memory。这个流程在传统 CUDA 推理里是这样的：

复制代码

GPU 显存不足
   ↓
cudaMalloc 分配失败
   ↓
OOM

它不会自动变成"GPU 显存不足 → 迁移到 Windows Shared Memory → 继续运行"------这条路径在纯 CUDA 语境下并不存在。

要把话说准确：对于支持 Offload 的框架（比如 GGUF/llama.cpp，或者用了 device_map="auto" 的 Transformers），显存不足不一定意味着失败，框架可以主动把部分权重或计算转移到 CPU 内存；但对于完全依赖 GPU 驻留的推理框架（vLLM、TensorRT 默认配置），显存不足依然会直接 OOM。这也是为什么"能不能跑"这件事，从来不是一句"内存够大就行"能概括的，还要看具体用的是哪个框架、有没有主动做 Offload。

换句话说，这套机制在生效的场景里，把"装不下就报错"，改写成了"装不下就降速"。对于用 GGUF/llama.cpp 这类天然支持异构计算的框架做本地部署的开发者来说，这是巨大的容错空间------你不需要在部署前精确计算显存够不够，只要内存够大，大概率都能跑起来；但如果你用的是 vLLM、PyTorch 默认配置这类以纯 GPU 计算为核心假设的框架，这份容错空间就不一定存在。

但这里有个陷阱："能跑"和"能用"是两回事。 如果借用比例太高，Token 速度可能慢到每秒两三个字。真正决定这台机器好不好用的，从来不是"能不能跑"，而是接下来要讲的------"慢多少"。

四、为什么速度会明显下降？

Shared Memory 不是显存，两者的速度差距是数量级的：

GPU 真正的显存：GDDR7，带宽在 TB/s 级别（RTX5090 显存带宽约 1.5-1.8 TB/s）。
Shared Memory：本质是 DDR5，带宽只有 GB/s 级别（双通道 DDR5-6400 约 100GB/s），路径还要多绕一层 PCIe。

GPU 每访问一次 Shared Memory 里的数据，都要多绕一圈：从 DDR5 出发，经过 PCIe 总线，才能到达 GPU 核心。这中间多出来的每一跳，都是延迟。打个比方，GDDR7 和 DDR5 的带宽差距，大约相当于市区骑自行车和高速公路开车的差距------理论上都能到目的地，但你会明显感觉到"这次怎么这么慢"。

把这件事画成一张层级图会更直观------AI 推理实际访问数据时，走的是一条从快到慢的层级链路：

层级越往下，带宽越低、延迟越高。性能下降的本质，不是容量增加，而是数据访问层级下降。 显存不够时，数据被迫从"快而小"的第二层，下沉到"慢而大"的第四层，容量问题解决了，但换来的是访问速度的代价。

所以规律很直接：Shared Memory 用得越多，意味着数据在更慢的层级上停留得越久，Token 速度也就掉得越多。

那有没有框架，一开始设计的时候就打算"擅长处理慢速内存"，而不是被动依赖 Windows 这套 Shared Memory 补丁？这就要说到全网很少讲透的一点------为什么同样是显存不够，有人说能部署，有人说直接崩了。

五、为什么 GGUF 能跑，而 vLLM 经常直接 OOM？

这是两种完全不同的设计哲学，也是"32GB 能不能跑 56GB"这件事最容易让人困惑的地方。

vLLM 的核心优化目标，是最大化 GPU 内的计算比例和吞吐 （配合 PagedAttention 高效管理 KV Cache），而不是像 llama.cpp 那样把"低显存设备也能跑起来"当作主要场景。说得更直接一点：vLLM 的目标不是"让任何模型跑起来"，而是在有限的 GPU 资源下，让大量并发请求获得最高吞吐。 这也是为什么同样一块 32GB 显卡，单用户场景下 llama.cpp 跑 10 tok/s 可能完全够用，但换成"每分钟 1000 个请求"的服务场景，vLLM 需要模型完整驻留显存才能达标------两者根本不是在同一个维度上竞争。它确实提供 cpu_offload_gb、swap_space、KV Cache Offload 等机制，并不是完全不能用系统内存兜底；但这些更多是"兜底选项"，而不是架构的核心设计目标。所以两者真正的区别，不是"能不能 Offload"，而是"设计目标不同"------vLLM 为服务端的高并发吞吐而生，默认思路是张量并行、更激进的量化、或缩小上下文；GGUF 为单机可用性而生，默认思路是把装不下的部分交给 CPU 继续算。这也是为什么显存明显不够时，vLLM 更容易直接报错退出。

这里有必要说清楚一件常被混淆的事：很多人争论"32GB 显卡能不能跑 50GB 模型"，其实双方说的根本不是同一件事------一方说的是"能启动并生成 Token"，另一方说的是"能否保持 GPU 满载、维持高吞吐推理"。 vLLM 面向的是后者，GGUF/llama.cpp 面向的更多是前者，这才是两边吵不到一起去的真正原因。

如果只用一句话概括两者的核心假设，会更清楚：vLLM 默认假设 GPU 是主要计算空间，GGUF 默认假设 CPU + GPU 是联合计算空间。两者最大的区别，从来不是有没有 Offload，而是谁把 Offload 当成核心能力。

再往深一层看，这个区别其实不是"GPU vs CPU"这么简单，而是一个更底层的设计问题：模型权重长期驻留在哪里（memory residency strategy）。

复制代码

vLLM：

Weight
  ↓
GPU HBM / GDDR
  ↓
Tensor Core


llama.cpp（GGUF）：

Weight
  ↓
DDR（系统内存）
  ↓
部分 Layer 常驻 CPU，部分 Layer 传输给 GPU
  ↓
GPU Compute

vLLM 的驻留策略是"权重只有一个家，就是显存"；GGUF 的驻留策略是"权重按层分家，一部分常驻 DDR，一部分常驻显存"。前者换来的是驻留位置单一、访问路径短、吞吐上限高；后者换来的是驻留位置灵活、能塞进更小的显卡，但访问路径变长了，也就是第四章讲的那条"层级下降"的代价。

而 GGUF（配合 llama.cpp）从设计之初，就是 GPU 和 CPU 共同完成推理 ，这不是"意外兼容"，而是从底层架构就为异构计算准备的。它有一个关键参数 -ngl（gpu-layers）：把模型的一部分层放进 GPU，剩下的层留在 CPU 上算，权重直接驻留在 DDR5 里------不需要依赖 Windows 的 Shared Memory 机制，也能实现类似的效果。这也是为什么很多人发现，手动用 llama.cpp 控制 -ngl，往往比"放任系统自动借用 Shared Memory"更稳定、更可控。

需要说得更精确一点：并不是每个 Token 都要把全部权重重新搬一遍------Transformer 推理实际访问的是当前层的权重、激活值和 KV Cache ，逐层进行。但在 CPU Offload 场景下，只要某一层被分到了 CPU，这一层的计算就需要频繁在 CPU 内存和 GPU 显存之间交换数据，PCIe 也就因此成为新的瓶颈。这条路径比 vLLM 那条纯 GPU 路径绕得多，但正因为它天生就把 CPU、DDR、PCIe 纳入了计算闭环，GGUF 才能在显存不够的情况下依然"优雅降级"，而不是直接报错。这才是"有人说能部署，有人说不能部署"这场争论背后的真正原因------他们用的根本不是同一套架构。

这里再补一句容易被混淆的点：量化和 CPU Offload 是两件独立的事，量化解决"模型本身能不能变小"，Offload 解决"变小之后还装不下时怎么办"，两者是叠加关系：

量化精度	27B 模型权重体积（约）	单卡 32GB 能否完全放下
FP16（原始精度）	≈54GB	否，必须依赖 Offload / 多卡
Q8_0	≈29GB	勉强，几乎不留 KV Cache 空间
Q4_K_M	≈16-18GB	可以，还能留出 KV Cache 空间

也就是说，"56GB 显存需求"通常指 FP16 原始精度。而绝大多数本地部署，其实是"量化到 Q4 左右 + CPU Offload/Shared Memory 兜底"这套组合拳------两层降级叠加，才让 32GB 显卡真正有了跑 27B 模型的可能。

把这一章的内容归拢一下，两者的设计哲学可以浓缩成这样一张对照：

vLLM

目标：最大化 GPU 利用率
假设：GPU 是主要计算设备
优化方向：Batch 批处理、PagedAttention、Tensor Parallel（张量并行）

llama.cpp（GGUF）

目标：最大化设备覆盖范围
假设：GPU 资源有限，需要和 CPU 协同
优化方向：Layer Offload、CPU Compute、量化

一句话概括：vLLM 解决的是"如何把一块大 GPU 用到极致"，llama.cpp 解决的是"如何让一块有限的硬件也能运行大模型"。 这两个问题看似都在回答"能不能跑"，其实从一开始就不是同一个问题。

既然 GGUF 要频繁访问 DDR5，一个自然的推论就来了：内存的快慢，是不是也开始变得重要了？

六、为什么 DDR5 和 192GB 内存越来越重要？

因为 GPU 一直在访问 DDR5，DDR 越快，Token 自然越高：

DDR4 双通道：约 50GB/s
DDR5-6400 双通道：约 100GB/s

这里需要说得更谨慎一点：如果模型能完全驻留在 GPU 显存里，DDR 速度对推理几乎没有影响；但在 CPU Offload 比例较高的场景，DDR 带宽会直接影响生成速度------更高的内存带宽通常会带来可感知的提升，但具体幅度取决于模型大小、Offload 比例、PCIe 版本和量化方式这几个变量的组合，不同平台上的差距可能很大，这里不给一个放之四海而皆准的固定百分比。

想验证，可以自己跑一下：

bash 复制代码

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-bench \
  -m ./models/qwen3.6-27b-q4_k_m.gguf \
  -ngl 40 \
  -p 512 -n 128 \
  -r 5

llama-bench 会输出 pp（prompt processing tokens/s）和 tg（token generation tokens/s），配合任务管理器观察 Shared Memory 占用曲线，就能直观看到"DDR 带宽 ↔ Token 速度"的关系。

⚠️ 下面两张表是综合公开评测和社区常见反馈整理出的典型区间，不同主板、BIOS 内存时序、量化版本、上下文长度都会让实测数字有明显差异。建议按上面命令在自己机器上实测，把真实数字替换进去。

以 27B、Q4_K_M 量化模型在 RTX5090 32GB + DDR5 平台上为例：

GPU Layers (-ngl)	Shared Memory 使用	趋势
全部层 GPU	极低	最佳性能
大部分层 GPU	较低	性能略降
GPU/CPU 混合	中等	性能明显下降
大部分层 CPU	很高	性能下降显著

不同内存平台的理论带宽差距，以及会放大或缩小这个差距的因素：

内存平台	理论双通道带宽	实际提升幅度的主要影响因素
DDR4-3200	≈50GB/s	基准
DDR5-6000	≈96GB/s	Offload 比例、PCIe 版本、量化精度、模型层数分布
DDR5-6400	≈102GB/s	同上，Offload 比例越高，带宽差距体现得越明显

除了频率，还有一个变量常被忽略：通道数。消费级平台大多是双通道，工作站平台（Threadripper、EPYC）能做到四通道甚至八通道，同样是 DDR5-6400，八通道理论带宽是双通道的 4 倍------这也是为什么重度本地部署的开发者，有时宁可放弃消费级 CPU 的高主频，也要换多通道平台。

这里还要纠正一个容易想岔的地方：CPU Offload 场景下，真正限制速度的通常不是 DDR 本身，而是 DDR 和 GPU 之间那座桥------PCIe。 数据要走完整条路径 CPU 内存 → PCIe → GPU，PCIe 这一段往往才是那个更窄的瓶颈：

链路	理论带宽
DDR5-6400 双通道	≈100GB/s
PCIe 5.0 x16（双向理论）	≈64GB/s

看这两个数字会发现，很多时候不是内存不够快，而是显卡和系统之间那条"桥"太窄------DDR5 本身能供得上的数据，PCIe 未必能及时搬过去。这也是为什么升级到 PCIe 5.0 平台、走满速 x16 通道，在重度 Offload 场景下的收益，有时候比单纯堆内存频率更直接。

内存越大，Shared Memory 可借用的上限越高；DDR5 带宽和通道数越高，CPU Offload 部分的 Token 速度越快------但 192GB 能成为个人开发者的"甜点配置"，原因并不只是 Shared Memory 这一件事。真正推动它的，是三股力量叠加：容量（模型还在持续变大，27B 只是起点，更大的 MoE 模型对系统内存的需求会更高）、带宽（前面讲的 CPU Offload 场景需要更快的 DDR，同时也要有匹配的 PCIe）、以及多任务并行 （开发者往往同时开着推理服务、向量数据库、IDE、浏览器一堆 Chrome 标签页，内存是会被同时抢占的）。内存，第一次同时决定了"能不能跑""跑得快不快""能不能同时干别的事"。

需要说清楚的是，个人 AI 工作站这股需求，推动的是高容量内存这个细分品类的需求增长，而不是决定整个 DDR5 市场的价格 ------DDR5 大盘价格背后有更多复杂因素，不是本文能一句话说清楚的财经问题。更准确的说法是：这也是为什么近年来 AI 工作站的配置思路，开始从单纯"堆 GPU"，转向"GPU + 大容量高速内存"这个组合。

七、32GB 显存，实际能跑什么？

前面六章讲了一整套原理，落到实处，很多读者最关心的还是一个具体问题：我这张 32GB 的卡，到底能不能跑某个模型？

以 RTX5090 32GB 为例，大致的参考情况是这样：

模型规模	精度	是否推荐
7B / 8B	FP16	完全没问题 ★★★★★
14B	FP16	可以 ★★★★
27B	Q4	非常适合 ★★★★★
27B	FP16	需要 Offload，能跑但吞吐会明显下降 ★★
70B	Q4	可以尝试，Offload 比例会比较高 ★★
70B	FP16	不现实，缺口太大 ×

⚠️ 这张表同样是参考区间，具体表现还要看上下文长度、KV Cache 占用、以及是否叠加了 Shared Memory/CPU Offload。

看这张表会发现一个规律：真正限制你的，从来不是"参数量"这一个数字，而是"模型精度 × 权重大小 × KV Cache × 推理框架"这四者的组合。 同样是 27B，Q4 量化下轻松愉快，FP16 原始精度下就得靠 Offload 硬撑；同样是 Offload，llama.cpp 和 vLLM 的表现又完全不是一回事------这也是为什么本文花了七章去拆这几个变量，而不是直接甩一句"看显存大小就行"。

八、为什么 AI 开发者仍然需要本地工作站？

DeepSeek、Qwen、Kimi 这些 API 已经很便宜了，为什么还要自己组一台本地机器？

如果你只是普通用户------聊天、办公、写代码、总结文档------直接用 API，一定比自己买机器划算，这点不需要犹豫。

但如果你是 AI 开发者，每天要调试 GGUF 的 Offload 比例、测试 vLLM、验证不同量化方案的效果差异，那么本地环境解决的不是"用 AI"，而是开发 AI。API 是黑盒，你只能看到输入输出，看不到"这一层放 GPU 还是 CPU 会怎样"------而这恰恰是本文一直在回答的问题。这不是"要不要买某款 CPU"的装机推荐问题，而是"要不要具备本地研发能力"的问题。如果预算允许，我会优先把预算放在内存上，而不是 CPU 主频，理由前面七章已经说得很清楚了。

九、为什么 Mac M 系列也能跑大模型？

讲到这里，经常会有读者问一个相关的问题："Mac 没有 NVIDIA 显卡，为什么 M3/M4 128GB 能跑 70B 模型？"

答案其实和前面八章的逻辑完全一致------都是在解决"显存不够用"这同一个根本问题，只是走了两条完全不同的技术路线。

Apple Silicon 用的是 统一内存架构（Unified Memory Architecture, UMA）：CPU、GPU、NPU 物理上共享同一块 LPDDR 内存，不存在"显存"和"系统内存"这两个独立的概念，自然也就不需要 Shared GPU Memory 这套"跨界借用"的机制------因为压根没有那条界限需要跨越。

	Windows + 独立显卡（本文主线）	Apple Silicon（UMA）
内存结构	显存（GDDR7）与系统内存（DDR5）物理独立	CPU/GPU/NPU 共享同一块 LPDDR 内存
突破容量限制的方式	Shared GPU Memory + PCIe 搬运 + CPU Offload	不需要额外机制，内存本身就是统一的
额外开销	存在 PCIe 搬运这一跳	没有独立显存和系统内存之间的搬运开销
典型带宽	显存 TB/s 级，DDR5 约 100GB/s（经 PCIe）	统一内存带宽通常在数百 GB/s 量级（视型号而定）
生态与算力	CUDA 生态成熟，vLLM 等框架支持完善，峰值算力更高	生态仍在追赶，但内存"上限即显存上限"

这不是说哪一条路线"更好"，而是两种完全不同的取舍：Windows + 独立显卡的优势是显存本身带宽极高、软件生态成熟，代价是显存和内存之间存在硬性隔离，需要 Shared GPU Memory 这类机制去"打补丁"；Apple 的优势是内存容量本身就是显存容量，不需要打补丁，代价是峰值算力和框架支持还在追赶 CUDA 生态。

理解了这一层，本文讨论的范围也就从"Windows 上一个显存扩展技巧"，扩展成了一个更大的问题：AI 推理硬件的内存架构，正在朝着"打破显存与内存边界"这个方向演进------Windows 选择用软件层的 Shared GPU Memory 去逼近这个目标，Apple 选择直接在硬件层做到统一。殊途同归。

十、为什么 5090 + 96GB/192GB RAM，成为 AI 工作站的新组合？

前面九章，其实一直在铺垫同一件事：装机这件事的底层逻辑，正在发生变化。

传统 PC 的内存路径，是一条简单的单向链路，GPU 基本不参与系统内存的调度：

复制代码

传统 PC：

CPU
  |
DDR
  |
GPU（独立存在，几乎不碰系统内存）

而现在的 AI PC，GPU 反过来成了整条链路的起点，系统内存变成了它可以延伸的一块地：

复制代码

AI PC：

GPU 显存
  |
PCIe
  |
DDR（系统内存）
  |
CPU

系统内存，开始成为 GPU 容量的扩展层。 这不是某个厂商的营销话术，而是本文前面九章一路推导下来的必然结果：Shared GPU Memory、CPU Offload、GGUF 的层级卸载，本质上都是这条新链路在不同软件层的具体实现。

这也是为什么"RTX5090 32GB + 96GB DDR5（或直接上 192GB）"会成为最近个人 AI 工作站里一个越来越常见的组合------它不是随便拼出来的配置，而是精确对应了这条新链路里的两个关键节点：显卡负责高速计算这一端，大容量高带宽内存负责兜住显卡装不下的那一端。

以前，装机看显卡，第一句话永远是"你显存多大"。

现在，组一台 AI 工作站，问的问题变成了"你的整个 Memory Hierarchy 什么样"------显存多大、内存多大、带宽多快、PCIe 什么代际，缺一不可。这也是本文接下来要收束的地方。

十一、回到最初的问题

32GB 显存，为什么能够运行需要 56GB 显存的大模型？

答案并不是：GPU 突然拥有了更多显存。

而是：GPU、DDR、PCIe 与 CPU 共同组成了一套异构内存系统。

GPU 负责高速计算。

DDR 负责扩展容量。

PCIe 负责数据传输。

CPU 负责调度与部分计算。

Shared GPU Memory、CUDA Unified Memory、框架级 CPU Offload、GGUF 的层级卸载------这些不同的软件层机制，本质上都是同一套逻辑的不同实现：让 GPU 能够"借用"系统内存，继续运行更大的模型。它们解决的不是性能问题，而是容量问题。

所以，32GB 的 RTX5090 并没有真的变成 56GB 或 78GB 显存。

大模型时代，显卡的边界正在从"显存容量"，变成"整个内存体系的协同能力"。GPU 决定计算速度，DDR 决定容量边界，PCIe 决定数据流动效率，而软件框架决定如何调度这一切。无论是 Windows 平台上的 Shared GPU Memory，还是 Apple 用统一内存直接抹平这条边界，指向的都是同一个方向：未来 AI 工作站竞争的，不只是显卡大小，而是谁能把 GPU、CPU、内存和软件组合成更高效的推理系统。