后摩 LQ50-24GB 芯片实测参数与测试方法报告

一、环境与链路基线

1.1 参数清单

1.2 测试方法

PCIe 链路协商速率

lspci -nn | grep -iE 'houmo|process|accel'      # 定位设备 BDF,本机为 01:00.0
sudo lspci -vvv -s 01:00.0 | grep -iE 'LnkCap|LnkSta'

判据:LnkSta 的 Speed 与 Width 应等于 LnkCap。本机 LnkCap 与 LnkSta 均为 Speed 16GT/s、Width x4,判定链路未被降速。

设备信息(显存 / 核心 / 频率 / 电压 / 功耗 / 温度)

hm_smi -a                                        # 全量设备信息
hm_smi -f <字段名> -l <采样间隔秒>                # 按字段脚本化采样

hm_smi -a 返回字段包括:Cur_BandWidth、Cur_Ipu_Freq、Core_Num、Voltage、DDR_Memory_Total/Free、Temperature(DDR0/2/4/5、Core0/1)、Board_Power、DVFS_Mode。

CPU 频率策略锁定

sudo cpupower frequency-set -g performance
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort -u    # 校验应全为 performance

二、芯片算力

2.1 参数清单

算力上限的两层口径(重要):

• 理论峰值(标称):INT8 160 TOPS / bFP16 100 TFLOPS。 INT8 峰值建立在 2:4 结构化稀疏加速之上,仅理想稀疏负载可逼近。
• 实测可达上限(稠密):INT8 ≈ 95 TOPS / bFP16 ≈ 81 TFLOPS。 由后摩自带 computing_perf 在理想稠密矩阵乘微基准上测得,任何真实模型 ≤ 此值。
• 对稠密大模型(LLM/翻译/TTS,权重非稀疏),可用算力上限按 95 TOPS(INT8)估算最贴合实际,而非标称 160。
• bFP16 实测利用率 81%(无稀疏光环,贴近峰值),说明芯片原始计算引擎效率高;INT8 的 60% 差距即为稠密负载吃不到的稀疏加速部分。

注: 具体模型的「达到算力」是负载效率,低于上述可达上限。例:由 prefill 反推(达到算力 ≈ 2×参数量×prefill_tps),Qwen3-8B 长输入 prefill 约 35–38 TOPS(≈可达上限 95 的 39%),属正常的 transformer prefill 利用率(GPU 上同类负载通常 30–50%),不代表芯片上限。

2.2 测试方法

使用 SDK 自带工具 tools/computing_perf。该工具生成一个含 64 层卷积的 ONNX 模型,编译后在芯片上推理,以「计算量 × 样本数 ÷ 运行时间」计算实际算力。

source ~/houmo/hm_env.sh
cd tools/computing_perf
python3 computing_perf.py                        # bFP16
python3 computing_perf.py --compute-mode int8    # INT8

口径说明(依据工具源码 computing_perf.py):

• 工具内置标称峰值常量:bFP16 PEAK=100 TFLOPS,INT8 PEAK=160 TOPS。
• INT8 模式启用稀疏特征(enable_xh2_sparse_feature=True),即 160 TOPS 为稀疏峰值。
• 测试模型以 ncore=1 编译,运行时启动 4 个进程并发(PROCESS_NUM=4),报告值为多进程聚合吞吐。
• 工具 README 说明:实测算力低于理论峰值属正常现象。

三、芯片内存带宽

3.1 参数清单

3.2 测试方法

使用 SDK 自带工具 tools/bandwidth_perf,通过转置读 / 写微基准测量。

source ~/houmo/hm_env.sh
cd tools/bandwidth_perf
bash run.sh                                      # 依次执行读、写测试

口径说明:测试模型以单核(1core)编译,运行时启动 4 个进程并发,报告值为聚合带宽。单位为 GiB/s(二进制),换算为 GB/s(十进制)乘以 1.0737。

四、大语言模型推理性能

4.1 度量口径定义

统一测试开关:关闭 thinking、greedy 解码、固定输出长度(忽略 EOS)、每组 5 次循环并含预热(预热轮次不计入)。

4.2 参数清单(官方预编译 Qwen3-8B,W4 量化,batch=1)

缩放对照(示例编译 Qwen3-0.6B,W4A8,batch=1,输入 128 / 输出 256):

自行移植量化编译模型:Hunyuan-MT-7B(W4A8,batch=1,输入 128 / 输出 256,loop=5)

Hunyuan-MT-7B(腾讯混元翻译)后摩无官方预编译,由本方从零适配架构 + W4A8 量化 + 编译 .hmm,搬至 LQ50 实测。其芯片吞吐(23.7 tok/s)与同级 Qwen3-8B(W4,~22 tok/s)一致,表明移植正确、性能正常。注:此为速度指标;量化后翻译质量(BLEU/COMET vs FP16)尚未评测。

4.3 量化格式核验

官方预编译 Qwen3-8B 产物构成:prefill.hmm 4.3 GB、decode.hmm 103 MB、embedding 1.24 GB。prefill.hmm 体积约为 8B 参数 × 0.5 字节,对应 W4(4-bit)权重。示例编译 Qwen3-0.6B 产物量化标识为 w4a8h0_ssfp(权重 4-bit、激活 8-bit)。

4.4 测试方法

交互 / 单次推理(功能与口径验证): 使用示例目录 models/llm/qwen3/demo.py,内置性能统计输出 TTFT / TPOT / 各阶段耗时。

source ~/houmo/hm_env.sh
cd models/llm/qwen3
python3 demo.py --model_size 8b \
  --prefill_path <prefill.hmm> --decode_path <decode.hmm> \
  --embedding_path <embedding.pt> --tokenizer_dir qwen3-8b \
  --question "<测试问题>"

批量性能测试(固定输入 / 输出长度): 使用工具 tools/llm_perf(C++,需编译),支持固定输入/输出长度、循环次数、预热、设备与主机监控、结果导出。

# 编译(依赖 eigen3、yaml-cpp)
cd tools/llm_perf && bash build_linux.sh
# 运行
tools/bin/llm_perf --model_name <名称> \
  --prefill <prefill.hmm> --decode <decode.hmm> --embedding <embedding.bin> \
  --input 128,512,1024,2048 --output 256,256,256,256 \
  --loop 5 --batch 1 --interval 100 --dump_file <结果.yaml>

embedding 需由 tools/llm_perf/convert_embed.py 将 .pt 转为 .bin。结果 YAML 含各输入组的 TTFT、TPOT、decode/prefill 吞吐、KV cache 占用、显存、设备功耗/温度/频率、主机内存。

五、功耗与温度(按工况)

5.1 参数清单(Qwen3-8B W4)

5.2 测试方法

功耗、温度、频率由 tools/llm_perf 运行时通过 --interval <毫秒> 参数内置采样(调用设备遥测),随性能结果一并导出至结果 YAML 的 DeviceMonitor 字段。

独立采样亦可用:

hm_smi -f Board_Power Temperature Cur_Ipu_Freq -l 0.1     # 10 Hz 采样

说明:上述功耗为芯片遥测值,不含板级 VRM 损耗;整机功耗需另接墙插功率计测量,本次未测。

五·补 长时间稳定性(soak)

参数清单(Qwen3-8B W4,输入 128 / 输出 2048,连续 40 轮,约 62 分钟不间断)

测试方法

tools/bin/llm_perf --model_name qwen3_8b_w4_soak \
  --prefill hmm_8b/qwen3_prefill.hmm --decode hmm_8b/qwen3_decode.hmm \
  --embedding hmm_8b/hmquant/quant_embedding.bin \
  --input 128 --output 2048 --loop 40 --batch 1 --interval 500 --dump_file soak.yaml

逐轮时间戳记录于 perf_dumper.log,聚合功耗/温度/频率记录于 soak.yaml 的 DeviceMonitor 字段。判据:连续运行下 tok/s 波动、频率是否触发降频、显存与主机内存是否随时间增长。

六、多设备支持

SDK 推理接口(demo.py 及 llm_perf)的设备数参数支持取值 1 或 2,即支持单模型最多 2 卡部署。卡间并行方式(张量并行 / 流水线并行)及通信机制未在本次测试范围内确认。

七、语音识别模型(qwen3-asr)

7.1 参数清单(Qwen3-ASR-0.6B,输入 4.99 s 中文音频)

7.2 测试方法

官方预编译产物下载:

source ~/houmo/hm_env.sh
cd models/asr/qwen3-asr
python3 get_model.py --type hmm --model_size 0.6b --model_name qwen3_asr

下载得到 output/xh2/ 下 qwen3_asr_encode.hmm、qwen3_asr_prefill.hmm、qwen3_asr_decode.hmm 及处理器配置目录 Qwen3-ASR-0.6B。运行 demo(需 transformers、qwen_asr、librosa、torch 等运行期依赖;示例 requirements 中的 onnxsim 为编译期依赖,运行 demo 不需要):

python3 demo_asr.py --processor_dir Qwen3-ASR-0.6B --audio ../../../data/audio/4s.wav

RTF 定义:芯片处理耗时 ÷ 音频时长,小于 1 表示可实时。demo 内置性能统计输出各阶段耗时、Decode 吞吐、E2E 延迟与 RTF。音频加载(librosa)耗时为一次性主机开销,不计入 RTF。

八、语音合成模型(cosyvoice3)

8.1 参数清单(Fun-CosyVoice3-0.5B-2512)

补充实测(长文本):合成约 63.4 s 音频,墙钟总耗时 65.2 s,整体 RTF ≈ 1.03。经查,TTS 段耗时按文本分段计,每段约 12.8 s 且与该段音频长度基本无关(短段 5.68 s 音频 → RTF 2.25;长段 14.08 s 音频 → RTF 0.91)。故:

• cosyvoice3 在本平台整体合成速率约为实时(RTF≈1.0),长文本无明显摊薄至远低于 1;短句因每段固定耗时而 RTF 显著大于 1。
• 首包延迟实测:向 API 输入一段文本,第一个音频段返回耗时约 14–16 s。同一进程内连续合成 3 次,首包延迟分别为 14.35 / 13.96 / 13.96 s,排除首次 warmup 因素。
• 每段耗时与该段音频长度无关:合成 5–7 s 音频同样耗时约 14 s(RTF 2.1–3.0)。该固定耗时不随内容变化。
• demo 提供的接口按文本分段返回,单段须完整合成后方返回,未暴露子段流式输出。

补充分析(供后续验证,非结论):预编译产物命名为 cosyvoice3_0.5b_2512_256_2k,含 2k 上下文标识;每段固定约 14 s 的耗时与输入长度无关,指向"按固定 2k 上下文编译、短输入仍执行满长度计算"的可能。若成立,按更短上下文(如 256/512)重新编译或有望降低该固定耗时。此推断需在编译机上重编验证。

小结:cosyvoice3 当前预编译版首包延迟约 14 s、整体 RTF≈1,不适用于低延迟实时对话场景;可用于离线/非交互式合成。实时性改善路径(重编译短上下文、暴露流式)需在编译机验证。

8.2 测试方法

source ~/houmo/hm_env.sh
cd models/tts/cosyvoice3
python3 get_model.py --type hmm        # 下载预编译产物(单 zip,约 1.56 GB,含 10 段子模型)
python3 demo.py                        # 零样本 / 跨语种 / 指令三种模式,输出至 ./results

运行期依赖:transformers==4.57.3、torch==2.8.0、torchaudio、wetext、inflect、openai-whisper。tokenizer 目录 Fun-CosyVoice3-0.5B-2512、prompt 音频 zero_shot_prompt.wav 随下载提供。demo 内置性能报告输出 LLM 段 TTFT/速度、TTS 段耗时、RTF、E2E 延迟。RTF = TTS 段耗时 ÷ 生成音频时长。

八·补 自行量化编译与架构移植

对后摩无官方预编译产物的目标模型,本方在量化编译机(2× RTX 4090)上完成从原始权重到芯片 .hmm 的全流程。

8补.1 Hunyuan-MT-7B —— 架构移植(工具链无 recipe)

后摩工具链不含 hunyuan_v1_dense 架构定义。本方基于 qwen3 handler 移植:①在 llm_converter、quarot get_model_type、模型 handler 三处注册 HunYuanDenseV1ForCausalLM;②适配 qk-norm 命名(query_layernorm/key_layernorm)与 dynamic-NTK rope(alpha 已在 inv_freq)。

全流程:量化(quarot+gptq → W4A8) → 导出 hmonnx → tcim 编译(llm_opt=True,ncore=2,prefill fill-length=256/context-length=2048) → .hmm → 传 LQ50 → llm_perf 实测。

• 状态:已在 LQ50 芯片跑通,Decode 23.71 tok/s(见第四节)。
• 待办:量化后翻译质量评测(BLEU/COMET vs FP16)。

8补.2 VoxCPM —— 编译流程修复(工具链有 recipe 但含缺陷)

工具链含 voxcpm2 recipe,但其 LM 导出的 current_input_length 形状为 [1,1],而 tcim 的 kv_cache 算子仅接受 [1],导致芯片编译失败。本方定位并修复(voxcpm2_llm_model.py 与 sessions 中去除多余 .unsqueeze(0))。

• 状态:8/8 组件(base/residual LM × prefill/decode、LocDiT、LocEnc、AudioVAE 编码器/解码器)全部编成芯片 .hmm。 host 端已端到端验证产出正常语音。
• 待办:多组件芯片 runtime 编排(官方仅提供 host 版推理编排;上 LQ50 运行需将各 Session 的推理引擎从 host 模拟 runtime 改为 tcim_lite 芯片 runtime)。量化后音质评测。

8补.3 结论

后摩官方预编译覆盖 Qwen3 / qwen3-asr / cosyvoice3 等;对客户自带或非标模型,可经本方"量化 + 编译(必要时架构移植 / recipe 修复)"引入该芯片 —— Hunyuan-MT-7B(移植)与 VoxCPM(修复)均已完成芯片 .hmm 产出并(HY-mt)芯片实测,验证了该工程能力。

九、模型可行性结论(基于本次实测)

下表按实测证据陈述各模型/模型类别在 LQ50 上的可行性状态,不含推测性评价。

结论要点(客观陈述):

1. LLM 与 ASR 两类均有官方预编译产物且已实测跑通;ASR 实时性满足 RTF < 1。
2. TTS 类经 cosyvoice3 实测跑通,证明该工具链可编译并运行含 flow matching 与声码器的 TTS 流水线;但 cosyvoice3 整句 RTF 大于 1,实时性达标与否尚未确认。
3. Hunyuan-MT-7b:后摩无 recipe,经本方从零架构移植 + W4A8 量化 + 编译,已在芯片实测跑通(23.7 tok/s),与同级 Qwen3-8B 性能一致。量化后翻译质量尚未评测。
4. VoxCPM:后摩 recipe 的 LM 导出形状与 tcim 芯片编译器不兼容(current_input_length [1,1] vs 需 [1]),经本方修复后 8 个组件全部编成芯片 .hmm;host 端产出正常语音。上芯片运行尚需多组件 runtime 编排。
5. 就量化格式而言,本平台工具链所见路径为 INT 量化(W8A8 / W4A16),未见 FP8 支持;含 FP8 权重的模型需以 FP16/BF16 原始权重重新量化。
6. 综合:官方预编译覆盖 Qwen3/ASR/cosyvoice3;客户自带或非标模型可经本方"量化 + 编译(必要时架构移植 / recipe 修复)"引入该芯片,Hunyuan-MT(移植)、VoxCPM(修复)已验证此路径可行。

十、本次测试的边界与未覆盖项

附:所有原始结果文件(llm_perf 导出的 YAML、日志)保存在测试主机 ~/houmo/houmo-examples-xh2_v1.3.0/houmo-examples-xh2/models/llm/qwen3/ 目录下。