CPU 時間是如何耗費在 llama.cpp 程式和 LLaMA2 模型內部的(使用 OpenResty XRay)
llama.cpp 和 LLaMA 2 是兩個流行的 AI 軟體專案,它們旨在讓大家能夠更方便、更高效地使用大型語言模型(LLMs)。llama.cpp 是用 C/C++ 語言實現的 Meta 公司的 LLaMA 模型。LLaMA 2 是一系列基於分組查詢注意力(grouped-query attention)技術的生成式文字模型,它們針對程式設計任務進行了專門的微調。然而,這些模型的執行需要消耗大量的 CPU 資源。
在這個教程中,我們會一步步地教您如何使用 OpenResty XRay 來分析執行 LLaMA2 模型的 llama.cpp 程式。我們會快速定位該程式中最耗 CPU 資源的 C++ 程式碼路徑。這些程式碼路徑消耗最多的 CPU 時間,會影響 llama 應用程式的效能。
問題: 高 CPU 使用率
進入 llama.cpp
目錄。
首先來編譯這個 C++ 專案。我們使用 -g
這個選項來開啟除錯符號。
執行 make
命令。
編譯結束了,沒有出現錯誤。
執行 llama.cpp
的 main
程式。Llama2 是微軟和 Meta 聯合開源的最新大語言模型。這裡我們使用了 llama.cpp
可以執行的量化後的 7B 模型。
指定生成的 token 數。
使用 “Linux” 作為提示來生成內容。
執行這個命令。可以看到下面已經在不斷地輸出生成的文字內容了。
開啟另一個終端,執行 top
命令檢視 CPU 的使用情況。
可以看到 llama.cpp
的 main
命令消耗了接近 400% 的 CPU 核心資源。
使用 OpenResty XRay 的引導式分析功能定位最熱的 C++ 程式碼路徑
我們可以使用 OpenResty XRay 來檢查這個未經修改的程序。在瀏覽器中開啟 OpenResty XRay 的 Web 控制檯。
我們可以在這裡對剛才看到的程序進行實時分析,檢視 CPU 時間具體消耗在哪裡了。
確保我們當前分析的是正確的機器。
如果當前顯示的機器不對,您可以從下面的列表中選擇一個正確的。
進入 “Guided Analysis” 頁面。
這裡可以看到系統能分析哪些型別的問題。
選擇 “High CPU usage”。
點選 “Next”。
透過選擇 “程序” 來選擇要分析的目標。
選擇 llama.cpp
的 main
程序。
確保應用程式的型別是正確的。通常預設值就是對的。
這裡的語言級別就只有 ”C 和 C++“。
我們還可以設定最大分析時間,這裡保持預設的 300 秒不變。
開始分析。
系統將持續執行多輪分析,現在它正在執行第一輪分析。
第一輪分析已經完成,現在進入第二輪分析。對這個例子來說,執行一輪分析就夠了。
現在停止分析。
這裡顯示了系統正在為本次分析生成報告。
可以看到自動生成了一份分析報告。
這是現在我們要分析的問題型別,CPU。
這個是佔用 CPU 時間最多的 C++ 程式碼路徑。
第一個函式 ggml_compute_forward_mul_mat
是 ggml
庫中的通用矩陣乘法函式。
而其上一級呼叫它的函式 ggml_graph_compute_thread
負責進行單個執行緒的計算。
點選 “More” 檢視細節資訊。
上面的程式碼路徑是從這個 CPU 火焰圖中推匯出來的。
下面是對當前問題更詳細的解釋和建議。
它提到了 ggml_compute_forward_mul_mat
函式。
這個函式進行矩陣乘法操作。
現在來看看佔用 CPU 時間排名第二的 C++ 程式碼路徑。
第一個函式 ggml_vec_dot_q4_K_q8_K
是 ggml
庫中用於計算兩個向量點積的函式。
點選 “More” 檢視細節資訊。
它提到了 ggml_vec_dot_q4_K_q8_K
函式。
也提到了它是計算兩個向量的點積的。
讓我們回到第二條程式碼路徑上來。把滑鼠放在第一個函式的綠色框上。
可以看到這個函式的原始檔名。在提示框中還可以看到 k_quants.c
檔案的完整路徑。
這行原始碼的行號是 2608。
點選這個圖示,複製這個函式完整的 C 原始檔路徑。
使用 vim 編輯器,檢視這個檔案裡的 C 程式碼。您可以使用任何您喜歡的編輯器。
正如 OpenResty XRay 建議的那樣跳轉到第 2608 行。
我們可以看到這行程式碼使用了 C 語言的位運算來對陣列的元素進行一些操作。
在狀態列中可以看到這行程式碼也確實在之前報告裡提到的 ggml_vec_dot_q4_K_q8_K
函式中。
全自動分析與報告
OpenResty XRay 也可以自動監控線上程序,並顯示分析報告。
跳轉到 “Insights” 頁面。
您可以在 “Insights” 頁面中找到以日和周為週期的報告。
所以您不是非得用 “Guided Analysis” 功能。當然,“Guided Analysis” 對於應用程式的開發和演示是很有用的。
關於 OpenResty XRay
OpenResty XRay 是一個動態追蹤產品,它可以自動分析執行中的應用程式,以解決效能問題、行為問題和安全漏洞,並提供可行的建議。在底層實現上,OpenResty XRay 由我們的 Y 語言驅動,可以在不同環境下支援多種不同的執行時,如 Stap+、eBPF+、GDB 和 ODB。
關於本文和關聯影片
本文和相關聯的影片都是完全由我們的 OpenResty Showman 產品從一個簡單的劇本檔案自動生成的。
關於作者
章亦春是開源 OpenResty® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。
章亦春(Github ID: agentzh),生於中國江蘇,現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物,曾供職於多家國際知名的高科技企業,如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅,擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay(利用動態追蹤技術的非侵入式的故障剖析和排除工具)和 OpenResty Edge(最適合微服務和分散式流量的全能型閘道器軟體),廣受全球眾多上市及大型企業青睞。在 OpenResty 以外,章亦春為多個開源專案貢獻了累計超過百萬行程式碼,其中包括,Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等,並編寫過 60 多個開源軟體庫。
關注我們
如果您喜歡本文,歡迎關注我們 OpenResty Inc. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號:
翻譯
我們提供了英文版原文和中譯版(本文)。我們也歡迎讀者提供其他語言的翻譯版本,只要是全文翻譯不帶省略,我們都將會考慮採用,非常感謝!