一文探秘LLM应用开发(19)-模型部署与推理(FastChat、OpenChat、HuggingChat、GPT4ALL)

技术

动手点关注

picture.image

干货不迷路

picture.image

本文旨在让无大模型开发背景的工程师或者技术爱好者无痛理解大语言模型应用开发的理论和主流工具,因此会先从与LLM应用开发相关的基础概念谈起,并不刻意追求极致的严谨和完备,而是从直觉和本质入手,结合笔者调研整理及消化理解,帮助大家能够更容易的理解LLM技术全貌,大家可以基于本文衍生展开,结合自己感兴趣的领域深入研究。若有不准确或者错误的地方也希望大家能够留言指正。

本文体系完整,内容丰富,由于内容比较多,分多次连载

第一部分 基础概念

1.机器学习场景类别

2.机器学习类型(LLM相关)

3.深度学习的兴起

4.基础模型

第二部分 应用挑战

1.问题定义与基本思路

2.基本流程与相关技术

1)Tokenization与Embbeding

2)向量数据库

3)finetune(微调)

4)模型部署与推理

5)prompt

6)编排与集成

7)预训练

第三部分 场景案例

常用参考

第二部分 应用挑战

2.基本流程与相关技术

4)模型部署与推理

模型服务层相关工具和框架

前文对模型服务层做了简单的分类,基于封装程度不同,有大量的框架和工具,笔者结合目前趋势,在每个类别中挑选了几个常见的项目和大家分享,它们各有特点,将从内向外一一介绍,最后给出一些选型建议以供参考。

picture.image

从应用开发者角度看,使用简单,功能强大,开箱即用,类似于ChatGPT这样的产品化的大模型ChatServer是最佳形态,它是对推理引擎和推理服务的再封装,一般不仅包含推理,还包含模型微调,评估等,覆盖大模型全生命周期,更有一些项目直接对标ChatGPT包含插件等高级功能。下面就给大家介绍几款业内比较知名的ChatServer产品。

FastChat

picture.image

FastChat系出名门,源自于加州大学伯克利分校和CMU共建的LMSYS,它是由前文介绍的基于vllm推理引擎后端的打擂平台的ChatServer开源而来,功能覆盖训练,推理,评估的全过程。设计目标也非常明确,就是在性能、功能及风格上全面对标OpenAI ChatGPT,以成为ChatGPT的开源平替。得益于来自于学术界,因此,FastChat最大优势是能够将最新的学术成果应用到产品中。除了vLLM,预置了基于llama二次训练的Vicuna模型,官方号称能达到ChatGPT的90%的能力(2023.3.30),该模型现已更新到1.5。在上下文长度层面应用了LongChat,其特点是将上下文长度扩展到 16K 字节的新水平。评估结果表明,LongChat-13B 的远程检索准确率比其他长语境开放模型(如 MPT-7B-storywriter (84K)、MPT-30B-chat (8K) 和 ChatGLM2-6B (8K))高出 2 倍。

需要注意的是,FastChat默认的推理后端仍然是huggingface transformer pipeline,要在启动时手工将fastchat.serve.model_worker改为fastchat.serve.vllm_worker。


            
pip install vllm
            

            
python3 -m fastchat.serve.vllm_worker --model-path lmsys/vicuna-7b-v1.3
            
#if you see tokenizer errors
            
python3 -m fastchat.serve.vllm_worker --model-path lmsys/vicuna-7b-v1.3 --tokenizer hf-internal-testing/llama-tokenizer
        

在评估层面,FastChat的方式比较有新意,它使用 MT-bench(多轮开放式问题集)来评估模型,并使用GPT-4来判断回答质量。

问题例子:


            
{"question_id": 1, "category": "generic", "turns": ["How can I improve my time management skills?"]}
            
...
        

下面是评估的prompt模版:


            
{"name": "pair-v2", "type": "pairwise", "system_prompt": "Please act as an impartial judge and evaluate the quality of the responses provided by two AI assistants to the user question displayed below. You should choose the assistant that follows the user's instructions and answers the user's question better. Your evaluation should consider factors such as the helpfulness, relevance, accuracy, depth, creativity, and level of detail of their responses. Begin your evaluation by comparing the two responses and provide a short explanation. Avoid any position biases and ensure that the order in which the responses were presented does not influence your decision. Do not allow the length of the responses to influence your evaluation. Do not favor certain names of the assistants. Be as objective as possible. After providing your explanation, output your final verdict by strictly following this format: \"[[A]]\" if assistant A is better, \"[[B]]\" if assistant B is better, and \"[[C]]\" for a tie.", "prompt_template": "[User Question]\n{question}\n\n[The Start of Assistant A's Answer]\n{answer_a}\n[The End of Assistant A's Answer]\n\n[The Start of Assistant B's Answer]\n{answer_b}\n[The End of Assistant B's Answer]", "description": "Prompt for general questions", "category": "general", "output_format": "[[A]]"}
            
{"name": "pair-v2-multi-turn", "type": "pairwise", "system_prompt": "Please act as an impartial judge and evaluate the quality of the responses provided by two AI assistants to the user questions. You should choose the assistant that follows the user's instructions and answers the user's questions better. Your evaluation should consider factors such as the helpfulness, relevance, accuracy, depth, creativity, and level of detail of their responses. You should focus on who provides a better answer to the second user question. Begin your evaluation by comparing the responses of the two assistants and provide a short explanation. Avoid any position biases and ensure that the order in which the responses were presented does not influence your decision. Do not allow the length of the responses to influence your evaluation. Do not favor certain names of the assistants. Be as objective as possible. After providing your explanation, output your final verdict by strictly following this format: \"[[A]]\" if assistant A is better, \"[[B]]\" if assistant B is better, and \"[[C]]\" for a tie.", "prompt_template": "<|The Start of Assistant A's Conversation with User|>\n\n### User:\n{question_1}\n\n### Assistant A:\n{answer_a_1}\n\n### User:\n{question_2}\n\n### Assistant A:\n{answer_a_2}\n\n<|The End of Assistant A's Conversation with User|>\n\n\n<|The Start of Assistant B's Conversation with User|>\n\n### User:\n{question_1}\n\n### Assistant B:\n{answer_b_1}\n\n### User:\n{question_2}\n\n### Assistant B:\n{answer_b_2}\n\n<|The End of Assistant B's Conversation with User|>", "description": "Prompt for multi-turn general questions", "category": "general", "output_format": "[[A]]"}
            
...
        

实际运行的截图:

picture.image

最终评估结果可以绘制成雷达图展示。

picture.image

在生态集成上,由于它完全兼容OpenAI的风格,基于ChatGPT的langchain应用,可以无缝地使用FastChat替代。


            
python3 -m fastchat.serve.model_worker --model-names "gpt-3.5-turbo,text-davinci-003,text-embedding-ada-002" --model-path lmsys/vicuna-7b-v1.3
            
python3 -m fastchat.serve.openai_api_server --host localhost --port 8000
        

FastChat的前端比较简陋,采用的是gradio生成,对于直接面向实际用户使用还有一定的距离,在管理功能层面也有一定的改进空间。

OpenChat

相较于学术产品的专注底层,在功能本身比较简单,而与之对比,OpenChat本质上是一个应用层上的产品,因此,在产品功能层面就更加的完善,更大功夫花在如何更方便的生成和管理ChatBot,从功能体验层面,更面向于终端用户,体现开箱即用的特点。OpenChat 无需编码,仅通过界面操作就能创建自己的聊天机器人,并且还可以很方便地被集成在现有网站中,就像增加一个问卷调查一样简单,轻松完成私域问答。在此之上,OpenChat可以很好地将这些Chatbot管理起来,形成自己的ChatBot矩阵。

OpenChat这些特性对于想要在自己网站中快速增加对话问答能力的用户是非常有吸引力的。但 项目目前也有一定潜在弱点,其一是在本地模型及中间件支持上还不够完善,强依赖云能力,现在还无法完全做到私有化(正在实现中)。其二,在底层优化上涉及较少,比较依赖底层引擎本身表现,这对于后期实际使用存在着一定的不可控性。

HuggingChat

picture.image

HuggingChat是HuggingFace出品的ChatServer产品,定位为ChatGPT的开源替代品。它实际上就是在推理引擎text-generation-inference(TGI)的基础上,增加了前端的UI及对话的历史的存储。所以,其项目名也很明确叫做ChatUI。

picture.image

在产品能力上,huggingchat也更像是一个演示性产品,产品中并不包含chatbot刚需的对话的context管理,也就是说,它无法进行多轮对话,而chatUi给出的方案是开发者自己绕过。

picture.image

当然,huggingchat相较于chatGPT有两个特色的功能——搜索和自定义模型。搜索功能是基于RAG架构,框架能够通过google收集更可靠的数据资料,这对于缓解大模型幻觉问题有一定的帮助。具体的SERPAPI,该api支持将google,baidu,bing等搜索的结果进行结构化,简化了网页解析的复杂度。另一方面,huggingchat得益于TGI的加持,支持自定义模型的切换。如下可以自定义传递给模型的参数或者可以通过更新 .env.local 中的 MODELS 变量来使用新模型:


            

            
MODELS=`[
            
  {
            
    "name": "OpenAssistant/oasst-sft-4-pythia-12b-epoch-3.5",
            
    "datasetName": "OpenAssistant/oasst1",
            
    "description": "A good alternative to ChatGPT",
            
    "websiteUrl": "https://open-assistant.io",
            
    "userMessageToken": "<|prompter|>", # This does not need to be a token, can be any string
            
    "assistantMessageToken": "<|assistant|>", # This does not need to be a token, can be any string
            
    "userMessageEndToken": "<|endoftext|>", # Applies only to user messages. Can be any string.
            
    "assistantMessageEndToken": "<|endoftext|>", # Applies only to assistant messages. Can be any string.
            
    "preprompt": "Below are a series of dialogues between various people and an AI assistant. The AI tries to be helpful, polite, honest, sophisticated, emotionally aware, and humble-but-knowledgeable. The assistant is happy to help with almost anything, and will do its best to understand exactly what is needed. It also tries to avoid giving false or misleading information, and it caveats when it isn't entirely sure about the right answer. That said, the assistant is practical and really does its best, and doesn't let caution get too much in the way of being useful.\n-----\n",
            
    "promptExamples": [
            
      {
            
        "title": "Write an email from bullet list",
            
        "prompt": "As a restaurant owner, write a professional email to the supplier to get these products every week: \n\n- Wine (x10)\n- Eggs (x24)\n- Bread (x12)"
            
      }, {
            
        "title": "Code a snake game",
            
        "prompt": "Code a basic snake game in python, give explanations for each step."
            
      }, {
            
        "title": "Assist in a task",
            
        "prompt": "How do I make a delicious lemon cheesecake?"
            
      }
            
    ],
            
    "parameters": {
            
      "temperature": 0.9,
            
      "top_p": 0.95,
            
      "repetition_penalty": 1.2,
            
      "top_k": 50,
            
      "truncate": 1000,
            
      "max_new_tokens": 1024,
            
      "stop": ["<|endoftext|>"]  # This does not need to be tokens, can be any list of strings
            
    }
            
  }
            
]`
            

        

GPT4ALL

picture.image M1 macOS设备上运行

gpt4all是一个主要面向端设备的大模型ChatServer。该项目相较于llama.cpp这样的底层引擎来比,封装度更高,做到了开箱即用,使用它会有一种本地使用chatGPT的错觉感。GPT4All的模型是一个3GB-8GB的文件,可以下载并插入GPT4All开源生态系统软件。作为Gpt4all的发起者Nomic AI支持并维护这一软件生态系统,以加强质量和安全,同时带头让任何人或企业都能轻松地训练和部署自己的边缘大型语言模型。由于定位在个人pc,覆盖mac,windows,ubuntu,也不要求GPU,一键安装,能够完成常见的问答,个人助理,文章总结,写代码等常见任务场景,受到了很多开发者的青睐,该项目当下已经获得了52.5k收藏,可以看出其受欢迎程度。

gpt4all基于模块定位分为4个项目,分别是gpt4all-backend(内置的经过高度优化推理引擎),gpt4all-bindings(面向不同语言的高阶的编程接口),gpt4all-api(经过封装的推理服务,对外暴露rest API),gpt4all-chat(客户端UI)。

GPT4ALL在模型上支持Falcon,LLama。Mpt,GPT-J架构下的模型,并对这些模型进行了量化,以便能够在PC上运行。另一方面,gpt4all将GGML,llama.cpp作为其中一个推理后端,因此,llama.cpp支持的模型,gpt4all都可以支持。

picture.image

除此之外,gpt4all有一个特色功能就是支持插件,通过插件可以极大地扩展LLM的能力,从而使得gpt4all进一步地向chatgpt靠拢。但遗憾的是,可能是受限于LLM的能力,它的插件( LocalDocs)还仅仅类似于RAG的检索增强,还无法做到采用Re-Act模式根据prompt及返回内容按需调起。

picture.image

gpt4all也支持server模式部署,对外提供OpenAI风格的推理接口,并且gpt4all与langchain等框架无缝集成,开发者想要使用gpt4all作为后端也是方便的。

小结

对于ChatServer来讲,已经是面向场景需求高度产品化后的产物,这也是为什么前面四个产品,功能差异明显,受众各异,这本质是一个“产品选用户”的逻辑,很难做到完全契合每一个业务实际的需求。在这个层面,选择产品并用在正确的地方更重要,因而会有一定的”选择成本“。对于有更高灵活性,个性化的场景,那就需要从推理服务,甚至推理引擎层面来集成,越底层,就越灵活,同时,开发门槛和使用成本就越高,因此,直接选择产品还是底层框架工具,这是结合实际情况平衡的问题。

选型建议:

最后,结合前面文章,在框架工具层面,给出私有化的服务端通用推理方案选型建议,可总结为两类:

路线1:k8s + triton server+vLLM,或者未来的triton server + tensorRTLLM,绑定英伟达,在软硬一体化优化层有优势。

路线2:k8s + kubeRay + rayLLM(ray serve)+ vLLM/TGI,Ray作为分布式机器学习全链路的基础设施,在统一基建层面上有优势。

下一章将介绍激发大模型的智能的魔法Prompt,欢迎关注。

合集目录:

第一部分 基础概念

一文探秘LLM应用开发(1)

第二部分 应用挑战

1.问题定义与基本思路

一文探秘LLM应用开发(2)

2 . 基本流程与相关技术

1)Tokenization与Embbeding

一文探密LLM应用开发(3)

2)向量数据库

一文探秘LLM应用开发(4)

3)微调

一文探秘LLM应用开发(5)-微调(背景与挑战)

一文探秘LLM应用开发(6)-微调(方案理论)

一文探秘LLM应用开发(7)-微调(工具实践)

4)模型部署与推理

一文探秘LLM应用开发(8)-模型部署与推理(DEMO验证)

一文探秘LLM应用开发(9)-模型部署与推理(模型适配优化之GPU面面观-1)

一文探秘LLM应用开发(10)-模型部署与推理(模型适配优化之GPU面面观-2)

一文探秘LLM应用开发(11)-模型部署与推理(模型大小与推理性能的关系)

一文探秘LLM应用开发(12)-模型部署与推理(大模型相关参数计算及性能分析)

一文探秘LLM应用开发(13)-模型部署与推理(优化理论)

一文探秘LLM应用开发(14)-模型部署与推理(技术架构)

一文探秘LLM应用开发(15)-模型部署与推理(框架工具-推理执行引擎(HF pipeline))

一文探秘LLM应用开发(16)-模型部署与推理(框架工具-TGI,vLLM,TensorRT-LLM,DS-MII)

一文探秘LLM应用开发(17)-模型部署与推理(框架工具-ggml、mlc-llm、ollama)

一文探秘LLM应用开发(18)-模型部署与推理(框架工具-Triton Server、RayLLM、OpenLLM)

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
火山引擎大规模机器学习平台架构设计与应用实践
围绕数据加速、模型分布式训练框架建设、大规模异构集群调度、模型开发过程标准化等AI工程化实践,全面分享如何以开发者的极致体验为核心,进行机器学习平台的设计与实现。
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论