模型使用指南 | AtomGit AI 社区帮助文档

模型中心

Mon, 01 Jan 0001 00:00:00 +0000

模型中心就像是AI模型的"图书馆"，里面存放着各种已经训练好的AI模型。这些模型就像是有特殊技能的助手，可以帮助你完成各种任务，比如识别图片、翻译文字、分析数据等。

什么是AI模型？

简单理解

想象一下，AI模型就像是一个经过大量练习的学生：

图像识别模型：就像是一个看过无数张图片的人，能够认出图片里是什么
文本处理模型：就像是一个读过很多书的人，能够理解和生成文字
语音识别模型：就像是一个听过很多声音的人，能够听懂你说的话

模型的作用

有了这些模型，你就不需要从零开始训练AI了，可以直接使用现成的。想要识别图片？直接使用图像分类模型。想要翻译文字？直接使用机器翻译模型。想要分析情感？直接使用情感分析模型。

模型分类

按任务分类

图像处理类包括图像分类（识别图片里是什么东西）、目标检测（找出图片中物体的位置）、图像分割（把图片分成不同的区域）和人脸识别（识别和验证人脸）。

文字处理类包括文本分类（给文字贴上标签）、机器翻译（把一种语言翻译成另一种）、问答系统（回答用户的问题）和文本生成（自动生成文章或对话）。

音频处理类包括语音识别（把语音转换成文字）、语音合成（把文字转换成语音）、音乐生成（创作新的音乐作品）和声音分类（识别不同的声音类型）。

按难度分类

入门级模型功能简单，容易使用，适合初学者学习，运行速度快，资源需求少。

进阶级模型功能更强大，效果更好，需要一定的技术基础，可能需要更多计算资源。

专业级模型功能最全面，效果最好，需要专业知识和经验，通常需要强大的硬件支持。

如何找到合适的模型

搜索方法

关键词搜索：在搜索框输入你需要的功能，比如"图像分类"，系统会显示相关的模型，浏览结果，找到最适合的。

分类浏览：点击"模型分类"菜单，选择你需要的任务类型，浏览该分类下的所有模型。

标签筛选：使用标签来缩小搜索范围，比如选择"中文"、“入门”、“免费"等标签，系统会显示符合所有标签的模型。

选择建议

考虑因素包括你的技术水平（初学者选择简单的模型）、任务需求（明确需要什么功能）、资源限制（考虑你的电脑配置）和使用许可（确认是否可以商用）。

查看信息包括模型描述（了解模型能做什么）、使用示例（看看具体怎么用）、用户评价（了解其他用户的使用体验）和更新记录（确认模型是否还在维护）。

模型使用

基本步骤

第一步：选择模型。在模型中心找到合适的模型，点击进入模型详情页面，仔细阅读使用说明。

第二步：下载模型。点击"下载"按钮，选择下载方式（直接下载或使用代码），等待下载完成。

第三步：使用模型。按照说明安装必要的软件，运行示例代码，根据自己的需求修改代码。

使用方式

在线使用：有些模型可以直接在网页上使用，上传你的数据，点击运行即可，不需要下载和安装。

本地使用：下载模型到你的电脑，安装必要的软件环境，运行代码使用模型。

API调用：通过编程接口调用模型，适合集成到自己的应用中，需要一定的编程基础。

模型质量

如何判断模型好坏

查看指标包括准确率（模型预测正确的比例）、速度（模型运行的速度）、大小（模型文件的大小）和更新（最后更新的时间）。

用户反馈包括评分（其他用户给出的评分）、评论（用户的使用体验）、下载量（受欢迎程度）和使用案例（实际应用效果）。

注意事项

使用限制包括有些模型有使用次数限制、有些模型需要付费使用、有些模型有使用许可要求、有些模型只能在特定环境下使用。

技术要求包括确认你的电脑配置是否满足要求、检查是否安装了必要的软件、了解模型的使用方法、准备好测试数据。

常见问题

模型下载失败

可能原因包括网络连接不稳定、模型文件太大、服务器暂时不可用、你的账号权限不足。

解决方法包括检查网络连接、尝试重新下载、联系客服寻求帮助、使用其他下载方式。

模型运行出错

可能原因包括软件环境不匹配、缺少必要的依赖、输入数据格式不对、硬件资源不足。

解决方法包括检查软件版本、安装缺失的依赖、确认数据格式、升级硬件配置。

效果不理想

可能原因包括模型不适合你的任务、数据质量不够好、参数设置不合理、使用方式不正确。

解决方法包括尝试其他模型、改进数据质量、调整参数设置、学习正确的使用方法。

使用建议

新手建议

从简单的开始：先使用入门级模型，熟悉基本操作。多看示例：学习别人是怎么使用的。多练习：用不同的数据测试模型。及时求助：遇到问题及时寻求帮助。

进阶建议

理解原理：了解模型背后的工作原理。优化参数：根据实际需求调整模型参数。组合使用：将多个模型组合起来使用。分享经验：把自己的使用经验分享给其他人。

模型卡片

Mon, 01 Jan 0001 00:00:00 +0000

模型卡片就像是模型的"身份证"，详细介绍了这个模型能做什么、怎么用、有什么特点等信息。就像买东西要看说明书一样，使用模型前也要仔细阅读模型卡片。

模型卡片包含什么信息？

基本信息

模型名称和版本包括模型叫什么名字、当前是什么版本、谁创建的这个模型、什么时候发布的。

模型用途包括这个模型能做什么、适合什么场景使用、有什么特殊功能、能达到什么效果。

使用说明

环境要求包括需要什么软件、需要什么硬件配置、支持什么操作系统、需要多少存储空间。

安装步骤包括如何下载模型、如何安装依赖、如何配置环境、如何验证安装。

使用方法包括基本的使用步骤、输入数据的格式、输出结果的说明、常见的使用场景。

如何阅读模型卡片？

第一步：了解基本信息

看标题和描述：模型叫什么名字，主要功能是什么，适合什么水平的用户。

检查要求：你的电脑配置是否满足要求，是否安装了必要的软件，是否有足够的时间和精力。

第二步：查看使用说明

安装指南：按照步骤一步步安装，遇到问题及时查看帮助，确认安装成功后再使用。

使用示例：运行提供的示例代码，理解输入输出的格式，尝试修改参数看效果。

第三步：了解限制和注意事项

使用限制：有什么使用条件，有什么功能限制，有什么时间限制。

注意事项：数据格式要求，性能影响因素，常见问题解决。

模型卡片中的重要信息

性能指标

准确率：模型预测正确的比例，数值越高效果越好，但也要考虑实际需求。

速度：模型运行的速度，处理一张图片需要多长时间，是否满足你的实时性要求。

资源需求：需要多少内存，是否需要GPU，是否能在你的设备上运行。

使用许可

开源许可：可以免费使用，可以修改和分享，但要注意许可条款。

商用许可：是否可以商用，是否需要付费，有什么使用限制。

使用声明：模型的使用范围，禁止的使用方式，责任和免责声明。

如何选择合适的模型？

根据需求选择

任务类型：明确你要解决什么问题，选择专门针对该任务的模型，不要用图像模型做文字任务。

难度级别：初学者选择简单的模型，有经验后可以尝试复杂的，根据学习进度逐步提升。

资源限制：考虑你的硬件配置，考虑你的时间预算，考虑你的技术能力。

根据评价选择

用户评分：查看其他用户的评分，阅读用户的使用体验，了解模型的优缺点。

使用案例：看看别人是怎么用的，了解实际应用效果，学习使用技巧。

更新维护：模型是否还在更新，问题是否及时修复，社区是否活跃。

使用模型的建议

新手建议

从简单的开始：选择功能单一的模型，先运行示例代码，熟悉基本操作后再深入。

多看文档：仔细阅读使用说明，查看常见问题解答，学习最佳实践。

多练习：用不同的数据测试，尝试不同的参数，记录使用经验。

进阶建议

理解原理：了解模型的工作原理，学习相关的理论知识，掌握调优技巧。

优化使用：根据实际需求调整参数，优化数据处理流程，提高运行效率。

分享经验：帮助其他用户，分享使用技巧，参与社区讨论。

常见问题

模型卡片信息不完整

可能原因包括模型刚发布，信息还在完善；创建者没有详细填写；某些信息不适合公开。

解决方法包括查看是否有其他文档、联系模型创建者、在评论区询问其他用户。

示例代码运行失败

可能原因包括环境配置不正确、依赖版本不匹配、数据格式不对。

解决方法包括检查环境配置、更新依赖版本、确认数据格式。

效果不如预期

可能原因包括数据质量不够好、参数设置不合理、使用方式不正确。

解决方法包括改进数据质量、调整参数设置、学习正确的使用方法。

总结

模型卡片是使用AI模型的重要参考资料。学会阅读和理解模型卡片，能帮助你选择合适的模型（根据需求和能力选择）、正确使用模型（按照说明操作，避免错误）、解决问题（遇到问题时能找到答案）和提高效率（少走弯路，快速上手）。

记住，好的模型卡片就像好的说明书，能让你事半功倍。如果遇到不清楚的地方，不要犹豫，及时寻求帮助！

上传模型

Mon, 01 Jan 0001 00:00:00 +0000

上传模型就像是把自己的作品放到"图书馆"里，让其他人也能使用。如果你训练了一个AI模型，或者找到了一个有用的模型，可以上传到平台分享给大家。

上传前需要准备什么？

模型文件

基本文件包括模型文件（训练好的模型数据）、配置文件（说明模型的结构和参数）和使用说明（告诉别人怎么用这个模型）。

可选文件包括示例代码（展示如何使用模型）、测试数据（验证模型效果）和训练记录（记录训练过程）。

模型信息

基本信息包括模型名称（起一个容易记住的名字）、模型描述（简单说明模型能做什么）、适用场景（适合什么任务使用）和技术特点（有什么特殊功能）。

分类信息包括任务类型（图像分类、文本处理等）、难度级别（入门、进阶、专业）、适用领域（通用、医疗、金融等）和标签（帮助别人找到你的模型）。

如何上传模型？

方法一：网页上传

第一步：登录账号。打开浏览器，访问平台，点击右上角"登录"按钮，输入用户名和密码。

第二步：开始上传。登录成功后，点击"上传模型"，或者点击导航栏中的"模型" → “上传模型”。

第三步：填写信息。上传模型文件，填写模型信息，选择分类和标签，设置访问权限。

第四步：完成上传。检查信息是否正确，点击"上传"按钮，等待上传完成。

方法二：命令行上传

安装工具：下载并安装命令行工具，在电脑上打开命令行，登录你的账号。

上传命令：进入模型文件所在文件夹，运行上传命令，按照提示填写信息。

方法三：API上传

适合程序员：编写上传代码，调用上传接口，自动完成上传。

上传时需要注意什么？

文件要求

文件格式：支持常见的模型格式，文件大小不能超过限制，文件名不能包含特殊字符。

文件完整性：确保模型文件没有损坏，检查配置文件是否正确，验证示例代码能否运行。

信息填写

描述要清楚：用简单的语言说明功能，列出主要特点，提供使用建议。

标签要准确

选择最相关的标签
避免使用过于专业的术语
考虑用户搜索习惯

分类要合适

选择最准确的分类
不要放在错误的类别下
便于其他用户找到

上传后的管理

查看状态

上传进度

查看上传是否成功
检查文件是否完整
确认信息是否正确

审核状态

等待平台审核
查看审核结果
根据反馈修改

更新维护

修改信息

更新模型描述
添加新的标签
修改分类信息

更新文件

上传新版本的模型
更新示例代码
添加新的文档

回复评论

回答用户问题
收集使用反馈
改进模型质量

常见问题

上传失败

可能原因包括网络连接不稳定、文件太大、格式不支持、信息填写不完整。

解决方法包括检查网络连接、压缩文件大小、转换文件格式、完善信息填写。

审核不通过

可能原因包括内容不符合要求、信息描述不清楚、文件有问题、违反平台规定。

解决方法包括查看审核意见、修改相关内容、重新提交审核、联系客服咨询。

使用效果不好

可能原因包括模型本身有问题、使用说明不清楚、示例代码有错误、环境配置不对。

解决方法包括检查模型质量、完善使用说明、修复示例代码、提供环境配置。

上传建议

新手建议

从简单的开始：先上传简单的模型，熟悉上传流程，积累经验后再上传复杂的。

准备要充分：确保模型能正常工作，写清楚使用说明，提供完整的示例。

多学习他人：看看别人是怎么上传的，学习好的描述方式，参考成功的案例。

进阶建议

提高质量：优化模型性能，完善文档说明，提供技术支持。

积极维护：及时回复用户问题，根据反馈改进模型，定期更新维护。

参与社区：帮助其他用户，分享使用经验，参与技术讨论。

总结

上传模型是分享知识、帮助他人的好方式。通过上传模型，你可以展示技术能力（让别人看到你的成果）、帮助其他用户（解决他们的问题）、获得反馈建议（改进模型质量）和建立专业形象（在社区中获得认可）。

下载模型

Mon, 01 Jan 0001 00:00:00 +0000

下载模型就像是把"图书馆"里的书借回家使用。找到合适的模型后，你需要下载到自己的电脑上，然后按照说明来使用。

如何找到要下载的模型？

搜索方法

关键词搜索：在搜索框输入你需要的功能，比如输入"图像分类"、“中文翻译"等，浏览搜索结果，找到合适的模型。

分类浏览：点击"模型分类"菜单，选择你需要的任务类型，浏览该分类下的所有模型。

标签筛选：使用标签来缩小搜索范围，比如选择"中文”、“入门”、“免费"等，系统会显示符合所有标签的模型。

选择建议

查看模型信息：模型描述（了解模型能做什么）、使用说明（看看具体怎么用）、用户评价（了解其他用户的使用体验）、更新记录（确认模型是否还在维护）。

考虑你的需求：技术水平（初学者选择简单的模型）、任务需求（明确需要什么功能）、资源限制（考虑你的电脑配置）、使用许可（确认是否可以商用）。

如何下载模型？

方法一：直接下载

网页下载：进入模型详情页面，找到"下载"按钮，选择下载方式，等待下载完成。

下载选项：完整模型（包含所有文件）、仅模型文件（只下载核心模型）、示例代码（下载使用示例）、文档说明（下载使用文档）。

方法二：使用代码下载

安装工具：在电脑上安装Python，安装下载工具，打开命令行或代码编辑器。

下载命令：使用Python代码下载模型，可以指定下载位置和参数。

方法三：批量下载

多个模型：如果你需要多个相关模型，可以一次性下载多个，节省时间和精力。

下载列表：创建下载清单，设置下载顺序，自动管理下载进度。

下载后如何使用？

基本步骤

第一步：解压文件。下载完成后，解压文件，查看文件夹结构，找到主要的模型文件。

第二步：安装依赖。查看需要什么软件。 2. 安装必要的程序 3. 确认环境配置正确

第三步：运行示例

找到示例代码
按照说明运行
确认模型能正常工作

使用方式

本地运行

在你自己电脑上运行
需要安装相关软件
可以离线使用

在线使用

有些模型可以直接在网页上使用
不需要下载和安装
但需要网络连接

集成到应用

把模型集成到你的程序中
需要一定的编程基础
可以实现更复杂的功能

下载时可能遇到的问题

网络问题

下载速度慢

网络连接不稳定
模型文件太大
服务器访问人数多

解决方法

检查网络连接
选择网络较好的时间
使用下载工具
尝试其他下载方式

文件问题

下载不完整

网络中断导致下载失败
文件损坏
存储空间不足

解决方法

重新下载
检查文件完整性
清理存储空间
使用断点续传功能

权限问题

无法下载：模型需要特殊权限，你的账号权限不足，模型已被删除或隐藏。

解决方法：申请访问权限，联系模型创建者，升级账号等级，寻找替代模型。

使用建议

新手建议

从简单的开始：先下载简单的模型，熟悉基本操作，积累使用经验。

多看说明：仔细阅读使用说明，按照步骤操作，遇到问题及时查看帮助。

多练习：用不同的数据测试，尝试不同的参数，记录使用经验。

进阶建议

理解原理：了解模型的工作原理，学习相关的理论知识，掌握调优技巧。

优化使用：根据实际需求调整参数，优化数据处理流程，提高运行效率。

分享经验：帮助其他用户，分享使用技巧，参与社区讨论。

常见问题

模型无法运行

可能原因包括软件环境不匹配、缺少必要的依赖、输入数据格式不对、硬件资源不足。

解决方法包括检查软件版本、安装缺失的依赖、确认数据格式、升级硬件配置。

效果不理想

可能原因包括模型不适合你的任务、数据质量不够好、参数设置不合理、使用方式不正确。

解决方法包括尝试其他模型、改进数据质量、调整参数设置、学习正确的使用方法。

存储空间不足

可能原因包括模型文件太大、电脑存储空间不够、下载了不需要的文件。

解决方法包括清理存储空间、只下载必要的文件、使用外部存储设备、选择较小的模型。

总结

下载模型是使用AI的第一步。通过下载模型，你可以获得AI能力（使用现成的AI模型）、学习技术（了解AI的工作原理）、解决问题（用AI解决实际问题）和提高效率（自动化处理任务）。

记住，下载模型只是开始，更重要的是学会使用。多练习，多学习，你就能充分发挥AI模型的价值！

计量说明

Mon, 01 Jan 0001 00:00:00 +0000

为了让开发者与企业用户更高效地使用 AtomGit AI 的模型能力，本计量说明文档对 Token 消耗、模型类型、Notebook/Space 核时计算 等内容进行统一说明，帮助你清晰了解资源计算规则及预估方式。

一、计量方式概览

AtomGit AI 目前提供两类资源计量方式：

Token 计量：适用于文本生成、图文转文本生成、文本生成图像、句子相似度、自动语音识别等模型推理服务。
核时计量：适用于 Notebook、Space 等需要计算资源的场景。

不同服务的计量方式独立计算，互不影响。

二、Token 计量规则

不同模型类型会消耗不同数量的 Token。以下为常见模型类型的 Token 预估规则：

模型类型	中文 Token 估算规则	英文 Token 估算规则	补充说明
文本生成	1 Token ≈ 1.5–1.8 个汉字	1 Token ≈ 4 个英文字符	不同模型采用的分词算法不一致，实际 Token 会有轻微差异。
图文转文本	1 Token ≈ 1.5–2 个汉字	1 Token ≈ 4 个英文字符	图像部分 Token 会根据分辨率计算：如 512×512≈334 Token。
句子相似度	1 Token ≈ 1.5-2 个汉字	1 Token ≈ 4 个英文字符	相似度结果分数约消耗 4 个 token。
自动语音识别	50,000 Token / 次		小于50M的音频文件每次成功生成消耗 50,000 Token
文生图	50,000 Token / 张图		不同分辨率与质量可能导致 Token 消耗调整，具体以调用结果为准。

说明：表格数据为一般估算规则，具体 Token 消耗以实际 API 返回为准。

三、核时计算规则（Notebook / Space）

Notebook 与 Space 使用 CPU 资源，采用核时计量方式。

核时计算公式：

核时 = CPU 核数 × 运行时间（小时）

Notebook / Space 核时消耗参考表

CPU 核数	10 分钟	30 分钟	60 分钟	120 分钟
0.5 核	0.08	0.25	0.5	1
2 核	0.34	1	2	4
4 核	0.67	2	4	8
8 核	1.34	4	8	16
16 核	3.34	8	16	32
32 核	5.34	16	32	64

说明：

Notebook 与 Space 计量逻辑一致；
实际扣取会根据资源使用日志精确计算，以实际使用日志计量为准；
多实例并发计算按实例累加；

四、常见问题

1. 总 Token 消耗怎么计算？

总 Token = 输入 Token + 输出 Token

输入输出越长，总 Token 消耗也越多。

2. 中英文混合 Token 怎么算？

系统会根据模型分词策略自动识别，中英文混合无需手动区分。

3. 图像 Token 为什么会变化？

取决于图像大小与模型支持的分辨率，通常分辨率越大 Token 越多。

以上就是 AtomGit AI 的计量方式说明。无论你是在使用推理 API、模型在线体验，还是在 Notebook / Space 中运行代码，都可以根据表格规则预估资源消耗。希望这份文档能帮助你更清楚地理解 Token 与核时的计算方式，方便你更安心地使用平台的各类模型与服务。遇到任何疑问，也欢迎随时在社区中联系我们。

模型可用性测试

Mon, 01 Jan 0001 00:00:00 +0000

模型可用性测试定义

模型可用性测试旨在验证用户基于本文档编写的自定义推理用例在NPU上执行是否通过。

如何进行模型可用性测试

遵循下文模型可用性测试运行脚本的指导编写脚本。注意：只有模型适配仓库管理员并且仓库硬件类型为npu,才可以提交模型可用性测试申请。
点击模型评测tab栏，进入模型评测页面。
在模型评测的页面，点击“可用性测试”的tab，选择模型的权重文件，然后单击“立即测试”，就可以发起测试。
等待模型可用性测试用例执行完成。
(可选) 当模型处于“测试中”时，用户可以单击“终止测试”手动停止测试。
当模型评测完成后，在“可用性测试”区域显示执行结果。同时提供日志下载和测试结果查看。

模型可用性测试运行脚本

模型可用性测试脚本以deploy.sh为入口。脚本编写请严格遵照本文档的规范。

模型可用性测试脚本必须包含以下两个文件:

requirements.txt：该脚本运行需配置的相应module (如果没有需要安装的依赖，则无需创建)。
deploy.sh: 模型评测服务基于该脚本安装依赖和启动此模型适配项目。

文件位置

requirements.txt和deploy.sh必须位于仓库根目录下。

requirements.txt文件（可选）

请设置NPU下运行该脚本需要配置的对应依赖，Torch_npu、Cann和Python根据选择的框架版本由环境提供，因此在requirements.txt中不需要重复上述依赖的添加（可能会导致依赖安装冲突异常）。库的依赖脚本格式示例如下：

transformers==4.37.0
accelerate==0.27.2

如果不需要添加任何依赖，该.txt文件可不提供，测试任务会跳过依赖安装。

deploy.sh文件

该文件是一个执行启动模型适配推理的shell脚本，该推理脚本运行方式无严格限制，以下为脚本规范。

执行安装依赖编写示例（可选）

python3 -m pip install --upgrade pip setuptools wheel

构造执行脚本所需要的入参

模型权重由自动化测试执行侧根据模型评测发起时页面选择模型权重仓库，在执行测试的时候下载。在shell脚本中，如果需要传入权重路径，可以通过环境变量"$MODEL_PATH"获取权重文件所在的path路径。如vllm启动项目，则传入模型path路径示例如下：

vllm serve "$MODEL_PATH" --trust-remote-code --tensor-parallel-size 1 --dtype float16 --max-num-seqs 4 --gpu-memory-utilization 0.95

适配代码编写要求

适配推理代码需要提供标准的，并且启动http server服务的端口必须为：8000。模型评测服务会根据选择的模型权重文件任务类型调用对应的推理接口进行模型评测 目前已经支持评测任务类型如下：

任务类型	任务编码	推理接口path
文本生成	text-generation	/v1/chat/completions
图片转文本	image-text-to-text	/v1/chat/completions
文本转语音	text-to-speech	/v1/audio/speech
多模态	any-to-any	/v1/chat/completions
语音识别	automatic-speech-recognition	/v1/audio/transcriptions
向量化	embedding	/v1/embeddings

注：如果适配框架为vllm启动方式，则可以忽略此条规则，因为vllm框架已经按照openapi规范提供标准推理接口。

模型权重文件大小限制

大小上限：100GB
限制说明：适配模型权重文件存储大小不得超出上限。
影响范围：若超出限制，将触发模型权重文件下载失败，直接导致模型评测任务失败。

全流程代码示例

deploy.sh

vllm适配验证示例：

#!/bin/sh
set -e
echo "=== MODEL_PATH set to: $MODEL_PATH ==="
vllm serve "$MODEL_PATH" --trust-remote-code --tensor-parallel-size 1 --dtype float16 --max-num-seqs 4 --gpu-memory-utilization 0.95

注：上面示例为vllm启动方式，无需设置–served-model-name，模型评测服务会自动使用模型权重的path作为serverd-model-name.

模型精度测试

Mon, 01 Jan 0001 00:00:00 +0000

关于模型精度测试

模型精度测试定义

功能描述：模型精度测试旨在验证用户基于本文档编写的自定义推理在特定数据集上的预测准确率。
要求：模型推理服务需支持流式接口/v1/chat/completions方式访问

如何进行模型精度测试

遵循下文模型精度测试运行脚本的指导编写脚本。注意：只有模型适配仓库管理员并且仓库硬件类型为npu,才可以发起模型精度测试。
点击模型评测tab栏，进入模型评测页面。
在模型精度评测页面，点击“精度测试”的tab，选择模型的权重文件仓库，然后单击“立即测试”，发起精度测试。
等待精度测试执行完成。
(可选) 当精度测试处于“测试中”时，用户可以单击“终止测试”手动停止测试。
当精度测试完成后，在“精度测试”区域显示测试状态，并提供测试日志和评测报告下载。

模型精度测试运行脚本

模型精度测试脚本以deploy.sh为入口。脚本编写请严格遵照本文档的规范。

模型精度测试的适配仓库须包含以下文件:

requirements.txt：该脚本运行需配置的相应module ,如果没有需要安装的依赖，则无需创建 (非必须)。
deploy.sh: 模型评测服务基于该脚本安装依赖和启动此模型适配项目 (必须)。

文件位置

requirements.txt和deploy.sh必须位于仓库根目录下。

requirements.txt文件（可选）

transformers==4.37.0
accelerate==0.27.2

如果不需要添加任何依赖，该.txt文件可不提供，测试任务会跳过依赖安装。

deploy.sh文件

该文件是一个执行启动模型适配推理的shell脚本，该推理脚本运行方式无严格限制，以下为脚本规范。

执行安装依赖编写示例（可选）

python3 -m pip install --upgrade pip setuptools wheel

构造执行脚本所需要的入参

模型权重由自动化测试执行侧根据模型精度测试发起时页面选择模型权重仓库，在执行测试的时候下载。在shell脚本中，如果需要传入权重路径，可以通过环境变量"$MODEL_PATH"获取权重文件所在的path路径。如vllm启动项目，则传入模型path路径示例如下：

vllm serve "$MODEL_PATH" --trust-remote-code --tensor-parallel-size 1 --dtype float16 --max-num-seqs 4 --gpu-memory-utilization 0.95

适配代码编写要求

适配推理代码需要提供标准的，并且启动http server服务的端口必须为：8000。模型评测服务会根据选择的模型权重文件任务类型调用对应的推理接口进行模型精度测试，目前已经支持评测任务类型如下：

任务类型	任务编码	推理接口path
文本生成	text-generation	/v1/chat/completions
图片转文本	image-text-to-text	/v1/chat/completions
多模态	any-to-any	/v1/chat/completions

注：模型精度测试服务依赖请求/v1/chat/completions进行测试，如果不存在此推理接口，会导致精度评测任务失败。

模型权重文件大小限制

大小上限：100GB
限制说明：适配模型权重文件存储大小不得超出上限。
影响范围：若超出限制，将触发模型权重文件下载失败，直接导致模型精度测试任务失败。

全流程代码示例

deploy.sh

vllm适配验证示例：

#!/bin/sh
set -e
echo "=== MODEL_PATH set to: $MODEL_PATH ==="
vllm serve "$MODEL_PATH" --trust-remote-code --tensor-parallel-size 1 --dtype float16 --max-num-seqs 4 --gpu-memory-utilization 0.95

注：上面示例为vllm启动方式，无需设置–served-model-name，模型评测服务会自动使用模型权重的path作为serverd-model-name.

精度测试报告

精度评测执行成功以后，下载精度测试报告，解压缩以后，包含以下文件夹：configs、predictions、results、summary，

最终生成的目录结构如下：

ee9480acbbac4d4aa190a124d5ddf39c/
├── configs # 模型任务、数据集任务和结构呈现任务对应的配置文件合成的一个配置
│ └── 20260326_151326_29317.py
├── logs # 执行过程中日志，命令中如果加--debug，不会有过程日志落盘（都直接打印出来了）
│ ├── eval
│ │ └── vllm-api-general-chat
│ │ └── demo_gsm8k.out # 基于predictions/文件夹下的推理结果的精度评测过程的日志
│ └── infer
│ └── vllm-api-general-chat
│ └── demo_gsm8k.out # 推理过程日志
├── predictions
│ └── vllm-api-general-chat
│ └── demo_gsm8k.json # 推理结果（推理服务返回的所有输出）
├── results
│ └── vllm-api-general-chat
│ └── demo_gsm8k.json # 精度评测计算的原始分数
└── summary
 ├── summary_20260326_151326.csv # 最终精度分数呈现（表格格式）
 ├── summary_20260326_151326.md # 最终精度分数呈现（markdown格式）
 └── summary_20260326_151326.txt # # 最终精度分数呈现（文本格式）

summary文件夹下中summary_20260326_151326.md的内容展示如下：

dataset	version	metric	mode	vllm-api-stream-chat
demo_gsm8k	0ba9da	accuracy (5 runs average)	gen	5.60
demo_gsm8k	0ba9da	avg@5	gen	5.60
demo_gsm8k	0ba9da	pass@5	gen	24.00
demo_gsm8k	0ba9da	cons@5	gen	0.00

精度测试结果说明

一、计算公式中 `n` 、`k` 与API配置文件中 `num_return_sequences` 的三者关系

1. `pass@k`的计算逻辑

此处仅简要描述pass@k一个指标作为参考，其它指标计算公式请参考

pass@k是代码生成任务的核心评估指标，用于衡量模型在生成k个候选解时，至少有一个解能通过所有测试用例的概率。其计算采用无偏估计方法，避免直接采样导致的方差问题。具体逻辑如下：

生成样本与正确性统计：
- 对每个问题生成n个候选解（n ≥ k），其中c个解通过测试（即功能正确）。
- 例如：生成n=100个样本，其中c=20个正确，则单样本通过率。
组合数学公式：
- 计算从n个样本中随机抽取k个样本时，全部失败的概率：
$$ \frac{\binom{n-c}{k}}{\binom{n}{k}} $$
- pass@k为至少一个成功的概率：
$$ pass@k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} $$
- 优化计算：为避免阶乘溢出，代码实现使用数值优化：
```
pass@k = 1 - np.prod(1.0 - k / np.arange(n - c + 1, n + 1))
```
无偏估计的意义：
- 在当前实现中，k和n暂时仅支持通过num_return_sequences配置为相同的值，故此处仅探讨无偏估计实现的优势
- 直接采样k次会导致高方差（尤其当k较大时），而生成n（n >> k）个样本后通过组合公式估算，显著提升统计稳定性。示例：若n=5, c=3, k=2：
- 全部失败概率 = C(2,2)/C(5,2) = 1/10 = 0.1
- pass@2 = 1 - 0.1 = 0.9（即90%概率在2次尝试中至少成功一次）。

2. 参数中的`n`、`k`与`num_return_sequences`的关系

三者均需为正整数，精度测试服务中num_return_sequences默认为：5。

是否支持配置	参数	解释	定义位置	约束关系
否	n	副本数（即每个问题生成`n`个副本），也叫作总生成样本数	目前不支持单独配置，取值为`num_return_sequences`	需满足：`n ≥ k`，但当前实现不支持单独配置，故无需关注
否	k	评估时随机抽取的样本数，决定`pass@k`的抽样规模	目前不支持单独配置，取值为`num_return_sequences`	需满足：`n ≥ k`，但当前实现不支持单独配置，故无需关注
是	num_return_sequences	单条请求独立重复推理次数	API模型配置文件，默认为`5`	-

3. 总结

pass@k逻辑：基于组合数学的无偏估计，解决直接采样的高方差问题。
当前实现的计算逻辑中的参数关系与约束：
- n和k目前不支持单独配置，仅num_return_sequences可在API配置文件中指定
- n = k = num_return_sequences
- pass@k、cons@k和avg@n名称中的k或n均为num_return_sequences

由于n和k虽然仅在评估阶段用于指标计算，而num_return_sequences用于推理过程，但取值来自于API配置文件中的num_return_sequences，所以在执行评估阶段（–mode eval）时，请确保reuse的推理结果中，配置的num_return_sequences与当前num_return_sequences值保持一致。

二、pass@k, cons@k, avg@n 的定义与关系

1. 背景介绍

在大语言模型和多模态理解强化学习评估中，pass@k、cons@k 和 avg@n 是三个核心指标，用于从不同维度衡量模型在多次推理中的表现。这些指标适用于代码生成、数学推理、强化学习等需要多次独立推理的任务场景，提供对模型性能的统计学意义上的多维度评估。

2. 指标定义与计算

2.1 指标定义

指标数学定义：

pass@k：

$$ 1 - \prod_{j=n-c+1}^{n} (1 - \frac{k}{j}) $$

cons@k：

$$ \frac{1}{N} \sum_{i=1}^{N} I(c_i > k/2) $$

avg@n：

$$ \frac{1}{N} \sum_{i=1}^{N} \frac{c_i}{n} $$

指标	计算逻辑	评估目标	值域
pass@k	至少一次正确的概率（无偏估计）	模型解决能力的可靠性	[0, 1]
cons@k	多数正确的概率估计	输出结果的稳定性	[0, 1]
avg@n	平均样本正确率	预测结果的整体准确性	[0, 1]

其中：

N: 问题总数（即数据集中问题的数量）。
n: 每个问题的重复推理次数（总生成样本数），对应于代码中的 n 参数。
k: 评估抽样数，用于计算 pass@k 和 cons@k，对应于代码中的 k 参数。
cᵢ: 问题 i 的正确次数（即该问题中通过测试的样本数量）。
I(·): 指示函数（条件满足为1，否则为0）。
公式中的乘积项索引 j 从 n-c+1 到 n，确保数值稳定性。

2.2 计算逻辑详解

pass@k：基于无偏估计方法，避免直接采样的方差问题。代码中使用 compute_pass_at_k(n, c, k)函数计算，其中 n是每个问题的总样本数，c是正确样本数，k是抽样数。公式等价于组合数学形式，但采用乘积形式优化计算。
cons@k：表示模型输出的“一致性”或“稳定性”，即多数样本正确的比例。代码中对于每个问题，如果正确样本数超过，则计为1，否则计为0，然后在所有问题上取平均。这直接反映了多数投票的准确率。
avg@n：表示所有问题的平均样本级别准确率。代码中对于每个问题计算 c / n（正确率），然后在所有问题上取平均。这反映了模型预测的整体准确性。

2.3 计算示例（`num_return_sequences=3`，即`n`、`k` = `3`）

问题1：预测 [A, A, X] → 正确次数=2
问题2：预测 [B, C, B] → 正确次数=2
问题3：预测 [X, X, C] → 正确次数=1
问题4：预测 [X, X, X] → 正确次数=0

pass@3 = (1.0 + 1.0 + 1.0 + 0.0)/4 = 0.75（问题1、2、3至少一次正确，问题4没有）
avg@3 = (2/3 + 2/3 + 1/3 + 0/3)/4 = (0.6667 + 0.6667 + 0.3333 + 0.0)/4 ≈ 0.4167
cons@3 = (1 + 1 + 0 + 0)/4 = 0.5（问题1和2多数票正确，问题3和4不正确）

3. `cons@k` vs `avg@n`

3.1 大小关系分析

由于统计学意义上的定义，pass@k总是大于或等于 avg@n和 cons@k，不可能存在 pass@k小于其他两个指标的情况，故此处不比较pass@k与其它两个指标

cons@k和avg@n的大小关系不确定，主要取决于模型预测的模式。以下是几种常见情况：

情况一：`cons@k` > `avg@n`

场景：模型预测倾向于高度一致但非完全正确（即多数问题有严格多数票正确，但正确率不是100%）。
示例：设 k=3，有 2 个问题：
- 问题1：预测 [A, A, B]，真实答案 A→ 正确次数 2，正确率 2/3 ≈ 0.667；多数票正确（A出现 2 次 > 1.5），所以 cons贡献 1。
- 问题2：预测 [B, B, C]，真实答案 B→ 正确率 2/3 ≈ 0.667；多数票正确，cons贡献 1。
- avg@n= (0.667 + 0.667) / 2 = 0.667
- cons@k= (1 + 1) / 2 = 1.0
- 因此 cons@k> avg@n。

情况二：`cons@k` < `avg@n`

场景：模型预测分散，没有多数票，但平均正确率较高（即正确预测均匀分布，但缺乏一致性）。
示例：设 k=3，有 2 个问题：
- 问题1：预测 [A, B, C]，真实答案 A→ 正确次数 1，正确率 1/3 ≈ 0.333；无严格多数票（所有出现次数 ≤ 1.5），所以 cons贡献 0。
- 问题2：预测 [A, B, C]，真实答案 B→ 正确率 1/3 ≈ 0.333；无严格多数票，cons贡献 0。
- avg@n= (0.333 + 0.333) / 2 = 0.333
- cons@k= (0 + 0) / 2 = 0
- 因此 cons@k< avg@n。

情况三：`cons@k` ≈ `avg@n`

场景：模型预测几乎完美或完全错误，或者预测分布使得多数票正确率与平均正确率相近。
示例：设 k=3，有 2 个问题：
- 问题1：预测 [A, A, A]，真实答案 A→ 正确率 1.0；多数票正确，cons贡献 1。
- 问题2：预测 [B, B, B]，真实答案 C→ 正确率 0.0；多数票错误，cons贡献 0。
- avg@n= (1.0 + 0.0) / 2 = 0.5
- cons@k= (1 + 0) / 2 = 0.5
- 因此 cons@k = avg@n。

3.2 一般趋势

当模型预测高度一致（即多数问题有严格多数票正确）时，cons@k可能高于 avg@n，因为 cons@k只要求多数票正确，而 avg@n受错误预测拖累。
当模型预测分散（即多数问题无严格多数票）但正确率平均较高时，avg@n可能高于 cons@k，因为 avg@n奖励部分正确，而 cons@k要求多数票正确。
在理想情况下（所有预测正确或所有预测错误），两者相近。
在实际应用中（如强化学习场景下的多轮推理），cons@k通常用于评估稳定性，而 avg@n评估整体准确性。两者互补，没有固定大小关系。

4. 总结与建议

指标选择原则
- 优先pass@k评估模型潜力
- 用cons@k验证稳定性
- 用avg@n衡量整体性能
常见解读误区
- 仅关注pass@1：忽略模型多次尝试的潜力
- 忽视cons@k：可能导致生产环境不稳定
- 单独使用avg@n：无法区分一致性和容错性

指标应用与决策指导

以下阈值均为假设定义：高(>0.8), 中(0.5-0.8), 低(<0.5) 以下决策相关内容仅作参考

应用场景推荐

场景类型	核心指标	辅助指标	目标值
可靠性优先（医疗诊断、金融分析）	cons@k	pass@k	cons@k > 0.8, pass@k > 0.9
容错性优先（代码生成、探索任务）	pass@k	avg@n	pass@k > 0.8, avg@n > 0.7
平衡评估（通用AI助手）	avg@n	cons@k + pass@k	avg@n > 0.75

决策指导矩阵

指标组合	模型状态	改进方向
高pass@k, 中avg@n, 低cons@k	潜力大但稳定性差	增强一致性（温度惩罚、投票机制）
中pass@k, 中avg@n, 中cons@k	均衡但需提升	全面优化（数据增强、提示工程）
低pass@k, 低avg@n, 高cons@k	系统性偏差	检查数据/提示工程/模型偏差
低pass@k, 低avg@n, 低cons@k	几乎失效	重新训练或更换模型架构

通过综合使用这三个指标，可以较为全面评估大语言模型的性能特征，为模型优化和应用部署提供具有统计学意义的科学依据。

5. 注意事项

当前并非所有数据集配置文件采用的评估器(Evaluator)支持这三种指标的计算，当数据集配置文件中eval_cfg指定的Evaluator未实现返回计算所需的指标时，则结果显示回退到仅计算原始用于精度表示的指标。

注：以上精度测试结果说明资料来源:

模型性能测试

Mon, 01 Jan 0001 00:00:00 +0000

关于模型性能测试

模型性能测试定义

功能描述：模型性能测试旨在评估模型推理服务在真实部署环境中的运行效率（吞吐、延迟）
要求：模型推理服务需支持流式接口/v1/chat/completions方式访问

如何进行模型性能测试

遵循下文模型性能测试运行脚本的指导编写脚本。注意：只有模型适配仓库管理员并且仓库硬件类型为npu,才可以启动模型性能测试。
点击模型评测tab栏，进入模型评测页面。
在模型评测的页面，点击“性能测试”的tab，选择模型的权重文件，然后单击“立即测试”，发起性能测试。
等待性能测试用例执行完成。
(可选) 当模型处于“测试中”时，用户可以单击“终止测试”手动停止性能测试。
当性能评测执行完成后，在“性能测试”区域显示测试状态，并提供测试日志和评测报告下载。

模型性能测试运行脚本

模型性能测试脚本以deploy.sh为入口。脚本编写请严格遵照本文档的规范。

模型性能测试的适配仓库须包含以下两个文件:

requirements.txt：该脚本运行需配置的相应module ,如果没有需要安装的依赖，则无需创建 (非必须)。
deploy.sh: 模型评测服务基于该脚本安装依赖和启动此模型适配项目 (必须)。

文件位置

requirements.txt和deploy.sh必须位于仓库根目录下。

requirements.txt文件（可选）

transformers==4.37.0
accelerate==0.27.2

如果不需要添加任何依赖，该.txt文件可不提供，测试任务会跳过依赖安装。

deploy.sh文件

该文件是一个执行启动模型适配推理的shell脚本，该推理脚本运行方式无严格限制，以下为脚本规范。

执行安装依赖编写示例（可选）

python3 -m pip install --upgrade pip setuptools wheel

构造执行脚本所需要的入参

vllm serve "$MODEL_PATH" --trust-remote-code --tensor-parallel-size 1 --dtype float16 --max-num-seqs 4 --gpu-memory-utilization 0.95

适配代码编写要求

任务类型	任务编码	推理接口path
文本生成	text-generation	/v1/chat/completions
图片转文本	image-text-to-text	/v1/chat/completions
多模态	any-to-any	/v1/chat/completions

注：模型性能测试服务依赖请求/v1/chat/completions进行测试，如果不存在此推理接口，会导致精度评测任务失败。

模型权重文件大小限制

大小上限：100GB
限制说明：适配模型权重文件存储大小不得超出上限。
影响范围：若超出限制，将触发模型权重文件下载失败，直接导致模型评测任务失败。

全流程代码示例

deploy.sh

vllm适配验证示例：

#!/bin/sh
set -e
echo "=== MODEL_PATH set to: $MODEL_PATH ==="
vllm serve "$MODEL_PATH" --trust-remote-code --tensor-parallel-size 1 --dtype float16 --max-num-seqs 4 --gpu-memory-utilization 0.95

注：上面示例为vllm启动方式，无需设置–served-model-name，模型评测服务会自动使用模型权重的path作为serverd-model-name.

性能测试报告

性能评测执行成功以后，下载精度测试报告，解压缩以后，包含以下文件夹：configs、logs、performance，

最终生成的目录结构如下：

ee9480acbbac4d4aa190a124d5ddf39c/
├── configs # 自动存储的所有已转储配置文件
├── logs # 执行过程中日志，命令中如果加--debug，不会有过程日志落盘（都直接打印出来了）
│ └── performance/ # 推理阶段的日志文件
└── performance # 性能测评结果
│ └── vllm-api-stream-chat/ # “服务化模型配置”名称，对应模型任务配置文件中models的 abbr参数
│ ├── gsm8kdataset.csv # 单次请求性能输出（CSV），与性能结果打屏中的Performance Parameters表格一致
│ ├── gsm8kdataset.json # 端到端性能输出（JSON），与性能结果打屏中的Common Metric表格一致
│ ├── gsm8kdataset_details.json # 全量打点日志（JSON）
│ └── gsm8kdataset_plot.html # 请求并发可视化报告（HTML）

查看性能结果

性能结果打印在评测日志中的示例如下：

03/26 20:22:24 - AISBench - INFO - Performance Results of task: vllm-api-stream-chat/gsm8kdataset:

╒══════════════════════════╤═════════╤══════════════════╤══════════════════╤══════════════════╤══════════════════╤══════════════════╤══════════════════╤══════════════════╤══════╕
│ Performance Parameters │ Stage │ Average │ Min │ Max │ Median │ P75 │ P90 │ P99 │ N │
╞══════════════════════════╪═════════╪══════════════════╪══════════════════╪══════════════════╪══════════════════╪══════════════════╪══════════════════╪══════════════════╪══════╡
│ E2EL │ total │ 2048.2945 ms │ 1729.7498 ms │ 3450.96 ms │ 2491.8789 ms │ 2750.85 ms │ 3184.9186 ms │ 3424.4354 ms │ 8 │
├──────────────────────────┼─────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────┤
│ TTFT │ total │ 50.332 ms │ 50.6244 ms │ 52.0585 ms │ 50.3237 ms │ 50.5872 ms │ 50.7566 ms │ 50 .0551 ms │ 8 │
├──────────────────────────┼─────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────┤
│ TPOT │ total │ 10.6965 ms │ 10.061 ms │ 10.8805 ms │ 10.7495 ms │ 10.7818 ms │ 10.808 ms │ 10.8582 ms │ 8 │
├──────────────────────────┼─────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────┤
│ ITL │ total │ 10.6965 ms │ 7.3583 ms │ 13.7707 ms │ 10.7513 ms │ 10.8009 ms │ 10.8358 ms │ 10.9322 ms │ 8 │
├──────────────────────────┼─────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────┤
│ InputTokens │ total │ 1512.5 │ 1481.0 │ 1566.0 │ 1511.5 │ 1520.25 │ 1536.6 │ 1563.06 │ 8 │
├──────────────────────────┼─────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────┤
│ OutputTokens │ total │ 287.375 │ 200.0 │ 407.0 │ 280.0 │ 322.75 │ 374.8 │ 403.78 │ 8 │
├──────────────────────────┼─────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────────────────┼──────┤
│ OutputTokenThroughput │ total │ 115.9216 token/s │ 107.6555 token/s │ 116.5352 token/s │ 117.6448 token/s │ 118.2426 token/s │ 118.3765 token/s │ 118.6388 token/s │ 8 │
╘══════════════════════════╧═════════╧══════════════════╧══════════════════╧══════════════════╧══════════════════╧══════════════════╧══════════════════╧══════════════════╧══════╛
╒══════════════════════════╤═════════╤════════════════════╕
│ Common Metric │ Stage │ Value │
╞══════════════════════════╪═════════╪════════════════════╡
│ Benchmark Duration │ total │ 19897.8505 ms │
├──────────────────────────┼─────────┼────────────────────┤
│ Total Requests │ total │ 8 │
├──────────────────────────┼─────────┼────────────────────┤
│ Failed Requests │ total │ 0 │
├──────────────────────────┼─────────┼────────────────────┤
│ Success Requests │ total │ 8 │
├──────────────────────────┼─────────┼────────────────────┤
│ Concurrency │ total │ 0.9972 │
├──────────────────────────┼─────────┼────────────────────┤
│ Max Concurrency │ total │ 1 │
├──────────────────────────┼─────────┼────────────────────┤
│ Request Throughput │ total │ 0.4021 req/s │
├──────────────────────────┼─────────┼────────────────────┤
│ Total Input Tokens │ total │ 12100 │
├──────────────────────────┼─────────┼────────────────────┤
│ Prefill Token Throughput │ total │ 17014.3123 token/s │
├──────────────────────────┼─────────┼────────────────────┤
│ Total generated tokens │ total │ 2299 │
├──────────────────────────┼─────────┼────────────────────┤
│ Input Token Throughput │ total │ 608.7438 token/s │
├──────────────────────────┼─────────┼────────────────────┤
│ Output Token Throughput │ total │ 115.7835 token/s │
├──────────────────────────┼─────────┼────────────────────┤
│ Total Token Throughput │ total │ 723.5273 token/s │
╘══════════════════════════╧═════════╧════════════════════╛

03/26 20:22:24 - AISBench - INFO - Performance Result files locate in outputs/default/20250605_202220/performances/vllm-api-stream-chat.

性能测评结果说明

性能测评结果包括单个推理请求性能输出结果和端到端性能输出结果，参数说明如下：

单个推理请求性能输出结果

部分统计指标解释如下所示：

P75 / P90 / P99：以 TPOT 为例，表示所有请求的 TPOT 值分别处于第 75、90、99 百分位的性能表现。
E2EL（End-to-End Latency）：单个请求从发送到接收全部响应的总时延。
TTFT（Time To First Token）：首个 Token 返回的时延。
TPOT（Time Per Output Token）：输出阶段每个 Token 的平均生成时延（不含首个 Token）。
ITL（Inter-token Latency）：相邻 Token 间的平均间隔时延（不含首个 Token）。
InputTokens：请求的输入 Token 数量。
OutputTokens：请求生成的输出 Token 数量。
OutputTokenThroughput：输出 Token 的吞吐率（Token/s）。
Tokenizer：Tokenizer 编码耗时。
Detokenizer：Detokenizer 解码耗时。

Performance Parameters	Stage	Average	Max	Min	Median	P75	P90	P99	N
E2EL	统计此参数的阶段	平均请求时延	最大请求时延	最小请求时延	请求时延中位数	请求时延75分位值	请求时延90分位值	请求时延99分位值	测试数据量，来源于输入参数
TTFT	统计此参数的阶段	首个token平均时延	首个token最大时延	首个token最小时延	首个token中位数时延	首个token75分位时延	首个token90分位时延	首个token99分位时延	测试数据量，来源于输入参数
TPOT	统计此参数的阶段	Decode阶段平均时延	最大Decode阶段时延	最小Decode阶段时延	Decode阶段中位数时延	75分位Decode阶段时延	90分位每条请求Decode阶段平均时延	99分位Decode阶段时延	测试数据量，来源于输入参数
ITL	统计此参数的阶段	token间平均时延	token间最大时延	token间最小时延	token间中位数时延	token间75分位时延	token间90分位时延	token间99分位时延	测试数据量，来源于输入参数
InputTokens	统计此参数的阶段	输入token平均长度	最大输入token长度	最小输入token长度	输入token中位数长度	75分位输入token长度	90分位输入token长度	99分位输入token长度	测试数据量，来源于输入参数
OutputTokens	统计此参数的阶段	输出token平均长度	最大输出token长度	最小输出token长度	输出token中位数长度	75分位输出token长度	90分位输出token长度	99分位输出token长度	测试数据量，来源于输入参数
OutputTokenThroughput	统计此参数的阶段	平均输出吞吐	最大输出吞吐	最小输出吞吐	中位数输出吞吐	输出吞吐75分位	输出吞吐90分位	输出吞吐99分位	测试数据量，来源于输入参数

端到端性能输出结果

参数	说明
Benchmark Duration	测试任务的总执行时间
Total Requests	请求总数量
Failed Requests	请求失败数量（包含无响应或响应为空）
Success Requests	成功返回的请求数量（包括空响应与非空响应）
Concurrency	实际平均并发数
Max Concurrency	配置的最大并发数
Request Throughput	请求级吞吐率（请求数/秒）
Total Input Tokens	所有请求的总输入 Token 数
Prefill Token Throughput	Prefill 阶段的 Token 吞吐率
Total Output Tokens	所有请求生成的总输出 Token 数
Input Token Throughput	输入 Token 吞吐率
Output Token Throughput	输出 Token 吞吐率
Total Token Throughput	总 Token 吞吐率（输入 + 输出）

性能测试可视化并发图使用说明

该并发图用于展示性能测评过程中的详细推理耗时，包括：

请求力度耗时展示：每条请求的详细处理耗时，包含Prefill 阶段耗时、Decode 阶段耗时以及请求完整耗时
实时并发数展示：反映测试过程中的并发变化趋势，帮助判断请求调度与系统吞吐能力。

核心功能

精细化耗时分析：可对每条请求的处理过程进行拆解，识别性能瓶颈是否集中在 prefill 或 decode 阶段。
并发动态可视化：展示整个测试期间的并发水平波动，辅助评估系统在高并发压力下的稳定性与响应效率。
支持大规模请求回放：适用于高压测试，分析模型或服务在持续负载下的表现。

使用场景

性能调优：识别瓶颈点，为模型推理服务的延迟优化、并发控制、批量处理策略调整提供数据支持。
推理服务压测验证：对部署后的服务进行压力测试，确保在目标并发场景下性能达标。
部署方案评估：对比不同模型、不同部署方式（如本地 vs 服务化）在相同负载下的响应表现。

数据生成方式：性能测试将自动生成一份 HTML 可视化报告。使用任意主流浏览器打开该文件，即可交互式查看每条请求的详细耗时信息和全程并发曲线。

性能报告文件查看

1. 视图控制

鼠标滑动至图的右上角可显示导航栏

导航栏说明

从左到右按顺序

名称	符号	作用
Download	照相机	将当前视图截屏并保存为`png`格式
Zoom	放大镜	开启Zoom模式，详见下表 `鼠标操作说明` 中的 `鼠标拖拽画布` 行
Pan	正十字	开启Pan模式，详见下表 `鼠标操作说明` 中的 `鼠标拖拽画布` 行
Zoom in	加号	以当前视图为中心，等比例同时放大上下两张图
Zoom out	减号	以当前视图为中心，等比例同时缩小上下两张图
Autoscale	斜十字 + 四角外框	根据数据规模，重置全图
Reset axes	房屋	根据初始设置，重置全图

2. 数据查看

参考样例
- 全图总览
- 请求线段图
  - 带Decode阶段图例
  - 不带Decode阶段图例
- 并发阶梯图
图例说明与计算
- 请求线段图
  - 每条水平线段：由红、蓝两部分，或只由红色部分组成，表示一条请求的E2EL
  - 红色线段：TTFT，即首Token时延
  - 蓝色线段：Decode, 即非首Token时延
  - 值的计算
    - TTFT = prefill_latency
    - Decode = end_time - (start_time + prefill_latency)
    - End-to-End Latency(E2EL) = end_time - start_time
- 并发阶梯图
  - 绿色线段：表示随着时间变化而变化的实时请求并发数
  - 值的计算：截取当前时间点的请求数量
悬停文本框
- 请求线段图：光标悬停在每条请求线段最开始的数据点附近，显示：首Token时延(TTFT)、非首Token时延(Decode)、该请求总时长(E2EL)
- 并发阶梯图：光标悬停在新事件的转折拐角点，显示：时间戳（Time）、并发数（Concurrency）
坐标轴说明
- 请求线段图：
  - 横坐标：相对时间线，起始点：0，单位：s
  - 纵坐标：请求索引，起始点：1
- 并发阶梯图：
  - 横坐标：相对时间线，起始点：0，单位：s
  - 纵坐标：请求并发个数，起始点：1

注：以上性能测试结果说明资料来源: