闲记算法

本文对比了全参数微调和LoRA，并分析了这两种技术各自的优势和劣势。作者使用了三个真实用例来训练LLaMA 2模型，这提供了比较特定任务的性能、硬件要求和训练成本的基准。本文证明了使用LoRA需要在serving效率和模型质量之间做出权衡，而这取决于具体的任务。 此外，本文还提供了关于如何通过智能提示技术来稳定LoRA训练的深入见解，并进一步验证了采用较低的学习率可以增强最终模型检查点的可靠性。实验是基于经LoRA调整的脚本版本进行的。 最近几个月，开源语言大模型（LLM）之间展开了与OpenAI专有模型的竞争。提升开源LLM性能的一种常用策略是全参数微调，这种方法对模型的所有参数进行了优化。在之前的博客文章中，我们分析了这种全参数微调与GPT-4的提示工程和少样本提示的比较效果。 正如你所料，全参数微调是一项资源密集型任务，需要强大的计算能力来管理优化器状态和检查点。一些上下文信息：通常情况下，优化器状态和梯度所占的内存空间约为模型本身的12倍。即便是拥有70亿参数的最小LLaMA-2模型，也需要大量计算资源来进行微调。因此，该领域出现了所谓的"参数高效微调（也被称为pef ...

Transformer一作Ashish Vaswani所在的AI公司Adept，发布了Fuyu-8B，这是一个多模态模型的小版本，为其产品赋能。Fuyu-8B的特点包括： （1）具有比其他多模态模型更简单的架构和训练程序； （2）从头开始为数字助手设计，支持任意图像分辨率，能够回答关于图表和图形的问题，并在屏幕图像上进行精细的定位； （3）响应速度快，对于大图像的响应时间不到100毫秒； （4) 尽管针对特定用例进行了优化，但在标准的图像理解基准测试中表现良好。 方法 模型架构： Adept致力于为知识工作者构建一个普遍智能的助手。为了实现这一目标，模型需要能够理解用户的上下文并代表用户采取行动。Fuyu的架构是一个普通的Decoder-only变压器，没有图像编码器。图像块直接线性投影到变压器的第一层。 从Huggingface中可以看到如下： 1234567....... self.vision_embed_tokens = nn.Linear( config.patch_size * config.patch_size * config.num_ch ...

用latexml转换arXiv.org论文(Latex源码)显示为HTML5，然后在借助沉浸式翻译，效率提高很多。强烈推荐！ Github地址: github.com/dginev/ar5iv Converted from TeX with LaTeXML. Sources upto the end of November 2023. Not a live preview service. For articles with multiple revisions, only a single version is made available. When in doubt, always use the main arXiv.org article page. Goal: incremental improvement until worthy of native arXiv adoption. Sample: A Simple Proof of the Quadratic Formula (1910.06709) View any arXiv article UR ...

很多人苦于不知道如何写高质量的 Prompt，尤其是如果要用英文表达更是吃力，不容易表达准确。 可以试试让 ChatGPT 帮你写，尤其是 GPT-4，生成的质量还是不错的。 如果你只是简单要求它写一个英文 Prompt，它很可能只是把你的要求翻译一遍，这样效果可能不够理想。要让 Prompt 质量高，可以让 Prompt 遵循一个好的结构，并应用一些好的策略，例如思考链、慢思考等等。 以前 OpenAI 分享过：《GPT best practices》，里面就介绍了很多优秀实践，我也分享过一些参考的结构。 基于这些可以写一个 Prompt 来让它写 Prompt😄 首先给它设定一个角色：“Prompt Engineer，擅长写 GPT-4 能理解并输出高质量结果的”，让它明白它擅长写 Prompt，生成时生成高质量 Prompt 内容的概率能高一点点。 然后告诉它要求，例如要考虑 Cot、慢思考，提供样例。 再告诉它输出的格式应该遵循一个结构。 这样它就能生成还不错的 Prompt 内容。 但是要注意的是，这种方法类似于让 ChatGPT 写代码，如果你自己不能提供清晰的步骤，Ch ...

GPT 和 PaLM 等大型语言模型（LLM）的出现催生出了开始对我们的工作和日常生活产生重大影响的新应用，比如编程助理和通用型聊天机器人。 许多云计算公司正竞相以托管服务的方式提供这些应用。但是，运行这些应用的成本非常高，需要大量硬件加速器，如 GPU。根据最近的估计，相比于传统的关键词查询方法，处理一个 LLM 请求的成本超过其 10 倍以上。考虑到成本如此之高，提高 LLM 服务系统的吞吐量（并由此降低单位请求的成本）就变得更为重要了。 论文地址: https://arxiv.org/abs/2309.06180 代码地址: https://github.com/vllm-project/vllm 文档地址: https://vllm.readthedocs.io/en/latest/ LLM 的核心是自回归 Transformer 模型。该模型可基于输入（prompt）和其之前输出的 token 序列生成词（token），一次生成一个。对于每次请求，这个成本高昂的过程都会重复，直到模型输出终止 token。这种按序列的生成过程会让工作负载受到内存限制，从而无法充分利用 G ...

由于 LLM 巨大的 GPU 内存开销和计算成本，在大多数应用中，机器学习工程师通常通过内部调整（如量化和对 CUDA 核的定制）来优化。然而，由于 LLM 通过迭代生成其输出，并且 LLM 推理通常涉及内存而不是计算，因此在很多实践中，优化系统级批处理可以使性能差异达到10倍甚至更多。 一种最近提出的优化方法是连续批处理（Continuous batching），也称为动态批处理或基于迭代级的批处理。其具有如下惊人的效果： 基于vLLM，使用连续批处理和连续批处理特定的内存优化，可以实现多达23倍的吞吐量提升； 对于 HuggingFace 本地生成推理，使用连续批处理，可以实现8倍的吞吐量提升； 基于 NVIDIA 的 FasterTransformer，使用优化过的模型实现，可以实现4倍的吞吐量提升。 本博客接下来将详细介绍相关技术的细节。 LLM推理 LLM 推理是一个迭代过程，在每个新前馈循环后获得一个额外的完成标记。例如，如果您提示一个句子"What is the capital of California:"，它需要进行十次前馈循环才能得到完整的回 ...

千元预算半天训练，效果媲美主流大模型，开源可商用中文LLaMA-2 [代码] [博客] [模型权重] LLaMA-2相较于LLaMA-1，引入了更多且高质量的语料，实现了显著的性能提升，全面允许商用，进一步激发了开源社区的繁荣，拓展了大型模型的应用想象空间。 然而，从头预训练大模型的成本相当高，被戏称「5000万美元才能入局」，这使得许多企业和开发者望而却步。那么，如何以更低的成本构建自己的大型模型呢？ 作为大模型降本增效的领导者，Colossal-AI团队充分利用LLaMA-2的基础能力，采用高效的训练方法，仅使用约8.5B token数据、15小时、数千元的训练成本，成功构建了性能卓越的中文LLaMA-2，在多个评测榜单性能优越。 相较于原始LLaMA-2，在成功提升中文能力的基础上，进一步提升其英文能力，性能可与开源社区同规模预训练SOTA模型媲美。 秉承Colossal-AI团队一贯的开源原则，完全开源全套训练流程、代码及权重，无商用限制，并提供了一个完整的评估体系框架ColossalEval，以实现低成本的可复现性。 此外，相关方案还可迁移应用到任意垂类领域和从头预训 ...

大模型的长输入在很多场景下都有非常重要的应用，如代码生成、故事续写、文本摘要等场景，支撑更长的输入通常意味着更好的结果。近日，斯坦福大学、加州伯克利大学和Samaya AI的研究人员联合发布的一个论文中有一个非常有意思的发现：当相关信息出现在输入上下文的开始或结束时，大模型的性能通常最高，而当大模型必须访问长上下文中间的相关信息时，性能显著下降。即，大模型对输入中不同位置的文本信息利用能力是不同的，对召回的若干条文档片段进行合理的位置安排，能有效提高模型的回答效果。 本文将简单介绍一下这个现象。 假设我们检索出来的相关文档为doc1，doc2，doc3，如下所示 存在一个问题是：这里doc1、doc2、doc3应该怎么排序合适？ 作者做了一系列的实验，这里直接给出结论：把关键信息位于输入上下文的开始或结尾时，模型表现最佳。而关键信息位于长上下文的中部，性能可能会大幅下滑。 那么如果在做RAG检索的时候，可以将相似度高的放到前后，而相似度低的放在中间。我们在实际项目中实验也有类似的结论。 实验场景 在论文中，作者以以下两种场景进行实验： （1）wiki问答场景：大模型输入中包含一个 ...

随着人们对大型语言模型 (LLM) 的兴趣激增，许多开发人员和组织正忙于利用其能力构建应用程序。然而，当开箱即用的预训练LLM没有按预期或希望执行时，如何提高LLM应用的性能的问题。最终我们会问自己：我们应该使用检索增强生成（RAG）还是模型微调来改善结果？ 在深入研究之前，让我们揭开这两种方法的神秘面纱： RAG：这种方法将检索（或搜索）的能力集成到LLM文本生成中。它结合了一个检索系统和一个法学硕士，前者从大型语料库中获取相关文档片段，后者使用这些片段中的信息生成答案。本质上，RAG 帮助模型“查找”外部信息以改进其响应。 微调：这是采用预先训练的 LLM 并在较小的特定数据集上对其进行进一步训练的过程，以使其适应特定任务或提高其性能。通过微调，我们根据数据调整模型的权重，使其更适合我们应用程序的独特需求。 RAG 和微调都是增强基于 LLM 的应用程序性能的强大工具，但它们涉及优化过程的不同方面，这在选择其中之一时至关重要。 以前，我经常建议组织在进行微调之前尝试使用 RAG。这是基于我的看法，即两种方法都取得了相似的结果，但在复杂性、成本和质量方面有所不同。我甚至用这样的图 ...

几个月前，在 Thoughtworks 的内部 AIGC 研讨会里，我们一直达成了一系列一致观点，诸如于：如果没有 “开源模型” 降低企业应用 LLM 的成本，那么 LLM 会很快消亡。所以，我们相信开源 LLM + LoRA 微调会成为企业的一种主流方式。现今，我们可以看到 LLaMA 2、Code LLaMA 2 等模型在不断刷新这种可能性。 而在模型不是问题之后，作为架构师、开发人员，我们应该致力于：将 LLM 以工程化的方式落地。于是，在过去的几个月里，我们开发了一系列不同领域的 LLM 应用 PoC（Proof of Concept），尝试从不同的角度思考如何构建好 LLM 应用。诸如于： 语言与生态的角度，探索优化语言间的交互？ 技术架构应该如何设计？ Prompt 建模与优化？ 有哪些模式构建更好的模型上下文？ 语言 API 应该包含那些内容？ 其它的一些问题，还包含如何通过小模型、传统 LLM 降低大模型花费？每个问题都是一个比较有意思的问题，也是我们在落地时要考虑的。 语言与生态的角度：LLM Service as a API vs FFI 已经有大量的企业尝试 ...