简而言之： 要优化 AI 模型，首先选择一个主要约束条件（延迟、成本、内存、质量、稳定性或吞吐量），然后在进行任何更改之前获取一个可靠的基准值。首先消除流水线瓶颈，然后应用混合精度和批处理等低风险的优化措施；如果质量保持不变，再进行编译器/运行时工具的优化，最后仅在必要时通过量化或蒸馏来减小模型大小。
要点总结：
限制：选择一到两个目标指标；优化是一个权衡取舍的过程，而不是免费的胜利。
测量：分析实际工作负载的 p50/p95/p99、吞吐量、利用率和内存峰值。
Pipeline：在处理模型之前，修复分词、数据加载器、预处理和批处理。
服务：使用缓存、有意识的批量处理、并发调优，并密切关注尾延迟。
防护措施：每次性能变更后运行黄金提示、任务指标和抽查。
🔗 如何有效评估人工智能模型？
公平可靠地评判模型的关键标准和步骤。
🔗 如何用真实指标衡量人工智能性能？
使用基准测试、延迟、成本和质量信号进行比较。
🔗 如何在生产前测试 AI 模型
实际测试工作流程：数据分割、压力测试和监控。
🔗 如何使用 AI 进行内容创作？
通过结构化的提示和迭代，更快地将想法转化为草稿。
1）“优化”在实践中的含义（因为每个人对它的理解都不同）🧠
人们常说的“优化人工智能模型”可能是指：
-
提高速度 （降低延迟）
-
降低成本 （减少 GPU 使用时间，降低云支出）
-
缩小体积 （内存占用、边缘部署）
-
提高准确性 （提升质量，减少幻觉）
-
使其更稳定 （减少波动，减少生产故障）
-
提高服务效率 （吞吐量、批量处理、可预测的性能）
这里有个有点恼人的真相：你不可能同时最大化所有这些因素。优化就像挤压气球——一端被挤压，另一端就会弹出来。虽然并非总是如此，但这种情况经常发生，所以你应该做好权衡取舍的准备。.
所以在进行任何操作之前，请先选择您的 主要约束条件：
-
如果您正在为用户提供实时服务，您会关注 p95 延迟 （AWS CloudWatch 百分位数）和尾部性能（“尾部延迟”最佳实践）📉
-
如果你在进行训练，你会关心训练 质量的达成时间 和GPU利用率🔥
-
如果你要在设备上部署，你会关心 内存和功耗 🔋
2) 优秀的 AI 模型优化版本是什么样的 ✅
好的优化方法并非只是“应用量化然后祈祷”，而是一个系统。最佳配置通常包含以下要素：
-
一个值得信赖的基准线。
如果你无法复现当前的结果，就无法确定自己是否取得了任何进步。道理很简单……但人们往往会忽略这一点。然后，问题就会陷入恶性循环。 -
明确的目标指标
很模糊。“在保持相同质量分数的前提下，将 p95 延迟从 900 毫秒降低到 300 毫秒”才是真正的目标。 -
质量保障：
每一次性能提升都可能导致质量悄然下降。你需要测试、评估，或者至少一套健全性检验工具。 -
硬件感知：
在某个GPU上运行“快速”的模型，在另一个GPU上可能运行缓慢。CPU本身就存在一种特殊的混乱局面。 -
迭代式修改，而非大刀阔斧的重写。
当你一次性修改五处地方，性能却有所提升时，你却不知道原因。这……令人不安。
优化应该像调吉他一样——微调、仔细聆听、反复练习🎸。如果感觉像是在耍刀子，那就说明有问题了。.
3) 对比表：优化 AI 模型的热门选项 📊
下面是一个简略的常用优化工具/方法对比表。当然，它并不完全“公平”——现实情况也并非如此。.
| 工具/选项 | 观众 | 价格 | 为什么有效 |
|---|---|---|---|
PyTorch torch.compile （PyTorch 文档） |
PyTorch 的朋友们 | 自由的 | 图捕获 + 编译器技巧可以减少开销……有时简直是魔法✨ |
| ONNX 运行时（ONNX 运行时文档） | 部署团队 | 相对自由 | 强大的推理优化、广泛的支持，有利于标准化服务 |
| TensorRT（NVIDIA TensorRT 文档） | NVIDIA部署 | 付费氛围（通常捆绑销售） | 激进的内核融合 + 精准的处理，点击速度极快。 |
| DeepSpeed（ZeRO 文档） | 训练团队 | 自由的 | 内存和吞吐量优化（ZeRO 等）。感觉就像喷气式发动机一样。 |
| FSDP（PyTorch）（PyTorch FSDP 文档） | 训练团队 | 自由的 | 分片参数/梯度，使大型模型不再那么可怕 |
| bitsandbytes 量化（bitsandbytes） | 法学硕士修补匠 | 自由的 | 低位权重，大幅节省内存——质量取决于具体情况，但呼😬 |
| 蒸馏（Hinton等人，2015） | 产品团队 | “时间成本” | 规模较小的学生模型能够继承学生的行为模式，通常从长远来看投资回报率最高。 |
| 剪枝（PyTorch 剪枝教程） | 研究 + 生产 | 自由的 | 去除冗余部分。与再培训结合使用效果更佳。 |
| Flash Attention / 融合内核（FlashAttention 论文） | 性能极客 | 自由的 | 注意力更集中，记忆力更强。变形金刚们真是赢家。 |
| Triton推理服务器（动态批处理） | 运维/基础设施 | 自由的 | 生产服务、批量处理、多模型流水线——感觉很像企业级产品。 |
格式怪癖坦白：“价格”这个词写得乱七八糟，因为开源软件仍然可能让你花一个周末的时间调试，这……也是一种代价。😵💫
4) 从测量开始：认真对待个人资料🔍
如果本指南只能让你做一件事，那就做到：正确测量。.
在我自己的测试中，最大的“优化突破”来自于发现一些极其简单的事情，例如：
-
数据加载器导致GPU资源不足
-
CPU预处理瓶颈
-
过小的批处理大小会导致内核启动开销
-
缓慢的分词（分词器可能是隐形的反派）
-
内存碎片（PyTorch CUDA 内存分配器说明）
-
单层主导计算
测量内容（最小测量集）
-
潜伏期 （p50、p95、p99）（潜伏期百分位数的SRE）
-
吞吐量 （令牌/秒，请求/秒）
-
GPU利用率 （计算+内存）
-
显存/内存峰值
-
每1000个代币（或每次推理）的成本
务实的侧写思维
-
描述一个你关心的场景（不是玩具提示）。.
-
把所有事情都记录在一个小小的“表演日志”里。
没错，这很繁琐……但它能避免你日后自我否定。
（如果你想要一个具体的工具作为起点： PyTorch Profiler （torch.profiler 文档）和 Nsight Systems （NVIDIA Nsight Systems）是常用的选择。）
5）数据+训练优化：无声的超能力📦🚀
人们过于关注模型架构而忽略了流水线。与此同时，流水线却悄无声息地消耗了GPU一半的资源。.
轻松获胜，而且很快就能见效。
-
使用混合精度 （FP16/BF16，如果稳定的话）（PyTorch AMP / torch.amp）
通常更快，通常也很好——但要注意数值怪癖。 -
当批次大小受限时，梯度累积（ 🤗加速指南）可保持优化稳定，而不会导致内存爆炸。
-
梯度检查点 （torch.utils.checkpoint）
以计算换取内存——使更大的上下文成为可能。 -
高效的代币化 （🤗 代币生成器）
代币化在规模化应用中可能成为瓶颈。它并不光鲜亮丽，但却至关重要。 -
数据加载器调
优：增加工作进程数、限制内存使用、预取内存——这些看似不起眼但却非常有效😴➡️💪（PyTorch 性能调优指南）
参数高效的微调
如果你正在微调大型模型，PEFT 方法（例如 LoRA 风格的适配器）可以大幅降低训练成本，同时保持惊人的性能（🤗 Transformers PEFT 指南， LoRA 论文）。这真是让人不禁感叹“为什么我们没早点这么做？”。
6) 架构级优化：合理调整模型规模🧩
有时候，优化的最佳方法是……停止使用过大的模型。我知道，这简直是亵渎神明😄。.
就几个基本问题做出判断：
-
决定你需要的是全面的通用情报，还是某个领域的专家。.
-
保持上下文窗口的大小适中，不要过大。.
-
使用针对当前任务训练的模型（分类模型用于分类工作，等等）。.
切实可行的合理规模化策略
-
对于大多数请求，切换到较小的骨干网络；然后将“困难查询”路由到更大的模型。
-
采用两阶段模式：
先快速构建模型草稿，再进行更严谨的模型验证或修改。
这就像和一个挑剔的朋友一起写作——虽然令人恼火，但效果显著。 -
减少输出长度。
输出代码需要花费金钱和时间。如果你的模型冗长繁琐，你就要为这些冗长的代码付出代价。
我见过一些团队通过强制缩短工期大幅降低成本。这听起来有点小题大做，但确实有效。.
7) 编译器 + 图优化：速度的来源🏎️
这是“让计算机做更智能的计算机任务”层。.
常用技术：
-
算子融合 （合并内核）（NVIDIA TensorRT“层融合”）
-
常量折叠 （预计算固定值）（ONNX 运行时图优化）
-
内核选择 针对硬件进行了优化
-
图捕获 以减少 Python 开销（
torch.compile概述）
简单来说：你的模型在数学上可能很快，但在实际运行中却很慢。编译器可以解决其中的一些问题。.
实用笔记（又名伤疤）
-
这些优化措施可能对模型形状的变化很敏感。.
-
有些车型加速很快，有些车型几乎纹丝不动。.
-
有时候你会遇到速度提升，但同时也会遇到一个令人费解的bug——就像有小精灵搬进来了一样🧌
不过，一旦成功，这将是最干净利落的胜利之一。.
8) 量化、精简、提炼：化繁为简，不至于崩溃（过度）🪓📉
这正是大家想看的部分……因为它听起来像是自由发挥。的确可以，但你必须像对待手术一样对待它。.
量化（低精度权重/激活值）
-
非常适合推理速度和内存
-
风险：质量下降，尤其是在极端情况下。
-
最佳实践：在真实的测试集上进行评估，而不是凭感觉。
常见的口味有：
-
INT8 （通常为实数）（TensorRT 量化类型）
-
INT4 / 低位 （大幅节省，但质量风险增加）（bitsandbytes k 位量化）
-
混合定量 （并非所有内容都需要相同的精度）
修剪（移除参数）
-
移除“不重要”的权重或结构（PyTorch 剪枝教程）
-
通常需要重新培训才能恢复质量
-
比人们想象的要好……只要操作得当。
蒸馏（学生向老师学习）
这是我个人最喜欢的长期杠杆。知识提炼可以生成一个行为相似的更小的模型，而且它通常比极端量化更稳定（神经网络中的知识提炼）。
一个不太恰当的比喻：蒸馏就像把一锅复杂的汤通过过滤器过滤，结果得到……一锅更清淡的汤。当然，汤的制作过程并非如此，但你明白我的意思🍲。.
9）发球与推理：真正的战场🧯
你可以“优化”模型，但服务质量仍然可能很差。服务交付环节才是延迟和成本真正发挥作用的地方。.
发球决定胜负
-
批处理
可以提高吞吐量，但如果过度批处理则会增加延迟。需要权衡利弊。（Triton 动态批处理） -
缓存
提示和键值缓存重用可能会造成巨大的性能损失。（键值缓存解释） -
流媒体输出
速度更快，即使总耗时相近。感知很重要🙂。 -
逐个代币减少开销
有些堆栈会为每个代币执行额外的工作。减少这些开销，就能获得巨大收益。
注意尾部延迟
你的平均延迟可能看起来很棒，但你的 P99 值却很糟糕。不幸的是，用户大多处于延迟的尾部。（“尾部延迟”以及为什么平均值会骗人）
10) 硬件感知优化：使模型与机器匹配 🧰🖥️
不考虑硬件状况就进行优化，就像调校赛车却不检查轮胎一样。当然，你也能做到，但这有点傻。.
GPU 注意事项
-
内存带宽通常是限制因素，而不是原始计算能力。
-
加大批量生产规模或许会有帮助，但过一段时间就未必了。
-
核融合和注意力优化对于Transformer模型来说非常重要（FlashAttention：IO感知的精确注意力）。
CPU 注意事项
-
线程化、向量化和内存局部性都非常重要。
-
分词开销可能很大（🤗“快速”分词器）
-
你可能需要与GPU上不同的量化策略。
边缘/移动端注意事项
-
内存占用成为首要任务
-
延迟差异很重要，因为设备……情绪不稳定。
-
规模较小、专业化的模型通常比大型通用模型更胜一筹。
11）质量保障：不要因为“优化”过度而导致程序出现漏洞🧪
每次速度胜利都应该附带质量检查。否则，你庆祝一番，发布产品后，可能会收到类似“为什么助手突然像海盗一样说话？”这样的消息。🏴☠️
务实的护栏：
-
黄金提示 （一组您始终要测试的固定提示）
-
任务指标 （准确率、F1 值、BLEU 值，或其他合适的指标）
-
人工抽查 （没错，是真的）
-
回归阈值 （“允许的下降幅度不得超过 X%）
同时跟踪故障模式：
-
格式偏移
-
拒绝行为的变化
-
幻觉频率
-
反应长度膨胀
优化会以意想不到的方式改变行为。有时很奇怪，有时令人恼火，但事后看来却又在意料之中。.
12) 清单：如何逐步优化 AI 模型 ✅🤖
如果你想了解优化人工智能模型的清晰操作步骤，以下工作流程通常能让你保持理智：
-
定义成功
选择 1-2 个主要指标（延迟、成本、吞吐量、质量）。 -
测量基准
性能，分析实际工作负载，记录 p50/p95、内存使用情况和成本。（PyTorch 分析器） -
修复管道瓶颈：
数据加载、分词、预处理、批处理。 -
应用低风险计算可获得
混合精度、内核优化和更好的批处理。 -
尝试编译器/运行时优化，
例如图捕获、推理运行时和算子融合。（torch.compile教程， ONNX 运行时文档） -
降低模型成本：
仔细量化，尽可能提炼，必要时进行精简。 -
调整服务
缓存、并发性、负载测试、尾部延迟修复。 -
验证质量：
运行回归测试并并排比较输出结果。 -
迭代：
小幅修改，清晰记录，反复进行。低调却有效。
没错，这仍然是“ 如何优化人工智能模型 ”，即使感觉更像是“如何避免踩到耙子”。本质是一样的。
13）常见错误（这样你就不会像我们其他人一样重蹈覆辙）🙃
-
先优化后衡量，
你会浪费时间。而且，你还会自信满满地优化错误的东西…… -
只追求单一基准
测试结果，基准测试会因遗漏某些因素而产生谎言。你的实际工作负载才是真相。 -
忽略内存
问题会导致运行速度变慢、崩溃和抖动。（了解 PyTorch 中的 CUDA 内存使用情况） -
过早过度量化
低比特量化可能非常有效，但首先要采取更安全的步骤。 -
没有回滚计划
，无法快速回滚，每次部署都会变得压力巨大。压力会导致漏洞。
结语：以人为本的优化方式😌⚡
如何优化 AI 模型 并非一蹴而就，而是一个循序渐进的过程：测量、修复管道、使用编译器和运行时环境、调整服务，然后在必要时通过量化或蒸馏来缩小模型规模。务必按部就班，坚守质量标准，并且不要仅仅因为“感觉更快”就盲目相信它（感觉固然美好，但感觉并非性能分析工具）。
如果要简短概括：
-
先测量一下🔍
-
接下来优化管道🧵
-
然后优化模型🧠
-
然后优化服务🏗️
-
始终保持质量检查✅
如果这能帮到你，请记住：目标不是“完美模型”。目标是快速、价格实惠、足够可靠的模型，让你晚上能睡个安稳觉……大多数晚上😴。.
真实案例：优化支持工单摘要器🎟️⚡
设想
想象一下，一个小型SaaS团队使用人工智能模型来总结收到的支持工单，然后再由人工客服回复。模型虽然有效，但速度很慢：客服人员等待摘要的时间过长，而且公司为推理支付的费用也超出了预期。.
目标并非在所有方面都力求“改进”模型。团队选择了一个主要约束条件：在保证摘要质量可接受的前提下，降低 p95 延迟。.
他们的目标很明确：
将 p95 延迟从大约 2.4 秒减少到 1.2 秒以下，并且在 50 张票的测试集中，严重摘要错误不超过一个。.
工作流程需要什么
为了使之切实可行，团队召开了会议：
一套包含50张试卷的黄金测试套装，试卷分为短试卷、中试卷和散乱试卷三种。
摘要格式要求：3 个要点，不捏造事实，如紧迫性显而易见，请注明。
基准指标：p50、p95、p99 延迟、生成的令牌数、单张票成本和错误计数
一份简单的人工审核清单
访问模型日志、令牌计数和批处理/并发设置
如果质量下降，则提供回滚选项
关键在于：他们并非从量化开始。首先，他们会检查流水线是否存在时间浪费。.
示例说明
对于每个支持工单，请用三条要点概括客户的问题。.
包括：
-
主要问题
-
提及的任何产品领域
-
紧急程度或业务影响（如有说明）
不要捏造缺失的细节。如果客户提供的信息不足，请注明“未说明”。.
摘要字数请控制在 80 字以内。.
如何测试它
使用新旧两种设置分别运行相同的 50 张工单。.
每次运行记录：
p50、p95 和 p99 潜伏期
平均输出标记
每1000张票的成本
包含虚构细节的摘要数量
需要人工重写的摘要数量
然后测试一些棘手的情况：
一张包含三个独立问题的工单
一条非常愤怒的顾客留言
一张几乎没有任何细节的模糊票据。
包含粘贴日志的工单
客户在工单中提到要取消账户
这可以发现一个常见的错误，即优化使模型运行速度更快，但不够谨慎。.
结果
以下结果基于对 50 张样本票据在三次优化前后的计时：
基线：
p95 延迟：2.4 秒
p99 延迟：3.1 秒
平均输出长度：142 个单词
人工修改：50 人中有 11 人修改
严重虚构细节错误：50个中有3个
优化后：
p95 延迟：1.1 秒
p99 延迟：1.6 秒
平均输出长度：61 个单词
人工修改：5/50
严重虚构细节错误：50 例中 1 例
发生了哪些变化：
团队将输出字数限制在80字以内。
他们将低优先级工单以8张为一组进行集中处理。
他们缓存了重复的产品政策上下文
在确认质量合格后，他们开启了混合精度模式。
由于延迟目标已经达到，他们把量化工作留到以后再做。
在这个例子中，成本也降低了，因为模型生成的词元数量减少了。如果旧方案每张工单生成约 142 个单词，而新方案生成约 61 个单词，则输出长度减少了约 57%。团队可以直接从日志中验证这一指标。.
可能出现什么问题
最容易犯的错误就是只追求速度优化。一个速度更快但又捏造退款承诺的摘要并不能算是改进。.
其他容易犯的错误：
仅测试干净的票据
忽略 p99 延迟
忘记比较输出长度
同时更改批处理和模型设置
使用平均延迟而不是尾延迟
声称“质量保持不变”却没有提供审核清单
更安全的审查规则很简单：如果 50 份摘要中有超过 2 份捏造重要细节，则回滚并进行调查。.
实用要点
这就是稳健的AI模型优化在实践中的样子：选择一个约束条件，评估当前系统，首先去除冗余，应用低风险的改动，然后通过看似枯燥但至关重要的测试来检验质量。最终的成果不仅仅是更快的模型，更重要的是一个速度更快且值得信赖的模型。.
常问问题
优化人工智能模型在实践中意味着什么
“优化”通常意味着改善某个主要约束条件：延迟、成本、内存占用、准确性、稳定性或服务吞吐量。难点在于权衡取舍——提升某一方面可能会影响其他方面。一个切实可行的方法是选择一个明确的目标（例如 p95 延迟或达到质量保证所需时间），并朝着这个目标进行优化。如果没有目标，即使“改进”了，最终也可能失败。.
如何在不悄悄损害质量的前提下优化人工智能模型
将速度或成本的每一次变化都视为潜在的隐性倒退。使用诸如黄金提示、任务指标和快速人工抽查等防护措施。设定一个可接受的质量偏差阈值，并将输出结果进行并排比较。这样可以避免在产品发布后，当初“速度更快了”的想法演变成“为什么生产环境突然变得奇怪了？”.
优化开始前需要衡量哪些指标？
首先关注延迟百分位数（p50、p95、p99）、吞吐量（每秒令牌数或每秒请求数）、GPU 利用率以及峰值显存/内存。如果成本是限制因素，则跟踪每次推理或每 1000 个令牌的成本。分析实际应用场景，而不是简单的示例提示。记录一份简短的“性能日志”有助于避免盲目猜测和重复犯错。.
快速、低风险地提升训练效果
混合精度（FP16/BF16）通常是最快的优化手段，但要注意数值计算方面的问题。如果批处理大小有限，梯度累积可以在不耗尽内存的情况下稳定优化。梯度检查点机制以减少内存占用为代价来换取额外的计算资源，从而支持更大的上下文。不要忽视标记化和数据加载器调优——它们可能会悄无声息地消耗 GPU 资源。.
何时使用 torch.compile、ONNX Runtime 或 TensorRT
这些工具旨在降低运维开销：图捕获、内核融合和运行时图优化。它们可以显著提升推理速度，但效果会因模型结构和硬件配置而异。有些配置效果立竿见影，而有些则几乎毫无变化。请注意，这些工具对模型结构变化较为敏感，并且偶尔会出现一些“小故障”——建议在实际工作负载下进行优化前后的对比测试。.
量化是否值得，以及如何避免矫枉过正
量化可以大幅节省内存并加快推理速度，尤其是在使用 INT8 类型时，但某些极端情况下质量可能会下降。低位量化选项（例如 INT4/k 位）虽然能带来更大的内存节省，但也伴随着更高的风险。最稳妥的做法是在真实的测试集上进行评估并比较输出结果，而不是凭感觉。先从更安全的步骤开始，只有在必要时才降低精度。.
模型规模缩减中剪枝和蒸馏的区别
剪枝会移除“无用”参数，但通常需要重新训练才能恢复模型质量，尤其是在剪枝过于激进的情况下。蒸馏训练一个较小的学生模型来模仿一个较大的教师模型的行为，从长远来看，它的投资回报率可能高于极端量化。如果您想要一个行为相似且稳定的小型模型，蒸馏通常是更明智的选择。.
如何通过服务改进来降低推理成本和延迟
服务端的优化效果最为显著：批量处理可以提升吞吐量，但如果过度使用则会增加延迟，因此需要谨慎调整。缓存（包括即时缓存和键值缓存重用）在上下文重复时会造成巨大的开销。即使总耗时相近，流式输出也能提升用户感知速度。此外，还要注意堆栈中逐个令牌的开销——即使是每个令牌的小开销也会迅速累积。.
为什么尾延迟在优化人工智能模型时如此重要
平均值可能看起来很棒，但 p99 却很糟糕，而用户往往处于延迟的尾部。尾部延迟通常源于抖动：内存碎片、CPU 预处理峰值、标记化速度减慢或批处理行为不佳。这就是为什么该指南强调百分位数和实际工作负载的原因。如果您只优化 p50，仍然可能导致用户体验“随机感觉缓慢”。
参考
-
亚马逊网络服务 (AWS) - AWS CloudWatch 百分位数（统计定义） - docs.aws.amazon.com
-
Google - 大规模尾部延迟（尾部延迟最佳实践） - sre.google
-
Google - 服务级别目标（SRE 书籍）- 延迟百分位数 - sre.google
-
PyTorch - torch.compile - docs.pytorch.org
-
PyTorch - FullyShardedDataParallel (FSDP) - docs.pytorch.org
-
PyTorch - PyTorch 分析器 - docs.pytorch.org
-
PyTorch - CUDA 语义：内存管理（CUDA 内存分配器说明） - docs.pytorch.org
-
PyTorch - 自动混合精度 (torch.amp / AMP) - docs.pytorch.org
-
PyTorch - torch.utils.checkpoint - docs.pytorch.org
-
PyTorch - 性能调优指南 - docs.pytorch.org
-
PyTorch - 剪枝教程 - docs.pytorch.org
-
PyTorch - 了解 PyTorch 中的 CUDA 内存使用情况 - docs.pytorch.org
-
PyTorch - torch.compile 教程/概述 - docs.pytorch.org
-
ONNX 运行时 - ONNX 运行时文档 - onnxruntime.ai
-
NVIDIA - TensorRT 文档 - docs.nvidia.com
-
NVIDIA - TensorRT 量化类型 - docs.nvidia.com
-
NVIDIA - Nsight Systems - developer.nvidia.com
-
NVIDIA - Triton 推理服务器 - 动态批处理 - docs.nvidia.com
-
DeepSpeed - ZeRO Stage 3 文档 - deepspeed.readthedocs.io
-
bitsandbytes（bitsandbytes-foundation） - bitsandbytes - github.com
-
Hugging Face - 加速：梯度累积指南 - huggingface.co
-
Hugging Face - 分词器文档 - huggingface.co
-
Hugging Face - 变形金刚：PEFT 指南 - huggingface.co
-
拥抱脸 - 变形金刚：KV缓存说明 - huggingface.co
-
Hugging Face - 变形金刚：“快速”分词器（分词器类） - huggingface.co
-
arXiv - 神经网络中的知识提炼（Hinton等人，2015） - arxiv.org
-
arXiv - LoRA：大型语言模型的低秩自适应 - arxiv.org
-
arXiv - FlashAttention：具有 I/O 感知功能的快速且内存高效的精确注意力机制 - arxiv.org