使用 Meta Llama 家族模型构建生成式 AI 应用：Llama 3.1 与 Llama 3.2 实战指南

本文以 Generative AI for Beginners 课程第 21 课的 孟加拉语译文版 为底本，对应课程英文原版 Building With the Meta Family Models。文章系统梳理 Meta「Llama 家族」中两大主力模型 —— Llama 3.1（文本/工具调用）与 Llama 3.2（多模态视觉）—— 的模型变体、核心能力边界与适用场景，并给出可直接运行的 Azure AI Inference SDK 代码示例。读者学完后，将掌握：如何通过统一推理端点调用 Llama 3.1 触发原生函数/工具调用、如何用 Llama 3.2 的视觉能力完成图文联合输入推理，以及如何在本仓库环境中配置模型凭证并逐行验证效果。

仓库中的这一课：底本、英文版与配套 Notebook

本课在仓库中的英文正本是 21-meta/README.md，孟加拉语译文 是它的翻译副本；两者在概念与代码上同源，区别主要在调用环境上：孟加拉语底本仍保留早期基于 GitHub Models 的写法（GITHUB_TOKEN 与 https://models.inference.ai.azure.com 端点），而英文正本与本仓库配套的 githubmodels-assignment.ipynb 已迁移到 Microsoft Foundry 环境的 AZURE_INFERENCE_CREDENTIAL / AZURE_INFERENCE_ENDPOINT 变量。课程总览 README.md 将第 21 课定位为："The features and differences of the Meta Family Models"（Meta 家族模型的功能与差异），与本篇内容一一对应。

在仓库的课程坐标系中，本课承前启后：第 02 课 02-exploring-and-comparing-different-llms/README.md 已把 Llama 归类为「开源/开放权重」模型阵营并给出选型原则，本课则深入到具体型号的工程使用；后续第 11 课（函数调用）、15 课（RAG 与向量数据库）、18 课（微调） 所讲的能力，恰好对应本课点出的三大高阶应用场景。

Meta 模型家族与可用模型变体

本课聚焦 Meta「Llama 群（Llama Herd）」中的两款模型：Llama 3.1 与 Llama 3.2。它们都派生自早期开源模型 Llama 3，但在能力方向上分化为「文本 + 工具调用」与「多模态视觉」两条路线，并在模型中各提供一个参数规模较大的旗舰档：

模型	变体	类型	本课关注点
Llama 3.1	70B Instruct	纯文本 LLM	原生函数调用、长上下文、RAG
Llama 3.1	405B Instruct	纯文本 LLM	旗舰级开源模型、综合文本任务
Llama 3.2	11B Vision Instruct	多模态（文本 + 图像）	灵活的视觉推理部署档
Llama 3.2	90B Vision Instruct	多模态（文本 + 图像）	本文代码示例所使用的模型
Llama 3.2	1B / 3B	纯文本	边缘/移动端低延迟部署（本课提及）

说明：更早的 Llama 3 也出现在模型目录中，但本课不展开讨论；各版本大小写不同的模型名（如 meta-llama-3.1-405b-instruct 与 Meta-Llama-3.1-405B-Instruct）指向同一模型的旧/新目录命名，调用时以你所使用端点的目录实际为准。

在运行本课示例前，需要先完成环境准备。仓库的 00-course-setup/02-setup-local.md 与 03-providers.md 给出了完整指引：创建一个 .env 文件，写入 AZURE_INFERENCE_ENDPOINT（项目端点）与 AZURE_INFERENCE_CREDENTIAL（项目 API Key），然后在代码中用 os.getenv 读取。需要特别留意的是，仓库多处（含 03-providers.md）明确提示：GitHub Models 将于 2026 年 7 月底退役，其 GITHUB_TOKEN 变量将不再可用，应改用 Microsoft Foundry 的统一端点与密钥。

Llama 3.1：405B 级开源 LLM 的三大能力跃迁

Llama 3.1 的旗舰版拥有 4050 亿（405B）参数，属于开源 LLM 类别。它被视为对前代 Llama 3 的一次直接升级，本课从三个可量化的维度说明升级点：

• 更长的上下文窗口 —— 128k tokens（Llama 3 为 8k tokens），16 倍提升；
• 更大的最大输出 tokens —— 4096（Llama 3 为 2048），翻倍；
• 更强的多语言支持 —— 源于训练 tokens 数量的大幅增加。

这三项基础能力的提升，直接支撑起构建生成式 AI 应用时的三类复杂用例：

• 原生函数调用（Native Function Calling）：让模型在自身工作流之外调用外部工具与函数；
• 更优的 RAG 表现：更大上下文窗口可容纳更多检索片段与引用；
• 合成数据生成：为微调等任务构造高质量有效数据，与 18 课微调 的训练数据准备形成呼应。

原生函数调用：内置 Brave Search 与 Wolfram Alpha

所谓「原生函数调用」，指 Llama 3.1 在指令微调阶段被专门强化，模型能根据用户提示自主判断「该调用哪个函数」。本课文档给出了两个模型内置可识别调用的工具：

• Brave Search：通过网页搜索获取实时信息（如天气）；
• Wolfram Alpha：完成复杂数学计算，避免开发者自行编写数学函数。

此外，你也可以创建自定义工具并让 LLM 按需调用——这一点与仓库第 11 课函数调用 的完整工具注册与执行回路互补：本课展示的是「模型主动发起调用」的前半段（声明工具 → 模型决策 → 输出调用文本），第 11 课则负责把模型输出真正路由到你的业务函数并回传结果。

触发函数调用的完整代码

下面的示例（源自本课文档与配套 githubmodels-assignment.ipynb，按当前 Foundry 环境变量改写）做了三件事：

1. 在系统提示中声明可用工具 brave_search, wolfram_alpha；
2. 发送一个询问某城市天气的用户提示；
3. 期望模型返回形如 <|python_tag|>brave_search.call(query="Stockholm weather") 的工具调用文本。

# 运行前：pip install azure-core azure-ai-inference
import os
from azure.ai.inference import ChatCompletionsClient
from azure.ai.inference.models import AssistantMessage, SystemMessage, UserMessage
from azure.core.credentials import AzureKeyCredential

# 这些值来自你的 Microsoft Foundry 项目 "Overview" 页面（见 00-course-setup/02-setup-local.md）
token = os.environ["AZURE_INFERENCE_CREDENTIAL"]
endpoint = os.environ["AZURE_INFERENCE_ENDPOINT"]
model_name = "Meta-Llama-3.1-405B-Instruct"

client = ChatCompletionsClient(
    endpoint=endpoint,
    credential=AzureKeyCredential(token),
)

tool_prompt = f"""
<|begin_of_text|><|start_header_id|>system<|end_header_id|>

Environment: ipython
Tools: brave_search, wolfram_alpha
Cutting Knowledge Date: December 2023
Today Date: 23 July 2024

You are a helpful assistant<|eot_id|>
"""

messages = [
    SystemMessage(content=tool_prompt),
    UserMessage(content="What is the weather in Stockholm?"),
]

response = client.complete(messages=messages, model=model_name)

print(response.choices[0].message.content)

对提示词逐段解读，会发现它正是 Llama 3.1「内建工具模式」的标准结构：

• 首尾的 <|begin_of_text|>、<|start_header_id|>system<|end_header_id|>、<|eot_id|> 是 Llama 3 系列的特殊 token，用于标记消息边界，正文不能省略，否则模型可能无法正确识别系统角色；
• Environment: ipython 声明运行环境，告诉模型它可以按代码执行工具调用的方式输出；
• Tools: brave_search, wolfram_alpha 是工具白名单，模型只会在其中挑选；
• Cutting Knowledge Date / Today Date 两项时间信息帮助模型判断哪些知识需要实时检索（这正是天气类问题要走搜索的原因）。

值得反复强调的是本课文档随代码给出的重要提示：该示例只产生「工具调用」本身，并不会真的返回搜索结果。若想拿到真实结果，你需要到 Brave API 注册免费账号、取得密钥并自行实现 brave_search 函数——即把模型产出的调用文本真正执行一遍，再作为新消息回传给模型，这与第 11 课 的完整循环一致。

兼容旧的 GitHub Models 写法

若你的账号仍在使用 GitHub Models（退役前），孟加拉语底本中对应的历史写法为：

token = os.environ["GITHUB_TOKEN"]
endpoint = "https://models.inference.ai.azure.com"
model_name = "meta-llama-3.1-405b-instruct"

其余导入与调用逻辑完全一致。在仓库当前语境下，建议直接采用上文的 Foundry 变量写法，避免后续迁移成本。

Llama 3.2：开源模型的多模态能力补位

尽管 Llama 3.1 是强大的 LLM，它仍有一个明显短板：不具备多模态能力——无法把图像等非文本输入作为提示，也无法基于它们给出回答。本课明确指出，这种图文同读的能力正是 Llama 3.2 的核心卖点之一，配套特性还包括：

• 多模态（Multimodality）：可同时评估文本与图像两类提示；
• 中小规格视觉变体（11B / 90B）：为灵活部署提供多种档位；
• 纯文本变体（1B / 3B）：可部署到边缘/移动设备，获得低延迟推理。

多模态支持被本课形容为开源模型世界的重要一步——此前这类能力多被封闭商用模型垄断。在微软 Foundry 的统一推理端点下，调用 Llama 3.2 视觉模型与调用文本模型共用同一套 ChatCompletionsClient，差异只在消息内容结构上。

用 Llama 3.2 90B 做图文联合分析

下面的代码（同样来自 githubmodels-assignment.ipynb）把一张本地图片 sample.jpg 与文本问题一起发给 Llama-3.2-90B-Vision-Instruct，获得对图像的详细描述：

import os
from azure.ai.inference import ChatCompletionsClient
from azure.ai.inference.models import (
    SystemMessage,
    UserMessage,
    TextContentItem,
    ImageContentItem,
    ImageUrl,
    ImageDetailLevel,
)
from azure.core.credentials import AzureKeyCredential

# 这些值来自你的 Microsoft Foundry 项目 "Overview" 页面
token = os.environ["AZURE_INFERENCE_CREDENTIAL"]
endpoint = os.environ["AZURE_INFERENCE_ENDPOINT"]
model_name = "Llama-3.2-90B-Vision-Instruct"

client = ChatCompletionsClient(
    endpoint=endpoint,
    credential=AzureKeyCredential(token),
)

response = client.complete(
    messages=[
        SystemMessage(
            content="You are a helpful assistant that describes images in details."
        ),
        UserMessage(
            content=[
                TextContentItem(text="What's in this image?"),
                ImageContentItem(
                    image_url=ImageUrl.load(
                        image_file="sample.jpg",
                        image_format="jpg",
                        detail=ImageDetailLevel.LOW)
                ),
            ],
        ),
    ],
    model=model_name,
)

print(response.choices[0].message.content)

与纯文本请求相比，这里的消息结构有三个关键差异值得记录：

1. UserMessage.content 不再是一个字符串，而是 TextContentItem（文本片段）与 ImageContentItem（图像片段）组成的列表，支持图文混排；
2. ImageUrl.load(image_file="sample.jpg", image_format="jpg") 负责从本地加载图片并指明格式，仓库已将示例输入图放在 21-meta/python/sample.jpg；
3. detail=ImageDetailLevel.LOW 控制图像送入模型的细节级别，LOW 档即可满足「画面里有什么」这类全局描述，且消耗的视觉 tokens 更少；如果要做细粒度 OCR 或文字识别类任务，可评估更高级别。

系统提示被设定为 "You are a helpful assistant that describes images in details."（你是一个会详细描述图像的助手），这种任务型系统提示能显著收敛输出风格。本课通过它演示了典型的多模态问答流程，而仓库第 09 课图像应用 则展示了相反方向的图像生成，二者共同覆盖了「看图说话」与「依文生图」两条主链路。

部署档位选择：从云端旗舰到边缘低延迟

本课对两个模型族的版本设计给出了一条清晰的选型线索：

• 追求上限用旗舰档：Llama 3.1 405B 拥有最大上下文与最强的工具/文本能力，适合作为云端主力模型处理复杂任务；
• 视觉推理用 Vision 档：Llama 3.2 11B 与 90B 在「视觉-语言」能力相同的前提下拉开参数差距，可按 GPU 预算与吞吐要求二选一；
• 边缘部署用 1B/3B 纯文本档：它们体量小、延迟低，可运行在手机等设备上做本地推理。

这与第 02 课 所强调的选型纪律一致：不要只按发布先后或参数规模做决定，而应把上下文窗口、多模态支持、工具调用、延迟与部署约束放在一起权衡。

常见问题与排查要点

围绕本课两个代码示例，有几个高频问题及其在仓库中的对应答案：

• KeyError: AZURE_INFERENCE_CREDENTIAL：环境变量未注入。请参考 00-course-setup/02-setup-local.md 中创建 .env 并加载变量的步骤，确认变量名拼写与 Foundry 项目 Overview 页面一致。
• 模型返回普通文本而非工具调用：检查系统提示是否完整保留 <|begin_of_text|> 与 <|eot_id|> 特殊 token，并确认 Tools: 一行列出了全部允许的工具名。
• 图片路径 sample.jpg 找不到：示例假定运行目录下存在该文件，仓库副本位于 21-meta/python/sample.jpg，可把 image_file 改为实际相对/绝对路径。
• 用的是旧版 GITHUB_TOKEN 写法：见本文「兼容旧的 GitHub Models 写法」小节，按仓库当前推荐迁移到 Foundry 变量。

小结：把 Llama 家族放进你的工具箱

从本课可以提炼出三个可直接落地的结论：

1. Llama 3.1 以 128k 上下文 + 原生函数调用见长，适合知识密集型 RAG 与需要「模型自主决定调用外部能力」的 Agent 型应用，其输出 工具名.call(...) 的调用文本可作为衔接第 11 课 工具执行层的输入契约。
2. Llama 3.2 把多模态带进了开源世界，90B/11B Vision 变体可直接消费图文复合提示，配合 sample.jpg 这类真实输入即可完成视觉理解闭环。
3. 统一推理端点大幅降低了上手成本：无论文本还是视觉模型，都只需一套 ChatCompletionsClient 与两个环境变量，这也是整个课程从 GitHub Models 平滑迁移到 Microsoft Foundry 后的推荐姿势。

在编写本课译文底本到英文正本的更新过程中，孟加拉语版保留了早期 GitHub Models 的环境写法，而英文正本与配套 Notebook 已先行切换到 Foundry 变量——阅读本课时以英文正本 21-meta/README.md 为最新依据，并在实际运行前对照 环境准备文档 完成凭证配置即可。