1. 一个从吃灰服务器上挖出的结论老Xeon配V100能扛住现代大模型如果你手头有一台2016年采购的双路Xeon服务器平时只能拿来跑点老业务一块V100 32GB显卡插在上面已经快忘了它的存在那你大概和我一样默认这种机器是跑不动现代大模型的。我的实测结论完全相反Qwen Flash next 部署在这台机器上生成速度稳定在 20 tok/s响应节奏已经能作为内部工具被正常使用。为什么这个数字值得说因为很多人对老硬件的认知还停留在显存够但算力不够的层面。实际上大模型推理是带宽敏感型负载权重从显存搬到计算单元的速度往往比计算本身更关键。V100 的显存带宽放在今天也只是落后不是不能用配合合理的框架和量化策略它就是一台完全可用的本地推理机。这篇文章适合三类人一是公司或高校机房还有一批 V100、老Xeon 没被淘汰想低成本开个内部模型服务的人二是手头预算有限、想用旧机器搭个离线模型环境的人三是对推理性能和硬件瓶颈有兴趣想搞清楚 tok/s 到底是受什么制约的人。我会把我实际的部署路径、测速方法和踩过的坑完整写出来你可以照着复现也可以只读原理部分作为参考。1.1 为什么老设备反而适合做私有化模型部署先泼一点冷水这台机器跑不了最新旗舰模型的全量精度也没必要跑。私有化部署的诉求通常是数据不出内网、可自主调用、延迟可以接受至于吞吐量能不能和云端比并不重要。一个 20 tok/s 的本地模型配合合适的工程封装足够胜任文档摘要、命名实体抽取、代码注释生成、客服话术辅助这类任务。更重要的是这种机器在不少单位里不是稀缺资源而是已经折旧完毕、没人争抢的闲置资源。把它们利用起来不需要新采购审批不需要机房扩容成本上几乎是零。之前很多人放弃老设备不是因为不能用而是因为新框架默认忽略老卡给了一点编译报错就劝退了。这篇文章要解决的正是怎么让老平台不被软件生态抛弃这件事。1.2 我是怎么验证这个结论的我不会只丢一个20 tok/s的结论。后面的内容会按这样的顺序展开先说清楚这台机器的具体配置和软件环境包括模型格式转换这种容易卡住的细节然后展示第一次测速得到的原始数据再用显存带宽公式解释 20 tok/s 背后的物理意义接着讲几个在老卡上特有的坑最后给出我从 20 调到 28 那两次关键调整的具体做法和最终参数。整套过程中我坚持的原则是每改一个变量只动一个东西测速前固定好 prompt 和上下文长度。这样得到的数据才有对比价值而不是靠感觉说变快了。2. 测试环境的完整清单Xeon、V100、驱动和模型格式转换2.1 服务器硬件与系统版本我用的是一台典型的 2016 年双路服务器具体配置如下表。这里值得注意的其实不是型号多老而是接口和带宽还够不够。部件配置备注CPU双路Xeon E5-2690 v4每颗14核28线程合计28核56线程主频2.6GHz内存128GB DDR4-24008条16GB内存通道填满GPUV100 32GBSXM2接口算力7.0NVLink互联系统Ubuntu 22.04 LTS内核5.15驱动基于CUDA 11.8的驱动这个版本和7.0算力兼容性最好存储系统盘NVMe SSD模型放本地SSD模型加载耗时约2分钟我特别提一下 SXM2 接口。V100 有 PCIe 版和 SXM2 版SXM2 版的显存带宽更高约 900GB/s功耗上限也更高。如果你手里是 PCIe 版同样模型很可能只有 12~15 tok/s这是接口和显存频率的差异不是软件问题。所以看到别人报的 tok/s 时先问一句用的是哪个版本否则对比没有意义。2.2 模型准备先把BF16切成FP16这步是绝大部分第一次在老卡上跑新模型的人都会卡住的地方。现在新发布的大语言模型不少直接给 BF16 权重而 V100 的 Tensor Core 只支持 FP16不支持 BF16。如果你直接把 BF16 权重丢给推理框架轻则警告重则直接报 dtype 不匹配。我的处理方式是先做一次精度转换把模型的 BF16 权重读取进来转换成 FP16 存盘。具体操作用一个能加载模型的 Python 脚本遍历权重表把 dtype 为 torch.bfloat16 的张量转成 torch.float16然后保存。核心代码大概长这样import torch state torch.load(model_pytorch.bin, map_locationcpu) for key, value in state.items(): if value.dtype torch.bfloat16: state[key] value.float().half() torch.save(state, model_fp16.bin)转换后的模型体积基本不变因为 BF16 和 FP16 都是 2 字节。转换完之后我一定要验证一下指定关键词的输出避免转换过程出现张量损坏。实测转换后生成质量和 BF16 几乎没有可感知差异整体损失可以忽略。2.3 推理框架的选型与第一次启动对老卡来说框架选择直接影响能否跑起来。我第一轮用的是社区里很流行的本地部署引擎部署简单依赖少对老 GPU 兼容性好第二轮换成面向高吞吐的服务化引擎做对比结论后面会展开。首轮启动命令大概是这样的./llama-server \ -m /models/qwen-flash-next-fp16.gguf \ --n-gpu-layers 99 \ -c 4096 \ --host 0.0.0.0 --port 8080这里-m指向转好的 FP16 GGUF 文件--n-gpu-layers 99表示把所有层都放进显存。第一次启动会做 CUDA kernel 编译和模型加载耗时大概两分钟。启动成功后我习惯先用一行命令测最小请求curl http://127.0.0.1:8080/v1/completions \ -H Content-Type: application/json \ -d {prompt:请用一句话介绍自己,max_tokens:64}返回正常时这个老平台就算跑通了。这一步的意义在于建立可用基线后续所有优化都围绕这个基线做对比。多说一句--n-gpu-layers 99这种写法是故意把层数设满的GPU 显存放得下就全部丢给 GPUCPU 只做调度和采样避免权重在 CPU 和 GPU 之间反复搬运。3. 20 tok/s的真实含义从带宽测算到性能归因3.1 一次规范的测速流程20 tok/s这种数字脱离测法就没有意义。我自己用的测法很固定单并发、流式输出固定一个 600 字左右的输入 prompt让模型不间断生成 200 个 token统计从第一个 token 到最后一个 token 的平均间隔。输入处理的时间单独记录不计入 decode 速度。下面是我记录的一组典型数据使用 FP16 权重上下文长度 4096未做量化指标数值输入长度768 tokens首token延迟约0.8秒decode速度20.1 tok/s端到端生成200 token耗时约10.5秒显存占用约28.5GB你看生成 200 个 token 约 10.5 秒平均每秒输出 20 个左右。这个速度下人读起来有轻微的等字出现的感觉但完全跟得上阅读节奏用于内部工具是合格的。3.2 用显存带宽反推速度上限我特别喜欢用带宽公式来校验实测数据这能快速判断一个数字是正常还是异常。大模型 decode 时每一步都要把全部权重从显存搬运到 SM计算量本身往往不是瓶颈带宽才是。粗略公式是理论上限 ≈ 显存带宽 / 每token需要搬运的显存数据量这台 V100 的显存带宽约 900GB/s。FP16 模型加载进显存后权重和 KV cache 合计占 28.5GB 左右那么每生成一个 token权重相关搬运至少是 28.5GB 的量级。900 除以 28.5理论极限其实只有约 31 tok/s。我们实测 20说明已经跑到理论极限的 65% 左右余量不大了。为什么达不到 100%因为还有 kernel 启动开销、注意力计算、CPU 和 GPU 的数据交换、以及显存读写本身并非纯顺序。65% 的利用率放在老卡上已经是相当健康的水平。我把这段写出来是想告诉你一个容易被忽略的事实在这类显存带宽不高不低的卡上模型越小越容易跑得快参数越大越吃带宽。这也是为什么量化往往比换更快的卡更划算。3.3 decode与prefill为什么要分开看老机器上还有一个典型现象输入处理比 decode 慢一个数量级。因为输入处理是密集计算非常吃 GPU 的 FP16 算力而 V100 的 Tensor Core 性能在今天的标准下确实不够看了。输入 768 token 跑一次输入处理耗时 0.8 秒均摊到每个输入 token 约 1ms这个数字放在新一代显卡上可以被虐哭但在老平台上是正常的。实际操作中我会针对输入处理做两件事。第一把输入 prompt 压缩改写能用 300 字表达清楚就不要用 1000 字第二尽量复用缓存相同前缀对话不要重复处理。这两点对交互体感的影响有时比优化 decode 速度更明显。4. 老卡上的几个隐蔽坑编译兼容、线程干扰与显存溢出4.1 算力7.0的软件兼容边界V100 的算力是 7.0而当前主流推理引擎为了新卡的算子优化经常会逐步放弃对 7.0 的编译支持。我踩到的第一个坑就是用最新版本框架编 CUDA kernel 时编译阶段直接提示架构不支持。解决办法是锁定旧版本或加编译参数。旧版本虽然功能少一些但对 7.0 的支持完备稳定性更好。这提醒我们老设备上追新的风险很高版本选型的第一原则是兼容性性能优化要在兼容基础上再做。遇到报错时我建议先搜错误信息中的sm_70或compute capability而不是直接换框架版本。能兼容 7.0 的版本列表通常很明确选定一个稳定版本后把它作为这台服务器的固定依赖轻易不要动。4.2 双路CPU的物理距离与线程调度双路 Xeon 看起来有 56 个线程似乎很充裕但在跑推理时线程调度不当会导致性能波动。NUMA非一致性内存访问结构下GPU 插在 PCIe 的某颗 CPU 侧模型数据和请求线程如果跨 CPU 访问内存时延会升高生成速度会不稳。我最初直接把线程数设成 56结果反而比设成 28 更慢。原因是调度器把负载分散到两颗 CPU 上跨 die 访问内存和 PCIe 链路开销比多线程带来的并发收益更大。改成将推理进程和 GPU 绑定在同一颗 CPU 的 14 个物理核上之后速度反而稳定在 20 以上。如果你也遇到CPU 占用不高但速度上不去的情况先查一下进程落在哪颗 CPU 上再决定要不要加numactl --cpunodebind之类的绑定参数。这条经验在双路服务器上非常常见单路机器反而不会遇到。4.3 显存用量为什么比估算高一截很多教程都会告诉你模型多少B就占多少GB显存但实测总是偏高。这个现象在老卡上尤其明显。V100 32GB 跑 FP16 模型理论权重只有不到 20GB但加载后总量跑到了 28.5GB接近上限。原因有三层KV cache 是按最大上下文预留的CUDA context 和算子临时缓存会额外占用碎片化导致显存无法完全复用。解决思路不是算精确值而是留出 20% 冗余。如果显存不够但有第二块 V100还可以把模型切到多卡。多卡时用 NVLink 互联吞吐损失不大但如果中间隔了 PCIe 交换机速度会掉一截建议先看拓扑再决定。4.4 千万别忽略的OOM表现显存溢出在老卡上表现得特别隐蔽。有时候不是直接报Out of memory而是生成到一半速度骤降甚至卡住几秒后输出乱码。我排查过一次最后发现是显存刚好卡在临界点框架开始偷偷把部分层回退到 CPU 计算速度自然崩了。我的经验是显存占用超过总容量 90% 时就要当心。要么缩短上下文长度要么换量化权重要么降低并发数。非要卡着临界点跑等于埋了一颗定时炸弹。5. 把速度再往上顶从20到28的两次有效调整5.1 第一刀压缩权重并保住精度从 FP16 改成 4bit 量化后模型权重从 28.5GB 降到 8GB 以内显存带宽公式里的每token搬运量大幅下降理论上限直接翻倍。我用了基于校准集的 4bit 量化方式生成质量在摘要类任务上几乎没有损失。量化后的实测速度到了 27~28 tok/s接近 FP16 时的 1.4 倍。这也验证了我前面的判断瓶颈在权重搬运压低权重体积是最有效的加速手段。要注意的是量化格式对老卡很有讲究V100 没有现代卡上针对低精度计算专门强化的路径所以别盲目选最小的 bit 数4bit 是一个平衡点再低的版本在 V100 上反而不稳定。5.2 第二刀绑定CPU与GPU的协作位置量化带来提速后我又做了一次进程绑定调整配合量化版本最终稳定到 28。做法是把服务进程和整条数据通路都放在同一 NUMA 节点上并给 CPU 设置明确的线程数而不是让框架自动探测 56 个线程。实际启动脚本大概长这样numactl --cpunodebind0 --membind0 \ ./llama-server \ -m /models/qwen-flash-next-q4_k.gguf \ -t 14 \ --n-gpu-layers 99 \ -c 4096在双路机器上这个调整带来的提升通常在 5%~10%但更重要的是稳定性峰值抖动明显减少连续请求时速度不再忽高忽下。5.3 用于日常服务的最终启动参数最终我保留的是下面这套参数组合作为这台服务器的日常服务配置参数项设定值原因权重格式4bitQ4_K显存占用与质量平衡线程数14单颗物理核数量避免跨NUMAGPU层数99全部层进显存上下文长度4096够内部工具使用显存可控并行槽位2控制显存和CPU开销这套配置下稳定速度约 28 tok/s显存占用约 7.5GB剩余空间足够放两路并发请求。对一台 2016 年的服务器来说这个结果已经很能打了。提示如果你的应用是一次输入很长、生成很短的类型不要只看 decode 速度重点优化输入处理和缓存命中如果是你来我往的聊天型decode 速度的意义更大。5.4 顺带验证过的并发表现我还测了量化后多并发的情况。2 并发时单路速度大约降到 22 tok/s但总吞吐提升到 44 tok/s 左右显存仍然稳在 10GB 以内。这说明只要权重体积下来了老卡的并发能力也随之释放。如果几位同事同时用可以把并行槽位调到 3~4依然比单路 FP16 的整体体验好不少。6. 尾声老设备适合哪种角色折腾完这台老服务器我个人的体会是硬件迭代在 LLM 推理场景里没有想象中那么绝对瓶颈解析和工程适配往往比直接换卡更值钱。老Xeon 加 V100 这套组合最终可以稳定承担内部辅助工具、批量文本分析、隔离网络环境模型服务这类角色作为生产力工具完全合格。我最后再分享一个小技巧如果你的服务器上还有其他业务在跑就把推理服务放到一个独占的 NUMA 节点上并用环境变量限制 GPU 可见性避免别的进程把显存挤爆。实际做法是设置CUDA_VISIBLE_DEVICES只暴露目标卡再配合numactl固定内存节点。这种给模型留一条独立通道的思路比反复调参更能保证长期稳定。如果你手里也有一台吃灰的老服务器不妨找个适合部署的模型试一次也许结果会和预期完全不一样。
1. 一个从吃灰服务器上挖出的结论老Xeon配V100能扛住现代大模型如果你手头有一台2016年采购的双路Xeon服务器平时只能拿来跑点老业务一块V100 32GB显卡插在上面已经快忘了它的存在那你大概和我一样默认这种机器是跑不动现代大模型的。我的实测结论完全相反Qwen Flash next 部署在这台机器上生成速度稳定在 20 tok/s响应节奏已经能作为内部工具被正常使用。为什么这个数字值得说因为很多人对老硬件的认知还停留在显存够但算力不够的层面。实际上大模型推理是带宽敏感型负载权重从显存搬到计算单元的速度往往比计算本身更关键。V100 的显存带宽放在今天也只是落后不是不能用配合合理的框架和量化策略它就是一台完全可用的本地推理机。这篇文章适合三类人一是公司或高校机房还有一批 V100、老Xeon 没被淘汰想低成本开个内部模型服务的人二是手头预算有限、想用旧机器搭个离线模型环境的人三是对推理性能和硬件瓶颈有兴趣想搞清楚 tok/s 到底是受什么制约的人。我会把我实际的部署路径、测速方法和踩过的坑完整写出来你可以照着复现也可以只读原理部分作为参考。1.1 为什么老设备反而适合做私有化模型部署先泼一点冷水这台机器跑不了最新旗舰模型的全量精度也没必要跑。私有化部署的诉求通常是数据不出内网、可自主调用、延迟可以接受至于吞吐量能不能和云端比并不重要。一个 20 tok/s 的本地模型配合合适的工程封装足够胜任文档摘要、命名实体抽取、代码注释生成、客服话术辅助这类任务。更重要的是这种机器在不少单位里不是稀缺资源而是已经折旧完毕、没人争抢的闲置资源。把它们利用起来不需要新采购审批不需要机房扩容成本上几乎是零。之前很多人放弃老设备不是因为不能用而是因为新框架默认忽略老卡给了一点编译报错就劝退了。这篇文章要解决的正是怎么让老平台不被软件生态抛弃这件事。1.2 我是怎么验证这个结论的我不会只丢一个20 tok/s的结论。后面的内容会按这样的顺序展开先说清楚这台机器的具体配置和软件环境包括模型格式转换这种容易卡住的细节然后展示第一次测速得到的原始数据再用显存带宽公式解释 20 tok/s 背后的物理意义接着讲几个在老卡上特有的坑最后给出我从 20 调到 28 那两次关键调整的具体做法和最终参数。整套过程中我坚持的原则是每改一个变量只动一个东西测速前固定好 prompt 和上下文长度。这样得到的数据才有对比价值而不是靠感觉说变快了。2. 测试环境的完整清单Xeon、V100、驱动和模型格式转换2.1 服务器硬件与系统版本我用的是一台典型的 2016 年双路服务器具体配置如下表。这里值得注意的其实不是型号多老而是接口和带宽还够不够。部件配置备注CPU双路Xeon E5-2690 v4每颗14核28线程合计28核56线程主频2.6GHz内存128GB DDR4-24008条16GB内存通道填满GPUV100 32GBSXM2接口算力7.0NVLink互联系统Ubuntu 22.04 LTS内核5.15驱动基于CUDA 11.8的驱动这个版本和7.0算力兼容性最好存储系统盘NVMe SSD模型放本地SSD模型加载耗时约2分钟我特别提一下 SXM2 接口。V100 有 PCIe 版和 SXM2 版SXM2 版的显存带宽更高约 900GB/s功耗上限也更高。如果你手里是 PCIe 版同样模型很可能只有 12~15 tok/s这是接口和显存频率的差异不是软件问题。所以看到别人报的 tok/s 时先问一句用的是哪个版本否则对比没有意义。2.2 模型准备先把BF16切成FP16这步是绝大部分第一次在老卡上跑新模型的人都会卡住的地方。现在新发布的大语言模型不少直接给 BF16 权重而 V100 的 Tensor Core 只支持 FP16不支持 BF16。如果你直接把 BF16 权重丢给推理框架轻则警告重则直接报 dtype 不匹配。我的处理方式是先做一次精度转换把模型的 BF16 权重读取进来转换成 FP16 存盘。具体操作用一个能加载模型的 Python 脚本遍历权重表把 dtype 为 torch.bfloat16 的张量转成 torch.float16然后保存。核心代码大概长这样import torch state torch.load(model_pytorch.bin, map_locationcpu) for key, value in state.items(): if value.dtype torch.bfloat16: state[key] value.float().half() torch.save(state, model_fp16.bin)转换后的模型体积基本不变因为 BF16 和 FP16 都是 2 字节。转换完之后我一定要验证一下指定关键词的输出避免转换过程出现张量损坏。实测转换后生成质量和 BF16 几乎没有可感知差异整体损失可以忽略。2.3 推理框架的选型与第一次启动对老卡来说框架选择直接影响能否跑起来。我第一轮用的是社区里很流行的本地部署引擎部署简单依赖少对老 GPU 兼容性好第二轮换成面向高吞吐的服务化引擎做对比结论后面会展开。首轮启动命令大概是这样的./llama-server \ -m /models/qwen-flash-next-fp16.gguf \ --n-gpu-layers 99 \ -c 4096 \ --host 0.0.0.0 --port 8080这里-m指向转好的 FP16 GGUF 文件--n-gpu-layers 99表示把所有层都放进显存。第一次启动会做 CUDA kernel 编译和模型加载耗时大概两分钟。启动成功后我习惯先用一行命令测最小请求curl http://127.0.0.1:8080/v1/completions \ -H Content-Type: application/json \ -d {prompt:请用一句话介绍自己,max_tokens:64}返回正常时这个老平台就算跑通了。这一步的意义在于建立可用基线后续所有优化都围绕这个基线做对比。多说一句--n-gpu-layers 99这种写法是故意把层数设满的GPU 显存放得下就全部丢给 GPUCPU 只做调度和采样避免权重在 CPU 和 GPU 之间反复搬运。3. 20 tok/s的真实含义从带宽测算到性能归因3.1 一次规范的测速流程20 tok/s这种数字脱离测法就没有意义。我自己用的测法很固定单并发、流式输出固定一个 600 字左右的输入 prompt让模型不间断生成 200 个 token统计从第一个 token 到最后一个 token 的平均间隔。输入处理的时间单独记录不计入 decode 速度。下面是我记录的一组典型数据使用 FP16 权重上下文长度 4096未做量化指标数值输入长度768 tokens首token延迟约0.8秒decode速度20.1 tok/s端到端生成200 token耗时约10.5秒显存占用约28.5GB你看生成 200 个 token 约 10.5 秒平均每秒输出 20 个左右。这个速度下人读起来有轻微的等字出现的感觉但完全跟得上阅读节奏用于内部工具是合格的。3.2 用显存带宽反推速度上限我特别喜欢用带宽公式来校验实测数据这能快速判断一个数字是正常还是异常。大模型 decode 时每一步都要把全部权重从显存搬运到 SM计算量本身往往不是瓶颈带宽才是。粗略公式是理论上限 ≈ 显存带宽 / 每token需要搬运的显存数据量这台 V100 的显存带宽约 900GB/s。FP16 模型加载进显存后权重和 KV cache 合计占 28.5GB 左右那么每生成一个 token权重相关搬运至少是 28.5GB 的量级。900 除以 28.5理论极限其实只有约 31 tok/s。我们实测 20说明已经跑到理论极限的 65% 左右余量不大了。为什么达不到 100%因为还有 kernel 启动开销、注意力计算、CPU 和 GPU 的数据交换、以及显存读写本身并非纯顺序。65% 的利用率放在老卡上已经是相当健康的水平。我把这段写出来是想告诉你一个容易被忽略的事实在这类显存带宽不高不低的卡上模型越小越容易跑得快参数越大越吃带宽。这也是为什么量化往往比换更快的卡更划算。3.3 decode与prefill为什么要分开看老机器上还有一个典型现象输入处理比 decode 慢一个数量级。因为输入处理是密集计算非常吃 GPU 的 FP16 算力而 V100 的 Tensor Core 性能在今天的标准下确实不够看了。输入 768 token 跑一次输入处理耗时 0.8 秒均摊到每个输入 token 约 1ms这个数字放在新一代显卡上可以被虐哭但在老平台上是正常的。实际操作中我会针对输入处理做两件事。第一把输入 prompt 压缩改写能用 300 字表达清楚就不要用 1000 字第二尽量复用缓存相同前缀对话不要重复处理。这两点对交互体感的影响有时比优化 decode 速度更明显。4. 老卡上的几个隐蔽坑编译兼容、线程干扰与显存溢出4.1 算力7.0的软件兼容边界V100 的算力是 7.0而当前主流推理引擎为了新卡的算子优化经常会逐步放弃对 7.0 的编译支持。我踩到的第一个坑就是用最新版本框架编 CUDA kernel 时编译阶段直接提示架构不支持。解决办法是锁定旧版本或加编译参数。旧版本虽然功能少一些但对 7.0 的支持完备稳定性更好。这提醒我们老设备上追新的风险很高版本选型的第一原则是兼容性性能优化要在兼容基础上再做。遇到报错时我建议先搜错误信息中的sm_70或compute capability而不是直接换框架版本。能兼容 7.0 的版本列表通常很明确选定一个稳定版本后把它作为这台服务器的固定依赖轻易不要动。4.2 双路CPU的物理距离与线程调度双路 Xeon 看起来有 56 个线程似乎很充裕但在跑推理时线程调度不当会导致性能波动。NUMA非一致性内存访问结构下GPU 插在 PCIe 的某颗 CPU 侧模型数据和请求线程如果跨 CPU 访问内存时延会升高生成速度会不稳。我最初直接把线程数设成 56结果反而比设成 28 更慢。原因是调度器把负载分散到两颗 CPU 上跨 die 访问内存和 PCIe 链路开销比多线程带来的并发收益更大。改成将推理进程和 GPU 绑定在同一颗 CPU 的 14 个物理核上之后速度反而稳定在 20 以上。如果你也遇到CPU 占用不高但速度上不去的情况先查一下进程落在哪颗 CPU 上再决定要不要加numactl --cpunodebind之类的绑定参数。这条经验在双路服务器上非常常见单路机器反而不会遇到。4.3 显存用量为什么比估算高一截很多教程都会告诉你模型多少B就占多少GB显存但实测总是偏高。这个现象在老卡上尤其明显。V100 32GB 跑 FP16 模型理论权重只有不到 20GB但加载后总量跑到了 28.5GB接近上限。原因有三层KV cache 是按最大上下文预留的CUDA context 和算子临时缓存会额外占用碎片化导致显存无法完全复用。解决思路不是算精确值而是留出 20% 冗余。如果显存不够但有第二块 V100还可以把模型切到多卡。多卡时用 NVLink 互联吞吐损失不大但如果中间隔了 PCIe 交换机速度会掉一截建议先看拓扑再决定。4.4 千万别忽略的OOM表现显存溢出在老卡上表现得特别隐蔽。有时候不是直接报Out of memory而是生成到一半速度骤降甚至卡住几秒后输出乱码。我排查过一次最后发现是显存刚好卡在临界点框架开始偷偷把部分层回退到 CPU 计算速度自然崩了。我的经验是显存占用超过总容量 90% 时就要当心。要么缩短上下文长度要么换量化权重要么降低并发数。非要卡着临界点跑等于埋了一颗定时炸弹。5. 把速度再往上顶从20到28的两次有效调整5.1 第一刀压缩权重并保住精度从 FP16 改成 4bit 量化后模型权重从 28.5GB 降到 8GB 以内显存带宽公式里的每token搬运量大幅下降理论上限直接翻倍。我用了基于校准集的 4bit 量化方式生成质量在摘要类任务上几乎没有损失。量化后的实测速度到了 27~28 tok/s接近 FP16 时的 1.4 倍。这也验证了我前面的判断瓶颈在权重搬运压低权重体积是最有效的加速手段。要注意的是量化格式对老卡很有讲究V100 没有现代卡上针对低精度计算专门强化的路径所以别盲目选最小的 bit 数4bit 是一个平衡点再低的版本在 V100 上反而不稳定。5.2 第二刀绑定CPU与GPU的协作位置量化带来提速后我又做了一次进程绑定调整配合量化版本最终稳定到 28。做法是把服务进程和整条数据通路都放在同一 NUMA 节点上并给 CPU 设置明确的线程数而不是让框架自动探测 56 个线程。实际启动脚本大概长这样numactl --cpunodebind0 --membind0 \ ./llama-server \ -m /models/qwen-flash-next-q4_k.gguf \ -t 14 \ --n-gpu-layers 99 \ -c 4096在双路机器上这个调整带来的提升通常在 5%~10%但更重要的是稳定性峰值抖动明显减少连续请求时速度不再忽高忽下。5.3 用于日常服务的最终启动参数最终我保留的是下面这套参数组合作为这台服务器的日常服务配置参数项设定值原因权重格式4bitQ4_K显存占用与质量平衡线程数14单颗物理核数量避免跨NUMAGPU层数99全部层进显存上下文长度4096够内部工具使用显存可控并行槽位2控制显存和CPU开销这套配置下稳定速度约 28 tok/s显存占用约 7.5GB剩余空间足够放两路并发请求。对一台 2016 年的服务器来说这个结果已经很能打了。提示如果你的应用是一次输入很长、生成很短的类型不要只看 decode 速度重点优化输入处理和缓存命中如果是你来我往的聊天型decode 速度的意义更大。5.4 顺带验证过的并发表现我还测了量化后多并发的情况。2 并发时单路速度大约降到 22 tok/s但总吞吐提升到 44 tok/s 左右显存仍然稳在 10GB 以内。这说明只要权重体积下来了老卡的并发能力也随之释放。如果几位同事同时用可以把并行槽位调到 3~4依然比单路 FP16 的整体体验好不少。6. 尾声老设备适合哪种角色折腾完这台老服务器我个人的体会是硬件迭代在 LLM 推理场景里没有想象中那么绝对瓶颈解析和工程适配往往比直接换卡更值钱。老Xeon 加 V100 这套组合最终可以稳定承担内部辅助工具、批量文本分析、隔离网络环境模型服务这类角色作为生产力工具完全合格。我最后再分享一个小技巧如果你的服务器上还有其他业务在跑就把推理服务放到一个独占的 NUMA 节点上并用环境变量限制 GPU 可见性避免别的进程把显存挤爆。实际做法是设置CUDA_VISIBLE_DEVICES只暴露目标卡再配合numactl固定内存节点。这种给模型留一条独立通道的思路比反复调参更能保证长期稳定。如果你手里也有一台吃灰的老服务器不妨找个适合部署的模型试一次也许结果会和预期完全不一样。
