Robert Corwin，Austin人工智能公司首席執(zhí)行官
David Davalos， Austin人工智能機(jī)器學(xué)習(xí)工程師
2024年10月24日
大型語言模型（LLM）已經(jīng)深刻地變革了技術(shù)領(lǐng)域，但數(shù)據(jù)安全問題依然嚴(yán)峻，尤其是在將敏感信息發(fā)送到第三方服務(wù)器時(shí)。在本文中，我們將探討如何在本地、私有環(huán)境（即個(gè)人計(jì)算機(jī)）中部署LLM模型，例如Llama模型。我們?cè)诒镜剡\(yùn)行了Llama 3.1，并分析了不同版本和框架的速度、功耗和整體性能，提供詳細(xì)的評(píng)測(cè)。不論是技術(shù)專家還是好奇的讀者，都能在本文中獲得關(guān)于本地LLM部署的見解。對(duì)于簡(jiǎn)要概述，非技術(shù)讀者可以參閱我們的匯總表；而技術(shù)讀者可進(jìn)一步了解具體工具和性能評(píng)測(cè)。
除非另有說明，所有圖片均由作者提供。作者和他們的雇主Austin Artificial Intelligence與本文中使用或提到的任何工具都沒有任何關(guān)系。
要點(diǎn)
LLM本地運(yùn)行：可以下載LLM模型，使用社區(qū)中廣泛的工具和框架在私有服務(wù)器上本地運(yùn)行。雖然最強(qiáng)大的模型需要昂貴的硬件，但小型模型可以在筆記本電腦或臺(tái)式機(jī)上順暢運(yùn)行。
隱私與定制性：本地運(yùn)行LLM不僅提升隱私保護(hù)，還增強(qiáng)了模型設(shè)置與使用策略的控制權(quán)。
模型規(guī)模：開源Llama模型有不同的規(guī)模，如Llama 3.1 提供了80億、700億和4050億參數(shù)版本。參數(shù)數(shù)量越多，模型性能越強(qiáng)，但同時(shí)也需要更高的內(nèi)存和存儲(chǔ)需求。
量化：量化通過將參數(shù)“舍入”至更低的精度來減少內(nèi)存和磁盤空間，但可能影響模型的精度。對(duì)于含有大量參數(shù)的LLM，量化在降低內(nèi)存使用和加快執(zhí)行速度方面至關(guān)重要。
成本效益：與云端解決方案相比，基于GPU的本地實(shí)現(xiàn)可以顯著節(jié)省成本。
在我們之前的文章中，探討了LLM的關(guān)鍵概念及其應(yīng)用，例如通過Langchain等框架創(chuàng)建個(gè)性化的聊天機(jī)器人或工具（見圖1）。這種架構(gòu)雖可采用合成數(shù)據(jù)或混淆數(shù)據(jù)的方法來保護(hù)隱私，但仍需要將數(shù)據(jù)傳輸至第三方，并且無法控制模型、策略或可用性方面的變化。一個(gè)有效的解決方案是在私有服務(wù)器上運(yùn)行LLM（見圖2）。此舉可以完全保障數(shù)據(jù)隱私，減少對(duì)外部服務(wù)商的依賴。
私有部署LLM需要考慮成本、功耗和處理速度。在我們的實(shí)驗(yàn)中，主要運(yùn)行的是Llama 3.1，測(cè)試其在不同量化級(jí)別與框架中的性能表現(xiàn)。這些權(quán)衡對(duì)于希望利用AI潛力并保持?jǐn)?shù)據(jù)與資源控制的用戶尤為重要。
圖1說明聊天機(jī)器人或工具的典型后端設(shè)置的圖表，其中ChatGPT（或類似模型）作為自然語言處理引擎。這種設(shè)置依賴于快速工程來定制響應(yīng)?！?/p>
圖2完全私有后端配置的示意圖，其中所有組件（包括大型語言模型）都托管在安全服務(wù)器上，確保完全控制和隱私。
量化和GGUF文件
在深入了解我們所探索的工具之前，讓我們首先討論量化和GGUF格式。
量化是一種通過將權(quán)重和偏差從高精度浮點(diǎn)值轉(zhuǎn)換為低精度表示來減小模型大小的技術(shù)。LLM從這種方法中受益匪淺，因?yàn)樗鼈冇写罅康膮?shù)。例如，最大版本的Llama3.1包含了驚人的4050億個(gè)參數(shù)。量化可以顯著減少內(nèi)存使用和執(zhí)行時(shí)間，使這些模型更有效地在各種設(shè)備上運(yùn)行。
GGUF格式用于存儲(chǔ)LLM模型，最近在分發(fā)和運(yùn)行量化模型方面得到了普及。它針對(duì)快速加載、讀取和保存進(jìn)行了優(yōu)化。與只使用張量的格式不同，GGUF還以標(biāo)準(zhǔn)化的方式存儲(chǔ)模型元數(shù)據(jù)，使框架更容易支持這種格式，甚至將其作為規(guī)范。
分析的工具和模型
我們探索了四種工具來本地運(yùn)行Llama模型：
Hugging Face的Transformers庫與Hub
vLLM
llama.cpp
Ollama
我們主要關(guān)注的是llama.cpp和Ollama，因?yàn)檫@些工具允許我們快速有效地部署模型。具體來說，我們探討了它們的速度、能源成本和整體性能。對(duì)于模型，我們主要分析了量化的8B和70B Llama 3.1版本，因?yàn)樗鼈冊(cè)诤侠淼臅r(shí)間范圍內(nèi)運(yùn)行。
HuggingFace
Hugging Face提供了一個(gè)豐富的模型和工具庫，使其成為開發(fā)者的熱門選擇。Transformers庫支持通過bitsandbytes進(jìn)行4位和8位量化，但直接使用變壓器庫加載量化模型在內(nèi)存占用上表現(xiàn)不佳。盡管如此，Hugging Face在文檔、社區(qū)支持和訓(xùn)練框架方面具有獨(dú)特優(yōu)勢(shì)。
vLLM
與hugs Face類似，vLLM可以通過正確配置的Python環(huán)境輕松安裝。然而，對(duì)GGUF文件的支持仍然是高度實(shí)驗(yàn)性的。雖然我們能夠快速設(shè)置它以運(yùn)行8B模型，但盡管有出色的文檔，但超出這個(gè)范圍的擴(kuò)展證明是具有挑戰(zhàn)性的。
總的來說，我們相信vLLM有很大的潛力。然而，我們最終選擇了llama.cpp和Ollama框架，因?yàn)樗鼈兙哂懈苯拥募嫒菪院托?。公平地說，本可以在這里進(jìn)行更徹底的調(diào)查，但考慮到我們?cè)谄渌麕熘邪l(fā)現(xiàn)的直接成功，我們選擇關(guān)注這些庫。
Ollama
我們發(fā)現(xiàn)Ollama非常棒。我們最初的印象是，它是一個(gè)用戶準(zhǔn)備好的工具，用于本地推斷Llama模型，具有開箱即用的易用性。Mac和Linux用戶安裝它很簡(jiǎn)單，Windows版本目前正在預(yù)覽中。Ollama自動(dòng)檢測(cè)你的硬件和管理模型卸載之間的CPU和GPU無縫。它有自己的模型庫，可以自動(dòng)下載模型并支持GGUF文件。雖然它的速度比lama.cpp略慢，但即使在只有cpu的設(shè)置和筆記本電腦上，它也表現(xiàn)得很好。
為了快速入門，安裝后，運(yùn)行ollama run llama3.1:latest將直接從命令行以對(duì)話模式加載最新的8B模型。
一個(gè)缺點(diǎn)是自定義模型可能有些不切實(shí)際，特別是對(duì)于高級(jí)開發(fā)。例如，即使調(diào)整溫度也需要?jiǎng)?chuàng)建一個(gè)新的聊天機(jī)器人實(shí)例，而這個(gè)實(shí)例又會(huì)加載一個(gè)已安裝的模型。雖然這是一個(gè)小小的不便，但它確實(shí)有助于在單個(gè)文件中設(shè)置自定義聊天機(jī)器人（包括其他參數(shù)和角色）?？偟膩碚f，我們相信Ollama是一個(gè)有效的本地工具，它模仿了云服務(wù)的一些關(guān)鍵功能。
值得注意的是，Ollama作為一種服務(wù)運(yùn)行，至少在Linux機(jī)器上是這樣，它提供了方便、簡(jiǎn)單的命令來監(jiān)控哪些模型正在運(yùn)行以及它們?cè)谀睦锉恍遁d，如果需要，還可以立即停止它們。社區(qū)面臨的一個(gè)挑戰(zhàn)是配置某些方面，例如模型存儲(chǔ)的位置，這需要Linux系統(tǒng)的技術(shù)知識(shí)。雖然這可能不會(huì)對(duì)最終用戶造成問題，但它可能會(huì)略微損害該工具在高級(jí)開發(fā)目的中的實(shí)用性。
llama.cpp
在分析過程中，lama.cpp成為我們最喜歡的工具。正如其存儲(chǔ)庫中所述，它旨在以最小的設(shè)置和先進(jìn)的性能在大型語言模型上運(yùn)行推斷。像Ollama一樣，它支持CPU和GPU之間的卸載模型，盡管這不是直接開箱即用的。要啟用GPU支持，你必須使用適當(dāng)?shù)臉?biāo)志編譯工具-特別是GGML_CUDA=on。我們建議使用最新版本的CUDA工具包，因?yàn)榕f版本可能不兼容。
該工具可以通過從存儲(chǔ)庫中提取并編譯來獨(dú)立安裝，這為運(yùn)行模型提供了方便的命令行客戶端。例如，你可以執(zhí)行l(wèi)lama-cli -p 'you are a useful assistant' -m Meta-Llama-3-8B-Instruct.Q8_0。gguf cnv。這里，最后一個(gè)標(biāo)志直接從命令行啟用對(duì)話模式。lama-cli提供了各種定制選項(xiàng)，比如調(diào)整上下文大小、重復(fù)懲罰和溫度，它還支持GPU卸載選項(xiàng)。
與Ollama類似，llama.cpp有一個(gè)Python綁定，可以通過pip install llama-cpp-python來安裝。這個(gè)Python庫允許大量定制，使開發(fā)人員可以輕松地根據(jù)特定的客戶需求定制模型。然而，與獨(dú)立版本一樣，Python綁定需要使用適當(dāng)?shù)臉?biāo)志進(jìn)行編譯以啟用GPU支持。
一個(gè)小缺點(diǎn)是該工具還不支持自動(dòng)CPU-GPU卸載。相反，用戶需要手動(dòng)指定將多少層卸載到GPU上，其余的交給CPU。雖然這需要一些微調(diào)，但這是一個(gè)簡(jiǎn)單、可控的步驟。
對(duì)于像我們這樣有多個(gè)gpu的環(huán)境，llama.cpp提供了兩種分割模式：行模式和層模式。在行模式下，一個(gè)GPU處理小張量和中間結(jié)果，而在層模式下，層在GPU之間劃分。在我們的測(cè)試中，這兩種模式都提供了相當(dāng)?shù)男阅埽ㄕ?qǐng)參閱下面的分析）。
實(shí)驗(yàn)分析
從現(xiàn)在開始，結(jié)果只涉及l(fā)lama.cpp和Ollama。
我們使用Ollama和Llama .cpp對(duì)70B和8B Llama 3.1模型的速度和功耗進(jìn)行了分析。具體來說，我們檢查了quantfactory中可用的各種量化方法中每個(gè)模型的速度和每個(gè)令牌的功耗。
為了執(zhí)行此分析，我們開發(fā)了一個(gè)小應(yīng)用程序，以便在選擇工具后評(píng)估模型。在推理過程中，我們記錄了一些指標(biāo)，例如速度（每秒令牌數(shù)）、生成的令牌總數(shù)、溫度、gpu上加載的層數(shù)以及響應(yīng)的質(zhì)量評(píng)級(jí)。此外，我們還測(cè)量了模型執(zhí)行期間GPU的功耗。在每個(gè)令牌生成之后，使用一個(gè)腳本（通過nvidia-smi）立即監(jiān)視GPU的電量使用情況。推斷完成后，我們根據(jù)這些讀數(shù)計(jì)算平均功耗。由于我們關(guān)注的是完全適合GPU內(nèi)存的模型，所以我們只測(cè)量GPU功耗。
此外，實(shí)驗(yàn)采用多種提示進(jìn)行，以確保不同的輸出大小，因此，數(shù)據(jù)涵蓋了廣泛的場(chǎng)景。
硬件和軟件設(shè)置
我們使用了一個(gè)具有以下功能的相當(dāng)不錯(cuò)的服務(wù)器：
CPU: AMD Ryzen Threadripper PRO 7965WX 24核@ 48x 5.362GHz
GPU: 2倍NVIDIA GeForce RTX 4090。
內(nèi)存:515276 mib -
操作系統(tǒng)：Pop 22.04 jammy。
內(nèi)核：x86_64 Linux 6.9.3-76060903-generic。
這個(gè)裝置的零售成本大約是15000美元。我們之所以選擇這樣的設(shè)置，是因?yàn)樗且粋€(gè)不錯(cuò)的服務(wù)器，雖然遠(yuǎn)不如擁有8個(gè)或更多gpu的專用高端AI服務(wù)器強(qiáng)大，但仍然具有相當(dāng)?shù)墓δ芎痛硇?，我們的許多客戶可能會(huì)選擇它。我們發(fā)現(xiàn)許多客戶對(duì)投資高端服務(wù)器猶豫不決，這種設(shè)置是成本和性能之間的一個(gè)很好的折衷。
速度
讓我們首先關(guān)注速度。下面，我們給出了幾個(gè)盒須圖，描繪了幾個(gè)量化的速度數(shù)據(jù)。每個(gè)模型的名稱以其量化級(jí)別開頭；例如，“Q4”表示4位量化。同樣，較低的量化水平輪詢更多，減小了尺寸和質(zhì)量，但提高了速度。
?技術(shù)問題1（關(guān)于盒須圖的提示）：盒須圖顯示中位數(shù)、第一和第三四分位數(shù)以及最小和最大數(shù)據(jù)點(diǎn)。須延伸到不被歸類為異常點(diǎn)的最極端點(diǎn)，而異常點(diǎn)是單獨(dú)繪制的。異常值被定義為落在Q1?1.5 × IQR和Q3 + 1.5 × IQR范圍之外的數(shù)據(jù)點(diǎn)，其中Q1和Q3分別代表第一和第三個(gè)四分位數(shù)。四分位間距（IQR）計(jì)算公式為：IQR = Q3?Q1。
llama.cpp
下面是llama.cpp的圖表。圖3顯示了QuantFactory中可用的70B參數(shù)的所有Llama 3.1模型的結(jié)果，圖4顯示了此處可用的8B參數(shù)的部分模型。70B型號(hào)最多可以卸載81層到GPU上，而8B型號(hào)最多可以卸載33層。對(duì)于70B，卸載所有層對(duì)于Q5量化和更精細(xì)是不可行的。每個(gè)量化類型包括在括號(hào)中卸載到GPU上的層數(shù)。正如預(yù)期的那樣，更粗的量化產(chǎn)生最佳的速度性能。由于行分割模式的執(zhí)行類似，我們?cè)谶@里主要討論層分割模式。
圖3具有70B參數(shù)的Llama 3.1模型在分模層的Llama.cpp下運(yùn)行。正如預(yù)期的那樣，更粗的量化提供了最好的速度。卸載到GPU上的層數(shù)在每個(gè)量化類型旁邊的括號(hào)中顯示。具有Q5和更精細(xì)量化的模型不完全適合VRAM。
圖4 8B參數(shù)的Llama 3.1模型在Llama .cpp下使用分模層運(yùn)行。在這種情況下，該模型適用于所有量化類型的GPU內(nèi)存，較粗的量化導(dǎo)致最快的速度。請(qǐng)注意，高速是異常值，而Q2_K的總體趨勢(shì)徘徊在每秒20個(gè)令牌左右。
主要觀察
在推理過程中，我們觀察到一些高速事件（特別是在8B Q2_K中），這是收集數(shù)據(jù)并理解其分布至關(guān)重要的地方，因?yàn)槭聦?shí)證明這些事件非常罕見。
正如預(yù)期的那樣，較粗的量化類型產(chǎn)生最佳的速度性能。這是因?yàn)槟Ｐ痛笮p小了，允許更快的執(zhí)行。
有關(guān)70B模型不能完全適合VRAM的結(jié)果必須謹(jǐn)慎對(duì)待，因?yàn)槭褂肅PU也可能導(dǎo)致瓶頸。因此，在這些情況下，報(bào)告的速度可能不是模型性能的最佳表示。
Ollama
我們對(duì)Ollama做了同樣的分析。圖5顯示了Ollama自動(dòng)下載的默認(rèn)Llama 3.1和3.2模型的結(jié)果。除了405B型號(hào)外，它們都適合GPU內(nèi)存。
圖5在Ollama下運(yùn)行的Llama 3.1和3.2模型。這些是使用Ollama時(shí)的默認(rèn)模型。所有3.1模型-特別是405B， 70B和8B（標(biāo)記為“最新”）-使用Q4_0量化，而3.2模型使用Q8_0 （1B）和Q4_K_M （3B）。
主要觀察
我們可以將70B Q4_0模型與Ollama和llama.cpp進(jìn)行比較，其中Ollama的速度略慢。
同樣，8B Q4_0模型在Ollama下比其對(duì)應(yīng)的llama.cpp要慢，而且有一個(gè)更明顯的區(qū)別——llama.cpp平均每秒多處理5個(gè)令牌。
分析框架總結(jié)
在討論功耗和可租用性之前，讓我們總結(jié)一下到目前為止我們分析的框架。
電力消耗和可租賃性
這個(gè)分析特別適用于將所有層都放入GPU內(nèi)存的模型，因?yàn)槲覀冎粶y(cè)量了兩個(gè)RTX 4090卡的功耗。盡管如此，值得注意的是，這些測(cè)試中使用的CPU的TDP為350 W，這提供了最大負(fù)載下的功耗估計(jì)。如果將整個(gè)模型加載到GPU上，CPU可能會(huì)保持接近空閑水平的功耗。
為了估計(jì)每個(gè)令牌的能耗，我們使用以下參數(shù)：每秒令牌數(shù)（NT）和兩個(gè)gpu消耗的功率(P)，以瓦為單位。通過計(jì)算P/NT，我們得到每個(gè)令牌的能耗，單位是瓦秒。將其除以3600得到每個(gè)令牌的能源使用量，單位是Wh，這是更常用的參考。
llama.cpp
以下是llama.cpp的結(jié)果。圖6為70B型號(hào)的能耗圖，圖7為8B型號(hào)的能耗圖。這些圖顯示了每種量化類型的能耗數(shù)據(jù)，其平均值顯示在圖例中。
圖6 Llama.cpp下，70B參數(shù)的Llama 3.1模型各量化的每令牌能量。顯示了行分割模式和層分割模式。結(jié)果僅適用于適合GPU內(nèi)存中所有81層的模型。
圖7 Llama .cpp下，8B參數(shù)下Llama 3.1模型各量化的每令牌能量。顯示了行分割模式和層分割模式。所有型號(hào)的平均消耗量都差不多。
Ollama
我們還分析了Ollama的能源消耗。圖8為L(zhǎng)lama 3.1 8B （Q4_0量化）和Llama 3.2 1B和3B（分別為Q8_0和Q4_K_M量化）的結(jié)果。圖9顯示了70B和405B型號(hào)的單獨(dú)能耗，均采用Q4_0量化。
圖8 Ollama下Llama 3.1 8B （Q4_0量化）和Llama 3.2 1B和3B模型（Q8_0和Q4_K_M量化）的每令牌能量。
圖9 Llama 3.1 70B（左）和Llama 3.1 405B（右）的每個(gè)令牌能量，均在Ollama下使用Q4_0量化。
成本
我們不會(huì)單獨(dú)討論每個(gè)模型，而是將重點(diǎn)放在跨llama.cpp和Ollama的可比較模型上，以及在llama.cpp下使用Q2_K量化的模型上，因?yàn)樗沁@里探討的最粗糙的量化。為了更好地了解成本，我們?cè)谙卤碇酗@示了每100萬個(gè)生成的令牌（1M）的能源消耗和以美元計(jì)算的成本的估計(jì)。該成本是根據(jù)德克薩斯州的平均電價(jià)計(jì)算的，根據(jù)該消息來源，每千瓦時(shí)0.14美元。作為參考，目前gpt - 40的定價(jià)至少為每百萬代幣5美元，而GPT-o mini的定價(jià)為每百萬代幣0.3美元。
llama.cpp
主要觀察
使用Q4_0的Llama 3.1 70B模型，Llama .cpp和Ollama的能耗沒有太大差異。
對(duì)于8B型駱駝來說，cpp比Ollama消耗更多的能量。
考慮一下，這里所描述的成本可以看作是運(yùn)行模型的“裸成本”的下限。其他成本，如操作、維護(hù)、設(shè)備成本和利潤(rùn)，不包括在這一分析中。
估計(jì)表明，與云服務(wù)相比，在私有服務(wù)器上運(yùn)行l(wèi)lm具有成本效益。特別是，在適當(dāng)?shù)那闆r下，將美洲駝8B與GPT-45o mini進(jìn)行比較，將美洲駝70B與gpt - 40進(jìn)行比較似乎是一筆潛在的好交易。
?技術(shù)問題2（成本估計(jì)）：對(duì)于大多數(shù)模型，每1M代幣的能源消耗（及其可變性）的估計(jì)是由“中位數(shù)±IQR”處方給出的，其中IQR代表四分位數(shù)范圍。只有在Llama 3.1 8B Q4_0模型中，我們使用“mean±STD”方法，其中STD表示標(biāo)準(zhǔn)差。這些選擇不是武斷的；除了Llama 3.1 8B Q4_0之外的所有模型都顯示出異常值，這使得中位數(shù)和IQR在這些情況下更加穩(wěn)健。此外，這些選擇有助于防止成本出現(xiàn)負(fù)值。在大多數(shù)情況下，當(dāng)兩種方法產(chǎn)生相同的集中趨勢(shì)時(shí)，它們提供了非常相似的結(jié)果。
結(jié)論
Meta AI圖像
對(duì)不同模型和工具的速度和功耗的分析只是整體情況的一部分。我們觀察到，輕量化或高度量化的模型通常在可靠性方面表現(xiàn)出一定的局限性。隨著聊天記錄的增加或任務(wù)的重復(fù)，出現(xiàn)幻覺的頻率也隨之上升。這并不意外——較小的模型難以捕捉較大模型的廣泛復(fù)雜性。為緩解這些限制，可以通過重復(fù)懲罰和溫度調(diào)節(jié)等設(shè)置來改善輸出質(zhì)量。
另一方面，像70B這樣的大模型始終展現(xiàn)出強(qiáng)大的性能，幾乎不會(huì)產(chǎn)生幻覺。然而，由于即便是最強(qiáng)大的模型也可能出現(xiàn)不準(zhǔn)確的情況，負(fù)責(zé)任且可靠的使用通常需要將這些模型與其他工具集成，比如LangChain和矢量數(shù)據(jù)庫。盡管我們?cè)诖瞬⑽瓷钊胩接懢唧w任務(wù)的性能表現(xiàn)，但這些集成對(duì)于最小化幻覺并增強(qiáng)模型的可靠性至關(guān)重要。
綜上所述，在私有服務(wù)器上運(yùn)行大型語言模型（LLM）作為一種服務(wù)，能夠提供具備競(jìng)爭(zhēng)力的LLM替代方案，同時(shí)兼具成本優(yōu)勢(shì)和定制化的可能性。無論是私有部署還是基于服務(wù)的選項(xiàng)，各有其獨(dú)特優(yōu)勢(shì)。在Austin AI，我們專注于提供滿足客戶需求的解決方案，無論這意味著利用私有服務(wù)器、云服務(wù)，還是采用混合方案。
聯(lián)系客服
