docs: plan Flash-Next tiered inference for RTX 4070 Ti SUPER and 32GB RAM
This commit is contained in:
+13
@@ -0,0 +1,13 @@
|
||||
.env
|
||||
.env.*
|
||||
!.env.example
|
||||
secrets/
|
||||
models/
|
||||
cache/
|
||||
results/
|
||||
*.safetensors
|
||||
*.gguf
|
||||
*.exl3
|
||||
*.log
|
||||
__pycache__/
|
||||
*.pyc
|
||||
@@ -0,0 +1,36 @@
|
||||
# Flash-Next · RTX 4070 Ti SUPER 16GB / 32GB RAM
|
||||
|
||||
状态：**架构与实验规划，尚未在目标硬件部署或完成推理测试。** 2026-09-21。
|
||||
|
||||
唯一目标是运行 Qwen3.8-Flash-Next，保留文字、图片和视频能力；不以更小模型替代。RTX 4070 Ti SUPER、32GB 内存、2TB PCIe NVMe SSD 是用户指定的假设硬件，CPU、内存通道/频率、SSD 型号和系统尚未指定。
|
||||
|
||||
这里的“模拟”指容量预算与未来限额实验，不是用 RTX 6000D 冒充 4070 Ti SUPER 的性能测试。本次未修改 Spark 或 6000D 服务。
|
||||
|
||||
## 方案结论
|
||||
|
||||
1. 架构采用 GPU 常驻计算部分＋CPU 专家计算/缓存＋NVMe 文件后备。**PLE 与专家权重都必须纳入磁盘和内存预算**，仅卸载 PLE 不足以解决容量问题。
|
||||
2. 原始目标 `nvidia/Qwen3.8-Flash-Next-NVFP4` 保持独立实验路线。不能直接套用已有 6000D 的 vLLM 配置；该路线尚缺经过核实的低内存专家卸载和加载峰值方案。
|
||||
3. 同一 Flash-Next 的 GGUF / EXL3 量化衍生版本作为候选路线，必须单独记录来源、量化损失及多模态支持。更换量化不等于原 NVIDIA checkpoint 已跑通。
|
||||
4. 优先审计 GGUF 的 CPU 专家＋惰性文件加载方案，EXL3 为第二候选；32GB 是否足够仍待实测。不会承诺社区 30–40 token/s 能在这台机器复现。
|
||||
5. 初始并发 1、上下文 4096、输出 512、关闭 MTP；加载和正确性通过以后再扩展。验收目标为短文本中位生成速度 ≥5 token/s、暖态首字 ≤10 秒，这些是项目门槛而非性能预测。
|
||||
|
||||
## 阅读顺序
|
||||
|
||||
- [架构与资源预算](docs/architecture.md)
|
||||
- [上游依据、问题与审计边界](docs/upstream-review.md)
|
||||
- [分阶段测试与停止条件](docs/test-plan.md)
|
||||
- [待办与交付条件](docs/roadmap.md)
|
||||
- [机器可读目标配置](configs/target.json)
|
||||
|
||||
本仓库不包含未经验证的“一键启动”Compose，不复制社区执行脚本。候选运行时通过源码审计、版本固定和目标硬件试验后，再添加可执行部署文件。
|
||||
|
||||
## 本地容量估算
|
||||
|
||||
```sh
|
||||
python3 scripts/capacity.py
|
||||
python3 scripts/capacity.py --checkpoint-gib 123.568
|
||||
```
|
||||
|
||||
输出只计算预算和理论容量缺口，不推算实际 token/s，不证明可成功加载。结果中的目标显存/内存预算包含运行开销，不能全部用来存权重。
|
||||
|
||||
仓库不收录模型权重、密钥、代理地址或未脱敏请求。模型按原许可证获取。
|
||||
@@ -0,0 +1,23 @@
|
||||
{
|
||||
"status": "planning_only_not_hardware_validated",
|
||||
"model_family": "Qwen3.8-Flash-Next",
|
||||
"reference_checkpoint": "nvidia/Qwen3.8-Flash-Next-NVFP4",
|
||||
"gpu": "NVIDIA GeForce RTX 4070 Ti SUPER",
|
||||
"gpu_architecture": "Ada",
|
||||
"vram_gib": 16,
|
||||
"inference_vram_budget_gib": 14,
|
||||
"host_ram_gib_assumed": 32,
|
||||
"process_tree_and_page_cache_budget_gib": 24,
|
||||
"ssd_capacity_tb_decimal": 2,
|
||||
"cpu": null,
|
||||
"ssd_model": null,
|
||||
"memory_channels_and_speed": null,
|
||||
"planned_os": "native Linux x86_64, version to be fixed",
|
||||
"context_tokens": 4096,
|
||||
"max_output_tokens": 512,
|
||||
"concurrency": 1,
|
||||
"mtp_enabled": false,
|
||||
"required_modalities": ["text", "image", "video"],
|
||||
"runtime_revision": null,
|
||||
"deployment_ready": false
|
||||
}
|
||||
@@ -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体系不同。本轮未刷新两台服务的实时状态。
|
||||
@@ -0,0 +1,28 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Planning arithmetic only: no model loading, hardware emulation or speed claims."""
|
||||
import argparse
|
||||
import json
|
||||
import math
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
def main():
|
||||
parser = argparse.ArgumentParser(description=__doc__)
|
||||
parser.add_argument('--checkpoint-gib', type=float, default=123.568)
|
||||
args = parser.parse_args()
|
||||
if not math.isfinite(args.checkpoint_gib) or args.checkpoint_gib <= 0:
|
||||
parser.error('--checkpoint-gib must be finite and positive')
|
||||
cfg = json.loads((Path(__file__).resolve().parents[1] / 'configs/target.json').read_text())
|
||||
combined = cfg['inference_vram_budget_gib'] + cfg['process_tree_and_page_cache_budget_gib']
|
||||
print(json.dumps({
|
||||
'status': 'planning_arithmetic_only',
|
||||
'checkpoint_gib': args.checkpoint_gib,
|
||||
'combined_runtime_budget_gib': combined,
|
||||
'optimistic_nonresident_checkpoint_gib': round(max(0, args.checkpoint_gib - combined), 3),
|
||||
'warning': 'Budgets include runtime overhead. File size is not runtime size. No loadability or speed prediction.',
|
||||
'hardware_test_executed': False
|
||||
}, ensure_ascii=False, indent=2))
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
Reference in New Issue
Block a user