MIT 6.5940 · Fall 2026 schedule + Fall 2024 materials · 中文学习载体
MIT 6.5940 高效 AI 计算课
这份课把 MIT Han Lab 的 6.5940 压缩成一条工程主线：当模型太大、太慢、太耗内存或无法在目标设备上跑时，应该从模型结构、数值表示、稀疏性、编译/运行时、训练和服务系统的哪一层下手。
这门课该怎么读
6.5940 和 CS149、CS336 正好拼成一条链：CS149 告诉你硬件和并行程序为什么快或慢；CS336 告诉你语言模型从数据到训练再到推理的完整栈；6.5940 专门回答“怎样让模型在真实资源约束下跑起来”。
读这门课不要先追论文名。先记住四个工程问题：模型占多少存储、每次推理搬多少数据、目标设备有什么算子和内存限制、压缩后准确率和延迟是否真的更好。
完整教材正文
这一节是主课。22 章按 MIT Han Lab 6.5940 Fall 2026 的公开 schedule 组织，并用 2024 已公开材料补足讲解。它的目标不是堆论文名，而是帮你判断一个模型为什么大、为什么慢、压缩后为什么未必更快，以及 Agent 系统该怎样估算成本。
01. Introduction
第一讲建立课程问题：深度模型越来越大，训练和推理成本不再只是研究成本，而是产品能否上线、能否端侧运行、能否被普通用户承担的问题。高效 AI 计算研究的不是“把模型变小”一个动作，而是在质量、延迟、内存、能耗和成本之间做可验证取舍。
1. 效率指标要拆开
一个模型可以参数少但延迟高，也可以 FLOPs 少但设备上跑得慢。高效计算至少要同时看 model size、MACs/FLOPs、activation memory、peak memory、latency、throughput、energy 和 accuracy。缺任何一个，都可能得出误判。
2. 设备决定优化方向
云端 GPU、笔记本、手机 NPU、MCU 的约束完全不同。GPU serving 可能被 HBM 和 batch 调度限制，MCU 可能先被 SRAM 卡住，手机端可能卡在算子支持和功耗。课程的压缩、量化、NAS、runtime 和端侧训练，都在回答“目标设备到底允许什么”。
3. 和 Agent 的关系
Agent 产品会把单次推理变成多次推理、工具调用、重试、检索和评测循环。一个 token 级成本会被任务链放大。学 6.5940，要把每个技巧都问回系统：它减少了权重读取、activation、KV cache、通信，还是只减少了 checkpoint 文件。
自测：为什么只说“模型小了 50%”不够？
模型文件变小只说明存储下降。真实收益还要看目标硬件上的延迟、内存峰值、吞吐、能耗和任务质量；如果 runtime 不能用上压缩格式，速度可能不变。
02. Basics of Deep Learning
第二讲补齐压缩前的账本。你要能从模型结构读出参数、激活、计算量和瓶颈，否则后面的剪枝、量化、NAS 都没有基准。
1. 参数、激活和计算量
参数是模型持久权重，影响存储、加载和部分计算量。激活是运行时中间 tensor，推理时影响峰值内存，训练时还要保留给反向传播。MACs/FLOPs 描述算术量，但真实延迟还取决于 kernel、layout、batch 和内存访问。
2. baseline 表比技巧更重要
每次压缩前先建 baseline：模型、数据集、精度、设备、batch size、latency、throughput、peak memory、accuracy。之后每个实验都和同一 baseline 比较。否则你无法判断收益来自模型、runtime、硬件状态，还是测量噪声。
3. FLOPs 和 latency 的差距
低 FLOPs 模型可能使用硬件不擅长的算子，或者产生很多小 kernel。高 FLOPs 模型如果矩阵形状规整、batch 足够大，反而能跑得更快。这就是为什么 6.5940 会把模型压缩和系统实现放在同一门课里。
自测：为什么 depthwise convolution 参数少，却不一定快？
它减少乘加，但每次计算复用较少，memory access 和 kernel overhead 占比可能更高。如果硬件或库对 depthwise 优化不足，真实延迟未必下降。
03. Pruning and Sparsity (Part I)
第三讲进入剪枝。剪枝不是简单删除小权重，而是在问：模型中哪些参数、通道、head 或 block 对目标任务贡献小，删掉后能否在真实硬件上得到收益。
1. unstructured 和 structured
unstructured pruning 可以删除任意位置的单个权重，容易得到高稀疏率，但生成的是不规则稀疏矩阵。structured pruning 删除 channel、filter、attention head 或 block，压缩率可能低一些，但结果仍是规整 dense tensor，更容易被通用 kernel 加速。
2. 怎么判断删谁
最简单的指标是 magnitude：绝对值小的权重可能影响小。更复杂的方法会看梯度、Hessian、activation 或验证集损失。所有指标都只是在估计“删掉这个部分的损害”。估计错了，模型质量就会掉。
3. 剪枝后还要恢复
剪枝会扰动模型分布，通常需要 fine-tuning。剪枝比例越高，恢复越重要。生产上还要区分三种收益：checkpoint size 是否变小，内存峰值是否下降，目标设备 latency 是否真的下降。
自测：为什么 90% 稀疏不等于 10 倍加速？
如果硬件和 kernel 仍按 dense 矩阵执行，零值也会被读写和计算。稀疏要变成速度，需要稀疏格式、调度和硬件支持。
04. Pruning and Sparsity (Part II)
第四讲继续剪枝，重点是全局分配和硬件形状。每层平均删 50% 通常不是好策略，因为不同层的冗余和敏感度不同。
1. 层间预算分配
第一层、最后一层、bottleneck 层、attention 投影、MLP 中间层，对剪枝的敏感度不同。好的剪枝方法会把压缩预算分给更能承受损失的部分，而不是机械地每层同样比例。
2. 稀疏模式要匹配硬件
2:4 sparsity 这类半结构化模式限制每 4 个元素里只保留 2 个。它没有任意稀疏那么灵活，但更容易映射到硬件。很多时候，受约束的稀疏模式比理论压缩率更高的不规则稀疏更有用。
3. Lottery Ticket 的启发
Lottery Ticket Hypothesis 讨论稀疏子网络和初始化的关系。对工程学习来说，不必把它当成固定配方。更重要的是：稀疏模型的可训练性、初始化、恢复训练和硬件可执行性是一个整体。
自测：为什么 channel pruning 常适合移动端？
删除 channel 后，后续 tensor 形状变小，常规 dense convolution 或 matrix kernel 可以直接运行。它不要求设备支持复杂稀疏格式。
05. Quantization (Part I)
第五讲进入量化。量化把连续浮点数映射到有限离散值，用更低 bit 表示权重或激活。它减少存储和带宽，但会引入数值误差。
1. scale 和 zero point
常见整数仿射量化用 scale 和 zero point 把浮点值映射到整数，再近似还原。scale 太大，分辨率粗；scale 太小，离群值会被 clip。zero point 处理非对称范围，使 0 更容易被准确表示。
2. 误差从哪里来
量化误差主要来自 clipping 和 rounding。clipping 截断范围外的值，rounding 把连续值压到离散格点。模型里少数离群 activation 可能决定 scale，导致大部分普通值的分辨率下降。
3. weight 和 activation 难度不同
weight 是固定的，可以离线统计分布。activation 随输入变化，范围和离群值更不稳定。LLM 里 activation outlier 尤其麻烦，这也是 SmoothQuant、AWQ 等方法要处理的重要问题。
自测：为什么 INT8 模型不一定自动更快？
需要硬件、kernel 和 runtime 支持 INT8 路径。若推理时频繁 dequant 到高精度、layout 不匹配或算子不支持，低 bit 的理论收益会被抵消。
06. Quantization (Part II)
第六讲讨论量化流程。PTQ 成本低，QAT 质量更稳；per-channel、group-wise、weight-only、activation quantization 各自解决不同误差和系统问题。
1. PTQ 和 QAT
Post-Training Quantization 在训练后用校准数据估计量化参数，再转换模型。它便宜，适合先试。Quantization-Aware Training 在训练中模拟量化，让模型适应误差，通常质量更好，但要付出训练成本。
2. STE 为什么存在
round 是离散操作，直接求梯度会出问题。Straight-Through Estimator 在反向时用近似梯度通过离散步骤，让量化模拟能进入训练循环。它不是精确数学，而是可用的训练技巧。
3. 粒度影响误差和开销
per-tensor 量化只有一个 scale，开销低但误差可能大。per-channel 或 group-wise 量化为不同通道或组设置不同 scale，质量更好，但元数据更多，kernel 也更复杂。LLM weight-only quantization 常用 group-wise，因为权重读取是 decode 主要成本之一。
自测：校准集为什么必须像真实请求？
校准集决定 activation 范围和 scale。若它没覆盖真实输入的长度、领域和离群值，线上 activation 会落到错误范围里，量化误差放大。
07. Neural Architecture Search (Part I)
第七讲讲 NAS。NAS 搜的不是抽象意义上的“最好模型”，而是在约束下寻找结构：目标设备、延迟、内存、能耗、参数量和准确率共同定义什么叫好。
1. search space 是上限
搜索空间决定候选模型能长什么样。你可以搜索层数、宽度、kernel size、expansion ratio、attention head、operator choice 或 skip connection。如果搜索空间没有包含适合目标设备的结构，搜索算法再强也找不到。
2. 目标函数不能只写 accuracy
移动端模型通常要把 latency、MACs、memory、energy 放进目标。云端 LLM 可能更关心吞吐、KV cache、batch 下的延迟。错误目标会稳定地产生错误模型。
3. 人工架构仍然重要
MobileNet、ShuffleNet、SENet、EfficientNet 这类人工设计常常为搜索空间提供积木。NAS 不是替代工程判断，而是把工程判断编码成可搜索的候选集合和约束。
自测：为什么 GPU 上快的模型不一定在手机 NPU 上快？
不同硬件支持的算子、layout、并行度和内存层级不同。GPU 友好的矩阵形状或算子组合，可能在手机 NPU 上走慢路径。
08. Neural Architecture Search (Part II)
第八讲关注 NAS 的成本。逐个完整训练候选模型太贵，所以 NAS 需要 proxy、weight sharing、supernet 和硬件延迟预测。
1. 为什么需要 proxy
如果每个候选模型都从头训练到收敛，搜索成本会爆炸。proxy task 用更小数据、更少 epoch、更低分辨率或部分模型评估候选。zero-cost proxy 试图用初始化或早期信号估计潜力。
2. supernet 和 weight sharing
supernet 把很多候选路径放进一个大网络，共享训练权重。评估某个候选时，只激活对应子路径。这样便宜很多，但也引入偏差：共享权重下表现好的子网，独立训练时未必同样好。
3. 硬件感知搜索
硬件感知 NAS 要测真实设备延迟，或者训练 latency predictor。只用 FLOPs 做代理会错过 kernel launch、memory layout、算子支持和并行效率。最终模型要在目标设备上复测。
自测：为什么 proxy 指标错位会很危险？
搜索会持续优化 proxy。如果 proxy 和真实目标不一致，搜索越充分，结果越可能偏离真实需求，例如低 FLOPs 但高延迟。
09. Knowledge Distillation
第九讲讲蒸馏。小模型不只从 hard labels 学，也可以从大模型的 soft distribution、中间特征和行为轨迹中学习。
1. soft logits 的信息
hard label 只告诉正确答案。teacher 的 soft logits 还表达了类别之间的相似度和不确定性。temperature 会把分布变平，让 student 更容易看到这些“暗知识”。
2. 蒸馏什么
分类模型可以蒸馏 logits。视觉模型可以蒸馏 feature map 或 attention map。LLM 可以蒸馏回答、推理轨迹、工具调用轨迹、偏好排序或 verifier 通过的样本。蒸馏目标越接近真实任务，越可能保留产品能力。
3. student 容量仍然是上限
teacher 能教，不代表 student 都能学会。小模型架构、数据覆盖、tokenizer、训练 recipe 和评测目标都会限制效果。对 Agent 来说，蒸馏 tool use 和错误恢复比蒸馏普通问答更难。
自测：为什么蒸馏适合做小模型？
teacher 把复杂数据分布压成更平滑的训练信号。student 能用更少容量学习 teacher 已经组织好的决策边界或行为模式。
10. MCUNet: TinyML on Microcontrollers
第十讲进入 TinyML。MCU 上的限制和服务器完全不同：SRAM 可能只有几十到几百 KB，Flash 也很小，batch 通常为 1，功耗和实时性也会限制设计。
1. MCU 的第一约束是内存
模型参数可以放在 Flash，但中间 activation 往往要放 SRAM。很多模型不是算不动，而是 activation 峰值超了。端侧部署前要画出每层 activation 生命周期，找峰值而不是只看参数量。
2. MCUNet 的联合设计
MCUNet 把 TinyNAS 和 TinyEngine 放在一起。TinyNAS 搜索适合 MCU 约束的模型，TinyEngine 生成适合该模型和设备的推理代码。模型和运行时互相约束，而不是先训练一个模型再硬塞到设备上。
3. patch-based inference
高分辨率输入会放大 activation。patch-based inference 把输入切块处理，降低峰值内存，但要处理边界、重叠和精度影响。它展示了 TinyML 的常见思路：改变执行方式来满足设备约束。
自测：为什么 activation memory 可能比参数更要命？
参数可压缩并放在较大的非易失存储里，activation 运行时需要快速读写。SRAM 太小时，峰值 activation 会直接决定模型能否运行。
11. TinyEngine and Parallel Processing
第十一讲说明：模型已经很小，仍然需要运行时。Tiny runtime 的工作是让每个 byte 的 SRAM、每个算子和每次内存访问都有安排。
1. memory planning
推理图中不同 activation 的生命周期不同。两个 tensor 如果不会同时使用，就可以复用同一块 buffer。memory planner 通过生命周期分析降低峰值内存，这在 MCU 上常常比减少少量计算更重要。
2. operator fusion 和 code generation
TinyEngine 会根据模型生成专门代码，减少通用 runtime 开销。融合 convolution、batch norm、activation 或 pooling，可以少写中间结果。代码生成还能针对固定 shape 消除动态分支。
3. 并行不是只有服务器需要
MCU 或 ARM CPU 也可能有 SIMD 指令和专用库，例如 CMSIS-NN。低端设备上每次内存访问和每条指令都更敏感。并行和向量化仍然重要，只是尺度更小。
自测：为什么 buffer reuse 需要知道 tensor 生命周期？
只有生命周期不重叠的 tensor 才能安全复用同一块内存。否则后一个 tensor 会覆盖前一个仍要使用的数据。
12. Transformer and LLM
第十二讲把效率问题带到 LLM。Transformer 的主要结构包括 attention、MLP、normalization 和 embedding；推理时要分 prefill 和 decode 看瓶颈。
1. prefill 和 decode
prefill 处理 prompt 中所有已知 token，可以并行计算隐藏状态并建立 KV cache。decode 每次生成一个 token，新 token 生成后才进入下一步。prefill 更像大矩阵计算，decode 更容易被权重读取和 KV cache 读取限制。
2. KV cache 是长上下文的账本
每层、每个 attention head 都要保存历史 Key/Value。上下文越长，KV cache 越大。GQA、MQA、MLA、KV compression、paged attention 等方法都在降低或管理这个成本。
3. LLM 优化要按层拆
MLP 层通常占大量参数和计算，attention 受上下文长度影响，norm 和 elementwise 操作容易被 memory bandwidth 限制。一个“LLM 慢”的问题，要拆成层、阶段和资源。
自测：为什么长输出和长输入的瓶颈不同？
长输入主要增加 prefill 时间和 KV cache 建立成本；长输出增加 decode 步数，每一步都要读权重和历史 KV，因此总延迟和吞吐压力更大。
13. LLM Quantization and Deployment
第十三讲关注 LLM 量化与部署。LLM 的 decode 阶段常常受权重和 KV 读取限制，所以 weight-only quantization、activation smoothing 和高效 kernel 都很重要。
1. weight-only quantization
weight-only 量化主要压缩权重，激活仍可用较高精度。它适合 decode 阶段，因为每生成一个 token 都要读大量权重。权重更小，就能降低带宽压力和显存占用。
2. SmoothQuant 和 AWQ 的方向
SmoothQuant 处理 activation outlier，把量化难度在 weight 和 activation 之间重新分配。AWQ 关注哪些权重对激活更重要，保护或重标定少量关键权重。两者都说明：LLM 量化不能只看权重静态分布，还要看真实 activation。
3. deployment 的最后一公里
4-bit 模型要变快，需要 packing、dequant、matmul kernel、cache layout 和 batch 调度配合。如果每次推理都要把 4-bit 解包成 16-bit 再走普通 kernel，收益会大打折扣。TinyChat、QServe、vLLM 这类系统的价值在运行时。
自测：为什么 4-bit 不一定比 8-bit 快一倍？
低 bit 减少权重读取，但 dequant、packing、kernel 支持、内存布局和 batch shape 都会影响真实时间。瓶颈也可能在 KV cache 或调度。
14. LLM Post Training
第十四讲把 post-training 放进效率课里。压缩后的模型不只是要保持困惑度或选择题准确率，还要保持指令跟随、格式稳定、工具使用和推理行为。
1. post-training 改变模型行为
pretraining 学下一个 token。SFT 用示范让模型学会回答方式。Preference tuning 或 RL 进一步把模型推向人类或 verifier 更偏好的输出。压缩会扰动这些行为，所以压缩后要重新评测，必要时再做微调或蒸馏。
2. 小模型的能力来自数据配方
一个小模型若要承担特定任务，通常需要高质量 instruction data、任务轨迹、teacher 生成数据和严格评测。它不能只靠通用预训练规模。对 Agent 来说，tool call schema、错误恢复和多步任务样本尤其重要。
3. 量化后要测格式
开放问答分数变化小，不代表 tool calling 没问题。函数名、JSON key、参数类型和边界条件可能对少量 token 很敏感。压缩 Agent 模型时，必须加入产品相关评测。
自测：为什么量化后要重测 tool calling？
tool calling 对格式和离散 token 选择很敏感。量化误差可能不明显影响普通问答，却破坏函数选择、参数结构或 JSON 可解析性。
15. Long Context LLM
第十五讲讲长上下文。长上下文首先是系统问题：prefill 更重，KV cache 更大，attention 更贵，评测也更容易产生幻觉般的信心。
1. context length 的成本
上下文越长，prefill 要处理的 token 越多，KV cache 要保存的历史越多。full attention 的成本随长度增长很快，decode 每步也要访问更长历史。长上下文窗口不是免费存储。
2. 降低成本的几类方法
RoPE scaling 试图扩展位置泛化。local/sparse attention 减少每个 token 看的范围。KV compression 压缩历史表示。retrieval 和 memory system 则把一部分信息放到模型外部，按需取回。
3. 长上下文评测要看位置和干扰
“能放 1M token”不等于“能有效使用 1M token”。信息位置、干扰文档、答案格式、跨段推理都会影响结果。Agent trace 更复杂，因为历史里有错误尝试、工具输出和过期状态。
自测：为什么 Agent 不该默认保留全部历史？
全部历史会增加 prefill、KV cache 和注意力干扰。更好的做法是保留任务状态、关键证据和可复查日志，把低价值 trace 压缩或移出上下文。
16. Vision Transformer
第十六讲把 Transformer 放到视觉。ViT 把图像切成 patch token，和文本一样进入序列模型，因此分辨率、patch size 和 token 数会直接进入计算和内存成本。
1. patch token 的账本
图像大小为 H×W，patch 为 P×P 时，token 数大致是 H/P × W/P。分辨率翻倍，token 数约变成 4 倍，attention 和 activation 成本都会变重。
2. efficient ViT 的方向
常见方法包括 window attention、token pruning、低分辨率早期处理、CNN-Transformer hybrid、蒸馏和量化。目标是减少不必要 token 和昂贵全局 attention，同时保留任务需要的空间信息。
3. 多模态 Agent 的含义
Agent 读 UI、截图、PDF 或白板时，视觉 token 成本会进入推理预算。截图分辨率、裁剪区域、OCR、region proposal 和多轮查看策略，都是系统参数。
自测：为什么高分辨率截图直接送模型会很贵？
高分辨率会产生更多 patch 或视觉特征，放大 attention、activation 和显存成本。很多任务只需要局部区域或先用 OCR/裁剪处理。
17. GAN, Video, and Point Cloud
第十七讲覆盖几类非文本模型。它们表面不同，但效率问题都从数据形状开始：图像有空间维度，视频多了时间，点云稀疏且不规则。
1. GAN 的推理和训练
GAN 包含生成器和判别器。部署时通常关心生成器延迟，训练时两者都参与。压缩生成器要同时看速度和生成质量，不能只看分类准确率。
2. video 的时间维度
视频模型的成本来自帧数、分辨率、clip 长度和跨帧建模。少采样会丢动作细节，多采样会让计算和内存膨胀。temporal attention 或 3D convolution 都要处理时间维度带来的成本。
3. point cloud 的不规则性
点云数据稀疏、不规则，邻域构建、采样、聚合和内存访问很重要。很多 dense 图像技巧不能直接套用。效率优化要先理解数据结构，而不是直接拿剪枝量化套模板。
自测：为什么视频模型比单图模型更容易成本失控？
视频同时有空间和时间维度。帧数、分辨率、clip 长度和跨帧建模都会增加计算、activation 和存储。
18. Diffusion Model
第十八讲讲 diffusion。它慢的主要原因不是单次网络一定巨大，而是生成通常需要多步 denoising，每一步都要跑主干网络。
1. 多步采样的成本
diffusion 从噪声逐步去噪生成样本。步数越多，质量通常更稳，但延迟越高。每一步可能包含 U-Net、DiT、cross attention 和文本条件。采样步数直接乘在推理成本上。
2. 压缩方向
减少 step、蒸馏采样轨迹、量化主干、剪枝、缓存部分特征、优化 scheduler，都是常见方向。不同方法会影响细节质量、文本对齐、稳定性和多样性。
3. 产品系统视角
生成式视觉产品还要看队列、分辨率、batching、并发和后处理。把 step 直接砍半也许快了，但失败样本可能显著增加。效率优化必须和质量评测绑定。
自测：为什么减少 diffusion step 可能伤质量？
每一步承担去噪路径的一部分。步数减少会改变采样轨迹，可能造成细节缺失、结构不稳定或文本对齐下降，需要蒸馏或新 scheduler 配合。
19. Distributed Training (Part I)
第十九讲进入训练效率。单卡 kernel 快，不代表大训练快；多卡训练要同时处理计算、显存、通信、checkpoint 和故障。
1. data parallel 的基本模式
Data parallel 把 batch 切给多个 worker，每个 worker 持有模型副本，计算本地梯度，再用 all-reduce 同步。它简单有效，但模型和 optimizer state 必须能放进单卡或单节点内存。
2. 内存里有什么
训练时显存不只放参数。还要放梯度、optimizer state、activation、通信 buffer 和临时 workspace。Adam 这类 optimizer 的状态可能是参数的数倍。activation checkpointing 用重算换显存。
3. 扩展效率受通信影响
GPU 数增加后，每张卡计算变少，通信占比可能变高。batch 太小会让同步成本压过计算收益；batch 太大又可能影响收敛。训练系统的扩展是算法和系统共同问题。
自测：为什么 batch 太小会让多卡训练效率差？
每张卡做的计算太少，all-reduce 和同步开销占比升高，硬件等通信。计算没有足够工作量覆盖固定成本。
20. Distributed Training (Part II)
第二十讲继续分布式训练，重点是模型放不下或通信太贵时的切分策略。data、tensor、pipeline、parameter sharding 和 gradient compression 解决的是不同瓶颈。
1. 多种并行切不同维度
tensor parallel 切层内矩阵，需要频繁 collective，适合高速互联。pipeline parallel 按层切模型，用 micro-batch 减少流水线空泡。ZeRO/FSDP 分片参数、梯度和 optimizer state，降低单卡内存。
2. 通信优化
gradient compression 用低 bit、稀疏更新或误差反馈减少通信量。通信计算重叠让 GPU 在等待网络时继续做其他工作。拓扑也重要：节点内 NVLink 和节点间网络不是同一个成本。
3. checkpoint 和故障
大训练持续时间长，故障是常态。checkpoint 频率太低，失败回滚损失大；频率太高，存储和暂停成本高。训练系统要把恢复成本写进吞吐账本。
自测：为什么 pipeline parallel 需要 micro-batch？
只有一个大 batch 时，各阶段会轮流空等。micro-batch 让不同阶段同时处理不同小批次，减少 pipeline bubble。
21. On-Device Training and Transfer Learning
第二十一讲讲端侧训练。端侧训练比端侧推理更难，因为反向传播需要保存 activation、计算梯度、更新参数，还要处理能耗、散热、隐私和数据少的问题。
1. 为什么通常只更新少量参数
完整 fine-tuning 需要为大量参数保存梯度和 optimizer state，端侧设备往往承受不了。常见做法是只训练 bias、adapter、LoRA、小头部或少数层。这样质量上限可能低一些，但内存和能耗可控。
2. transfer learning 的边界
端侧数据通常少、偏、噪声高。模型容易过拟合，也不容易得到可靠验证集。训练流程需要正则化、早停、回滚和隐私保护。很多场景更适合个性化小模块，而不是改完整模型。
3. Agent 的本地适配
个人 Agent 可能要在本地适配用户偏好、文件格式、常用工具和隐私数据。端侧训练的价值在隐私和个性化，但必须有清楚的评测：适配后是否真的更好，是否破坏通用能力。
自测：为什么 adapter 适合端侧训练？
adapter 参数少，训练时需要保存和更新的状态少。它能把改动限制在小模块内，便于回滚和个性化管理。
22. Advanced LLM and Agents
第二十二讲是 2026 schedule 里的高级主题。详细讲义在当前公开页面中还没有稳定链接，所以这里不虚构具体 slide 内容，而是把它放回 6.5940 的主线：Agent 是高效 AI 计算的压力测试。
1. Agent 成本来自整个轨迹
普通 chat 的成本大致是一次 prompt 和一次 response。Agent 任务包含计划、工具调用、观察、重试、检索、代码执行和评测。每一步都可能产生 prompt tokens、generated tokens、KV cache、工具等待和日志。
2. 优化手段不只在模型内部
可以用量化模型降低单次推理成本，也可以用模型路由把简单步骤交给小模型，用上下文压缩控制 KV cache，用缓存复用相同前缀，用工具 schema 减少无效输出，用评测器减少盲目重试。
3. 怎么把 6.5940 用到 Agent 产品
为一个 Agent 产品做效率设计时，至少列出：模型选择、量化格式、上下文策略、并发和 batching、缓存、工具调用延迟、失败重试、离线评测和线上观测。效率不是最后上线时的调参，而是产品协议的一部分。
自测：为什么全程用最大模型通常不是好设计？
不同步骤对能力、格式、延迟和成本的要求不同。规划、检索改写、工具调用、验证和总结可以采用不同模型或策略，整体更可控。
总地图：高效 AI 计算的优化路径
这张图从模型出发，但终点不是模型文件。真正的目标是给定设备、延迟、成本和质量约束下的可运行系统。压缩技巧如果没有和 kernel、runtime、memory layout、serving 策略连上，常常只能得到论文里的指标。
课程模块
速查与进度卡片
这里用于快速回忆和勾选进度。每张卡片只保留问题、知识链路、工程判断和轻练习；需要系统阅读时，以上方“完整教材正文”为准。2026 新增或调整的 Advanced LLM and Agents 会按课程位置说明它应解决的系统问题，不编造未发布讲义细节。
Labs 和 final project 地图
6.5940 的实验比单纯读 lecture 更重要。自学时不一定要完整提交，但至少要跑通小模型版本，记录压缩率、延迟、显存/内存和准确率的变化。
和 Agent 开发的关系
Agent 会放大推理成本
工具调用、长上下文、重试、多样本和反思都会增加 token 和中间状态。6.5940 让你从量化、KV、serving、batching 和端侧部署角度估算这些成本。
压缩必须看任务边界
一个压缩模型在 benchmark 上没掉分，不等于在 Agent 里可用。工具调用格式、长链路推理、代码生成和多模态输入都可能对量化、剪枝和蒸馏更敏感。
术语速查
公开资料来源
页面内容以公开资料为依据，正文为中文重写和工程化组织；不复制 slides、Colab 或 notes 的长段原文。