上周帮人部署一台双卡V100的推理服务器，目标很明确：把QUASAR-NVFP4量化模型在2×V100上跑起来，对外提供稳定的OpenAI兼容接口给内部业务用。这活儿看着简单，真正做起来牵扯的东西不少——V100是Volta架构的老卡，NVFP4是NVIDIA为Blackwell准备的4-bit浮点格式，1Cat-vLLM又是一套在vLLM基础上做量化适配的社区分支，三个变量叠在一起，想把它们拧到同一根轴上，我前后折腾了快三天。这篇文章就把整个过程从头到尾捋一遍，包括那些文档里找不到的坑，给同样手里攥着几块V100又不想扔的朋友一个参考。

整个部署过程中最反直觉的一点是：V100本身没有任何FP4计算单元，但量化模型跑起来不仅显存问题解决了，速度反而比FP16版本更快。这个结论背后牵扯到量化格式的存储方式、kernel的加载路径、以及两张卡之间的通信方式。把这些搞明白，你就不会觉得这是一件碰运气的事，而是一套可以稳定复现的工程方案。

1. 为什么要在V100这种老卡上跑NVFP4量化模型——背景与选型

1.1 这件事的起点：两张V100和QUASAR模型

V100是2017年发布的Volta架构数据中心卡，放在今天确实算老古董了。但它有个优势：二手市场价格很低，而且16GB HBM2在某些场景下依然比消费级显卡能打。QUASAR这个模型我拿到的版本是35B总参数、约3B激活参数的MoE结构，长上下文能力比较强，从架构特征看跟最近开源的Qwen系35B-A3B-MTP-Compact模型同源。原版FP16权重的话，35B×2字节就是70GB，两张32GB V100都塞不下，更不用说我手上这两张只是16GB版本。所以量化是唯一出路，而不是什么可选项。

NVFP4量化之后，权重直接从2字节/参数降到0.5字节/参数，35B模型大约只需要17.5GB的权重存储。加上scaler表和一些开销，两张16GB V100做tensor parallel切分后，每卡大概只需要9GB左右放权重，剩下6GB可以全部留给KV cache和激活值。这个数学账一算，方案就基本定了。

1.2 不量化的路根本走不通：用数字说话

我们先把显存账算细一点。QUASAR这类35B级MoE模型，FP16权重是70GB；如果退一步用INT8量化，权重降到35GB，两张32GB V100勉强装下，但16GB版本依然无望。NTFP4/4-bit量化后权重是17.5GB，加上每128个元素一个FP32 scale，粗略增加1.1GB，合计18.6GB。两张16GB V100总显存32GB，TP=2后权重均摊到每卡约9.3GB，剩余空间可以支撑几万token的KV cache。

这不是优化问题，是能不能跑的问题。V100只有16GB和32GB两个显存版本，二手市场上16GB居多。对很多预算有限的团队来说，与其换全套平台，不如让老卡继续服役。另外还有个隐性好处：权重变小后，两张卡之间 tensor parallel 通信的数据量也小了，这在没有NVLink的PCIe平台上尤其重要。后面我会专门讲这个点。

1.3 为什么是1Cat-vLLM而不是原版vLLM

原版vLLM对FP4/NVFP4这类格式的支持是最近才逐步完善的，而且主要针对Blackwell新卡。1Cat-vLLM这个分支做的事情，是在原版基础上补齐了老卡的兼容路径：注册了nvfp4量化方式入口，修改了权重加载逻辑，让FP4权重可以在kernel内部反量化成FP16参与计算。也就是说，它保留了vLLM的调度器、PagedAttention、continuous batching这些核心组件，只是在图编译和kernel选择上做了适配。

我的选型建议是：如果你只是想在V100上跑量化模型，优先考虑这种针对性分支，不要自己去改原版代码。用原版vLLM强行加载NVFP4模型，大概率会卡在"不支持的量化格式"或者错误的kernel选择上，改起来成本不低。1Cat-vLLM对社区量化模型的支持更积极，能省下大量调试时间。

2. 平台搭建与驱动准备：X99、供电、ECC与TCC模式的坑

2.1 X99平台双卡怎么拆PCIe通道

这次用的是一块X99主板配两颗至强处理器的平台，这是目前DIY双卡推理服务器最常见的方案之一。X99属于LGA2011-3接口，Haswell-E/Broadwell-E级别的CPU一般提供40条PCIe 3.0通道，足够拆成x16+x16给两张V100用。需要注意的点是：CPU通道数不够40条的低端型号会变成x16+x8，对TP=2这种通信敏感的负载有一定影响。

实际装机时还要确认PCIe插槽的物理带宽是否被其他设备占用，比如有些主板插上M.2 SSD后会从PCIe x16槽借通道。我的做法是装系统前先在BIOS里把PCIe链路设置为x16/x16，并检查两条槽位是否跑在Gen3速率。V100的PCIe版对外功耗一般在250W左右，如果主板插槽供电不够，两张卡满载时会直接掉驱动或者触发保护。稳妥的方案是使用服务器电源，并用转接线给每张卡单独供电，别指望主板PCIe插槽那75W能扛住。

2.2 V100驱动选型与TCC/WDDM问题

V100的驱动选择有个容易被忽略的分叉：如果你只是跑Linux容器，装数据中心驱动（datacenter driver）就好，不要装带显示功能的桌面驱动。我在实际部署中用的驱动分支是r535系列，对V100支持稳定，CUDA runtime可以用12.x，编译vLLM和flash-attn都没有问题。

如果你在Windows下做前期验证，就会遇到TCC和WDDM的问题。V100默认可能跑在WDDM模式，这个模式会保留显示输出能力，但对纯计算负载有额外开销，而且显存管理方式不友好。切成TCC模式后，GPU对CUDA计算是直通状态，显存利用率更高，也不会有桌面刷新抢占计算资源的问题。切换命令需要管理员权限，在Windows设备管理器里找到显卡属性中的"compute mode"或直接用nvidia-smi切换，切完必须重启。不过TCC只解决Windows下的验证问题，正式服务我还是强烈建议搬到Linux。

2.3 ECC内存错误：跑大模型前先体检

V100的HBM2显存带ECC纠错，这是它非常适合长期跑推理任务的原因之一。二手卡到手后，第一步不是急着装环境，而是查看ECC错误计数。命令很简单：

nvidia-smi -q -d ECC

看Volatile和Aggregate两个字段，Volatile代表开机以来的瞬时错误，Aggregate是累积计数。单bit（Single Bit）错误少量出现问题不大，ECC能自动纠正；但如果Double Bit错误持续增长，说明显存颗粒可能已经开始不稳定，跑长任务随时可能触发CUDA错误。

我在这次部署中就有一次经历：模型加载后跑了两个钟头，突然出现计算错误，排查一圈发现是另一张卡的Aggregate Double Bit计数在增加。处理方式是先重启机器排除瞬时状态，然后在BIOS里把卡的供电策略调保守一点，同时用nvidia-smi --ecc-config=1强制开启ECC，让硬件做纠错。V100开ECC会损失约6%可用显存，但换来稳定性非常值得，尤其跑30B级模型一次推理的时间那么长，中途崩一下代价太大。

3. QUASAR-NVFP4量化格式解析：V100没有FP4单元凭什么能跑

3.1 NVFP4到底怎么存数：E2M1与分组缩放

NVFP4是NVIDIA定义的4-bit浮点格式，核心规格是E2M1：1位符号、2位指数、1位尾数。什么意思呢？它表示的数比传统4-bit整数格式（比如INT4）动态范围更大，接近浮点的分布特性，更适合神经网络权重那种"大部分值集中在0附近，偶尔有大的离群值"的分布。

但只有4位不可能表示足够精确的数值，所以NVFP4的关键设计是"分组量化+FP32缩放因子"。实际存储时，每128个权重值共享一个FP32的scale参数，存储时保存量化后的4-bit值和scale；计算时用scale反量化回浮点。这样的好处是：即便单个4-bit值只有15种可表示状态，但乘以合适的scale后，每个组内都有高精度的动态范围。对MoE模型来说，专家矩阵的权重分布差异大，分组缩放能显著降低量化误差。

3.2 V100上的真实执行路径：FP4存储、FP16计算

V100的Tensor Core支持FP16和INT8，但不支持FP8和FP4。那怎么跑NVFP4模型？答案在于：NVFP4是"存储精度"，不是"计算精度"。1Cat-vLLM的实际执行路径是这样的：

• 模型权重在磁盘和显存中以FP4格式存放，显存占用减半；
• 执行GEMM时，自定义kernel把FP4权重从显存加载到寄存器/SRAM，解码成FP16；
• 解码后的FP16矩阵在V100的Tensor Core上做标准矩阵乘。

这里有个很关键的性能逻辑：V100的HBM2带宽约900GB/s（16GB版），FP16权重加载开销大，而FP4格式把加载数据量削减一半以上。虽然多了一步反量化，但反量化在SM内部完成，不占用HBM带宽。对于推理这种访存密集负载，省下来的显存带宽比多出来的计算开销更值钱。这就是为什么V100这种不带FP4单元的卡，跑量化模型反而比FP16版本整体更快的底层原因。

3.3 量化结果怎么看：三档量化模型对比

如果你见过"开源模型量化档排名"这类讨论，会发现不同量化精度之间的规律基本是：FP16效果最好但显存最大，INT8是安全退路，FP4/NVFP4显存最小但需要慎用。放在V100这种老卡上，我的建议是：

对QUASAR这种35B级模型，双16GB V100其实只有NVFP4一条路。既然没有别的选择，重点就是如何把量化质量保住。实际用下来，模型在长文本生成和指令跟随上的损失可以接受，数学推理上比FP16弱一些但不算明显崩坏。这个代价换来的是从"不能跑"到"能跑"的质变。

4. 1Cat-vLLM部署实操：从源码安装到双卡推理服务

4.1 环境依赖与源码编译

部署前先把基础环境理清楚。我的建议环境是Ubuntu 22.04、CUDA 12.x、Python 3.10/3.11。V100的算力是7.0，CUDA 12.x依然支持sm_70，所以编译不会有问题；不建议追新CUDA 13，那种版本对Volta的兼容性已经出现松动。

1Cat-vLLM的安装我推荐源码编译方式。先按照项目仓库README把依赖装齐，然后在项目根目录执行：

pip install -e .

编译过程会构建自定义的量化kernel，耗时要看机器性能，通常十几分钟到半小时。如果编译过程中报flash-attn相关错误，多半是flash-attn版本和CUDA版本不匹配。处理办法是不让它强制安装，改用项目要求的指定版本，或者直接设环境变量在V100上走eager模式兜底。

4.2 模型权重获取与目录准备

模型权重建议放在一个纯路径里，不要带中文和空格。将Quasar-NVFP4的模型目录准备好后，注意检查里面的配置文件是否包含quantization_config字段。如果字段缺失，启动时需要手动指定--quantization nvfp4；如果字段写着fp4或者nvfp4，1Cat-vLLM会自动识别。

我习惯先单独验证一下权重目录的完整性和tokenizer文件：

python -c "from transformers import AutoTokenizer; AutoTokenizer.from_pretrained('/path/to/QUASAR-NVFP4'); print('ok')"

这个步骤能提前暴露目录结构问题，避免后面启动服务时才发现tokenizer加载失败。

4.3 启动服务的完整命令与参数解读

服务启动命令如下，这段配置我在双卡V100上实测可用：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/QUASAR-NVFP4 \ --served-model-name QUASAR \ --quantization nvfp4 \ --dtype float16 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --max-num-seqs 16 \ --port 8000

逐个说下关键参数。--quantization nvfp4是1Cat-vLLM注册的量化入口，告诉后端按NVFP4格式解析权重；--dtype float16指定计算精度，因为V100不支持BF16 Tensor Core，所以统一用float16；--tensor-parallel-size 2是把模型按TP切分到两张卡上，这是双卡部署最重要的参数；--gpu-memory-utilization 0.92表示每张卡允许vLLM占用92%显存，留一点给CUDA context和其他开销；--max-model-len 32768是上下文上限，如果业务对长文本需求不强烈，可以降到16384，能换来更大的KV cache和并发能力。

4.4 验证接口与常见启动报错

启动后看到Application startup complete和监听端口号，服务就算起来了。用curl验证一下：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "QUASAR", "prompt": "用一句话介绍人工智能", "max_tokens": 64, "temperature": 0.7 }'

能正常返回choices就说明链路通了。

常见启动报错我列几个自己踩过的：一是shared memory相关的Bus error，多半是Docker容器或系统的/dev/shm太小，TP=2模式下两个worker进程需要共享权重页，Docker启动要加--shm-size=10g；二是ValueError: Unknown quantization method: nvfp4，说明你用的vLLM不是1Cat-vLLM，或者分支版本太旧；三是CUDA error: out of memory，多半是--gpu-memory-utilization给太高，TP初始化时CUDA context申请不到空间，适当降到0.88再试。

5. 双卡实测：吞吐、显存与把V100压到极限的经验

5.1 显存占用分布：权重量化省下的都给了KV cache

模型加载完成后用nvidia-smi观察显存，两张卡的显存占用非常均衡，基本都在14GB左右。其中权重占9GB左右，剩下的空间被PagedAttention按需分配给KV cache。这一步的收获很直观：如果不量化，这个模型根本进不来；量化之后，KV cache的余量反而比很多小模型还宽裕。长上下文的业务要的就是这个效果。

--gpu-memory-utilization 0.92这个值不是无脑越高越好。V100上跑CUDA图形时，如果显存被压得太满，kernel并发调度可能失败。我的经验是0.90到0.93是甜点区间，超过0.95就容易出现"CUDA error 2: out of memory"这种不是真OOM但确实分配失败的问题。

5.2 吞吐量实测与并发调优

吞吐量方面，我没有把具体数字当标杆来宣传，但可以给一个参考趋势：在8并发、输出200~500 token的常规负载下，双卡整体吞吐能稳定跑在几十到一百多token每秒的区间，远满足内部工具链使用。对比同模型FP16在四卡上的表现，双卡量化方案的速度大约有20%~50%的领先，原因是前面说的带宽优势。

并发调优的关键参数是--max-num-seqs。V100的SM数量多，但单卡算力不如新卡，所以更适合"小批量多长度混合"的调度模式。max-num-seqs太小会导致GPU利用率不足，太大会挤占KV cache或触发排队延迟。我实测16到24之间比较合适，你可以用vllm benchmark脚本跑一轮，或者直接在业务侧压测看首token延迟和整体吞吐的平衡点。

5.3 TP=2在无NVLink的PCIe平台上的通信问题

没有NVLink是这套平台最大的物理短板。V100的SXM2版本有NVLink，但PCIe版本只能走PCIe 3.0 x16，双向带宽大约16GB/s。FP16模型在做TP=2时，每层forward都要做allreduce同步激活值，通信量很大；而NVFP4模型因为权重本身就是4-bit，反量化发生在GEMM之前，通信的主要是较小的激活值部分，整体压力大幅下降。

实测中我发现一个有意思的现象：FP16权重时，两张卡之间的PCIe通信能把PCIe带宽吃到70%以上，GPU利用率反而只在50%上下徘徊；换成NVFP4后，通信占比下降明显，GPU利用率能拉到80%以上。所以这套方案在X99这种无NVLink平台上，优势被进一步放大。如果条件允许，尽量让两张卡插在直连CPU的槽位上，别经过PCH芯片组转接，否则延迟会增加，P2P还可能直接不可用。可以用nvidia-smi topo -m检查拓扑，确认两卡之间是否有P2P能力。

5.4 跑长任务时最该小心的三件事

第一件是共享内存。刚才提到过/dev/shm太小会导致TP worker之间共享权重失败，但即使服务启动成功，长时间运行后共享内存被碎块化也可能触发相同错误。建议在系统层面就把共享内存调大，比如mount -o remount,size=16G /dev/shm，一劳永逸。

第二件是ECC错误复发。如果长时间跑高负载任务后出现不明CUDA错误，第一反应应该是看ECC计数，而不是怀疑软件配置。若Volatile Double Bit从0变成几次，说明硬件层面的纠错能力被击穿了。此时建议降低gpu-memory-utilization让显存控制器稍微喘口气，并观察是否继续增长；真要是持续增长，老老实实换卡，别硬撑。

第三件是CUDA graph与V100的兼容性。有几次我刻意开启CUDA graph加速，反而在捕获阶段报错。1Cat-vLLM在V100上如果走CUDA graph路径不稳定，可以加--enforce-eager参数禁用图模式。代价是每次请求都重新调度，吞吐略有下降，但稳定性明显提升。老卡上稳妥比微小的性能提升重要。

6. 最后聊几句：这套方案适合什么人、不适合什么人

如果你问我这套"2×V100 + QUASAR-NVFP4 + 1Cat-vLLM"的组合到底值不值得搞，我的回答是：看场景。如果你的业务就是提供一个中等并发的内部对话接口，对首token延迟不敏感，预算又有限，这套方案性价比极高。二手V100价格很低，加上一套X99平台，整个硬件成本可能还不如一张新卡贵，却能跑35B级量化模型，长上下文能力还很强。

但如果你追求高并发、大批量推理，或者需要低延迟响应，V100已经不适合了——再量化也弥补不了算力代差。另外，如果模型效果在这个量化精度下无法满足业务要求，也别硬刚，换个8-bit量化方案或者上更大显存的新卡才是正路。

我个人在实际操作中的体会是：做这类老卡部署，最大的障碍不是性能，而是信息差。文档不会告诉你V100该选哪个驱动分支、TP=2该给/dev/shm留多少、FP4权重在老卡上究竟走什么执行路径。把这些问题一个个摸清楚，老卡依然能发挥余热。这篇文章里提到的流程和命令，都是我实际验证过的东西，希望帮你少走几步弯路。下次如果你手里也恰好躺着几块吃灰的V100，不妨照着这个思路重新算一笔账——很多模型不是跑不动，是没找到合适的跑法。