威海市做网站的wordpress 页面压缩

威海市做网站的,wordpress 页面压缩,潍坊大宇网络网站建设,广州建网站点击下方“AINLPer“#xff0c;添加关注 更多干货#xff0c;第一时间送达 引言 随着生成式AI和大型语言模型#xff08;LLM#xff09;的应用的普及。企业纷纷部署基于LLM的应用#xff0c;如何评估不同AI服务应用的效率是一项特别重要的需求。「LLM应用部署的成本取决于…点击下方“AINLPer“添加关注更多干货第一时间送达引言随着生成式AI和大型语言模型LLM的应用的普及。企业纷纷部署基于LLM的应用如何评估不同AI服务应用的效率是一项特别重要的需求。「LLM应用部署的成本取决于其每秒能处理的请求量同时还需满足终端用户的响应速度并保证回答的准确性」。本文将详细介绍LLM应用成本评估核心指标吞吐量和响应延迟旨在澄清常见指标解析不同流行测试工具对这些指标的定义与测量差异并讨论基准测试的关键参数。本文目录安排如下1. 负载测试与性能基准测试负载测试与性能基准测试是评估LLM部署的两种不同方法。负载测试通过模拟高并发请求来检验模型处理大流量的能力重点关注服务器容量、自动扩展策略、网络延迟和资源利用率等问题。而性能基准测试专注于测量模型本身的性能如吞吐量、延迟和词元级指标用于识别模型效率、优化和配置相关问题。总的来说「负载测试是确保模型能应对高流量而性能基准测试则关注请求处理效率」。结合两者可全面评估LLM部署能力并定位改进方向。2. LLM推理基本原理这里在介绍基准测试指标之前首先带大家回顾一下LLM推理的工作原理及相关术语。生产实际应用的时候LLM推理生成通常会经历以下几个阶段「提示Prompt」用户提交查询「排队Queuing」查询进入处理队列「预填充Prefill」模型处理提示prompt「生成Generation」模型逐词元Token输出响应「词元」Token又称标记是自然语言模型当然包括大模型特有的概念它是模型处理自然语言的最小语言单位所有词元的集合称为词表。每个LLM有自己的分词器用于高效表示输入文本。粗略估算多数主流LLM中1个Token≈0.75个英文单词对于汉字来说1个Token≈1.8个汉字这个具体也因模型而异。「序列长度」数列的长度。输入序列长度ISL是模型接收的Token数包含用户请求、系统提示如模型指令、历史对话记录、思维链CoT推理及检索增强生成RAG的文档。输出序列长度OSL是模型生成的Token数。上下文长度是模型每一步生成时使用的总Token数含输入和已生成的输出每个LLM有最大上下文长度限制。「流式传输」Streaming允许将部分输出以增量词元块形式实时返回用户这对需要快速初始响应的聊天应用尤为重要。非流式模式下则一次性返回完整结果。3. LLM推理指标本节解释行业常用指标包括比如“首 Token 时间”Time to First Token简称 TTFT和“Token 间延迟”Intertoken Latency简称 ITL。虽然这些指标听起来挺直观但不同测试工具在定义和测量方式上其实有一些细微但重要的差别。3.1 首Token时间TTFT首个Token时间TTFT指从提交提示到生成第一个Token所需的时间即用户等待模型首次输出的时长。具体如下图所示TTFT通常包含请求排队时间、预填充时间和网络延迟。提示越长TTFT越大因为注意力机制需计算整个输入序列以创建键值缓存KV Cache此后迭代生成循环才开始。此外生产环境中多个请求可能同时处理导致某一请求的预填充阶段与其他请求的生成阶段重叠。需要注意的是不同的基准测试工具比如 GenAI-Perf 和 LLMPerf在测 TTFT 时通常会「忽略那些“无内容”的初始响应」比如返回了空字符串或者没有生成任何 Token 的情况。这是因为如果第一条返回的内容是空的TTFT这个指标就没什么参考价值了。3.2 端到端请求延迟e2e_latency端到端请求延迟e2e_latency指从提交请求到接收完整响应的总时间含排队、批处理和网络延迟如下图所示。流式模式下由于分次返回结果解词元步骤可能多次执行。对于单个请求来说端到端延迟就是从「请求发出」到「最后一个 Token 返回」的时间差。即需要注意的是生成阶段的持续时间generation_time是从收到第一个 Token 到最后一个 Token 的时间跨度。同时一些测试工具比如 GenAI-Perf会过滤掉最后的完成信号或者空白响应不把这些算进 e2e_latency 里。3.3 Token 间延迟ITLToken间延迟ITL是序列中连续词元生成的平均间隔时间也称每Token时间Time Per Output TokenTPOT。尽管定义看似简单不同工具在指标收集方式上存在差异。例如GenAI-Perf不将TTFT纳入平均值计算而LLMPerf则包含。GenAI-Perf通过以下公式定义ITL即平均 Token 时间 (收到最后一个 Token 的时间 - 收到第一个 Token 的时间) / (总 Token 数 - 1)这里减 1是为了把首 Token 排除掉让 ITL 更准确地反映真正的解码Decoding阶段性能。另外随着输出 Token 数量增加KV Cache 也会逐渐变大。每生成一个新 Token注意力机制的计算量也线性增长。不过通常这个阶段不会是计算瓶颈。如果 ITL 保持稳定说明内存管理和带宽利用都做得不错Attention 机制也处理得高效。3.4 每秒生成 Token 数TPS「TPSTokens Per Second」是系统整体每秒生成多少个 Token 的量。一开始随着并发请求数增加系统的 TPS 也会跟着增加直到 GPU 资源被用满TPS 就会趋于饱和甚至可能开始下降。比如在一次完整的基准测试中可以这么理解时间轴上的事件以上图为例假设基准测试总时间线包含n个请求事件定义如下「Li」第i个请求的端到端延迟「T_start」测试开始时间「Tx」首个请求发送时间戳「Ty」末个请求的最后响应时间戳「T_end」测试结束时间GenAI-Perf 将 TPS 定义为总生成 Token 数除以第一个请求和最后一个请求的最后一个响应之间的端到端延迟时间LLMPerf 将 TPS 定义为总生成 Token 数除以整个基准测试持续时间因此LLMPerf的指标还包含以下开销输入提示生成请求准备响应存储根据我们的观察在单并发single concurrency场景下这些开销有时候可以占到整个基准测试持续时间的 33% 左右。需要注意的是TPS 的计算是批量batch完成的不是实时live动态变化的指标。另外GenAI-Perf 使用了滑动窗口技术sliding window technique来寻找稳定的测量区间。这意味着最终统计的结果是基于一部分已经完成的代表性请求子集得出的也就是说在计算时会排除掉刚开始预热warming up和最后收尾阶段cooling down的请求。每个用户的 TPSTPS per user表示从单个用户角度测量的吞吐量定义为这个定义适用于单个用户的每次请求。当输出序列长度不断增加时TPS per user 的值会逐渐趋近于 1/ITL即每个 Token 的平均生成时间的倒数。需要注意的是随着系统中并发请求数的增加系统整体的总 TPS 会增加但单个用户的 TPSTPS per user会随着延迟增加而下降3.5 每秒请求数RPS每秒请求数RPS表示系统1秒内成功完成的平均请求数计算公式为虽然 RPS 这个指标比 TPS 粗一些但也很重要尤其是对应用服务器层面的性能评估来说。4. 基准测试与最佳实践本节介绍确保测试有效性的关键参数及其取值范围。合理的测试设置才能保证测试结果既靠谱又能真正反映系统性能。4.1 用场景对 LLM 性能的影响不同的应用场景对输入ISL和输出OSLToken 数量的要求是完全不一样的。而这些 Token 数的变化直接影响系统消化输入、构建 KV 缓存、生成输出的速度。一般来说输入序列越长预填阶段Prefill需要的显存就越多首 Token 时间TTFT就越高输出序列越长生成阶段Generation对显存带宽和容量的要求也越高Token 间延迟ITL就越大。所以「在部署 LLM 时一定要搞清楚自己应用场景里输入和输出的长度分布情况。这样才能更好地规划硬件资源做到最优利用」。常见应用场景和它们的 ISL / OSL 特征举例「翻译」包括语言翻译和代码翻译。特点是输入输出长度差不多都在 5002000 个 Token 左右。「内容生成」比如生成代码、故事、邮件正文或者通过检索生成一般性内容。特点是输出很长大概 1000 Token 量级而输入通常很短大概 100 Token 量级。「摘要总结」包括检索、链式思考提示CoT prompting、多轮对话等场景。特点是输入很长大约 1000 Token 以上输出很短大约 100 Token。「推理」Reasoning最近的新型推理模型比如做复杂推理、代码生成、数学题、逻辑谜题时经常需要非常详细的链式思考、反思验证等。特点是输入短大概 100 Token但输出超级长1000 到 10000 Token 级别。4.2 负载控制参数Load Control Parameters这里讲一些专门用来“施加负载”的参数。「并发数」Concurrency N同时活跃的请求数也可以理解为有多少个用户在同时发请求。每当一个用户的请求完成就立刻发起下一个请求保证系统里随时有 N 个活跃请求。通常描述 LLM 推理负载最常用的就是并发数。「最大批处理大小」Max Batch Size指推理引擎一次能同时处理的最多请求数。这可能是并发请求的一个子集。如果并发数超过了最大批处理大小 × 活跃副本数多余的请求就得排队等待后面有空位再处理。这种情况下TTFT首 Token 时间也会因为排队而变长。「请求速率」Request Rate控制新请求发送频率的另一种方式。「恒定速率」Constant Rate每 1/r 秒发 1 个请求「泊松分布速率」Poisson Rate请求之间的间隔时间是随机的但平均速率固定不同测试工具支持的负载控制方式也不太一样有的更倾向用并发数有的支持两种。一般建议优先用并发控制因为如果只控制发送速率而系统处理不过来未完成请求数可能会无限堆积。小tip在设定测试参数时可以从并发数 1 开始逐步增加到略高于最大批处理大小的范围。因为通常在并发数接近最大批处理时系统吞吐量会达到饱和而延迟会继续上升。4.3 其他重要参数除了负载相关的还有一些其他设置也会影响推理性能或者影响测试准确性「是否忽略 EOSignore_eos 参数」大多数 LLM 都有一个特别的“结束符”EOS Token表示生成结束。正常推理时模型遇到 EOS 就会停止生成。但在性能测试时为了测到指定长度、保证每次输出长度一致通常会设置忽略 EOS让模型继续生成直到达到最大 Token 数。「采样策略」Sampling Parameters不同的采样策略比如Greedy每次选得分最高的 Token、Top-p按累积概率筛选、Top-k按最高 k 个概率选、Temperature调整随机性都会影响生成速度。比如 Greedy 策略最快因为不用排序、归一化概率分布直接拿最高分的 Token 就行了。做基准测试时「不管选哪个采样方法都要在整个测试过程中保持一致避免引入额外干扰」。AI-Agent文章推荐[1]Gartner预测2028年Agent应用将融入1/3的企业软件」[2]大模型Agent | 构建AI-Agent的 5大挑战及解决方案[3]盘点一下大模型Agent“花式玩法”[4]大模型Agent的USB接口--MCP[5]2025年的风口| 万字长文纵观大模型Agent[6]万字长文从AI Agent到Agent工作流一文详细了解代理工作流(Agentic Workflows)更多精彩内容--专注大模型/AIGC、Agent、RAG等学术前沿分享欢迎投稿或寻求报道联系ainlperbot「资料整理不易点个在看、赞吧」