NInfer-V100-Duo-Win 发布：在 Windows + 双 V100 TCC 上跑起 TP2 原生推理，兼容 NInferV2 / V3
一、这项目是怎么来的
我的环境是 Windows + 2×Tesla V100-SXM2-16GB（TCC 模式，NVLink 互连）。在这套配置上，推理速度一直是个痛点：
| 方案 |
实测 decode |
评价 |
| LM Studio |
~30 tok/s |
太慢 |
| unsloth |
~45 tok/s |
太慢 |
| Coder 390 |
~70 tok/s |
还是不够 |
而以速度著称的 NInfer，之前只在 Linux 上验证过双卡。直到我看到两个关键项目：
plus1998/NInfer-V100-Duo：适配 V100 的 Linux 双卡分支natpate/ninfer-windows：适配 Windows 的单卡分支
两者一拼，理论上就是我要的东西。我先问了 AI 移植难度，答曰"不难"。于是我花了大概 2 块钱 的 API 费用，让 DSF1017 改出第一版——成功跑通了官方 Qwen3.8-27B 的 NVFP4 artifact。后来顺手测试，发现 Coder390 的 NInferV2 与 NInferV3 两种 artifact 格式也都能直接加载运行。
于是就有了这个发布。
二、项目脉络：它站在谁的肩膀上
┌─────────────────────────────┐
│ NInfer (upstream) │
│ 通用 CUDA 推理引擎 / 多卡 │
└──────────────┬──────────────┘
│
┌────────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ ninfer-v100 │ │ ninfer-win │ │ ninfer-v100-duo │
│ V100 架构适配分支 │ │ Windows 平台适配 │ │ Linux 双卡 V100 分支│
│ (单卡 / 通用) │ │ (单卡, RTX 5090) │ │ TP2 + NVLink │
└─────────┬──────────┘ └─────────┬──────────┘ └─────────┬──────────┘
│ │ │
└────────────┬───────────┴────────────┬───────────┘
│ │
▼ ▼
┌────────────────────────────────────────────┐
│ NInfer-V100-Duo-Win (本项目) │
│ Windows 原生 + 双 V100 TCC + TP2 + NVLink │
│ ─ 平台层移植（reader / 异步 I/O / CMake） │
│ ─ Stub 媒体层（绕过 FFmpeg/CURL） │
│ ─ AllReduce 稳定性门禁（Phase 0） │
│ ─ 同时加载 NInferV2 / NInferV3 artifact │
└────────────────────────────────────────────┘
一句话概括脉络：
- 上游 NInfer 提供推理引擎主体（quantization、kernel、serve 接口）
- ninfer-v100 解决 Volta 架构（sm_70） 的算子与量化兼容
- ninfer-win 提供 Windows 平台层 的参考实现（文件 I/O、CMake、MSVC 工具链）
- ninfer-v100-duo 提供 Linux 双卡 TP2 + NVLink 的通信与切分逻辑
- 本项目 = 把后三者的关注点合到一台 Windows 双卡 V100 TCC 机器上
需要强调的是：本项目没有把 natpate/ninfer-windows 合并进来（它是单卡 RTX 5090 参考），只是抄代码。移植时按"一次一个关注点、每步可编译"的原则推进，最终产出 ninfer.exe / ninfer-serve.exe + 可 replay 的 patches/0001..000N。
三、这个移植能干嘛
-
在 Windows 本机原生跑 ninfer-serve --tp 2
不需要 WSL2、不需要 Linux VM，直接吃上双 V100 的 NVLink P2P。
-
同时支持 NInferV2 与 NInferV3 两种 artifact 格式
实测四类 artifact 均可加载运行：官方 NVFP4、Coder390 W4A4 NInferV2、Coder390 W4A4 NInferV3、Coder390 Q6_K。V2/V3 无需额外转换，直接喂给 ninfer-serve。
四、四个模型的实际表现
所有测试在 2×Tesla V100-SXM2-16GB（TP2、NVLink、TCC） 上完成，固定 profile：
--prefill-chunk 2048 --max-context 196608 --kv-capacity 196608
--kv-dtype int8 --max-concurrency 1 --no-prefix-reuse --greedy
--tp 2 --devices 0,1 --spec mtp --draft-tokens 3
5 个 coding 场景（几何推导、C++20 实现、并发 LRU 调试、热点重构、约 18.9 万字符长上下文定位），统一 reasoning_effort=medium、greedy。每个模型单独启动一次 server，顺序执行 5 个非流式请求；缓存关闭，每个请求都是冷 prefill。
4.1 四个被测模型
| 代号 |
artifact |
格式 |
说明 |
| A |
qwen3_8_27b_nvfp4.ninfer |
官方 NVFP4 |
MTP3 + optimized head |
| B |
Qwen3.8-27B-Coder390-W4A4-MTP-DFlash2-NInferV2-NOT-FOR-V3.ninfer |
NInferV2 |
Coder390 W4A4 V2，MTP3 + full head |
| C |
Qwen3.8-27B-Coder390-EfficientThink-W4A4-MTP-DFlash2.ninfer |
NInferV3 |
Coder390 W4A4 V3（含 Vision 权重，未启用），MTP3 + optimized head |
| D |
Qwen3.8-27B-Coder390-EfficientThink-Q6_K-MTP.ninfer |
Q6_K |
weights gguf-blocks-full，full proposal head |
B 与 C 分别代表 NInferV2 和 NInferV3 两种 artifact 格式，本项目对两者均可直接加载、跑满 5 场景，说明格式兼容层在 Windows 移植路径上是通的。
4.2 主实验：A / B / C（196K 上下文，MTP3）
run：results/run-20261019-190343/
| 指标 |
A（官方 NVFP4） |
B（Coder390 V2） |
C（Coder390 V3） |
| decode tok/s |
112.77 |
107.48 |
112.43 |
| 48,056-token prefill tok/s |
958.1 |
956.8 |
955.9 |
| 格式 |
官方 NVFP4 |
NInferV2 |
NInferV3 |
总览：总 token 149,370 prompt + 61,694 completion = 211,064；总墙钟 899.2 s（14m59s，含三次模型加载）；Engine 请求时间 715.4 s。
大致结论：三个模型 decode 都稳在 107–113 tok/s，prefill 都在 956–958 tok/s。B 因使用 full proposal head，decode 略低约 5%，但仍超过 107 tok/s。A/C 使用 optimized head，decode 基本持平。
4.3 补充：D（Q6_K，155648 上下文，MTP3）
Q6_K 在 196608 下因显存不足无法启动（需 5,304,856,832 B，可用 4,486,056,960 B，差 781 MiB），155648 下启动成功，slack 165.7 MiB；使用 full proposal head。
run：results/run-20261020-030645/
| 指标 |
C（W4A4 MTP3） |
D（Q6_K MTP3） |
相对 |
| completion tokens |
19,710 |
20,385 |
+3.4% |
| prefill tok/s |
947.8 |
1,501.0 |
+58.4% |
| decode tok/s |
112.33 |
82.30 |
-26.7% |
| 48K 场景 TTFT |
50.5 s |
31.7 s |
-37.2% |
| 48K 场景 total |
74.3 s |
62.2 s |
-16.3% |
| 接受率 |
70.3% |
68.9% |
-1.4 pp |
大致结论：Q6_K 是明显的 prefill 型 profile——长 prompt 预填快约 58%，但 decode 慢约 27%。短 prompt 场景总时间慢 26%–61%；只有 48K 长上下文因 prefill 收益而快 16.3%。如果是"长仓库上下文 + 短输出"的 coding 工作负载，Q6_K 有优势；短 prompt 多轮生成则 W4A4 更合适。
4.4 DFlash2 vs MTP3（C artifact，补充对比）
C 的 DFlash2 companion 在 196608 下同样无法启动（差 893 MiB），降到 155648 后：
| 指标 |
C MTP3 K=3 @155648 |
C DFlash2 K=7 @155648 |
| decode tok/s |
112.33 |
108.71 |
| request seconds |
228.4 |
230.2 |
| 接受率 |
70.3% |
43.9% |
同 context 下 DFlash2 仍慢 3.2%，接受率明显更低（43.9% vs 70.3%），更高单轮验证成本没换来收益。本项目的默认推荐仍是 MTP3 K=3。
五、已知限制
- 本次最大 prompt 为 48,056 token（196,608 的 24.4%），没有填满 196K 上下文。
- DFlash2 与 Q6_K 在 196608 下均因显存差 800–900 MiB 无法启动，需降到 155648。
- C artifact 含 Vision 权重但未启用；当前发布形态是文本推理优先，媒体层走 Stub。
- 响应文本曾因 Windows PowerShell 5.1 按 Latin-1 解码 UTF-8 而乱码，已用无损反转修复；token/时间数据来自 server JSONL，未受影响。
- B 的加载时间 29.8 s 受 主要是咋比较快的固态硬盘 影响，A/C 约 71 s；不要据此比较冷启动。
- 每个场景只跑 1 次，decode 差异小于约 3% 不足以视为稳定优势。
六、结语
从"AI 说移植不难、花 2 块钱让 DSF1017 改第一版"，到四个模型、两种 artifact 格式（NInferV2 / NInferV3）在 196K 上下文下的完整 coding 基准，这个项目的意义不在于刷出多高的数字，而在于证明：
Windows + 双 V100 TCC + NVLink 这套"看起来有点烦"的配置，可以原生跑起 NInfer 的 TP2 推理，同时兼容 NInferV2 与 NInferV3 artifact，decode 稳定在 107–113 tok/s、prefill 接近 960 tok/s，Q6_K 更能把长 prompt prefill 拉到 1500 tok/s。
项目地址
https://github.com/Xxx-Bin/NInfer-V100-Duo-Win
ninfer.exe / ninfer-serve.exe 下载地址