假如你是一个致力于将 AI 引入传统行业的工程团队。现在，你有一个问题：训练一个能看懂复杂机械图纸、设备维护手册或金融研报图表的多模态助手。这个助手不仅要能专业陪聊，更要能精准地识别图纸上的零件标注，或者从密密麻麻的财报截图中提取关键数据。
首先，你需要选择一个合适的模型。
7B 参数的小模型虽然跑得快，但「脑容量」太小，面对复杂的图文逻辑经常一本正经地胡说八道；而 70B 甚至更大的模型虽然聪明，但部署和推理成本直接劝退了客户。最后，你可能发现 30B 参数级的开源多模态模型（例如 Qwen-VL-30B）是个不错的选择。
30B 被称为大模型的黄金尺寸：它在理解能力上远超小模型，又比巨型模型轻量，是企业私有化部署的完美平衡点。
不过呢，你可能也会发现，「30B 参数」也是一个极具欺骗性的数字。
在纯文本时代，一张前沿的消费级显卡或许还能勉强塞下 30B 的推理。但在多模态（Vision-Language）场景下，事情完全变了。当模型需要处理高分辨率图像时，视觉编码器会产生大量的视觉 Token；而为了让模型真正懂行业 Know-how，必须用数千张有标注图像进行 LoRA 微调。
这就意味着，除了模型本身的权重，我们还需要在显存里塞进梯度、优化器状态以及训练过程中的激活值。
原本以为只是「稍微大一点」的任务，瞬间撞上了物理学的墙。
这些方案不太行
如果你的开发环境是顶级消费级旗舰，拥有 24 GB 的超大显存，但在这次的任务面前，它显得如此无力。
当你尝试启动微调脚本时，终端里那行熟悉的红色报错如期而至：
RuntimeError: CUDA out of memory.
对于 30B 多模态模型的微调来说，24 GB 的显存就是不够。为了让程序跑起来，你可能会选择牺牲性能，比如：
- Batch Size 降到 1： 哪怕训练速度慢到像蜗牛爬。
- 开启梯度检查点： 这是一个典型的「时间换空间」策略，通过不缓存中间激活值而是在反向传播时重算，来节省显存。但这让训练时间直接翻倍。
- 极限量化： 将模型量化到 4-bit 甚至更低。但这也会带来新的问题：对于精密图纸的识别，量化后的模型精度下降明显，连零件号都经常认错。
即使做了所有这些妥协，只要稍微喂进去一张分辨率高一点的图表，显存还是瞬间溢出，程序直接崩溃。那种「只差一点点就能跑通」的挫败感，最是折磨人。
「要不试试隔壁美术组那台 Mac Studio？」你可能会这样想。那台机器拥有 128 GB 统一内存（Unified Memory）。从硬件上看，这简直是完美的救星 —— 别说 30B，就是 70B 也能塞得下。
但当你兴冲冲地把代码拷过去，才发现这是另一个深坑。
首先是环境配置的噩梦。开源社区的主流多模态模型（尤其是涉及底层 CUDA 优化的视觉算子）在苹果芯片上的适配往往慢半拍。你可能会花不少时间解决各种编译报错，好不容易跑通了推理，却发现训练速度受限于优化，效率远不及预期。
更致命的是「生态隔离」。在 Mac 上微调出的模型检查点，想要部署回公司的 Linux 服务器（基于 NVIDIA GPU）上，需要进行繁琐的格式转换和精度对齐。这种开发环境与生产环境的割裂，对于追求快速迭代的工程团队来说，是不可接受的风险。
那么，你到底需要什么？
难道为了跑通这个 30B 模型，你真的要走漫长的合规流程去申请昂贵的 A100 云实例，时刻防范私密数据出域的风险？又或者，仅仅为了这一个开发项目，就专门配置一个高成本的工作站，甚至去采购一台必须安置在专业机房、且维护成本高昂的机架式服务器？
你需要这样一台机器：它要有 Mac Studio 那样海量的统一内存，让你不再为显存精打细算；它同时又必须流淌着纯正的 NVIDIA 血液，拥有原生的 CUDA 生态，让代码无缝迁移。
这个「既要又要」的幻想，直到一台 1 升体积的小盒子的出现，才变成了现实。
桌面上的一升解决方案
这个盒子就是联想 ThinkStation PGX
如果你关注过英伟达之前的动作，可能会觉得眼熟。没错，联想 ThinkStation PGX 在核心配置上与 NVIDIA DGX Spark 完全一致。
准确地说，ThinkStation PGX 正是英伟达 DGX Spark 的 OEM 量产版本。英伟达已将这一参考设计授权给了联想等厂商，由它们负责具体的工程化制造与差异化定制。
这台机器最直观的冲击力来自于它的尺寸：仅有 1 升（1L）。它小到可以轻松塞进通勤背包，放在办公桌的一角几乎没有存在感。但就在这方寸之间，联想塞进了一颗基于 NVIDIA Grace Blackwell 架构的 GB10 超级芯片。
