Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[J]. Advances in neural information processing systems, 2017, 30.
Han K, Xiao A, Wu E, et al. Transformer in transformer[J]. Advances in neural information processing systems, 2021, 34: 15908-15919.
Silva L, Barbosa L. Improving dense retrieval models with LLM augmented data for dataset search[J]. Knowledge-based systems, 2024, 294: 111740.
Wang S, Chen Z, Li B, et al. Scaling laws across model architectures: A comparative analysis of dense and MoE models in large language models[J]. arXiv preprint arXiv:2410.05661, 2024.
Du X, Gunter T, Kong X, et al. Revisiting moe and dense speed-accuracy comparisons for llm training[J]. arXiv preprint arXiv:2405.15052, 2024.
Shen L, Chen G, Shao R, et al. Mome: Mixture of multimodal experts for generalist multimodal large language models[J]. Advances in neural information processing systems, 2024, 37: 42048-42070.
Liang W, Yu L, Luo L, et al. Mixture-of-transformers: A sparse and scalable architecture for multi-modal foundation models[J]. arXiv preprint arXiv:2411.04996, 2024.
Li Y, Jiang S, Hu B, et al. Uni-moe: Scaling unified multimodal llms with mixture of experts[J]. IEEE Transactions on Pattern Analysis and Machine Intelligence, 2025.
Zacarias F V, Palli K, Vazhkudai S, et al. Analyzing LLM performance: The impact of high-bandwidth memory on model inference[J].
Na S, Jeong G, Ahn B H, et al. Understanding performance implications of llm inference on cpus[C]//2024 IEEE International Symposium on Workload Characterization (IISWC). IEEE, 2024: 169-180.
Hasan S, Basak S. Open-source AI-powered optimization in scalene: Advancing python performance profiling with DeepSeek-R1 and LLaMA 3.2[J]. arXiv preprint arXiv:2502.10299, 2025.
Gao T, Jin J, Ke Z T, et al. A comparison of deepseek and other LLMs[J]. arXiv preprint arXiv:2502.03688, 2025.
Zhao K, Liu Z, Lei X, et al. Quantifying the Capability Boundary of DeepSeek Models: An Application-Driven Performance Analysis[J]. arXiv preprint arXiv:2502.11164, 2025.
一、项目简介
🚀AICompass 是一套面向异构算力场景的智能评估工具,能够在可视化界面根据各类大模型参数及结构,计算其显存及算力需求,智能推荐满足服务指标要求的异构硬件所需配置方案。
📊同时提供算力及互联带宽测试工具,从大模型推理部署需求出发,搭建跨架构统一表征框架,精准测量异构加速卡性能。
🔍通过大量的测试实验,修正计算公式,显存占用预测误差控制在**5%**以内,推荐的硬件配置能够满足吞吐量指标要求,助力智算中心实现从“盲目建设”到“按需供给”的转型。
🔗体验链接:http://siborn.top
👨💻团队成员:季玮晔、许博文
🎓指导老师:杨鹏飞
1.1 赛题完成情况
1.2 核心工作
(1)可视化平台 🖼️:通过网页部署形式展示评估工具,用户可以通过桌面端或移动端浏览器访问,方便直观。网页支持主流或自定义大模型,支持稠密、稀疏、多模态大模型,以可视化方式展示各部分显存占用情况。选定部署指标及服务指标要求,页面能够给出异构硬件最小部署需求。另外提供推理速度模拟,供服务指标修改参考。
(2)算力测试工具🔬:提供一套针对异构硬件的算力及互联带宽测试工具,通过实验分析,确定大模型推理部署算子及其尺寸,构建统一的算力及互联带宽等效建模能力,解决理论值难以精确预测硬件需求的问题,从而提供准确的硬件方案建议,测试工具代码已开源。
(3)充分实测验证💻:本项目选取受广泛认可的经典模型,如 llama\mixtral\llava 等,对不同的输入负载,测试不同并发量下的模型各部分显存占用,经对比误差小于5%。对某国产加速卡,使用评估工具建议的硬件配置,对DeepSeek-R1 671B满血版进行测试,能够满足服务指标及吞吐量要求,测试及可视化代码已开源。
1.3 对比其他工具的核心优势
1.4 应用价值
AICompass 服务于大模型推理部署决策,解决开发者三大痛点,助力智算中心建设:
二、项目结构
三、使用方法
打开 index.html 文件(建议使用现代浏览器如 Chrome、Firefox 等)
选择模型配置方式:
预设模型:从下拉菜单选择主流模型(如 DeepSeek、Llama 等)
自定义模型:手动输入模型参数(支持 Dense、MoE、多模态三种类型)
调整推理配置:
设置量化方案(权重、KV Cache、激活值)
调整输入/输出长度和并发量
配置服务指标(TTFT、TPOT)
查看显存占用分析:实时显示内存分布饼图
可选功能:
启动推理速度模拟:观察实时 Token 生成过程
四、变量说明
模型参数
推理配置
服务指标
计算因子
硬件参数
五、计算方法
显存占用计算
稠密模型(Dense)显存计算
稠密模型的显存占用主要包括模型权重、KV缓存、激活值和额外开销四部分:
模型权重显存:
Mweights=Ptotal×QweightKV缓存显存:
Mkv=B×S×L×2×Hkv×Dh×Qkv激活值显存:
Mact=B×S×H×Fact×Qact额外开销显存:
Moverhead=(Mweights+Mkv+Mact)×Roverhead总显存:
Mtotal=Mweights+Mkv+Mact+Moverhead混合专家模型(MoE)显存计算
MoE模型的显存占用包括共享权重、专家权重、KV缓存、激活值和额外开销:
共享权重显存:
Mshared=Pshared×Qweight专家权重显存:
Mexpert=Pexpert×E×QweightKV缓存显存:与Dense模型相同
激活值显存:
Mact_shared=B×S×H×Fshared×QactMact_expert=B×S×Eactive×I×Fexpert×QactMact=Mact_shared+Mact_expert额外开销显存:
Moverhead=(Mshared+Mexpert+Mkv+Mact)×Roverhead总显存:
Mtotal=Mshared+Mexpert+Mkv+Mact+Moverhead多模态模型(Multimodal)显存计算
多模态模型的显存占用包括基础LLM权重、视觉模态权重、音频模态权重、KV缓存、激活值和额外开销:
基础LLM权重显存:
Mbase=Pbase×Qweight视觉模态权重显存:
Mvision=Pvision×Qweight音频模态权重显存:
Maudio=Paudio×QweightKV缓存显存:
Stotal=Stext+Simage×Fvision+Saudio×FaudioMkv=B×Stotal×L×2×Hkv×Dh×Qkv激活值显存:
Mact_llm=B×Stext×H×Fllm×QactMact_vision=B×Simage×H×Fvision_act×QactMact_audio=B×Saudio×H×Faudio_act×QactMact=Mact_llm+Mact_vision+Mact_audio额外开销显存:
Moverhead=(Mbase+Mvision+Maudio+Mkv+Mact)×Roverhead总显存:
Mtotal=Mbase+Mvision+Maudio+Mkv+Mact+Moverhead计算能力需求评估
稠密模型(Dense)算力计算
Cprefill=TTFTFbase×Smodel×Lin×Ptotal×(1/Eattn)×BCtoken=Fbase×Smodel×(1+0.1log10(Lseq))×Ptotal×(1/Eattn)×0.5×BCdecode=Ctoken×TC=max(Cprefill,Cdecode)×Fquant×Ebatch×Gcal混合专家模型(MoE)算力计算
Peffective=Pshared+Pexpert×RexpertCprefill=TTFTFbase×Smodel×Lin×Peffective×(1/Eattn)×B×FmoeCtoken=Fbase×Smodel×(1+0.1log10(Lseq))×Peffective×(1/Eattn)×0.5×B×FmoeCdecode=Ctoken×TC=max(Cprefill,Cdecode)×Fquant×Ebatch×Gcal多模态模型(Multimodal)算力计算
Cprefill=TTFTFbase×Smodel×Lin×Pbase×(1/Eattn)×B×FmmCtoken=Fbase×Smodel×(1+0.1log10(Lseq))×Pbase×(1/Eattn)×0.5×BCdecode=Ctoken×TCvision=Pvision×Fvision×BCaudio=Paudio×Faudio×BCmodal=Cvision+CaudioC=(max(Cprefill,Cdecode)+Cmodal)×Fquant×Ebatch×Gcal硬件需求计算
显卡数量计算
Nmem=⌈Mtotal/Mgpu⌉Ncomp=⌈C/(Cgpu×Ugpu)⌉N=max(Nmem,Ncomp)六、测试部分
DenseBench
在本项目的 Dense 模型显存测试中,通过理论建模与实测验证的双重手段对资源需求进行全面评估。测试框架基于配置文件解析模型的隐藏层维度、注意力头数、网络层数等结构参数,结合量化精度参数,构建显存消耗的模型。该模型将显存占用解耦为权重存储、KV缓存、激活值及系统开销四个组件:权重存储规模由参数总量与量化精度决定,KV缓存显存与批处理规模、总序列长度、注意力头维度及网络层数正相关,激活值显存通过引入每 token 的激活因子表征中间数据增量,系统级缓存等未计量项则通过预设比例系数补偿。
实际测试阶段通过构造指定长度的输入文本生成批量化的 GPU 张量,分阶段记录显存变化。模型初始化时获取基础权重加载后的显存基线,完整推理过程中动态监测多卡设备的聚合显存峰值。测试代码调用
torch.cuda.memory_allocated
接口实现显存数据的跨卡采集,同步对 KV cache 张量进行空间计算。每次推理后执行显存清理与垃圾回收,确保测试环境的一致性。测试方案设定了 16 组参数组合,涵盖批处理规模按 2 的幂次从 1 到 32 的梯度扩展,以及输入/输出序列长度在 256 至 2048 tokens 区间的四种典型组合模式(短输入短输出、短输入长输出、长输入短输出、长输入长输出)。这种多维参数空间设计可系统性揭示批处理规模与序列长度对显存占用的耦合效应,为不同推理场景提供资源消耗基线。
执行过程中测试程序自动生成 CSV 格式报告,包含推理耗时、吞吐量、理论/实测显存分解数据。通过比对权重与KV缓存的实际值与理论计算值,可校验估算公式的准确性。当激活值显存出现显著偏差时,差异数据将为经验性激活因子优化提供依据,增强理论模型的泛化能力。最终测试报告不仅输出各场景的显存绝对值,更通过组件级资源占比分析,为分布式训练模型切分、推理服务批处理规模优化等决策提供量化支撑。
针对
llama2-7B/13B
模型的实测数据显示,理论预估与实测显存占用的误差控制在 5% 以内,验证了计算模型的有效性。MoeBench
在 MoE 模型的显存测试框架中,我们针对稀疏激活特性构建了差异化的显存估算模型。与 Dense 模型不同,MoE 模型的参数量被解构为共享参数与专家参数两部分:共享参数包含嵌入层、注意力机制及路由门控网络,其显存占用由隐藏层维度与词汇表的乘积(嵌入层)叠加注意力参数构成;专家参数则基于FFN层的专家网络参数量乘以专家总数,采用分设备存储策略时,实际算力需求仅需计算活跃专家参数。
激活值显存计算引入双因子机制,共享激活部分沿用与 Dense 模型相同的
MOE_SHARED_ACTIVATION_FACTOR
,专家激活部分则采用MOE_EXPERT_ACTIVATION_FACTOR
,两者分别乘以序列长度、批处理规模及中间层维度。由于 MoE 模型在推理时仅激活部分专家网络,实测阶段通过遍历模型输出的past_key_values
张量,精确捕获各专家层的显存波动,特别监测专家切换时的显存增量。结果分析模块新增共享权重/专家权重的显存占比对比曲线,揭示不同批处理规模下模型结构的显存分布规律。当处理长序列任务时,专家激活显存的增长速度显著高于共享部分,这种现象为专家负载均衡策略的优化提供了数据支持。测试报告同时记录路由决策耗时,帮助开发者辨识显存消耗与计算效率的平衡点。
MultimodalBench
在多模态模型测试中,显存计算采用了实测与理论估算相结合的方法,通过动态测量和参数推导全面评估显存需求。测试脚本首先加载多模态模型,并解析模型配置文件中的关键参数,包括隐藏层维度、注意力头数、图像处理尺寸等配置信息。模型权重通过设备映射分配到多个 GPU 上,同时根据图像 Patch 尺寸动态计算视觉模块的输入序列长度,为后续显存分析奠定基础。
在显存实测环节,测试程序通过 CUDA 接口实时追踪显存状态。每次推理前重置所有 GPU 的峰值显存统计,随后生成模拟输入序列并执行模型推理。在推理过程中,系统精确记录模型权重加载的初始显存占用、KV 缓存的动态增长以及激活值的瞬时消耗,最终通过峰值显存统计接口获取实际显存占用量。针对多模态特性,测试特别处理了视觉模块的图像输入,通过处理器生成符合模型要求的图像张量,确保视觉与文本模态的联合推理符合真实场景。
理论计算部分构建了分模块的显存估算模型。模型权重显存通过参数量与量化精度计算,其中基础语言模型、视觉编码器的参数量分别从配置文件动态提取。KV 缓存显存则基于批处理大小、总序列长度(文本 Token 数与图像 Patch 数的加权求和)、注意力层数及头维度进行矩阵式推导,量化精度单独设定。激活值显存通过引入模态相关因子动态调整,准确反映不同模块的计算强度。理论模型还预留了额外开销比例,以覆盖框架层和通信的隐性成本。
测试同样覆盖了典型推理场景的显存压力测试,包括短/长文本输入与生成长度的四种组合,以及多批次规模的横向对比。每次测试后,系统将实测峰值显存、理论分解值(权重 / KV缓存 / 激活值 / 其他)及推理吞吐量写入结构化 CSV 报告。这种双轨验证机制既提供了即时的显存监控数据,又通过理论模型揭示显存瓶颈的构成因素,为模型部署时的资源预判提供可解释的量化依据。
下面是我们对 Mixtral 8x7B(MoE)模型和 llava-1.5(Multimodal)模型的测试结果展示:
Perf-Test
算力测试部分的实现通过构建通用基准测试框架,评估硬件在不同计算类型和数据类型下的性能表现。测试框架以矩阵乘法 (GEMM) 和层归一化 (LayerNorm) 为代表操作,分别衡量计算密集型任务的理论算力和访存密集型任务的有效带宽。整体设计兼顾测试结果的稳定性和测量精度,采用预热迭代消除初始化干扰,利用 CUDA 事件实现纳秒级异步计时,并通过多次测试取均值降低偶然误差。
测试流程首先通过
prepare_func
函数生成特定维度的随机张量,确保每次测试的输入数据具备一致性。预热阶段执行 20 次迭代操作,使 GPU 达到稳定工作状态并完成内核编译。正式测试阶段通过 CUDA 事件精确记录 100 次迭代的总耗时,计算单次操作平均时间时同步等待所有计算核心完成任务,避免流水线并行带来的计时偏差。性能计算模块根据算子特征采用差异化的评估策略。GEMM 测试基于矩阵维度参数,通过
2*M*N*K
公式估算浮点运算量,最终输出 TFLOPS 指标反映计算单元的理论峰值利用率。LayerNorm 测试则根据张量元素数量和数据精度计算内存读写总量,输出有效带宽指标反映存储系统的数据传输效率。错误处理机制实时捕获内存溢出、数据类型不兼容等异常,确保测试流程的鲁棒性。我们的测试中,NVIDIA A100-40G PCIe 的测试结果如下:
结果显示 NVIDIA A100-40G PCIe 实际的利用率在 80% 作用。因此我们可以在网页中设置计算卡的利用率为 0.8:
SLO-test
SLO(Service Level Objective)是对系统服务质量的量化承诺指标,在人工智能推理场景中主要用于衡量系统响应能力与服务质量。
下面是对其中涉及到的一些指标的解释:
在测试中,我们将 DeepSeek 671B 满血版作为被测模型,通过项目中的自定义硬件方式,指定了某国产加速卡的性能配置(FP16 算力 1123TFLOPS,显存 96GB),并且声明了我们测试的 SLO(TTFT 500 ms, TPOT 50 ms)。
通过我们的 AICompass 项目,我们得出如果要部署项目,需要使用 16 卡的配置。经过 vllm benchmark 的测试,最终得出结论:实际部署的性能能够达到用户目标吞吐量。
参考文献