指南)
推理引擎大模型【免費下載鏈接】FlexGenRunning large language models on a single GPU for throughput-oriented scenarios.項目地址https://gitcode.com/gh_mirrors/fl/FlexGen點擊查看免費下載本文以 FlexGen 倉庫中收錄的論文《High-throughput Generative Inference of Large Language Models with a Single GPU》為核心骨架結(jié)合倉庫源碼flexgen/flex_opt.py、flexgen/compression.py、experimental/cost_model.py 等展開解讀。通過本文你將理解 FlexGen 如何在單塊普通 GPU如 16GB T4上通過 GPU/CPU/磁盤三級異構(gòu)聚合、線性規(guī)劃策略搜索與 4-bit 分組量化將 OPT-175B 級別的模型吞吐推升至 1 token/s 以上并掌握--percent卸載策略、壓縮開關(guān)、HELM 基準(zhǔn)接入與分布式擴(kuò)展的完整實操方法。FlexGen 的定位是面向吞吐優(yōu)先throughput-oriented場景的生成引擎這類任務(wù)批量評測、信息抽取、數(shù)據(jù)整理、表單處理需要以批處理方式在數(shù)百萬 token 上反復(fù)運行 LLM對單次延遲不敏感但對整段運行時間的 token 吞吐率極為敏感。其核心思想是用 I/O 效率換延遲在低成本單 GPU 硬件上把批大小做到傳統(tǒng)方案無法企及的規(guī)模從而顯著提升最大吞吐。倉庫 README 同時明確列出了其局限性作為基于卸載offloading的系統(tǒng)在弱 GPU 上、尤其是小批量場景下其速度仍遠(yuǎn)低于擁有足夠強(qiáng) GPU 將整個模型駐留顯存的方案因此它主要針對單 GPU 上的批量處理設(shè)置優(yōu)化。一、論文核心貢獻(xiàn)為什么單卡能跑 175B 模型1.1 問題背景LLM 推理的資源門檻論文摘要指出大語言模型推理的傳統(tǒng)路徑需要多塊高端加速器才能可行。而現(xiàn)實中出現(xiàn)了一批延遲不敏感l(wèi)atency-insensitive的批量處理任務(wù)公司內(nèi)部全部私有文檔的分類與抽取、HELM 基準(zhǔn)上全部任務(wù)的跑分等。這類工作負(fù)載允許晚上提交作業(yè)、隔夜跑完的運行方式代價是吞吐率直接決定成本——吞吐被定義為任務(wù)整個運行時間可達(dá)數(shù)小時內(nèi)每秒處理的 token 數(shù)。這種特性使得用延遲換吞吐成為可行策略也讓低成本的普通商用 GPU 有了用武之地。1.2 三大關(guān)鍵技術(shù)FlexGen 應(yīng)對資源約束的三大手段README How It Works 一節(jié)與論文摘要一致異構(gòu)資源聚合GPU CPU Disk在不同硬件資源約束下靈活配置把權(quán)重、激活、注意力 KV cache 分散存放在 GPU 顯存、CPU 內(nèi)存與磁盤上按需加載計算線性規(guī)劃LP策略優(yōu)化器通過線性規(guī)劃自動搜索張量存哪里、何時訪問的最優(yōu)模式在給定硬件GPU/CPU/磁盤容量與帶寬約束下最大化吞吐4-bit 分組量化壓縮對權(quán)重與注意力 KV cache 均壓縮到 4 bit精度損失可忽略negligible從而把可容納的批大小上限大幅抬升。1.3 代表性結(jié)果以論文/README 為準(zhǔn)論文摘要給出了兩個標(biāo)志性結(jié)論均基于 GCP 上單塊 NVIDIA T416GB實例、208GB DRAM、1.5TB SSD 的環(huán)境input seq len512output seq len32批大小調(diào)至各系統(tǒng)最大吞吐值運行 OPT-175B 時FlexGen首次在單 16GB GPU 上達(dá)到 1 token/s 的生成吞吐有效批大小 144配合壓縮后的數(shù)字見下文性能表在 HELM 基準(zhǔn)上FlexGen 用 16GB GPU 在 21 小時內(nèi)完成了 30B 模型在 7 個代表性子場景下的跑分。二、上手實測從 OPT-1.3B 到 OPT-175B2.1 安裝倉庫 README 給出兩種安裝方式唯一硬性要求是PyTorch 1.12# 方式一pip 安裝 pip install flexgen # 方式二源碼安裝 git clone https://github.com/FMInference/FlexGen.git cd FlexGen pip install -e .2.2 OPT-1.3B無卸載快速體驗小模型可直接放進(jìn)單 GPU無需卸載。FlexGen 會自動從 Hugging Face 下載權(quán)重python3 -m flexgen.flex_opt --model facebook/opt-1.3b運行后會看到 OPT-1.3B 生成的文本以及 benchmark 結(jié)果prefill/decode 延遲與吞吐見 flex_opt.py 的日志邏輯。2.3 OPT-30B引入 CPU 卸載與--percentpython3 -m flexgen.flex_opt --model facebook/opt-30b --percent 0 100 100 0 100 0--percent是 FlexGen 最核心的參數(shù)。它接收 6 個整數(shù)依次表示源碼注釋原文見 flex_opt.py位置含義默認(rèn)值1權(quán)重放在 GPU 的百分比1002權(quán)重放在 CPU 的百分比03注意力 cache 放在 GPU 的百分比1004注意力 cache 放在 CPU 的百分比05激活activations放在 GPU 的百分比1006激活放在 CPU 的百分比0每一類的磁盤百分比是隱含的第三項由Policy屬性計算得出flex_opt.pyproperty def w_disk_percent(self): # 權(quán)重磁盤占比 return 100 - self.w_gpu_percent - self.w_cpu_percent property def cache_disk_percent(self): # cache 磁盤占比 return 100 - self.cache_gpu_percent - self.cache_cpu_percent property def act_disk_percent(self): # 激活磁盤占比 return 100 - self.act_gpu_percent - self.act_cpu_percent實際分配時init_weight_list會按張量體積的累計分布cumsum把不同權(quán)重切成三段分別落到磁盤、CPU、GPUflex_opt.py。因此--percent 0 100 100 0 100 0的含義是權(quán)重全部放 CPU、cache 與激活全部放 GPU——這是 30B 在 16GB 顯卡上的典型起點。參考策略可見 benchmark/flexgen/bench_suite.py30B 無壓縮時通常采用--percent 20 80 0 100 0 100或--percent 10 90 0 100 0 100約 10%~20% 權(quán)重駐留 GPU其余在 CPU并搭配--gpu-batch-size 48 --num-gpu-batches 3之類的分批參數(shù)。2.4 OPT-175B全量卸載到磁盤OPT-175B 需要先從 metaseq 項目下載權(quán)重并按 Alpa 格式轉(zhuǎn)換然后可將全部權(quán)重卸載到 SSDpython3 -m flexgen.flex_opt --model facebook/opt-175b --percent 0 0 100 0 100 0 --offload-dir YOUR_SSD_FOLDER--offload-dir默認(rèn)值為~/flexgen_offload_dirflex_opt.py用于存放卸載到磁盤的張量。三、吞吐優(yōu)先場景HELM 基準(zhǔn)與數(shù)據(jù)整理應(yīng)用3.1 將 FlexGen 接入 HELMFlexGen 可以作為 HELM 的執(zhí)行后端。README 給出的 MMLU 場景示例命令可在單塊 T416GB 200GB DRAM 上運行pip install crfm-helm python3 -m flexgen.apps.helm_run --description mmlu:modeltext,subjectabstract_algebra,data_augmentationcanonical --pad-to-seq-len 512 --model facebook/opt-30b --percent 20 80 0 100 0 100 --gpu-batch-size 48 --num-gpu-batches 3 --max-eval-instance 100實現(xiàn)側(cè)flexgen/apps/helm_run.py 中的execute會構(gòu)造ExecutionEnv與Policy將 HELM 請求按effective_bs分批get_batches先用 tokenizer 把 prompt 填充到pad_to_seq_len再按 batch_size 切分helm_run.py。README 提醒僅測試了部分 HELM 場景已測試場景清單見 flexgen/apps/helm_passed_30b.sh。3.2 數(shù)據(jù)整理Data Wrangling任務(wù)論文的姊妹工作《Can Foundation Models Wrangle Your Data?》中的示例可以直接復(fù)現(xiàn)操作說明位于 flexgen/apps/data_wrangle。該目錄下 data_wrangle_run.py 同時提供single_query_test與batch_query_test兩種模式分別對應(yīng)單條查詢與批量查詢測試腳本如 test_batch_query_all_opt30b.sh正是吞吐優(yōu)先場景的典型落地。四、API 使用Hugging Face 風(fēng)格的生成接口4.1 生成 APIFlexGen 提供仿 Hugging Face transformers 風(fēng)格的生成 API核心簽名見 completion.pyoutput_ids model.generate( input_ids, do_sampleTrue, temperature0.7, max_new_tokens32, stopstop)底層OptLM.generate支持debug_mode、cut_gen_len截斷生成長度用于快速調(diào)試等參數(shù)并內(nèi)置 normal / overlap 兩類生成循環(huán)generation_loop_normal、generation_loop_overlap_single_batch、generation_loop_overlap_multi_batch等見 flex_opt.py 中的方法定義。4.2 示例命令完整 OPT-6.7B至少 15GB 顯存python3 -m flexgen.apps.completion --model facebook/opt-6.7b完整 OPT-30B約需 90GB CPU 內(nèi)存python3 -m flexgen.apps.completion --model facebook/opt-30b --percent 0 100 100 0 100 0指令微調(diào)的 OPT-IML-MAX-30B同樣約需 90GB CPU 內(nèi)存python3 -m flexgen.apps.completion --model facebook/opt-iml-max-30b --percent 0 100 100 0 100 0注意completion.py內(nèi)置了兩個示例 prompt奧運會地點問答、機(jī)場代碼抽取并在生成結(jié)束后調(diào)用env.close_copy_threads()關(guān)閉磁盤拷貝線程completion.py。五、性能數(shù)據(jù)與復(fù)現(xiàn)方法5.1 生成吞吐對比表README Performance Results 中的對比表括號內(nèi)為有效批大小及其最低卸載層級硬件為 GCP 上 T4 16GB 208GB DRAM 1.5TB SSDworkload 為 input512 / output32批大小按各系統(tǒng)最大吞吐調(diào)優(yōu)吞吐定義為 生成 token 數(shù) ÷prompt 處理時間 生成時間系統(tǒng)OPT-6.7BOPT-30BOPT-175BHugging Face Accelerate25.12 (2 on GPU)0.62 (8 on CPU)0.01 (2 on disk)DeepSpeed ZeRO-Inference9.28 (16 on CPU)0.60 (4 on CPU)0.01 (1 on disk)Petals8.25 (2 on GPU)2.84 (2 on GPU)0.08 (2 on GPU)FlexGen25.26 (2 on GPU)7.32 (144 on CPU)0.69 (256 on disk)FlexGen with Compression29.12(72 on GPU)8.38(512 on CPU)1.12(144 on CPU)對應(yīng)的有效批大小表與 Petals 基線說明見 benchmark/batch_size_table.md。完整復(fù)現(xiàn)方法含 1x1 / 1x4 / 4x1 等多種拓?fù)涞?shell 腳本與 bench_suite.py 自動化套件見 benchmark/flexgen/README.md。從 bench_suite.py 可以直觀看到壓縮帶來的批大小提升30B 無壓縮時--gpu-batch-size 48 --num-gpu-batches 3有效批 144而啟用--compress-cache后達(dá)到--gpu-batch-size 64 --num-gpu-batches 8有效批 512——與 README 表中數(shù)字一一對應(yīng)。175B 壓縮配置則采用--percent 0 100 0 100 0 100 --compress-weight --compress-cache的全 CPU策略配合--pin-weight 0以緩解內(nèi)存壓力。5.2 延遲-吞吐權(quán)衡Pareto 前沿README 中docs/throughput_vs_latency.jpg查看圖片展示了三個基于卸載的系統(tǒng)在 OPT-175B左與 OPT-30B右上的延遲-吞吐曲線FlexGen 達(dá)成新的 Pareto 最優(yōu)前沿最大吞吐顯著更高而其他系統(tǒng)因內(nèi)存不足無法繼續(xù)增大批大小圖中 FlexGen(c) 即啟用壓縮的 FlexGen。六、工作原理批調(diào)度、I/O 重疊與策略搜索6.1 吞吐視角下的延遲-吞吐權(quán)衡FlexGen 的關(guān)鍵洞見是主動利用延遲-吞吐權(quán)衡卸載方案天生難以實現(xiàn)低延遲但在吞吐優(yōu)先場景下卸載的 I/O 效率可以被大幅提升。具體手段是block schedule塊調(diào)度按塊復(fù)用權(quán)重、把 I/O 與計算重疊overlap而基線系統(tǒng)普遍采用低效的逐行row-by-row調(diào)度。README 用 docs/block_schedule.jpg 直觀對比了兩種調(diào)度方式a 為基線逐行、b 為 FlexGen 塊調(diào)度。這一思想在源碼中落地為Policy的overlap字段默認(rèn) True見 flex_opt.py以及OptLM的三套生成循環(huán)generation_loop_overlap_single_batch與generation_loop_overlap_multi_batch專門負(fù)責(zé)在多 GPU batch 之間交錯加載權(quán)重與計算從而隱藏磁盤/CPU 加載延遲。benchmark 套件中常見--overlap False的對照實驗bench_suite.py便于量化重疊帶來的收益。6.2 線性規(guī)劃策略優(yōu)化器與成本模型論文所述通過線性規(guī)劃優(yōu)化器搜索張量存儲與訪問的最優(yōu)模式對應(yīng)倉庫 experimental/cost_model.py。它基于pulp線性規(guī)劃庫實現(xiàn)典型用法# 1. 在給定硬件約束下自動搜索最優(yōu)策略 python cost_model.py --model facebook/opt-30b --prompt-len 512 --gen-len 32 \ --gpu-mem 16 --cpu-mem 200 --nvme-mem 1500 # 2. 估算給定策略的吞吐 python cost_model.py --model facebook/opt-30b --prompt-len 512 --gen-len 32 \ --gpu-mem 16 --cpu-mem 200 --nvme-mem 1500 \ --gpu-batch-size 48 --num-gpu-batches 3 \ --percent 20 80 0 100 0 100 \ --alpha-g 1.2 --alpha-c 1.2 --alpha-n 1.2文件頭部注釋明確給出了使用須知cost_model.py硬件常數(shù)CostModelConfig需要針對自己的設(shè)備重新擬合作者通過采集真實運行數(shù)據(jù)點用梯度下降擬合直接 profile 單個算子或從網(wǎng)絡(luò)抄數(shù)都不準(zhǔn)確alpha_g/alpha_c/alpha_n是峰值內(nèi)存估計的松弛系數(shù)調(diào)小策略偏保守、調(diào)大偏激進(jìn)當(dāng)前模型不考慮 CPU 計算委托且量化支持不完整。README 的 Roadmap 也標(biāo)注Release the cost model and policy optimizer為已完成項[X]。6.3 4-bit 分組量化權(quán)重與 KV cache 雙壓縮壓縮由 flexgen/compression.py 實現(xiàn)核心是CompressionConfig分組量化配置與TorchCompressedDevice壓縮張量管理設(shè)備。運行時通過兩個開關(guān)開啟--compress-weight # 壓縮權(quán)重約省 70% 權(quán)重內(nèi)存 --compress-cache # 壓縮 KV cache兩者默認(rèn)的分組量化配置flex_opt.py為權(quán)重CompressionConfig(num_bits4, group_size64, group_dim0, symmetricFalse)cacheCompressionConfig(num_bits4, group_size64, group_dim2, symmetricFalse)從 compression.py 的實現(xiàn)可以看到壓縮存儲的具體形態(tài)4-bit 數(shù)據(jù)按group_size64分組data張量按每 2 個 4-bit 值打包成 1 個 uint8的方式存放data_shape shape[:group_dim] (num_groups * (group_size // 2),) ...并附帶一個 fp16 的scale張量記錄每組縮放因子。compress/decompress函數(shù)完成實際量化與反量化cache 壓縮時還會在 CPU 上分配 fp32 反量化工作區(qū)init_attention_compute_workspace見 compression.py。README 提示權(quán)重壓縮大約可減少 70% 的權(quán)重內(nèi)存且論文報告壓縮后精度損失可忽略negligible。6.4 執(zhí)行環(huán)境與內(nèi)存層級抽象FlexGen 把硬件抽象為統(tǒng)一的內(nèi)存層級utils.py 的ExecutionEnv pytorch_backend.py 中的TorchDevice/TorchDisk/TorchMixedDevicegpu TorchDevice(cuda:0) cpu TorchDevice(cpu) disk TorchDisk(args.offload_dir) env ExecutionEnv(gpugpu, cpucpu, diskdisk, mixedTorchMixedDevice([gpu, cpu, disk]))權(quán)重按Policy的百分比切分后分別allocate在 disk/cpu/gpu 上init_weight_list推理時通過load_weight/load_cache/store_cache在層級間搬運磁盤側(cè)使用多線程拷貝TorchDisk默認(rèn) 4 個拷貝線程隱藏 I/O 延遲。--pin-weight 0可關(guān)閉 CPU 端權(quán)重頁鎖定pinned memory約減少 20% 以上的 CPU 權(quán)重內(nèi)存占用README FAQ代價是拷貝稍慢。6.5 分布式擴(kuò)展卸載 流水線并行當(dāng)多機(jī)多卡但聚合顯存仍小于模型大小時FlexGen 可把卸載與流水線并行pipeline parallelism結(jié)合DistOptLMdist_flex_opt.py繼承OptLM引入pipeline_rank/num_pipeline_stages/comm_device等參數(shù)并通過send_hidden/recv_hidden在流水線階段間傳遞激活。README 提示要獲得可擴(kuò)展的性能GPU 應(yīng)分布在多臺機(jī)器上同機(jī)多卡性能優(yōu)化仍在其 Roadmap 中列為未完成項。分布式 benchmark 腳本見 benchmark/flexgen/bench_dist_single_node.sh 與 benchmark/flexgen/bench_dist_multi_node.sh。七、FAQ策略調(diào)參與內(nèi)存不足排查7.1 如何設(shè)置卸載策略--percentREADME 明確說明目前需要手工嘗試若干策略自動策略優(yōu)化器已隨 cost model 發(fā)布但調(diào)優(yōu)仍需人工?？傮w原則是盡可能把參數(shù)與注意力 cache 卸載到 CPU、必要時到磁盤從而把顯存讓給更大的批大小?？芍苯訁⒖?bench_suite.py 中的基準(zhǔn)參考策略。出現(xiàn) OOM 時把--percent中對應(yīng)項調(diào)向 CPU/磁盤方向即可卸載更多張量。7.2 內(nèi)存不足OOM時怎么辦README FAQ 給出三條由省內(nèi)存 → 更慢排序的應(yīng)急手段不鎖定權(quán)重加--pin-weight 0CPU 權(quán)重內(nèi)存約省 20% 以上壓縮權(quán)重加--compress-weight權(quán)重內(nèi)存約省 70%權(quán)重全部落盤--percent 0 0 100 0 100 0配合--offload-dir幾乎不占 CPU 與 GPU 內(nèi)存。更進(jìn)階的排查可借助profile_bandwidth.pyflexgen/profile_bandwidth.py測磁盤與 PCIe 帶寬與profile_matmul.pyflexgen/profile_matmul.py測矩陣乘性能先行刻畫本機(jī)硬件常數(shù)再用 cost_model.py 預(yù)估各策略的吞吐減少盲目試參。八、結(jié)語與路線圖FlexGen 證明了一條弱硬件 極致 I/O 調(diào)度 壓縮 大批量的可行路徑在 16GB 單卡上首次達(dá)到 OPT-175B 的 1 token/s 生成吞吐并把 HELM 30B 跑分壓縮到 21 小時。它明確面向吞吐優(yōu)先的批量場景代價是小批量/低延遲場景不具優(yōu)勢。README Roadmap 顯示其后續(xù)計劃包括優(yōu)化同機(jī)多卡性能、支持更多模型BLOOM、CodeGen、GLM、MacbookM1/M2與 AMD 支持。論文全文出處為 docs/paper.md 所收錄的 arXiv 論文《High-throughput Generative Inference of Large Language Models with a Single GPU》arXiv:2303.06865作者包括 Ying Sheng、Lianmin Zheng 等Subj 分類為 cs.LG / cs.AI / cs.PF。贊分享推理引擎大模型【免費下載鏈接】FlexGenRunning large language models on a single GPU for throughput-oriented scenarios.項目地址https://gitcode.com/gh_mirrors/fl/FlexGen點擊查看免費下載相關(guān)推薦推薦文章FlexGen——單GPU下大型語言模型高吞吐量推理的新引擎推薦文章FlexGen——單GPU下大型語言模型高吞吐量推理的新引擎 在當(dāng)今人工智能的快速發(fā)展中大型語言模型LLMs正以前所未有的方式重塑我們對信息處理推理引擎大模型FlexGen 單 GPU 高吞吐大語言模型推理引擎從安裝、Offloading 策略到 HELM 與數(shù)據(jù)整理實戰(zhàn)FlexGen 單 GPU 高吞吐大語言模型推理引擎從安裝、Offloading 策略到 HELM 與數(shù)據(jù)整理實戰(zhàn) FlexGen 是一個面向吞吐優(yōu)先th推理引擎大模型FlexGen 基準(zhǔn)測試實戰(zhàn)指南單 GPU 與多機(jī)多卡 OPT 模型吞吐量測試全解析FlexGen 基準(zhǔn)測試實戰(zhàn)指南單 GPU 與多機(jī)多卡 OPT 模型吞吐量測試全解析 本篇技術(shù)指南圍繞 FlexGen 官方基準(zhǔn)測試方案 benchmark推理引擎大模型上一篇終極指南如何使用 cmp-buffer 插件提升 Neovim 代碼補(bǔ)全效率下一篇OpenVEX 漏洞披露數(shù)據(jù)管理指南以 minikube 倉庫 .openvex 模板目錄與 vexctl 發(fā)布集成為例創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 FlexGen 單 GPU 高吞吐大模型推理引擎：論文解讀與源碼實戰(zhàn)指南
推理引擎大模型【免費下載鏈接】FlexGenRunning large language models on a single GPU for throughput-oriented scenarios.項目地址https://gitcode.com/gh_mirrors/fl/FlexGen點擊查看免費下載本文以 FlexGen 倉庫中收錄的論文《High-throughput Generative Inference of Large Language Models with a Single GPU》為核心骨架結(jié)合倉庫源碼flexgen/flex_opt.py、flexgen/compression.py、experimental/cost_model.py 等展開解讀。通過本文你將理解 FlexGen 如何在單塊普通 GPU如 16GB T4上通過 GPU/CPU/磁盤三級異構(gòu)聚合、線性規(guī)劃策略搜索與 4-bit 分組量化將 OPT-175B 級別的模型吞吐推升至 1 token/s 以上并掌握--percent卸載策略、壓縮開關(guān)、HELM 基準(zhǔn)接入與分布式擴(kuò)展的完整實操方法。FlexGen 的定位是面向吞吐優(yōu)先throughput-oriented場景的生成引擎這類任務(wù)批量評測、信息抽取、數(shù)據(jù)整理、表單處理需要以批處理方式在數(shù)百萬 token 上反復(fù)運行 LLM對單次延遲不敏感但對整段運行時間的 token 吞吐率極為敏感。其核心思想是用 I/O 效率換延遲在低成本單 GPU 硬件上把批大小做到傳統(tǒng)方案無法企及的規(guī)模從而顯著提升最大吞吐。倉庫 README 同時明確列出了其局限性作為基于卸載offloading的系統(tǒng)在弱 GPU 上、尤其是小批量場景下其速度仍遠(yuǎn)低于擁有足夠強(qiáng) GPU 將整個模型駐留顯存的方案因此它主要針對單 GPU 上的批量處理設(shè)置優(yōu)化。一、論文核心貢獻(xiàn)為什么單卡能跑 175B 模型1.1 問題背景LLM 推理的資源門檻論文摘要指出大語言模型推理的傳統(tǒng)路徑需要多塊高端加速器才能可行。而現(xiàn)實中出現(xiàn)了一批延遲不敏感l(wèi)atency-insensitive的批量處理任務(wù)公司內(nèi)部全部私有文檔的分類與抽取、HELM 基準(zhǔn)上全部任務(wù)的跑分等。這類工作負(fù)載允許晚上提交作業(yè)、隔夜跑完的運行方式代價是吞吐率直接決定成本——吞吐被定義為任務(wù)整個運行時間可達(dá)數(shù)小時內(nèi)每秒處理的 token 數(shù)。這種特性使得用延遲換吞吐成為可行策略也讓低成本的普通商用 GPU 有了用武之地。1.2 三大關(guān)鍵技術(shù)FlexGen 應(yīng)對資源約束的三大手段README How It Works 一節(jié)與論文摘要一致異構(gòu)資源聚合GPU CPU Disk在不同硬件資源約束下靈活配置把權(quán)重、激活、注意力 KV cache 分散存放在 GPU 顯存、CPU 內(nèi)存與磁盤上按需加載計算線性規(guī)劃LP策略優(yōu)化器通過線性規(guī)劃自動搜索張量存哪里、何時訪問的最優(yōu)模式在給定硬件GPU/CPU/磁盤容量與帶寬約束下最大化吞吐4-bit 分組量化壓縮對權(quán)重與注意力 KV cache 均壓縮到 4 bit精度損失可忽略negligible從而把可容納的批大小上限大幅抬升。1.3 代表性結(jié)果以論文/README 為準(zhǔn)論文摘要給出了兩個標(biāo)志性結(jié)論均基于 GCP 上單塊 NVIDIA T416GB實例、208GB DRAM、1.5TB SSD 的環(huán)境input seq len512output seq len32批大小調(diào)至各系統(tǒng)最大吞吐值運行 OPT-175B 時FlexGen首次在單 16GB GPU 上達(dá)到 1 token/s 的生成吞吐有效批大小 144配合壓縮后的數(shù)字見下文性能表在 HELM 基準(zhǔn)上FlexGen 用 16GB GPU 在 21 小時內(nèi)完成了 30B 模型在 7 個代表性子場景下的跑分。二、上手實測從 OPT-1.3B 到 OPT-175B2.1 安裝倉庫 README 給出兩種安裝方式唯一硬性要求是PyTorch 1.12# 方式一pip 安裝 pip install flexgen # 方式二源碼安裝 git clone https://github.com/FMInference/FlexGen.git cd FlexGen pip install -e .2.2 OPT-1.3B無卸載快速體驗小模型可直接放進(jìn)單 GPU無需卸載。FlexGen 會自動從 Hugging Face 下載權(quán)重python3 -m flexgen.flex_opt --model facebook/opt-1.3b運行后會看到 OPT-1.3B 生成的文本以及 benchmark 結(jié)果prefill/decode 延遲與吞吐見 flex_opt.py 的日志邏輯。2.3 OPT-30B引入 CPU 卸載與--percentpython3 -m flexgen.flex_opt --model facebook/opt-30b --percent 0 100 100 0 100 0--percent是 FlexGen 最核心的參數(shù)。它接收 6 個整數(shù)依次表示源碼注釋原文見 flex_opt.py位置含義默認(rèn)值1權(quán)重放在 GPU 的百分比1002權(quán)重放在 CPU 的百分比03注意力 cache 放在 GPU 的百分比1004注意力 cache 放在 CPU 的百分比05激活activations放在 GPU 的百分比1006激活放在 CPU 的百分比0每一類的磁盤百分比是隱含的第三項由Policy屬性計算得出flex_opt.pyproperty def w_disk_percent(self): # 權(quán)重磁盤占比 return 100 - self.w_gpu_percent - self.w_cpu_percent property def cache_disk_percent(self): # cache 磁盤占比 return 100 - self.cache_gpu_percent - self.cache_cpu_percent property def act_disk_percent(self): # 激活磁盤占比 return 100 - self.act_gpu_percent - self.act_cpu_percent實際分配時init_weight_list會按張量體積的累計分布cumsum把不同權(quán)重切成三段分別落到磁盤、CPU、GPUflex_opt.py。因此--percent 0 100 100 0 100 0的含義是權(quán)重全部放 CPU、cache 與激活全部放 GPU——這是 30B 在 16GB 顯卡上的典型起點。參考策略可見 benchmark/flexgen/bench_suite.py30B 無壓縮時通常采用--percent 20 80 0 100 0 100或--percent 10 90 0 100 0 100約 10%~20% 權(quán)重駐留 GPU其余在 CPU并搭配--gpu-batch-size 48 --num-gpu-batches 3之類的分批參數(shù)。2.4 OPT-175B全量卸載到磁盤OPT-175B 需要先從 metaseq 項目下載權(quán)重并按 Alpa 格式轉(zhuǎn)換然后可將全部權(quán)重卸載到 SSDpython3 -m flexgen.flex_opt --model facebook/opt-175b --percent 0 0 100 0 100 0 --offload-dir YOUR_SSD_FOLDER--offload-dir默認(rèn)值為~/flexgen_offload_dirflex_opt.py用于存放卸載到磁盤的張量。三、吞吐優(yōu)先場景HELM 基準(zhǔn)與數(shù)據(jù)整理應(yīng)用3.1 將 FlexGen 接入 HELMFlexGen 可以作為 HELM 的執(zhí)行后端。README 給出的 MMLU 場景示例命令可在單塊 T416GB 200GB DRAM 上運行pip install crfm-helm python3 -m flexgen.apps.helm_run --description mmlu:modeltext,subjectabstract_algebra,data_augmentationcanonical --pad-to-seq-len 512 --model facebook/opt-30b --percent 20 80 0 100 0 100 --gpu-batch-size 48 --num-gpu-batches 3 --max-eval-instance 100實現(xiàn)側(cè)flexgen/apps/helm_run.py 中的execute會構(gòu)造ExecutionEnv與Policy將 HELM 請求按effective_bs分批get_batches先用 tokenizer 把 prompt 填充到pad_to_seq_len再按 batch_size 切分helm_run.py。README 提醒僅測試了部分 HELM 場景已測試場景清單見 flexgen/apps/helm_passed_30b.sh。3.2 數(shù)據(jù)整理Data Wrangling任務(wù)論文的姊妹工作《Can Foundation Models Wrangle Your Data?》中的示例可以直接復(fù)現(xiàn)操作說明位于 flexgen/apps/data_wrangle。該目錄下 data_wrangle_run.py 同時提供single_query_test與batch_query_test兩種模式分別對應(yīng)單條查詢與批量查詢測試腳本如 test_batch_query_all_opt30b.sh正是吞吐優(yōu)先場景的典型落地。四、API 使用Hugging Face 風(fēng)格的生成接口4.1 生成 APIFlexGen 提供仿 Hugging Face transformers 風(fēng)格的生成 API核心簽名見 completion.pyoutput_ids model.generate( input_ids, do_sampleTrue, temperature0.7, max_new_tokens32, stopstop)底層OptLM.generate支持debug_mode、cut_gen_len截斷生成長度用于快速調(diào)試等參數(shù)并內(nèi)置 normal / overlap 兩類生成循環(huán)generation_loop_normal、generation_loop_overlap_single_batch、generation_loop_overlap_multi_batch等見 flex_opt.py 中的方法定義。4.2 示例命令完整 OPT-6.7B至少 15GB 顯存python3 -m flexgen.apps.completion --model facebook/opt-6.7b完整 OPT-30B約需 90GB CPU 內(nèi)存python3 -m flexgen.apps.completion --model facebook/opt-30b --percent 0 100 100 0 100 0指令微調(diào)的 OPT-IML-MAX-30B同樣約需 90GB CPU 內(nèi)存python3 -m flexgen.apps.completion --model facebook/opt-iml-max-30b --percent 0 100 100 0 100 0注意completion.py內(nèi)置了兩個示例 prompt奧運會地點問答、機(jī)場代碼抽取并在生成結(jié)束后調(diào)用env.close_copy_threads()關(guān)閉磁盤拷貝線程completion.py。五、性能數(shù)據(jù)與復(fù)現(xiàn)方法5.1 生成吞吐對比表README Performance Results 中的對比表括號內(nèi)為有效批大小及其最低卸載層級硬件為 GCP 上 T4 16GB 208GB DRAM 1.5TB SSDworkload 為 input512 / output32批大小按各系統(tǒng)最大吞吐調(diào)優(yōu)吞吐定義為 生成 token 數(shù) ÷prompt 處理時間 生成時間系統(tǒng)OPT-6.7BOPT-30BOPT-175BHugging Face Accelerate25.12 (2 on GPU)0.62 (8 on CPU)0.01 (2 on disk)DeepSpeed ZeRO-Inference9.28 (16 on CPU)0.60 (4 on CPU)0.01 (1 on disk)Petals8.25 (2 on GPU)2.84 (2 on GPU)0.08 (2 on GPU)FlexGen25.26 (2 on GPU)7.32 (144 on CPU)0.69 (256 on disk)FlexGen with Compression29.12(72 on GPU)8.38(512 on CPU)1.12(144 on CPU)對應(yīng)的有效批大小表與 Petals 基線說明見 benchmark/batch_size_table.md。完整復(fù)現(xiàn)方法含 1x1 / 1x4 / 4x1 等多種拓?fù)涞?shell 腳本與 bench_suite.py 自動化套件見 benchmark/flexgen/README.md。從 bench_suite.py 可以直觀看到壓縮帶來的批大小提升30B 無壓縮時--gpu-batch-size 48 --num-gpu-batches 3有效批 144而啟用--compress-cache后達(dá)到--gpu-batch-size 64 --num-gpu-batches 8有效批 512——與 README 表中數(shù)字一一對應(yīng)。175B 壓縮配置則采用--percent 0 100 0 100 0 100 --compress-weight --compress-cache的全 CPU策略配合--pin-weight 0以緩解內(nèi)存壓力。5.2 延遲-吞吐權(quán)衡Pareto 前沿README 中docs/throughput_vs_latency.jpg查看圖片展示了三個基于卸載的系統(tǒng)在 OPT-175B左與 OPT-30B右上的延遲-吞吐曲線FlexGen 達(dá)成新的 Pareto 最優(yōu)前沿最大吞吐顯著更高而其他系統(tǒng)因內(nèi)存不足無法繼續(xù)增大批大小圖中 FlexGen(c) 即啟用壓縮的 FlexGen。六、工作原理批調(diào)度、I/O 重疊與策略搜索6.1 吞吐視角下的延遲-吞吐權(quán)衡FlexGen 的關(guān)鍵洞見是主動利用延遲-吞吐權(quán)衡卸載方案天生難以實現(xiàn)低延遲但在吞吐優(yōu)先場景下卸載的 I/O 效率可以被大幅提升。具體手段是block schedule塊調(diào)度按塊復(fù)用權(quán)重、把 I/O 與計算重疊overlap而基線系統(tǒng)普遍采用低效的逐行row-by-row調(diào)度。README 用 docs/block_schedule.jpg 直觀對比了兩種調(diào)度方式a 為基線逐行、b 為 FlexGen 塊調(diào)度。這一思想在源碼中落地為Policy的overlap字段默認(rèn) True見 flex_opt.py以及OptLM的三套生成循環(huán)generation_loop_overlap_single_batch與generation_loop_overlap_multi_batch專門負(fù)責(zé)在多 GPU batch 之間交錯加載權(quán)重與計算從而隱藏磁盤/CPU 加載延遲。benchmark 套件中常見--overlap False的對照實驗bench_suite.py便于量化重疊帶來的收益。6.2 線性規(guī)劃策略優(yōu)化器與成本模型論文所述通過線性規(guī)劃優(yōu)化器搜索張量存儲與訪問的最優(yōu)模式對應(yīng)倉庫 experimental/cost_model.py。它基于pulp線性規(guī)劃庫實現(xiàn)典型用法# 1. 在給定硬件約束下自動搜索最優(yōu)策略 python cost_model.py --model facebook/opt-30b --prompt-len 512 --gen-len 32 \ --gpu-mem 16 --cpu-mem 200 --nvme-mem 1500 # 2. 估算給定策略的吞吐 python cost_model.py --model facebook/opt-30b --prompt-len 512 --gen-len 32 \ --gpu-mem 16 --cpu-mem 200 --nvme-mem 1500 \ --gpu-batch-size 48 --num-gpu-batches 3 \ --percent 20 80 0 100 0 100 \ --alpha-g 1.2 --alpha-c 1.2 --alpha-n 1.2文件頭部注釋明確給出了使用須知cost_model.py硬件常數(shù)CostModelConfig需要針對自己的設(shè)備重新擬合作者通過采集真實運行數(shù)據(jù)點用梯度下降擬合直接 profile 單個算子或從網(wǎng)絡(luò)抄數(shù)都不準(zhǔn)確alpha_g/alpha_c/alpha_n是峰值內(nèi)存估計的松弛系數(shù)調(diào)小策略偏保守、調(diào)大偏激進(jìn)當(dāng)前模型不考慮 CPU 計算委托且量化支持不完整。README 的 Roadmap 也標(biāo)注Release the cost model and policy optimizer為已完成項[X]。6.3 4-bit 分組量化權(quán)重與 KV cache 雙壓縮壓縮由 flexgen/compression.py 實現(xiàn)核心是CompressionConfig分組量化配置與TorchCompressedDevice壓縮張量管理設(shè)備。運行時通過兩個開關(guān)開啟--compress-weight # 壓縮權(quán)重約省 70% 權(quán)重內(nèi)存 --compress-cache # 壓縮 KV cache兩者默認(rèn)的分組量化配置flex_opt.py為權(quán)重CompressionConfig(num_bits4, group_size64, group_dim0, symmetricFalse)cacheCompressionConfig(num_bits4, group_size64, group_dim2, symmetricFalse)從 compression.py 的實現(xiàn)可以看到壓縮存儲的具體形態(tài)4-bit 數(shù)據(jù)按group_size64分組data張量按每 2 個 4-bit 值打包成 1 個 uint8的方式存放data_shape shape[:group_dim] (num_groups * (group_size // 2),) ...并附帶一個 fp16 的scale張量記錄每組縮放因子。compress/decompress函數(shù)完成實際量化與反量化cache 壓縮時還會在 CPU 上分配 fp32 反量化工作區(qū)init_attention_compute_workspace見 compression.py。README 提示權(quán)重壓縮大約可減少 70% 的權(quán)重內(nèi)存且論文報告壓縮后精度損失可忽略negligible。6.4 執(zhí)行環(huán)境與內(nèi)存層級抽象FlexGen 把硬件抽象為統(tǒng)一的內(nèi)存層級utils.py 的ExecutionEnv pytorch_backend.py 中的TorchDevice/TorchDisk/TorchMixedDevicegpu TorchDevice(cuda:0) cpu TorchDevice(cpu) disk TorchDisk(args.offload_dir) env ExecutionEnv(gpugpu, cpucpu, diskdisk, mixedTorchMixedDevice([gpu, cpu, disk]))權(quán)重按Policy的百分比切分后分別allocate在 disk/cpu/gpu 上init_weight_list推理時通過load_weight/load_cache/store_cache在層級間搬運磁盤側(cè)使用多線程拷貝TorchDisk默認(rèn) 4 個拷貝線程隱藏 I/O 延遲。--pin-weight 0可關(guān)閉 CPU 端權(quán)重頁鎖定pinned memory約減少 20% 以上的 CPU 權(quán)重內(nèi)存占用README FAQ代價是拷貝稍慢。6.5 分布式擴(kuò)展卸載 流水線并行當(dāng)多機(jī)多卡但聚合顯存仍小于模型大小時FlexGen 可把卸載與流水線并行pipeline parallelism結(jié)合DistOptLMdist_flex_opt.py繼承OptLM引入pipeline_rank/num_pipeline_stages/comm_device等參數(shù)并通過send_hidden/recv_hidden在流水線階段間傳遞激活。README 提示要獲得可擴(kuò)展的性能GPU 應(yīng)分布在多臺機(jī)器上同機(jī)多卡性能優(yōu)化仍在其 Roadmap 中列為未完成項。分布式 benchmark 腳本見 benchmark/flexgen/bench_dist_single_node.sh 與 benchmark/flexgen/bench_dist_multi_node.sh。七、FAQ策略調(diào)參與內(nèi)存不足排查7.1 如何設(shè)置卸載策略--percentREADME 明確說明目前需要手工嘗試若干策略自動策略優(yōu)化器已隨 cost model 發(fā)布但調(diào)優(yōu)仍需人工?？傮w原則是盡可能把參數(shù)與注意力 cache 卸載到 CPU、必要時到磁盤從而把顯存讓給更大的批大小?？芍苯訁⒖?bench_suite.py 中的基準(zhǔn)參考策略。出現(xiàn) OOM 時把--percent中對應(yīng)項調(diào)向 CPU/磁盤方向即可卸載更多張量。7.2 內(nèi)存不足OOM時怎么辦README FAQ 給出三條由省內(nèi)存 → 更慢排序的應(yīng)急手段不鎖定權(quán)重加--pin-weight 0CPU 權(quán)重內(nèi)存約省 20% 以上壓縮權(quán)重加--compress-weight權(quán)重內(nèi)存約省 70%權(quán)重全部落盤--percent 0 0 100 0 100 0配合--offload-dir幾乎不占 CPU 與 GPU 內(nèi)存。更進(jìn)階的排查可借助profile_bandwidth.pyflexgen/profile_bandwidth.py測磁盤與 PCIe 帶寬與profile_matmul.pyflexgen/profile_matmul.py測矩陣乘性能先行刻畫本機(jī)硬件常數(shù)再用 cost_model.py 預(yù)估各策略的吞吐減少盲目試參。八、結(jié)語與路線圖FlexGen 證明了一條弱硬件 極致 I/O 調(diào)度 壓縮 大批量的可行路徑在 16GB 單卡上首次達(dá)到 OPT-175B 的 1 token/s 生成吞吐并把 HELM 30B 跑分壓縮到 21 小時。它明確面向吞吐優(yōu)先的批量場景代價是小批量/低延遲場景不具優(yōu)勢。README Roadmap 顯示其后續(xù)計劃包括優(yōu)化同機(jī)多卡性能、支持更多模型BLOOM、CodeGen、GLM、MacbookM1/M2與 AMD 支持。論文全文出處為 docs/paper.md 所收錄的 arXiv 論文《High-throughput Generative Inference of Large Language Models with a Single GPU》arXiv:2303.06865作者包括 Ying Sheng、Lianmin Zheng 等Subj 分類為 cs.LG / cs.AI / cs.PF。贊分享推理引擎大模型【免費下載鏈接】FlexGenRunning large language models on a single GPU for throughput-oriented scenarios.項目地址https://gitcode.com/gh_mirrors/fl/FlexGen點擊查看免費下載相關(guān)推薦推薦文章FlexGen——單GPU下大型語言模型高吞吐量推理的新引擎推薦文章FlexGen——單GPU下大型語言模型高吞吐量推理的新引擎 在當(dāng)今人工智能的快速發(fā)展中大型語言模型LLMs正以前所未有的方式重塑我們對信息處理推理引擎大模型FlexGen 單 GPU 高吞吐大語言模型推理引擎從安裝、Offloading 策略到 HELM 與數(shù)據(jù)整理實戰(zhàn)FlexGen 單 GPU 高吞吐大語言模型推理引擎從安裝、Offloading 策略到 HELM 與數(shù)據(jù)整理實戰(zhàn) FlexGen 是一個面向吞吐優(yōu)先th推理引擎大模型FlexGen 基準(zhǔn)測試實戰(zhàn)指南單 GPU 與多機(jī)多卡 OPT 模型吞吐量測試全解析FlexGen 基準(zhǔn)測試實戰(zhàn)指南單 GPU 與多機(jī)多卡 OPT 模型吞吐量測試全解析 本篇技術(shù)指南圍繞 FlexGen 官方基準(zhǔn)測試方案 benchmark推理引擎大模型上一篇終極指南如何使用 cmp-buffer 插件提升 Neovim 代碼補(bǔ)全效率下一篇OpenVEX 漏洞披露數(shù)據(jù)管理指南以 minikube 倉庫 .openvex 模板目錄與 vexctl 發(fā)布集成為例創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考