直播测试与硬件环境介绍

本次直播旨在验证在本地硬件上运行大语言模型（LLM）微调工作流的可行性。主播首先进行了音频和画面的测试，确认观众可以正常收听并看到屏幕内容。虽然主播表示很久没有进行直播，操作略显生疏，但整体流媒体连接稳定。此次演示的核心硬件是 NVIDIA DGX Spark，这是一台由 NVIDIA 提供的开发设备，主播对其性能持开放态度，表示将如实评价其表现。该设备的市场价格为 3,999 USD，虽然价格不菲，但作为测试平台，其便携性和集成度对于本地 AI 开发具有重要意义。主播强调，本次测试的目标是验证此前在 Google Colab 上跑通的微调流程，能否成功迁移并运行在本地硬件上，从而摆脱对云端算力的依赖。

"They actually didn't tell me what to say, so I'm just going to tell you if it's good or not."

为了展示 DGX Spark 的基础算力，主播首先运行了一个图像分割模型 EOM MT。这是一个基于 Transformer 编码器的分割模型，主播指出它在处理图像分割任务时速度非常快。通过展示一张包含主播及其妻子的照片的分割结果，以及后续对纽约街景的处理，主播证实了代码能够在该设备上顺利运行且延迟可控。这一环节不仅验证了硬件的图形处理能力，也为后续的语言模型微调奠定了环境基础。主播还提到，他正在学习柔术，并幽默地表示希望未来能开设“机器学习烹饪秀”类的直播，将复杂的 AI 流程比作烹饪，使内容更易于理解。

微调动机与小语言模型的选择

本次微调的核心目标是训练一个 小语言模型（SLM），具体选用的是 Google 发布的 Gemma 3 270M 指令微调版模型。选择小模型而非大型商业 API 模型，主要基于以下几个关键考量：首先，对于特定任务，小模型足以胜任，无需调用庞大的通用模型；其次，使用本地模型可以 避免支付昂贵的 API 费用，降低长期运营成本；第三，也是最重要的一点，本地运行可以 确保数据隐私，防止敏感数据泄露到第三方服务器。主播指出，如果拥有自己的模型，用户可以在任何地方、任何设备上自由运行，拥有完全的控制权。

"We want small model for a specific task eg don't want to pay API credits or leak our data online."

主播进一步解释了为何选择微调而非检索增强生成（RAG）。当任务非常具体且明确时，例如将 LLM 用作特定的语言处理工具，微调是更优的选择。RAG 更适合需要实时检索外部知识库的场景，而微调则是让模型内化特定的知识或行为模式。本次演示的具体任务是 从文本中提取食物和饮料项目。假设有一大批图像描述数据，需要过滤出与食物相关的内容以用于开发食品类应用，微调一个专门擅长此任务的小模型比使用通用大模型加 RAG 更高效、更精准。这种场景下，模型不需要具备广泛的常识，只需要精通“提取食物名称”这一单一任务。

技术栈搭建与监督微调（SFT）原理

为了实现上述目标，主播选择了 TRL（Transformers Reinforcement Learning） 库作为核心工具。TRL 是基于 Hugging Face Transformers 库构建的，专门用于大模型的微调、强化学习对齐等高级操作。主播在 Jupyter Notebook 中首先检查了环境，确认已安装 transformers 库，但尚未安装 trl。由于直播环境需要谨慎处理 GitHub 凭证以防密码泄露，主播登录 GitHub 后，使用 UV 包管理器（因其速度快且体验好）安装了 TRL 库。安装完成后，重启 Notebook 以加载新库，为后续代码执行做好准备。

本次采用的微调方法是 监督微调（Supervised Fine-Tuning, SFT）。SFT 的基本原理是提供输入-输出样本对，让模型学习从特定输入映射到特定输出的规律。主播举了一个简单的例子：如果目标是提取人名，输入是 "Hello, my name is Daniel"，对应的输出就是 "Daniel"。通过大量这样的样本训练，模型就能学会在类似语境下准确提取目标信息。本次微调的“食材”包括：1. 基础模型 Gemma 3 270M；2. 预构建的数据集，专门用于从文本中提取食物信息。主播将这些步骤比作烹饪，强调每一步都需要精确的“配料”和“火候”，即正确的库版本和数据格式。

"We are going to do supervised fine-tuning which is also known as SFT which is basically SFT = give samples of inputs and outputs."

在代码层面，主播开始编写微调脚本。他选择直接在 Notebook 中编写代码，以便实时查看每一步的输出和错误信息，而不是写成独立的脚本文件。他导入了必要的库，并准备定义模型加载参数。整个环境配置过程展示了现代 AI 开发的高效性：通过简单的几行命令，即可在本地设备上搭建起完整的微调环境。主播还提到，他的同事就在旁边工作，这种“边工作边直播”的场景也反映了 AI 开发在日常办公中的普及化趋势。

微调与RAG的核心场景辨析

在开始技术实操之前，必须明确微调（Fine-tuning）与检索增强生成（RAG）在业务逻辑上的本质区别。微调适用于那些定义明确、需要高频重复执行的特定任务，其核心在于让模型掌握某种固定的输出格式或行为模式。相比之下，RAG 的核心在于向大语言模型注入自定义知识库，使其能够基于最新或私有文档生成回答，而非改变模型本身的参数权重。

"Fine-tuning equals an example would be you're an insurance company who gets 10,000 emails a day and you want to extract structured data directly from these emails to JSON."

以保险公司为例，若每天收到一万封邮件并需将其提取为JSON格式，这属于典型的结构化数据提取任务，适合通过微调实现自动化。而在RAG场景中，当用户询问如“栅栏坏了”这类问题时，系统并非从模型内部记忆提取答案，而是检索内部文档库，将相关支持信息链接或内容注入提示词中，从而生成包含官方文档依据的回复。这种区分决定了后续数据准备和训练策略的根本不同。

项目架构与工具链准备

本次教程采用端到端（End-to-End）的教学方法，旨在最终产出一个可交互的演示原型。整个工作流程被拆解为七个标准化步骤：首先下载模型和数据集，随后检查数据集质量，接着在数据集上训练模型，之后对模型进行评估，最后启动交互式演示。作为加分项，还可以将演示部署到公共平台供他人使用。

"We need some training code, eval code and then demo. So our method is going to be one download model, two download data set, three inspect data set and then four train model on data set."

在工具链选择上，本项目主要依赖 Hugging Face 生态体系。模型加载使用 transformers 库，数据集管理使用 datasets 库，微调框架采用 TRL (Transformer Reinforcement Learning)，评估环节同样基于 Hugging Face 的标准流程，而交互式演示则使用 Gradio 构建。最终部署目标为 Hugging Face Spaces，确保教程的完整性和可复现性。

模型选型与硬件环境配置

在模型选择上，本教程选用 Gemma 3 270M 作为基础模型。尽管 Hugging Face 上存在其他表现更优的模型（如 Baguetteron 或 Qwen 系列），但 Gemma 3 270M 仅包含 2.7亿参数，模型大小约为 536MB，非常适合在资源受限的环境中进行快速验证和文本处理任务，无需追求极致的知识广度。

"I'm just using Gemma 270 mil because this is quite a small model, 536 megabytes. There are other models out there like um baguetteron model hugging face which apparently works better."

在硬件环境配置阶段，遇到了 PyTorch CUDA 不可用 的问题。初始检查发现 torch.cuda.is_available() 返回 False，导致系统回退到 CPU 模式。为解决此问题，必须确保安装支持 CUDA 的 PyTorch 版本，因为 CUDA 是运行 NVIDIA GPU 加速模型的关键依赖，否则模型推理速度将极其缓慢。经过重新安装适配 Linux 的 PyTorch CUDA 版本后，成功恢复了 GPU 加速能力。作者强调，本次教程将手动编写代码而非依赖 AI 辅助工具，以便深入理解底层逻辑，为后续使用 AI 编码工具打下基础。

模型名称 参数量 模型大小/备注 适用场景/特点
Gemma 3 270 Million 536 MB 轻量级，适合快速验证和文本处理
Baguetteron 321 Million 信息不足 据称性能优于 Gemma，但未在本教程测试
Qwen 3 600 Million 信息不足 较大参数规模，知识库更丰富
Monad 信息不足 比 Gemma 小 6 倍 未来实验候选，体积更小

构建食品提取数据集与合成标注策略

本项目的核心目标是微调小型语言模型（如Gemma 3），使其能够从文本中高效提取结构化数据，从而复现大型语言模型的处理能力。为了实现这一目标，作者使用了GPT-OSS-120B作为标注工具，合成了约一千条文本序列。这些序列涵盖了关于食品或非食品的各种描述，旨在让模型学习如何识别并提取其中的食品项目。这种方法的灵活性在于，LLM能够接受任何类型的文本输入，并生成结构化的输出，这在处理大规模数据库过滤（如Neutrify应用中的食品图像或文本过滤）时具有显著优势。

"I've got GPTO OSS120B to synthetically label uh about a thousand or so sequences of text whether they be about food or not and to extract uh different items food items from that."

在实际应用中，这种技术不仅限于食品行业。企业可以利用类似的方法从保险索赔、金融报告等特定文本中提取公司名称或其他关键结构化数据。通过这种方式，小型LLM可以替代大型模型执行特定的数据提取任务，从而降低计算成本并提高部署效率。作者强调，这种从非结构化文本到结构化数据的转换，是构建自动化数据处理流水线的关键步骤。

数据格式转换：从原始文本到结构化JSON

为了让模型理解任务，需要将原始文本输入转换为明确的输入输出对。作者展示了具体的处理流程：首先获取随机采样的文本序列作为输入，然后使用GPT-OSS-120B生成的JSON格式作为标签（Ground Truth）。在代码实现中，通过print(info)查看原始输入和输出示例，确保模型能够理解从原始字符串到JSON对象的映射关系。

例如，一段描述“手持橙色盖子的玻璃罐，内含芥末籽基调味品”的文本，其对应的结构化输出包含is_food_or_drink: true以及详细的成分列表（如芥末籽、盐、糖、姜黄等）。另一个例子描述了黄瓜、苹果和甜甜圈，模型成功提取了这些食品项目。这种近乎玩具问题的案例验证了数据格式的可行性，但为了实际应用，需要确保模型能够处理更复杂或噪声较大的数据，如图像标题中的乱码（如“11111.tiff”），此时模型应输出is_food_or_drink: false。

优化输出效率：压缩数据与Token控制

在微调过程中，减少输出Token的数量是提升推理速度的关键策略。作者引入了“压缩版本”（condensed version）的概念，即去除JSON格式中的多余字符和换行符，仅保留核心数据。虽然压缩后的格式类似YAML，但它可以轻松转换为JSON供后续处理。

"The condensed version is less output tokens. So when we're fine-tuning an LLM, uh the less output tokens basically the better because that is going to be our constraint is how fast."

通过减少每个样本的输出Token，可以显著缩短生成时间，从而加快整个微调过程和后续的推理速度。作者指出，如果模型能够以更少的Token完成相同的提取任务，那么整体处理效率将得到提升。这种优化对于需要在资源受限环境（如边缘设备或低成本服务器）上部署模型的场景尤为重要。通过对比原始JSON和压缩后的文本，作者展示了如何在保持数据完整性的同时，最小化模型的输出负担。

硬件对比直觉与数据格式化准备

在硬件选择方面，作者初步直觉认为，自建PC（配备RTX 4090）可能在纯计算速度上优于DGX Spark，因为RTX 4090拥有更高的显存带宽和计算核心。然而，DGX Spark的优势在于其128GB的VRAM，远超RTX 4090的24GB，这使得它能够轻松加载和微调更大的模型，且具备“即插即用”的便利性。

硬件配置 显存 (VRAM) 主要优势 潜在劣势
DGX Spark 128 GB 大显存支持大模型，即插即用，便携性 具体计算速度待验证，可能受限于功耗墙
自建PC (RTX 4090) 24 GB 高计算性能，可能更快的微调速度 显存较小，难以加载超大模型，需自行组装

在正式微调之前，必须对数据进行格式化。LLM通常不接受原始的键值对，而是需要特定的对话格式（如system和user角色分离）。作者参考Hugging Face的TRL文档，将数据转换为包含系统提示（System Prompt）和用户输入（User Input）的结构。例如，系统提示定义模型角色，用户输入提供待处理的文本。这种标准化的数据格式是确保微调成功的关键，它将非结构化的提取任务转化为模型熟悉的指令遵循任务。

微调任务的数据格式基础与核心逻辑

在进行大语言模型（LLM）的微调或从头训练时，首要且最关键的步骤是理解并掌握数据集的格式规范。对于希望模型执行特定任务的微调场景，数据格式的标准化是机器学习模型入门的核心环节。数据集的结构通常被分类为标准格式（Standard）或对话格式（Conversational），而具体的类型则与任务目标紧密相关，例如仅提示（Prompt-only）、偏好对齐（Preference）或语言建模（Language Modeling）。每种类型都由特定的列结构组成，以适应其设计用途。

"A lot of jargon there. I understand it via just inputs and outputs. What inputs do you have? What outputs do you want?"

为了简化这一复杂概念，可以将所有机器学习问题归结为输入与输出的映射关系。在当前的项目中，团队决定采用语言建模（Language Modeling）风格，这意味着输入将是用户提供的文本字符串，而输出则是模型生成的、符合特定结构化要求的内容。这种选择旨在让模型学会从非结构化文本中提取并输出结构化的数据，而非简单的提示补全或偏好排序。

数据集构建：从原始文本到对话格式

数据集的具体构建过程涉及将原始数据转换为模型可理解的消息（Messages）格式。在代码实现中，数据被组织为包含role（角色）和content（内容）的列表。其中，role为user的部分承载了原始的输入序列，而role为system或assistant的部分则承载了模型的标签（Labels）。这些标签并非人工标注，而是通过合成数据生成技术获得。

"I've synthetically labeled all of this with GPT-4o OSS 120B because it's basically one of the best open source models that are available."

这一过程利用了2026年AI开发的显著优势：数据生成的自动化。过去，数据标注是创建自定义模型的最大瓶颈，而现在可以利用像GPT-4o这样的高质量开源模型来合成标注数据。所有涉及的模型、数据集以及合成样本均保持完全开源。这种自动化不仅加速了数据准备流程，还确保了数据的一致性和高质量，为后续的微调奠定了坚实基础。

案例演示：文本到JSON的结构化提取

为了验证数据格式的有效性，演示了一个具体的结构化数据提取案例，目标是从长文本中提取食物和饮料项目并转换为JSON格式。原始输入是一段详细的图像描述文本，其中包含了多种食材名称，如“白山药”、“叉烧猪肉”和“红帝鱼”。

任务类型 输入格式 输出格式 数据来源 标注方式
结构化提取 自然语言文本 JSON对象 Hugging Face数据集 GPT-4o合成

在对话格式中，用户输入包含完整的描述文本，而助手（模型）的输出则是提取后的JSON数据及相关的标签（如食物标签、饮料标签）。虽然ChatGPT等大模型能轻松完成此任务，但本项目的目标是训练一个小型本地LLM，使其具备同样的能力，从而摆脱对大型云端模型的依赖。通过将原始文本与合成标签配对，模型将学习如何从复杂的文本语境中精准识别并提取关键实体，实现从非结构化文本到结构化数据的自动化转换。

硬件讨论与未来规划

在数据处理的同时，视频还涉及了对硬件性能的讨论。有观众评论指出NVIDIA DGX Spark的内存带宽表现不佳，这可能影响推理速度。对此，演示者承认，对于现代GPU而言，定制PC在推理任务上确实会更快，但DGX Spark更适合本地实验和开发环境。

"Custom PC if you have a modern GPU will be much faster at inference. DJX Spark is better at local experiments."

为了提升未来的开发能力，演示者提出了一个具体的硬件升级目标：获取一张RTX Pro 6000显卡。该显卡在澳大利亚的售价约为14,000澳元。演示者承诺，如果通过直播获得该显卡，将投入超过100小时的直播开发时间，并计划发布更多开源模型。这一目标不仅是为了提升硬件性能，更是为了促进社区协作，通过公开工作成果让社区受益。

"If I do over 100 hours of streaming with the Pro 6000, then I can keep it. So that's my deal."

这一计划旨在通过高强度的本地AI开发直播，展示如何利用现有资源进行模型微调，并最终将成果开源至Hugging Face，供社区使用。

数据标注与格式映射的初步尝试

在微调大语言模型（LLM）之前，首要任务是确保训练数据的准确性与格式的一致性。视频以“白葡萄酒醋”为例，探讨了数据标注中的语义歧义问题。虽然白葡萄酒醋通常被视为食品配料，但在特定语境下可能被错误分类。作者指出，数据标注的准确性直接决定了模型的学习效果，因此需要仔细定义标签体系。例如，是将其归类为“饮品”还是“食品成分”，这取决于具体的应用场景。通过编写函数将样本映射到对话格式（conversation style），可以标准化数据输入。这一过程涉及将原始数据转换为模型可理解的 messages 结构，确保每条数据都包含用户输入和预期回复。这种精细化的预处理步骤虽然繁琐，但是构建高质量微调数据集的基础，避免了因数据噪声导致的模型性能下降。

数据集划分与机器学习核心原则

完成数据格式化后，下一步是将数据集划分为训练集和测试集。作者使用 Hugging Face 的 datasets 库，通过 train_test_split 函数，设置测试集比例为 0.2，不打乱数据顺序（shuffle=false），并固定随机种子为 42。这一操作遵循了机器学习的黄金法则：始终在训练集上进行训练，在测试集上进行评估。作者强调，许多商业模型发布的基准测试（Benchmarks）可能存在数据泄露风险，即测试数据可能已包含在训练数据中。例如，Gemini 3 等模型的基准测试结果虽然亮眼，但若未严格隔离测试集，其真实泛化能力存疑。因此，创建专属的测试集是验证模型在真实世界中表现的关键，而非仅仅依赖公开的基准测试分数。这有助于防止模型“死记硬背”测试题，从而更准确地评估其在生产环境中的实际效能。

输入提示词构建与特殊 Token 解析

在将数据送入模型前，必须正确构建输入提示词（Input Prompt）。作者演示了如何将格式化后的对话数据转换为模型可接受的文本格式。这一过程涉及添加特殊的控制 Token，如 BOS（Begin of Sentence，句子开始）、<|start_of_turn|>user（用户回合开始）、<|end_of_turn|>（回合结束）以及 <|start_of_turn|>model（模型回合开始）。这些特殊 Token 是 LLM 训练数据的一部分，模型通过它们识别对话的边界和角色。作者指出，理解这些底层 Token 机制对于调试和优化模型输出至关重要。虽然可以使用 AI 自动生成代码，但手动理解每个步骤有助于在出现问题时快速定位原因。例如，当模型输出异常时，检查 Token 是否正确嵌入是首要排查步骤。这种对细节的掌控，是构建可靠本地 AI 应用的核心能力。

本地 AI 的优势与未来展望

视频最后探讨了本地运行小模型的优势及未来趋势。作者认为，2024 年是本地 AI 的元年，随着 NVIDIA DGX Spark、Apple M4 等硬件以及 Hugging Face 等工具链的成熟，个人开发者构建和发布自定义模型的条件已具备。本地 AI 的核心优势在于数据隐私保护和离线运行能力。例如，特斯拉自动驾驶汽车需要在无网络连接的情况下实时处理数据，这要求 AI 模型必须能在本地高效运行。作者计划通过本地微调，创建针对特定任务的小模型，并发布到 Hugging Face 社区。这不仅避免了将敏感数据发送给大型科技公司，还降低了延迟和运营成本。通过掌握从数据预处理到模型部署的全流程，开发者能够更灵活地定制 AI 解决方案，满足特定场景的需求。

本地推理：2.7亿参数模型的极速体验

视频主角Daniel展示了一个仅270M参数、文件大小为500MB的本地大语言模型（LLM）在NVIDIA DGX Spark设备上的运行表现。他首先通过代码加载模型，并输入提示词要求生成一首关于机器学习的诗歌。整个推理过程极其迅速，生成时间不到一秒，展现了小模型在边缘设备上的高效性。Daniel强调，尽管模型体积小，但其响应速度令人惊叹，这在几年前是难以想象的。

"Look at that. Under a second. Please reply to me with a machine learning palm."

生成的诗歌内容虽然简单，但成功完成了任务。Daniel指出，重点不在于诗歌质量，而在于模型能否执行指令。他通过代码提取生成的文本，并打印出输入提示与输出结果，验证了模型的基础对话能力。这种快速响应证明了本地部署小模型在实时交互场景中的可行性，无需依赖云端API即可实现低延迟的内容生成。

数据预处理与模板应用

为了进行微调测试，Daniel引入了一个包含多种文本样本的数据集。他编写代码从数据集中随机抽取一个样本，例如描述“低卡肉桂卷慕斯”的文本。关键在于应用聊天模板（Chat Template），将原始文本转换为模型可理解的格式。他使用tokenizer.apply_chat_template函数，将消息转换为输入提示（Input Prompt）。

在此过程中，Daniel特别指出需要移除标签（Label），即模型不应看到预期的输出内容，而应仅根据输入生成预测。他通过设置tokenize=False查看原始文本结构，确保输入提示仅包含用户指令和上下文，而不包含模型应生成的答案。这种预处理步骤是微调前的必要环节，旨在模拟真实推理场景，验证基础模型在未微调状态下的默认行为。

基础模型默认行为分析

在未进行微调的情况下，Daniel测试了基础模型对特定输入的反应。他输入了一段关于“日本有My Little Pony主题咖啡馆”的描述，并观察模型的输出。结果显示，模型仅仅是对输入文本进行自然回复，例如表示兴奋并询问用户希望探索的领域。这表明基础模型具备通用的对话能力，但缺乏特定任务的指令遵循能力。

接着，他输入了一段关于“ rustic wooden board”（乡村木板）的图片描述，试图让模型提取食物和饮料项目。然而，模型并未执行提取任务，而是继续生成通用的描述性文本。Daniel指出，基础模型默认行为是回复任意文本输入，而非执行特定的结构化数据提取任务。这凸显了微调的必要性：通过微调，可以将通用模型转化为特定任务专家，如结构化数据提取。

提示工程尝试与微调目标

为了验证是否可以通过提示工程（Prompt Engineering）实现结构化输出，Daniel尝试在输入中注入指令。他修改消息内容，要求模型从图像描述文本中提取食物和饮料项目，并以Python列表形式返回。如果不存在，则返回空列表。他还提供了示例（Few-shot prompting）以引导模型行为。

然而，Daniel明确表示，提示工程并非最终解决方案。他计划通过微调（Fine-tuning）来实现更稳定、更精确的结构化输出。他强调，使用Gemma 2 270M小模型是为了刻意测试小模型在特定任务上的潜力，而非追求通用对话能力。通过对比基础模型的默认回复与微调后的表现，他将展示微调如何将小模型转化为高效的任务专用模型，从而在边缘设备上实现高性能的数据处理。

"We're trying to do fine-tuning to structured output. Let's try to prompt it because that should be your order of operation default and then try to prompt the model."

Daniel的演示清晰地展示了从基础推理到数据预处理，再到默认行为分析，最后到微调目标设定的完整流程。这一过程不仅验证了NVIDIA DGX Spark在小模型部署上的性能，也为后续的微调实验奠定了坚实基础。

提示词注入与结构化数据提取的初步尝试

在本地大语言模型（LLM）的微调过程中，构建高质量的指令微调（SFT）数据集是核心环节。视频演示了如何通过编程方式将原始文本转换为带有明确指令的结构化提示词。具体而言，开发者定义了一个辅助函数 update_input_message_content，其作用是将原始的“输入文本”替换为包含示例（Example）和指令（Instruction）的模板字符串。例如，输入文本 "hello, my name is Daniel" 被转换为要求模型输出 "food items, drink items" 的结构化格式；另一个例子是将午餐描述 "plate of rice cakes, salmon, cottage cheese, and small cherry tomatoes with a cup of tea" 转换为对应的食物和饮品列表。

"We're just giving it a little instruction and we're trying to get our structured data format out from a prompt. Before it was just replying with a default output, but now we're actually giving it uh some structure around it."

通过代码实现，原始内容（如图像描述或简单文本）被注入到提示词模板中，形成新的输入消息。这一过程显著提升了传递给 LLM 的信息密度和结构清晰度。开发者通过 prompt_instruction.replace 方法，将目标输入文本替换为原始内容，并构建包含角色（user）和内容的新输入列表。这种编程式的提示词工程确保了数据格式的一致性，为后续的模型训练奠定了数据基础。

本地微调与 API 调用的场景权衡

在决定使用本地微调还是 API 调用时，数据隐私、网络依赖性和特定用例是关键考量因素。开发者指出，对于通用聊天任务，直接使用 API 是最便捷的方式；但当需要模型执行非常特定的用例（如从非结构化文本中提取结构化数据）时，本地微调成为更优选择。

"If I want a general model, I'll probably just generally go to the chat, the best the best uh API. But if I want a fine-tuned model, I'm going to be wanting to basically just run that locally, do it myself."

视频强调了一个实际案例：某公司需要在无互联网连接的野外环境中运行计算机视觉模型，这要求模型必须在移动设备上运行。虽然这涉及数据创建、模型测试、量化和部署等复杂工作，但本地部署是唯一可行的解决方案。这种对离线能力和特定任务性能的追求，是驱动本地微调需求的核心动力。开发者表示，这种从抽象层（API）下沉到具体实现（本地微调）的过程，虽然工作量大，但能带来最大的技术满足感和业务价值。

小模型性能瓶颈与错误分析

在初步测试中，开发者使用了一个2.7 亿参数的小模型（270M）来执行从文本中提取食物和饮品列表的任务。然而，模型的表现并未达到预期，而是生成了Python 代码而非预期的列表格式。例如，当要求提取 "Rice cakes, salmon, cottage cheese, cherry tomatoes, cup of tea" 时，模型输出了一个 Python 函数，而非简单的列表项。

"The output's outputting... the model because it's only a small model 270 mil it has written a Python function to extract the food and drink items."

这一错误揭示了小模型在指令遵循和格式控制上的局限性。尽管开发者尝试通过提示词工程（Prompt Engineering）来修正，例如将指令改为 "return in the following format. Food items. Item one..."，但模型仍然倾向于生成 Python 代码。这表明，小模型难以理解细微的格式要求，尤其是在缺乏大量训练数据的情况下。开发者指出，错误在机器学习中至关重要，因为它指明了下一步的改进方向。通过对比理想输出与实际输出，开发者确认了微调的必要性：小模型无法仅通过提示词工程完美胜任这一特定任务。

微调前的验证与 JT GPT 对比

为了验证微调的必要性，开发者将相同的提示词输入到了 JT GPT（推测为基于万亿参数的大模型）中。结果显示，大模型能够准确无误地按照要求输出结构化的食物和饮品列表，无需生成代码。这一对比实验清晰地展示了模型规模与指令遵循能力之间的正相关关系。

"This is the exact use case we'd like to fine-tune our model. So it is a small Python model, uh, sorry, small LLM. So it doesn't really understand the nuance of what we're trying to do."

由于小模型无法通过简单的提示词调整达到大模型的效果，监督微调（SFT）成为必然选择。开发者计划通过设置 SFT 配置，使用包含正确格式输出的数据集来训练小模型。这一过程旨在让小模型学习如何直接输出结构化数据，而非生成代码。通过这一系列实验，开发者不仅验证了微调的必要性，还明确了数据集构建的关键点：必须提供正确的格式示例，以纠正小模型的默认行为倾向。

实验配置与训练环境设定

在开始微调之前，作者首先确立了实验追踪机制，使用 Weights and Biases (wandb) 将模型训练过程中的各项指标记录为字典格式，以便后续分析实验结果。配置文件中包含了多个关键超参数，包括 最大序列长度 (max_length)、训练轮数 (epochs) 以及 批量大小 (batch size)。值得注意的是，评估批量大小 (eval batch size) 被设定为 16，作者特别指出这一数值可根据 GPU 的 显存 (VRAM) 容量进行调整，体现了硬件资源对训练配置的直接影响。

"We can just track it as a dictionary. That's going to be something we look at later as well is tracking our experiments."

作者还提到了当前使用的技术生态，表达了对 Hugging Face 和 NVIDIA 的感激之情，认为这两家公司使得使用大型语言模型变得极其容易。此外，作者也提到了 Apple 在端侧模型（如 Epic Max）方面的贡献，以及 Google 的 Gemini 模型。这种对开源和硬件生态的依赖，构成了本次本地微调实验的基础背景。

监督微调 (SFT) 代码实现

进入第二步，作者引入了 SFT Trainer，这是基于 Hugging Face transformers 库中的 Trainer 类封装的专门用于 监督微调 (Supervised Fine-Tuning) 的组件。SFT 的核心逻辑是提供输入样本和期望的输出样本，让模型学习从输入到输出的映射关系。在代码实现中，作者创建了 SFTTrainer 对象，并传入了以下关键参数：

  1. model: 待微调的基础模型。
  2. args: SFT 配置对象，包含超参数设置。
  3. train_dataset: 训练数据集。
  4. eval_dataset: 评估数据集。
  5. processing_class: 分词器 (tokenizer)，用于处理文本输入。

"SFT stands for supervised fine-tuning... create the trainer object."

作者强调，如果代码配置正确（如逗号等语法无误），模型即可开始训练。这次训练的目标是让 Gemma 3 270M 小模型执行特定的 食物提取任务。这是作者首次在 NVIDIA DGX Spark 2 上进行模型训练，此前仅在该硬件上做过推理测试，因此这次训练也是一次对硬件训练性能的实测。

训练过程监控与性能数据

训练启动后，作者通过 nvidia-smi 监控 GPU 状态，显示 GPU 利用率达到 93%，表明硬件资源得到了充分利用。训练预计耗时约 3 分钟，实际运行中风扇噪音轻微，显示出 DGX Spark 在低功耗下的静音表现。随着训练进行，作者观察到 准确率 (Accuracy) 迅速攀升至 60%，同时 损失值 (Loss) 持续下降，验证了模型正在有效学习。

为了量化训练效率，以下是本次实验的关键性能数据记录：

指标项 数值/状态 备注
GPU 利用率 93% 表明计算资源被高效占用
预计训练时间 ~3 分钟 基于初步估算
最终准确率 61% 训练结束时的评估结果
处理 Token 数 246,000 模型在训练过程中看到的 Token 总量
模型大小 270 Million Gemma 3 270M 版本

"Accuracy has gone up. That's cool. Loss has gone down. This is how many number of tokens our model has seen. 246,000."

作者对训练速度表示满意，认为 3 分钟 完成微调比预期更快。期间，作者还引入了“每训练一次做 10 个俯卧撑”的趣味规则，将机器学习与健身结合，增加了直播的互动性。训练完成后，作者计划休息 5 分钟，并准备对微调后的模型进行测试。

数据集结构与微调结果验证

训练所使用的数据集为 food_extract，其核心内容是将图像描述 (image captions) 转换为结构化的 JSON 数据。数据样本包含两个主要部分：输入 (Input) 为图像的文字描述，输出 (Output) 为经过 GPT-4o 120B 标注的结构化食物信息。输出数据包括：

  1. 食物/饮料分类：标记为 1 (是) 或 0 (否)。
  2. 标签 (Tags)：包括食物项、饮料项、食品广告、食品包装等类别。

"These are image captions with a JSON of food information extracted from it."

微调的目标是让 Gemma 3 270M 复现这种从非结构化文本到结构化数据的转换。在微调前，该模型倾向于生成 Python 代码，而非所需的结构化数据。经过 270M 参数的微调，模型在 3 分钟内达到了 61% 的准确率，成功从生成代码转向生成结构化 JSON 数据。这证明了在 NVIDIA DGX Spark 上，即使使用极小的模型，也能通过本地微调快速适应特定任务，且无需依赖外部生成器或云端 API，实现了完全的 本地化 (Local) 和 从 scratch (从零编写代码) 的训练流程。

从通用描述到结构化数据提取的目标

本次微调的核心目的是构建一个能够处理特定领域数据的模型，具体应用场景是为一款名为“Neutrify”的应用服务，该应用旨在识别照片中的食物成分。为了实现这一目标，我们首先定义了一个具体的输入输出示例。输入是一段详细的图像描述，例如：“一张俯视图，展示了一块质朴的木板，上面放着三件不同的物品：去皮白薯被切成厚实的象牙色圆片，表面光滑，等等。”对应的输出则是结构化的JSON数据，包含分类标签（如“食物或饮料”）和具体的食物名称列表（如“去皮白薯”、“深红色的Goju Chang”、“金黄色的Pandas”等）。

"We want to build this app and then but we only want food images. So, we could run it across all of these text items here and then extract all the food items from that."

这种微调策略的价值在于能够处理大规模数据集。例如，我们可以利用包含10亿张图像及其描述的“Data Comp 1B”数据集。虽然数据集庞大，但我们不需要全部使用，而是通过模型筛选出仅包含食物的图像，最终可能只需500万张高质量的食物图像进行训练。这种方法使得模型能够专注于特定领域的结构化数据提取，而非通用的语言生成任务。

训练过程分析与过拟合的辩证看待

在训练过程中，我们密切监控了训练损失（Training Loss）和验证损失（Validation Loss）的变化曲线。结果显示，训练损失持续下降，而验证损失在初始阶段就已经处于较低水平。通常情况下，验证损失低于训练损失可能暗示模型出现了过拟合现象。然而，在大型语言模型（LLM）的特定应用场景中，这种过拟合并不一定是坏事。

"Overfitting in an LLM is not too bad if you have a specific use case for it. For example, if we just want to extract structured data, overfitting is actually probably okay because it just means that the model is outputting to me."

我的直觉认为，对于需要严格遵循固定输出结构的任务（如提取结构化数据），适度的过拟合是可以接受的。因为这意味着模型已经牢固地掌握了我们定义的输出格式和逻辑，能够稳定地生成符合预期的结果。LLM的本质是“输入token，输出token”，只要输入正确，输出就会正确。因此，我们不必过度担心过拟合，反而可以利用它来确保模型在特定任务上的一致性和准确性。

模型保存与加载验证

训练完成后，我们使用Trainer API保存了模型检查点（Checkpoints）。系统自动生成了多个检查点文件，如checkpoint-1、checkpoint-2等，默认加载的是最新的检查点。我们将这些检查点保存下来，以便后续加载和推理。在VS Code环境中，我们重新加载了微调后的模型，并确认其架构与原始的Gemma 3模型保持一致，但底层权重已更新，以适应新的令牌任务。

"Same architecture. All we've done is update the weights behind the scenes to do our token task instead of um its default token task."

为了验证模型效果，我们创建了一个推理管道（Pipeline），使用相同的Tokenizer加载模型，并准备在测试集上进行评估。需要注意的是，我们不能在训练集上进行测试，因为模型已经“见过”这些数据。因此，我们随机选取了测试集中的样本，例如关于阿根廷美食的描述，来检验模型是否能生成与预期一致的结构化输出。这一过程不仅验证了模型的有效性，也让我们对微调后的模型行为有了更直观的认识。

硬件环境与推理测试

本次实验的硬件环境非常独特且高效。我们使用NVIDIA DGX Spark作为主要的计算设备，通过SSH连接进行远程训练和推理。开发者则在Mac Mini上进行代码编写和监控，形成了一种高效的分布式工作流。这种设置使得我们能够在桌面级设备上运行强大的AI训练任务。

"I had a photo of it before. For those wondering, this is what we're running on. So there's my Mac Mini. Um, I'm coding on that and then all the training has been done on the Spark as you can see here via SSH."

在推理测试阶段，我们计划将这一工作流程在NVIDIA RTX 4090显卡上进行对比测试，以评估不同硬件在相同任务下的性能差异。虽然目前尚未在4090上运行完全相同的流程，但这一对比将为后续的性能优化提供重要数据。目前，我们在DGX Spark上进行的初步推理测试显示，模型能够正常加载并生成预测结果，为后续的详细性能基准测试奠定了基础。

微调模型初步测试与结果分析

在 NVIDIA DGX Spark 上成功加载并运行了经过微调的本地大语言模型（LLM）。测试样本显示，模型能够准确识别输入文本中的食品项，如大豆油、大蒜、葱、青柠、鱼露、欧芹和胡椒等，且未出现重复输出。然而，模型在饮料类别的识别上存在遗漏，例如未能正确提取“水”和“青柠汁”。这表明模型在特定类别（饮料）的训练数据覆盖上仍有不足，未来可通过增加相关样本进行优化。

"Our model hasn't seen any of these... It missed a few. Okay. Water and lime juice. Yep, lime juice. It missed that."

尽管存在少量错误，但考虑到该模型仅经过 3分钟 的训练，且训练数据集仅包含 1000个样本，其表现已相当出色。模型能够生成符合预期的结构化输出，证明了在边缘设备上快速微调小模型的可行性。虽然部分非食品项（如“Flavored cream”）被误标，但整体准确率已具备实用价值。

模型规模对比与参数统计

为了量化模型的性能与效率，我们统计了微调后模型的参数量，并与基准模型 GPT OSS 12B 进行了对比。通过调用 PyTorch 函数计算，微调后的 Gemma 3 模型总参数量为 2.7亿（270 million）。相比之下，GPT OSS 12B 拥有 1200亿（120 billion） 参数。

模型名称 参数量 (Parameters) 相对大小比例 训练耗时 训练数据量
微调后 Gemma 3 270 Million 1x (基准) ~3 分钟 1,000 样本
GPT OSS 12B 120 Billion ~444x 未知 未知

计算表明，我们的微调模型比 GPT OSS 12B 小约 444倍。这一巨大的规模差异突显了在小参数模型上进行特定任务微调的高效性。尽管参数量极小，但在提取食品和饮料这一特定任务上，其输出质量已接近大模型水平，证明了 Supervised Fine-Tuning (SFT) 在垂直领域应用中的巨大潜力。

后续计划与直播总结

本次直播的核心成果是在 NVIDIA DGX Spark 上从零开始完成了代码迁移、模型加载及微调。下一步计划包括： 1. 创建 Demo 应用：开发一个基于 Gradio 的演示界面，允许用户输入文本，模型自动提取其中的食品和饮料项。 2. 上传至 Hugging Face：将微调后的模型保存并共享到 Hugging Face 平台，以便社区使用。 3. 执行评估 (Evals)：将微调模型与 GPT OSS 12B 进行正式的性能对比评估，验证其在不同测试集上的表现。

"From scratch, we have gone in two hours or thereabouts... We've fine-tuned that Gemma 3 model... it is working quite well on our target problem."

在演示中，模型成功从复杂的文本描述中提取出如“Double shot latte”、“Dark chocolate”、“Russian caravan tea”等具体项，甚至能正确忽略无关内容。这证实了 Tokens in, Tokens out 的模式在特定任务中的有效性。未来可通过增加数据量进一步提升模型在饮料类别的召回率。