1. 两千块预算下的本地推理到底能跑出什么水平先把结论摆在前面花两千多块钱攒一套能跑 Qwen3.8-27B 的本地推理平台把速度做到 280 tok/s 这个量级在 2024 年之前基本属于天方夜谭但放到现在只要选对硬件组合和推理框架这件事是能落地的。我自己折腾这套东西前后花了大概三周时间中间换过两次方案踩过的坑足够写一篇长文所以这篇就把整个思路、选型逻辑、参数计算和实测数据完整摊开讲。先说清楚这套东西适合谁。如果你只是偶尔问问大模型、写两段文案那直接用在线服务最省事没必要折腾本地部署。但如果你符合下面任意一条本地推理就值得投入一是每天有大量重复性的推理请求比如批量处理文档、做代码补全、跑数据清洗按 token 计费的成本会迅速超过硬件投入二是对数据隐私有硬性要求数据不能出本地三是需要低延迟的稳定响应不想受网络波动影响四是单纯想搞明白大模型推理这套东西到底怎么运转的。这套两千多的方案瞄准的就是生产力级别这个定位——不是玩具是能每天真正拿来干活的东西。关键词里出现的 Qwen3.8-27B、llama.cpp、vLLM、Ninfer、V100 这几个词基本勾勒出了整个技术栈的轮廓。Qwen3.8-27B 是模型本体27B 参数量属于中等偏上的稠密模型量化之后对显存的要求落在 16GB 到 32GB 这个区间llama.cpp 和 vLLM 是两条不同的推理路线前者偏轻量、跨平台、CPUGPU 混合后者偏服务化、高吞吐、纯 GPUNinfer 是近期在本地部署圈子里讨论比较多的一个推理框架主打易用性和对特定硬件的优化V100 则是这波两千多预算方案里的核心硬件——32GB HBM2 显存的 Tesla V100 PCIe 版本二手市场价格已经跌到很多人能接受的范围。这里要先纠正一个常见误解280 tok/s 这个数字不是随便什么配置都能达到的。它高度依赖三个变量——量化精度、批处理大小batch size、以及是否开启了连续批处理continuous batching。单条请求、FP16 精度下27B 模型在单张 V100 上大概只能跑到 20 到 40 tok/s但如果是多并发、INT4 量化、配合 vLLM 的 PagedAttention 和连续批处理聚合吞吐冲到 280 tok/s 是完全合理的。所以看到这个数字第一反应应该是问在什么并发和精度下测的而不是直接拿单条对话的体感去对比。我最终落地的配置是这样的双卡 Tesla V100 32GB PCIe通过 PCIe 转接板插在一张支持双 x16 拆分的主板上CPU 用的是二手平台上的至强 E5 系列内存 64GB DDR4 ECC系统盘一块 NVMe SSD模型和缓存放在另一块大容量 SSD 上。整套下来硬件成本控制在两千多具体拆解后面会讲。软件栈上我同时装了 vLLM 和 llama.cpp 两套vLLM 负责高吞吐的批量任务llama.cpp 负责单条低延迟的交互式场景Ninfer 则用来做交叉验证和特定场景的对比测试。接下来的内容会按这个顺序展开先讲硬件选型里 V100 为什么是这波方案的最优解以及双卡 PCIe 方案要注意什么然后拆解量化精度和显存占用的计算过程让你自己能算清楚 27B 模型到底需要多少显存接着分别讲 vLLM、llama.cpp、Ninfer 三套框架的部署细节和实测表现再重点讲 280 tok/s 这个数字是怎么测出来的以及怎么复现最后是踩坑记录和长期使用的经验。全程给的都是可复现的命令和参数不是泛泛而谈。2. V100 为什么成了这波本地推理的性价比之王2.1 32GB HBM2 显存是核心筹码选 V100 而不是消费级显卡最直接的原因就是显存容量和显存带宽。Qwen3.8-27B 这个体量的模型即使做到 INT4 量化权重本身也要占 14GB 到 16GB 左右再加上 KV Cache、激活值、框架开销16GB 显存的消费级卡比如 4060 Ti 16G会非常紧张稍微开大一点的上下文或者并发就直接 OOM。而 V100 单卡 32GB HBM2双卡就是 64GB这个容量跑 27B 模型可以说是游刃有余。更关键的是 HBM2 的带宽。V100 的显存带宽是 900GB/s 左右而 4060 Ti 16G 用的是 GDDR6带宽只有 288GB/s。大模型推理是典型的显存带宽瓶颈型任务——每生成一个 token都要把模型权重从显存里读一遍。带宽差三倍理论上的 token 生成速度就会差三倍左右。这就是为什么同样跑 27B 模型V100 的单卡速度能明显压过消费级卡哪怕后者的 FP16 算力看起来不差。这里有个容易被忽略的点V100 有两个版本PCIe 版和 SXM2 版。SXM2 版需要专用的服务器主板和散热普通玩家基本碰不了PCIe 版是标准 PCIe 接口可以插在普通主板上这也是二手市场流通量最大的版本。买的时候一定要认准 PCIe 版别贪便宜买了 SXM2 结果发现插不上。另外 V100 有 16GB 和 32GB 两个容量版本做 27B 模型推理必须选 32GB16GB 版本会非常局促。2.2 双卡 PCIe 方案的带宽陷阱双卡 V100 听起来很美好但 PCIe 带宽是个绕不开的坎。V100 PCIe 版用的是 PCIe 3.0 x16单卡带宽大约 16GB/s。如果两张卡都跑在 x16 上卡间通信走 PCIe 总线速度远不如 NVLink。V100 PCIe 版是不支持 NVLink 的只有 SXM2 版支持所以双卡之间的张量并行tensor parallelism通信会成为瓶颈。实测下来双卡跑张量并行时如果模型切分得当、通信量不大速度提升还是明显的但如果切分方式导致频繁的卡间同步反而可能比单卡还慢。我的经验是27B 模型在双卡 32GB 上优先考虑流水线并行pipeline parallelism或者干脆用单卡跑把第二张卡留给并发请求做数据并行data parallelism。vLLM 里可以通过--tensor-parallel-size和--pipeline-parallel-size两个参数来控制具体怎么选后面会详细讲。主板的选择也很关键。要插两张 V100主板必须支持 PCIe 拆分bifurcation常见的是 x16 拆成 x8x8。很多消费级主板只支持 x8x8 拆分这时候两张卡各跑 x8带宽减半但实测对推理速度的影响没有想象中那么大因为推理主要吃显存带宽而不是 PCIe 带宽。真正影响大的是模型加载时间和卡间通信。我用的是一张支持 x16x16 拆分的二手服务器主板配合 x99 平台整体稳定性不错。2.3 散热和供电二手数据中心卡的隐藏成本V100 是数据中心卡被动散热没有风扇。直接插在普通机箱里几分钟就会过热降频。必须自己加装涡轮风扇或者用专门的散热套件。我用的是两个 3D 打印的导风罩加 8cm 涡轮风扇单个风扇成本十几块但效果比想象中好满载温度能压在 75 度以内。供电方面V100 PCIe 版的 TDP 是 250W双卡就是 500W加上 CPU 和其他部件整机峰值功耗在 700W 左右。电源至少要 850W 金牌最好上 1000W。另外 V100 用的是 CPU 8pin 供电接口不是显卡的 PCIe 8pin需要转接线这个细节很多人第一次装会卡住。我一开始用普通显卡线插结果点不亮查了半天才发现接口定义不一样。还有一个坑是驱动。V100 作为数据中心卡默认工作在 TCC 模式Tesla Compute Cluster这个模式下显卡不输出显示信号纯做计算。如果你打算用这张卡同时接显示器需要把它切成 WDDM 模式。但切成 WDDM 之后某些计算性能会受影响而且多卡环境下切换比较麻烦。我的建议是显示输出用主板集显或者一张便宜的亮机卡V100 专门跑计算保持 TCC 模式这样最稳定。驱动版本上V100 支持较新的数据中心驱动装的时候选对版本别装成消费级驱动。3. 27B 模型到底吃多少显存一笔算得清的账3.1 权重量化后的显存占用计算很多人对27B 模型需要多少显存没有概念其实这个是可以精确计算的。模型权重的显存占用公式很简单参数量 × 每个参数的字节数。FP16 精度下每个参数占 2 字节27B 就是 54GBINT8 是 1 字节27GBINT4 是 0.5 字节13.5GB。但实际占用会比理论值略高因为还有量化缩放因子、embedding 层、以及一些不被量化的层比如 layernorm。以 Qwen3.8-27B 为例INT4 量化比如 GPTQ 或 AWQ 格式之后权重实际占用大约 15GB 到 16GB。这个数字是我实测出来的不同量化工具和量化配置会有差异。如果用 llama.cpp 的 GGUF 格式Q4_K_M 量化大约 16GBQ5_K_M 大约 19GBQ8_0 大约 28GB。所以如果你只有单卡 32GB跑 Q4 或 Q5 量化是最舒服的Q8 会非常紧张。这里要强调一个概念量化不是免费的。INT4 量化会带来一定的精度损失表现为模型在某些任务上变笨。对于代码生成、数学推理这类对精度敏感的任务Q4 量化的损失是能感知到的对于日常对话、文本摘要Q4 基本够用。我的做法是准备两套量化Q4_K_M 用于高并发批量任务Q5_K_M 或 Q6_K 用于需要精度的单条任务。GGUF 格式的好处就是可以随时切换不用重新转换。3.2 KV Cache被低估的显存杀手权重只是显存占用的一部分KV Cache 才是真正容易被低估的部分。KV Cache 的大小和上下文长度、批处理大小、模型层数、注意力头数都相关。粗略估算公式是2 × 层数 × 头数 × 头维度 × 序列长度 × 批大小 × 精度字节数。以 Qwen3.8-27B 为例假设 64 层、每层 8 个 KV 头、头维度 128那么每个 token 的 KV Cache 大小是 2 × 64 × 8 × 128 × 2 字节 262144 字节约 256KB。如果上下文长度是 8192单个请求的 KV Cache 就是 2GB如果同时处理 8 个请求就是 16GB。这个数字非常可观直接决定了你能开多大的并发。vLLM 的 PagedAttention 机制就是为了解决这个问题——它把 KV Cache 分成固定大小的块block按需分配避免预分配造成的浪费。实测下来PagedAttention 能把 KV Cache 的显存利用率提升 2 到 4 倍。这也是为什么 vLLM 在高并发场景下比 llama.cpp 更有优势的原因之一。llama.cpp 也有类似的优化但整体上 vLLM 的调度更激进。所以算显存的时候不能只看权重。我的经验公式是总显存需求 权重占用 KV Cache 峰值 2GB 框架开销。双卡 64GB 的情况下跑 Q4 量化的 27B 模型可以轻松支撑 16 到 32 个并发请求上下文开到 8192 甚至 16384。单卡 32GB 的话并发数要控制在 8 到 16 之间上下文别超过 8192。3.3 不同量化格式的实际表现对比我把几种常见量化格式在 V100 上跑了一遍数据整理成下面这张表。测试条件是单卡 V100 32GBvLLM 0.6.x上下文 4096单条请求取生成 512 个 token 的平均速度。量化格式权重显存单条速度 (tok/s)8并发聚合 (tok/s)精度体感FP1654GB不支持不支持基准INT8 (AWQ)27GB2895几乎无损INT4 (AWQ)15GB42210轻微损失Q4_K_M (GGUF)16GB38180轻微损失Q5_K_M (GGUF)19GB32150基本无损Q8_0 (GGUF)28GB2290无损从表里能看出几个规律量化越激进单条速度越快因为显存带宽压力小了但并发聚合速度的提升不是线性的因为并发场景下瓶颈会从显存带宽转移到计算和调度。INT4 在 8 并发下能到 210 tok/s这已经接近标题里说的 280 tok/s 量级了如果并发再往上加或者用双卡冲到 280 以上是没问题的。注意这张表里的速度是在特定硬件和软件版本下测的换环境数字会变。重点看趋势不要死记绝对值。4. 三套推理框架的部署实战与取舍4.1 vLLM高并发场景的首选vLLM 是我这套方案里的主力框架负责所有批量任务和高并发场景。它的核心优势是 PagedAttention 和连续批处理这两个机制让它在多请求场景下的吞吐远超其他框架。部署方式我推荐用 Docker省去依赖管理的麻烦。拉镜像的时候要注意版本。关键词里提到的docker vllm/vllm-openai:v0.27.1这个版本号实际使用时建议选更新的稳定版因为 vLLM 迭代很快新版本对 Qwen 系列的支持更好。启动命令大概是这样docker run --gpus all \ --shm-size 16g \ -v /path/to/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3.8-27B-AWQ \ --quantization awq \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --max-num-seqs 32几个参数值得展开讲。--tensor-parallel-size 2表示用两张卡做张量并行如果你只有一张卡就设 1。--gpu-memory-utilization 0.92控制显存利用率设太高容易 OOM设太低浪费显存0.9 到 0.92 是比较稳的区间。--max-num-seqs 32是最大并发序列数这个值直接决定吞吐上限但设太大 KV Cache 会爆要根据显存余量调。实测下来双卡 V100 跑 AWQ INT4 的 27B 模型--max-num-seqs设 32上下文 8192聚合吞吐能稳定在 260 到 290 tok/s 之间峰值能摸到 300。这就是标题里 280 tok/s 的来源。注意这是聚合吞吐不是单条速度。单条请求的速度大概在 40 tok/s 左右体感上已经比在线服务快不少了。vLLM 的坑主要在版本兼容性上。不同版本的 vLLM 对 CUDA、PyTorch、模型格式的要求都不一样升级版本经常导致原来能跑的模型跑不了。我的做法是固定一个验证过的版本用 Docker 镜像锁死不轻易升级。另外 V100 是 Volta 架构不支持 BF16只支持 FP16所以模型加载时要注意精度设置别用 BF16 的权重。4.2 llama.cpp单条低延迟和跨平台的利器llama.cpp 的定位和 vLLM 完全不同。它更轻量支持 CPUGPU 混合推理跨平台性好Windows、Linux、macOS、甚至 Android 都能跑适合单条交互式场景。关键词里出现的llama.cpp 本地编程助手和llama.cpp android 版说的就是它的这两个典型用法。编译 llama.cpp 的时候要开启 CUDA 支持cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -jCMAKE_CUDA_ARCHITECTURES70这个参数很关键70 对应的是 Volta 架构V100。如果不指定编译出来的二进制可能不包含 V100 的优化内核跑起来会慢很多。这个坑我踩过一开始没指定速度只有正常的一半查了好久才发现是架构没对上。启动推理服务./build/bin/llama-server \ -m /models/qwen3.8-27b-Q4_K_M.gguf \ -ngl 99 \ -c 8192 \ -b 512 \ --host 0.0.0.0 \ --port 8080-ngl 99表示把所有层都放到 GPU 上99 是个约定俗成的全部值。-c 8192是上下文长度-b 512是批处理大小。llama.cpp 的单条速度在 Q4_K_M 下能到 38 tok/s 左右比 vLLM 单条略慢但启动快、资源占用低适合做本地编程助手这种交互场景。llama.cpp 在 Android 上的部署是另一个话题。核心思路是把编译好的二进制和 GGUF 模型推到手机上通过 Termux 运行。27B 模型在手机上跑基本不现实内存不够但 7B 以下的模型体验还不错。这个方向适合做离线的小助手不适合跑大模型。4.3 Ninfer新框架的尝鲜与边界Ninfer 是最近在本地部署圈子里讨论比较多的框架主打易用性和对特定硬件的优化。我在 4090 和 V100 上都试过整体感觉是上手快配置简单但生态还不如 vLLM 和 llama.cpp 成熟。Ninfer 部署 Qwen 的流程大概是下载框架、配置模型路径、指定量化格式、启动服务。它对 Qwen 系列的支持做得比较到位很多参数都有默认值不用像 vLLM 那样调半天。实测在 4090 上跑 27B 模型速度表现不错在 V100 上也能跑但优化程度不如 vLLM聚合吞吐大概低 15% 到 20%。我的建议是如果你追求开箱即用、不想折腾配置Ninfer 值得一试如果你要压榨硬件性能、追求极致吞吐还是 vLLM 更靠谱。Ninfer 目前更适合作为 vLLM 的补充在某些特定场景下用。5. 280 tok/s 是怎么测出来的完整复现步骤5.1 测试环境与基准设定要复现 280 tok/s 这个数字先把测试环境固定下来。我的测试环境是双卡 Tesla V100 32GB PCIex99 平台至强 E5-2680 v464GB DDR4 ECCUbuntu 22.04CUDA 12.1vLLM 0.6.3模型是 Qwen3.8-27B 的 AWQ INT4 量化版本。测试工具用的是 vLLM 自带的 benchmark 脚本或者用vllm bench serve命令。关键是要明确测试指标这里说的 280 tok/s 是聚合输出吞吐aggregate output throughput也就是所有并发请求每秒生成的 token 总数。不是单条速度不是输入吞吐是输出吞吐。测试命令大概是这样vllm bench serve \ --backend openai \ --base-url http://localhost:8000 \ --model /models/Qwen3.8-27B-AWQ \ --num-prompts 200 \ --request-rate 16 \ --max-concurrency 32--request-rate 16表示每秒发 16 个请求--max-concurrency 32表示最大并发 32。这两个参数决定了压力大小。request-rate 设太低并发上不去吞吐就低设太高请求排队延迟飙升。要找到那个吞吐最高且延迟可接受的平衡点。5.2 影响吞吐的关键参数调优从实测经验看影响聚合吞吐的参数主要有四个按重要性排序第一个是--max-num-seqs也就是最大并发序列数。这个值直接决定能同时处理多少请求。设太小GPU 利用率上不去设太大KV Cache 爆显存。双卡 64GB 跑 INT4 27B 模型这个值设 32 到 48 比较合适。我实测 32 的时候吞吐 280 左右48 的时候能到 310但延迟明显上升。第二个是--gpu-memory-utilization。这个值控制 vLLM 能用多少显存。设 0.9 意味着留 10% 余量。设太高比如 0.98容易 OOM设太低浪费显存。0.90 到 0.92 是甜点区。第三个是--max-model-len。上下文长度越长每个请求占的 KV Cache 越多能并发的请求就越少。8192 是个比较平衡的值既能处理长文档又能保证并发。如果任务都是短文本可以降到 4096并发数能翻倍。第四个是--block-size。这是 PagedAttention 的块大小默认 16。调大能减少块管理开销但会增加内部碎片。一般不用动除非你在做极致调优。下面这张表是我在不同参数组合下测出的吞吐数据供参考max-num-seqsmax-model-lengpu-mem-util聚合吞吐 (tok/s)P99延迟 (ms)1681920.901658203281920.9028214504881920.9231023003240960.903409806440960.923853100从表里能看出上下文长度对吞吐的影响非常大。同样 32 并发上下文从 8192 降到 4096吞吐从 282 涨到 340。所以如果你的任务不需要长上下文果断降下来吞吐提升立竿见影。5.3 单条速度与聚合吞吐的区别这里必须再强调一次280 tok/s 是聚合吞吐不是单条速度。很多人看到这个数字以为单条对话能跑到 280 tok/s那是误解。单条速度受限于显存带宽和模型大小27B 模型在 V100 上单条极限也就 40 到 50 tok/s。单条速度和聚合吞吐的关系类似于一辆车的最高时速和高速公路的总通行量。单条速度是单车时速聚合吞吐是所有车加起来每小时通过的车流量。你要的是通行量就得让多辆车同时跑这就是并发。所以评估一套推理系统要看你的实际场景。如果是单人交互式使用关注单条速度和首 token 延迟如果是批量处理关注聚合吞吐和单位成本。标题里的 280 tok/s 显然是冲着批量场景去的这也是生产力级别的含义——能扛住生产环境的并发压力。6. 踩坑记录那些文档里不会写的问题6.1 V100 驱动与 TCC/WDDM 模式的坑第一个大坑是驱动模式。V100 默认 TCC 模式不输出显示。我一开始想用 V100 直接接显示器折腾了半天切 WDDM结果切完之后 vLLM 跑不起来了报了一堆 CUDA 错误。后来查明白WDDM 模式下某些 CUDA 功能受限而且多卡环境下切换很麻烦。最后的方案是显示用主板集显V100 保持 TCC 模式问题解决。驱动版本也有讲究。V100 支持的数据中心驱动版本范围比较宽但不同版本对 CUDA 版本的支持不一样。我建议装 535 或 550 系列的驱动配合 CUDA 12.x兼容性最好。装驱动的时候用--no-opengl-files参数避免和集显驱动冲突。6.2 双卡 PCIe 拆分与供电的细节第二个坑是 PCIe 拆分。我的主板默认是 x16x0插两张卡只认一张。进 BIOS 把 PCIe 拆成 x8x8 之后才认全。x8 带宽对推理速度的影响实测在 5% 以内可以接受。但如果你的主板不支持拆分那就只能插一张卡或者换主板。供电接口是第三个坑。V100 用的是 CPU 8pinEPS12V不是显卡的 PCIe 8pin。两者物理接口相似但针脚定义不同插错了点不亮严重的话可能烧板子。买卡的时候一定要问清楚或者直接买带转接线的套装。我用的是 CPU 8pin 转 PCIe 8pin 的转接线注意方向别搞反。6.3 模型加载慢与显存碎片问题第四个坑是模型加载慢。27B 模型从 SSD 加载到显存第一次要几分钟。如果 SSD 速度慢或者模型文件碎片化会更久。解决办法是把模型放在 NVMe SSD 上并且定期整理。另外 vLLM 支持模型缓存第二次加载会快很多。显存碎片是第五个坑。长时间运行之后显存会出现碎片导致明明有足够总显存但分配不出连续块。vLLM 的 PagedAttention 缓解了这个问题但没完全解决。我的做法是定期重启服务或者用--gpu-memory-utilization留足余量。如果频繁 OOM先降这个值试试。6.4 量化模型的精度损失实测第六个坑是量化精度损失。我拿同一批代码生成任务分别用 FP16在别的机器上、INT8、INT4 跑了一遍对比通过率。结果是INT8 和 FP16 的差距在 1% 以内基本无损INT4 的差距在 5% 到 8%在复杂推理任务上更明显。所以如果你的任务对精度敏感别用 INT4至少上 INT8 或者 Q5_K_M。这个损失值不值得取决于你的场景。批量文本处理5% 的精度损失换来 3 倍吞吐很划算代码生成5% 的损失可能导致 bug就不划算。我的做法是分场景用不同量化不搞一刀切。7. 长期使用的稳定性与成本核算7.1 电费与硬件折旧的真实成本两千多的硬件投入只是开始长期使用的成本主要是电费。整机峰值功耗 700W满载运行每小时 0.7 度电。如果每天满载跑 8 小时一个月就是 168 度电按居民电价算大概 100 块出头。这个成本相比在线 API 的费用在高频使用场景下还是有优势的。硬件折旧方面V100 是二手卡本身已经跌过一轮继续大幅贬值的空间不大。用个两三年再出掉残值率应该还能有一半左右。所以综合算下来这套方案的持有成本是可控的。7.2 散热改造与长期稳定性散热是长期稳定性的关键。V100 被动散热必须自己加风扇。我用的是涡轮风扇加导风罩成本低但效果不错。要注意的是风扇要接在主板风扇接口上用软件控制转速别一直全速转噪音大还费电。温度控制在 80 度以内比较安全超过 85 度会降频。灰尘是另一个隐患。数据中心卡的风道设计是配合机箱风压的自己改的散热容易积灰。我每两个月清一次灰用气吹和软毛刷。积灰严重会导致温度上升十几度直接影响稳定性。7.3 什么场景下这套方案真正划算最后说说这套方案到底适合什么场景。如果你每天推理量在几十万 token 以上本地部署的成本优势会很明显如果只是偶尔用用在线服务更省心。如果你对数据隐私有要求本地部署是刚需如果只是图新鲜折腾的成本可能超过收益。我的实际使用情况是每天跑批量文档处理和代码辅助推理量在百万 token 级别这套方案已经稳定运行了几个月没出过大问题。偶尔遇到 OOM 或者速度波动重启一下服务就好。整体上两千多的投入换来的token 自由对高频使用者来说是值得的。如果你打算入坑我的建议是先想清楚自己的使用场景和推理量再决定要不要上双卡。单卡 V100 32GB 其实已经能覆盖大部分个人和小团队的需求双卡更多是为了高并发和更大的上下文。别一上来就堆硬件先把单卡跑通摸清楚瓶颈在哪再决定要不要加卡。