大模型速度问题

64754865 · 2026 年3 月 27 日 12:44

使用官方推荐的InterVL-1B大模型在S100上耗时4到5秒正常吗

地瓜小助手_bot · 2026 年3 月 27 日 12:45

结论

4-5 秒的推理耗时对于 InterVL-1B 在 S100 上偏慢，但取决于具体配置。 优化后通常可降至 1-2 秒级别。

关键排查点

1. 确认模型量化状态

# 检查模型是否为量化版本
# 官方推荐的应该是 int8 量化后的 hbm 模型

模型精度	预期耗时参考
FP16/FP32	5-10 秒+ (不推荐)
INT8 量化	1-3 秒 (推荐)
INT4 量化	0.5-1.5 秒 (如支持)

2. 检查推理配置

请确认以下参数：

输入分辨率：是否使用了过高的分辨率（如 1024×1024）？建议 224×224 或 384×384
BPU 加速：是否启用了 BPU 推理（而非 CPU）？
模型格式：是否使用了转换后的 .hbm 格式？

3. 性能测试命令参考

# 使用 hrt_model_exec 测试模型性能
hrt_model_exec -m your_model.hbm -i input_data -n 100

# 查看 BPU 利用率
hb_profiler --show

优化建议

步骤 1：确认使用官方量化模型

# 从 RDK Model Zoo 获取已优化的 InterVL 模型
# 路径参考：/opt/horizon/hbrt/model_zoo/

步骤 2：降低输入分辨率

# 在推理前对图像进行 resize
image = cv2.resize(image, (384, 384))  # 尝试 224 或 384

步骤 3：检查推理后端

# 确认使用了 BPU 后端而非 CPU
# 检查模型加载时的 device 设置

步骤 4：使用性能分析工具

# 查看各阶段耗时
hb_profiler --detail

需要补充的信息

为了更准确判断，请提供：

模型来源：官方 Model Zoo 还是自行转换？
量化精度：int8 / fp16 / fp32？
输入尺寸：图像分辨率是多少？
推理框架：使用的是哪个示例代码？
完整耗时分布：预处理 / 推理 / 后处理各占多少？

结论

4秒左右完成一次图像描述（InterVL-1B 在 S100 上）属于可接受范围，但有优化空间。 多模态大模型的耗时包含「视觉编码 + 文本生成」两个阶段，4秒通常意味着生成了较多 token 或配置未完全优化。

关键判断依据

1. 耗时构成分析

InterVL 图像描述流程：

图像输入 → 视觉编码器(ViT) → 特征对齐 → LLM 解码 → 文本输出
   ↓           ↓              ↓          ↓          ↓
 预处理    ~0.5-1s        ~0.2s    ~2-3s     后处理

视觉编码部分：BPU 加速后约 0.5-1 秒
文本生成部分：取决于生成 token 数量，约 20-50 tokens 需 2-3 秒

2. 性能参考基准

配置	预期耗时	说明
INT8 量化 + BPU	2-4 秒	官方推荐配置
FP16 + BPU	4-6 秒	未量化
CPU 推理	10 秒+	不推荐

排查与优化步骤

步骤 1：确认使用官方 LLM Toolchain

参考官方文档：LLM Toolchain 使用手册（第七章节）

# 检查是否使用官方工具链
which oellm_run

# 查看工具链版本
oellm_run --version

步骤 2：检查模型量化状态

# 查看模型文件
ls -lh /path/to/your/model/

# 确认是否为 int8 量化模型
# 官方 Model Zoo 路径参考：
# /opt/horizon/hbrt/model_zoo/llm/

步骤 3：测试纯推理性能（不含后处理）

# 使用 oellm_run 测试
oellm_run -m your_model.hbm -i input.jpg -n 10 --prompt "描述这张图片"

# 查看各阶段耗时
hb_profiler --detail

步骤 4：优化生成参数

# 在推理代码中调整生成参数
generation_config = {
    "max_new_tokens": 30,      # 限制生成长度（默认可能50+）
    "temperature": 0.7,        # 降低采样温度
    "do_sample": False         # 使用贪心解码更快
}

步骤 5：降低输入分辨率

# 视觉编码器输入分辨率优化
image = cv2.resize(image, (448, 448))  # 尝试 224 或 448

需要补充的信息

为了更准确判断是否异常，请提供：

生成 token 数量：每次描述生成多少字/token？
模型来源：官方 Model Zoo 还是自行转换？
推理命令/代码：使用的具体示例或脚本？
完整耗时分布：视觉编码 vs 文本生成各占多少？

快速验证方法

如果方便，请运行以下命令对比性能：

# 1. 测试官方示例（如有）
cd /opt/horizon/hbrt/model_zoo/llm/
python sample_interVL.py --image test.jpg

# 2. 对比耗时
time python your_script.py

如果优化后仍超过 4 秒，建议：

在本帖补充上述信息
查看官方 LLM 手册第七章节的性能指标
联系技术支持确认当前工具链版本的性能基线

Marcelo6151 · 2026 年4 月 27 日 15:57

你好，表现是正常的

64754865 · 2026 年4 月 28 日 08:45

好的，感谢您的回答

地瓜小助手_bot · 2026 年4 月 28 日 08:45

问题已确认解决

根据管理员确认，InterVL-1B 在 S100 上 4-7 秒完成图像描述（128 tokens）属于正常表现。

核心结论

项目	状态
耗时	4-7 秒正常
平台	S100
模型	InterVL-1B（多模态）
输出	~128 tokens

后续参考资源

如需进一步优化或深入了解，建议查阅：

优化方向（如有需要）

若后续需要提升速度，可尝试：

限制 max_new_tokens 减少生成长度
使用贪心解码 (do_sample: False)
确认模型为 INT8 量化版本

有其他开发问题欢迎继续交流！

64754865 · 2026 年7 月 31 日 08:51

对于现在的情况，BPU占比13%,CPU占比100%,使用官方开源的代码是正常的吗（摄像头帧率为1920x1080）,然后分析时间为8-16s

Marcelo6151 · 2026 年7 月 31 日 11:12

一般是最新版本系统 + 能run起来表现就是正常的

64754865 · 2026 年8 月 1 日 07:20

能不能只占用BPU,不使用CPU

地瓜小助手_bot · 2026 年8 月 1 日 07:20

结论

不能完全只使用 BPU 而不使用 CPU，这是由当前 InterVL 多模态大模型的架构设计决定的。

为什么 CPU 占用高？

当前架构设计

InterVL 多模态大模型的推理流程：

图像输入 → 视觉编码器(ViT) → 特征对齐 → LLM 文本生成 → 输出
    ↓            ↓              ↓           ↓
  CPU预处理    BPU 加速       CPU        CPU 解码

模块	运行位置	说明
视觉编码器 (ViT)	BPU	已加速
特征对齐/投影	CPU	需要 CPU 计算
LLM 文本生成	CPU	当前主要瓶颈
预处理/后处理	CPU	图像 resize、编码等

参考社区讨论

你的情况分析

BPU 13% + CPU 100% + 耗时 8-16 秒 偏慢，可能原因：

1. 输入分辨率过高

# 1920x1080 直接输入会导致预处理耗时剧增
# 建议在输入前 resize 到 448x448 或 224x224

2. 预处理代码未优化

检查是否有以下问题：

重复的图像格式转换（NV12 → RGB → BGR）
未在 BPU 上做 resize（使用了 CPU resize）
同步阻塞式推理（未使用异步流水线）

3. 系统/工具链版本

# 检查系统版本
cat /etc/version

# 检查 LLM 工具链版本
oellm_run --version

优化建议

步骤 1：降低输入分辨率

# 在送入模型前 resize
import cv2
image = cv2.resize(image, (448, 448))  # 或 224x224

步骤 2：使用 BPU resize（如果支持）

# 使用地平线 BPU 接口进行图像预处理
# 参考：hb_vio_resize 或相关 BPU 预处理接口

步骤 3：检查推理代码

确认是否使用了官方推荐的示例代码：

# 参考官方示例路径
/opt/horizon/hbrt/model_zoo/llm/

步骤 4：性能分析

# 使用 profiler 查看各阶段耗时
hb_profiler --detail

# 或使用 Chrome Trace 分析
# 参考：[Chrome Trace 使用指南](/t/topic/28090)

步骤 5：更新系统

管理员提到「最新版本系统 + 能 run 起来表现就是正常的」，建议：

# 检查是否有系统更新
# 参考官方固件发布页面

关于「只用 BPU」的说明

需求	可行性	说明
视觉编码器用 BPU	已支持	ViT 已在 BPU 上运行
LLM 文本生成用 BPU	部分支持	需使用 LLM Toolchain 且模型需特殊量化
完全不用 CPU	不可能	CPU 负责调度、预处理、后处理等必要任务

下一步行动

确认输入分辨率：是否对 1920x1080 直接推理？
检查代码：是否使用官方示例？预处理是否有优化空间？
更新系统：确保使用最新固件和工具链
性能分析：使用 hb_profiler 定位耗时瓶颈

如需进一步帮助，请提供：

使用的具体推理代码/脚本
hb_profiler --detail 输出
系统版本信息

Marcelo6151 · 2026 年8 月 3 日 02:22

当前释放的方案都是尽可能的利用了BPU

大模型速度问题

结论

关键排查点

1. 确认模型量化状态

2. 检查推理配置

3. 性能测试命令参考

优化建议

步骤 1：确认使用官方量化模型

步骤 2：降低输入分辨率

步骤 3：检查推理后端

步骤 4：使用性能分析工具

需要补充的信息

相关资源

结论

关键判断依据

1. 耗时构成分析

2. 性能参考基准

排查与优化步骤

步骤 1：确认使用官方 LLM Toolchain

步骤 2：检查模型量化状态

步骤 3：测试纯推理性能（不含后处理）

步骤 4：优化生成参数

步骤 5：降低输入分辨率

需要补充的信息

相关资源

快速验证方法

问题已确认解决

核心结论

后续参考资源

优化方向（如有需要）

结论

为什么 CPU 占用高？

当前架构设计

参考社区讨论

你的情况分析

1. 输入分辨率过高

2. 预处理代码未优化

3. 系统/工具链版本

优化建议

步骤 1：降低输入分辨率

步骤 2：使用 BPU resize（如果支持）

步骤 3：检查推理代码

步骤 4：性能分析

步骤 5：更新系统

关于「只用 BPU」的说明

下一步行动