羊城迷鹿的博客

本文系统梳理五大算法的理论基础、关键公式和工程实现，通过 Online 与 Offline 的对比、显存开销的量化分析、以及基于显存和数据类型的决策树，帮助你快速找到最适合自己项目的方案。文章包含完整的 LLaMA Factory 配置示例、超参数调优建议和常见问题解决方法，既适合初学者建立系统认知，也适合工程师作为实战参考手册。

基于以上30+组实验的系统性分析，我们总结出以下LoRA调优最佳实践指南。

随着大语言模型参数规模突破千亿级别，模型部署面临着严峻的内存和计算挑战。LlamaFactory作为一个强大的LLM训练与部署框架，集成了完整的量化技术栈，让模型压缩变得简单高效。本文将以LlamaFactory为核心，系统性地介绍LLM量化的完整技术方案：从量化基础理论出发，深入解析PTQ（训练后量化）和QAT（量化感知训练）两大范式，详细讲解GPTQ、AWQ等主流权重量化算法的原理与实现，并通过LlamaFactory实战案例展示如何实现4-8倍内存压缩和2-4倍推理加速，为大模型的高效部署提供完整的解

掌握大模型前沿技术，探索实战应用的无限可能。

本文将详细记录使用 PolarDB for PostgreSQL 构建图数据库的完整实践过程，从 Docker 环境搭建、关系型数据库实验，到基于 Apache AGE 插件的图谱构建，最终实现图数据的可视化展示。整个实践过程并非一帆风顺，特别是在图谱可视化环节遇到了诸多技术挑战。从 Docker 镜像拉取失败，到 Node.js 版本兼容性问题，再到前端依赖包的路径解析错误，每一个障碍都需要仔细分析和逐一攻克。通过切换 Node.js 版本、手动安装 Babel 运行时环境、修改前端代码的导入语句等一

开发了一个即插即用的超参数自动搜索插件，它能够自动遍历参数空间、执行训练评估、收集性能指标，并生成详细的对比报告，让模型调优变得轻松高效。本插件采用配置层-执行层-输出层的三层架构设计，通过三个YAML配置文件（基准参数、搜索空间、实验配置）驱动整个搜索流程。在技术实现上，系统解决了几个关键问题：通过进程树递归追踪解决了GPU显存监控中主进程与训练子进程不一致的问题；从训练日志中提取运行时间和关键指标；通过灵活的指标配置机制，支持任意评估指标的自动收集；通过增量实验机制和配置快照，支持分批执行和历史追溯

为了规范训练参数的输入，我们使用Pydantic定义了配置模型。这个模型包含了SSH连接配置、远程环境配置和训练超参数三个主要部分。"""微调配置模型"""# SSH连接配置# 远程环境配置# 训练配置这个配置模型不仅提供了参数验证功能，还为每个参数设置了合理的默认值。在实际使用中，调用者只需要提供必须修改的参数，其他参数会自动使用默认配置，大大简化了API调用的复杂度。通过SSH协议实现远程模型训练管理系统，我们解决了本地训练向生产环境迁移过程中的关键技术问题。

原理： 在预训练权重旁注入低秩分解矩阵，仅训练轻量级适配器优势： 参数效率高(典型适配器仅58MB)，显存占用低，训练快速适用场景： 资源受限环境下的快速迭代2. Full Fine-tuning (全量微调)原理： 更新模型全部参数优势： 理论性能上限最高，适合大规模数据场景劣势： 需要DeepSpeed ZeRO-3等分布式策略，显存需求大(22GB+)（约7GB模型文件）3. Freeze Fine-tuning (冻结微调)

上篇文章通过系统化的对比实验，回答了多模态微调中的三个基础问题：“选什么方法”(LoRA/Full/Freeze/OFT对比)、“用什么配置”(60+组超参数组合)、“达到什么效果”(ROUGE-L/BLEU-4指标)。这些结果为后续工作奠定了实验基线，但也留下了更深层的疑问：为何相同方法在不同数据集上表现迥异？为何某些超参数的微小调整会引发性能剧变？如何在未见过的任务上快速找到最优配置？本文是对前文实验数据的二次挖掘与机理解析。我们将关注点从"做了什么实验"转移到"实验揭示了什么规律"，实验视角从"结果对

本文记录了华为NPU服务器驱动失效问题的完整排查与解决过程。服务器重启后npu-smi info命令失效，经诊断发现是内核自动升级导致当前运行的5.15.0-153版本缺少Ascend驱动模块。通过对比/lib/modules目录下各内核版本的驱动文件，确认5.15.0-144-generic版本包含完整的24个驱动模块。随后修改GRUB配置回退至该内核版本，并通过锁定内核包和禁用自动升级机制防止问题再次发生。

原始github网址。

本文提出了一种**逆向工程**的思路：基于vLLM显存占用的底层机制，通过精确计算模型权重、KV缓存、激活内存等各组件的显存需求，**倒推出最优的gpu-memory-utilization参数**。这种方法让我们能够在部署前就准确预估资源需求，实现一次配置、稳定运行。本文我们将从vLLM显存计算的核心原理出发，构建完整的倒推计算框架和源码，并通过大量实验验证其准确性（会有误差，但基本可以直接使用）。

本文基于Qwen3-14B-AWQ和Qwen3-32B-AWQ模型的详细实验，通过50+组精确控制的对比测试，系统性地分析了vLLM中各个关键参数对显存使用的真实影响规律。我们不仅展示实验结果，更重要的是深入揭示了vLLM显存分配的底层机制——包括激活值显存与KV Cache之间的竞争博弈、多卡环境下的非线性分配规律，以及参数间复杂的相互作用关系。通过对这些机制的深度解析，我们构建了完整的显存优化方法论，成功实现了在RTX 4090服务器上单卡和多卡环境下的稳定部署，并提供了基于机制理解的科学调参策略。

在使用Dify进行知识库管理的过程中，我们经常遇到一个实际问题：如何将已上传到知识库中的文档批量下载到本地？目前Dify的管理界面虽然功能强大，但暂时没有提供直接的UI界面来批量导出或下载知识库内的文档。这意味着如果我们需要将知识库中的文件备份到本地或进行离线处理，只能通过API接口来实现。本文将详细介绍如何利用Dify的REST API构建一个完整的知识库文档下载解决方案，这也是目前实现知识库文件批量下载到本地的唯一可行路径。🎉进入大模型应用与实战专栏 | 🚀查看更多专栏内容首先，我们需要在Dify的

指定使用的GPU设备：基础模型路径template：模板类型，需与模型匹配cutoff_len：最大序列长度：训练轮数：每设备批次大小output_dir：模型保存路径dataset：训练数据集名称@app.post("/finetune/start", summary="启动微调服务")@app.post("/finetune/stop", summary="停止微调服务")@app.get("/finetune/status", summary="获取微调服务状态")

大模型的显存大小，与大模型本身的参数量有关，与是训练还是推理过程有关，而训练过程采用的训练参数以及推理过程采用的推理参数也会影响。模型参数量：决定了模型权重的基础存储需求运行模式：训练过程需要存储梯度和优化器状态，显存需求远高于推理训练方法：全参数微调、LoRA、QLoRA等不同方法的显存需求差异巨大量化精度：FP32、FP16、INT8、INT4等不同精度直接影响显存占用推理参数：批次大小、序列长度、KV缓存等都会显著影响推理时的显存需求。

随着大语言模型（LLM）如ChatGPT、Claude等的快速发展，代码生成和自动化编程已成为AI应用的重要场景。然而，如何安全地执行AI生成的代码一直是一个关键挑战。本文将详细介绍如何从零开始搭建一个基于Docker沙盒和FastAPI的在线Python代码执行平台，为大模型应用提供安全、隔离的代码执行环境。

下面是工作流官方文档中给出的工作流定义，其实工作流与Agent调用的对象是一样的，都是预先定义好的智能体。不过工作流是在一个确定的任务空间里面，根据预定义的长且复杂的智能体链条去完成任务；Agent则要利用大模型的语义理解能力，首先从无穷的语义空间中进入一个有限的任务空间，再将潜在的智能体空间与这个任务空间做对齐，通过重复的思考-尝试-反馈思维链条去迭代出一个相对来说较为简单的智能体调用链。

首先下载上面给出的github项目并安装环境，然后想想要测试什么问题。请问下面这个字符串的长度的三次幂是几：XXX，理想情况下，Agent加持的大模型会分析出需要调用获取字符串长度和计算三次幂这两个工具，然后连续调用它们得到正确的结果。所以第一步就是要把这两个工具定义好，在这个项目里，只要在Tool文件夹下定义好xxx.py和xxx.yaml这两个文件，xxx这个工具就算可以使用了，我们对这两个工具的定义如下，注意这些工具的输入和输出都得是字符串。

跟一文读懂Langchain：ChatGLM3和ChatGPT的Agent调用分析中的测试基准一样，针对请问下面这个字符串的长度的三次幂是几：XXX这个问题，看看能否正确调用获取字符串长度和计算三次幂这两个工具。选择创建空白定义，类型为Agent点击Agent设置，可以看到默认模式就是ReActDify里面的工具都是基于外部API定义的，因此需要将两个函数封装成API的形式title="Agent测试API",return appsummary="获取字符串长度",