news 2026/3/28 22:51:32

多GPU和单GPU运行llama的时间差

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
多GPU和单GPU运行llama的时间差

在今天测试的时候,遇到了非常奇怪的问题。

之前的llama推理耗时40-50秒,而今晚的llama推理耗时580-590秒。

llama模型没变,adapter没变,代码没变,唯一的可能就是gpu。我只能怀疑是有什么进程在跑,和我抢占资源。

可是我不运行的时候,发现gpu几乎使用为0。也就说不太可能有其他人和我抢占资源。

我只能继续测试。

我开始运行llama。

实验室的server有4个24GB的gpu

nvidia-smi watch -n 1 nvidia-smi

情况大致如下:

可以看到显存的分布情况是四个GPU都有,并且都占很少的显存。

然后我们发送prompt给llama,此时算力出现变化。

可以看见,虽然分散了,但是llama还是只在其中一个上运行,其他全部都算力为0,而第一个gpu的算力是34%-45%之间跳动。

这个时候的生成耗时为580秒。非常离谱

llama推理时间很慢的情况,网上没找到解决方案(因为我都不知道这样的问题该怎么搜索,除了当事人谁™遇到过这种操蛋事情),大模型也是啥都不知道。

首先怀疑llama是不是跑到cpu运行了(虽然也不太可能,因为cpu90%多idle)。

def check_device(self): """检查模型实际运行在哪里""" import torch print("\n" + "="*60) print("🔍 设备检查") print("="*60) try: # 检查模型 model = self.chat_model.engine.model device = next(model.parameters()).device print(f"📍 模型在: {device}") if device.type == 'cpu': print("⚠️⚠️⚠️ 警告:模型在CPU上运行! ⚠️⚠️⚠️") else: print(f"✅ 模型在 GPU {device.index} 上") # 检查CUDA可用性 print(f"\n🎮 CUDA状态:") print(f" - CUDA可用: {torch.cuda.is_available()}") print(f" - CUDA版本: {torch.version.cuda}") print(f" - GPU数量: {torch.cuda.device_count()}") if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(f" - GPU {i}: {torch.cuda.get_device_name(i)}") print(f" 已用内存: {torch.cuda.memory_allocated(i)/1e9:.2f}GB") except Exception as e: print(f"❌ 检查失败: {e}") print("="*60 + "\n")

这个代码用来检测llama运行时的模型位置检测,并将这个测试代码的调用放在模型构建后。

self.chat_model = ChatModel(args) print("✅ 模型加载完成!\n") self.check_device() # 添加这行

结果如下。

- GPU 0: NVIDIA GeForce RTX 4090 已用内存: 3.27GB - GPU 1: NVIDIA GeForce RTX 4090 已用内存: 4.42GB - GPU 2: NVIDIA GeForce RTX 4090 已用内存: 4.42GB - GPU 3: NVIDIA GeForce RTX 4090 已用内存: 3.09GB

可以看到llama确实运行在gpu上,所以cpu猜想错误。

发给大模型,它认为可能是llama分散使用gpu导致运行效率低下。

于是想尝试之前学到的一个指令:

CUDA_VISIBLE_DEVICES

这个指令是能够直接屏蔽程序发现其他gpu,完全契合visble这个单词。

我输入指令

CUDA_VISIBLE_DEVICES=1 python /root/llama_fine/llama_server.py

当我使用了这个visible的时候,我发现cuda的时候情况变得很不一样。

部分cuda的分布直接快接近0了。

而当我发送prompt给llama时,算力的变化尤其大。

cuda 1的算力快被拉满了。 这是什么,这是希望啊卧槽。

因为算力才是影响快慢的关键,我直到现在也搞不清楚这太服务器的进程数量到底是如何影响算力的。明明cpu22核,为什么开16个进程的时候算力最高就30%的使用率了。这个90%多的算力使用率意味着——

同一个模型,同一个代码,同一个adapter,同一个prompt,运行时间天差地别。

比我之前40-50秒还快。

难道因为当时gpu都有人用,所以llama不得不集中在某几个cuda上,而现在没人和我抢,所以才快?

不理解。

这玩意也没有人开课,大模型也不懂,纯靠人工一个个试出来。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/3/27 0:18:42

AShareData:构建个人专属A股数据仓库的完整解决方案

在当今数据驱动的投资时代,拥有一个稳定可靠的本地A股数据仓库已成为量化投资者和研究人员的必备工具。AShareData项目通过自动化数据采集与智能管理机制,为金融数据分析提供了强有力的技术支撑。 【免费下载链接】AShareData 自动化Tushare数据获取和My…

作者头像 李华
网站建设 2026/3/27 16:01:28

手把手教你解决USB转串口控制器驱动问题

从“找不到驱动”到彻底掌控:深入理解USB转串口控制器的工程真相 你有没有过这样的经历? 手头一块开发板插上电脑,设备管理器里却只显示一个带黄色感叹号的“未知设备”。你反复拔插、换USB线、重启系统……结果还是一样—— usb-serial c…

作者头像 李华
网站建设 2026/3/26 22:22:00

开源电路板查看器OpenBoardView:突破性的.brd文件解析革命

开源电路板查看器OpenBoardView:突破性的.brd文件解析革命 【免费下载链接】OpenBoardView View .brd files 项目地址: https://gitcode.com/gh_mirrors/op/OpenBoardView 在电子设计领域,专业电路板查看软件往往价格昂贵且功能臃肿。OpenBoardVi…

作者头像 李华
网站建设 2026/3/28 22:50:11

Qwen3-VL滑雪姿态优化:空中动作稳定性评估

Qwen3-VL滑雪姿态优化:空中动作稳定性评估 在职业滑雪比赛中,一个微小的姿态偏差可能直接决定金牌归属。腾空瞬间的身体倾斜角度、四肢的协同程度、重心是否偏移——这些细节往往超出肉眼捕捉范围,传统依赖慢放回看和经验判断的方式已难以满足…

作者头像 李华
网站建设 2026/3/28 7:29:40

终极免费AI图像放大:Upscayl完整使用指南与色彩优化技巧

终极免费AI图像放大:Upscayl完整使用指南与色彩优化技巧 【免费下载链接】upscayl 🆙 Upscayl - Free and Open Source AI Image Upscaler for Linux, MacOS and Windows built with Linux-First philosophy. 项目地址: https://gitcode.com/GitHub_Tr…

作者头像 李华
网站建设 2026/3/22 3:30:22

Three.js与Qwen3-VL联动:根据自然语言指令生成3D场景代码

Three.js与Qwen3-VL联动:根据自然语言指令生成3D场景代码 在数字内容创作的边界不断被AI拓展的今天,一个引人深思的问题浮现出来:如果普通人不需要写一行代码,也能“说出”一个三维世界——那会怎样? 想象一下&#xf…

作者头像 李华