wordpress客户端linux,班级优化大师app下载学生版,风景网页制作模板,html网站标签一、MindSpore Serving
MindSpore Serving是一款轻量级、高性能的服务工具#xff0c;帮助用户在生产环境中高效部署在线推理服务。
使用MindSpore完成模型训练导出MindSpore模型#xff0c;即可使用MindSpore Serving创建该模型的推理服务。
MindSpore Serving包含以…一、MindSpore Serving
MindSpore Serving是一款轻量级、高性能的服务工具帮助用户在生产环境中高效部署在线推理服务。
使用MindSpore完成模型训练导出MindSpore模型即可使用MindSpore Serving创建该模型的推理服务。
MindSpore Serving包含以下功能 支持自定义关于模型的预处理和后处理简化模型的发布和部署。 支持batch功能包含多个实例的请求会被拆分组合以满足模型batch size的需要。 支持分布式模型推理功能。 支持客户端gRPC接口提供简单易用的客户端Python封装接口。 支持客户端RESTful接口。
部署Serving推理服务
serving_server.py为启动服务脚本文件。xxx.mindir为上一步网络生成的模型文件。servable_config.py为模型配置文件定义了模型的处理函数。
启动服务
执行serving_server.py完成服务启动
import os
import sys
from mindspore_serving import serverdef start():servable_dir os.path.dirname(os.path.realpath(sys.argv[0]))servable_config server.ServableStartConfig(servable_directoryservable_dir, servable_nameadd,device_ids(0, 1))server.start_servables(servable_configsservable_config)server.start_grpc_server(address127.0.0.1:5500)server.start_restful_server(address127.0.0.1:1500)if __name__ __main__:start()启动脚本中start_servables将在设备0和1上共加载和运行两个推理副本来自客户端的推理请求将被切割分流到两个推理副本。
当服务端打印如下日志时表示Serving gRPC服务和RESTful服务启动成功。 Serving gRPC server start success, listening on 127.0.0.1:5500 Serving RESTful server start success, listening on 127.0.0.1:1500 执行推理
客户端提供两种方式访问推理服务一种是通过gRPC方式一种是通过RESTful方式。 使用serving_client.py启动Python客户端。 ———————————————————————————————————————— RESTful是一种基于HTTP协议的网络应用程序的设计风格和开发方式通过URI实现对资源的管理及访问具有扩展性强、结构清晰的特点。基于其轻量级以及通过HTTP直接传输数据的特性RESTful已经成为最常见的Web服务访问方式。用户通过RESTful方式能够简单直接的与服务进行交互。
通过mindspore_serving.server.start_restful_server接口启动RESTful服务
请求方式 当前仅支持POST类型的RESTful请求请求格式如下
POST http://HOST:1234/model/LLaMA:generated_stream如果使用curl工具RESTful请求方式如下
curl -X POST -d {instances:{image:{b64:babe64-encoded-string}}} http://HOST:1234/model/LLaMA:generated_stream二、TGI框架 若干客户端同时请求Web Server的“/generate”服务后服务端将这些请求在“Buffer”组件处整合为Batch并通过gRPC协议转发请求给NPU推理引擎进行计算生成。
将请求发给多个Model Shard多个Model Shard之间通过NCCL通信 是因为显存容量有限或出于计算效率考虑需要多卡进行分布式推理。
推理框架一般会将第1次推理(首Token)和余下的推理生成其余Token分别设计为Prefill和Decode两个过程 Prefill 是将1个请求的Prompt一次性转换为KV Cache,并生成第1个Token的过程。 假设Prompt的长度为LMultiHead Attention的头数为HHead每个头的维度为HSHead Size暂不考虑GQA/MQA。 计算该过程时输入Attention的Q、K、V维度均为[L,H, HS],输入FFN的hidden隐藏层向量维度为[L, H *HS]。 完成模型计算后仅对最后一个Logit进行解码得到首Token中间过程计算得到的K、V被保留在显存中即KV Cache用于避免后续Decode过程重复计算这些K、V导致算力浪费。 Decode从第2个Token开始将上一次推理的输出新生成的1个Token作为输入进行一次新的推理。假设BatchSize1已生成的新子序列长度为N在计算该过程时输入Attention的Q维度为[1,H, HS], K、V维度则为[LN1,H, HS]输入FFN的hidden维度为[1, H*HS]。 完成模型计算后对唯一的Logit进行解码得到新生成的Token中间过程计算得到的K、V追加到KV Cache中原因同上。重复Decode流程持续生成Token直到模型输出(End of Sentence,表示输出结束的特殊Token)。
将推理分为Prefill和Decode是考虑到生成第1个Token和其余Token时计算模式的差异较大分开实现有利于针对性优化。
TGI引入Continuous Batching特性其中请求的合并和剔除就是通过Router向Server发送Concatenate和Filter的Request实现。
Continuous Batching或称Inflight Batch核心思想是在两次Decode的间隙插入新请求的Prefill、各请求的合并和剔除等操作从而以动态Batch推理的方法提高NPU利用率。
