基础作业:
- 使用 LMDeploy 以本地对话、网页Gradio、API服务中的一种方式部署 InternLM-Chat-7B 模型,生成 300 字的小故事(需截图)
2 服务部署
这一部分主要涉及本地推理和部署。我们先看一张图。
我们把从架构上把整个服务流程分成下面几个模块。
- 模型推理/服务。主要提供模型本身的推理,一般来说可以和具体业务解耦,专注模型推理本身性能的优化。可以以模块、API等多种方式提供。
- Client。可以理解为前端,与用户交互的地方。
- API Server。一般作为前端的后端,提供与产品和服务相关的数据和功能支持。
值得说明的是,以上的划分是一个相对完整的模型,但在实际中这并不是绝对的。比如可以把“模型推理”和“API Server”合并,有的甚至是三个流程打包在一起提供服务。
接下来,我们看一下lmdeploy提供的部署功能。
2.1 模型转换
使用 TurboMind 推理模型需要先将模型转化为 TurboMind 的格式,目前支持在线转换和离线转换两种形式。在线转换可以直接加载 Huggingface 模型,离线转换需需要先保存模型再加载。
TurboMind 是一款关于 LLM 推理的高效推理引擎,基于英伟达的 FasterTransformer 研发而成。它的主要功能包括:LLaMa 结构模型的支持,persistent batch 推理模式和可扩展的 KV 缓存管理器。
2.1.1 在线转换
lmdeploy 支持直接读取 Huggingface 模型权重,目前共支持三种类型:
- 在 huggingface.co 上面通过 lmdeploy 量化的模型,如 llama2-70b-4bit, internlm-chat-20b-4bit
- huggingface.co 上面其他 LM 模型,如 Qwen/Qwen-7B-Chat
示例如下:
# 需要能访问 Huggingface 的网络环境
我们也可以直接启动本地的 Huggingface 模型,如下所示。
lmdeploy chat turbomind /share/temp/model_repos/internlm-chat-7b/ --model-name internlm-chat-7b
以上命令都会启动一个本地对话界面,通过 Bash 可以与 LLM 进行对话。
2.1.2 离线转换
离线转换需要在启动服务之前,将模型转为 lmdeploy TurboMind 的格式,如下所示。
# 转换模型(FastTransformer格式) TurboMind lmdeploy convert internlm-chat-7b /path/to/internlm-chat-7b
这里我们使用官方提供的模型文件,就在用户根目录执行,如下所示。
lmdeploy convert internlm-chat-7b /root/share/temp/model_repos/internlm-chat-7b/
执行完成后将会在当前目录生成一个 workspace
的文件夹。这里面包含的就是 TurboMind 和 Triton “模型推理”需要到的文件。
目录如下图所示。
weights
和 tokenizer
目录分别放的是拆分后的参数和 Tokenizer。如果我们进一步查看 weights
的目录,就会发现参数是按层和模块拆开的,如下图所示。
每一份参数第一个 0 表示“层”的索引,后面的那个0表示 Tensor 并行的索引,因为我们只有一张卡,所以被拆分成 1 份。如果有两张卡可以用来推理,则会生成0和1两份,也就是说,会把同一个参数拆成两份。比如 layers.0.attention.w_qkv.0.weight
会变成 layers.0.attention.w_qkv.0.weight
和 layers.0.attention.w_qkv.1.weight
。执行 lmdeploy convert
命令时,可以通过 --tp
指定(tp 表示 tensor parallel),该参数默认值为1(也就是一张卡)。
简单来说,就是把一个大的张量(参数)分到多张卡上,分别计算各部分的结果,然后再同步汇总。
2.2 TurboMind 推理+命令行本地对话
模型转换完成后,我们就具备了使用模型推理的条件,接下来就可以进行真正的模型推理环节。
我们先尝试本地对话(Bash Local Chat
),下面用(Local Chat 表示)在这里其实是跳过 API Server 直接调用 TurboMind。简单来说,就是命令行代码直接执行 TurboMind。所以说,实际和前面的架构图是有区别的。
这里支持多种方式运行,比如Turbomind、PyTorch、DeepSpeed。但 PyTorch 和 DeepSpeed 调用的其实都是 Huggingface 的 Transformers 包,PyTorch表示原生的 Transformer 包,DeepSpeed 表示使用了 DeepSpeed 作为推理框架。Pytorch/DeepSpeed 目前功能都比较弱,不具备生产能力,不推荐使用。
执行命令如下。
# Turbomind + Bash Local Chat lmdeploy chat turbomind ./workspace
启动后就可以和它进行对话了,如下图所示。
输入后两次回车,退出时输入exit
回车两次即可。此时,Server 就是本地跑起来的模型(TurboMind),命令行可以看作是前端。
2.3 TurboMind推理+API服务
在上面的部分我们尝试了直接用命令行启动 Client,接下来我们尝试如何运用 lmdepoy 进行服务化。
”模型推理/服务“目前提供了 Turbomind 和 TritonServer 两种服务化方式。此时,Server 是 TurboMind 或 TritonServer,API Server 可以提供对外的 API 服务。我们推荐使用 TurboMind,TritonServer 使用方式详见《附录1》。
首先,通过下面命令启动服务。
# ApiServer+Turbomind api_server => AsyncEngine => TurboMind lmdeploy serve api_server ./workspace \ --server_name 0.0.0.0 \ --server_port 23333 \ --instance_num 64 \ --tp 1
上面的参数中 server_name
和 server_port
分别表示服务地址和端口,tp
参数我们之前已经提到过了,表示 Tensor 并行。还剩下一个 instance_num
参数,表示实例数,可以理解成 Batch 的大小。执行后如下图所示。
然后,我们可以新开一个窗口,执行下面的 Client 命令。如果使用官方机器,可以打开 vscode 的 Terminal,执行下面的命令。
# ChatApiClient+ApiServer(注意是http协议,需要加http) lmdeploy serve api_client http://localhost:23333
如下图所示。
当然,刚刚我们启动的是 API Server,自然也有相应的接口。可以直接打开 http://{host}:23333
查看,如下图所示。
注意,这一步由于 Server 在远程服务器上,所以本地需要做一下 ssh 转发才能直接访问(与第一部分操作一样),命令如下:
ssh -CNg -L 23333:127.0.0.1:23333 root@ssh.intern-ai.org.cn -p <你的ssh端口号>
而执行本命令需要添加本机公钥,公钥添加后等待几分钟即可生效。ssh 端口号就是下面图片里的 36408。
这里一共提供了 4 个 HTTP 的接口,任何语言都可以对其进行调用,我们以 v1/chat/completions
接口为例,简单试一下。
接口请求参数如下:
{ "model": "internlm-chat-7b", "messages": "写一首春天的诗", "temperature": 0.7, "top_p": 1, "n": 1, "max_tokens": 512, "stop": false, "stream": false, "presence_penalty": 0, "frequency_penalty": 0, "user": "string", "repetition_penalty": 1, "renew_session": false, "ignore_eos": false }
请求结果如下。
2.4 网页 Demo 演示
这一部分主要是将 Gradio 作为前端 Demo 演示。在上一节的基础上,我们不执行后面的 api_client
或 triton_client
,而是执行 gradio
。
由于 Gradio 需要本地访问展示界面,因此也需要通过 ssh 将数据转发到本地。命令如下:
ssh -CNg -L 6006:127.0.0.1:6006 root@ssh.intern-ai.org.cn -p <你的 ssh 端口号>
2.4.1 TurboMind 服务作为后端
API Server 的启动和上一节一样,这里直接启动作为前端的 Gradio。
bash
conda activate lmdeploy
# ApiServer+Turbomind api_server => AsyncEngine => TurboMind
lmdeploy serve api_server ./workspace \
--server_name 0.0.0.0 \
--server_port 23333 \
--instance_num 64 \
--tp 1
# Gradio+ApiServer。必须先开启 Server,此时 Gradio 为 Client
lmdeploy serve gradio http://0.0.0.0:23333 \
--server_name 0.0.0.0 \
--server_port 6006 \
--restful_api True
结果如下图所示。
2.4.2 TurboMind 推理作为后端
当然,Gradio 也可以直接和 TurboMind 连接,如下所示。
# Gradio+Turbomind(local) lmdeploy serve gradio ./workspace
可以直接启动 Gradio,此时没有 API Server,TurboMind 直接与 Gradio 通信。如下图所示。
2.5 TurboMind 推理 + Python 代码集成
前面介绍的都是通过 API 或某种前端与”模型推理/服务“进行交互,lmdeploy 还支持 Python 直接与 TurboMind 进行交互,如下所示。
from lmdeploy import turbomind as tm # load model model_path = "/root/share/temp/model_repos/internlm-chat-7b/" tm_model = tm.TurboMind.from_pretrained(model_path, model_name='internlm-chat-20b') generator = tm_model.create_instance() # process query query = "写一首关于秋天的诗" prompt = tm_model.model.get_prompt(query) input_ids = tm_model.tokenizer.encode(prompt) # inference for outputs in generator.stream_infer( session_id=0, input_ids=[input_ids]): res, tokens = outputs[0] response = tm_model.tokenizer.decode(res.tolist()) print(response)
在上面的代码中,我们首先加载模型,然后构造输入,最后执行推理。
加载模型可以显式指定模型路径,也可以直接指定 Huggingface 的 repo_id,还可以使用上面生成过的 workspace
。这里的 tm.TurboMind
其实是对 C++ TurboMind 的封装。
构造输入这里主要是把用户的 query 构造成 InternLLM 支持的输入格式,比如上面的例子中, query
是“写一首关于秋天的诗”,构造好的 Prompt 如下所示。
""" <|System|>:You are an AI assistant whose name is InternLM (书生·浦语). - InternLM (书生·浦语) is a conversational language model that is developed by Shanghai AI Laboratory (上海人工智能实验室). It is designed to be helpful, honest, and harmless. - InternLM (书生·浦语) can understand and communicate fluently in the language chosen by the user such as English and 中文. <|User|>:写一首关于秋天的诗 <|Bot|>: """
Prompt 其实就是增加了 <|System|>
消息和 <|User|>
消息(即用户的 query
),以及一个 <|Bot|>
的标记,表示接下来该模型输出响应了。最终输出的响应内容如下所示。
秋风萧瑟,落叶纷飞, 天高云淡,秋意渐浓。 霜叶红于二月花, 丹桂飘香,黄菊盛开。 秋天的景色,如诗如画, 让人心旷神怡,流连忘返。
确实超乎想象了!!!
2.6 这么多,头秃,有没有最佳实践
2.6.1 方案实践
必——须——有!
首先说 “模型推理/服务”,推荐使用 TurboMind,使用简单,性能良好,相关的 Benchmark 对比如下。
上面的性能对比包括两个场景:
- 场景一(前4张图):固定的输入、输出 token 数(分别1和2048),测试Token输出吞吐量(output token throughput)。
- 场景二(第5张图):使用真实数据,测试吞吐量(request throughput)。
场景一中,BatchSize=64时,TurboMind 的吞吐量超过 2000 token/s,整体比 DeepSpeed 提升约 5% - 15%;BatchSize=32时,比 Huggingface 的Transformers 提升约 3 倍;其他BatchSize时 TurboMind 也表现出优异的性能。
场景二中,对比了 TurboMind 和 vLLM 在真实数据上的吞吐量(request throughput)指标,TurboMind 的效率比 vLLM 高 30%。
大家不妨亲自使用本地对话(Local Chat)感受一下性能差别(2.2 节),也可以执行我们提供的 infer_compare.py
脚本,示例如下。
# 执行 Huggingface 的 Transformer python infer_compare.py hf # 执行LMDeploy python infer_compare.py lmdeploy
LMDeploy应该是Transformers的3-5倍左右。
后面的 API 服务和 Client 就得分场景了。
- 我想对外提供类似 OpenAI 那样的 HTTP 接口服务。推荐使用 TurboMind推理 + API 服务(2.3)。
- 我想做一个演示 Demo,Gradio 无疑是比 Local Chat 更友好的。推荐使用 TurboMind 推理作为后端的Gradio进行演示(2.4.2)。
- 我想直接在自己的 Python 项目中使用大模型功能。推荐使用 TurboMind推理 + Python(2.5)。
- 我想在自己的其他非 Python 项目中使用大模型功能。推荐直接通过 HTTP 接口调用服务。也就是用本列表第一条先启动一个 HTTP API 服务,然后在项目中直接调用接口。
- 我的项目是 C++ 写的,为什么不能直接用 TurboMind 的 C++ 接口?!必须可以!大佬可以右上角叉掉这个窗口啦。
2.6.2 模型配置实践
不知道大家还有没有印象,在离线转换(2.1.2)一节,我们查看了 weights
的目录,里面存放的是模型按层、按并行卡拆分的参数,不过还有一个文件 config.ini
并不是模型参数,它里面存的主要是模型相关的配置信息。下面是一个示例。
[llama] model_name = internlm-chat-7b tensor_para_size = 1 head_num = 32 kv_head_num = 32 vocab_size = 103168 num_layer = 32 inter_size = 11008 norm_eps = 1e-06 attn_bias = 0 start_id = 1 end_id = 2 session_len = 2056 weight_type = fp16 rotary_embedding = 128 rope_theta = 10000.0 size_per_head = 128 group_size = 0 max_batch_size = 64 max_context_token_num = 1 step_length = 1 cache_max_entry_count = 0.5 cache_block_seq_len = 128 cache_chunk_size = 1 use_context_fmha = 1 quant_policy = 0 max_position_embeddings = 2048 rope_scaling_factor = 0.0 use_logn_attn = 0
其中,模型属性相关的参数不可更改,主要包括下面这些。
model_name = llama2 head_num = 32 kv_head_num = 32 vocab_size = 103168 num_layer = 32 inter_size = 11008 norm_eps = 1e-06 attn_bias = 0 start_id = 1 end_id = 2 rotary_embedding = 128 rope_theta = 10000.0 size_per_head = 128
和数据类型相关的参数也不可更改,主要包括两个。
weight_type = fp16 group_size = 0
weight_type
表示权重的数据类型。目前支持 fp16 和 int4。int4 表示 4bit 权重。当 weight_type
为 4bit 权重时,group_size
表示 awq
量化权重时使用的 group 大小。
剩余参数包括下面几个。
tensor_para_size = 1 session_len = 2056 max_batch_size = 64 max_context_token_num = 1 step_length = 1 cache_max_entry_count = 0.5 cache_block_seq_len = 128 cache_chunk_size = 1 use_context_fmha = 1 quant_policy = 0 max_position_embeddings = 2048 rope_scaling_factor = 0.0 use_logn_attn = 0
一般情况下,我们并不需要对这些参数进行修改,但有时候为了满足特定需要,可能需要调整其中一部分配置值。这里主要介绍三个可能需要调整的参数。
- KV int8 开关:
- 对应参数为
quant_policy
,默认值为 0,表示不使用 KV Cache,如果需要开启,则将该参数设置为 4。 - KV Cache 是对序列生成过程中的 K 和 V 进行量化,用以节省显存。我们下一部分会介绍具体的量化过程。
- 当显存不足,或序列比较长时,建议打开此开关。
- 对应参数为
- 外推能力开关:
- 对应参数为
rope_scaling_factor
,默认值为 0.0,表示不具备外推能力,设置为 1.0,可以开启 RoPE 的 Dynamic NTK 功能,支持长文本推理。另外,use_logn_attn
参数表示 Attention 缩放,默认值为 0,如果要开启,可以将其改为 1。 - 外推能力是指推理时上下文的长度超过训练时的最大长度时模型生成的能力。如果没有外推能力,当推理时上下文长度超过训练时的最大长度,效果会急剧下降。相反,则下降不那么明显,当然如果超出太多,效果也会下降的厉害。
- 当推理文本非常长(明显超过了训练时的最大长度)时,建议开启外推能力。
- 对应参数为
- 批处理大小:
- 对应参数为
max_batch_size
,默认为 64,也就是我们在 API Server 启动时的instance_num
参数。 - 该参数值越大,吞度量越大(同时接受的请求数),但也会占用更多显存。
- 建议根据请求量和最大的上下文长度,按实际情况调整。
- 对应参数为
进阶作业(可选做)文章来源:https://www.toymoban.com/news/detail-837523.html
- 将第四节课训练自我认知小助手模型使用 LMDeploy 量化部署到 OpenXLab 平台。
- 对internlm-chat-7b模型进行量化,并同时使用KV Cache量化,使用量化后的模型完成API服务的部署,分别对比模型量化前后(将 bs设置为 1 和 max len 设置为512)和 KV Cache 量化前后(将 bs设置为 8 和 max len 设置为2048)的显存大小。
- 在自己的任务数据集上任取若干条进行Benchmark测试,测试方向包括:
(1)TurboMind推理+Python代码集成
(2)在(1)的基础上采用W4A16量化
(3)在(1)的基础上开启KV Cache量化
(4)在(2)的基础上开启KV Cache量化
(5)使用Huggingface推理
备注:由于进阶作业较难,完成基础作业之后就可以先提交作业了,在后续的大作业项目中使用这些技术将作为重要的加分点!文章来源地址https://www.toymoban.com/news/detail-837523.html
到了这里,关于《书生·浦语大模型全链路开源开放体系》第五课作业 LMDeploy 的量化和部署的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!