大家好，我是 leopardracer！
你基本上可以在任何你能用到的设备上运行本地 AI 推理。从配置一般的笔记本电脑到高端游戏主机，二者都能以某种形式运行 AI。实际上，你甚至可以在智能手机这样简单的设备上运行 AI 模型。
但如果我们专门打造一台用于本地人工智能的机器呢？这就是 Lenovo ThinkStation PGX 的用武之地，它搭载了 Nvidia GB10 Grace Blackwell Superchip 和 128GB 统一内存。
一开始我要说明一点：Lenovo ThinkStation PGX 并不比单个 Nvidia H100 甚至 RTX 5090 更快。相反，它面向的是那些想在单台机器上快速原型或构建较小模型、且对速度要求不高的开发者。其主要卖点是将大量显存整合到一个封装中，同时围绕 Nvidia 生态系统的核心——CUDA 构建。
Lenovo ThinkStation PGX 是一款由 Nvidia GB10 Grace Blackwell Superchip 驱动的迷你 PC。它拥有 128 GB 显存用于本地 AI 工作负载，可用于量化、微调以及所有与 CUDA 相关的工作。
ThinkStation PGX 的内部硬件
它本质上就是一台印着联想标志的 DGX Spark。
Lenovo ThinkStation PGX 围绕 Nvidia GB10 Grace Blackwell Superchip 构建，如果你觉得这个说法耳熟，那是因为它与 Nvidia DGX Spark 内置的芯片相同。实际上，PGX 是同款参考设计的多个 OEM 变体之一，其他还包括 Dell Pro Max AI、Asus Ascent GX10 和 Acer Veriton GN100。这些设备的硬件几乎完全相同：同样的芯片、同样的内存、同样的外形。区别在于品牌、支持结构以及驱动器中预装的软件。以 PGX 为例，它运行基于 Ubuntu 构建的 Nvidia DGX OS，并预装了 CUDA 13、cuDNN、TensorRT 和 AI Workbench。
GB10 本身是一款系统级芯片，它将 20 核 Arm CPU 与 Blackwell 架构 GPU 配对，通过 NVLink-C2C 互连。CPU 部分分为 10 个高性能 Cortex-X925 核心和 10 个高效 Cortex-A725 核心，这是一种异构 big.LITTLE 架构，类似高端智能手机中使用的核心系列，不过数量要少得多。
在 GPU 方面，你拥有 6,144 个 CUDA 核心、192 个第五代 Tensor Core 和 48 个第四代 RT Core。这个 CUDA 核心数量在纸面上与 RTX 5070 相当，但 CUDA 核心数不能跨架构直接比较，也不能线性换算成性能。Nvidia 评估其 FP4 性能（带结构稀疏性）为 1 petaflop，即 1,000 TOPS。不过这个数字还有更多细节，它特指的是假设结构稀疏性下的理论峰值 FP4 吞吐量。
不过，这颗芯片对 AI 来说有趣的并不在于原始算力，而是内存。PGX 配备了 128GB LPDDR5X 统一内存，256 位总线，带宽为 273 GB/s。CPU 和 GPU 可以一致地共享整个内存池，这意味着不需要通过 PCIe 总线来回拷贝数据。当你加载一个 700 亿参数的模型时，它位于一个统一的地址空间中，GPU 可以直接访问。在传统桌面工作站上，GPU 有自己的显存（例如 RTX 5090 上的 32GB），任何超出显存的数据必须溢出到系统内存中，而系统内存的速度要慢得多。
对于这么小的机器来说，其余规格出人意料地全面。而且它确实很小：PGX 每个方向尺寸仅为 150mm，高度略高于 50mm。重量为 1.2kg（2.65lb），大小和重量大致相当于一台 Mac Mini。存储是一个单 NVMe M.2 插槽，提供 1TB 或 4TB 配置（支持自加密）。整机通过 USB-C 电源供电，最大功耗 240 瓦。连接性包括 10 Gigabit 以太网、Wi-Fi 7、蓝牙 5.3、三个支持 DisplayPort 2.1 alt-mode 的 USB4 端口、一个 HDMI 2.1a 输出，以及值得注意的是，通过集成的 ConnectX-7 NIC 提供的双 QSFP 端口。这些 QSFP 端口的存在是有原因的：你可以将两台 PGX 设备连接起来以汇聚它们的性能……某种程度上。
可以将两台 PGX 系统连接起来
但并非你想象的那种方式
ThinkStation PGX 上的双 QSFP 端口暴露了板载 ConnectX-7 控制器，可实现两台设备之间 200 GbE 的直接连接。Nvidia 提供了官方指南，用于连接两台 Nvidia DGX Spark 设备、配置网络接口、设置无密码 SSH，以及在转向分布式工作负载之前验证连接性。一旦连接，你可以使用 NCCL 等库实现节点间高带宽 GPU 到 GPU 通信。这允许你运行分布式训练任务或多节点推理配置，将工作负载拆分到多台机器上。
然而，这里有些注意事项，而且它并不是你想象的那种两台设备之间的共享内存池。
这种设置并不会将两台机器合并成一个统一的单一内存系统。问题是，每台 PGX 内部的 128GB LPDDR5X 统一内存通过 NVLink-C2C 在其 CPU 和 GPU 之间保持一致，但这种一致性在系统边界处就停止了。QSFP 端口提供高速以太网，但并非外部 NVLink 内存结构。这意味着你可以运行分布式工作负载，并且可以使用支持张量并行或流水线并行的框架将大型语言模型分片到多个节点上。但是，你不能将两个 128GB 系统当作一个透明的 256GB 共享内存机器来使用。
如果你想在两台系统之间拆分一个模型，你需要一个分布式框架（比如 Megatron-LM、DeepSpeed 或 vLLM 多节点），该框架会显式地划分模型并通过网络通信激活值。这种通信在 200 GbE 上可以非常快，但它仍然是网络流量，而不是硬件级的内存汇聚。
当我们谈论内存汇聚时，通常意味着一个单一的地址空间和跨设备的自动驻留管理。DGX Spark（以及扩展而来的 PGX）所实现的是高带宽分布式计算，这很强大，但仍然根本不同。
与 Apple Silicon 的比较
相同的概念，不同的侧重点
人们很容易将 PGX 与 Mac Mini 或 Mac Studio 进行比较，乍看之下，这种比较是有道理的。两者都使用统一内存架构，CPU 和 GPU 共享同一内存池。两者都很小巧、安静、节能，不过相似之处主要停留在表面。
最大的区别在于内存带宽，而这并不利于 PGX。Apple 的 M4 Max 能达到约 546 GB/s，M4 Ultra 则达到约 800 GB/s。PGX 的 LPDDR5X 最高为 273 GB/s。对于 LLM 推理来说，这非常重要。当模型逐 token 生成时，瓶颈几乎完全是内存带宽，因为 GPU 在每个解码步骤中会反复从内存中流式加载模型权重，而带宽越高，每秒生成的 token 就越多。如果你在同一台 Mac Studio 和 PGX 上运行相同的量化模型，在带宽受限的场景下，Mac 很可能会更快地生成 token，纯粹是因为它能以更高的速率将数据从内存传输到计算单元。
那么，你为什么会选择 PGX 而不是 Mac 呢？这似乎是一个奇怪的选择，但有两个非常重要的原因。
第一个重要原因是整个 CUDA 生态系统，我们在这篇文章的开头就提到了。几乎每个 AI 框架、优化库和模型部署工具都是首先为 Nvidia 的生态系统构建的。vLLM、TensorRT、FlashInfer 和 Nvidia Container Toolkit 都有一个共同点：它们都无法在 Mac 上运行。Apple 有 MLX，llama.cpp 中有 Metal 后端，两者在本地推理方面都很强大。但话说回来，它们只代表了 CUDA 上可用工具的一小部分。如果你的工作流程涉及来自 Nvidia 注册表的 Docker 容器，或者你需要具备功能调用和前缀缓存的生产级服务能力，你的 Mac 根本无法胜任。
第二个重要原因是 Tensor Core 确实很重要。虽然自回归解码（逐 token 生成）受限于带宽，但其他工作负载则受限于计算。长上下文上的提示处理、使用 LoRA 进行微调以及批量推理都更依赖原始算力吞吐量，而 Blackwell Tensor Core 正是为此而生。Apple 的 GPU 核心功能多样，但在相同规模下没有专用的矩阵乘法硬件。
总而言之，Apple Silicon 能在一个也是一台出色的通用计算机的机器上提供更多带宽。PGX 提供的带宽较少，但让你处于整个 AI 行业赖以建立的 Nvidia 生态系统的中心。哪个更好完全取决于你在构建什么。
在 ThinkStation PGX 上运行大规模本地语言模型
Qwen3-Coder-Next：800 亿稠密模型
我首先测试的是以 FP8 精度使用 Nvidia 自身的容器基础设施服务 Qwen3-Coder-Next，一个 800 亿参数的编码模型。具体操作如下：
1docker run --rm -it --gpus all --ipc=host --network host \2--ulimit memlock=-1 --ulimit stack=67108864 \3-v ~/.cache/huggingface:/root/.cache/huggingface \4nvcr.io/nvidia/vllm:26.01-py3 \5vllm serve "Qwen/Qwen3-Coder-Next-FP8" \6--served-model-name qwen3-coder-next --port 8000 --max-model-len 170000 --gpu-memory-utilization 0.90 \7--enable-auto-tool-choice --tool-call-parser qwen3_coder --attention-backend flashinfer --enable-prefix-caching \8--kv-cache-dtype fp8 --max-num-seqs 1
如果你对此不熟悉，下面解释一下。该命令从 Nvidia 自身的注册表拉取一个 Docker 容器，并使用 vLLM（一个高性能模型服务框架）将模型作为 API 端点托管在本地机器上。在 FP8 下，模型的 800 亿个参数每个占用一个字节，因此权重本身大约占用 80GB 内存。在配备 24GB 显存的消费级 GPU 上，如果没有激进的量化，这个模型根本无法容纳。然而，PGX 的 128GB 统一内存可以轻松加载它，并且还有富余空间。
--gpu-memory-utilization 0.90 标志告诉 vLLM 它可以使用 90% 的可用内存，这为模型及其上下文窗口留出大约 115GB 的空间。这很重要，因为 --max-model-len 170000 设置了一个 170,000 token 的上下文窗口，而上下文窗口是很耗内存的。模型处理的每个 token 都需要存储在 KV 缓存中（也就是上下文），它本质上就是模型到目前为止对话的工作记忆。这个缓存会随着每个 token 增长，在 170,000 token 时，如果使用全精度，它将变得巨大。这就是为什么要使用 --kv-cache-dtype fp8，它将 KV 缓存以 FP8 而非 FP16 存储。仅此一项就大约将其内存占用减半。
其余的是性能调优。--attention-backend flashinfer 使用了一种内存高效的注意力实现，避免实例化完整的注意力矩阵；--enable-prefix-caching 意味着如果你重复发送相同的系统提示，模型不会浪费时间重新计算它。--enable-auto-tool-choice 和 --tool-call-parser qwen3_coder 启用了函数调用，因此模型可以输出结构化工具调用用于代理式编码工作流程，例如像 Claude Code 那样。最后，--max-num-seqs 1 将服务器限制为一次处理一个请求，因为这是一台放在桌子上的原型机，而不是处理数十个并发用户的数据中心节点。
这就是 Nvidia 随 PGX 一起销售的工作流程。从其注册表中拉取一个容器，运行一个命令，你就可以在本地网络上拥有一个 800 亿参数的模型，支持工具调用、长上下文和优化。一切都能正常工作，因为你处于他们的生态系统中，而且你也可以将其与 Claude Code 一起使用。
最棒的是，Qwen3-Coder-Next 在这种配置下生成响应速度在每秒 25 到 40 个 token 之间，使其成为一个非常实用且强大的本地代码辅助语言模型。
Step-3.5-Flash：196b MoE 模型
vLLM 命令展示了精美的 Nvidia 原生路径。而这个则讲述了一个不同的故事，使用社区构建的工具来展示为什么 PGX 的统一内存架构具有超越 Nvidia 自身软件栈的更广泛实用性。我首先编译了他们的 llama.cpp 分支，该分支对此特定模型进行了优化，然后使用 vLLM 运行它。
1GGML_CUDA_ENABLE_UNIFIED_MEMORY=1 $HOME/llama.cpp/build-cuda/bin/llama-server \2-m $HOME/Step-3.5-Flash-GGUF-Q4_K_S/step3p5_flash_Q4_K_S-00001-of-00012.gguf \3-c 140000 \4-b 2048 \5-ub 1024 \6-ngl 999 \7-fa on \8-ctk q8_0 \9-ctv q8_0 \10--temp 1.0 \11--host 0.0.0.0 \12--port 8000
Step-3.5-Flash 是 StepFun 的一个大型模型，这里它已经被量化为 Q4_K_S，一种 4 位 GGUF 格式。即使经过量化，它仍然分布在 12 个分片文件中，这让你对其大小有所了解。llama.cpp 会自动将这些分片拼接在一起，但模型仍然需要大量内存，特别是当 -c 140000 设置了 140,000 token 的上下文窗口时。
整个命令中最重要的部分是顶部的环境变量：GGML_CUDA_ENABLE_UNIFIED_MEMORY=1。这告诉 llama.cpp 的后端使用统一内存，这意味着如果模型及其 KV 缓存无法容纳在单个 GPU 内存分配中，系统可以透明地溢出到共享内存池。在带有独立 GPU 的普通桌面上，“溢出”意味着通过 PCIe 回退到系统 RAM，这会严重影响性能。在 PGX 上，没有 PCIe 瓶颈。CPU 和 GPU 通过 NVLink-C2C 共享相同的物理内存，因此与传统桌面 GPU 上通过 PCIe 回退到系统 RAM 相比，溢出带来的性能损失要小得多。这就是统一内存的优势，模型可以以大约每秒 20 个 token 的速度生成，token 延迟为 50ms。
-ngl 999 标志告诉 llama.cpp 将所有层卸载到 GPU。结合统一内存，GPU 处理所有计算，内存系统负责数据实际存放的位置。-fa on 启用了闪存注意力，在这些上下文长度下，这是避免完整注意力矩阵消耗比模型本身更多内存所必需的。与我们处理 Qwen 时一样，KV 缓存被量化了。通过使用 -ctk q8_0 和 -ctv q8_0，我们将键和值以 8 位整数格式存储，使上下文窗口的内存占用保持在可控范围内。
接下来，我们设置 -b 2048 和 -ub 1024，它们控制模型如何处理初始提示。当你提供一个长提示时，它会以 2,048 个 token 为一批进行处理，微批次为 1,024 个 token。这可以调优“预填充”阶段（模型读取输入的部分）的吞吐量，而不会使系统不堪重负。
这个例子很好地展示了 PGX 的强大和多功能性，因为 llama.cpp 并不是专门为 PGX 构建的。它是一个社区项目，可以在从 Raspberry Pi 到服务器机架的任何设备上运行。但统一内存标志，加上 PGX 的 NVLink 连接内存架构，意味着它可以以在标准桌面上不切实际的方式处理具有巨大上下文窗口的大型量化模型。它以大约每秒 20 个 token 的速度运行，因此虽然不是世界上最快的，但肯定是可以使用的。
在 ThinkStation PGX 上微调模型
Qwen2.5b LoRA
在大型预训练模型上运行推理是一回事，但 PGX 也专为训练工作负载而构建，特别是那种允许你使基础模型适应自己的数据而无需重新训练整个模型的参数高效微调。为了测试这一点，我使用 LoRA 在 Alpaca 指令遵循数据集上微调了 Qwen2.5-7B，使用了我为 Nvidia playbook 脚本构建的相同基准测试框架。
为此，我以 bfloat16 精度加载 Qwen2.5-7B，将 LoRA 适配器附加到每个块的标准投影模块集（例如模型的注意力和 MLP 投影层），并在 5,000 个 Alpaca 样本上训练一个 epoch。LoRA（Low-Rank Adaptation）通过冻结原始模型权重并将小的可训练矩阵注入特定层来工作。在这种情况下，适配器针对每个 transformer 块中的所有七个投影矩阵：注意力机制中的查询、键、值和输出投影，以及 MLP 中的门、上和下投影。使用 rank 16 和 alpha 32，可训练参数数量只是全 70 亿参数的一小部分，这使得在单个设备上进行训练成为可能。完整模型以 bfloat16 格式驻留在内存中，而只有适配器权重接收梯度更新。
训练配置使用每个设备批次大小为 4，梯度累积步数为 4，有效批次大小为 16。序列长度限制为 1,024 个 token，学习率设置为 2e-4，这对于此大小模型的 LoRA 微调来说是相当标准的。整个作业在 Nvidia 的 NGC PyTorch 容器内运行，因此 CUDA、cuDNN 和所有相关库都已存在，我创建了一个基准测试框架来监控整个过程中的 GPU 利用率、内存、温度和功耗。
微调 Qwen2.5-7b 耗时不到 18 分钟。在峰值时，它使用了 41.1 GB 内存，GPU 功耗为 65.4W，记录到的最高温度为 77ºC。风扇肯定会转，但 ThinkStation PGX 在整个运行过程中非常安静。功耗保持稳定，GPU 时钟速度也稳定在 2.5 GHz，这意味着系统在这些条件下没有因热问题而限制 GPU。
与受内存带宽限制的自回归 token 生成不同，微调涉及每次前向和反向传播时的密集矩阵乘法。Blackwell Tensor Core 正是为此类持续计算而构建的，统一内存架构意味着模型、优化器状态和梯度缓冲区都存在于一个连贯的地址空间中，没有典型的 PCIe 主机到设备瓶颈。在配备独立 GPU 的传统桌面上，一个 70 亿参数的 bfloat16 模型加上 LoRA 开销将逼近高端消费级显卡 24GB 显存的上限。在这里，它轻松地处于 PGX 的 128GB 池内。
输出是一组保存到磁盘的 LoRA 适配器权重，准备合并回基础模型或在服务时加载到其上。整个工作流程，从拉取容器到拥有一个微调后的适配器，都在设备上运行，无需任何额外硬件。
在 Lenovo ThinkStation PGX 上量化模型
MedGemma-27b to NVFP4
推理和微调是引人注目的工作负载，但在本地 AI 流程中还有一个更安静的步骤同样重要：量化。在你能高效地服务大型模型之前，通常需要先压缩它，将其权重从高精度格式转换为适合内存并能以可接受速度运行的形式。为了在 PGX 上测试这一点，我使用 Nvidia 的 TensorRT Model Optimizer 将 MedGemma-27B 量化为 NVFP4。
MedGemma-27B 是 Google 的医学领域模型，在全精度下，其权重占据了相当大一部分内存。NVFP4 是 Nvidia 的 4 位浮点格式，一种 Blackwell Tensor Core 可以直接加速的硬件原生量化方案。该过程通过将校准数据传入模型以确定最佳缩放因子，然后以较低精度格式重新打包权重来完成。输出是一个标准的 Hugging Face 模型目录，只是规模显著缩小，并可直接使用。
这在 PGX 上之所以有趣，是因为观察系统在处理与推理或训练截然不同的工作负载时的表现。量化是一个批处理过程：模型加载到内存中，校准运行会持续高强度地驱动 GPU，然后压缩后的权重被写回磁盘。没有交互式 token 生成，没有梯度计算，只是一个漫长而稳定的计算任务。
整个运行耗时 26 分钟，使用了 63.6 GB 内存，峰值功耗为 57.3W。Tensor Core 在大部分运行时间内都在执行它们的设计初衷：高吞吐量的密集矩阵运算。GPU 最高温度达到 74°C，同样没有出现热节流迹象。
内存使用情况更有趣。系统空闲时约为 4.2GB，然后峰值达到 63.6GB，仅略高于 PGX 可用 RAM 池的一半。这很合理：全精度模型需要与校准缓冲区和正在组装的量化输出一起驻留在内存中。在配备 24GB GPU 的桌面上，此作业需要将大量数据卸载到系统 RAM，从而大大减慢整个过程的处理速度。在 PGX 上，它可以舒适地容纳在统一内存空间中，并且还有富余空间。
你应该购买 Lenovo ThinkStation PGX 吗？
它针对的是非常特定类型的用户
ThinkStation PGX 是一款很容易推荐的机器，但只针对非常特定的受众。如果你是一位 AI 开发者，需要在单个设备上原型、微调和服务高达 2000 亿参数的模型，并且你的工作流程依赖于 CUDA、vLLM、TensorRT 或 Nvidia 生态系统中的任何其他东西，那么 PGX 确实能做到它承诺的事情。你拉取一个容器，运行一个命令，一个大型模型就在你的本地网络上提供服务，支持功能调用和大 token 上下文窗口。对于这个特定的用例，市场上没有其他产品能提供统一内存容量、Nvidia 软件兼容性和物理紧凑性的相同组合。
但这个受众确实很窄。如果你主要进行本地推理且不需要 CUDA 生态系统，那么一台配备 M4 Max 的 Mac Studio 通常能以相似的价格产生更快的 token 生成速度，同时也是一台功能齐全的台式计算机。如果你需要严肃的训练吞吐量，PGX 甚至无法与单个 H100 竞争，而 Nvidia 自己也会告诉你这一点。如果你的模型可以舒适地容纳在 24GB 显存中，那么配备 RTX 5090 的台式机在原始速度上会优于 PGX，同时成本显著更低。
PGX 占据了一个非常特定的空白：模型太大而无法容纳在消费级显存中，工作流程太依赖 Nvidia 工具而无法使用 Apple Silicon，以及预算或安全要求排除了云计算。如果这描述了你的情况，那么 ThinkStation PGX 可以说是当今你能放在桌子上的最实用的设备。如果不是，你可能已经有更好的选择了。
如果这篇文章对你有帮助——关注 @leopardracer 获取更多类似内容，并加入我的 Telegram 频道：https://t.me/+ygATQAt9sUM1N2U6
