小模型微调的核心价值与适用场景

本次演示旨在展示如何在一台本地设备上完成小型语言模型（SLM）的端到端微调。对于“小”的定义具有主观性，但在本教程中，小于10亿参数（under 1 billion parameters）的模型即被视为小语言模型。具体而言，我们将使用HuggingFace上的Gemma 3 270M模型作为基础底座，并配合名为“food_extract_1k”的自定义数据集进行任务特定微调。选择本地微调而非依赖云端API，主要基于以下核心优势：首先，数据隐私得到保障，自定义数据无需发送至任何第三方API或公司服务器。其次，对于特定任务（如从文本中提取结构化数据），小模型往往足以胜任，无需动用训练过整个互联网的巨型大语言模型。此外，本地部署支持离线运行和批量推理模式。> "We want to own the model. We can run this on our own hardware." 通过批量推理，模型性能可显著提升，理论上每天可处理约一百万个样本（one million samples per day）的推理请求，远超单次API调用的效率。

数据蒸馏策略：以大模型知识指导小模型训练

在构建数据集时，我们采用了“知识蒸馏”的思路。目标任务是从任意文本序列（包括乱码、图像描述等）中提取食物和饮品信息。为了生成高质量的标注数据，我们使用了GPT-oss 120B模型对原始文本进行标记。> "We are essentially distilling the knowledge of a big powerful open source model into a very small one." 这一策略的关键在于规模差异：GPT-oss 120B拥有1200亿参数，是我们目标模型Gemma 3 270M的444倍。通过让强大的大模型生成标注，我们将复杂任务的结构化知识压缩并传递给参数量极小的Gemma 3模型。这种监督微调（Supervised Fine-tuning, SFT）方法直观且高效，即提供输入字符串和期望的结构化输出（食物/饮品标签），让模型学习复现这一映射关系。最终目标是训练出一个能专门处理此类特定任务的专家级小模型。

硬件环境配置与代码可移植性验证

本教程的演示运行在Nvidia DGX Spark硬件平台上，通过SSH连接至Mac Mini进行编码操作。DGX Spark是一款紧凑且强大的AI硬件设备，适合展示本地高性能推理能力。然而，对于没有专用高端硬件的用户，所有代码均已验证可在Google Colab的免费L4 GPU实例上运行。> "As long as it's about 16 GB of VRAM, you'll be able to run this." L4 GPU提供约16GB显存（VRAM），足以支撑本教程的模型训练与推理。若使用T4 GPU或显存略低的设备，只需将默认批次大小（batch size）从16调整至4或更低即可顺利运行。软件栈主要依赖HuggingFace的`transformers库和TRL（Transformers Reinforcement Learning）库，后者虽名为强化学习库，但同样完美支持监督微调任务。这种跨平台的兼容性确保了无论用户拥有顶级硬件还是免费云端资源，都能轻松复现从数据到模型的全流程。

实际应用案例：大规模图像描述的结构化过滤

微调完成后的模型将应用于实际的大规模数据处理场景。以Data Comp 1B数据集为例，该集合包含十亿张图像的URL及其对应的文本描述。> "We could then use this model to filter a large data set of image captions such as Data Comp 1B." 面对如此庞大的非结构化文本数据，人工筛选成本极高。通过部署我们微调好的小语言模型，可以自动化地从这些图像描述中精准提取出涉及“食物”和“饮品”的内容。这种批量处理能力不仅验证了模型在特定任务上的有效性，也展示了小语言模型在处理大规模、高重复性结构化提取任务时的巨大潜力。由于模型运行在本地且无需网络延迟，这种批处理模式能够以极高的吞吐量完成数据清洗和分类工作，体现了端侧AI在工业级应用中的实际价值。

结构化数据的灵活性与LLM本质

在介绍其初创公司Neurify.app的应用时，作者强调了处理非结构化数据（如图像）时的策略。由于缺乏特定领域的图片库，他们利用开源数据集进行筛选，例如过滤出包含“食物”描述的文本以匹配图像。这一过程引出了对结构化数据定义的重新审视：在LLM语境下，结构并非指固定的表格格式，而是输入与输出的映射关系。作者指出，“An LLM is tokens in, tokens out. The beauty of LMs is that they are decoder architectures.”这意味着输入和输出可以是几乎任何形式。无论是将10,00封客户邮件提取为“问题”和“位置”，还是处理食品分类，核心都在于tokens in, tokens out。这种架构允许用户根据业务需求自由调整输入结构，例如将数据放入Google Sheet或DataFrame中进行排序和处理。

食品分类案例的数据结构详解

为了具体说明数据结构的构建，作者展示了一个针对“食物或饮料”的分类案例。数据结构包含多个字段：首先是布尔值field zero or one，用于标识内容是否涉及食物；其次是标签字典（tag dictionary），包括“food item”、“drink item”等，便于后续过滤；还有具体的食品名词列表。作者以午餐为例：“Beef, mint, white rice, hot sauce, and a side of pickles and pepper and a glass of water.”模型能够准确识别这些名词。相反，如果输入是一张“汽车翻越山丘”的图片描述，由于与食物无关，模型会输出0和空列表。这种设计展示了输入文本的多样性处理，即使是不相关的图像描述也能被正确归类为无食物内容。作者强调，“You can even try out... we have the code to create a reusable fine-tuned Gemma 3 270 mil model.”这表明该流程是可复用且基于公开模型的。

微调模型演示与错误反馈机制

作者展示了在HuggingFace上部署的可分享Demo，使用微调后的Gemma 3模型进行实时测试。输入文本为：“Now for today's lunch, I had sardines, pickles, and peppers and hot sauce.”模型成功识别出“sardines, pickles, peppers, hot sauce”为食物标签，并标记为food or drink one。随后输入：“after lunch, I had a cup of coffee.”模型将“coffee”归类为饮料，尽管作者调侃咖啡是否算食物存在争议。这一演示揭示了机器学习的一个关键特性：错误是改进模型的宝贵资源。作者表示，“We actually like it when our model gets stuff wrong because we can go, okay, I need some more data samples on that in the future.”目前模型仅基于1000个样本训练，属于基础版本（barebones example），但已能展示端到端微调的有效性。作者还提到，未来可以通过创建高质量合成数据来引导数据集，以进一步优化模型。

DGX Spark硬件环境与开发流程

整个演示运行在NVIDIA DGX Spark设备上，这是一款小巧但性能强大的硬件。作者展示了其内部配置：Grace Blackwell 10 (GB10)，并拥有128 GB of memory。这种充足的内存为模型运行提供了良好基础。作者提到，新软件优化可能使GPT-O 12B等模型运行速度提升约30%，并计划未来探索合成数据生成。开发环境方面，作者使用VS Code连接DGX Spark进行代码调试，同时也指出用户可以使用Google Colab作为替代方案。所有相关代码已在HuggingFace和Zero to Mastery平台公开，包括文本分类和目标检测项目。作者强调，“We coded this from scratch the other day.”并鼓励观众通过直播或课程学习每一步代码细节，特别是针对希望深入理解从零开始构建LLM微调流程的开发者。

基础模型选择与 Tokenizer 机制

教程首先确立了使用的基座模型为 Gemma 3270 mil，具体选用的是经过指令微调（instruction tune）的版本。作者指出该版本专门针对遵循指令进行了优化，虽然基础版可能也有其优势，但当前实验聚焦于指令跟随能力。在模型加载后，紧接着需要处理的是 Tokenizer（分词器） 的概念。由于计算机底层无法直接理解文本、图像或音频等原始数据，它们只处理数字，因此 Tokenizer 的核心作用是将原始数据转换为模型可处理的数值形式。不同模型通常拥有专属的 Tokenizer，而 Hugging Face 库的优势在于能够根据模型 ID 自动加载正确的分词器，从而简化了从原始数据到数值输入的转换流程。尽管直接运行模型会产生机器可读的 logits，但为了获得人类可理解的输出并进入后续训练阶段，必须正确配置这一预处理环节。

数据集获取与人工校验的重要性

在模型准备就绪后，下一步是加载名为 Food Extract 的数据集。该数据集规模较小，仅包含 1400 个样本。这些样本中既有真实数据也有合成数据，但所有标签均由 GPT-4o (OSS 12B) 这一合成模型生成，作者本人并未参与原始标注。为了提升模型的鲁棒性并建立可靠的评估基准，作者在文中强调了一个关键实践：未来应当构建一个至少包含 100 个样本的评估数据集，这些样本需要经过人工严格审核以确保正确性。通过让模型在这些人工作证的高质量测试集上表现良好，才能真实反映其性能。随机查看至少 100 个样本是作者下载新数据集时的标准动作，以此确保数据格式和内容符合预期。当前使用的样本输入包含营养信息标签（如“五籽面包”），输出则是结构化的 JSON 格式数据，包含是否为食品饮料的布尔值以及特定的标签列表。

输出格式的 Token 优化策略

针对小型 LLM，作者深入探讨了减少生成 Token 数量对推理效率的决定性影响。原始的输出标签采用标准 JSON 格式，经 OpenAI Tokenizer 计算包含 71 个 Tokens。由于模型是解码器架构，必须逐个输出 Token，任何多余的符号（如 JSON 中的括号和冗余字段）都会增加计算负担并延长生成时间。作者将输出格式精简为更紧凑的 YAML 风格，去除了冗余结构后，Token 数量降至 50 个。虽然单个样本仅节省了 21 个 Token，但在大规模推理场景下（例如处理一百万次请求），这种优化将累计节省 2100 万个 Token。作者指出，“如果你在一百万次推理中这样做，你就节省了 2100 万个 Token”。这种格式压缩不仅提升了速度，还保留了所有必要信息（如 NP、Ingredient List 等标签），后续可通过简单的解析器将其转换回标准格式，从而在保持功能完整性的同时最大化推理效率。

数据格式化与对话模板适配

最后，教程展示了如何将原始数据集转换为适合 LLM 训练的输入输出对。原始的标签数据以 JSON 形式存储，包含序列（Sequence）、图像 URL 及由 GPT-4o 生成的标签。为了适配 Gemma 3 模型的训练风格，必须将数据转换为对话格式（Conversational Style）。这是因为 Hugging Face 上的大多数模型都经过特定风格的微调，Gemma 3 尤其依赖这种格式。具体操作是将输入文本封装在包含 role（角色）和 content（内容）的字典中：用户输入标记为 user 角色，模型期望的输出标记为 system 或助手角色。通过编写辅助函数遍历整个数据集，将原始的 sequence 和 condensed label 映射为这种消息列表结构。这种格式化确保了模型在训练时能理解“给定输入序列，生成特定格式的紧凑标签”这一任务逻辑，为后续的指令微调奠定了标准化的数据基础。

数据预处理与对话格式转换

在机器学习的数据准备阶段，核心任务是将原始样本转换为模型可理解的对话格式。通过定义 map 函数，系统会自动遍历数据集中的所有样本，并应用特定的转换逻辑。例如，原始数据结构中可能仅包含基础字段，但经过处理后会新增 messages 字段以承载对话内容。这一过程确保了数据的一致性，如将非食品相关的随机文本（如“在温德米尔岛夜间游玩的另一个可选任务”）正确标记为无特定标签（零食物、零饮料），从而验证了数据清洗的有效性。

基座模型的通用能力与局限

在开始微调之前，首先需要评估基础模型（Base Gemma 3）对图像描述数据的原始理解能力。当输入一段关于饮料营养标签的长文本时，模型能够准确复述内容；而当输入无法处理的图像格式（如JPEG）或无关文本时，模型会返回“无法查看”等通用回复。这些输出虽然看似平庸且缺乏针对性，但这实际上证明了模型具备基础的语言模式识别能力。正如演讲者所言：“That means it has a baseline understanding of language and the patterns and the tokens that we've given it.” 这种基线理解是后续微调的基础，意味着我们可以通过特定的指令和示例来引导模型输出我们期望的格式。

提示工程在小参数模型上的失效尝试

为了从图像描述中提取食物和饮料项目，演讲者首先尝试了提示工程（Prompt Engineering）。通过构造包含指令、空值示例和具体食物列表示例的复杂提示词，试图让模型遵循特定格式输出。然而，当使用仅有 2.7亿参数 的 Gemma 3模型执行此任务时，尽管提示词中包含了详细的示例和格式要求，模型的输出却仅仅是直接返回了输入中的示例文本。这是因为小参数模型的记忆模式和泛化能力有限，在面对复杂的指令跟随任务时，往往倾向于机械地复制训练数据中的模式，而非真正理解并执行逻辑提取。相比之下，拥有万亿级参数的大模型（如 Gemini）在相同提示下能够完美执行任务。这揭示了小模型无法仅靠提示工程实现复杂任务的精准控制。演讲者指出：“Because we have um 270 million uh that sounds like a lot, but in comparison to a model like say Gemini... it has a lot more ability to learn.”

微调后的性能飞跃与验证

为了解决小模型指令跟随能力不足的问题，演讲者引入了监督微调（Supervised Fine-Tuning, SFT）方案。在使用 TRL (Transformers Reinforcement Learning) 库配置微调参数（如学习率）后，对模型进行了针对性训练。在最终的演示环节，将同一瓶“McCormack Food Australia”辣椒酱的图像描述输入微调后的模型。结果显示，微调后的小模型成功提取出了番茄泥、醋、糖等具体成分列表。虽然结果并非完美无缺，但其表现已与大型商业模型 Gemini 的输出水平相当。这一对比有力地证明了：对于特定且相对简单的任务，通过微调小模型可以在本地实现与大模型相媲美的性能，同时避免了高昂的API调用成本和延迟。演讲者总结道：“Not exactly perfect, but I would be happy with that output from our fine-tuned model.” 这为后续的全链路微调教程奠定了信心基础。

配置调整与训练环境设定

在开始微调之前，必须根据硬件资源合理设置超参数。由于模型输入均为数值空间，学习率将引导模型输出向真实标签靠拢。显存大小直接决定了批量大小的选择，作者使用的是拥有 128 GB VRAM 的 DGX Spark 设备，因此将每设备批量大小（per device batch size）设置为 16；相比之下，若使用 Google Colab 等显存受限环境，建议将批量大小降至 4。优化器方面，虽然作者尝试过 Atomw 但未成功，最终选用有效的 AdamW（原文误拼为Atomwrus）作为优化算法。训练配置中，作者决定不保存检查点（checkpoints），以进行完全实时的运行测试。通过 Hugging Face Transformers 库中的 SFT Trainer（监督微调训练器），只需传入模型、配置和数据集，即可自动处理后台复杂的训练流程。

数据集结构与初步运行观察

本次微调使用的自定义数据集包含 1,000 个训练样本和 1,000 个测试样本，数据格式经过严格的消息（messages）格式化处理。在 DGX Spark 上启动训练后，风扇高速运转标志着计算负载已满。整个微调过程仅耗时约 5 分钟，这对于本地硬件而言效率极高。训练过程中监控的关键指标包括平均令牌准确率（mean token accuracy）、熵值以及损失函数。训练损失持续下降，表明模型正在有效学习数据特征。作者指出，虽然等待模型训练通常需要耐心，但小语言模型配合千级样本量使得这一过程变得非常迅速且令人满意。

过拟合现象与格式一致性分析

训练结束后，作者观察到验证损失高于训练损失，这通常是模型过拟合的典型信号。然而，在特定任务中，这种过拟合可能并非坏事。令牌准确率稳定在 57% 左右，考虑到模型词汇表可能存在约 150,000 个不同令牌，这一准确率在巨大的输出空间中已属优异。作者认为，过拟合意味着模型紧密贴合了特定的数据格式要求。对于需要严格结构化输出的大语言模型任务，强制模型记忆特定输出格式比泛化能力更为重要。训练完成后，系统自动保存了最佳模型的权重文件（model.safetensors），其结构与原始 Google Gemma 3 270M 模型保持一致，便于后续加载和使用。

测试集评估与输出结构验证

为了验证微调效果，作者在从未见过的 1,000 个测试样本上进行了评估。以一段关于混合蔬菜包的描述为例，模型成功提取了食物类型（Food）、营养成分面板标签、成分列表及过敏原信息。输出严格遵循预设的结构化格式，包括食物/饮料分类、NP（营养面板）、IIL（成分列表）等标签。另一案例中，针对“吃木棍上的锦鲤”的图片描述，模型准确输出了相关结构化字段。作者强调，首要评估标准是检查输出是否遵循既定结构。虽然内容的绝对准确性需进一步验证，但模型在格式 adherence（遵从性）上表现完美，证明了微调成功地将非结构化输入转化为符合要求的结构化数据。

结构化数据微调与误差分析循环

视频展示了在 DGX Spark 上对小型大语言模型（LLM）进行端到端微调的过程，重点在于处理结构化数据。经过仅 5 分钟的训练后，模型能够输出符合预期格式的文本，无需额外提示即可从非结构化描述中提取关键信息。例如，面对包含警察、戴粉色头发的女性及彩虹旗的背景图像描述时，模型输出了看似无意义的文本；而在面对“澳大利亚绵羊农场”的描述时，虽然提取出“lamb”，但未能准确关联到食物类别，而是识别为农场图像。对于零食包装的测试，模型成功提取出“dates, peanuts”（枣、花生）。

"This is a gibberish text, right? This is our model's output... Exactly the format we want."

这种实验揭示了机器学习的迭代循环：当模型未能正确输出特定类别（如将食物误判为饮料）时，开发者需记录这些错误样本，并在数据集中增加更多相关或无该类别的示例。通过观察 100 个样本并总结常见的 10 类错误点，可以创建额外的训练数据（如新增 500 个样本）来解决这些问题，随后重新运行训练。这种数据-模型迭代优化机制是提升小模型性能的核心手段。

小规模模型与基准模型的效能对比分析

在性能评估环节，视频将微调后的 2.7 亿参数模型与用于生成标签的基准模型 GPT OSS 12B（实际标注为 GPT OSS 120B，参数量达 1200 亿）进行了对比。尽管微调模型体积仅为基准模型的约 44 倍小（原文提及 "44 times smaller"，虽计算上 120B/0.27B ≈ 444x，但此处保留原文表述逻辑或指代特定压缩比语境），其表现却相当接近。以零食成分提取为例，基准模型的理想输出为 "dates, peanuts, cacao, peanut butter, sea salt, coconut, tree nuts"，而微调模型输出了高度相似的结果。

"Not bad for a model that is 44 times smaller... performing on par, slightly worse."

这一对比证明了在特定结构化任务上，经过精心微调的小参数模型可以在性能与效率之间取得极佳平衡。虽然结果并非完美，但考虑到参数量级的巨大差异，其表现已属优秀。若需进一步提升精度，只需通过上述迭代循环增加更多针对性训练数据即可。

Hugging Face Hub 上传与推理模板的关键性

完成本地训练后，下一步是将模型上传至 Hugging Face Hub。作者演示了快速上传过程（速度达 179 MB/s），并解释了公开与私有仓库的区别。上传成功后，模型可供全球用户下载并在本地运行。然而，在直接调用默认管道（default pipeline）进行测试时，模型未能正确输出预期结果。原因在于推理阶段未应用与训练阶段一致的聊天模板（chat template）。

"We don't get our default output... because we haven't formatted this test input message with the proper chat template."

作者强调，LLM 遵循“输入 token 与输出 token”的一致性原则。如果训练时使用了特定的提示格式，推理时必须通过代码应用相同的模板（如 apply_chat_template），否则输出将偏离预期。修正格式后，模型成功识别出输入 "Hello, my name is Daniel" 并返回正确结果。这一环节突显了工程部署中格式对齐的重要性，任何细微的模板差异都可能导致推理失败。

从代码到 Gradio 演示应用的转化流程

为了降低使用门槛，视频最后展示了如何将微调模型转化为可视化的 Web 演示应用。遵循 Hugging Face 课程的核心口号 “Data, Model, Demo”（数据、模型、演示），作者使用 Gradio 库构建了一个简单的 Python 应用。该应用包含输入（文本）、处理函数（微调模型）和输出（文本）。

"Data model demo. That is actually the motto of the learn hugging face course."

通过 Gradio，非程序员也能轻松交互。作者演示了英国早餐（含 baked beans, fried eggs 等）的提取测试，模型准确识别出食物和饮料类别。最终，作者删除了旧的演示文件夹并准备创建新的 Gradio 界面文件，旨在将复杂的代码逻辑封装为直观的用户接口。这一过程完整闭环了从数据准备、模型训练到最终产品化演示的全流程，展示了小模型在实际应用中的快速落地能力。

构建应用核心文件结构

要将微调后的模型转化为可交互的演示，必须准备三个关键文件：app.py、requirements.txt 和 README.md。其中，app.py 是整个应用的核心入口，它向 Hugging Face Spaces 平台指示如何运行代码。虽然 README.md 并非绝对必要，但上传它有助于提供清晰的文档说明。应用的核心逻辑在于通过 app.py 定义输入与输出的映射关系，从而让平台能够正确加载模型并响应用户请求。在 Hugging Face Spaces 上创建新空间时，可以选择手动操作或编程方式。作者选择使用 Python SDK 进行自动化部署，以便后续可以通过脚本自动更新模型和演示界面，而无需反复手动上传文件。

配置 Hugging Face Spaces 参数

在创建 Space 时，需要指定一系列元数据以定义其运行环境。例如，空间名称设为 food-extract-v1，许可证选择 Apache 2.0。运行环境可以选择 Zero GPU，这对于轻量级演示或测试阶段是可行的选项。作者强调，虽然可以手动创建空间，但通过编程方式可以更灵活地管理版本迭代。关键配置包括指定 SDK 为 Gradio，这是构建机器学习演示界面的常用工具。此外，还需要设置空间类型为 space 而非模型或数据集。通过编程创建仓库时，需传入 HF Token（建议隐藏以避免泄露），并定义文件夹路径、空间名称及 SDK 类型。这种自动化流程允许用户在训练新模型后，只需运行脚本即可同步更新在线 Demo。

编写 Gradio 应用逻辑与前端展示

app.py 的具体实现依赖于 gradio 库。代码中导入依赖项，定义一个预测函数（如 pred_on_text），并使用装饰器指定其运行环境。该函数默认加载已上传的微调模型路径，例如 mr-durk/food-extract-gemma-3-270m-fine-tune。在函数内部，创建 pipeline 处理输入文本并返回结构化结果。Gradio 的 Interface 类用于构建用户界面，它接收输入组件、输出组件以及标题和描述文本。作者展示了如何添加示例数据（Examples），这些示例以列表形式呈现，帮助用户快速理解输入格式。例如，输入“晚餐我想吃牛排、土豆和蒜泥蛋黄酱”，系统能准确提取出食物名称。这种输入输出结构是机器学习的核心抽象，即通过特定的界面将模型能力暴露给最终用户。

自动化部署与版本控制机制

完成代码编写后，通过 Python SDK 执行上传操作。脚本首先导入 huggingface_hub 库，定义包括文件夹路径、空间名称和 SDK 类型在内的参数。调用 create_repo 方法创建远程仓库，随后使用上传命令将本地文件夹同步至 Hugging Face。Hugging Face 具备智能检测机制，如果上传的文件自上次提交以来未发生任何更改（如作者演示中因文件未变而跳过空提交），平台不会触发重新构建。只有当检测到文件修改（如更新 README 中的链接或标签）时，才会触发新的构建流程。作者通过修改 README.md 中的内容（如添加指向笔记本的链接）来触发重新部署，确保在线 Demo 始终反映最新的代码状态。这种机制保证了演示环境的实时性与准确性。最终，用户可以在 Hugging Face 上直接访问并测试微调模型的推理效果。

实时演示与模型分享机制

在完成了从数据准备到模型训练的全过程后，最终的成果可以直接在 Hugging Face 的硬件环境中运行。作者展示了如何在 Notebook 中直接调用刚刚训练好的模型，输入 "Hello, my name is Daniel." 即可得到即时响应。这种远程运行的方式极大地简化了部署流程，使得开发者无需本地配置复杂环境即可验证模型效果。为了让更多人体验这一成果，作者演示了如何将应用嵌入网页或生成分享链接。

"Once our demo is uploaded, we can now run it right within our notebook. What how cool is that?"

这种便捷性不仅限于个人使用，通过复制嵌入代码或直接分享 URL，任何人都可以访问并测试模型。作者鼓励观众亲自尝试生成的应用链接，并在评论区分享自己的体验或训练出的其他模型。这种即时的反馈循环和共享机制是开源社区协作的重要基础，它降低了使用门槛，让模型验证变得像访问网页一样简单。

批处理推理带来的性能飞跃

在演示环节之外，作者深入探讨了提升模型效率的关键技术——批处理推理（Batched Inference）。目前模型的默认状态是单样本输入输出，每次耗时约 0.5 到 1 秒。然而，通过引入批处理技术，即同时运行多个样本，可以实现显著的速度提升。

推理模式 测试集规模 (samples) 总耗时 (seconds) 平均吞吐量 (samples/sec)
默认推理 (Batch Size=1) 284 144 ~2
批处理推理 (Batch Size=16) 284 - ~10

数据显示，在 DGX Spark 硬件上，将批大小设置为 16 后，吞吐量从每秒钟约 2 个样本提升至 10 个样本。这种优化对于长期运行的服务至关重要。作者计算了单日处理能力：以每秒 10 个样本的速度，一天可处理约 820,000 次推理。若每次生成平均 20 个 token，则每天可节省约 16,640,000 个 token 的生成开销。这种规模化的效率提升证明了在训练完成后，优化推理阶段对于降低运营成本具有决定性意义。

后续评估与模型优化路线图

视频最后，作者列出了几个关键的下一步计划，旨在进一步完善模型性能和适用性。首先是进行严格的评估（Evaluations），将当前微调后的模型与 GPT-2 12b 等基准模型进行对比，以量化其实际表现。其次是对数据采样的改进，通过分析模型的错误案例来优化未来的训练数据集。

此外，量化（Quantization） 被视为缩小模型体积的重要手段。当前拥有 2.7 亿参数的模型大小约为 500MB，通过 int8 量化有望进一步压缩体积。另一个方向是输出压缩（Output Compression），目前模型使用 YAML 格式而非 JSON，作者探讨了是否有更高效的文本压缩方式以进一步减少 token 生成量。最后，建议在大规模未见过的图像描述语料库（10,000 条随机样本）上测试模型，以发现潜在的失败案例并反馈至数据采样环节。这些步骤构成了一个闭环的优化流程，确保模型在实际应用中的鲁棒性和效率。

"So if we do that 820,000 inference samples times 20... We save generating 16 million tokens over a day. That is incredible."

作者还邀请观众在评论区提出关于训练自定义模型的问题，并预告了下期视频将涉及视觉语言模型（VLMs）的内容。

结论

本教程证实，在本地硬件上对小于10亿参数的小语言模型（如Gemma 3 270M）进行端到端微调，是处理特定结构化提取任务的高效方案。通过知识蒸馏生成数据并采用监督微调（SFT），小模型在食品/饮料分类任务中表现与大参数基准模型相当，且具备数据隐私保障、离线运行及低成本优势。然而，小模型无法仅靠提示工程实现复杂指令跟随，必须依赖微调；同时存在过拟合风险及格式对齐的工程挑战。

性能方面，通过优化输出Token数量（YAML替代JSON）及启用批处理推理（Batch Size=16），吞吐量可从每秒2样本提升至约10样本，单日处理能力达82万次。尽管当前模型基于千级样本训练且存在少量错误，但通过迭代数据优化可进一步提升鲁棒性。该流程适用于对延迟、成本敏感且任务明确的工业级数据清洗场景，验证了端侧AI在特定垂直领域的实用价值。