Llama 3.1 - 405B、70B 和 8B 的多語言與長上下文能力解析

HuggingFace發表於2024-07-26

Llama 3.1 釋出了！今天我們迎來了 Llama 家族的新成員 Llama 3.1 進入 Hugging Face 平臺。我們很高興與 Meta 合作，確保在 Hugging Face 生態系統中實現最佳整合。Hub 上現有八個開源權重模型 (3 個基礎模型和 5 個微調模型)。

Llama 3.1 有三種規格: 8B 適合在消費者級 GPU 上進行高效部署和開發，70B 適合大規模 AI 原生應用，而 405B 則適用於合成資料、大語言模型 (LLM) 作為評判者或蒸餾。這三個規格都提供基礎版和指令調優版。

除了六個生成模型，Meta 還發布了兩個新模型: Llama Guard 3 和 Prompt Guard。Prompt Guard 是一個小型分類器，可以檢測提示注入和越獄。Llama Guard 3 是一個保護模型，能夠分類 LLM 輸入和生成的內容。

此次釋出的一些功能和整合包括:

Hub 上的模型
Hugging Face Transformers 和 TGI 整合
Meta Llama 3.1 405B Instruct 的 Hugging Chat 整合
使用推理端點、Google Cloud、Amazon SageMaker 和 DELL Enterprise Hub 進行推理和部署整合
FP8、AWQ 和 GPTQ 的量化，便於推理
使用 🤗 TRL 在單個 GPU 上微調 Llama 3.1 8B
使用 Distilabel 生成 Llama 3.1 70B 和 405B 的合成資料

Llama 3.1 的新功能

Llama 3.1 為什麼令人興奮？在前代產品的基礎上，Llama 3.1 增加了一些關鍵新功能:

128K token 的長上下文能力 (相較於原來的 8K)
多語言支援
工具使用功能
擁有 4050 億引數的超大稠密模型
更寬鬆的許可證

讓我們深入瞭解這些新功能！

Llama 3.1 版本引入了基於 Llama 3 架構的六個新開源 LLM 模型。它們有三種規格: 8B、70B 和 405B 引數，每種都有基礎版 (預訓練) 和指令調優版。所有版本都支援 128K token 的上下文長度和 8 種語言，包括英語、德語、法語、義大利語、葡萄牙語、印地語、西班牙語和泰語。Llama 3.1 繼續使用分組查詢注意力 (GQA)，這是一種高效的表示方式，有助於處理更長的上下文。

Meta-Llama-3.1-8B: 基礎 8B 模型
Meta-Llama-3.1-8B-Instruct: 基礎 8B 模型的指令調優版
Meta-Llama-3.1-70B: 基礎 70B 模型
Meta-Llama-3.1-70B-Instruct: 基礎 70B 模型的指令調優版
Meta-Llama-3.1-405B: 基礎 405B 模型
Meta-Llama-3.1-405B-Instruct: 基礎 405B 模型的指令調優版

除了這六個語言模型，還發布了 Llama Guard 3 和 Prompt Guard。

Llama Guard 3 是 Llama Guard 家族的最新版本，基於 Llama 3.1 8B 進行微調。它為生產用例而設計，具有 128k 的上下文長度和多語言能力。Llama Guard 3 可以分類 LLM 的輸入 (提示) 和輸出，以檢測在風險分類中被認為不安全的內容。
Prompt Guard，另一方面，是一個小型 279M 引數的基於 BERT 的分類器，可以檢測提示注入和越獄。它在大規模攻擊語料庫上訓練，並建議使用特定應用的資料進行進一步微調。

與 Llama 3 相比，Llama 3.1 的新特點是指令模型在工具呼叫方面進行了微調，適用於智慧體用例。內建了兩個工具 (搜尋，使用 Wolfram Alpha 進行數學推理)，可以擴充套件為自定義 JSON 功能。

Llama 3.1 模型在定製 GPU 叢集上訓練了超過 15 萬億 token，總計 39.3M GPU 小時 (8B 1.46M，70B 7.0M，405B 30.84M)。我們不知道訓練資料集混合的具體細節，但我們猜測它在多語言方面有更廣泛的策劃。Llama 3.1 Instruct 已最佳化用於指令跟隨，並在公開可用的指令資料集以及超過 2500 萬合成生成的示例上進行監督微調 (SFT) 和人類反饋的強化學習 (RLHF)。Meta 開發了基於 LLM 的分類器，以在資料混合建立過程中過濾和策劃高質量的提示和響應。

關於許可條款，Llama 3.1 具有非常相似的許可證，但有一個關鍵區別: 它允許使用模型輸出來改進其他 LLM。這意味著合成資料生成和蒸餾是允許的，即使是不同的模型！這對 405B 模型尤其重要，如後面所討論的。許可證允許再分發、微調和建立衍生作品，仍然要求派生模型在其名稱的開頭包括 “Llama”，並且任何衍生作品或服務必須提及 “Built with Llama”。有關完整詳情，請確保閱讀官方許可證。

Llama 3.1 需要多少記憶體？

Llama 3.1 帶來了令人興奮的進步。然而，執行它需要仔細考慮硬體資源。我們分解了三種模型規格在訓練和推理中的記憶體需求。

推理記憶體需求

對於推理，記憶體需求取決於模型規格和權重的精度。以下是不同配置所需的近似記憶體:

模型規格	FP16	FP8	INT4
8B	16 GB	8 GB	4 GB
70B	140 GB	70 GB	35 GB
405B	810 GB	405 GB	203 GB

注意: 上面引用的數字表示僅載入模型檢查點所需的 GPU VRAM。它們不包括核心或 CUDA 圖形的 torch 保留空間。

例如，一個 H100 節點 (8x H100) 有約 640GB 的 VRAM，因此 405B 模型需要在多節點設定中執行或以較低精度 (例如 FP8) 執行，這是推薦的方法。

請記住，較低精度 (例如 INT4) 可能會導致一些精度損失，但可以顯著減少記憶體需求並提高推理速度。除了模型權重外，您還需要將 KV 快取保持在記憶體中。它包含模型上下文中所有 token 的鍵和值，以便在生成新 token 時不需要重新計算。特別是當利用可用的長上下文長度時，它變得至關重要。在 FP16 中，KV 快取記憶體需求如下:

模型規格	1k token	16k token	128k token
8B	0.125 GB	1.95 GB	15.62 GB
70B	0.313 GB	4.88 GB	39.06 GB
405B	0.984 GB	15.38	123.05 GB

特別是對於小規格模型，當接近上下文長度上限時，快取使用的記憶體與權重一樣多。

訓練記憶體需求

以下表格概述了使用不同技術訓練 Llama 3.1 模型的大致記憶體需求:

模型規格	Full Fine-tuning	LoRA	Q-LoRA
8B	60 GB	16 GB	6 GB
70B	300 GB	160 GB	48 GB
405B	3.25 TB	950 GB	250 GB

注意: 這些是估計值，可能會根據具體實現細節和最佳化情況有所不同。

Llama 3.1 評估

注意: 我們目前正在新的 Open LLM Leaderboard 2 上單獨評估 Llama 3.1，並將在今天晚些時候更新此部分。以下是 Meta 官方評估的摘錄。

類別	基準	*樣本數*	指標	*Llama 3 8B*	*Llama 3.1 8B*	*Llama 3 70B*	*Llama 3.1 70B*	*Llama 3.1 405B*
綜合	MMLU	5	宏觀平均/字元準確率	66.7	66.7	79.5	79.3	85.2
	MMLU PRO（CoT）	5	宏觀平均/字元準確率	36.2	37.1	55.0	53.8	61.6
	AGIEval 英語	3-5	平均/字元準確率	47.1	47.8	63.0	64.6	71.6
	CommonSenseQA	7	字元準確率	72.6	75.0	83.8	84.1	85.8
	Winogrande	5	字元準確率	-	60.5	-	83.3	86.7
	BIG-Bench Hard（CoT）	3	平均/完全匹配	61.1	64.2	81.3	81.6	85.9
	ARC-Challenge	25	字元準確率	79.4	79.7	93.1	92.9	96.1
知識推理	TriviaQA-Wiki	5	完全匹配	78.5	77.6	89.7	89.8	91.8
	SQuAD	1	完全匹配	76.4	77.0	85.6	81.8	89.3
閱讀理解	QuAC（F1）	1	F1	44.4	44.9	51.1	51.1	53.6
	BoolQ	0	字元準確率	75.7	75.0	79.0	79.4	80.0
	DROP（F1）	3	F1	58.4	59.5	79.7	79.6	84.8

使用 Hugging Face Transformers

Llama 3.1 需要進行少量建模更新，以有效處理 RoPE 縮放。使用 Transformers 4.43 版，您可以使用新的 Llama 3.1 模型，並利用 Hugging Face 生態系統中的所有工具。確保使用最新的 transformers 版本:

pip install "transformers>=4.43" --upgrade

幾個細節:

Transformers 預設以 bfloat16 載入模型。這是 Meta 釋出的原始檢查點使用的型別，因此這是確保最佳精度或進行評估的推薦方法。
助手響應可能以特殊 token <|eot_id|> 結尾，但我們還必須在找到常規 EOS token 時停止生成。我們可以透過在 eos_token_id 引數中提供終止符列表來提前停止生成。
我們使用了 Meta 程式碼庫中的預設取樣引數 (temperature 和 top_p )。我們還沒有時間進行廣泛測試，請隨意探索！

以下程式碼段顯示瞭如何使用 meta-llama/Meta-Llama-3.1-8B-Instruct 。它大約需要 16 GB 的 VRAM，適合許多消費者級 GPU。相同的程式碼段適用於 meta-llama/Meta-Llama-3.1-70B-Instruct ，在 140GB VRAM 和 meta-llama/Meta-Llama-3.1-405B-Instruct (需要 810GB VRAM)，使其成為生產用例的非常有趣的模型。可以透過以 8 位或 4 位模式載入進一步減少記憶體消耗。

from transformers import pipeline
import torch

model_id = "meta-llama/Meta-Llama-3.1-8B-Instruct"
pipe = pipeline(
    "text-generation",
    model=model_id,
    model_kwargs={"torch_dtype": torch.bfloat16},
    device="cuda",
)

messages = [
    {"role": "user", "content": "Who are you? Please, answer in pirate-speak."},
]
outputs = pipe(
    messages,
    max_new_tokens=256,
    do_sample=False,
)
assistant_response = outputs[0]["generated_text"][-1]["content"]
print(assistant_response)
# Arrrr, me hearty! Yer lookin' fer a bit o' information about meself, eh? Alright then, matey! I be a language-generatin' swashbuckler, a digital buccaneer with a penchant fer spinnin' words into gold doubloons o' knowledge! Me name be... (dramatic pause)...Assistant! Aye, that be me name, and I be here to help ye navigate the seven seas o' questions and find the hidden treasure o' answers! So hoist the sails and set course fer adventure, me hearty! What be yer first question?

您還可以自動量化模型，以 8 位甚至 4 位模式載入，使用 bitsandbytes。4 位載入大 70B 版本大約需要 34 GB 的記憶體執行。這是如何以 4 位模式載入生成管道:

pipeline = pipeline(
    "text-generation",
    model=model_id,
    model_kwargs={
        "torch_dtype": torch.bfloat16,
        "quantization_config": {"load_in_4bit": True}
    },
)

有關使用 transformers 模型的更多詳細資訊，請檢視模型卡片。

注意: Transformers 處理所有棘手的提示模板問題，如果您想了解更多關於提示的資訊，請檢視下一部分。

如何使用 Llama 3.1

基礎模型沒有提示格式。像其他基礎模型一樣，它們可以用於繼續輸入序列並進行合理的延續或零樣本/少樣本推理。它們也是微調您自己用例的絕佳基礎。

指令版本支援具有 4 個角色的對話格式:

system: 設定對話的上下文。它允許包括規則、指南或必要的資訊，幫助有效響應。它也用於在適當情況下啟用工具使用。
user: 使用者輸入、命令和對模型的問題。
assistant: 助手的響應，基於 system 和 user 提示中提供的上下文。
ipython: Llama 3.1 中引入的新角色。當工具呼叫返回給 LLM 時作為輸出使用。

指令版本使用以下對話結構進行簡單對話:

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

{{ system_prompt }}<|eot_id|><|start_header_id|>user<|end_header_id|>

{{ user_msg_1 }}<|eot_id|><|start_header_id|>assistant<|end_header_id|>

{{ model_answer_1 }}<|eot_id|>

Llama 3.1 指令模型現在支援工具呼叫，包括三個內建工具 (brave_search、wolfram_alpha 和 code_interpreter) 和透過 JSON 函式呼叫的自定義工具呼叫。內建工具使用 Python 語法。生成 Python 程式碼以進行函式呼叫是程式碼直譯器工具的一部分，必須在系統提示中使用 Environment 關鍵字啟用，如下所示。

內建工具呼叫

內建工具呼叫示例

<|begin_of_text|><|start_header_id|>system<|end_header_id|>


Environment: ipython
Tools: brave_search, wolfram_alpha

Cutting Knowledge Date: 01 March 2023
Today's Date: 13 July 2024


You are a helpful Assistant.<|eot_id|><|start_header_id|>user<|end_header_id|>

Weather in Menlo Park, California<|eot_id|><|start_header_id|>assistant<|end_header_id|>

此時模型的響應將包括呼叫其中一個支援的工具 (在本例中為 brave_search ) 的 Python 程式碼:

<|python_tag|>brave_search.call(query="current weather in Menlo Park, California")<|eom_id|>

執行呼叫的響應然後傳送回模型以檢索最終響應。為了簡潔，以下內容將附加到前面程式碼段中顯示的訊息:

<|python_tag|>brave_search.call(query="Menlo Park California weather")<|eom_id|><|start_header_id|>ipython<|end_header_id|>

{"query": "Menlo Park California weather", "top_k": [{"title": "10-Day Weather Forecast for West Menlo Park, CA - The Weather Channel | weather.com", "url": "https://weather.com/weather/tenday/l/West+Menlo+Park+CA?canonicalCityId=b2375713aa1943aad7d1a13a85e1c0adad13c1b10563b2bbaad70734dc61cf11", "description": "Be prepared with the most accurate 10-day forecast for West <strong>Menlo</strong> <strong>Park</strong>, CA with highs, lows, chance of precipitation from The <strong>Weather</strong> Channel and <strong>Weather</strong>.com", "type": "search_result"},....}<|eot_id|><|start_header_id|>assistant<|end_header_id|>

LLM 的最終響應將是:

The current weather in Menlo Park, California is mostly sunny with a high of 77°F and a low of 56°F.<|eot_id|>

自定義工具呼叫

Llama 3.1 指令支援從單個使用者訊息中呼叫自定義函式。以下提示提供瞭如何從模型輸出呼叫自定義函式的示例。在自定義函式呼叫中，模型輸出 <|eot_id|> 而不是 <|eom_id|> 。需要調整系統提示以告知模型如何處理函式呼叫輸出。

自定義工具呼叫 JSON 函式

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

You are a helpful assistant with tool calling capabilities. When you receive a tool call response, use the output to format an answer to the orginal user question.<|eot_id|><|start_header_id|>user<|end_header_id|>

Given the following functions, please respond with a JSON for a function call with its proper arguments that best answers the given prompt.

Respond in the format {"name": function name, "parameters": dictionary of argument name and its value}. Do not use variables.

{
    "type": "function",
    "function": {
    "name": "get_current_conditions",
    "description": "Get the current weather conditions for a specific location",
    "parameters": {
        "type": "object",
        "properties": {
        "location": {
            "type": "string",
            "description": "The city and state, e.g., San Francisco, CA"
        },
        "unit": {
            "type": "string",
            "enum": ["Celsius", "Fahrenheit"],
            "description": "The temperature unit to use. Infer this from the user's location."
        }
        },
        "required": ["location", "unit"]
    }
    }
}

Question: what is the weather like in Menlo Park?<|eot_id|><|start_header_id|>assitant<|end_header_id|>

{"name": "get_current_conditions", "parameters": {"location": "Menlo Park, CA", "unit": "Fahrenheit"}}<|eot_id|><|start_header_id|>ipython<|end_header_id|>

當我們從選定的工具檢索輸出時，我們將其傳回模型，使用相同的 <|python_tag|> 分隔符。<|python_tag|> 不意味著使用 Python。它僅用於表示任何工具的輸出開始。

<|python_tag|>{
    "tool_call_id": "get_current_conditions"
    "output": "Clouds giving way to sun Hi: 76° Tonight: Mainly clear early, then areas of low clouds forming Lo: 56°"
}<|eot_id|><|start_header_id|>assistant<|end_header_id|>

The weather in Menlo Park is currently cloudy with a high of 76° and a low of 56°, with clear skies expected tonight.<|eot_id|>

這種格式必須精確複製才能有效使用。transformers 中可用的聊天模板使其易於正確格式化提示。

演示

您可以在以下演示中試驗三種指令模型:

Llama 3.1 405B 的 Hugging Chat https://huggingface.co/chat/models/meta-llama/Meta-Llama-3.1-405b-instruct/
Llama 3.1 70B 的 Hugging Chat https://huggingface.co/chat/models/meta-llama/Meta-Llama-3.1-70b-instruct/
Llama 3.1 8B 演示的 Gradio 驅動的 Space https://huggingface.co/spaces/ysharma/Chat_with_Meta_llama3_1_8b

整個堆疊都是開源的。Hugging Chat 由 chat-ui 和 text-generation-inference 提供支援。

Llama 3.1 405B 的 FP8、AWQ 和 GPTQ 量化

Meta 建立了 Llama 3.1 405B 的官方 FP8 量化版本，精度損失最小。為實現這一目標，FP8 量化僅應用於模型的主要線性運算子，例如 FFNs 的門和上升及下降投影 (涵蓋 75% 的推理 FLOPs)。我們共同努力，確保此 FP8 量化檢查點在社群中相容 (transformers, TGI, VLLM)。

此外，我們使用 AutoAWQ 和 AutoGPTQ 建立了 INT4 的 AWQ 和 GPTQ 量化變體。對於 AWQ，所有線性層都使用 GEMM 核心進行量化，將零點量化到 4 位，組大小為 128; 對於 GPTQ，相同的設定僅使用 GPTQ 核心。我們確保 INT4 檢查點與 transformers 和 TGI 相容，包括 Marlin 核心支援，以加快 TGI 中 GPTQ 量化的推理速度。

可用的 Llama 3.1 405B 的量化權重:

meta-llama/Meta-Llama-3.1-405B-Base-FP8: 官方 FP8 量化權重，可在 8xH100 上執行
meta-llama/Meta-Llama-3.1-405B-Instruct-FP8: 官方 FP8 量化權重，可在 8xH100 上執行
hugging-quants/Meta-Llama-3.1-405B-Instruct-AWQ-INT4: Hugging Face 量化權重，可在 8xA100 80GB, 8xH100 80GB 和 8xA100 40GB (減少 KV 快取且無 CUDA 圖形) 上執行
hugging-quants/Meta-Llama-3.1-405B-Instruct-GPTQ-INT4:: Hugging Face 量化權重，可在 8xA100 80GB, 8xH100 80GB 和 8xA100 40GB (減少 KV 快取且無 CUDA 圖形) 上執行
hugging-quants/Meta-Llama-3.1-405B-BNB-NF4: Hugging Face 量化權重，適用於 QLoRA 微調
hugging-quants/Meta-Llama-3.1-405B-Instruct-BNB-NF4: Hugging Face 量化權重，適用於在 8xA100 和 4xH100 上推理

Hugging Quants 組織還包含 70B 和 8B 版本的量化檢查點。

推理整合

Hugging Face 推理 API

Hugging Face PRO 使用者現在可以訪問獨家 API 端點，託管 Llama 3.1 8B Instruct、Llama 3.1 70B Instruct 和 Llama 3.1 405B Instruct AWQ，由 text-generation-inference 提供支援。所有版本都支援 Messages API，因此與 OpenAI 客戶端庫相容，包括 LangChain 和 LlamaIndex。

注意: 使用 pip install "huggingface_hub>=0.24.1" 更新到最新的 huggingface_hub 版本。

from huggingface_hub import InferenceClient

# 初始化客戶端，指向一個可用的模型
client = InferenceClient()

chat_completion = client.chat.completions.create(
    model="meta-llama/Meta-Llama-3.1-405B-Instruct-FP8",
    messages=[
        {"role": "system", "content": "You are a helpful and honest programming assistant."},
        {"role": "user", "content": "Is Rust better than Python?"},
    ],
    stream=True,
    max_tokens=500
)

# 迭代並列印流
for message in chat_completion:
    print(message.choices[0].delta.content, end="")

有關使用 Messages API 的更多詳細資訊，請檢視此帖子。

Hugging Face 推理端點

您可以在 Hugging Face 的推理端點上部署 Llama 3.1，它使用 Text Generation Inference 作為後端。Text Generation Inference 是 Hugging Face 開發的生產就緒推理容器，支援 FP8、連續批處理、token 流、張量並行，以便在多個 GPU 上快速推理。要部署 Llama 3.1，請轉到模型頁面並點選部署 -> 推理端點小部件:

Meta-Llama-3.1-8B-Instruct 推薦在 1x NVIDIA A10G 或 L4 GPU 上執行
Meta-Llama-3.1-70B-Instruct 推薦在 4x NVIDIA A100 或量化為 AWQ/GPTQ 在 2x A100 上執行
Meta-Llama-3.1-405B-Instruct-FP8 推薦在 8x NVIDIA H100 上以 FP 執行或量化為 AWQ/GPTQ 在 8x A100 上執行

from huggingface_hub import InferenceClient

# 初始化客戶端，指向一個可用的模型
client = InferenceClient(
    base_url="<ENDPOINT_URL>",
)

# 建立一個聊天完成
chat_completion = client.chat.completions.create(
    model="ENDPOINT",
    messages=[
        {"role": "system", "content": "You are a helpful and honest programming assistant."},
        {"role": "user", "content": "Is Rust better than Python?"},
    ],
    stream=True,
    max_tokens=500
)

# 迭代並列印流
for message in chat_completion:
    print(message.choices[0].delta.content, end="")

Hugging Face 合作伙伴整合

注意: 我們目前正在與我們的合作伙伴 AWS、Google Cloud、Microsoft Azure 和 DELL 合作，將 Llama 3.1 8B、70B 和 405B 新增到 Amazon SageMaker、Google Kubernetes Engine、Vertex AI Model Catalog、Azure AI Studio、DELL Enterprise Hub。我們將在容器可用時更新此部分 - 您可以訂閱 Hugging Squad 以獲取電子郵件更新。

使用 Hugging Face TRL 進行微調

在本節中，我們將檢視 Hugging Face 生態系統中可用的工具，以便在消費者級 GPU 上高效訓練 Llama 3.1。下面是一個示例命令，用於在 OpenAssistant 的 chat 資料集上微調 Llama 3.1 8B。我們使用 4 位量化和 QLoRA 來節省記憶體，以針對所有注意力塊的線性層。

使用 Hugging Face TRL 的微調示例

首先，安裝最新版本的 🤗 TRL 並克隆 repo 以訪問訓練指令碼:

pip install "transformers>=4.43" --upgrade
pip install --upgrade bitsandbytes
pip install --ugprade peft
pip install git+https://github.com/huggingface/trl
git clone https://github.com/huggingface/trl
cd trl

然後你可以執行指令碼:

python \
    examples/scripts/sft.py \
    --model_name meta-llama/Meta-Llama-3.1-8B \
    --dataset_name OpenAssistant/oasst_top1_2023-08-25 \
    --dataset_text_field="text" \
    --per_device_train_batch_size 1 \
    --per_device_eval_batch_size 1 \
    --gradient_accumulation_steps 4 \
    --learning_rate 2e-4 \
    --report_to "none" \
    --bf16 \
    --max_seq_length 1024 \
    --lora_r 16 --lora_alpha 32 \
    --lora_target_modules q_proj k_proj v_proj o_proj \
    --load_in_4bit \
    --use_peft \
    --attn_implementation "flash_attention_2" \
    --logging_steps=10 \
    --gradient_checkpointing \
    --output_dir llama31

如果您有更多的 GPU，可以使用 DeepSpeed 和 ZeRO Stage 3 執行訓練:

accelerate launch --config_file=examples/accelerate_configs/deepspeed_zero3.yaml \
    examples/scripts/sft.py \
    --model_name meta-llama/Meta-Llama-3.1-8B \
    --dataset_name OpenAssistant/oasst_top1_2023-08-25 \
    --dataset_text_field="text" \
    --per_device train batch_size 1 \
    --per_device_eval_batch_size 1 \
    --gradient_accumulation_steps 4 \
    --learning_rate 2e-5 \
    --report_to wandb \
    --bf16 \
    --max_seq_length 1024 \
    --attn_implementation eager \
    --logging_steps=10 \
    --gradient_checkpointing \
    --output_dir models/llama

使用 distilabel 生成合成資料

Llama 3.1 許可證的一個重大變化是，它允許使用模型輸出來改進其他 LLM，這意味著您可以使用 Llama 3.1 模型生成合成資料集，並使用它們來微調更小、更專業的模型。

讓我們看一個示例，如何使用 distilabel，一個用於生成合成資料的開源框架，生成一個偏好資料集。該資料集可用於使用 TRL 提供的偏好最佳化方法 (如 DPO 或 KTO) 微調模型。

首先安裝最新的 distilabel 版本，包括 hf-inference-endpoints 額外元件，使用 pip 如下:

pip install “distilabel[hf-inference-endpoints]” --upgrade

然後定義一個管道:

從 Hugging Face Hub 載入帶有指令的資料集。
使用 Hugging Face 推理端點，透過 Llama 3.1 70B Instruct 和 Llama 3.1 405B Instruct 生成響應。
最後，使用 Llama 3.1 405B Instruct 作為裁判，使用 UltraFeedback 提示對響應進行評分。從這些評分中，可以選擇和拒絕響應，並使用偏好最佳化方法微調模型。

請參閱下面的程式碼以定義管道，或使用此 Colab 筆記本自行執行並探索生成的資料集。

from distilabel.llms import InferenceEndpointsLLM
from distilabel.pipeline import Pipeline
from distilabel.steps import LoadDataFromHub, CombineColumns
from distilabel.steps.tasks import TextGeneration, UltraFeedback

llama70B = InferenceEndpointsLLM(
    model_id="meta-llama/Meta-Llama-3.1-70B-Instruct"
)
llama405B = InferenceEndpointsLLM(
    model_id="meta-llama/Meta-Llama-3.1-405B-Instruct-FP8"
)

with Pipeline(name="synthetic-data-with-llama3") as pipeline:
    # 載入帶有提示的資料集
    load_dataset = LoadDataFromHub(
        repo_id="argilla/10Kprompts-mini"
    )
    # 為每個提示生成兩個響應
    generate = [
        TextGeneration(llm=llama70B),
        TextGeneration(llm=llama405B)
    ]
    # 將響應組合到一個列中
    combine = CombineColumns(
        columns=["generation", "model_name"],
        output_columns=["generations", "model_names"]
    )
    # 使用 405B LLM-as-a-judge 對響應進行評分
    rate = UltraFeedback(aspect="overall-rating", llm=llama405B)
    # 定義管道
    load_dataset >> generate >> combine >> rate

if __name__ == "__main__":
    distiset = pipeline.run()

接下來是什麼？除了上述示例， distilabel 還提供了使用 LLM 在廣泛的場景和主題中生成合成資料的令人興奮的方法。它包括當前 SOTA 文獻中的實現，用於任務如使用 LLM-as-a-judge 方法評估輸出、進化指令、資料過濾以及定義自定義元件。

附加資源

Hub 上的模型
Hugging Face Llama Recipes
Open LLM Leaderboard
Llama 3.1 405B Instruct 的 Hugging Chat 演示
Meta 部落格

致謝

沒有成千上萬社群成員對 transformers、tgi、vllm、pytorch、LM Eval Harness 和許多其他專案的貢獻，這些模型的釋出和生態系統中的支援與評估是不可能實現的。這次釋出離不開 Clémentine 和 Nathan 對 LLM 評估的支援; Nicolas、Olivier Dehaene 和 Daniël de Kok 對 Text Generation Inference 支援的貢獻; Arthur、Matthew Carrigan、Zachary Mueller、Joao、Joshua Lochner 和 Lysandre 對 Llama 3.1 整合到 transformers 的貢獻; Matthew Douglas 對量化支援的貢獻; Gabriel Martín Blázquez 對 distilabel 支援的貢獻; Merve Noyan 和 Aymeric Roucher 對稽核的貢獻; hysts 和 Yuvi 對演示的貢獻; Ellie 對微調測試的貢獻; Brigitte Tousignant 和 Florent Daudens 對溝通的貢獻; Nathan 和 Victor 對 Hugging Chat 中 Llama 3.1 的可用性的貢獻。

感謝 Meta 團隊釋出 Llama 3.1 並使其在開源 AI 社群中可用！

英文原文: https://hf.co/blog/llama31

原文作者: Philipp Schmid, Omar Sanseviero, Alvaro Bartolome, Leandro von Werra, Daniel Vila, Vaibhav Srivastav, Marc Sun, Pedro Cuenca

譯者: AdinaY

LlamaCoder：一款基於Llama 3.1 405B的全新開源AI程式設計助手
2024-10-21
MacAI程式設計
本地執行LLaMa3:70b
2024-05-26
英偉達玩轉剪枝、蒸餾：把Llama 3.1 8B引數減半，效能同尺寸更強
2024-08-16
Fusion元件庫是如何支援多語言能力的
2019-02-19
元件
有人跑過辣媽 3.1 的 405b 模型嗎？
2024-07-29
模型
LLaMA-Factory微調多模態大語言模型教程
2024-05-31
模型
DDD中限界上下文與通用語言的作用
2021-06-06
LLAMA3.1資料處理
2024-07-25
學習筆記447—本地部署 Llama3 – 8B/70B 大模型！最簡單的方法：支援CPU /GPU執行【3種方案】
2024-04-25
筆記大模型GPU
與 C 語言長別離
2018-01-26
多語言與多時區的解決方案
2019-06-06
擊敗GPT-4o的開源模型如何煉成？關於Llama 3.1 405B，Meta都寫在這篇論文裡了
2024-07-24
GPT模型
僅8B引數，可與GPT-4媲美，上交大團隊構建多語言醫學大模型
2024-10-17
GPT大模型
基於 eBPF 的 Serverless 多語言應用監控能力建設
2023-03-06
eBPFServer
神經語言模型如何利用上下文資訊：長距離上下文的詞序並不重要
2018-06-05
模型
解析Java語言的介面與型別安全(轉)
2007-09-19
Java型別
LLaMA 3 原始碼解讀-大語言模型5
2024-05-07
原始碼模型
OpenHarmony 3.1 Release版本關鍵特性解析——ArkUI框架又有哪些新增能力？
2022-06-07
UI框架
大語言模型中上下文視窗理解和實現原理
2024-06-18
模型
微調大模型，AMD MI300X就夠了！跟著這篇部落格微調Llama 3.1 405B，效果媲美H100
2024-10-08
大模型
Laravel中的多語言
2024-05-23
Laravel
iOS 多國語言本地化與App內語言切換（Swift）
2018-11-26
iOSAPPSwift
Go 語言的詞法分析和語法分析(2)—Import宣告的解析
2021-03-26
Go詞法分析語法分析Import
Golang | Go語言多型的實現與interface使用
2020-07-31
Golang多型
LLM大語言模型-ChatGPT、LLaMA、ChatGLM、文心一言、通義千問
2024-07-25
模型ChatGPT
Go語言封裝、繼承、介面、多型和斷言的案例
2019-08-19
Go封裝繼承多型
基於Llama-3的OpenBioLLM-70B和8B：在醫療領域優於GPT-4
2024-04-28
GPT
本地部署Llama3-8B/70B 並進行邏輯推理測試
2024-04-20
Pinterest與FB消費能力對比：圖片勝於語言
2012-06-01
REST
集眾之長，一種包含多種語言模型的混合框架
2018-07-09
模型框架
Mac上LLAMA2大語言模型安裝到使用
2024-03-07
Mac模型
go語言與c語言的相互呼叫
2019-04-09
GoC語言
多語言遇到的問題
2019-05-11
Swift多語言版本的建立
2017-12-14
Swift
OAF多語言的實現
2015-09-24
用無上下文的Go語言實現HTTP服務
2022-04-09
GoHTTP
大語言模型湧現欺騙能力
2024-06-05
模型
歡迎 Llama 3：Meta 的新一代開源大語言模型
2024-04-23
模型