2026/9/15 23:27:13
FEATURED · 精选文章 
先交代一下背景我们机房那台 4×V100(32G) 的老机器一直处于“算力过剩但谁都不敢动”的状态。最近团队想内部体验一下 Qwen3.8-Flash-Next正好看到 Ollama 仓库里有qwen3.8-flash-next:125b-a6b-q4_k_m这个标签就决定拿它练手。折腾了三天中间掉过驱动、加载过不完整的量化文件、还碰到多卡显存严重不均最后总算稳定跑起来了。这篇就是那份踩坑记录适合手头有 V100 或者其它老计算卡、想把新 MoE 模型本地跑起来的团队参考。1. 这套组合到底适不适合跑先算一笔显存账1.1 从模型标签看懂参数构成qwen3.8-flash-next:125b-a6b-q4_k_m这个标签拆开看就是三个信息总参数量 125B、激活参数量 6B、量化格式 Q4_K_M。很多朋友看到 125B 就直接摇头觉得 V100 肯定带不动但 MoE 架构最关键的地方在于“每次推理只激活一小部分参数”。也就是说虽然权重全部要驻留在显存里但单次前向计算的开销接近一个 7B 级别的 dense 模型而不是 125B 的 dense 模型。Flash-Next 这个后缀在社区的不同实现里含义不太一样我手上的这个量化包主要是在 attention 和后处理层做了优化减少 KV cache 的碎片浪费。不过这些优化不影响部署规划只影响实际推理时的显存水位和速度。1.2 4×V100(32G) 的显存与带宽账先算一道最基本的题Q4_K_M 量化下125B 参数大概占多少显存Q4_K_M 平均每个权重约 4.5 bit加上少量额外管理数据估算公式是125 × 10^9 × 4.5 / 8 ≈ 70.3 GB实际从 Ollama 拉下来的模型文件也差不多在 71~73 GB 之间。4 张 V100 32G 一共 128 GB减去权重后还剩 55 GB 左右给 KV cache、激活值和中间结果。单卡 32G 肯定装不下完整模型所以多卡并行不是“可选项”是“刚需”。V100 这块卡的显存带宽是 900GB/s 左右4 卡合计理论带宽 3.6TB/s但跨卡通信要经过 NVLink 或者 PCIe实际能跑到的带宽取决于服务器拓扑。如果是 SXM2 版本且开了 NVLinkP2P 表现会好不少如果是 PCIE 版跨卡通信就是明显瓶颈。所以部署之前先确认硬件形态别等到测试时才发现吞吐上不去。1.3 为什么第一反应是量化模型模型官方发布时一般会给 BF16 或者 FP16 权重125B 参数用 BF16 表示光权重就超过 250GB4 张 V100 的 128GB 显存根本装不下。更麻烦的是 V100 是 Volta 架构只支持 FP16 和 FP32对 BF16 的支持很弱硬跑还会遇到精度和性能问题。所以在这个场景下社区量化好的 Q4_K_M 文件反而是最务实的路径体积小llama.cpp 生态直接认效果损失也在可接受范围。注意Q4_K_M 是效果与效率的折中不是无损。如果你做的是法律、医疗等对输出精确度要求极高的场景至少要先做一轮任务集评测再决定要不要上。2. 环境准备让四张老卡稳定工作2.1 驱动与内核版本锁定V100 这几年最容易翻车的不是模型而是驱动。我们最开始开机一切正常重启一次之后nvidia-smi直接报 “No devices were found”当时还以为是哪张卡烧了。后来查dmesg看到NVRM: failed to initialize the NVIDIA kernel module才确认是内核自动升级把驱动搞挂了。解决方案分两步。第一步切回旧内核重启确认四卡恢复第二步锁定内核版本防止再被自动更新。sudo apt-mark hold linux-image-generic linux-headers-generic驱动版本建议选 NVIDIA 535 或 550 这类已经迭代很久的稳定分支不要随手装最新版。V100 在新驱动上表现不差但新驱动偶尔会对老架构的初始化流程做调整容易引入一些莫名其妙的问题。2.2 软件栈版本搭配我在 Ubuntu 22.04 上的最终版本组合是NVIDIA 驱动535.xCUDA12.2驱动自带不单独装Ollama最新稳定版Python3.10辅助工具nvidia-smi、dmesg、htopOllama 安装很简单curl -fsSL https://ollama.com/install.sh | sh systemctl status ollama这里有一个容易忽略的点Ollama 自己会带推理后端不需要手动装 CUDA toolkit但系统里要确保有常用的 GPU 内核模块和 NCCL 库。如果之前装过别的深度学习框架建议先做一次清理避免 PyTorch 自带 CUDA runtime 和系统 CUDA 版本冲突。2.3 硬件拓扑确认多卡部署前一定要先看拓扑nvidia-smi topo -m输出里重点看 GPU 之间的互连方式。如果是NV#或者NVSW说明有 NVLink如果是PIX或者PHB说明走 PCIe 交换机跨卡传输会慢很多。我们这台机器是 4×V100 SXM2NVLink 全互联理论上跨卡通信不是最短板。同时用nvidia-smi确认四张卡都识别正常nvidia-smi --query-gpuindex,name,memory.total,power.draw,temperature.gpu --formatcsv四张卡型号、显存、温度都正常后再进入部署环节。不要跳过这步后面模型加载失败时排查成本会高很多。3. 基于 Ollama 的多卡部署实操3.1 拉取模型并验证文件完整性模型拉取没什么特殊的ollama pull qwen3.8-flash-next:125b-a6b-q4_k_m这个包不小接近 72GB走公网下载要耐心。如果中途断了Ollama 支持断点续传直接重新执行同一命令就行。拉取完成后用ollama show看模型信息ollama show qwen3.8-flash-next:125b-a6b-q4_k_m确认架构、参数量、量化方式、context length 都符合预期。这里有个经验不要只看命令成功就开跑最好检查一下 Ollama 的 manifest 和 blob 文件大小。模型文件不完整时ollama run可能不会立刻报错而是等到真正推理时才崩排查成本很高。3.2 启动参数并发数、上下文长度、显卡分配Ollama 默认安装后会创建 systemd 服务我把它改成了更适合内部服务的配置sudo systemctl edit ollama写入[Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m这几个参数的作用分别是OLLAMA_HOST0.0.0.0允许局域网内其它机器访问 API方便前端或脚本连过来。OLLAMA_NUM_PARALLEL4同一个模型最多同时处理 4 个请求。MoE 模型激活参数量小适合用并发把四张卡的算力“喂饱”。OLLAMA_MAX_LOADED_MODELS1只保留一个常驻模型避免多模型切换导致显存爆炸。OLLAMA_KEEP_ALIVE5m模型空闲 5 分钟后才卸载避免频繁冷加载。然后重启服务sudo systemctl daemon-reload sudo systemctl restart ollama第一次加载模型可以这样验证ollama run qwen3.8-flash-next:125b-a6b-q4_k_m输入一个简单的测试问题同时另开终端观察四卡显存watch -n 1 nvidia-smi正常情况下四张卡都会被占用但显存分配不一定均匀这个后面会专门说。3.3 首测性能基线我记录了一组比较有代表性的数据条件为四卡 V100 SXM2 32GNVLink 全互联模型 Q4_K_M上下文长度设置为 16384单请求无并发。项目实测值模型加载时间约 2 分 10 秒首 token 延迟约 1.8 秒稳定生成速度约 32 token/s四卡总显存占用约 104 GB首 token 延迟高主要是因为模型太大加载后需要做一次完整的 KV cache 初始化。KEEP_ALIVE设置长一点后后续请求首 token 延迟能降到 0.6 秒左右。生成速度接近 30 token/s对内部工具来说已经够用。4. 把 Ollama 包装成内部可用的 API 服务4.1 先理解 Ollama 的 API 形态Ollama 自带 HTTP API并且提供了 OpenAI 兼容端点。也就是说Dify、ComfyUI、FastGPT 这类前端工具不需要写私有协议直接把 Base URL 填成http://服务器IP:11434/v1模型名填qwen3.8-flash-next:125b-a6b-q4_k_m就能对接。用 curl 可以直接测试curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.8-flash-next:125b-a6b-q4_k_m, messages: [{role: user, content: 用一句话解释什么是张量并行}], stream: false }返回结果里会带usage字段包含 prompt_tokens 和 completion_tokens可以用于统计和计费。4.2 并发请求下的显存与延迟变化把OLLAMA_NUM_PARALLEL调到 4 后我又测了一轮并发数总吞吐量单请求平均生成速度总显存占用132 token/s32 token/s104 GB248 token/s24 token/s109 GB461 token/s15 token/s116 GB从这个结果看并发确实能把四张卡的有效吞吐拉起来但单请求的响应速度会下降。如果内部用户大多是“问一句等几秒”的交互式场景并发 2 到 3 比较舒服如果要跑批量任务并发 4 更划算。4.3 监控与告警别让温度成为下一个事故V100 SXM2 通常是被动机箱散热满载后温度上升很快。我们在测试中看到 4 卡满载 10 分钟后温度稳定在 78~82 摄氏度还在安全范围内但机房空调稍微差点就会飙到 90 度以上。建议至少做两层监控nvidia-smi --query-gpuindex,temperature.gpu,utilization.gpu,memory.used,power.draw --formatcsv -l 5第一层是人工巡检第二层是脚本告警。温度超过 85 度就发告警超过 90 度直接停掉推理任务。V100 虽然耐操但长期高温会加速风扇和供电模块老化。5. 踩坑记录掉驱动、量化文件加载失败、负载不均5.1 掉驱动不是硬件挂了而是驱动和系统更新打架前面提到重启后nvidia-smi找不到设备这里把完整排查链路写一下。现象出现后我的排查顺序是nvidia-smi dmesg | grep -i nvidia | tail -50dmesg里如果出现NVRM: failed to initialize the NVIDIA kernel module基本可以确定是内核模块加载失败。接着看当前内核和已安装驱动匹配情况uname -r dpkg -l | grep nvidia-driver我们当时的驱动是 535但系统内核从 5.15 自动升级到了 5.19新内核没有对应 DKMS 模块所以驱动起不来。解决办法是重启时在 GRUB 里选旧内核然后锁定内核版本。之后重新生成一次模块sudo apt --reinstall install nvidia-driver-535 sudo update-initramfs -u别一上来就重装驱动。先查 dmesg80% 的“掉驱动”都是内核升级引起的。5.2 量化文件加载失败检查 manifest 与 blob 大小第二次糟心事是ollama run执行到一半直接报model not found但ollama list里又能看到模型。这个很迷惑后来发现是下载中断后manifest 里记录了模型但实际 blob 文件缺失或不完整。检查方式ls -lh ~/.ollama/models/blobs/如果模型文件只有 50GB 左右明显不对正常应该在 70GB 以上。处理方式也简单删掉重拉ollama rm qwen3.8-flash-next:125b-a6b-q4_k_m ollama pull qwen3.8-flash-next:125b-a6b-q4_k_mOllama 的断点续传不总是可靠遇到这种“列表里有但跑不了”的情况别心疼重新拉一次最省事。5.3 多卡负载不均核心在并发和上下文长度第一次跑通后我发现 GPU0 显存占了 30GB其它三张卡只有 22~24GB。这个现象在 MoE 模型里很常见因为 Ollama/llama.cpp 做多卡推理时默认是按照层或者专家来切分某些层或专家组恰好集中在前几张卡上。解决方式不是手动指定卡而是增加并发和 batch size。当OLLAMA_NUM_PARALLEL设为 4并且连续向 API 发送多个请求后四张卡的显存逐渐趋于接近分别稳定在 27~30GB。原因是多个请求同时推理时后端会重新平衡 tensor 分发。另一个影响因素是上下文长度。num_ctx调得越大KV cache 占用越多分布不均的现象越明显。所以在不必要的情况下不要盲目把上下文调到 32K 或更大16K 对大多数内部任务已经足够。6. 如果重来一次我会怎么选型和调优6.1 Ollama 还是 vLLM我在这个项目里也试过 vLLM但最终放弃主要原因是 V100 对很多新特性的支持不完整尤其是我手上的 Q4_K_M 量化文件通过 vLLM 加载的社区支持还不够稳定。而 Ollama 底层用的 llama.cpp本身就是从 GGUF 生态长出来的对量化文件的支持最自然。如果模型提供的是 FP16/AWQ 等标准格式且机器是 Ampere 以上的卡那 vLLM 的高吞吐优势会非常明显。但在 V100 上与其花时间调 vLLM 的兼容性问题不如老老实实用 Ollama。老卡有老卡的活法不要为了追求“更专业”的工具而忽略硬件本身的局限性。6.2 值得调的三个参数参数推荐值理由num_ctx16384显存和长文本能力之间的平衡点32K 会明显挤压并发空间OLLAMA_NUM_PARALLEL3~4让四卡算力尽量吃满内部 API 延迟依然可以接受OLLAMA_KEEP_ALIVE5m 以上避免频繁模型卸载带来的 2 分钟冷启动如果你需要在低延迟场景下使用建议把OLLAMA_NUM_PARALLEL降到 1 或 2并设置更长的KEEP_ALIVE。这个组合更偏向“稳定输出”而不是“最大化吞吐”。6.3 最后一点个人体会老卡不是不能用但一定要认清定位。4×V100(32G) 跑 Qwen3.8-Flash-Next 的 Q4_K_M 量化版很适合做内部知识库问答、代码辅助、文本处理这类对响应时间不太苛刻的场景。它可以稳定提供 30~60 token/s 的总吞吐这已经能支撑一个小团队日常使用了。但如果你想做高并发在线服务或者需要单请求极低延迟还是老老实实换新卡。V100 不是不行只是它的年代决定了它更适合当“原型验证机”而不是“生产主力机”。我踩完这些坑之后的体会是部署老模型有老模型的坑部署新模型到老卡上更是处处配合问题但只要把显存账算清楚、把驱动锁稳定、把量化格式用好这套组合还是能给你惊喜的。
V100老卡跑通MoE大模型：基于Ollama的Qwen3.8多卡部署踩坑指南
先交代一下背景我们机房那台 4×V100(32G) 的老机器一直处于“算力过剩但谁都不敢动”的状态。最近团队想内部体验一下 Qwen3.8-Flash-Next正好看到 Ollama 仓库里有qwen3.8-flash-next:125b-a6b-q4_k_m这个标签就决定拿它练手。折腾了三天中间掉过驱动、加载过不完整的量化文件、还碰到多卡显存严重不均最后总算稳定跑起来了。这篇就是那份踩坑记录适合手头有 V100 或者其它老计算卡、想把新 MoE 模型本地跑起来的团队参考。1. 这套组合到底适不适合跑先算一笔显存账1.1 从模型标签看懂参数构成qwen3.8-flash-next:125b-a6b-q4_k_m这个标签拆开看就是三个信息总参数量 125B、激活参数量 6B、量化格式 Q4_K_M。很多朋友看到 125B 就直接摇头觉得 V100 肯定带不动但 MoE 架构最关键的地方在于“每次推理只激活一小部分参数”。也就是说虽然权重全部要驻留在显存里但单次前向计算的开销接近一个 7B 级别的 dense 模型而不是 125B 的 dense 模型。Flash-Next 这个后缀在社区的不同实现里含义不太一样我手上的这个量化包主要是在 attention 和后处理层做了优化减少 KV cache 的碎片浪费。不过这些优化不影响部署规划只影响实际推理时的显存水位和速度。1.2 4×V100(32G) 的显存与带宽账先算一道最基本的题Q4_K_M 量化下125B 参数大概占多少显存Q4_K_M 平均每个权重约 4.5 bit加上少量额外管理数据估算公式是125 × 10^9 × 4.5 / 8 ≈ 70.3 GB实际从 Ollama 拉下来的模型文件也差不多在 71~73 GB 之间。4 张 V100 32G 一共 128 GB减去权重后还剩 55 GB 左右给 KV cache、激活值和中间结果。单卡 32G 肯定装不下完整模型所以多卡并行不是“可选项”是“刚需”。V100 这块卡的显存带宽是 900GB/s 左右4 卡合计理论带宽 3.6TB/s但跨卡通信要经过 NVLink 或者 PCIe实际能跑到的带宽取决于服务器拓扑。如果是 SXM2 版本且开了 NVLinkP2P 表现会好不少如果是 PCIE 版跨卡通信就是明显瓶颈。所以部署之前先确认硬件形态别等到测试时才发现吞吐上不去。1.3 为什么第一反应是量化模型模型官方发布时一般会给 BF16 或者 FP16 权重125B 参数用 BF16 表示光权重就超过 250GB4 张 V100 的 128GB 显存根本装不下。更麻烦的是 V100 是 Volta 架构只支持 FP16 和 FP32对 BF16 的支持很弱硬跑还会遇到精度和性能问题。所以在这个场景下社区量化好的 Q4_K_M 文件反而是最务实的路径体积小llama.cpp 生态直接认效果损失也在可接受范围。注意Q4_K_M 是效果与效率的折中不是无损。如果你做的是法律、医疗等对输出精确度要求极高的场景至少要先做一轮任务集评测再决定要不要上。2. 环境准备让四张老卡稳定工作2.1 驱动与内核版本锁定V100 这几年最容易翻车的不是模型而是驱动。我们最开始开机一切正常重启一次之后nvidia-smi直接报 “No devices were found”当时还以为是哪张卡烧了。后来查dmesg看到NVRM: failed to initialize the NVIDIA kernel module才确认是内核自动升级把驱动搞挂了。解决方案分两步。第一步切回旧内核重启确认四卡恢复第二步锁定内核版本防止再被自动更新。sudo apt-mark hold linux-image-generic linux-headers-generic驱动版本建议选 NVIDIA 535 或 550 这类已经迭代很久的稳定分支不要随手装最新版。V100 在新驱动上表现不差但新驱动偶尔会对老架构的初始化流程做调整容易引入一些莫名其妙的问题。2.2 软件栈版本搭配我在 Ubuntu 22.04 上的最终版本组合是NVIDIA 驱动535.xCUDA12.2驱动自带不单独装Ollama最新稳定版Python3.10辅助工具nvidia-smi、dmesg、htopOllama 安装很简单curl -fsSL https://ollama.com/install.sh | sh systemctl status ollama这里有一个容易忽略的点Ollama 自己会带推理后端不需要手动装 CUDA toolkit但系统里要确保有常用的 GPU 内核模块和 NCCL 库。如果之前装过别的深度学习框架建议先做一次清理避免 PyTorch 自带 CUDA runtime 和系统 CUDA 版本冲突。2.3 硬件拓扑确认多卡部署前一定要先看拓扑nvidia-smi topo -m输出里重点看 GPU 之间的互连方式。如果是NV#或者NVSW说明有 NVLink如果是PIX或者PHB说明走 PCIe 交换机跨卡传输会慢很多。我们这台机器是 4×V100 SXM2NVLink 全互联理论上跨卡通信不是最短板。同时用nvidia-smi确认四张卡都识别正常nvidia-smi --query-gpuindex,name,memory.total,power.draw,temperature.gpu --formatcsv四张卡型号、显存、温度都正常后再进入部署环节。不要跳过这步后面模型加载失败时排查成本会高很多。3. 基于 Ollama 的多卡部署实操3.1 拉取模型并验证文件完整性模型拉取没什么特殊的ollama pull qwen3.8-flash-next:125b-a6b-q4_k_m这个包不小接近 72GB走公网下载要耐心。如果中途断了Ollama 支持断点续传直接重新执行同一命令就行。拉取完成后用ollama show看模型信息ollama show qwen3.8-flash-next:125b-a6b-q4_k_m确认架构、参数量、量化方式、context length 都符合预期。这里有个经验不要只看命令成功就开跑最好检查一下 Ollama 的 manifest 和 blob 文件大小。模型文件不完整时ollama run可能不会立刻报错而是等到真正推理时才崩排查成本很高。3.2 启动参数并发数、上下文长度、显卡分配Ollama 默认安装后会创建 systemd 服务我把它改成了更适合内部服务的配置sudo systemctl edit ollama写入[Service] EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m这几个参数的作用分别是OLLAMA_HOST0.0.0.0允许局域网内其它机器访问 API方便前端或脚本连过来。OLLAMA_NUM_PARALLEL4同一个模型最多同时处理 4 个请求。MoE 模型激活参数量小适合用并发把四张卡的算力“喂饱”。OLLAMA_MAX_LOADED_MODELS1只保留一个常驻模型避免多模型切换导致显存爆炸。OLLAMA_KEEP_ALIVE5m模型空闲 5 分钟后才卸载避免频繁冷加载。然后重启服务sudo systemctl daemon-reload sudo systemctl restart ollama第一次加载模型可以这样验证ollama run qwen3.8-flash-next:125b-a6b-q4_k_m输入一个简单的测试问题同时另开终端观察四卡显存watch -n 1 nvidia-smi正常情况下四张卡都会被占用但显存分配不一定均匀这个后面会专门说。3.3 首测性能基线我记录了一组比较有代表性的数据条件为四卡 V100 SXM2 32GNVLink 全互联模型 Q4_K_M上下文长度设置为 16384单请求无并发。项目实测值模型加载时间约 2 分 10 秒首 token 延迟约 1.8 秒稳定生成速度约 32 token/s四卡总显存占用约 104 GB首 token 延迟高主要是因为模型太大加载后需要做一次完整的 KV cache 初始化。KEEP_ALIVE设置长一点后后续请求首 token 延迟能降到 0.6 秒左右。生成速度接近 30 token/s对内部工具来说已经够用。4. 把 Ollama 包装成内部可用的 API 服务4.1 先理解 Ollama 的 API 形态Ollama 自带 HTTP API并且提供了 OpenAI 兼容端点。也就是说Dify、ComfyUI、FastGPT 这类前端工具不需要写私有协议直接把 Base URL 填成http://服务器IP:11434/v1模型名填qwen3.8-flash-next:125b-a6b-q4_k_m就能对接。用 curl 可以直接测试curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.8-flash-next:125b-a6b-q4_k_m, messages: [{role: user, content: 用一句话解释什么是张量并行}], stream: false }返回结果里会带usage字段包含 prompt_tokens 和 completion_tokens可以用于统计和计费。4.2 并发请求下的显存与延迟变化把OLLAMA_NUM_PARALLEL调到 4 后我又测了一轮并发数总吞吐量单请求平均生成速度总显存占用132 token/s32 token/s104 GB248 token/s24 token/s109 GB461 token/s15 token/s116 GB从这个结果看并发确实能把四张卡的有效吞吐拉起来但单请求的响应速度会下降。如果内部用户大多是“问一句等几秒”的交互式场景并发 2 到 3 比较舒服如果要跑批量任务并发 4 更划算。4.3 监控与告警别让温度成为下一个事故V100 SXM2 通常是被动机箱散热满载后温度上升很快。我们在测试中看到 4 卡满载 10 分钟后温度稳定在 78~82 摄氏度还在安全范围内但机房空调稍微差点就会飙到 90 度以上。建议至少做两层监控nvidia-smi --query-gpuindex,temperature.gpu,utilization.gpu,memory.used,power.draw --formatcsv -l 5第一层是人工巡检第二层是脚本告警。温度超过 85 度就发告警超过 90 度直接停掉推理任务。V100 虽然耐操但长期高温会加速风扇和供电模块老化。5. 踩坑记录掉驱动、量化文件加载失败、负载不均5.1 掉驱动不是硬件挂了而是驱动和系统更新打架前面提到重启后nvidia-smi找不到设备这里把完整排查链路写一下。现象出现后我的排查顺序是nvidia-smi dmesg | grep -i nvidia | tail -50dmesg里如果出现NVRM: failed to initialize the NVIDIA kernel module基本可以确定是内核模块加载失败。接着看当前内核和已安装驱动匹配情况uname -r dpkg -l | grep nvidia-driver我们当时的驱动是 535但系统内核从 5.15 自动升级到了 5.19新内核没有对应 DKMS 模块所以驱动起不来。解决办法是重启时在 GRUB 里选旧内核然后锁定内核版本。之后重新生成一次模块sudo apt --reinstall install nvidia-driver-535 sudo update-initramfs -u别一上来就重装驱动。先查 dmesg80% 的“掉驱动”都是内核升级引起的。5.2 量化文件加载失败检查 manifest 与 blob 大小第二次糟心事是ollama run执行到一半直接报model not found但ollama list里又能看到模型。这个很迷惑后来发现是下载中断后manifest 里记录了模型但实际 blob 文件缺失或不完整。检查方式ls -lh ~/.ollama/models/blobs/如果模型文件只有 50GB 左右明显不对正常应该在 70GB 以上。处理方式也简单删掉重拉ollama rm qwen3.8-flash-next:125b-a6b-q4_k_m ollama pull qwen3.8-flash-next:125b-a6b-q4_k_mOllama 的断点续传不总是可靠遇到这种“列表里有但跑不了”的情况别心疼重新拉一次最省事。5.3 多卡负载不均核心在并发和上下文长度第一次跑通后我发现 GPU0 显存占了 30GB其它三张卡只有 22~24GB。这个现象在 MoE 模型里很常见因为 Ollama/llama.cpp 做多卡推理时默认是按照层或者专家来切分某些层或专家组恰好集中在前几张卡上。解决方式不是手动指定卡而是增加并发和 batch size。当OLLAMA_NUM_PARALLEL设为 4并且连续向 API 发送多个请求后四张卡的显存逐渐趋于接近分别稳定在 27~30GB。原因是多个请求同时推理时后端会重新平衡 tensor 分发。另一个影响因素是上下文长度。num_ctx调得越大KV cache 占用越多分布不均的现象越明显。所以在不必要的情况下不要盲目把上下文调到 32K 或更大16K 对大多数内部任务已经足够。6. 如果重来一次我会怎么选型和调优6.1 Ollama 还是 vLLM我在这个项目里也试过 vLLM但最终放弃主要原因是 V100 对很多新特性的支持不完整尤其是我手上的 Q4_K_M 量化文件通过 vLLM 加载的社区支持还不够稳定。而 Ollama 底层用的 llama.cpp本身就是从 GGUF 生态长出来的对量化文件的支持最自然。如果模型提供的是 FP16/AWQ 等标准格式且机器是 Ampere 以上的卡那 vLLM 的高吞吐优势会非常明显。但在 V100 上与其花时间调 vLLM 的兼容性问题不如老老实实用 Ollama。老卡有老卡的活法不要为了追求“更专业”的工具而忽略硬件本身的局限性。6.2 值得调的三个参数参数推荐值理由num_ctx16384显存和长文本能力之间的平衡点32K 会明显挤压并发空间OLLAMA_NUM_PARALLEL3~4让四卡算力尽量吃满内部 API 延迟依然可以接受OLLAMA_KEEP_ALIVE5m 以上避免频繁模型卸载带来的 2 分钟冷启动如果你需要在低延迟场景下使用建议把OLLAMA_NUM_PARALLEL降到 1 或 2并设置更长的KEEP_ALIVE。这个组合更偏向“稳定输出”而不是“最大化吞吐”。6.3 最后一点个人体会老卡不是不能用但一定要认清定位。4×V100(32G) 跑 Qwen3.8-Flash-Next 的 Q4_K_M 量化版很适合做内部知识库问答、代码辅助、文本处理这类对响应时间不太苛刻的场景。它可以稳定提供 30~60 token/s 的总吞吐这已经能支撑一个小团队日常使用了。但如果你想做高并发在线服务或者需要单请求极低延迟还是老老实实换新卡。V100 不是不行只是它的年代决定了它更适合当“原型验证机”而不是“生产主力机”。我踩完这些坑之后的体会是部署老模型有老模型的坑部署新模型到老卡上更是处处配合问题但只要把显存账算清楚、把驱动锁稳定、把量化格式用好这套组合还是能给你惊喜的。 
