# 模型服务与算力 学习模型服务框架、并行计算与底层优化，适合维护训练和推理基础设施的人员。 - 所属：[部署与推理优化]() - 网站：[https://oplearnx.com/topics/model-serving-compute]() ## 推荐学习顺序 1. [GTC 柏林 2026：NVIDIA CEO 黄仁勋主题演讲实时更新]()（博客 · 入门）：这是 NVIDIA 官方博客对 GTC 柏林 2026 主题演讲的实时报道。文章介绍大会在柏林举行、为期三天、包含 100 多场关于智能体 AI、机器人、物理 AI、开放模型与加速计算的会议，并记录黄仁勋开场提到多家欧洲企业与 NVIDIA 的 AI 合作、公司对欧洲技术生态近 100 亿美元的投入，以及“AI 五层蛋糕”的表述。 2. [在 AWS 上进行基础模型训练与推理的构建模块]()（博客 · 入门）：Hugging Face 上由亚马逊作者 Keita Watanabe、Pavel Belevich、Aman Shanbhag 撰写、2026 年 5 月 11 日发布的企业类文章，讨论在 AWS 上训练和推理基础模型的构建模块。文章从 Kaplan 等人 2020 年关于缩放定律的研究出发，引用英伟达“从一个到三个缩放定律”的框架，说明除预训练外，后训练（如监督微调和强化学习方法）与测试时计算也在推动性能提升，并据此讨论基础模型生命周期。 3. [为什么 AI 算力是按矩形购买的 —— Erik Bernhardsson，Modal CEO]()（博客 · 进阶）：Latent Space 的访谈节目，主持人与 Modal CEO Erik Bernhardsson 讨论公司在 5 亿美元 C 轮后完成 7.5 亿美元 D 轮、估值 160 亿美元、年化收入突破 10 亿美元并创建近 30 亿个沙箱的情况。核心话题是算力经济学：传统容量合同把 GPU 按固定数量、固定时长购买，在时间—容量图上呈矩形，而真实工作负载会增长、突增、回落；Erik 讲述 Modal 如何通过聚合数千客户的需求来做“时长变换”。含 YouTube 完整对话链接，涉及服务器无服务器化 AI 基础设施的开发者与商业读者可关注。 4. [可编程数据中心——Evan Conrad，SF Compute]()（博客 · 进阶）：这是 Latent Space 在 AIE NYC 新设的 Compute Trading 分论坛期间录制的对谈，嘉宾为 SF Compute 的 Evan Conrad。文章以软件定义网络对思科、VMware 的影响作类比，讨论 GPU 计算的同类变化：SF Compute 让用户买卖当下和未来的 GPU 小时，并从网络到内存进行程序化控制。对谈还涉及物理交付 GPU 合约需要什么条件、计算市场要变得流动需要满足哪些前提，以及公司从转租集群扩展到承担云运营商职能的过程。 5. [同样的 GPU，产出多出 50%：为什么运营方是关键——SemiAnalysis 的 Oliver Kennon]()（博客 · 进阶）：演讲把算力视为大宗商品市场，指出购买 GPU 只是获得潜力，实际可用产出取决于运营方：在同样的 B200 芯片上，仅服务栈一项就能带来约 50% 的产出差异。内容还包括集群安全如何影响“智能”是否有用、SemiAnalysis 的 ClusterMAX 如何给运营方评级、租用价格与生产成本的区别、成本位置取决于竞争对手，以及构建可比算力评级与算力期货所需的条件。 6. [为一万到一万二千美元预算的本地 agentic coding 装机：1× 5090 对比 4× 3090、混合方案、PRO 6000、Mac Studio？]()（帖子 · 进阶）：r/LocalLLaMA 社区帖子。发帖者准备花约 1 万美元（必要时到 1.2 万）买硬件做本地 agentic coding，用途包括 agentic coding、偶尔 2–4 个并行 subagent 和逆向工程，可选需求是用 Hunyuan3D-2.1 做贴图生成（需 CUDA 和约 21GB 显存）。其列出正在考虑的方案：单张 RTX 5090、四张二手 3090、5090 \+ 2×3090 混合、Mac Studio M5 Ultra 256GB、超预算的 PRO 6000，并就长上下文中单 5090 与四 3090 的日常体验、3090 长上下文预填充表现、混合方案在 AM5 上以 x8/x8/x4 跑两个 vLLM 实例是否值得、以及是否该等 50 Super 或改装 4090 48GB 等问题征询意见。适合正在规划本地多卡推理/编码 agent 装机的人阅读。 7. [你的模型能在 AWS Trainium 上运行吗？查一查就知道]()（博客 · 进阶）：文章介绍一个 torch-neuronx 模型支持情况 Space，用于查询 Hub 上热门模型能否在 AWS Trainium 上运行。该 Space 的 Selected 视图展示按下载量和趋势分挑选的模型，每行给出结果、模型分片占用的 Trainium 核心数、运行实际耗时（含编译）和峰值设备内存；Trending 和 Downloads 视图按 Hub 自身排名逐任务列出结果，并对故意未测试的模型说明原因，还可选择 neuronx-cc 和 Transformers 的版本。这是继此前介绍 TorchNeuron 的文章之后的更新。 8. [TorchNeuron：在 AWS Trainium 上运行 HF 模型前所未有地简单]()（博客 · 进阶）：这是 Hugging Face 博客的一篇文章，介绍为 AWS Trainium 提供 PyTorch 原生后端的 TorchNeuron 插件，支持 eager 模式、torch.compile 以及 FSDP、TP 等原生分布式 API。文章说明 Transformers、Diffusers 和 Kernels 已原生支持该后端，此前 HF 在 Trainium 上依赖基于 PyTorch XLA 的 optimum-neuron；TorchNeuron 自 2026 年 10 月 20 日起进入公开测试，可通过 pip 安装。 9. [Hugging Face ❤️ TorchTPU：原生支持 TPU]()（博客 · 进阶）：博客文章，介绍 TorchTPU 这一原生 PyTorch 后端，使 TPU 成为 PyTorch 中的普通设备；文中称 Transformers、Diffusers 和 Kernels 可在 TPU 上原生运行，从 Hub 选择模型后发送到 "tpu" 即可。文章还简介了 TPU 作为 Google 自研 AI 加速器的情况与可用规模，并对比了此前需经 torch\_xla 的旧方式及其限制。面向希望在 TPU 上运行 PyTorch 模型的用户。 10. [PyTorch 2.15 中的 MPS]()（博客 · 进阶）：Hugging Face PyTorch 团队撰写的博客文章，介绍 PyTorch 2.15 中 Apple MPS 后端的更新，包括 MPS 支持 FP8、语言模型解码在线性层与 softmax 上获得更快路径、以及针对音频、视频和训练工作负载中新 Metal 内核。文中说明该团队以 Hugging Face Hub 上的真实模型排查 MPS 不足并向上游修复，并提到 MoE 模型解码速度较 2.14 提升 5–6.5 倍。适合在 Mac 上运行或训练 PyTorch 模型的读者。 11. [StartLuxLabs/StartLux-Decision]()（项目 · 进阶）：这是一个开源决策模型系列的项目仓库，模型规模从 0.8B 到 27B，一次推理即为每个选项给出校准概率，仅在不确定时输出简短思考。项目提供面向 vLLM、llama.cpp 和 MLX 的推理引擎，并提供 Hugging Face 模型页、arXiv 技术报告、API 文档与博客链接。 12. [cobanov/PS5LM]()（项目 · 进阶）：该项目把 llama.cpp 移植到已越狱的 PlayStation 5 上，允许主机原生运行 GGUF 格式模型，从 Qwen 3.8 开始。README 说明它借助主机 GPU 推理，提供 OpenAI 与 Anthropic 兼容 API 和适配电视的界面，可在无 PC、无云端、无账号的情况下为局域网内设备提供模型服务，另新增了 Ollaya 的决策模型支持。适合拥有越狱 PS5、想在家搭私有模型服务的读者。 13. [在 4 块 R9700 上对比 Qwen 3.8 27B 与 Nanbeige 4.3 33B：我的工作负载下的实际 TPS 与每小时任务数]()（帖子 · 进阶）：这是 r/LocalLLaMA 的一篇社区帖子，作者此前发布过用 127 美元二手 EPYC 搭建 4 卡 R9700 机器的方案，本次在同一套硬件上对比 Qwen 3.8 27B 与 Nanbeige 4.3 33B。他以自己公司维护枪械相关商家信息（营业时间、价格、设施等）的实际工作为负载，让两套配置各跑同样的 2,484 个案例，以审计员身份输出接受、拒绝或弃权，并统计吞吐、每日经核实的正确任务数、准确率，以及 1/4/8 路并发下的 token 速度。帖子还提到 Qwen 在思考模式下审计自身结果的表现优于 Nanbeige，并在结尾向做编程或创意写作测试的人征询情况。适合关注本地多卡推理部署、按实际业务任务而非纯跑分评估模型的人阅读。 14. [MacBook Pro M5 Max 上运行 Nanbeige4.3-33B Q4：mlx-lm、llama.cpp 与 Kapitsa 的对比，512 到 32K 上下文范围]()（帖子 · 深入）：这是一篇社区基准测试帖，在 MacBook Pro M5 Max（128GB）上对 Nanbeige4.3-33B 4-bit 量化模型比较 mlx-lm、llama.cpp 与 Kapitsa 三个引擎的 prefill、decode、首 token 时间、后续延迟和显存占用，覆盖 512 至 32K 提示长度；作者自述是 Kapitsa 引擎的开发者，并公开了原始输出与脚本。帖中称该模型速度慢、KV 缓存占用高（128K 上下文约 26GB），编码能力尚可。适合在 Apple 芯片上做本地推理性能对比的人阅读。 15. [RTX 3080 20GB 解锁 reBAR 与 P2P：提示处理速度提升 70%]()（帖子 · 深入）：帖子称 RTX 3080 20GB 的 P2P 已解锁，在张量并行模式下提示处理速度大幅提升；发帖人转述原作者 u/nathannguyennng 的工作，并给出自己的测试环境（Proxmox 上双 RTX 3080 20GB、vllm 0.32.0、INT4 量化模型、张量并行等）以及原装、gpu-unlock、gpu-unlock\+ReBAR\+P2P 三种配置的对比。适合在本地多卡上运行大模型、关注vLLM 推理性能调优的人阅读。 16. [试过在 3090 等显卡上做 GPU 解锁的人：对混合精度量化（部分权重 ≤Q8、部分张量保留 BF16）有区别吗？]()（帖子 · 深入）：这是一篇社区提问帖，询问在 3090 一类显卡上解锁 FP16/BF16 矩阵乘性能后，对混合精度量化模型是否有效。评论者回复称基本没有差别：解锁只放开带 FP32 累加的 FP16/BF16 与 TF32 矩阵乘；llama.cpp 对 Q4–Q8 等量化权重走 MMQ INT8→INT32 路径，本来就没有锁定，实测 Q6\_K 模型 prefill 与 decode 速度无变化，收益只出现在用 llama.cpp 跑未量化 BF16 GGUF 时。适合在消费级显卡上运行量化模型并关心推理性能调优的人阅读。 17. [搭建 GPU kernel 开发环境的实践笔记：CUDA 13 的显卡截止、异步计时陷阱、profiler 计数器权限 \[P\]]()（帖子 · 进阶）：一篇 r/MachineLearning 社区帖子，作者在准备自己的 GPU kernel 工程系列第一节环境配置时，整理了若干耗时且不易集中查到的要点。内容包括用 compute\_cap 判断显卡架构、CUDA 13 已不再支持 Maxwell/Pascal/Volta、GTX 16 系无张量核心、FP8 需 Ada 或 Hopper；还说明驱动、工具链与 PyTorch 自带 CUDA 运行时是三件不同的事，以及 WSL 2 中的安装方式，并提到 GPU 启动异步导致朴素计时测到的是排队时间。适合刚开始做 CUDA kernel 开发、正在配置环境的人阅读。 18. [剖析 TorchNeuron（第一部分）：在 AWS Trainium 上进行系统级性能剖析]()（教程 · 进阶）：这是关于 AWS Trainium 的系列文章第一篇，介绍如何系统地分析推理性能并找出时间开销所在。文章使用 Trainium 专用的开源 PyTorch 后端 TorchNeuron，讲解如何配置 torch.profiler 并抓取干净的 trace、阅读 key\_averages\(\) 表格以识别消耗 Neuron 设备时间的算子、以及通过 Neuron Explorer 追踪单个算子从框架调度到 NeuronCore 硬件执行的过程。文中说明从零讲起，假定读者没有性能剖析经验。 19. [OpenAI 与 Broadcom 发布面向 LLM 优化的推理芯片]()（博客 · 进阶）：这是 OpenAI 与 Broadcom（NASDAQ: AVGO）的发布公告，介绍 OpenAI 首款“智能处理器”Jalapeño，一款围绕 LLM 推理架构设计的定制加速器。文中称早期测试显示其每瓦性能显著优于当前最先进水平，从设计到量产历时九个月，并将与数据中心伙伴按吉瓦级规模多代部署。 20. [英伟达机密计算扩展，使前沿模型构建者可在全球基础设施上安全扩展]()（博客 · 进阶）：这是 NVIDIA 博客文章，介绍 NVIDIA 机密计算的扩展。文中提到 NVIDIA OpenShell 参考架构，以及新增的 Confidential Bare Metal 部署选项，使前沿模型构建者可在第三方专用基础设施上运行敏感工作负载，同时保留对模型和数据的控制。文章还介绍新的平台安全控制，用于保护传输中的数据、度量平台完整性并实施硬件级访问限制；指出机密计算现提供裸金属、Kubernetes 容器和虚拟机三种部署选项。适合关注模型训练与部署基础设施安全的企业与开发者读者。 21. [在 NVIDIA DGX Spark 上提升 MoE 推理性能的 3 种方法]()（博客 · 深入）：这是 NVIDIA 技术博客的一篇文章，以 1240 亿参数、每 token 激活 51 亿参数的 Ling-3.0-flash 混合专家模型为例，在 NVIDIA DGX Spark、batch size 为 1 的条件下评测三项优化：Humming MXFP4 MoE 后端、在线 FP8 LM head 量化、以及结合 NEXTN 的 MTP 投机解码。文中给出配置对比数据：基线每输出 token 耗时 27.71 ms、解码吞吐 36.09 tok/s，逐项叠加后分别提升 9.3%、21.7%，三项全开时为 9.72 ms、102.88 tok/s、相对基线提升 185.1%。文中还提到性能剖析显示解码受内存带宽限制，MoE 计算与输出层投影占主要执行时间。 22. [如何用 NVIDIA GPUDirect Storage 在 Python 中把数据读入 GPU 显存]()（教程 · 深入）：NVIDIA 技术博客，作者 Andrew Hoyle，2026 年 10 月 22 日发布。文章介绍 KvikIO 库如何以 Python 和 C\+\+ 高层接口封装 cuFile C API，实现加速的文件 I/O 直读 GPU 显存；说明了 KvikIO 与 cuFile 各自的路径选择、KVIKIO\_COMPAT\_MODE、KVIKIO\_GDS\_THRESHOLD、cufile.json 中的 parallel\_io 与 min\_io\_threshold\_size\_kb 等设置，以及用 CUFILE\_STATS\_LEVEL=3 与 gds\_stats 判断走加速路径还是兼容路径，并提到 KvikIO 在 cuDF、cuCIM、cuPhoton 和 GPU 加速 Presto 中的应用。 23. [GLM-5.3 Workers AI 模型中的跨请求 KV 缓存泄露（155 条响应）]()（博客 · 深入）：这是 Cloudflare 博客与推理引擎 SGLang 协同披露的一篇安全事件报告。文章称 2026 年 8 月 27 日至 9 月 9 日期间，使用 GLM-5.3 Workers AI 模型的少数客户收到了包含其他客户此前请求数据的响应，共涉及 155 条响应，且均为超过 681,280 token 的长提示。文章说明问题已修复并于 9 月 9 日恢复该模型，未发现故意利用的证据，同时介绍了缺陷原因、响应时间线及对生产环境 SGLang 部署的加固措施。 24. [将 TorchTPU 集成进 TorchTitan 并为 TPU 优化模型]()（博客 · 深入）：Google 开发者博客 2026 年 10 月 20 日的文章，作者包括 Aleksey Vlasenko、Rob Torres 以及来自 Meta 的 Will Constable。内容讲 TorchTPU 在 PyTorch 中集成原生 torch.device\("tpu"\) 后端，使开发者无需改用 JAX 即可在 Google Cloud TPU 上训练大规模模型；TorchTitan 的 TPU 分支提供 SimpleFSDP、Graph Trainer 和自定义 Pallas 内核等生产级扩展原语，在稠密与 MoE 架构上取得较高模型算力利用率，并提供优化手册、配方和 Hugging Face 建模后端。适合在 TPU 上进行大模型训练的工程与研究人员阅读。 25. [我构建了一个能在廉价（尚可）硬件上以近 400 token/s 运行 Qwen-Flash-Next 的引擎：老 R740 中的 3 块 V100 32GB；最初从 strata 分叉，但引擎核心全部针对老 Volta 架构构建]()（项目 · 深入）：这是一个 GitHub 项目（sFNX）的介绍，作者称在约 1,800 美元的二手 GPU 上（3 块约 600 美元的 Tesla V100-32GB，PCIe Gen3、无 NVLink）以 382 token/s 运行 Qwen3.8-Flash-Next 的代码编辑任务，同时服务 6 个各持完整 262,144 token 上下文的会话，并提供 OpenAI 聊天与响应、Anthropic 消息、工具与图像前端。README 说明其把每一层都切分到三块卡上以避免按层切分时的轮流等待，自行实现跨卡求和，并给出专家层、Gated DeltaNet 循环层和注意力 K/V 的切分方式。 26. [mw00/project-maya]()（项目 · 深入）：Project Maya 是用于在自有 GPU 上私有运行 GLM-5.3-Flash（321B MoE）和 DeepSeek-V4.1-Flash-1017（748B MoE）的项目，支持单卡至 16 卡、NVIDIA 与 AMD、Linux 与 Windows（实验性）。包含推理引擎、服务器、仪表盘、OpenAI 与 Anthropic 兼容 API 以及量化工具，可处理并发请求并支持图片。 27. [DeepInfer：DeepSeek 模型的高性能推理框架]()（项目 · 深入）：DeepSeek 在 GitHub 上开源的推理框架仓库，称其为支撑 DeepSeek 大规模生产服务的高性能框架，此次开源版本提供面向规模化服务的离线推理能力。README 列出支持的模型为 DeepSeek-V4.1-Flash，并列出了优化内核、注意力 DP/CP 与 MoE EP\+EPLB 并行、异步调度、批不变量推理、确定性采样、结构化输出等功能及配置细节。材料中还包含一条 Reddit 用户评论。 28. [incoai/Qwen3.8-Flash-Next-DFlash2]()（项目 · 深入）：Hugging Face 仓库页面，内容为 Qwen/Qwen3.8-Flash-Next 的 DFlash 2 草稿模型，本身不是独立语言模型，需在推测解码服务器中为目标模型起草 token。DFlash 2 是块扩散式 drafter，一次预测一整块 token 并在每个位置保留最优候选，再由轻量选择器串成连贯路径；解码是无损的，贪心输出与目标模型完全一致。页面给出使用 SGLang 部署的快速开始步骤，需先应用仓库内附带的捕获补丁。附带说明中称并发为 1 时其速度约比 MTP 快 20%。 29. [为服务逾 10 亿 ChatGPT 用户而快速扩展在线存储（第二部分）]()（博客 · 深入）：OpenAI 工程博客系列第二部分，作者为 Jon Lee、Hrachya Hakobyan 和 Chaomin Yu，讲述其应用存储平台 Habitat 如何针对 Azure Cosmos DB 做优化以应对用户规模的快速增长，并实现 ChatGPT 读取速度提升 12 倍。内容包括可靠的多租户机制与全局缓存等主题。工程与基础设施方向的读者可参考。 30. [我为一个面向大规模 GPU 工作负载的 PyTorch 优化器做了实现——希望获得反馈 \[P\]]()（帖子 · 深入）：这是 r/MachineLearning 的一篇社区帖子（\[P\] 表示项目分享），作者介绍自己开发的 PyTorch 优化器 ApexW，目标是降低优化器状态显存占用并加快较大 GPU 工作负载上的优化器更新步骤，做法是紧凑的优化器状态加一条基于 Triton 的执行路径。作者称在只有几个大张量时的优化器单项基准中，Triton 加紧凑状态路径比 PyTorch 的 fused AdamW 快约 1.5 倍，优化器状态显存约减半；同时说明自动执行模式尚未稳定取得同样加速，含大量小张量的负载明显慢于 PyTorch fused 优化器（例如 1.28 亿参数分散在众多小张量时，PyTorch 原生为 16.1 ms/步），并强调这些数字来自优化器单项测试而非完整模型训练，希望有人在实现与基准测试上把关。适合从事 PyTorch 训练优化、关注优化器状态显存与 Triton 内核实现的人阅读。 31. [Deepity：一个手工调优的 C\+\+/CUDA 预测编码库，在 MNIST 上超过 jpc（JAX）和 ngc-learn（含 CPU 基准与源码）\[P\]]()（项目 · 深入）：这是一篇 \[P\] 类社区发布帖，作者用 C\+\+20 从零实现预测编码（PC）引擎并配薄 Python 层，发布首个公开版本。帖中介绍了预测编码与反向传播的区别（各层本地信念对自上而下预测做误差最小化、需“settling”阶段、不保存反向计算图），以及库的组成：手写 AVX2/AVX-512 SIMD 内核、OpenBLAS/MKL 做 GEMM、仍在调优的 CUDA 后端（暂不可用）、基于 nanobind 的 Python 绑定（pip install pydeepity），并支持多种 PCN 变体；帖子称在 MNIST 上优于 jpc（JAX）与 ngc-learn，并附带 CPU 基准和源码。适合研究预测编码、非反向传播训练方法与底层内核优化的人阅读。 32. [面向 LLM 的 CUDA]()（书籍 · 深入）：这是 Manning Publications 出版的书，作者 Elliot Arledge，出版日期 2026-10-15，408 页，ISBN 9781633434899，主题词为数据科学与深度学习。简介称其讲解在 CUDA 生态中从编写第一个 kernel 到实现 Flash Attention 等高级 LLM 特性，包括用 Nsight Compute 做性能剖析与瓶颈定位，并针对最新 NVIDIA 硬件讲解 CUDA 基础。适合想从 GPU 编程层面优化大模型、需要实操 kernel 开发的 AI 工程师阅读。 33. [借助 NVIDIA CUDA 13.4 在 Kubernetes 中实现按显存强制的 GPU 共享]()（博客 · 深入）：NVIDIA 技术博客，作者 Ekin Karabulut、David Lifshitz、Hagay Sharon，2026 年 10 月 27 日发布。文章介绍挂在 KAI Scheduler 组织下的开源 GPU Fractioning Operator，它与 NVIDIA GPU Operator 配合在每台 GPU 节点上配置并监管 MPS，按工作负载施加显存上限与计算模式，并按 GPU 切片而非整卡计量使用量；CUDA 13.4 引入对应用透明的显存边界强制，支持精确显存额、保证下限加可突发上限、时间切片与 SM 共享两种计算模式，KAI Scheduler v0.18.0 通过 NvFractions 模式写入 Pod 注解来落实这些设置。 34. [PyTorch 分布式概览]()（教程 · 进阶）：PyTorch 官方教程中的 torch.distributed 包总览页，将相关文档按主题分类并作简要说明。正文介绍分布式库包含并行模块、通信层以及启动和调试大型训练任务的基础设施，并列出并行 API（DDP、FSDP2、张量并行、流水线并行）和 DTensor、DeviceMesh 等分片原语。页面注明首次构建 PyTorch 分布式训练应用的人可从该文档入手寻找适用的技术。 35. [PyTorch 中的分布式数据并行——视频教程]()（课程 · 进阶）：PyTorch 官方视频教程系列的开篇页，讲解通过 DDP 进行分布式训练。系列从一个简单的非分布式训练任务开始，最终部署到跨多台机器的集群，过程中介绍用于容错分布式训练的 torchrun；章节包括 DDP 原理、单节点多 GPU 训练、容错、多节点训练和 minGPT 训练。教程假定读者对 PyTorch 模型训练有基本了解，运行代码需要多块 CUDA GPU（示例使用 4 GPU 的 Amazon EC2 P3 实例），代码托管在 GitHub 仓库中。 36. [完全分片数据并行（FSDP2）入门]()（教程 · 进阶）：PyTorch 官方中级教程，介绍 FSDP2 的工作方式，示例代码来自 pytorch/examples。正文对比 DDP，说明 FSDP 通过分片模型参数、梯度和优化器状态来降低 GPU 显存占用，使单卡放不下的模型也能训练；并描述前向与反向计算之外参数处于完全分片状态、计算前对分片参数做 all-gather、反向中对未分片梯度做 reduce-scatter 等流程。页面说明 FSDP1 已弃用，其教程已归档。 37. [用一个 Hub Bucket 传输万亿参数：TRL 中的增量权重同步]()（博客 · 深入）：文章介绍 TRL 中一项名为 Delta Weight Sync 的改动：异步强化学习中训练器每步需向推理引擎发送整个模型，而相邻两个优化步之间约 99% 的 bf16 权重完全相同，因此只把变化元素编码为稀疏 safetensors 文件，上传到 Hugging Face Bucket 并让 vLLM 拉取。文中称在 Qwen3-0.6B 上每步传输量从 1.2 GB 降至 20–35 MB，并演示了训练器、vLLM 与 Wordle 环境分处不同位置的分离式训练。 38. [解锁连续批处理中的异步性]()（教程 · 深入）：Hugging Face 博客于 2026 年 5 月 14 日发布的文章，作者为 Rémi Ouazan Reboul、Pedro Cuenca 和 Aritra Roy Gosthipaty，是高效 LLM 推理系列的第二篇。文章说明如何分离 CPU 与 GPU 工作负载以大幅提升推理性能：默认的同步连续批处理会导致 CPU 与 GPU 相互等待，停顿可能占近四分之一运行时间，因此采用异步批处理让 GPU 持续计算。文中提及 KV 缓存、FlashAttention、注意力掩码等概念，并以 H200 在 Inference Endpoints 上的价格为例说明成本考量。 39. [PyTorch 中的 Channels Last 内存格式]()（教程 · 深入）：PyTorch 官方中级教程，介绍 channels last 内存格式是什么，以及如何用它提升某些算子的性能。正文说明该格式在保留 NCHW 维度顺序的前提下改变内存排列，使通道成为最密集的维度，并利用现有 strides 结构实现，例如 10x3x16x16 批次在该格式下 strides 为 \(768, 1, 48, 3\)；该格式仅针对 4D NCHW 张量实现，页面还给出连续格式与 channels last 格式之间的张量转换 API。前置条件为 PyTorch v1.5.0 和支持 CUDA 的 GPU。 40. [用 Green Contexts 控制 GPU 如何共享工作]()（博客 · 深入）：NVIDIA 技术博客的一篇文章，介绍 CUDA 13.1 中的 green contexts：允许应用在单个进程内显式划分 SM 和工作队列等 GPU 执行资源。文中举例说，为 green context 分配专用 SM 后，延迟敏感的 kernel 无需等待批量任务排空，在拥有 148 个 SM 的 Blackwell GPU 上可将关键 kernel 延迟从 0.140 ms 降至 0.007 ms。编程模型从 green context 句柄创建 stream，而不再依赖隐式的线程本地设备状态，同时保留既有基于 stream 的 CUDA 工作流；green contexts 为可选、可叠加特性，现有应用可按需逐步采用。 41. [使用 NVIDIA Megatron Core 扩展按位确定性预训练]()（博客 · 深入）：NVIDIA 技术博客的一篇文章，介绍 Megatron-LM PR \#7262 提出的工作流：记录各 rank 有序的张量指纹，用于定位并修复大规模预训练中的非确定性。文中说明按位确定性可支持故障重放、loss 尖峰调试、系统变更验证以及中断的万亿参数训练恢复；在三项 Nemotron 工作负载上优化后，在 2,432 块 GPU 上把确定性开销降至约 2%，并在 800 步内保持按位确定性。还提到通过为 grouped-GEMM 写入者分配私有输出槽位、采用固定归约顺序等内核级改动，在保持并行的同时恢复确定性结果；Megatron Core 通过配方验证、内核测试和跨并行配置（含 FP8、FP4）的模块验证来防止回退。 42. [斯坦福 CS336：从零构建语言模型（2026 春）]()（课程 · 深入）：斯坦福大学 2026 年春季 CS336 “Language Modeling from Scratch” 课程主页，授课教师为 Tatsunori Hashimoto 和 Percy Liang，另列有多名课程助理及各自的答疑时间，课程录像发布在 YouTube 播放列表。页面介绍课程定位：语言模型是现代自然语言处理应用的基础，课程通过带学生走完开发语言模型的完整流程，帮助其全面理解语言模型。页面还提供往期开课（2025 春、2024 春）链接和课程联系方式说明。课程涉及大规模模型训练，适合具备深度学习与系统实现基础、希望深入理解语言模型构建过程的人了解。 43. [深度学习系统：算法与实现（2026 秋）]()（课程 · 深入）：这是卡内基梅隆大学风格课程“深度学习系统”的 2026 秋季课程主页（页面来自 dlsyscourse.org）。页面列有开课信息：首次课 8 月 25 日，周二、周四 11:00–12:20 在 DH 2315 上课，并给出了助教答疑的时间和地点表。课程说明部分提到，前几周采用按 Andrew ID 首字母分组的“线下期望轮换”临时安排：ID 以 a–m 开头的周二到课、周四远程，n–z 反之；所有讲座都会录像。页面还包含课程描述，说明深度学习对人工智能的影响。适合想了解该课程安排和上课方式的人阅读。 44. [Stanford CS149：并行计算（2025 秋）]()（课程 · 深入）：斯坦福大学 CS149《并行计算》2025 年秋季课程网站。课程旨在深入讲解现代并行计算系统设计的基本原理与工程权衡，并教授有效利用这些机器所需的并行编程技术，内容同时涵盖并行硬件与软件设计。基本信息显示上课时间为周二、周四 10:30–11:50，地点 NVIDIA Auditorium，授课教师为 Kayvon Fatahalian 和 Kunle Olukotun。页面还列出课程安排，前几讲涉及并行的动机与效率、现代多核处理器（多核、SIMD、多线程）、ISPC 编程抽象、数据并行示例以及程序优化等主题。 --- 中文标题与摘要由模型根据原文生成，以原文为准。 来源：LearnMap · 学径（https://oplearnx.com）