网站建设与管理专业好不好就业网页编辑软件edit

当前位置： 首页 > news >正文

网站建设与管理专业好不好就业,网页编辑软件edit,seo优化专员招聘,合肥哪家公司做网站在此前的大模型技术实践中#xff0c;我们介绍了加速并行框架Accelerate、DeepSpeed及Megatron-LM。得益于这些框架的助力#xff0c;大模型的分布式训练得以化繁为简。 然而#xff0c;企业又该如何将训练完成的模型实际应用部署#xff0c;持续优化服务吞吐性能#xf…在此前的大模型技术实践中我们介绍了加速并行框架Accelerate、DeepSpeed及Megatron-LM。得益于这些框架的助力大模型的分布式训练得以化繁为简。 然而企业又该如何将训练完成的模型实际应用部署持续优化服务吞吐性能我们不仅要考量模型底层的推理效率还需从请求处理的调度策略上着手确保每一环节都能发挥出最佳效能。 本期内容优刻得将为大家带来vLLM[1]一款高性能推理服务框架的相关内容。vLLM于近期推出了0.6.0版本[2]。那么相比旧版本推出了什么新功能又做了哪些优化呢 优刻得模型服务平台UModelVerse现已同步上线vLLM0.6.0。仅需几步即刻畅享新版vLLM带来的极速推理体验。文末为您带来详细的使用教程。 01 API服务端-推理引擎进程分离 推理服务框架需要考虑服务部署的两个要素面向客户请求的服务端以及背后的模型推理端。在vLLM中分别由API服务端 (API Server)和模型推理引擎 (vLLM Engine)执行相应任务。 1.1 进程共用 vs. 进程分离 根据旧版vLLM设计负责处理请求的API服务端与负责模型推理的推理引擎共用同一个python进程 0.6.0版本将API服务端和推理引擎分离分别由两个python进程运行。进程之间的信息交互由ZeroMQ socket进行传输 [3]。 上API服务端与推理引擎共用同一个python进程 下API服务端与推理引擎各自独用python进程。 API服务端需要承担一系列处理HTTP请求等任务。通过对旧版本的性能分析vLLM团队发现API服务端消耗大量CPU资源。 举个例子在推理引擎端轻负载下使用Llama3 8B模型推理生成1个token的耗时约为13ms而相对应地API服务端需要能够每秒处理76个token才能跟上推理引擎的速度。由于python GIL的存在推理引擎还会与服务端争抢CPU资源。CPU端负载巨大无法及时处理计算则会使得GPU端因等待CPU而产生空闲无法充分利用性能[3]。 在0.6.0版本中将API服务端与推理引擎端分离为两个进程后两个进程可以各自专注于份内职责而不会受GIL的影响。而在分离后团队后续可以更好地对两端分别进行更细致的性能优化和打磨。 1.2 TTFT、TPOT和ITL 在进入测试对比前先了解一下衡量语言模型服务推理效率通常参照的三个指标即 首个token响应时长 (Time to first token, TTFT 每个token输出时长 (Time per output token, TPOT) 跨token延迟 (Inter-token latency, ITL) TTFT顾名思义就是从客户端发出请求后开始计时直到服务端返回第一个输出token的耗时。过程中由服务端收到请求后着手处理交由调度器准备推理。推理引擎需要完成prefill任务。基于prefill得到的kv值decode得到第一个输出token后返回。 而TPOT和ITL概念相对接近表达的都是后续一连串decode的耗时。根据vLLM测试代码 [4]我们定义如下 TPOT是在一个请求从发出后不纳入TTFT的耗时 (主要是为了排除prefill耗时)到所有token全部decode完成并返回的整体耗时除以一共返回的token数量即每个token输出的平均时长 而ITL是在计算每次请求返回部分token时所需的时长即服务端每次decode后返回一个或一批token所需的时长。 举个例子如果每次服务端返回1个token则ITL耗时应与TPOT接近而当每次服务端返回5个token则ITL耗时应接近于5倍的TPOT耗时 (因为ITL计算单次的时长而TPOT计算单token的时长)。 1.3 测试对比 在优刻得云主机上开展对比测试。 利用vLLM官方提供的benchmark_serving基准测试我们可以模拟真实的客户端请求从而对比vLLM 0.6.0与旧版vLLM (0.5.5)在进程分离上的优化导致的性能差异。关闭其他优化方法后在保持其他参数不变的情况下在opt-125m模型上开展测试。 在服务端我们分别在0.6.0和旧版本上使用以下的参数 #vLLM 0.5.5共用进程     vllm serve facebook/opt-125m \     –max-model-len 2048 \     –use-v2-block-manager     #vLLM 0.6.0分离进程     vllm serve facebook/opt-125m \     –max-model-len 2048 \     –use-v2-block-manager \     –disable-async-output-proc #关闭0.6.0的新优化方法异步输出处理。下文有详解 而在客户端我们统一采用以下脚本。我们模拟100个请求同时发出请求数据随机取自ShareGPT v3数据集。 python vllm/benchmarks/benchmark_serving.py \     –backend vllm \     –model facebook/opt-125m \     –tokenizer facebook/opt-125m \     –request-rate inf \ #所有请求无间隔同时发送     –num-prompts 100 \ #共100条请求发出     –dataset-name sharegpt \     –dataset-path dataset/ShareGPT_V3_unfiltered_cleaned_split.json \     –sharegpt-output-len 1024 \     –seed 42 #固定种子控制变量 经过测试结果如下 (左旧版本0.5.5右新版本0.6.0) 进程分离以牺牲TTFT指标为代价 (笔者推测进程间ZeroMQ通信带来开销)测试整体时长(Benchmark duration)比进程共用快近14秒提速约40%。该模型参数量较小GPU压力较小瓶颈主要在于CPU。进程分离消除了CPU争抢造成的开销。 02 多步调度Multi-step scheduling 在请求调度层面vLLM 0.6.0的更新中引入了多步调度 (Multi-step scheduling)的方法 [2]使得请求处理的调度更高效。为了更好地理解多步调度的意义我们简单了解一下vLLM调度器。 2.1 调度器 (Scheduler) vLLM推理引擎LLMEngine中存在调度器 (Scheduler)的概念。调度器控制来自服务端的输入请求会以什么顺序送入模型执行推理。 对于一个输入请求我们需要首先对输入的句子执行prefill计算并基于prefill得到的kv值开展decode计算即预测下一个token。而调度器的职责就是以合理的调度策略安排模型执行prefill或是decode的顺序 (篇幅限制具体调度细节这里不展开)。 2.2 单步调度 vs. 多步调度 在旧版vLLM中每次调度器只会为下一次的模型推理安排优先顺序即每次调度对应一次模型推理。该方法被称为单步推理 0.6.0引入多步推理每次调度器调度会安排接下来的多次模型推理即每次调度对应n次推理。多步推理可以减少调度次数降低CPU开销从而让模型推理充分利用GPU资源尽量保持运行。 上一次调度后执行1步推理 下一次调度后执行3步推理。 据vLLM团队测试4张H100环境下运行Llama 70B多步推理的吞吐量比单步推理提升了28%[3]。 2.3 测试对比 利用上述基准测试对比单步调度与多步调度的性能差异。这次我们统一使用0.6.0版本。在保持其他设置相同的情况下设置服务端启动参数分别如下。而客户端方面设置与上文相同在此不再赘述。 #单步/多步调度     vllm serve facebook/opt-125m \     –max-model-len 2048 \     –use-v2-block-manager \     –disable-async-output-proc \ #关闭异步输出处理     –num-scheduler-steps ¹⁄₁₀ #每次调度1步/10步 以下为测试结果 (左单步调度右多步调度step10) 多步调度(step10)的情况下基准测试仅耗时7.69秒而单步调度耗时21.68秒整体速度上快近3倍。由于opt-125m模型的参数量较小计算瓶颈主要位于CPU端因此对CPU端的优化效果极其显著对于更大规模的模型瓶颈位于GPU端加速效果相对没有这么明显。 使用NVIDIA Nsight systems [5]进一步分析profile (NVTX中绿色块表明执行调度)。多步调度中每个绿色块之间有10组CPU epoll_pwait和read即执行10次GPU上的模型推理并读取结果而单步推理中每个绿色块之间仅有1组epoll_pwait和read即1次模型推理。 多步调度(step10) 单步调度(step1) 细心的同学可能发现了上述测试中尽管多步调度的整体耗时降低了很多但是ITL远大于单步调度。这是因为多步调度(step10)将10步推理整合到了一起。 因此ITL(69.87秒)正好约为10倍TPOT(7.41秒)。增加一场多步调度(step5)的测试进行验证可以看到ITL约为41.76秒约5倍于TPOT的8.79秒。 多步调度(step5) 03 异步输出处理ASync output processing 在旧版vLLM中GPU端模型推理输出token后必须在CPU端对输出token进行处理并判断是否符合停止条件 (stopping criteria从而决定是否继续推理这个操作会产生时间开销 新版vLLM引入了异步输出处理使得模型推理和输出处理异步进行从而重叠计算的时间[3]。 3.1 异步输出处理 在异步输出处理中我们把模型输出从GPU端取到CPU端进行停止条件判定时并不会让模型停止推理等待判定结果从而导致空闲。在CPU端对第n个输出进行处理并判定是否停止的同时我们在GPU端假设第n个输出尚不符合停止条件并继续推理预测第n1个输出。 这样的设计可能会使得每条请求都多了一次推理造成些许耗时但与GPU空闲等待所浪费的时间相比就显得很划算了。  上不启用异步输出处理下启用异步输出处理。 据vLLM团队测试4张H100环境下运行Llama 70B异步输出处理的TPOT指标比禁用快了8.7%[3]。 3.2 测试对比 我们对比启用和禁用异步输出处理的性能差异。在保持其他设置相同的情况下设置服务端启动参数分别如下。vLLM 0.6.0中默认启用该功能可以通过设置参数–disable-async-output-proc来手动关闭。 #禁用/启用异步输出处理 vllm serve facebook/opt-125m \     –max-model-len 2048 \     –use-v2-block-manager \     –disable-async-output-proc #移除该参数则默认启用 以下为测试结果 (左禁用异步输出处理右启用异步输出处理) 异步输出处理可以获得一些细微的性能提升主要体现在TPOT和ITL上约5%左右基本符合预期。 04 在优刻得UModelVerse体验新版vLLM 4.1 创建并启动服务 打开UCloud控制台 (https://console.ucloud.cn/)登录账号。点击左上角的“全部产品”从中找到“模型服务平台 UModelVerse”。 点击进入后点击左侧栏目中的“服务部署”并点击“创建服务”。 进入界面后设置想要使用的模型并添加服务名称后在右侧选择合适的支付方式并点击“立即购买”系统自动跳转到支付页面。 完成支付后页面回到“服务部署”。可以看到我们购买的服务正处于“部署中”的状态稍作等待…… 待状态转为“已上线”后即可点击“访问”打开网页图形界面或通过API调用。 4.2 使用服务 4.2.1 通过网页图形界面 点击“访问”即可进入与chatbot的图形对话页面 4.2.2 通过API接口 当然我们也可以通过API接口进行对话。以下是调用代码样例。调用的API参数可以在服务列表中找到。其中 • API_KEY即API Key • BASE_URL为API地址 • MODEL为模型的名称 Python from openai import OpenAI API_KEY aDZ39J204akIPPhmqQtLuf64CBA7ZbyQ0Ov88VzlPuBRjdvP # API Key BASE_URL https://ai.modelverse.cn/uminfer-14e3pxj9lnfc/v1 # 模型URL MODEL meta-llama/Meta-Llama-3.1-8B-Instruct # 模型名 client OpenAI(     api_keyAPI_KEY,     base_urlBASE_URL ) # 调用模型生成文本 response client.chat.completions.create(     modelMODEL,  # 选择模型     temperature0.5, # 温度模型输出结果的随机性     max_tokens512, # 最大tokens长度     messages[         {role: user, content: 你好呀可以给我讲个笑话嘛},     ] ) # 获取并打印 AI 生成的回复 print(response.choices[0].message.content) 【相关资料】 [1] vLLM: https://github.com/vllm-project/vllm [2] vLLM Highlights: https://github.com/vllm-project/vllm/releases/v0.6.0 [3] vLLM v0.6.0: 2.7x Throughput Improvement and 5x Latency Reduction: https://blog.vllm.ai/2024/09/05/perf-update.html [4] vLLM benchmark source code: https://github.com/vllm-project/vllm/blob/b67feb12749ef8c01ef77142c3cd534bb3d87eda/benchmarks/backend_request_func.py#L283 [5] NVIDIA Nsight Systems: https://developer.nvidia.com/nsight-systems