如果我們想搭建一個(gè)企業(yè)級(jí)的大模型應(yīng)用碍拆,不管使用開源的基礎(chǔ)模型自己來發(fā)布,還是使用類似于 ChatGPT 的閉源 API慨蓝,我們都需要搭建一個(gè)大模型流水線來管理應(yīng)用體系中除了基礎(chǔ)模型之外的功能模塊感混。
Replit 的一篇博客(https://blog.replit.com/llm-training)里列出了一個(gè)非常典型的使用私有數(shù)據(jù)來訓(xùn)練和伺服私有大模型的流水線:
當(dāng)然,絕大部分企業(yè)或者機(jī)構(gòu)都不會(huì)太需要自己去訓(xùn)練一個(gè)私有化的大模型礼烈,但是即使是做一個(gè)簡單的 RAG(Retrieval-Augmented Generation)系統(tǒng)弧满,我們也需要一個(gè)完整的文檔處理流水線來持續(xù)轉(zhuǎn)換文檔,劃分文檔為合適的文本塊此熬,選擇合適的 embedding model 和向量數(shù)據(jù)庫庭呜,然后使用 prompt engineering 來構(gòu)建合理的問題提交給大模型。在目前來說犀忱,類似于 LlamaIndex 或者 LangChain 的工具在使用集成的第三方 API 或者內(nèi)嵌的數(shù)據(jù)庫來實(shí)現(xiàn)快速原型是很方便的募谎,但是如果我們想嘗試獨(dú)立的 embedding 模型,高速的分布式向量數(shù)據(jù)庫阴汇,定制化的文檔劃分策略数冬,或者是細(xì)分的權(quán)限管理,還是有很多額外的工作要處理搀庶。
除了基礎(chǔ)大模型之外拐纱,大模型生態(tài)系統(tǒng)中用來建設(shè)一個(gè)模型流水線的工具組件可以分為兩大類铜异,第一類是作為第三方庫被其它應(yīng)用調(diào)用,從最底層的 CUDA秸架,PyTorch揍庄,Pandas, 到中間的各種 tokenizer, quantization, 到上層的 Transformers, Adapters 等等。第二類一般是作為建設(shè)一個(gè)完整模型流水線時(shí)的一個(gè)應(yīng)用組件东抹,可以獨(dú)立運(yùn)行并完成特定的任務(wù)蚂子。當(dāng)然,有些開源系統(tǒng)兩種使用形式都存在缭黔,例如向量數(shù)據(jù)庫缆镣,很多既可以獨(dú)立運(yùn)行,又可以作為一個(gè)內(nèi)嵌的組件供應(yīng)用使用试浙。作為最終模型流水線的搭建者來講董瞻,我們直接打交道的大部分是第二類應(yīng)用組件類型的工具,它們又會(huì)去調(diào)用很多第一類的第三方庫來完成自己的工作田巴。
下面列出了一些常用的應(yīng)用組件類別以及其代表性開源組件钠糊。
1. Model Serving
模型服務(wù)工具,將訓(xùn)練好的模型部署為可供應(yīng)用程序使用的服務(wù)壹哺。這些工具通常提供 API 接口抄伍,允許開發(fā)者輕松地將模型集成到現(xiàn)有的系統(tǒng)中,支持高并發(fā)請求管宵,確保模型的響應(yīng)速度和穩(wěn)定性截珍。
vLLM: 一個(gè)高吞吐量且內(nèi)存效率高的推斷和服務(wù)引擎,主要使用了 PagedAttention 和定制的 CUDA kernel 來提高性能箩朴。
GPT4All: 支持在日常硬件上(主要是 CPU 上)訓(xùn)練和部署 quantized LLM岗喉。
Ollama: 方便的在私有化環(huán)境下一鍵發(fā)布和運(yùn)行各種開源大模型,提供通用命令行推理工具以及兼容 OpenAI API 的 API 接口炸庞。
LocalAI: 主要目標(biāo)是 OpenAI API 生態(tài)體系的本地替代品钱床,允許在本地運(yùn)行大模型服務(wù),與 OpenAI backend 無縫切換埠居。
2. Training Framework
訓(xùn)練框架查牌,提供了工具和 API 來簡化大規(guī)模模型的訓(xùn)練過程。這些框架優(yōu)化了數(shù)據(jù)處理滥壕、模型構(gòu)建纸颜、訓(xùn)練循環(huán)和資源管理等過程,使得開發(fā)者可以更專注于模型的設(shè)計(jì)和實(shí)驗(yàn)绎橘。
Megatron: NVIDIA 提出的一種用于分布式訓(xùn)練大規(guī)模語言模型的架構(gòu)胁孙,針對 Transformer 進(jìn)行了專門的優(yōu)化(也就是大矩陣乘法)。
Lightning: 支持在大規(guī)模分布式環(huán)境下使用 PyTorch 進(jìn)行 AI 模型的預(yù)訓(xùn)練、微調(diào)和部署浊洞,而無需修改代碼。
3. Scheduling and Orchestration
調(diào)度工具胡岔,將模型運(yùn)行在云上或者分布式集群中法希。
SkyPilot: 主要支持在公有云服務(wù)上一鍵運(yùn)行 LLM、AI 和批處理作業(yè)靶瘸,而無需手動(dòng)去購買資源以及配置服務(wù)器苫亦,它可以自動(dòng)尋找最合適的配置,并在運(yùn)行完成后自動(dòng)釋放資源怨咪,提供成本節(jié)約屋剑、提高 GPU 使用效率。
Ray: Ray 是一款基于 PyTorch 的框架诗眨,專為并行處理 AI 和 Python 應(yīng)用程序設(shè)計(jì)唉匾。它提供了高級(jí) API,可用于處理數(shù)據(jù)匠楚、模型巍膘、超參數(shù)和強(qiáng)化學(xué)習(xí)等任務(wù),以及核心原語芋簿,可用于構(gòu)建分布式應(yīng)用或自定義平臺(tái)峡懈。
4. Document Processing
文檔處理工具,專注于從非結(jié)構(gòu)化數(shù)據(jù)中提取信息和結(jié)構(gòu)与斤,如從 PDF肪康、圖片或文本文件中提取文本內(nèi)容和元數(shù)據(jù)。
Unstructured: 提供了用于攝取和預(yù)處理圖像和文本文檔的開源組件撩穿,例如 PDF磷支,HTML,Word 文檔食寡,和更多其他格式齐唆。它的模塊化功能和連接器形成了一個(gè)統(tǒng)一的系統(tǒng),簡化了數(shù)據(jù)攝取和預(yù)處理冻河,使其能適應(yīng)不同的平臺(tái)箍邮,并有效地將非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)化為結(jié)構(gòu)化輸出。
Apache Tika: Apache Tika 工具套件可以檢測并提取來自一千多種不同文件類型(如 PPT叨叙、XLS 和 PDF)的元數(shù)據(jù)和文本锭弊。所有這些文件類型都可以通過單一接口進(jìn)行解析,使 Tika 對于搜索引擎索引擂错、內(nèi)容分析味滞、翻譯等都非常有用。
5. VectorDB
向量數(shù)據(jù)庫,專門用于存儲(chǔ)和檢索向量數(shù)據(jù)剑鞍,主要用于實(shí)現(xiàn)基于相似性搜索和 RAG 系統(tǒng)中昨凡。
Milvus: 主要特點(diǎn)是支持分布式發(fā)布以及并行處理,底層使用 etcd, MinIO, Pulsar, RocketMQ 等分布式處理組件蚁署,在生產(chǎn)環(huán)境上可以快速支持彈性擴(kuò)展便脊。
Chroma: 主要特點(diǎn)是安裝快速方便,資源開銷小光戈,依賴簡單哪痰,適合用在嵌入式場景下,快速構(gòu)數(shù)據(jù)搜索應(yīng)用久妆。
6. Application Framework
應(yīng)用框架晌杰,提供了構(gòu)建特定應(yīng)用程序的基礎(chǔ)設(shè)施和組件,如語言模型的索引和檢索筷弦、聊天機(jī)器人的對話管理等肋演。
LlamaIndex: 簡化 LLM 和外部數(shù)據(jù)源(比如 API、PDF烂琴、SQL 等)之間進(jìn)行交互的工作惋啃,可以快速實(shí)現(xiàn)基于數(shù)據(jù)的大模型應(yīng)用。它提供了對結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的索引监右,有助于簡化處理不同的數(shù)據(jù)源边灭。它能夠存儲(chǔ)提示工程所需的上下文,處理上下文窗口過大時(shí)的限制健盒,并在查詢期間幫助平衡成本和性能的關(guān)系绒瘦。
LangChain: 將各種大模型功能以 chain 的方式集成起來,幫助開發(fā)人員低代碼快速開發(fā)端到端大模型應(yīng)用扣癣。LangChain 提供了一整套的工具惰帽、組件和接口,能夠方便地處理與語言模型的交互父虑,連接多個(gè)組件该酗,以及整合額外的資源,如 API 和數(shù)據(jù)庫士嚎。
7. Finetune
微調(diào)工具呜魄,允許開發(fā)者在特定的數(shù)據(jù)集上調(diào)整預(yù)訓(xùn)練模型的參數(shù),以提高模型在特定任務(wù)上的表現(xiàn)莱衩。
Llama Factory: 基于 PyTorch爵嗅,用于微調(diào)和二次訓(xùn)練 LLM 的框架。支持多種微調(diào)方法和優(yōu)化技術(shù)笨蚁,如 LoRA睹晒、QLoRA趟庄、P-Tuning 等,可以在有限的算力和數(shù)據(jù)下伪很,定制開發(fā)專屬的領(lǐng)域大模型戚啥。還提供了一個(gè)名為 LLaMA Board 的網(wǎng)頁界面,可以方便地調(diào)整模型參數(shù)和查看訓(xùn)練結(jié)果锉试。
HuggingFace TRL: 一個(gè)基于 PyTorch 的框架猫十,用于使用強(qiáng)化學(xué)習(xí)訓(xùn)練 Transformer 的模型。它提供了一整套工具键痛,從監(jiān)督微調(diào)(SFT)炫彩、獎(jiǎng)勵(lì)建模(RM)到近端策略優(yōu)化(PPO)等步驟匾七,可以方便地定制和優(yōu)化語言模型的性能和品質(zhì)絮短。它還支持多種預(yù)訓(xùn)練模型、數(shù)據(jù)集昨忆、采樣方法和訓(xùn)練輔助功能丁频,涵蓋了不同的任務(wù)需求。
8. RAG: RAG
(Retrieval-AugmentedGeneration)
是一種結(jié)合了檢索和生成的技術(shù)邑贴,用于提高語言模型在特定任務(wù)上的表現(xiàn)席里,如問答和文本生成。
PrivateGPT: 私有發(fā)布的 RAG 平臺(tái)拢驾,使用 LlamaIndex 搭建 RAG 流水線奖磁,在本地運(yùn)行 Chat UI,提供大部分模型管理以及文檔管理功能繁疤,同時(shí)提供 OpenAI API 兼容的接口咖为,可以方便地與現(xiàn)有的應(yīng)用集成。
LocalGPT: 使用 LangChain稠腊,llama-cpp 和 Streamlit 搭建的 RAG 平臺(tái)躁染,主要特點(diǎn)是支持各種 quantized LLM 和 CPU 運(yùn)行,可以快速在單機(jī)上運(yùn)行架忌。
9. ChatBot
集成聊天機(jī)器人吞彤,專注于構(gòu)建和部署交互式對話系統(tǒng),一般提供對話管理叹放、提示詞工程管理饰恕、歷史管理的功能。
NextChat: 用于快速創(chuàng)建和部署跨平臺(tái)的 ChatGPT/Gemini 應(yīng)用井仰,可以快速地搭建自己的私人聊天機(jī)器人懂盐,支持 GPT3, GPT4 和 Gemini Pro 等多種語言模型以及提示詞管理,歷史管理等核心功能糕档,提供 Linux / Windows / MacOS 客戶端莉恼。
Jan: 提供了一個(gè)跨平臺(tái)的本地 ChatBot 桌面應(yīng)用拌喉,支持 Linux / Windows / MacOS,內(nèi)嵌使用其自主開發(fā)的 Nitro 推理引擎來運(yùn)行大模型俐银,可以作為一個(gè)完全離線的 ChatGPT 替代產(chǎn)品尿背。
然而,使用這個(gè)生態(tài)系統(tǒng)搭建模型流水線的一個(gè)主要挑戰(zhàn)是管理和維護(hù)各種依賴項(xiàng)的兼容性捶惜,包括 Python 版本田藐、第三方庫版本、CUDA 版本以及硬件和操作系統(tǒng)的兼容性吱七。這些因素共同構(gòu)成了一個(gè)復(fù)雜的環(huán)境汽久,經(jīng)常導(dǎo)致版本沖突和不兼容的情況。此外踊餐,如何將各個(gè)組件的配置統(tǒng)一管理起來景醇,不用重復(fù)配置,不用手動(dòng)配置各種端口以避免沖突吝岭,動(dòng)態(tài)管理依賴三痰,也是常見需要解決的問題。除了應(yīng)用運(yùn)行之外窜管,數(shù)據(jù)在這些組件之間的流動(dòng)也需要完善的管理以保證數(shù)據(jù)的正確性以及數(shù)據(jù)任務(wù)的及時(shí)完成散劫。
這些問題聽起來是不是有些熟悉呢?是的幕帆,這些問題其實(shí)還是屬于傳統(tǒng)數(shù)據(jù)流水線(Data Pipeline)和運(yùn)維(DataOps)的范疇获搏,只不過多了幾個(gè)特定功能場景:使用 GPU 或者 CPU 來發(fā)布大模型,用 sequence 數(shù)據(jù)(大部分是文檔)來 finetune, pretrain 大模型失乾,或者用大模型來進(jìn)行 inference 服務(wù)或者以 agent 形式提供自動(dòng)操作常熙。在 A16Z 的“Emerging Architectures for LLM Applications”博客中列出的大模型應(yīng)用技術(shù)棧中,除了 Data Pipelines 本身就屬于這個(gè)技術(shù)棧的一部分之外仗扬,類似 Embedding Model, Vector DB, Logging/Observability, Orchestration 這些組件症概,其實(shí)和 DataOps 中相應(yīng)的組件的管理運(yùn)營方式差別不大,特別是在云原生和容器化這個(gè)方向上早芭,基本是一致的彼城。
所以,我們認(rèn)為退个,將這些組件以容器的形式實(shí)現(xiàn)標(biāo)準(zhǔn)化發(fā)布(上面的組件中很多都已經(jīng)提供 Docker 發(fā)布方式)募壕,使用類似于 Kubernetes 這樣的資源調(diào)度平臺(tái)來管理這些組件的運(yùn)行,可以大大降低大模型流水線的使用門檻语盈,提高大模型應(yīng)用發(fā)布和運(yùn)行的效率舱馅。而且,不管后端的基礎(chǔ)大模型如何變化刀荒,這樣建設(shè)流水線的工作都是需要的甚至我們可以說代嗤,為了適應(yīng)快速迭代的基礎(chǔ)大模型棘钞,我們應(yīng)該以云原生,容器化干毅,服務(wù)化宜猜,標(biāo)準(zhǔn)化的方式建設(shè)我們的大模型流水線,允許我們在不同的私有發(fā)布硝逢,公有發(fā)布的大模型之間隨意切換姨拥,選擇最適合我們應(yīng)用場景和和價(jià)格最合適的大模型使用模式。
我們將會(huì)在”容器中的大模型”系列博客中渠鸽,以不同的大模型應(yīng)用場景(例如 RAG叫乌,Text2SQL 等等)為例,展示如何以容器化的方式發(fā)布這些開源大模型應(yīng)用組件并合理地將它們組織起來來完成具體場景的工作徽缚。希望這些博客能為準(zhǔn)備建設(shè)大模型流水線的讀者提供一些參考憨奸,也非常期待大家的反饋和建議。