模型服务与算力

学习模型服务框架、并行计算与底层优化,适合维护训练和推理基础设施的人员。

44 条精选 · 入门 2 · 按推荐学习顺序:越基础、直观越靠前,越系统、深入越靠后

在 3D 图中查看
  1. 1入门
    博客发布 10-21
    NVIDIA 博客

    GTC 柏林 2026:NVIDIA CEO 黄仁勋主题演讲实时更新

    GTC Berlin 2026: Live Updates From NVIDIA CEO Jensen Huang’s Keynote

    这是 NVIDIA 官方博客对 GTC 柏林 2026 主题演讲的实时报道。文章介绍大会在柏林举行、为期三天、包含 100 多场关于智能体 AI、机器人、物理 AI、开放模型与加速计算的会议,并记录黄仁勋开场提到多家欧洲企业与 NVIDIA 的 AI 合作、公司对欧洲技术生态近 100 亿美元的投入,以及“AI 五层蛋糕”的表述。

  2. 2入门
    博客发布 05-12
    Hugging Face

    在 AWS 上进行基础模型训练与推理的构建模块

    Building Blocks for Foundation Model Training and Inference on AWS

    Hugging Face 上由亚马逊作者 Keita Watanabe、Pavel Belevich、Aman Shanbhag 撰写、2026 年 5 月 11 日发布的企业类文章,讨论在 AWS 上训练和推理基础模型的构建模块。文章从 Kaplan 等人 2020 年关于缩放定律的研究出发,引用英伟达“从一个到三个缩放定律”的框架,说明除预训练外,后训练(如监督微调和强化学习方法)与测试时计算也在推动性能提升,并据此讨论基础模型生命周期。

  3. 3进阶
    博客发布 10-23
    Latent Space

    为什么 AI 算力是按矩形购买的 —— Erik Bernhardsson,Modal CEO

    Why AI Compute Comes in Rectangles — Erik Bernhardsson, Modal CEO

    Latent Space 的访谈节目,主持人与 Modal CEO Erik Bernhardsson 讨论公司在 5 亿美元 C 轮后完成 7.5 亿美元 D 轮、估值 160 亿美元、年化收入突破 10 亿美元并创建近 30 亿个沙箱的情况。核心话题是算力经济学:传统容量合同把 GPU 按固定数量、固定时长购买,在时间—容量图上呈矩形,而真实工作负载会增长、突增、回落;Erik 讲述 Modal 如何通过聚合数千客户的需求来做“时长变换”。含 YouTube 完整对话链接,涉及服务器无服务器化 AI 基础设施的开发者与商业读者可关注。

  4. 4进阶
    博客发布 10-21
    Latent Space

    可编程数据中心——Evan Conrad,SF Compute

    The Programmable Data Center — Evan Conrad, SF Compute

    这是 Latent Space 在 AIE NYC 新设的 Compute Trading 分论坛期间录制的对谈,嘉宾为 SF Compute 的 Evan Conrad。文章以软件定义网络对思科、VMware 的影响作类比,讨论 GPU 计算的同类变化:SF Compute 让用户买卖当下和未来的 GPU 小时,并从网络到内存进行程序化控制。对谈还涉及物理交付 GPU 合约需要什么条件、计算市场要变得流动需要满足哪些前提,以及公司从转租集群扩展到承担云运营商职能的过程。

  5. 5进阶
    博客发布 10-21
    YouTube

    同样的 GPU,产出多出 50%:为什么运营方是关键——SemiAnalysis 的 Oliver Kennon

    Same GPU, 50% More Output: Why the Operator Matters — Oliver Kennon, SemiAnalysis

    演讲把算力视为大宗商品市场,指出购买 GPU 只是获得潜力,实际可用产出取决于运营方:在同样的 B200 芯片上,仅服务栈一项就能带来约 50% 的产出差异。内容还包括集群安全如何影响“智能”是否有用、SemiAnalysis 的 ClusterMAX 如何给运营方评级、租用价格与生产成本的区别、成本位置取决于竞争对手,以及构建可比算力评级与算力期货所需的条件。

  6. 6进阶
    帖子发布 10-26
    Reddit

    为一万到一万二千美元预算的本地 agentic coding 装机:1× 5090 对比 4× 3090、混合方案、PRO 6000、Mac Studio?

    $10–12K build for local agentic coding: 1× 5090 vs 4× 3090 vs hybrid vs PRO 6000 vs 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. 7进阶
    博客发布 10-23
    Hugging Face

    你的模型能在 AWS Trainium 上运行吗?查一查就知道

    Does Your Model Run on AWS Trainium? Look It Up

    文章介绍一个 torch-neuronx 模型支持情况 Space,用于查询 Hub 上热门模型能否在 AWS Trainium 上运行。该 Space 的 Selected 视图展示按下载量和趋势分挑选的模型,每行给出结果、模型分片占用的 Trainium 核心数、运行实际耗时(含编译)和峰值设备内存;Trending 和 Downloads 视图按 Hub 自身排名逐任务列出结果,并对故意未测试的模型说明原因,还可选择 neuronx-cc 和 Transformers 的版本。这是继此前介绍 TorchNeuron 的文章之后的更新。

  8. 8进阶
    博客发布 10-19
    Hugging Face

    TorchNeuron:在 AWS Trainium 上运行 HF 模型前所未有地简单

    TorchNeuron: running HF models on AWS Trainium is easier than ever

    这是 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. 9进阶
    博客必读发布 10-20
    Hugging Face

    Hugging Face ❤️ TorchTPU:原生支持 TPU

    Hugging Face ❤️ TorchTPU: TPUs, Natively

    博客文章,介绍 TorchTPU 这一原生 PyTorch 后端,使 TPU 成为 PyTorch 中的普通设备;文中称 Transformers、Diffusers 和 Kernels 可在 TPU 上原生运行,从 Hub 选择模型后发送到 "tpu" 即可。文章还简介了 TPU 作为 Google 自研 AI 加速器的情况与可用规模,并对比了此前需经 torch_xla 的旧方式及其限制。面向希望在 TPU 上运行 PyTorch 模型的用户。

  10. 10进阶
    博客发布 10-20
    Hugging Face

    PyTorch 2.15 中的 MPS

    MPS in PyTorch 2.15

    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. 11进阶
  12. 12进阶
    项目发布 10-02
    GitHub

    cobanov/PS5LM

    该项目把 llama.cpp 移植到已越狱的 PlayStation 5 上,允许主机原生运行 GGUF 格式模型,从 Qwen 3.8 开始。README 说明它借助主机 GPU 推理,提供 OpenAI 与 Anthropic 兼容 API 和适配电视的界面,可在无 PC、无云端、无账号的情况下为局域网内设备提供模型服务,另新增了 Ollaya 的决策模型支持。适合拥有越狱 PS5、想在家搭私有模型服务的读者。

  13. 13进阶
    帖子发布 10-29
    Reddit

    在 4 块 R9700 上对比 Qwen 3.8 27B 与 Nanbeige 4.3 33B:我的工作负载下的实际 TPS 与每小时任务数

    Qwen 3.8 27B vs Nanbeige 4.3 33B on 4xR9700s: Real World TPS and jobs/hour on my workload

    这是 r/LocalLLaMA 的一篇社区帖子,作者此前发布过用 127 美元二手 EPYC 搭建 4 卡 R9700 机器的方案,本次在同一套硬件上对比 Qwen 3.8 27B 与 Nanbeige 4.3 33B。他以自己公司维护枪械相关商家信息(营业时间、价格、设施等)的实际工作为负载,让两套配置各跑同样的 2,484 个案例,以审计员身份输出接受、拒绝或弃权,并统计吞吐、每日经核实的正确任务数、准确率,以及 1/4/8 路并发下的 token 速度。帖子还提到 Qwen 在思考模式下审计自身结果的表现优于 Nanbeige,并在结尾向做编程或创意写作测试的人征询情况。适合关注本地多卡推理部署、按实际业务任务而非纯跑分评估模型的人阅读。

  14. 14深入
    帖子发布 10-27
    Reddit

    MacBook Pro M5 Max 上运行 Nanbeige4.3-33B Q4:mlx-lm、llama.cpp 与 Kapitsa 的对比,512 到 32K 上下文范围

    Nanbeige4.3-33B Q4 on a MacBook Pro M5 Max, mlx-lm vs llama.cpp vs Kapitsa, Prefill/Decode 512 to 32K range.

    这是一篇社区基准测试帖,在 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. 15深入
    帖子发布 10-26
    Reddit

    RTX 3080 20GB 解锁 reBAR 与 P2P:提示处理速度提升 70%

    RTX 3080 20GB got reBAR and P2P unlock! +70% prompt processing speed

    帖子称 RTX 3080 20GB 的 P2P 已解锁,在张量并行模式下提示处理速度大幅提升;发帖人转述原作者 u/nathannguyennng 的工作,并给出自己的测试环境(Proxmox 上双 RTX 3080 20GB、vllm 0.32.0、INT4 量化模型、张量并行等)以及原装、gpu-unlock、gpu-unlock+ReBAR+P2P 三种配置的对比。适合在本地多卡上运行大模型、关注vLLM 推理性能调优的人阅读。

  16. 16深入
    帖子发布 10-26
    Reddit

    试过在 3090 等显卡上做 GPU 解锁的人:对混合精度量化(部分权重 ≤Q8、部分张量保留 BF16)有区别吗?

    People who tried gpu-unlock on 3090s and such - does this make any difference on mixed-precision quants where you get some parts of the model quantized to <=Q8 but keep some tensors at BF16?

    这是一篇社区提问帖,询问在 3090 一类显卡上解锁 FP16/BF16 矩阵乘性能后,对混合精度量化模型是否有效。评论者回复称基本没有差别:解锁只放开带 FP32 累加的 FP16/BF16 与 TF32 矩阵乘;llama.cpp 对 Q4–Q8 等量化权重走 MMQ INT8→INT32 路径,本来就没有锁定,实测 Q6_K 模型 prefill 与 decode 速度无变化,收益只出现在用 llama.cpp 跑未量化 BF16 GGUF 时。适合在消费级显卡上运行量化模型并关心推理性能调优的人阅读。

  17. 17进阶
    帖子发布 10-27
    Reddit

    搭建 GPU kernel 开发环境的实践笔记:CUDA 13 的显卡截止、异步计时陷阱、profiler 计数器权限 [P]

    Practical notes on setting up a GPU kernel-dev environment: CUDA 13's GPU cutoff, async timing pitfalls, profiler counter permissions [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. 18进阶
    教程发布 10-22
    Hugging Face

    剖析 TorchNeuron(第一部分):在 AWS Trainium 上进行系统级性能剖析

    Profiling TorchNeuron (Part 1): System-level profiling on AWS Trainium.

    这是关于 AWS Trainium 的系列文章第一篇,介绍如何系统地分析推理性能并找出时间开销所在。文章使用 Trainium 专用的开源 PyTorch 后端 TorchNeuron,讲解如何配置 torch.profiler 并抓取干净的 trace、阅读 key_averages() 表格以识别消耗 Neuron 设备时间的算子、以及通过 Neuron Explorer 追踪单个算子从框架调度到 NeuronCore 硬件执行的过程。文中说明从零讲起,假定读者没有性能剖析经验。

  19. 19进阶
    博客发布 06-24
    OpenAI

    OpenAI 与 Broadcom 发布面向 LLM 优化的推理芯片

    OpenAI and Broadcom unveil LLM-optimized inference chip

    这是 OpenAI 与 Broadcom(NASDAQ: AVGO)的发布公告,介绍 OpenAI 首款“智能处理器”Jalapeño,一款围绕 LLM 推理架构设计的定制加速器。文中称早期测试显示其每瓦性能显著优于当前最先进水平,从设计到量产历时九个月,并将与数据中心伙伴按吉瓦级规模多代部署。

  20. 20进阶
    博客发布 10-21
    NVIDIA 博客

    英伟达机密计算扩展,使前沿模型构建者可在全球基础设施上安全扩展

    NVIDIA Confidential Computing Expands, Enabling Frontier Model Builders to Securely Scale Across Global Infrastructure

    这是 NVIDIA 博客文章,介绍 NVIDIA 机密计算的扩展。文中提到 NVIDIA OpenShell 参考架构,以及新增的 Confidential Bare Metal 部署选项,使前沿模型构建者可在第三方专用基础设施上运行敏感工作负载,同时保留对模型和数据的控制。文章还介绍新的平台安全控制,用于保护传输中的数据、度量平台完整性并实施硬件级访问限制;指出机密计算现提供裸金属、Kubernetes 容器和虚拟机三种部署选项。适合关注模型训练与部署基础设施安全的企业与开发者读者。

  21. 21深入
    博客发布 10-27
    developer.nvidia.com

    在 NVIDIA DGX Spark 上提升 MoE 推理性能的 3 种方法

    3 Ways to Boost MoE Inference on NVIDIA DGX Spark

    这是 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. 22深入
    教程发布 10-23
    developer.nvidia.com

    如何用 NVIDIA GPUDirect Storage 在 Python 中把数据读入 GPU 显存

    How to Read Data into GPU Memory in Python with NVIDIA GPUDirect Storage

    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. 23深入
    博客发布 10-27
    blog.cloudflare.com

    GLM-5.3 Workers AI 模型中的跨请求 KV 缓存泄露(155 条响应)

    Cross-request KV cache exposure in the GLM-5.3 Workers AI model (155 responses)

    这是 Cloudflare 博客与推理引擎 SGLang 协同披露的一篇安全事件报告。文章称 2026 年 8 月 27 日至 9 月 9 日期间,使用 GLM-5.3 Workers AI 模型的少数客户收到了包含其他客户此前请求数据的响应,共涉及 155 条响应,且均为超过 681,280 token 的长提示。文章说明问题已修复并于 9 月 9 日恢复该模型,未发现故意利用的证据,同时介绍了缺陷原因、响应时间线及对生产环境 SGLang 部署的加固措施。

  24. 24深入
    博客发布 10-20
    Google 开发者博客

    将 TorchTPU 集成进 TorchTitan 并为 TPU 优化模型

    Integrating TorchTPU into TorchTitan and Optimizing Models for 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. 25深入
    项目发布 10-27
    GitHub

    我构建了一个能在廉价(尚可)硬件上以近 400 token/s 运行 Qwen-Flash-Next 的引擎:老 R740 中的 3 块 V100 32GB;最初从 strata 分叉,但引擎核心全部针对老 Volta 架构构建

    I built an engine that runs Qwen-Flash-Next at nearly 400t/s on cheap(ish) hardware. 3x V100 32GB in an old R740. Originally forked from strata but the engine guts all built for the old Volta generation.

    这是一个 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. 26深入
    项目发布 10-07
    GitHub

    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. 27深入
    项目必读发布 10-16
    GitHub

    DeepInfer:DeepSeek 模型的高性能推理框架

    DeepInfer: High-performance inference framework for DeepSeek models

    DeepSeek 在 GitHub 上开源的推理框架仓库,称其为支撑 DeepSeek 大规模生产服务的高性能框架,此次开源版本提供面向规模化服务的离线推理能力。README 列出支持的模型为 DeepSeek-V4.1-Flash,并列出了优化内核、注意力 DP/CP 与 MoE EP+EPLB 并行、异步调度、批不变量推理、确定性采样、结构化输出等功能及配置细节。材料中还包含一条 Reddit 用户评论。

  28. 28深入
    项目发布 10-23
    Hugging Face

    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. 29深入
    博客发布 10-24
    OpenAI

    为服务逾 10 亿 ChatGPT 用户而快速扩展在线存储(第二部分)

    Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

    OpenAI 工程博客系列第二部分,作者为 Jon Lee、Hrachya Hakobyan 和 Chaomin Yu,讲述其应用存储平台 Habitat 如何针对 Azure Cosmos DB 做优化以应对用户规模的快速增长,并实现 ChatGPT 读取速度提升 12 倍。内容包括可靠的多租户机制与全局缓存等主题。工程与基础设施方向的读者可参考。

  30. 30深入
    帖子发布 10-27
    Reddit

    我为一个面向大规模 GPU 工作负载的 PyTorch 优化器做了实现——希望获得反馈 [P]

    I built a PyTorch optimizer for large GPU workloads — looking for feedback[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. 31深入
    项目发布 10-27
    Reddit

    Deepity:一个手工调优的 C++/CUDA 预测编码库,在 MNIST 上超过 jpc(JAX)和 ngc-learn(含 CPU 基准与源码)[P]

    Deepity: a hand-tuned C++/CUDA predictive coding library, beats jpc (JAX) and ngc-learn on MNIST (CPU benchmarks + source inside) [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. 32深入
    书籍发布 10-15
    Manning

    面向 LLM 的 CUDA

    CUDA for LLMs

    这是 Manning Publications 出版的书,作者 Elliot Arledge,出版日期 2026-10-15,408 页,ISBN 9781633434899,主题词为数据科学与深度学习。简介称其讲解在 CUDA 生态中从编写第一个 kernel 到实现 Flash Attention 等高级 LLM 特性,包括用 Nsight Compute 做性能剖析与瓶颈定位,并针对最新 NVIDIA 硬件讲解 CUDA 基础。适合想从 GPU 编程层面优化大模型、需要实操 kernel 开发的 AI 工程师阅读。

  33. 33深入
    博客发布 10-28
    developer.nvidia.com

    借助 NVIDIA CUDA 13.4 在 Kubernetes 中实现按显存强制的 GPU 共享

    Memory-Enforced GPU Sharing in Kubernetes with NVIDIA CUDA 13.4

    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. 34进阶
    教程发布 2023-01-01
    docs.pytorch.org

    PyTorch 分布式概览

    PyTorch Distributed Overview

    PyTorch 官方教程中的 torch.distributed 包总览页,将相关文档按主题分类并作简要说明。正文介绍分布式库包含并行模块、通信层以及启动和调试大型训练任务的基础设施,并列出并行 API(DDP、FSDP2、张量并行、流水线并行)和 DTensor、DeviceMesh 等分片原语。页面注明首次构建 PyTorch 分布式训练应用的人可从该文档入手寻找适用的技术。

  35. 35进阶
    课程发布 2023-01-01
    docs.pytorch.org

    PyTorch 中的分布式数据并行——视频教程

    Distributed Data Parallel in PyTorch - Video Tutorials

    PyTorch 官方视频教程系列的开篇页,讲解通过 DDP 进行分布式训练。系列从一个简单的非分布式训练任务开始,最终部署到跨多台机器的集群,过程中介绍用于容错分布式训练的 torchrun;章节包括 DDP 原理、单节点多 GPU 训练、容错、多节点训练和 minGPT 训练。教程假定读者对 PyTorch 模型训练有基本了解,运行代码需要多块 CUDA GPU(示例使用 4 GPU 的 Amazon EC2 P3 实例),代码托管在 GitHub 仓库中。

  36. 36进阶
    教程发布 2023-01-01
    docs.pytorch.org

    完全分片数据并行(FSDP2)入门

    Getting Started with Fully Sharded Data Parallel (FSDP2)

    PyTorch 官方中级教程,介绍 FSDP2 的工作方式,示例代码来自 pytorch/examples。正文对比 DDP,说明 FSDP 通过分片模型参数、梯度和优化器状态来降低 GPU 显存占用,使单卡放不下的模型也能训练;并描述前向与反向计算之外参数处于完全分片状态、计算前对分片参数做 all-gather、反向中对未分片梯度做 reduce-scatter 等流程。页面说明 FSDP1 已弃用,其教程已归档。

  37. 37深入
    博客发布 05-27
    Hugging Face

    用一个 Hub Bucket 传输万亿参数:TRL 中的增量权重同步

    Shipping a Trillion Parameters With a Hub Bucket: Delta Weight Sync in TRL

    文章介绍 TRL 中一项名为 Delta Weight Sync 的改动:异步强化学习中训练器每步需向推理引擎发送整个模型,而相邻两个优化步之间约 99% 的 bf16 权重完全相同,因此只把变化元素编码为稀疏 safetensors 文件,上传到 Hugging Face Bucket 并让 vLLM 拉取。文中称在 Qwen3-0.6B 上每步传输量从 1.2 GB 降至 20–35 MB,并演示了训练器、vLLM 与 Wordle 环境分处不同位置的分离式训练。

  38. 38深入
    教程发布 05-14
    Hugging Face

    解锁连续批处理中的异步性

    Unlocking asynchronicity in continuous batching

    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. 39深入
    教程发布 2023-01-01
    docs.pytorch.org

    PyTorch 中的 Channels Last 内存格式

    Channels Last Memory Format in PyTorch

    PyTorch 官方中级教程,介绍 channels last 内存格式是什么,以及如何用它提升某些算子的性能。正文说明该格式在保留 NCHW 维度顺序的前提下改变内存排列,使通道成为最密集的维度,并利用现有 strides 结构实现,例如 10x3x16x16 批次在该格式下 strides 为 (768, 1, 48, 3);该格式仅针对 4D NCHW 张量实现,页面还给出连续格式与 channels last 格式之间的张量转换 API。前置条件为 PyTorch v1.5.0 和支持 CUDA 的 GPU。

  40. 40深入
    博客发布 10-06
    developer.nvidia.com

    用 Green Contexts 控制 GPU 如何共享工作

    Control How Your GPU Shares Work with Green Contexts

    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. 41深入
    博客发布 10-07
    developer.nvidia.com

    使用 NVIDIA Megatron Core 扩展按位确定性预训练

    Scale Bitwise-Deterministic Pretraining with NVIDIA Megatron Core

    NVIDIA 技术博客的一篇文章,介绍 Megatron-LM PR #7262 提出的工作流:记录各 rank 有序的张量指纹,用于定位并修复大规模预训练中的非确定性。文中说明按位确定性可支持故障重放、loss 尖峰调试、系统变更验证以及中断的万亿参数训练恢复;在三项 Nemotron 工作负载上优化后,在 2,432 块 GPU 上把确定性开销降至约 2%,并在 800 步内保持按位确定性。还提到通过为 grouped-GEMM 写入者分配私有输出槽位、采用固定归约顺序等内核级改动,在保持并行的同时恢复确定性结果;Megatron Core 通过配方验证、内核测试和跨并行配置(含 FP8、FP4)的模块验证来防止回退。

  42. 42深入
    课程必读发布 03-28
    Stanford 课程官网

    斯坦福 CS336:从零构建语言模型(2026 春)

    斯坦福大学 2026 年春季 CS336 “Language Modeling from Scratch” 课程主页,授课教师为 Tatsunori Hashimoto 和 Percy Liang,另列有多名课程助理及各自的答疑时间,课程录像发布在 YouTube 播放列表。页面介绍课程定位:语言模型是现代自然语言处理应用的基础,课程通过带学生走完开发语言模型的完整流程,帮助其全面理解语言模型。页面还提供往期开课(2025 春、2024 春)链接和课程联系方式说明。课程涉及大规模模型训练,适合具备深度学习与系统实现基础、希望深入理解语言模型构建过程的人了解。

  43. 43深入
    课程
    dlsyscourse.org

    深度学习系统:算法与实现(2026 秋)

    这是卡内基梅隆大学风格课程“深度学习系统”的 2026 秋季课程主页(页面来自 dlsyscourse.org)。页面列有开课信息:首次课 8 月 25 日,周二、周四 11:00–12:20 在 DH 2315 上课,并给出了助教答疑的时间和地点表。课程说明部分提到,前几周采用按 Andrew ID 首字母分组的“线下期望轮换”临时安排:ID 以 a–m 开头的周二到课、周四远程,n–z 反之;所有讲座都会录像。页面还包含课程描述,说明深度学习对人工智能的影响。适合想了解该课程安排和上课方式的人阅读。

  44. 44深入
    课程
    Stanford 课程官网

    Stanford CS149:并行计算(2025 秋)

    斯坦福大学 CS149《并行计算》2025 年秋季课程网站。课程旨在深入讲解现代并行计算系统设计的基本原理与工程权衡,并教授有效利用这些机器所需的并行编程技术,内容同时涵盖并行硬件与软件设计。基本信息显示上课时间为周二、周四 10:30–11:50,地点 NVIDIA Auditorium,授课教师为 Kayvon Fatahalian 和 Kunle Olukotun。页面还列出课程安排,前几讲涉及并行的动机与效率、现代多核处理器(多核、SIMD、多线程)、ISPC 编程抽象、数据并行示例以及程序优化等主题。

部署与推理优化的其他细分主题