为什么本地 RAM 池化胜过购买更大的机器
Source: Dev.to
我们都有过这样的经历。
你正在进行一次大型构建、训练模型，或处理海量数据集。突然，一切卡住了。你打开 htop，看到那条死亡红线：Swap。你的 32 GB MacBook 气喘吁吁，而同事的笔记本却闲置，办公室服务器只用了 5 % 的资源。
此时，典型工程师的本能（包括我在内）是：
“我需要一台更大的机器。”
我们本能地掏出信用卡，想升级到 64 GB 或 128 GB。最近，我意识到这种本能不仅昂贵，而且在技术上是倒退的。
传统观念
单台机器的 RAM 越多 = 性能越好
这看起来很合理，因为本地内存通常是我们拥有的最快的资源。但在构建分布式系统的过程中，我吃了苦头才明白其中的陷阱。
为什么单机扩展会碰壁
- 带宽瓶颈 – 单条内存总线只能推送有限的数据。
- NUMA 惩罚 – 在多插槽服务器上，访问“另一颗”CPU 上的 RAM 会显著增加延迟。
- 灾难半径 – 如果那台昂贵的机器宕机，整个工作负载也随之崩溃。
相比之下，坐在你旁边的笔记本或服务器有自己的内存控制器、自己的总线和自己的 CPU。当你横向扩展时，内存带宽线性增长：两台各 64 GB RAM 的机器的总带宽大约是单台 128 GB 机器的两倍。
“横向扩展”为何困难
我们已经有了共享 CPU（Kubernetes）和存储（S3、网络磁盘）的优秀工具。但内存一直被限制在盒子内部，严格是“本地”的。这导致了我所说的 被困的 RAM。
现在，办公室或数据中心中约有 60–80 % 的总 RAM 已经配置、付费并通电——但对实际需要它的进程来说完全不可访问。
这就像车道上停着五辆车，却因为坐的那辆没油而无法开去上班。
介绍 MemCloud
我创建了 MemCloud 来打破这一限制。其理念是把局域网内的 RAM（笔记本、台式机、Raspberry Pi 集群）视为一个巨大的统一内存池。
MemCloud 并不取代本地 RAM（网络延迟是真实存在的），而是位于内存层次结构的 “温热” 层：
| 层级 | 大约延迟 | 感受 |
|---|---|---|
| CPU 缓存 | ~0 ns | 瞬间 |
| 本地 RAM | ~0.1 µs | 瞬间 |
| MemCloud / 远程 RAM | ~10–30 µs | 极其流畅 |
| NVMe SSD | ~100 µs | 快速 I/O |
| 磁盘 | ms | … |
远程 RAM 仍然比 NVMe SSD 快 5–10 倍，是以下场景的理想选择：
- 构建缓存
- 机器学习嵌入向量
- 临时编译产物
- 分析用的临时空间
将几 GB “温热” 数据卸载到邻近节点，让本机喘口气：交换分区抖动停止，界面再次响应。
使用场景
- CI 流水线 可以在非工作时间从办公室工作站借用 100 GB RAM。
- 边缘设备 可以池化资源，运行单独无法处理的 AI 模型。
- 团队 可以共享庞大的内存数据集，而无需每个人都拥有完整副本。
入门指南
MemCloud 使用 Rust 编写，体现了从单体巨兽向协作式、点对点群体转变的更大趋势。
- 📖 阅读文档：
- 💻 浏览代码：
如果你曾在一堆闲置的电脑旁面对 “内存不足” 崩溃，那么你一定能体会到这项技术的重要性。欢迎在评论区讨论你的内存相关痛点！