本文由 OpenAI 发布于 2024 年 9 月 12 日。 OpenAI o1 系列模型是新一代通过强化学习训练的大型语言模型，专门用于处理复杂的推理任务。o1 模型在回答问题之前会进行思考，能够在回应用户之前生成一系列内部推理链。o1 模型在科学推理方面表现出色，在 Codeforces 编程竞赛中排名前 11%，并在美国数学奥林匹克竞赛 (AIME) 预选赛中跻身美国前 500 名选手，同时在物理、生物和化学问题的基准测试 (GPQA) 中超越了博士生水平的准确性。 API 中目前有两种推理模型： o1-preview：o1 模型的早期预览版，擅长利用广泛的世界知识来解决复杂问题。 o1-mini：o1 的更快且成本更低的版本，尤其适合处理不依赖广泛知识的编程、数学和科学任务。 虽然 o1 模型在推理能力上取得了重大进展，但并不打算在所有应用场景中取代 GPT-4o。 对于需要图像输入、函数调用或快速响应的应用，GPT-4o 和 GPT-4o mini 模型仍然是更合适的选择。不过，如果你正在开发的应用需要深度推理且可以接受较长的响应时间，那么 o1 模型可能是一个理想的选择。我们很期待看到你用这些模型创造出什么！ 🧪 o1 模型目前处于测试阶段 目前，o1 模型正处于测试版阶段，功能有所限制。仅限五级开发者访问（在此处查看你的使用等级），并且速率限制较低（20 RPM）。我们正在努力增加更多功能、提高速率限制，并计划在未来几周内向更多开发者开放！ 快速入门 o1-preview 和 o1-mini 模型可以通过聊天完成端点访问。 from openai import OpenAI client = OpenAI() response = client.chat.completions.create( model="o1-preview", messages=[ { "role": "user", "content": "Write a bash script that takes a matrix represented as a string with format '[1,2],[3,4],[5,6]' and prints the transpose in the same format....

OpenAI 于 2024 年 9 月 12 日推出了 o1 和 o1-mini 模型，显著提升了 AI 推理能力。o1 不仅仅是一个新模型，更是一个新范式。ChatGPT 正在从仅使用系统 1 思维（快速、自动、直观、容易出错）发展到系统 2 思维（缓慢、深思熟虑、有意识、可靠）。这使得它能够解决以前无法解决的问题。除了模型的推出，OpenAI 还发布了2篇报告：Introducing OpenAI o1-preview、OpenAI o1-mini，通读这两篇报告，可以对 o1 和 o1-mini 有更深入的了解，我这里摘要了其中的核心内容。 o1 模型能力 一种通过强化学习训练的大语言模型，能够执行复杂的推理任务。o1 会在回答前先进行思考——它可以在回复用户之前生成较长的内部思维链。 强化学习算法 OpenAI 的大规模强化学习算法通过模型的思维链教会模型如何以高效的数据利用率进行推理。随着强化学习训练时的计算量增加，以及测试时模型思考时间的延长，模型 o1 的性能会持续提升。这种方法在扩展过程中的限制与大语言模型 (LLM) 的预训练有显著不同。 思维链方式 就像人类在回答困难问题前可能需要长时间思考一样，o1 在解决问题时也会使用“思维链” （chain of thought）的方式。通过强化学习，o1 不断优化这种思维链，改进其解决问题的策略。它能够识别并修正自己的错误，将复杂的步骤分解成简单的部分，并在当前方法无效时尝试不同的路径。这个学习过程极大地提升了模型的推理能力。 考试成绩表现 在 2024 年的 AIME（专为挑战美国顶尖高中生设计的数学竞赛）考试中，GPT-4o 平均只解决了 12%（1.8/15）的题目，而 o1 在每题只使用一个样本的情况下，解决了 74%（11.1/15）；使用 64 个样本取共识后，解决率提高到 83%（12.5/15）；通过对 1000 个样本进行评分排序，解决率进一步提升到 93%（13.9/15）。13.9 分的成绩足以让 o1 排名进入全国前 500 名，并超过了美国数学奥林匹克的入选线。 推理表现 在数据分析、编码和数学等推理密集型类别中，o1-preview 明显优于 gpt-4o。然而，o1-preview 在某些自然语言任务上并不是首选，这表明它并不适合所有用例。...

本文是 Anthropic 官方文档给出的一些 LLM 术语的解释，我这里将其翻译为了中文，并增加了 LLM 中一些常见的术语词。 LLM 大语言模型（LLM, Large Language Model）是一种具有大量参数的 AI 语言模型，能够执行多种复杂且实用的任务。这些模型通过大量文本数据进行训练，能够生成类人文本、回答问题、总结信息等。Claude 是基于大语言模型的对话助手，并通过人类反馈强化学习（RLHF, Reinforcement Learning from Human Feedback）进一步训练，以更有帮助、诚实且无害。 Pretraining 预训练（Pretraining）是语言模型在大规模无标注文本数据集上进行的初始训练过程。以 Claude 为例，自回归语言模型会根据文档中的上下文来预测下一个词。预训练模型本身并不擅长回答问题或遵循指令，通常需要复杂的提示工程来引导出预期的行为。通过微调（Fine-tuning）和人类反馈强化学习（RLHF），这些预训练模型可以进一步优化，从而在广泛任务中变得更加有用。 Fine-tuning 微调（Fine-tuning）是通过额外数据进一步训练预训练模型（Pretraining）的过程。这会使模型开始模仿微调数据集中的模式和特征。微调可以帮助模型适应特定领域、任务或写作风格，但需要仔细考虑微调数据的质量及其对模型性能和潜在偏见的影响。 SFT (Supervised Fine-Tuning) SFT 是一种用于语言模型优化的技术，它通过使用标注好的数据集对模型进行进一步训练。相比预训练过程中的无监督学习，SFT 专注于让模型在特定任务上表现更好。在监督微调中，模型根据人为标注的输入和输出对进行学习，从而提高其在回答问题、完成任务或遵循指令等特定场景中的表现。SFT 经常用于帮助模型理解更复杂的任务要求，使其生成的输出更加符合预期。 LORA（Low-Rank Adaptation） LORA 是一种微调大型预训练语言模型的技术。它通过在模型的某些权重矩阵上引入低秩分解来降低模型更新所需的参数数量。传统的微调需要更新模型的所有参数，而 LORA 只微调一部分参数，这大大减少了微调的计算成本和存储需求，同时保持了模型的性能。LORA 在特定任务或数据集上的微调表现良好，因为它可以灵活地适应新的任务要求，而不需要重新训练整个模型。 QLORA（Quantized Low-Rank Adaptation） QLORA（量化低秩适应）是一种用于大语言模型的微调技术，它通过对模型权重进行低秩分解和量化来减少微调的计算开销，同时保持性能。这种方法能够在保持模型准确性的同时，显著降低内存需求和计算复杂度，因此特别适用于在有限的资源下微调超大规模模型。 QLORA 的主要特点是： 低秩适应（Low-Rank Adaptation, LORA）：通过对模型权重的低秩分解，QLORA 可以仅对少量参数进行微调，这样可以在节省计算资源的同时仍能有效捕捉任务相关的模式。 量化（Quantization）：QLORA 使用 4-bit 或更低精度的量化技术来减少模型的存储和计算要求。量化技术通过缩减模型中存储和处理的参数位数，能够降低硬件负载，而不显著影响模型的性能。 高效微调：QLORA 可以在不完全重训练模型的情况下进行微调，尤其适用于资源受限的场景，例如边缘设备或中小型研究团队。 QLORA 技术的出现使得对大型预训练模型进行特定任务的微调变得更加可行。 RLHF（Reinforcement Learning from Human Feedback） 来自人类反馈的强化学习（RLHF, Reinforcement Learning from Human Feedback）是一种用于训练预训练语言模型的技术，使其行为更加符合人类的偏好。这种训练方式可以帮助模型更有效地执行指令，或表现得更像聊天机器人。人类反馈的过程包括对多个文本样本进行排序，强化学习会鼓励模型倾向于生成与高排名样本相似的输出。Claude 已通过 RLHF 进行训练，使其成为一个更加有用的助手。更多详情可以参考 Anthropic 的论文: Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback。...

本文探讨了当前互联网消费领域的创新机会，并指出我们正进入一个类似于 1994-1998、2003-2007 和 2008-2012 的新时期。在这个新时期，技术的进步将推动新一代消费级应用的诞生。文章提出了几个可能的创新方向，包括“合成专家”、“消费化的创造力”、“新浏览器”和“AI 伴侣”，并分析了这些方向的潜力和挑战。 历史背景： 互联网消费公司往往在技术突破后迅速崛起。例如，1990年代初的网络浏览器诞生后，Yahoo、Amazon、Google 等公司相继成立；高速度互联网普及后，LinkedIn、Facebook、YouTube 等平台出现；iOS 应用商店和 Facebook 平台开放后，Airbnb、Uber、Instagram 等应用迅速发展。 2010年代对消费互联网公司不太友好，部分原因是缺乏技术上的重大突破（加密货币可能是个例外）。 当前的技术机会： 合成专家：AI 技术的发展将使得某些服务变得非常便宜，并可能催生出“合成专家”类产品。这些产品可能以导师、教练或治疗师的形式出现，帮助用户学习新技能或支持情感需求。 消费化的创造力：AI 降低了创作门槛，使得更多创意领域变得对普通消费者友好。例如，Midjourney（图像）、Suno 和 Udio（音乐）、Runway（视频）等公司已经取得了突破。未来，软件开发、时尚设计、游戏开发等领域也可能会变得更加消费化。 新浏览器：浏览器可能成为用户与 AI 助手交互的主要应用，因为它是用户花费最多时间的地方。AI 提供商可能会与现有浏览器合作或收购它们，以获得用户的注意力。文章特别提到 Arc 浏览器可能成为 OpenAI 或 Anthropic 的收购目标。 AI 伴侣：AI 伴侣能够深入了解用户，提供个性化的建议和情感支持，甚至帮助用户更好地理解自己。尽管这种技术可能带来便利，但也可能让人们减少对人际关系的依赖。 总的来说，作者认为这些新兴的技术方向将带来新的消费互联网机会，但同时也提醒我们要谨慎对待这些技术对人类关系的潜在影响。 1994年的重现 2024年8月25日 随着技术的突破，最大的消费级互联网公司纷纷成立。 网络浏览器的诞生（Nexus 于1991年推出，Mosaic 于1993年，Netscape 于1994年）： Yahoo（1994年），Amazon（1994年），Ebay（1995年），Craigslist（1995年），Expedia（1996年），Paypal（1998年），Google（1998年）。 高速互联网的普及： LinkedIn（2003年），FB（2004年），YouTube（2005年），Reddit（2005年），Twitter（2006年），Spotify（2006年），Dropbox（2007年）。 Facebook 平台（2007年）+ iOS 应用商店（2008年）： Airbnb（2008年），Pinterest（2009年），Whatsapp（2009年），Venmo（2009年），Uber（2010年），Instagram（2010年），Snapchat（2011年），Tinder（2012年）。 2010年代对消费级互联网公司来说相当艰难。虽然有很多因素影响了消费者市场（例如，Facebook 撤销了 API，开始掠夺合作伙伴，并证明它可以成功击退、复制或收购潜在威胁……），但最简单的解释是，2010年代缺乏像之前那样推动消费市场发展的技术突破（加密货币可能是个例外）。 显而易见，我们已经进入了一个新的消费者机会期——类似于1994-1998年、2003-2007年和2008-2012年。 我们可以在哪些领域期待出现新的突破性消费应用呢？这里有几个想法： 合成专家 自动化的好处是服务变得极其便宜，但负面影响是，那些原本因为这些服务昂贵而依赖劳动的人会面临什么命运。 先从好的一面说起。在未来不远的某个时刻，我预计我们会看到类似“合成专家”的产品。 这些专家可能像导师一样，帮助我们学习新技能，比如烹饪、语言学习、高中物理、编程、象棋。它们也可能像教练或培训师，甚至是帮助我们满足情感需求的治疗师…… 创造力的普及 过去几年里，我们看到一些在不同创意表达领域取得突破的公司：Midjourney（图像），Suno 和 Udio（音乐），Runway（视频）。 我猜测有些创意领域，虽然目前还不太适合大众使用，但随着 AI 降低了进入门槛，最终会变得更加亲民。 比如软件开发——通过像 val.town、Claude 或 websim 这样的工具——可能会成为一个突破点。时尚设计、家具设计、游戏开发、硬件设计等领域也可能如此。我从未设计过自己的家具或开发过视频游戏，但我敢打赌，将来某一天我会尝试。...

在选择合适的模型时，需要在准确性、延迟和成本之间找到平衡。首先应优先优化准确性，达到目标后再优化成本和延迟。本文提供了一个实用指南，帮助用户在不同模型之间做出明智的选择，并通过一个假新闻分类器的示例展示了如何应用这些原则。 准确性优先 设定明确的准确性目标，例如在客户服务场景中，90%的电话需要在首次交互中正确分类。 开发评估数据集，以衡量模型在这些目标下的表现。 使用最强大的模型（如 GPT-4o）来优化准确性，记录所有响应以便后续使用更小的模型进行蒸馏。 成本和延迟优化 一旦达到准确性目标，可以通过以下方法优化成本和延迟： 使用更小的模型（如 GPT-4o-mini）进行零样本或少样本测试，确保在较低成本和延迟下维持准确性。 使用蒸馏技术对更小的模型进行微调。 实际示例 通过开发一个假新闻分类器，设定目标为90%的准确性、每千篇文章成本低于 $5、每篇文章处理时间少于2秒。 通过三次实验，最终使用微调的 GPT-4o-mini 达到了所有目标，成本仅为初始模型的2%。 结论 通过从 GPT-4o 切换到微调后的 GPT-4o-mini，性能相当但成本大幅降低。这一过程强调了先使用强大的模型达到准确性目标，然后再通过微调更小的模型来优化成本和延迟的策略。 如何选择合适的模型 选择合适的模型，无论是 GPT-4o 还是较小的 GPT-4o-mini，都需要在 准确性、延迟 和 成本 之间进行权衡。本指南为您提供关键原则，并通过一个实际例子帮助您做出明智的决策。 核心原则 选择模型的原则很简单： 首先优化准确性： 优化准确性，直到达到目标准确率。 其次优化成本和延迟： 在维持准确率的前提下，选择最便宜且最快的模型。 1. 首先关注准确性 首先为您的用例设定一个明确的准确性目标，确定达到“足够好”的准确率即可投入生产。可以通过以下方式实现： 设定明确的准确性目标： 明确您的目标准确率统计指标。 例如，90% 的客户服务电话需要在首次互动时得到正确分类。 开发评估数据集： 创建数据集，用以衡量模型的实际表现。 继续以上的例子，收集 100 个交互实例，记录用户的请求、LLM 的分类结果、正确的分类结果，以及分类是否正确。 使用最强大的模型进行优化： 从最强的模型入手，以确保达到目标准确率。记录所有响应，供后续更小的模型蒸馏使用。 使用检索增强生成 (retrieval-augmented generation) 来提高准确性。 使用微调 (fine-tuning) 来优化模型的一致性和行为。 在这个过程中，收集提示与生成对 (prompt and completion pairs)，用于评估、少样本学习或微调。这一过程被称为 提示优化 (prompt baking)，有助于未来生成高质量的示例。 想了解更多方法和工具，请查看我们的 准确性优化指南。 设定一个现实的准确性目标 通过评估模型决策的财务影响来设定一个合理的准确性目标。例如，在假新闻分类的场景中：...

本文讨论了创业者在公司扩展过程中面临的管理挑战，特别是与传统管理模式的冲突。作者通过引用 Airbnb 创始人 Brian Chesky 的经验，指出传统的“经理模式”在初创公司扩展时往往无效，甚至有害。相反，作者提出了“创始人模式”的概念，认为创始人应该继续以更直接、更深入的方式参与公司运营，即使公司规模扩大。虽然目前对“创始人模式”的理解还不成熟，但已有成功的案例证明其有效性。 传统管理模式的缺陷： 传统观点认为，随着公司规模扩大，创始人应逐渐退居幕后，依赖高管团队来管理公司。这种模式通常被总结为“雇佣优秀的人并给他们足够的空间工作”。 然而，许多创始人，包括 Brian Chesky，发现这种模式在实际操作中效果不佳，导致公司业绩下滑。 创始人模式的提出： 作者提出，创始人应保持对公司运营的深入参与，而不仅仅依赖高管团队。这种模式被称为“创始人模式”。 这种模式类似于 Steve Jobs 在苹果公司采用的方式，例如他每年都会与公司中最重要的 100 人举行一次特别的会议，而这些人并不一定是公司中职位最高的。 创始人模式的潜在挑战： 虽然创始人模式可能更有效，但它也更复杂，涉及到更多的直接参与和决策。这种模式可能会因人而异，甚至在同一家公司内，不同时期的实施方式也会有所不同。 文章还警告说，创始人模式可能会被误用。例如，一些创始人可能会借此为不愿意合理授权辩护，或者非创始人管理者可能会错误地尝试模仿创始人的行为。 未来展望： 作者希望未来能更好地理解和定义创始人模式，从而帮助更多的初创公司在扩展过程中保持成功。同时，他也意识到随着创始人模式的普及，可能会出现新的问题和挑战。 创始人模式 2024年9月 上周在 YC 的一场活动中，Brian Chesky 做了一场让所有在场者都记忆深刻的演讲。我事后与大多数创始人交流时，他们都表示这是他们听过的最好的演讲。Ron Conway 生平第一次忘记了做笔记。我并不打算在这里试图重现它，而是想谈谈它引发的一个问题。 Brian 的演讲主题是，关于如何经营大公司的传统智慧其实是错误的。随着 Airbnb 的扩展，一些出于好意的人建议他必须以某种方式管理公司以便扩张。这些建议可以乐观地总结为“雇佣优秀的人并给他们足够的空间去完成工作”。他照做了，但结果却十分糟糕。于是他不得不自己摸索更好的方法，其中部分灵感来自于研究 Steve Jobs 如何经营 Apple。目前来看，这些方法似乎确实有效。Airbnb 现在的自由现金流利润率已经位居硅谷前列。 在这场活动中，许多我们曾资助过的最成功的创始人都表示，他们也经历了类似的情况。他们同样被告知要用这种方式管理公司，但最终却对公司产生了负面影响。 为什么大家都在对这些创始人传达错误的建议？这对我来说是个谜。在反复思考后，我找到了答案：他们所收到的建议，其实是针对如何管理一个自己没有创立的公司——如何在你只是一个职业经理人时管理公司。但这种方法效果远逊于创始人自己的管理方式，对创始人来说，这种模式显得无效和不自然。因为创始人能够做到一些经理人无法做到的事情，而不去做这些事对创始人来说确实是错误的。 实际上，经营公司的方式有两种：创始人模式和经理人模式。到目前为止，即使在硅谷，大多数人也默认为初创公司扩展时必须转向经理人模式。但我们可以从那些尝试了经理人模式的创始人的失望中，以及他们努力摆脱这种模式的成功中，推断出另一种模式的存在。 据我所知，目前还没有专门讨论创始人模式的书籍。商学院甚至对它一无所知。到目前为止，我们只能依赖那些个别创始人通过自身实践所摸索出来的经验。然而，现在我们知道我们在寻找什么，我们可以更有针对性地去探寻。我希望在未来几年里，创始人模式能够像经理人模式一样被广泛理解。我们已经可以猜测出它在某些方面会有所不同。 经理人被教导的管理公司方法，似乎类似于模块化设计：你将组织结构中的各个部门视为一个个黑箱。你告诉直接下属该做什么，他们则负责具体执行。但你不会深入干预他们的工作细节。那样会变成微观管理，这是被认为不好的行为。 雇佣优秀的人并给他们足够的空间去完成工作。用这种方式描述听起来很有吸引力，不是吗？然而，实际上，许多创始人都发现，这往往意味着：雇佣一些看似专业的骗子，然后让他们把公司推向深渊。 我在 Brian 的演讲中，以及与其他创始人的对话中，注意到了一个共同的主题——被“误导”的感觉。创始人们感觉自己被两方面误导了：一方面是那些告诉他们必须像经理人一样管理公司的人，另一方面是当他们这样做时，公司内部的人对他们的反馈。通常情况下，当你周围的人都不同意你的意见时，你的默认假设应该是自己错了。但在这里，这是一个罕见的例外。没有自己做过创始人的风险投资人并不清楚创始人应该如何管理公司，而 C 级高管们则通常是极为擅长“向上管理”的高手。 无论创始人模式的具体内容是什么，很明显它将打破 CEO 只能通过直接下属与公司接触的传统原则。“跳级”会议将成为常态，而不再是一个如此不寻常以至于需要特别命名的做法。而一旦你放弃了这一限制，你就有无数的选择可以尝试。 例如，Steve Jobs 曾经每年为他认为是 Apple 最重要的100人举办一次休闲会，而这些人并不一定是组织结构图中职位最高的。你能想象在普通公司中做到这一点需要多大的决心吗？然而，试想一下这种做法可能带来的好处。它能够让一个大公司重新拥有初创公司的氛围。如果这些休闲会没有效果，Steve 应该不会年复一年地继续举办这些活动。但我从未听说有其他公司这么做。那么这是一个好主意还是一个坏主意？我们仍然不知道。这说明我们对创始人模式了解得有多么有限。 显然，创始人不可能继续用他们在公司只有20人时的方式来管理2000人的公司。某种程度的授权是必然的。自主权的边界在哪里，以及这些边界的明确程度，可能会因公司而异。甚至在同一家公司内部，随着管理者逐渐赢得信任，这些边界也会有所变化。因此，创始人模式将比经理人模式更为复杂，但它的效果也会更好。从个别创始人摸索前行的例子中，我们已经看到了这一点。 实际上，我关于创始人模式的另一个预测是，一旦我们弄清楚它的本质，我们会发现许多创始人其实早已在无意识中接近了这一模式——尽管他们的做法可能被许多人视为古怪，甚至更糟。 奇妙的是，想到我们对创始人模式的了解还如此之少，这本身就是一种鼓舞人心的念头。看看创始人们已经取得的成就，而他们是在面对不当建议的逆风中取得这些成就的。想象一下，如果我们能够告诉他们如何像 Steve Jobs 那样经营公司，而不是像 John Sculley 那样，他们又能取得怎样的成就呢？...

本文是 Django 的共同创建者，同时担任工程主管的 Jacob Kaplan-Moss 所写。软件项目的估算是一个众所周知的难题，许多项目经常出现成本超支和进度延误的情况。然而，尽管估算困难，作者强调了估算的重要性，并认为放弃估算可能会限制职业发展。准确的估算是可以学习和掌握的技能，它能够帮助建立信任并促进职业的进一步发展。Jacob Kaplan-Moss 分享了一种软件项目时间估算的技术。他的方法的核心特点是同时捕捉时间和不确定性，以便为项目制定更准确的时间表。他的技术包括将工作分解为较小的任务、估算不确定性、计算预期和最坏情况的时间、必要时进行精细化，以及跟踪估算的准确性以便不断改进。 估算的挑战： 软件项目估算普遍困难，研究表明许多 IT 项目成本超支超过 200%，并且平均延误近 70%。 大型软件项目尤其容易超支，预算超过 1500 万美元的项目平均超支 66%，进度延误 33%。 “无估算”方法的局限性： 尽管有“无估算”方法和 Agile 方法试图避免时间单位的估算，但在某些情况下，准确的时间估算是不可避免的。例如，销售团队可能需要一个具体的时间表来完成交易，或者其他团队可能依赖于特定功能的交付时间。 估算的重要性： 估算是职业发展的关键技能，能够准确地给出时间表并按时交付任务有助于建立信任。对于希望在技术职业中更进一步的人来说，掌握估算技能至关重要。 估算是可以学习的技能： 估算是一项可以通过实践和反复校准来学习的技能。通过反复的项目分解和时间估算，工程师可以逐渐提高估算的准确性，并了解团队的工作节奏和代码库的复杂性。 我的估算技术： 任务分解：Kaplan-Moss 建议将工作分解为不同复杂度的小任务，并使用实际的日历时间（而非理想化的“程序员时间”）来估算每个任务的完成时间。任务复杂度分为小（1天）、中（3天）、大（5天）和超大（10天）四种。 估算不确定性：在初步估算的基础上，他建议通过应用一个“如果事情出错”的乘数来捕捉不确定性。这个乘数根据不确定性水平（低、中、高、极高）从 1.1 到 5.0 不等。这样可以得到预期时间和最坏情况的时间。 计算时间：通过任务复杂度和不确定性乘数，计算出每个任务的预期时间和最坏情况时间。例如，一个中等复杂度且高不确定性的任务预期需要 3 天，但最坏情况下可能需要 6 天。 精细化估算：如果估算范围过大，他建议通过进一步分解大任务或减少不确定性来精细化估算。可以通过研究、短期试验（spikes）或直接动手完成部分任务来减少不确定性。 跟踪准确性：最后，他强调在项目进行过程中跟踪实际用时，并与估算时间进行比较。这种反馈循环有助于不断改进未来的估算精度。 其他估算技术：Kaplan-Moss 还提到了其他几种估算技术，如 PERT（程序评估与审查技术）、基于证据的调度（Evidence-based scheduling）和水果沙拉 Scrum（Fruit-salad scrum），并指出这些技术也捕捉了时间和不确定性，但采用了不同的方法。 软件项目估算 众所周知，估算软件项目的难度非常大。哈佛商业评论 (HBR) 的一项研究发现，每六个 IT 项目中就有一个成本超支超过 200%，且延迟几乎 70%。麦肯锡 (McKinsey) 的另一项研究发现，IT 项目的平均预算超支 45%，时间超出计划 7%。研究还指出，大型软件项目的问题尤为严重：预算超过 1500 万美元的软件项目，平均预算超支 66%，时间延迟 33%。 实际上，任何在软件行业工作过一段时间的人都经历过类似的情形。你可能曾自信地说“这应该只需要几天时间”，但一个月后却发现自己仍未完成。软件项目估算总是难免遇到霍夫施塔特定律 (Hofstadter’s Law)：“事情总是比你预期的时间更长，即使你考虑了霍夫施塔特定律。” 遗憾的是，许多人看到这种模式后，觉得估算软件项目太困难，干脆选择放弃。有一种被称为“无估算” (No Estimates) 的立场认为我们应该完全停止对软件项目进行时间估算。很多敏捷方法采用了任意的评分系统——如故事点 (Story Points)、T 恤尺码等——这些系统的设计目的就是为了避免给出具体的时间估算。...

BosonAI 联合创始人、亚马逊前首席科学家，人工智能框架 MXNet 的作者之一：李沐，今年8月份在母校上海交大做了一场演讲，主要分享了他对大语言模型（LLM）的技术现状、未来趋势的预测以及个人职业生涯的感悟。因为他的创业方向是为客户做定制的LLM，他应该是我们熟知的大牛中离LLM最近的人之一，包括数据准备/清晰、预训练、后训练、LLM部署、机房建设、提供 serving、GPU/带宽/电力瓶颈等等。所以，他的演讲会给出很多有关LLM的一线认知，这里我摘出了其中他提到的一些核心认知。 核心认知 语言模型可以分为三块：算力、数据和算法。所以语言模型也好，整个机器学习模型也好，本质上就是把数据通过算力和算法压进中间那个模型里面，使得模型有一定的能力，在面对一个新的数据时，它能够在原数据里面找到相似的东西，然后做一定的修改，输出你要的东西。 这一次（浪潮里）的语言模型和上一次深度学习（浪潮里）的模型有一个比较大的区别 —— 上一次是，我炼一个什么丹就治一个什么病，这次我希望这个东西炼出来会有灵魂在里面，它能解决你很多问题，这其实是技术一代代往前进。 硬件 带宽：让芯片靠得更近一些 因为就现在的模型训练而言，很难让一个机器搞定所有事情，所以要做分布式训练，通常瓶颈就在带宽上。 我们现在的带宽是一根光纤承载 400Gigabits，下一代就是 double，变成 800Gigabits。 英伟达的 GB200 这个卡就可以把 GPU 都放一起，那么它们之间的通讯会变得更好一些。你可以理解成：之前我们做多核，把单核封装到一个芯片里面，现在是说多核不够，我要做多卡，多卡以前是分布在一个房间里面，现在是多卡也要尽量放在一起，这是一个趋势。就是一块芯片那么大，早就做不上去了，这是台积电等面临的工艺难题，现在是尽量把这些东西弄得近一些。 还有一个通讯是 GPU 和 CPU 之间的 PCIe，它每几年也在翻倍，但是确实会慢一些。 内存：制约模型尺寸的一大瓶颈 现在的语言模型，核心是把整个世界的数据压进模型里面，那模型就被搞得很大，几百 GB 的样子。在运行的时候，它的中间变量也很大，所以它就需要很多的内存。现在我们可以做到一个芯片里面封装近 192 GB 的内存。下一代带宽会更高一点。 很有可能在未来几年之内，一个芯片就 200GB 内存，可能就走不动了。这个要看工艺有没有突破。 内存大小会是模型上限的一个制约，而不是算力。内存不够，模型就做不大。在这一块，虽然英伟达是领先者，但其实英伟达是不如 AMD 的，甚至不如 Google 的 TPU。 算力：长期来看会越来越便宜 机器学习好的一点是，你可以用 4 位浮点数，硬件会变小，它对带宽的利用率也会变低，因为每次计算它只有那么多浮点数在里面。所以我们最近几代优化都来自浮点数的精度的降低。这是它给硬件带来的好处。 当你把模型做得更大的时候，你会发现资源是问题，就是供电。 最大的一个芯片要耗一千瓦，一千块芯片就是一兆瓦，整个校园都未必能用上一兆瓦的电。 关于算力价格。从理论上来说，在公平的市场里面，每次算力翻倍，价格会保持不变。但因为英伟达垄断的原因，短期内算力翻倍，价格可能会有1.4倍的提升。长期来看算力会变得越来越便宜。 算力这块，你可以用别的芯片，但是这些芯片用来做推理还 OK，做训练的话还要等几年的样子，英伟达还是处在一个垄断的地位。 今天训练一个模型，一年之后它的价值会减半。很多时候，大家不要去想我现在能搞多大的模型，一年之后，这个模型会贬值。我想说，大模型不是特别有性价比的东西。你要想清楚，从长期来看，你的模型能带来什么价值，让你能够保值。 模型 我觉得语言模型已经达到了较高的水平，大约在 80 到 85 分之间。 音频模型在可接受的水平，处于能用阶段，大约在 70-80 分之间。 但在视频生成方面，尤其是生成具有特定功能的视频尚显不足，整体水平大约在 50 分左右。 语言模型：100B 到 500B 参数会是主流 每次预训练，无论是 OpenAI 还是别的模型，基本都是用 10T 到 50T token 做预训练。开源的话基本也在 10T token 以上。这个数据量我觉得差不多了，不会再往一个更大的尺寸去发展。原因是，人类历史上的数据比这个多是多，但是看多样性、质量的话，我觉得 10T 到 50T 这个规模就差不多了。 我觉得比较好的一线的模型就是 500B，超过 500B 不是训练不动，而是做 serving 很难。在谷歌历史上，他们就没有让 500B 以上的模型上过线。OpenAI 没有对外说，但我觉得 OpenAI 历史上没有上线过有效大小超过 500B 的模型。当然 MoE 不算，我是说换算成稠密模型的话 语音模型：延迟更低、信息更丰富 GPT-4o 出来之后，大家对于语音模型产生了浓厚的兴趣。端到端的方案有两个优点: 1....

本文探讨了程序员 Jeff 和 Sanjay 之间深厚的友谊及其对 Google 成功的推动作用。他们的紧密合作不仅体现在工作中，还在生活中展现了创意与效率的结合。两人的协作方式、互补的思维方式以及在编程中的默契，使他们成为了 Google 发展过程中不可或缺的搭档。 友谊与合作：Jeff 和 Sanjay 在 Google 之前就建立了深厚的友谊，他们常常一起度假，Jeff 的女儿们称 Sanjay 为“叔叔”。这种紧密的私人关系促进了他们在工作中的合作。 编程风格的互补：Jeff 更加外向和探索性，能迅速提出新想法，而 Sanjay 则专注于系统设计，编写出结构优美的代码。他们的合作使得编程过程更加高效，减少了创意瓶颈的发生。 重要项目：两人共同开发的 MapReduce 软件为 Google 带来了巨大的性能提升，使得程序员能够更高效地处理数据。该技术后来成为 Hadoop 的基础，广泛应用于大数据处理。 AI 的发展：Jeff 在 Google Brain 项目中的参与，使得神经网络技术得以迅速发展，最终取代了传统的搜索算法，标志着 Google 在 AI 领域的转折。 角色变化：随着时间的推移，Jeff 和 Sanjay 的角色逐渐分化。Jeff 负责更大的项目和团队管理，而 Sanjay 则专注于独立开发，继续为 Google 的技术决策提供支持。 持续的友谊：尽管工作节奏有所变化，两人仍保持联系，定期共进晚餐，回忆起早年的合作时光，展现了他们之间持久的友谊与默契。 谷歌崛起背后的友谊 “我们在 Google 之前就已经这么做了。” Jeff 说道。 “但我也不清楚为什么我们觉得坐在一台电脑前比两台更好。” Sanjay 说道。 “我常常从离两条街远的 D.E.C. 研究室走到他的 D.E.C. 研究室，” Jeff 说道。“中间还经过一家意式冰淇淋店。” “所以是因为那家冰淇淋店！” Sanjay 笑着说。 单身的 Sanjay 经常与 Jeff 及其妻子 Heidi 和两个女儿一同度假。Jeff 的女儿们称他为 Sanjay 叔叔，五个人通常在周五晚上一起吃饭。Sanjay 和 Jeff 的大女儿 Victoria 开始一起烘焙。“我看着他的女儿们一点点长大，” Sanjay 自豪地说。2004 年 Google 上市后，他们搬到了相距四英里的新居。Sanjay 住在旧山景城的一栋普通的三居室，而 Jeff 则亲自设计了他位于帕洛阿尔托市区附近的房子，还在地下室装了蹦床。在设计这栋房子时，他意识到虽然他喜欢规划空间设计，但没有耐心去处理那些他称之为“适合 Sanjay 的建筑细节”：如梁柱、螺栓和承重结构，这些都是支撑整体设计的基础部分。...

本文介绍了如何高效地对 Llama 3.1 模型进行监督微调，特别是使用 Unsloth 库进行 8B 模型的微调。文章强调，Llama 3.1 的发布缩小了闭源和开源模型之间的性能差距，微调该模型可以实现更好的性能和定制化，且成本更低。作者提供了监督微调的全面概述，比较了与提示工程的不同，并详细介绍了主要技术及其优缺点。 监督微调（SFT）概述： SFT 是一种改善和定制预训练 LLM 的方法，通过在较小的数据集上重新训练基础模型，使其能够更好地执行指令和回答问题。 SFT 可以提高模型的整体性能，增加新知识，或适应特定任务和领域。 SFT 技术： 全微调：对预训练模型的所有参数进行重新训练，效果最佳但需要大量计算资源。 LoRA（低秩适应）：只训练小的适配器，减少内存使用和训练时间，非破坏性。 QLoRA：LoRA 的扩展，提供更高的内存节省，适合 GPU 内存受限的情况，但训练时间更长。 微调 Llama 3.1 8B 的过程： 使用 Unsloth 库进行高效微调，支持单 GPU 设置，提供更快的训练速度和更低的内存使用。 训练使用了 mlabonne/FineTome-100k 数据集，经过处理后应用 ChatML 模板。 训练参数和过程： 训练使用 A100 GPU，耗时约 4 小时 45 分钟，建议在资源有限的情况下加载数据集的子集以加快训练。 主要超参数包括学习率、批量大小、训练轮数等，使用 AdamW 8-bit 优化器。 模型评估与保存： 训练完成后，通过简单的提示测试模型性能，并使用 Unsloth 提供的保存方法将训练好的模型上传到 Hugging Face Hub。 文章还提到量化模型的不同格式以便于在推理引擎中使用。 后续步骤建议： 评估模型性能，进行偏好对齐，量化以提高推理速度，或在 Hugging Face Space 部署模型。 使用 Unsloth 超高效微调 Llama 3....