docs: plan Flash-Next tiered inference for RTX 4070 Ti SUPER and 32GB RAM
This commit is contained in:
@@ -0,0 +1,60 @@
|
||||
# 架构设计
|
||||
|
||||
## 硬件假设与边界
|
||||
|
||||
RTX 4070 Ti SUPER 是 Ada 16GB 卡，不能按 Blackwell 原生 FP4 性能设计。vLLM 有 NVFP4 权重压缩、W4A16 Marlin 计算路径，但线性层支持不证明该模型的 MoE、QSA、PLE、视觉和 MTP 全链路兼容，逐项测试后才能选择。
|
||||
|
||||
CPU 不虚构型号。登记物理核心、AVX2/AVX-512、内存通道及实测带宽；CPU 专家计算方案的性能高度依赖这些项目。SSD 登记型号、PCIe 协商链路、文件系统、随机读延迟、温度和剩余空间，不能把标称顺序带宽当作 PLE 查表速度。
|
||||
|
||||
首选原生 Linux 以便记录 cgroup、文件页缓存和 I/O。Windows/WSL2 是后续独立平台，不能混用测量结果。
|
||||
|
||||
## 数据流
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
API[本机 API：单请求] --> R[Flash-Next 推理运行时]
|
||||
R --> G[GPU：注意力、稠密路径、缓存、部分专家]
|
||||
R --> C[CPU：卸载专家计算与 PLE 查询]
|
||||
C --> RAM[内存：专家工作集、PLE 页缓存、暂存区]
|
||||
SSD[NVMe：模型文件、PLE、非驻留专家] --> RAM
|
||||
RAM --> G
|
||||
C --> G
|
||||
```
|
||||
|
||||
这是逻辑设计，不是已经实现的调度器。GPU/CPU 专家划分首先采用候选引擎已有的静态逐层配置；不假设它拥有动态热门专家缓存。对非驻留 CPU 权重采用文件后备时，由操作系统分页或引擎显式加载，实际行为必须从源码和磁盘读量确认。
|
||||
|
||||
## 资源上限
|
||||
|
||||
| 项目 | 起始预算 | 说明 |
|
||||
|---|---:|---|
|
||||
| GPU 推理总占用 | ≤14GiB | 包含权重、KV/循环状态、视觉编码器峰值、计算缓冲 |
|
||||
| GPU 预留 | 约2GiB | 桌面显示、驱动及波动；不是额外可用权重空间 |
|
||||
| CPU 进程树＋计费文件缓存 | ≤24GiB | 加载期和稳态均须满足；不能只测主进程 RSS |
|
||||
| 主机预留 | 约8GiB | OS、客户端和峰值；真实可用容量以实机为准 |
|
||||
| SSD 模型与实验空间 | 初期约400GiB预算 | 原版、一个候选量化、转换临时文件分开核算；转换可能超出此预算 |
|
||||
|
||||
保持至少约20% SSD 可用空间作为初始管理目标；不为了达到固定分区比例移动用户数据。模型以只读目录挂载，缓存、输出、凭据分目录。
|
||||
|
||||
NVIDIA checkpoint 约133GB（十进制）；历史部署记录约123.568GiB。即使把14＋24GiB全部用于权重，仍有约85.6GiB不能同时驻留，实际缺口更大。不能把 PLE 的约47.7GiB独立映射后就宣称问题解决，剩余主体仍过大。
|
||||
|
||||
SSD 只解决容量，不保证访问时间。PLE 稀疏读取和路由专家访问分别统计，避免用平均数据量掩盖随机 I/O 延迟。被 mmap 的页会占用内存缓存；mmap 不等于零内存，也不等于每步必然访问物理 SSD。
|
||||
|
||||
## 路线选择
|
||||
|
||||
| 路线 | 优先级 | 决定条件 |
|
||||
|---|---|---|
|
||||
| 同一 Flash-Next 的 GGUF，CPU MoE＋PLE/专家文件后备 | 首先审计 | 确认精确分支支持架构、惰性加载、视觉、视频输入；≤24GiB 总内存才继续 |
|
||||
| EXL3，CPU MoE＋磁盘 PLE | 第二候选 | 社区3.05bpw方案报告约47.8GiB RAM，不能原样采用；需支持混合专家放置或更低位量化并通过质量评估 |
|
||||
| NVIDIA NVFP4＋vLLM/其他引擎 | 原始 checkpoint 对照路线 | Ada 全算子兼容、专家卸载与PLE磁盘路径可组合、加载峰值有界；目前未证实 |
|
||||
|
||||
不自动裁剪专家、删除视觉编码器或过度量化 PLE 来满足容量。GGUF/EXL3 是量化变体，保留原模型结构不代表输出质量等价。先从现成且来源可核对的量化版本评估，避免在32GB主机上盲目执行可能需要数百GB内存的转换。
|
||||
|
||||
## 容量模拟的正确用法
|
||||
|
||||
以后若在更大的测试机器上做试验，CPU容器内存限24GiB、禁用该容器swap，且把所有worker放在同一cgroup。GPU显存需要引擎分配预算配合实际峰值监控；Docker内存限制不限制显存。
|
||||
|
||||
不要通过占满其他显存来冒充4070TiSUPER，不通过全局drop_caches干扰生产服务。共享宿主的预热文件页、缓存计费归属、不同CPU/GPU与PCIe都会影响结果。限额实验只报告“受限容量加载结果”；实际延迟、功耗与吞吐必须在4070TiSUPER上测量。
|
||||
|
||||
## 服务形态
|
||||
|
||||
通过验收后封装单服务API，默认绑定127.0.0.1，权重只读、凭据单独挂载，前端按需增加。先验证文字，再验证图像与视频；最终目标始终保留三者。如果引擎只接受视频抽帧，记录采样率、帧数和时间顺序，不把“识别一张图片”当作视频验收。
|
||||
@@ -0,0 +1,13 @@
|
||||
# 待办与交付
|
||||
|
||||
- [x] 固定用户目标：Flash-Next、4070TiSUPER 16GB、32GB RAM、2TB NVMe。
|
||||
- [x] 建立三级存储架构、预算、证据与测试门槛。
|
||||
- [x] 阅读低显存参考方案及家用桌面issue，区分显存限额和真实硬件。
|
||||
- [ ] 补齐实际CPU、内存配置、SSD及操作系统。
|
||||
- [ ] 固定候选代码SHA，审计加载/专家/PLE/视觉实现；确认量化衍生版本可接受的质量。
|
||||
- [ ] 获得实际测试机器；若使用大卡限额模拟，结果单独标注。
|
||||
- [ ] 依次完成P0–P5，记录失败与回退。
|
||||
- [ ] 仅为通过版本编写Dockerfile/Compose与启动、健康检查、停服脚本。
|
||||
- [ ] 复测MTP和上下文扩展；形成“已测配置中的最佳”，不宣称全局最优。
|
||||
|
||||
交付分层：规划完成 → 固定源码审计完成 → 容量试验通过 → 真机性能通过 → 多模态质量通过 → 日常部署。仓库创建不代表后面阶段已完成。
|
||||
@@ -0,0 +1,49 @@
|
||||
# 测试方案
|
||||
|
||||
当前所有阶段均未执行硬件测试。门槛是工程验收目标，不是已达到指标。
|
||||
|
||||
## 固定条件
|
||||
|
||||
精确记录GPU/CPU/内存通道/SSD/驱动/内核/引擎SHA/量化revision。每次只改一个变量，固定prompt、seed、采样参数、模板、上下文4096、输出512、并发1、MTP关闭。计时分开记录加载、预填充、首字、decode和总耗时。
|
||||
|
||||
原版与重新量化版本不能作为只改变卸载参数的性能A/B；它们是不同质量档。相同输入也可能产生不同输出，另测固定生成长度和自然结束的真实任务。
|
||||
|
||||
## 顺序与通过条件
|
||||
|
||||
| 阶段 | 工作 | 通过条件 |
|
||||
|---|---|---|
|
||||
| P0 | 收集真实硬件；完成候选源码审计，固定版本 | 有可追溯加载路径和全部算子支持证据 |
|
||||
| P1 | 逐张量预算、加载峰值；先GGUF，后EXL3，再评估原NVFP4路线 | GPU≤14GiB、完整进程树与缓存≤24GiB，无OOM；不偷用宿主额外RAM |
|
||||
| P2 | 128token冒烟；512token固定长度；自然结束任务 | API成功且有有效回答，模板与reasoning字段正确 |
|
||||
| P3 | 同一量化依次GPU预算10/12/14GiB，改变CPU专家层比例；上下文固定 | 记录最优已测分配；运行时不支持的组合标记不支持，不硬凑 |
|
||||
| P4 | 2K提示词＋512输出，冷态3次、暖态10次；8K作为后续扩展 | 暖态中位decode≥5tok/s、p95 TTFT≤10秒为交互目标；未达标列为实验可运行 |
|
||||
| P5 | 文字、图像、视频质量及30分钟混合负载 | 0错误/0OOM，所有必需功能通过，资源上限始终满足 |
|
||||
| P6 | 仅对通过方案测试MTP1/2、图优化、长上下文 | 相同任务总耗时改善≥10%，质量不退化且峰值不超限才启用 |
|
||||
|
||||
图优化、MTP、8K以上上下文均不是第一轮默认项。候选若只支持文字，标记“文字阶段通过”，整体仍未验收。
|
||||
|
||||
## 质量任务
|
||||
|
||||
- 12个确定性算术、10个结构化JSON、5个多轮约束、5个代码单元测试；确定性项全对，代码在隔离且有限时的环境执行。
|
||||
- 20个中文问答/摘要/代码实际任务，与原NVFP4参考输出盲评；若使用现有服务作参考，另行安排负载窗口，记录版本，不能把模型输出当唯一真值。
|
||||
- 图片：至少5张含已知字段的票据/图表，核对字段和总计；验证多图不串图。
|
||||
- 视频：至少3段有明确事件顺序的短片，记录帧采样、时序和正确答案；不只提交一帧。
|
||||
- 降位量化不以能流畅说话作为质量证据；报告准确率、失败样例、推理预算截断与无最终答案情况。
|
||||
|
||||
## 观测与失效判断
|
||||
|
||||
每秒采集GPU显存/利用率/温度、cgroup memory.current/peak/stat/events、swap、worker总占用、磁盘读量/延迟/队列及major faults。报告阶段增量、页缓存和匿名内存，而非只给父进程RSS。
|
||||
|
||||
冷态明确区分进程首次启动和物理文件缓存冷态。不得在生产宿主全局清页缓存；优先独立实验机重启后测试，并如实记录SSD和OS缓存条件。限额模拟若共享已有热页缓存，不能用于声称32GB实际冷启动成功。
|
||||
|
||||
启动超30分钟或单请求5分钟无输出即停止该臂；出现OOM、swap持续增长或宿主可用内存低于4GiB也停止。短文本连续3次低于1tok/s，先检查I/O与CPU瓶颈，不继续加大上下文。
|
||||
|
||||
## 回退
|
||||
|
||||
每个试验记录独立配置，失败后停止本项目进程并恢复上一通过配置；若没有通过配置则保持停止，不循环重启。此次规划不授权停掉现有Spark/6000D生产服务来做限额模拟。后续执行应先选定实际实验机器和窗口。
|
||||
|
||||
## 证据格式
|
||||
|
||||
每次保存脱敏JSON：run_id、timestamp、machine、simulation_or_real、engine_sha、model_revision、model_hashes、quantization、placement、resource_limits、prompt_hash、input/output/reasoning_tokens、finish_reason、ttft_s、decode_tps、total_s、gpu_peak_mib、cgroup_peak_bytes、disk_read_bytes、oom_events、quality_pass、limitations。
|
||||
|
||||
原始结果放本地results/；只把脱敏且经过复核的汇总提交到audit/results/。没有真实结果时不得创建伪造成功样例。
|
||||
@@ -0,0 +1,39 @@
|
||||
# 上游证据与审计边界
|
||||
|
||||
检索日期：2026-09-21。本轮完成公开资料和issue初筛，**尚未完成候选引擎源码审计**，未运行第三方脚本。参考项目main/master会变化，GitHub API读取提交号本轮失败；以下为按日期记录的页面证据，不冒充固定SHA审计。部署前必须锁定引擎、补丁、量化文件revision及SHA256。
|
||||
|
||||
## 证据表
|
||||
|
||||
| 来源 | 核实内容 | 对本项目的意义 |
|
||||
|---|---|---|
|
||||
| [NVIDIA checkpoint](https://huggingface.co/nvidia/Qwen3.8-Flash-Next-NVFP4/tree/main) | 页面文件总量约133GB | 不能依靠16＋32GB全部驻留 |
|
||||
| [vLLM Marlin NVFP4](https://docs.vllm.ai/en/stable/api/vllm/model_executor/kernels/linear/nvfp4/marlin/) | 提供非原生FP4硬件的W4A16线性核路径 | Ada并非必然不能读取NVFP4，但全模型支持仍需核实 |
|
||||
| [Flash-Next VRAM Benchmark](https://github.com/lukaLLM/Qwen3.8-Flash-Next-VRAM-Benchmark) | 低显存档最初使用约91GiB主机RAM；另有24GB显存档56/64GB内存限额测试，讨论lazy加载和CPU专家 | 有分层实现线索，没有本项目16GB＋32GB完整证据；文中GPU是大卡限额，不能继承其速度 |
|
||||
| [flash-next-8gb](https://github.com/lna-lab/flash-next-8gb) | 3.05bpw EXL3方案报告约47.8GiB cgroup内存；测试平台高端CPU及大内存 | 只看标题“8GB GPU”会漏掉主机内存要求；不是32GB方案 |
|
||||
| [issue #1](https://github.com/lna-lab/flash-next-8gb/issues/1) | 用户报告5700X3D、64GB DDR4、4070 SUPER、Windows 11约3.5tok/s | 非4070TiSUPER、非32GB，也不是严格对照；说明CPU与平台差异不可忽略 |
|
||||
| [llama.cpp](https://github.com/ggml-org/llama.cpp) | 支持CPU/GPU混合推理基础能力 | 不能据此推导Flash-Next全部特殊算子及多模态已通过 |
|
||||
|
||||
阅读了lna-lab issue列表及#1。另一参考项目issue列表本轮抓取失败，不声称没有问题。没有找到经过核实、精确匹配4070TiSUPER＋32GB＋完整Flash-Next多模态的验收报告。
|
||||
|
||||
## 初筛决定
|
||||
|
||||
- 保留上述两条低显存方案为审计候选，不复制Dockerfile、启动脚本或镜像。
|
||||
- 参考README中的lazy-mode和专家层参数是候选版本线索，不作为已核实的本仓库启动命令。
|
||||
- 社区README中的绝对表述需独立验证，例如“磁盘表不需要内存”不符合页缓存实际语义；网络文件系统是否可mmap也不能一概否定。
|
||||
- 当前官方NVFP4配置只作为精度/能力参考，不能直接缩小gpu_memory_utilization后宣称能跑。
|
||||
- GGUF/EXL3衍生版本来源和质量必须单独验收。用户要Flash-Next，不更换为27B或14B模型。
|
||||
|
||||
## 下一阶段源码审计清单
|
||||
|
||||
1. 从维护者仓库固定SHA，记录许可证、依赖、补丁及镜像digest。
|
||||
2. 检查加载器是否mmap后又完整复制、解量化或锁页；记录worker与加载临时峰值。
|
||||
3. 检查PLE地址计算、FP8/量化scale、稀疏查询批量化、边界处理；禁止因省内存静默丢精度。
|
||||
4. 检查专家路由、CPU/GPU分层与张量生命周期，证实专家可分页且不会全量pinned。
|
||||
5. 审计Ada编译目标、MoE、QSA、循环状态和视觉算子，单核正确不等于端到端正确。
|
||||
6. 检查聊天模板、reasoning字段、工具调用、图片及视频预处理兼容；文本接口可用不能替代多模态验收。
|
||||
7. 查所有相关开放/关闭issues及修复PR的实际合入SHA，不靠版本名称判断。
|
||||
8. 自行编写最小启动配置；不运行curl管道安装、无版本依赖或来源不明二进制。
|
||||
|
||||
## 已有项目的适用范围
|
||||
|
||||
已有[6000D项目](https://git.bunnyruihan.com:16666/ruihan/qwen38-flash-next-rtx6000d)和[Spark项目](https://git.bunnyruihan.com:16666/ruihan/qwen38-flash-next-dgx-spark)仅用于测试方法和模型能力参考。6000D的CPU驻留PLE依赖充足内存，Spark统一内存与独显PCIe体系不同。本轮未刷新两台服务的实时状态。
|
||||
Reference in New Issue
Block a user