[Feature]让拥有强大单GPU但内存受限的个人开发者，能通过卸载“非激活专家”至SSD来运行DeepSeek等MoE大模型

### 检查清单

- [ ] 1. 如果您提出的不是新功能而是问题，请在讨论区发起讨论 https://github.com/kvcache-ai/ktransformers/discussions。否则该 issue 将被关闭
- [ ] 2. 为方便社区交流，我将使用中文/英文或附上英文/中文翻译（如使用其他语言）。未附带翻译的非英文/中文内容可能会被关闭

### 需求背景

---

### 功能请求：为大型MoE模型实现基于SSD的内存扩展

**问题陈述 (Problem Statement):**
此功能旨在解决一个特定且关键的用户痛点。当前，许多个人开发者投入资源配置了**高性能单GPU**（如RTX 4090），但他们的工作站系统内存（RAM）通常有限（如32/64GB）。

当他们尝试运行DeepSeek-V3这类大型MoE模型时，即便VRAM足以容纳激活的参数，但海量的非激活Experts参数也会迅速耗尽系统内存，导致模型无法加载。这形成了一个“**有算力，无内存**”的瓶颈，阻碍了这部分核心用户的使用和探索。

**核心提议 (Core Proposal):**
提议引入一个可选的三级存储机制，作为内存扩展方案。其核心逻辑为：**当且仅当**RAM不足以容纳全部非激活Experts时，才将超出部分**卸载（offload）至SSD**。这是一个条件触发的应急（fallback）机制，而非默认行为。

**技术路径建议 (Suggested Technical Path):**
建议采用 `mmap` 内存映射参数文件。在应用层预测出所需Expert后，通过**类似 `madvise` 等标准系统调用**，将异步预加载任务委托给操作系统内核。此方法避免了在用户空间重复实现复杂的I/O调度，实现简洁且高效。

**预期价值 (Expected Value):**
1. **降低硬件门槛**：使拥有强大GPU但标准内存配置的开发者也能运行和研究大型MoE模型。
2. **扩大社区基础**：显著增加项目的潜在用户和贡献者群体。

### 相关资源

_No response_

No files, tests, or entry points are named. Start by locating the model-loading and expert offload paths, then determine how an optional mmap-based SSD fallback could detect insufficient RAM and preload inactive experts; done means large MoE models can run under the stated memory constraints without making SSD offload the default.

Written by the indexing model from the issue text.