大语言模型：那些硬核难题——第一性原理：在开始用 LLM 构建之前，我们需要考虑什么

自由这种东西，如果不用，就会死去。

------亨特·S·汤普森

大语言模型（LLM）代表了一个真正的拐点：它改变了软件能够做什么，也改变了我们构建应用的方式。LLM 能够理解上下文，识别文档之间的模式，生成连贯的解释，并且在没有脆弱规则集或海量训练数据的情况下，适应细微复杂的请求。这些能力非常惊人，而开源工具又让任何规模的组织、任何预算水平的个人，都能够接触到这项技术。本书的目标，是让读者掌握开源框架，以便成功落地这项技术，并避开那些容易让我们走偏的常见陷阱。

在接下来的章节中，我们会通过讨论、动手示例和可复现的代码流程，帮助大家进入并理解这个世界。我们强调的不只是 LLM 本身，而是构建我们称之为 基于 LLM 的应用 ，也就是 LLMBA。我们相信，LLM 真正困难的部分，出现在我们把它们应用到真实世界中那些可处理、可落地的问题上时。

不过，在真正开始构建之前，我们先花几页篇幅，讨论一些在写代码或设计框架之前就必须考虑的第一性原理。

本书会使用多种工具。我们调用的许多 LLM 是专有模型，并通过 API 访问。我们认为，熟悉如何调用这些 API 是有价值的；同时，我们也会介绍完全本地化的工具。不过，对于那些困难的 LLM 问题的解决方案，我们会重点关注开源。

为什么是开源？

我们之所以聚焦于用开源方案解决常见的 LLM 陷阱，首要原因是：我们希望本书中的代码可以被任何拥有一台笔记本电脑和互联网连接的人复现。第二，我们相信，使用开源工具进行构建，并学习如何用这些工具应对风险，可以为我们打下扎实的基础。即使在更强大的企业级工具已经可用的情况下，它也会迫使我们从零开始构建一些东西。如果有一天，我们有机会使用那些企业级工具，那么对开源实现的理解，也会让我们知道这些工具底层到底发生了什么。最后，正如我们会在结尾章节中讨论的那样，我们对开源模型和专有模型的未来都相当乐观，并且预见到这样一个世界：二者会共存在同一个生态系统中，并在各自擅长的领域繁荣发展。

开源为我们提供了一个本地、可访问的环境，让我们可以实验、折腾，并理解运行 LLM 时会遇到的挑战。这能帮助我们作为"手艺人"做出有根据的决策，更有效地排查问题，并推动可能性的边界。

运行开源模型还能让我们切身感受到不同模型之间的差异。例如，7B 参数模型和 70B 参数模型之间有什么区别；速度和质量之间如何取舍；不同评估库如何帮助我们搭建框架。我们可以自由实验，而不用担心 API 成本不断累积，也不用担心速率限制打断我们的探索。这种亲手实验会建立一种非常宝贵的直觉。当我们之后在企业环境中做架构决策时，这种直觉尤其重要，因为我们不仅知道文档上写了什么，也知道实际跑起来什么才有效------因为我们亲自试过。

归根到底，开源工具是我们理解 AI 系统的个人实验室。我们可以把东西搞坏，从失败中学习，测试大胆的想法，并在不受企业系统限制和成本约束的情况下建立真正的专业能力。这种对技术深入而亲身的参与，正是那些真正理解工具的手艺人，与那些只是使用工具的人之间的区别。

战略性考虑

要想成功地将 LLM 作为应用的一部分来实现，也就是构建 LLMBA，这件事早在选择模型或编写提示词之前就已经开始了。基础在于：我们需要清晰定义一组需求，而这些需求会覆盖企业或组织的许多不同方面。

企业需求

明确企业需求，是成功构建 LLMBA 的第一步。我们需要具体描述：我们要解决什么问题，以及这个问题为什么对企业重要。像"我们想用 AI"或者"我们想提升效率"这样模糊的愿望，并不足以指导实施决策，也无法衡量成功。相反，我们需要深入到具体结果：这个项目是否能把客户等待时间从五分钟降低到三十秒，从而可能以可衡量的比例提高留存率？它是否能消除一个当前每年要耗费公司 20 万美元人工工时成本的手工录入流程？这里的"为什么"，必须直接连接到企业影响：要么是通过效率提升带来的成本节约，要么是通过改善客户体验、加快上市时间或增强决策能力带来的收入增长。

预算和投资回报率（ROI）的考虑，对于确保 LLMBA 的长期可行性也至关重要。组织必须设定清晰的支出上限，使其与自身财务能力相匹配，同时定义现实可行的单次交易成本目标。ROI 预期需要通过详细分析谨慎建立，并且要根据不同用例的业务影响和优先级，在各类用例之间进行战略性的预算分配。

利益相关方需求

在 LLMBA 的语境中，利益相关方指的是组织内部那些推动 AI 能力需求的人。我们首先要识别所有利益相关方：从批准预算的高管，到每天会与系统交互的最终用户，到需要治理数据的数据工程师，再到工作流会因此发生变化的团队。

理解到底是谁需要我们的 LLM 解决方案，会揭示出最终决定项目成败的人类上下文。项目究竟会被真正采用，还是变成束之高阁的"货架产品"，往往取决于这一点。这种利益相关方映射还会帮助我们发现潜在的支持者：他们可以在开发过程中提供领域知识，并在上线后推动采用。

合规与安全需求

安全和合规不能被忽视，也不能被推迟处理。这包括全面识别所有适用的监管要求，并建立稳健的数据处理标准。组织必须明确完整的审计要求，以保持透明度和问责能力，同时实施适当的安全控制，保护敏感数据和系统访问。

性能需求

准确性和质量构成了任何 LLM 性能需求的基础。从根本上说，这意味着我们需要确定一个模型必须达到的最低准确性水平，才能被认为是成功的。这是评估模型表现和做出部署决策时的关键基线。建立清晰的评估指标，无论是通过自动化指标，还是通过人工评估流程，都可以为判断这些阈值是否被满足提供具体方法。持续监控这些准确性指标，可以确保系统随着使用模式和数据分布的变化，仍然保持性能。

延迟和吞吐量需求同样关键，因为它们决定了用户体验和系统可靠性。这些规格定义了系统必须多快响应请求，以及它能处理多少并发用户。响应时间需求必须与可用的计算资源仔细平衡，而峰值负载能力则需要考虑使用高峰和增长模式。究竟采用实时处理来提供即时响应，还是采用批处理来提高效率，很大程度上取决于具体用例和用户预期。

运维需求

规模和容量是 LLM 部署运维需求的支柱。我们必须全面分析预期的系统使用情况和增长模式，以确保基础设施既能支撑当前需求，也能支撑未来需求。组织需要谨慎预测每日和每月的模型调用量，同时计算每次请求的平均 token 数，以准确估算资源需求。理解使用模式，包括季节性变化，有助于进行合理的容量规划。此外，制定 12 到 24 个月的增长预测，可以帮助确保基础设施能够随着需求增长而适当扩展。

可靠性和可用性需求对于维持稳定的服务质量同样关键。这些规格定义了系统必须保持的预期正常运行时间，通常表示为总运行时间中的百分比。组织需要设定清晰的维护窗口，在尽量减少用户中断的同时，确保必要的系统更新和优化可以执行。还必须明确完整的备份和故障转移需求，以确保在发生故障时业务连续性不受影响。

集成需求

系统集成需求定义了 LLM 系统如何与现有基础设施和应用进行交互与通信。这包括仔细梳理所有集成点，也就是 LLM 系统需要连接其他系统的位置；建立标准化的数据格式和接口，以实现顺畅通信；实施强健的安全措施，保护传输中的数据；以及识别任何可能影响集成的技术约束。把这些集成需求做好，对于确保 LLM 系统能够在更广泛的技术生态中有效运行至关重要。

数据管理需求

数据管理需求关注信息如何在 LLM 系统中被存储、处理和维护。这包括确定合适的存储方案，用于保留对话上下文和历史；选择并配置向量数据库，以支持高效的 RAG；制定全面的数据保留策略，在运维需求和资源约束之间取得平衡；并确保所有数据处理实践符合相关隐私法规。良好的数据管理对于系统性能和监管合规都至关重要，因此它是任何 LLM 实施中的关键考虑因素。

组织级 AI 框架

除了这些需求之外，我们还需要围绕如何治理、衡量和扩展我们的 LLMBA 生态做出一个重要决策。我们会考虑三种不同的框架：集中式、去中心化式和联邦式。

集中式框架

在集中式框架中，一个核心团队负责管理整个组织内的 AI 开发和部署。这个框架将 AI 专业知识、基础设施和决策权集中在一个地方，通常由首席 AI 官负责，或者由一个专门的 AI 卓越中心（COE）承担。中央团队负责制定并实施整体战略、政策和标准，同时监控合规并确保质量。

理想情况下，这个团队是一个多学科团队，包括数据工程师、IT 架构师、业务分析师和 AI 伦理专家，并由一位 C 级高管监督运营。不同机构中的组织结构各不相同，可能是专门的集中式指导委员会，也可能是中心辐射型系统，其中多个职能中心在一个整体网络中协同工作。

对于金融机构等高度监管行业来说，这种框架提供了简化的治理、一致的合规和清晰的问责。它确保整个企业拥有统一的数据标准和政策，降低合规碎片化风险，并简化监管报告。

然而，随着各业务单元对 AI 解决方案的需求增长，集中化也可能造成瓶颈，进而放慢创新速度，使中央团队从赋能者变成约束条件。

去中心化框架

去中心化框架赋予各个业务单元或团队完全的自由：每个团队可以定义自己的规则，选择自己的工具，并管理自己的数据。在去中心化方法中，AI 开发和部署由各业务线自行发起和管理。这个框架最大化了速度和敏捷性，因为没有官僚流程或中央审批机制拖慢实验。业务单元可以快速原型化并部署精确适配其领域问题的 AI 解决方案，因此这种框架对那些优先追求创新速度而非标准化的组织很有吸引力。

然而，去中心化框架也伴随着重大风险。如果缺乏协调，组织会出现同一个关键指标存在多个相互冲突的定义，数据大量重复，质量不一致。对于受监管机构而言，更严重的问题是它会制造合规漏洞，因为组织没有统一视图，无法知道敏感数据在哪里、哪些模型正在生产环境中运行，或者不同 AI 系统如何可能形成聚合风险。

这种自主性既可能带来创造力，也可能带来 AI 驱动的混乱。实践中，很少有大型机构采用完全去中心化的 AI 项目，原因正是监管要求需要企业级的可见性和控制力。

联邦式框架

联邦式治理框架是一种混合方法，它将集中式的政策制定与去中心化的执行相结合，让组织在保持标准的同时，也能授权领域团队在既定护栏内自主行动。这种运营框架促进协作、复用和标准化，同时赋予业务线对其 AI 解决方案的控制权，在自治与治理之间取得平衡。

实践中，中央单元会制定企业级政策，覆盖模型风险管理、数据治理、伦理 AI 原则和安全标准。随后，各业务单元------例如在银行、财富管理、信用分析和交易台等领域------会在遵守这些护栏的前提下，实现适合自身商业需求的 AI 解决方案。

联邦式治理使自治团队能够在统一框架内运行，同时保持独立性，从而确保协调管理，并提升不同系统之间的一致性和可访问性。这个框架在大型金融机构中特别有效，因为不同部门有不同需求，但又必须保持企业级合规。中央团队负责持续演进运营框架，重构并增强 AI 服务，以满足各业务线不断变化的需求，并跟上快速发展的技术进步。联邦式方法实现了一种平衡：它既能缓解完全去中心化计划的风险，又能尽量减少过度集中带来的瓶颈。

大多数大型受监管机构在成熟之后，最终都会走向联邦式框架。它们通常先从集中控制开始，以建立标准；随后随着治理框架逐步稳固，再逐渐授权业务单元。

数据的重要性

无论 LLM 多么强大，没有有效的数据战略，就不可能有有效的 AI 战略。事实上，当有人问我们"AI 的价值是什么？"时，我们喜欢把这个问题重新表述为："被 AI 分析的数据有什么价值？"确实，在开始构建大多数企业级 LLMBA 之前，我们需要全面盘点自己实际能够访问哪些数据，这些数据在哪里，以及我们是否被允许使用它们，尤其是在使用 LLM 的情况下。

我们可以先区分组织中的结构化数据和非结构化数据。结构化数据具有预定义的模式，并以整齐的格式呈现，可以直接用于分析；而非结构化数据没有任何预定义格式，以原始形态存在。金融交易、客户账户记录和交易数据是结构化数据；电子邮件、呼叫中心转写文本、研究报告和合同则是非结构化数据。

接下来，我们必须确定的不只是我们拥有哪些数据，还包括我们是否有法律权利用这些数据开展 AI 项目。通用数据保护条例（GDPR）、健康保险流通与责任法案（HIPAA）或加州消费者隐私法案（CCPA）等数据隐私法规，都要求对个人数据和敏感数据进行适当处理和保护；而非结构化数据治理则包括确保遵守这些法规的相关程序。

设想一个场景：我们希望分析客户趋势，而这需要分析客户数据。我们需要问：客户在开户或开始与我们交易时，是否授权了这种具体用途？我们的隐私政策是否限制了他们的信息可以如何被使用？这种用 LLM 分析数据的新方式，是灰色地带，还是明确允许的白色地带？

对于第三方数据，例如市场行情、采购数据集和供应商信息，我们必须审查许可协议，以确认是否允许用于 AI。许多数据供应商明确禁止使用其数据进行模型训练，同时又会提供同一数据的 AI-ready 版本，使 LLM 能够从中生成洞察。但如果我们还想让应用对齐某项公司政策呢？这确实需要微调，那么这些不同数据源是否允许用于微调？换个角度说，如果我们拥有一个专有数据集，我们一定希望它被用来微调某个 LLM 吗？

为了解决这些潜在问题，我们的数据范围界定流程应当实施治理专家所说的发现、分类和血缘追踪。数据发现和盘点涉及识别并编目数据，以便对其进行妥善管理，包括定位存储在各种仓库中的数据，例如文件共享、云存储和电子邮件系统。数据分类则涉及根据数据的敏感性、重要性和与组织的相关性，对数据进行标记和分段。例如，在金融组织中，只有具备强健的治理能力，才能共享那些可能包含客户个人身份信息（PII）或其他敏感数据的敏感文档。

实施端到端工作流，可以让团队连接到数据源，抽取关键实体，丰富元数据，并跟踪数据血缘，以确保透明度和信任。血缘追踪可以回答一些关键问题：这些数据来自哪里？谁访问过它？它经过了哪些转换？我们能否证明自己的使用方式符合内部政策和外部法规？如果没有这个基础，我们的 AI 计划要么会因为合规审查而推进过慢，要么会推进过快，并制造出只有在部署之后才会暴露出来的责任风险。

模型类型

本书后续会详细讨论基准测试和评估，因此这里我们先考虑不同类型的 LLM：基础模型、指令微调模型和领域适配模型。图 1-1 展示了这些模型的演进过程：从最通用，到最具体。

图示说明：模型类型的演进，从基础语言模型，到指令微调模型，再到领域适配模型。

图 1-1 模型类型的演进

基础模型

基础语言模型是通过预训练创建出来的基础性 LLM。所谓预训练，是指在海量文本数据上训练神经网络，让它预测序列中的下一个 token。这些模型通过处理来自书籍、网站、代码仓库和其他文本来源的数万亿 token，学习语言中的统计模式、结构和关系。基础模型会形成广泛能力，例如语法、事实知识、推理模式，甚至某些涌现能力；但从根本上说，它们是文本补全引擎，而不是对话助手。

所谓文本补全引擎，是指基础模型并不是在真正"回答"我们的问题，而是在给定其训练结果的情况下，以统计上最可能的方式继续文本。它可能会补全一个句子，模仿问题的风格，也可能朝意想不到的方向偏离。这种原始、未对齐的行为，一方面是基础模型在直接交互中的限制；另一方面，在某些希望进行纯模式延续的应用中，它也是一种优势。

这些模型之所以被称为"大"语言模型，主要原因是参数规模，也就是数十亿甚至数万亿个数值权重，这些权重编码了模型学到的知识和能力。早期语言模型只有数百万参数，而现代 LLM 的参数规模从数十亿，例如 7B 参数的小型模型，到数千亿甚至更多，例如 GPT-4 或 Llama 4。

这种规模通过少样本学习、复杂推理和跨领域泛化等能力，释放出性质上不同的行为，而大多数较小模型根本不具备这些行为。"大"这个称谓既反映了模型的尺寸，也反映了训练它们所需的计算规模，并由此将这些基础模型与只能处理较有限语言任务的较小前辈区分开来。

指令微调模型

指令微调模型是指经过额外训练的 LLM，这种训练使用的是"指令---响应"示例，使模型能够更好地遵循自然语言任务指令，并生成有帮助的回答。这个过程帮助 LLM 更好地理解用户想要什么，并做出恰当回应。

这个过程通常包括在高质量指令和期望响应示例上进行监督微调（SFT），随后通常还会进行基于人类反馈的强化学习（RLHF）。RLHF 是一种机器学习技术：人类对 AI 输出进行评分或排序，以教会 AI 哪些回答更好，使其学习那些很难提前明确规定的偏好，并让其行为与人类偏好保持一致。

例如，当我们与 ChatGPT.com 或 Claude.ai 交互时，我们实际上是在与指令调优后的模型对话。如果没有这类额外训练，基础预训练模型在对话中会远不如现在有用，它们往往会以意想不到的方式继续文本，而不是直接回答问题。

Llama 2 模型家族很好地展示了这些区别。基础版 Llama 2 在两万亿个公共数据 token 上训练，在文本生成和翻译任务中展现出通用能力。其面向聊天优化、经过指令调优的变体 Llama-2-Chat，则在超过一百万条人工标注的对话示例上进行了额外微调，因此尤其擅长自然对话。

表 1-1 中的基准结果突出了模型专门化的影响。我们可以看到，聊天优化版本在真实性方面有显著提升，关于 TruthfulQA 我们会在后续章节中讨论。同样，在衡量有毒内容生成的 ToxiGen 基准上，与基础模型 21% 到 26% 的毒性比例相比，Llama-2-Chat 模型几乎显示出零毒性。

表 1-1 Llama 2 模型家族的基准测试结果

模型	规模	TruthfulQA	ToxiGen
Llama 2	7B	33.29	21.25
Llama 2	13B	41.86	26.10
Llama 2	70B	50.18	24.60
Llama-2-Chat	7B	57.04	0.00
Llama-2-Chat	13B	62.18	0.00
Llama-2-Chat	70B	64.14	0.01

a Hugo Touvron 等，《Llama 2: Open Foundation and Fine-Tuned Chat Models》（2023）。

虽然 Llama 系列模型在通用知识、指令遵循和专门领域中都表现强劲，但在高度特定的应用中，专门构建的模型仍可能优于它。

领域适配模型

领域适配模型是通过在特定领域数据上进行有针对性的微调和/或偏好对齐，从而专门适配某些领域的模型。

BloombergGPT 是一个很好的例子。它是一个 500 亿参数模型，训练数据集由领域特定的金融数据和通用文本混合组成。该模型的构建者发表了一篇详细论文，介绍了他们的流程和涉及的步骤：

大规模领域特定数据集的整理

Bloomberg 创建了 "FinPile"，这是一个全面的英文金融文档集合，包括新闻、申报文件、新闻稿以及从网页抓取的金融文档。

领域数据与通用数据的平衡

训练语料大约一半是领域特定文本，一半是通用文本，以确保模型既能在金融任务上表现出色，又能在通用基准上保持稳健表现。

自定义分词

团队采用了 Unigram 分词器，并结合基于字节的方法，以更好地处理领域特定术语。

巨大的计算投入

Bloomberg 使用 GPU 服务器训练该模型，花费约 270 万美元。

完整描述可参见 Wu 等人在 2023 年发表的《BloombergGPT: A Large Language Model for Finance》。

其他领域适配模型的例子包括 Med-PaLM，这是 Google 基于 Pathways Language Model（PaLM）适配到医疗领域的模型；BioGPT，这是 Microsoft 为生物医学文本生成和挖掘设计的模型；以及 Code Llama，这是 Meta 为编程和代码相关任务适配的模型。

模型特性

模型特性既可能使 LLM 能够用于某些具体用例，也可能限制其可行性。理解候选模型的特性，对于判断一个模型是否适合我们的应用至关重要。这里我们重点关注以下特性：上下文长度、输出控制、缓存和输出 token 长度。

上下文长度

模型处理更长文本序列的能力，会直接影响它是否适合某项任务。上下文长度，也称上下文窗口或最大序列长度，指的是模型在一次请求中可以处理的 token 总数，包括我们的输入提示词和模型生成的响应。在过去一年左右，我们已经从 4K 到 8K token 限制作为标准，发展到现在支持 128K、200K，甚至百万 token 以上上下文窗口的模型。上下文长度之所以重要，是因为它决定了哪些任务在根本上是可行的。

有了更长的上下文，我们可以在不切块的情况下分析整篇文档，可以保留更长的对话历史而不忘记早期交流，可以提供完整代码库用于调试，也可以同时跨几十个来源进行多文档推理。然而，更长的上下文并不是免费的。它会增加内存需求，降低推理速度，尤其会影响首个 token 生成时间，并且有时会导致"中间遗忘"问题，也就是模型难以有效利用长提示词深处的信息。

输出控制

有些任务要求精确、事实性和结构化的输出，而另一些任务则允许更具创造性、更非结构化的生成。受控输出通常被称为结构化输出或约束解码，指的是强制语言模型生成符合特定格式或 schema 的文本的能力，最常见的是生成符合预定义结构的 JSON。

系统会在生成过程中限制模型的 token 选择，只允许那些能让输出继续保持在语法或 schema 所定义的有效路径上的 token。这意味着，如果我们的 schema 要求一个 "name" 字段必须是字符串，那么模型实际上无法生成会违反该约束的 token。对于需要可靠机器可读输出的生产系统来说，这项能力至关重要。

缓存

支持缓存的模型可以以更低成本加快推理速度。对于那些需要成本可控的实时响应应用来说，这一点尤其重要。多个开源 LLM 通过其推理框架支持提示词缓存，不过严格来说，这项能力更多属于服务基础设施，而不是模型本身。

Llama 模型通过 vLLM 等框架支持缓存，vLLM 实现了自动前缀缓存。Mistral 的开源模型也可以在兼容的推理引擎中使用类似缓存机制。尤其是 vLLM 框架，已经成为服务开源模型的一个标准框架，它拥有成熟的缓存能力，支持跨请求自动复用键值缓存（KV cache）。其他推理引擎，例如 Hugging Face 的 TGI（Text Generation Inference）和 SGLang，也为各种开源模型实现了提示词缓存。

输出 token 长度

模型生成更长回答的能力，会影响它是否适合内容生成任务。一个擅长简短回答的模型，可能在生成长篇内容时表现吃力，例如技术文档或详细分析报告。输出 token 长度，也就是最大输出 token 数，指的是模型在单次响应中最多可以生成多少 token。

这与上下文长度不同。一个模型可能拥有 200K token 的上下文窗口，但单次回答最多只能生成 4K 或 8K token。最近，我们也看到这个指标显著提升：过去被限制在 2K 到 4K 输出 token 的模型，现在已经扩展到 8K、16K，甚至 32K 以上。有些供应商现在允许输出占用大部分可用上下文窗口，不过生成极长回答也会带来它自身的挑战。

成本与速度

和任何系统一样，运行 LLM 应用所需的成本，以及我们返回结果的速度，都是重要考量。以下是我们在成本和速度方面会考虑的一些指标：

每输入 token 成本（CPIT）

对于长提示词，也就是输入很长的应用来说，CPIT 非常重要。例如文档分析、使用大上下文窗口的 RAG，或者带有大量历史记录的多轮对话。

每输出 token 成本（CPOT）

对于内容创作、代码生成或详细解释等生成类任务而言，CPOT 会成为主导因素，因为这些任务的回答往往很长。关键在于让成本结构匹配我们的用例：一个客户服务聊天机器人，查询很短但回答很详细，就应当优先关注较低的输出 token 成本；而一个处理成千上万页文档的文档分类系统，则应当关注输入 token 定价。许多团队错误地优化了不该优化的指标：当工作负载主要是输入密集型时，却选择了输出定价很好的模型；或者反过来。

总拥有成本（TCO）

TCO 远远超出了按 token 计价的范围，它涵盖完整的运营图景。如果是自托管，它包括基础设施成本，例如 GPU 支出、维护和扩展开销；还包括模型质量带来的隐藏成本，例如较便宜的模型是否需要更多重试或人工审核；以及开发人员花在优化和排障上的时间价值。一个更昂贵但能可靠产生正确结果的模型，可能比一个需要大量提示词工程、后处理或质量保障流程的便宜模型拥有更低的 TCO。此外，还要考虑与延迟相关的成本：较慢的模型可能需要更多并行实例才能满足吞吐需求，从而放大基础设施成本。最优选择往往不是按 token 最便宜的选项，而是在我们的具体任务、规模和质量要求下，以最低总体运营成本交付可接受质量的模型。

首个 token 时间（TTFT）

TTFT 对聊天机器人等流式应用非常重要，因为它衡量的是模型多快开始生成响应。TTFT 指的是用户提交提示词，到模型返回响应中第一个 token 之间的延迟。它本质上就是我们看到任何输出开始出现之前的"思考时间"。随着聊天界面部署给那些期待即时响应的用户，TTFT 变得越来越重要。

每输出 token 时间（TPOT）

TPOT 衡量的是生成开始之后，相邻 token 之间的延迟。它本质上是吞吐量的倒数，通常以每个 token 的毫秒数表示，而不是每秒 token 数。TPOT 决定了文本在生成时显得有多流畅。较低的 TPOT，也就是较快的 token 生成，会创造流畅的阅读体验；较高的 TPOT 会让回答显得迟缓或卡顿，即使 TTFT 表现不错也是如此。

许可

在为企业使用评估开源 LLM 时，理解许可格局至关重要，因为错误选择可能在后续造成法律和运营风险。传统开源许可证，例如 Mistral AI 使用的 Apache 2.0，以及 Microsoft Phi-3 使用的 MIT，提供了最大的自由度：我们可以在最少限制下对这些模型进行商业使用、修改和部署。因此，对希望拥有完全灵活性、同时避免法律复杂性的企业来说，它们是最安全的选择。

然而，自定义商业许可证会引入重要限制，企业必须仔细评估。Meta 的 Llama 3 和 Alibaba 的 Qwen2.5 虽然可以免费使用，但都带有使用规模阈值，分别是 7 亿用户和 1 亿用户；超过这些阈值后，就需要单独的商业协议。二者还都明确禁止使用其模型输出训练竞争性的 LLM。对于考虑在这些基础模型之上构建专有模型的企业来说，这一点尤其重要。

对大多数组织来说，实际结论是：如果我们是在典型企业规模下构建内部工具或应用，这些商业许可证是可行的；但如果我们是大型平台、超大规模云厂商，或者计划使用模型输出进行进一步 AI 开发，那么就应使用 Apache 2.0 或 MIT 许可的模型，以避免随着增长撞上许可边界。

表 1-2 总结了一些最流行开源 LLM 的许可条款。

表 1-2 开源 LLM

创建者	LLM	许可证
Meta AI	Llama 3	自定义------700M 用户以下免费；不能使用输出训练其他非 Llama LLM
Microsoft	Phi-3	MIT
Mistral AI	Mistral	Apache 2.0
Alibaba	Qwen2.5	自定义------100M 用户以下免费；不能使用输出训练其他非 Qwen LLM
Google	Gemma	自定义------免费，但有使用限制
DeepSeek	DeepSeek-V2	自定义------免费，但有使用限制；基于其输出训练的模型会成为 DeepSeek 衍生模型

表 1-2 只是示例，不构成法律建议。许可条款会因模型家族、模型版本、分发渠道和日期而变化。在商业部署模型之前，团队应直接查阅当前的模型卡和许可证文本。

定制化

在选择开源 LLM 时，模型定制化是一个重要考虑因素。针对特定用例进行适配和微调，会显著影响模型在生产环境中的实际效用和表现。

成功的模型定制化要求在整个开发生命周期中管理资源。这包括严格的数据集准备和验证，以确保高质量训练数据；仔细配置训练基础设施，以优化计算资源；在管理相关成本的同时系统性地进行实验迭代；建立全面的性能评估框架，以衡量改进效果；并周密规划部署架构，以确保顺利进入生产环境。当然，实际的存储和推理成本也应当纳入考虑。

小语言模型

近年 AI 研究中最重要的变化之一，是越来越多证据表明：更大并不总是更好。小语言模型（SLM）已经成为一种有吸引力的轻量替代方案，适用于许多定制化和部署场景。近期研究表明，较小模型可以达到令人意外的竞争性表现，甚至可以与规模大得多的模型相比。对于需要有能力的 AI，但又不想承担运行大模型所需基础设施成本、延迟和复杂性的企业与个人实践者来说，SLM 代表了一个务实的中间地带。SLM 对大量真实世界任务已经足够有用，同时又足够轻量，可以在普通硬件上运行。

这一代小模型中的一个突出例子是 Hugging Face 的 SmolLM2。这是一个紧凑型语言模型家族，提供三种规模：135M、360M 和 1.7B 参数。这些模型足够小，可以在设备端和本地硬件上运行，而不需要昂贵的 GPU 资源，因此相比传统大模型，它们适用于更广泛的部署环境。尽管体积紧凑，SmolLM2 模型却表现出远超其规模的能力：它们支持文本摘要、改写和函数调用，甚至通过 SmolVLM 扩展到多模态应用。

SmolLM2 在资源约束、隐私要求或延迟要求使大型云端模型不切实际的场景中尤其出色。例如边缘部署、移动应用、与外网隔离的企业环境，或者我们需要快速推理且不希望经过网络往返的场景。它广泛支持各类框架，这意味着我们几乎可以以很小摩擦将它集成到任何现有技术栈中。

对于希望更进一步的团队，SmolLM2 还支持通过 TRL 和参数高效微调（PEFT）进行微调。PEFT 是一组技术，允许我们只微调模型参数中的一个小子集，而不是整个模型，从而降低为特定任务定制 LLM 所需的计算资源和内存。此外，SmolLM2 还包含预训练和微调脚本，并提供用于构建自定义训练数据的合成数据流水线。

结论

现在，我们终于进入了实现阶段：是时候构建、迭代、优化、实验和创造了。在下一章中，我们会深入评估的世界。随着 AI 在企业应用中变得越来越普遍，评估已经成为 LLM 开发中一个越来越重要、也非常令人兴奋的领域。

关于 vLLM 的一个应用，可参见 Ye Wang 等人在 2025 年发表的《Fastest Speculative Decoding in vLLM with Arctic Inference and Arctic Training》。
参见 Wanying Ding 等人在 2025 年发表的《Better with Less: Small Proprietary Models Surpass Large Language Models in Financial Transaction Understanding》。