From 4b0121bf94add0a52b48440ce69570ec0b1d5c35 Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Wed, 5 Aug 2026 21:29:41 +0800 Subject: [PATCH] docs: update AI study notes and kernel descriptions --- study/ai/AIOS.MD | 21 +- study/ai/TRANSFORMER.MD | 231 +++-- study/kernel/00-DESCRIPTION/ARCH.md | 13 +- study/kernel/00-DESCRIPTION/BPF.md | 18 + study/kernel/00-DESCRIPTION/DEBUGGING.md | 17 +- study/kernel/00-DESCRIPTION/LOCKING.md | 3 +- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 1 + study/kernel/00-DESCRIPTION/SCHEDULER.md | 58 +- study/kernel/00-DESCRIPTION/TODO.md | 932 +++++++++++++++--- 9 files changed, 1035 insertions(+), 259 deletions(-) diff --git a/study/ai/AIOS.MD b/study/ai/AIOS.MD index db62b0f..6c26820 100644 --- a/study/ai/AIOS.MD +++ b/study/ai/AIOS.MD @@ -58,13 +58,13 @@ blogexcerpt: 虚拟化 & KVM 子系统 华擎的 AI QuickSet WSL 旨在通过 WSL 下的自动 ROCm 设置以及安装/配置流行的 AI 软件包以在 WSL+ROCm 下加速执行, 从而轻松"在 Windows 上运行 Linux AI 应用程序". 参见 [phoronix, 2025/09/15, ASRock AI Quickset WSL Aims To Make It Easier Running ROCm + AI Linux Apps On Windows](https://www.phoronix.com/news/ASRock-AI-QuickSet-WSL) -[知乎--机器之心--跟不上、读不完？上万篇顶会论文，这个工具一键分析](https://zhuanlan.zhihu.com/p/1968619277394346770) +[知乎--机器之心--跟不上、读不完？上万篇顶会论文, 这个工具一键分析](https://zhuanlan.zhihu.com/p/1968619277394346770) ## 1.1 AI4OS ------- -[Learning-directed operating system (LDOS)](https://ldos.utexas.edu) 是德克萨斯大学奥斯汀分校的一个研究项目, 专注于开发基于机器学习的下一代作系统, 以提高效率和性能. 该项目旨在通过将机器学习驱动的方法集成到核心系统组件中, 通过"从头开始的范式"彻底改变作系统设计. 这包括优化资源分配、调度和拥塞控制机制，以动态适应不同的工作负载. +[Learning-directed operating system (LDOS)](https://ldos.utexas.edu) 是德克萨斯大学奥斯汀分校的一个研究项目, 专注于开发基于机器学习的下一代作系统, 以提高效率和性能. 该项目旨在通过将机器学习驱动的方法集成到核心系统组件中, 通过"从头开始的范式"彻底改变作系统设计. 这包括优化资源分配、调度和拥塞控制机制, 以动态适应不同的工作负载. 2025 年, LDOS 团队发表了两篇论文: "Canopy: Property-Driven Learning for Congestion Control" 探索了使用机器学习根据网络属性动态调整拥塞控制策略, "Large Language Models as Realistic Microservice Trace Generators" 应用 LLM 生成用于测试微服务的真实流量跟踪, 提高模拟模型的准确性. @@ -76,8 +76,8 @@ blogexcerpt: 虚拟化 & KVM 子系统 | 2025/07 | AI 辅助调度 Load Balancing | [LWN 2025/07/01, Improved load balancing with machine learning](https://lwn.net/Articles/1027096 | Free5GC | Ching-Chun("Jim") Huang 展示了其将 (本地) 机器学习应用于在复杂系统上调度器负载均衡的工作成果, [Improve Load Balancing with Machine Learning Techniques based on sched_ext Framework](https://static.sched.com/hosted_files/ossna2025/d2/Improve-Load-Balancing-With-Machine-Learning-Techniques-based-on-sched_ext.pdf). Free5GC 开发人员研究通过机器学习来改进调度器的负载均衡. 在此类系统上进行调度需要考虑许多输入维度; 此外, 调度程序还必须考虑每个任务的优先级、其 CPU 要求、到目前为止的虚拟运行时间以及最近的 CPU 使用模式. 必须考虑每个 CPU 上的负载, 以及 NUMA 距离、缓存共享和工作频率. 当然, 还有特定于工作负载的因素. 基于 scx_rusty 来尝试考虑所有这些参数并决定何时应该将任务从一个 CPU 移动到另一个 CPU. 它最初以数据收集模式运行, 查看迁移决策及其结果; 然后, 这些决策用于训练模型(在用户空间中), 该模型随后存储在 BPF 映射中. 然后, 调度程序可以在内核内使用此模型来做出负载平衡决策. 这些决策的结果会不断被测量并报告回用户空间, 从而随着时间的推移更新模型. 在使用最重要的内核编译基准测试的测试中, 该调度器的编译时间比 EEVDF 调度器缩短了 10%, 任务迁移的数量减少了 77%. Huang 总结了机器学习在这种情况下起作用的原因: 在这种复杂的环境中进行调度是一个模式识别问题, 而神经网络擅长这项任务. 调度程序能够平衡相互竞争的目标, 并自动针对新的架构和工作负载进行自我重新训练. 调度程序能够为每个迁移决策考虑 15 个单独的参数, 并根据结果调整其模型. [2025 Open Source Summit North America](https://events.linuxfoundation.org/open-source-summit-north-america), 参见 LWN 报道 [LWN 2025/07/01, Improved load balancing with machine learning](https://lwn.net/Articles/1027096), 代码 [scx_rusty](https://github.com/vax-r/scx/tree/scx_rusty_MLLB). | | 2025/03 | AI 辅助 CPU/GPU 调频 | [An Intelligent Scheduling Approach on Mobile OS for Optimizing UI Smoothness and Power](https://dl.acm.org/doi/full/10.1145/3674910) | 提出了 MobiRL 一种基于强化学习的调度器, 用于智能地调整移动系统中的 CPU/GPU 频率, 以准确满足用户需求. MobiRL监测移动系统状态, 并通过执行 CPU/GPU 频率调整操作自主学习以优化用户界面的流畅度和功耗. 在最新交付的智能手机上的实验结果表明, MobiRL 在真实设备上的表现优于广泛使用的商业调度器——分别降低了 4.1% 的掉帧率和 42.8% 的功耗. 此外, 与使用 Q 学习进行 CPU 频率调度的研究相比, MobiRL 实现了最高 2.5% 的掉帧率降低, 并分别减少了 32.6% 的功耗. | | 2025/03/25 | AI 辅助 CPU/GPU/DDR 调频 | [CRAVE: Analyzing Cross-Resource Interaction to Improve Energy Efficiency in Systems-on-Chip](https://dl.acm.org/doi/10.1145/3689031.3717498) | 提出了 CRAVE, 它利用学习到的设计特性来控制动态电压和频率调节. 在设计阶段, CRAVE 通过在三个主要移动系统组件(CPU内核、GPU和内存)的频率设置多元空间中采样, 为系统级芯片(SoC)确定最优的 DVFS 设置. 在运行时, CRAVE 以类似于当今操作系统内核中内置的现有简单调速器的方式监控资源利用率, 然后应用之前学习到的最优设置. 在两个真实的移动平台上实现了CRAVE: ODROID-XU4 和 NVIDIA Jetson TX2. 与最佳的内置 Linux 调速器相比, CRAVE 在 TX2 上将性能提高了20%, 同时能耗降低了 16%, 在 XU4 上也取得了类似的提升. 此外, 与最先进的应用驱动调速器相比, CRAVE 也表现出了一定的优势, 性能提高了 16%, 能耗节省了10%. | -| 2025/07/11 | AI 生成操作系统交互界面 | | [NeuralOS: Towards Simulating Operating Systems via Neural Generative Models](https://arxiv.org/abs/2507.08800) | 滑铁卢大学 | 名为 NeuralOS 的创新性神经框架. 其核心目标是利用深度生成模型, 完全模拟一个操作系统的图形用户界面(GUI). 不同于传统依赖预编程内核和应用程序的操作系统, NeuralOS 通过一个深度神经网络, 直接根据用户的输入(如鼠标移动、点击和键盘事件)来预测并生成屏幕的下一帧图像.
核心贡献可以概括为以下几点:
1. 提出新范式: 首次尝试将整个操作系统 GUI 交互过程建模为一个端到端的生成问题, 为实现完全自适应、个性化的未来人机交互界面提供了概念验证(Proof-of-Concept).
2. 设计创新架构: 提出了一种受传统操作系统启发的模块化架构, 该架构由一个负责追踪系统状态的循环神经网络(RNN)"内核"和一个负责生成屏幕图像的扩散模型"渲染器"组成, 有效处理了动态交互中的长期依赖和高保真视觉生成.
3. 开发有效训练策略: 设计了一套复杂的多阶段训练流程, 包括 RNN 预训练、联合训练、计划采样和课程学习等, 成功解决了直接训练生成式交互模型时遇到的梯度消失、渲染器忽略控制信号和误差累积等关键挑战.
4. 构建大规模数据集: 通过结合 AI Agent 的智能探索和随机探索, 建立了一个大规模、多样化的 Ubuntu XFCE 桌面交互数据集, 为训练此类复杂的交互模型奠定了基础. 参见 [知乎--周舒畅--远程桌面蒸馏成RNN+扩散模型：NeuralOS: Towards Simulating Operating Systems via Neural Generative Models](https://zhuanlan.zhihu.com/p/1928592949131863847) | -| 2025/10/21 | AI 实现补丁管理，实现补丁管理效率倍级提升| openEuler | [基于 openEuler Intelligence打造补丁管理智能体，实现补丁管理效率倍级提升](https://mp.weixin.qq.com/s/SwRTuH6iDISfD3QucNeOzw) | openEuler Intelligence 服务引擎, 实现操作系统级的 Agent 智能体与 MCP 工具管理, 提供全局、高效、低噪的智能服务框架. | +| 2025/07/11 | AI 生成操作系统交互界面 | | [NeuralOS: Towards Simulating Operating Systems via Neural Generative Models](https://arxiv.org/abs/2507.08800) | 滑铁卢大学 | 名为 NeuralOS 的创新性神经框架. 其核心目标是利用深度生成模型, 完全模拟一个操作系统的图形用户界面(GUI). 不同于传统依赖预编程内核和应用程序的操作系统, NeuralOS 通过一个深度神经网络, 直接根据用户的输入(如鼠标移动、点击和键盘事件)来预测并生成屏幕的下一帧图像.
核心贡献可以概括为以下几点:
1. 提出新范式: 首次尝试将整个操作系统 GUI 交互过程建模为一个端到端的生成问题, 为实现完全自适应、个性化的未来人机交互界面提供了概念验证(Proof-of-Concept).
2. 设计创新架构: 提出了一种受传统操作系统启发的模块化架构, 该架构由一个负责追踪系统状态的循环神经网络(RNN)"内核"和一个负责生成屏幕图像的扩散模型"渲染器"组成, 有效处理了动态交互中的长期依赖和高保真视觉生成.
3. 开发有效训练策略: 设计了一套复杂的多阶段训练流程, 包括 RNN 预训练、联合训练、计划采样和课程学习等, 成功解决了直接训练生成式交互模型时遇到的梯度消失、渲染器忽略控制信号和误差累积等关键挑战.
4. 构建大规模数据集: 通过结合 AI Agent 的智能探索和随机探索, 建立了一个大规模、多样化的 Ubuntu XFCE 桌面交互数据集, 为训练此类复杂的交互模型奠定了基础. 参见 [知乎--周舒畅--远程桌面蒸馏成RNN+扩散模型: NeuralOS: Towards Simulating Operating Systems via Neural Generative Models](https://zhuanlan.zhihu.com/p/1928592949131863847) | +| 2025/10/21 | AI 实现补丁管理, 实现补丁管理效率倍级提升| openEuler | [基于 openEuler Intelligence打造补丁管理智能体, 实现补丁管理效率倍级提升](https://mp.weixin.qq.com/s/SwRTuH6iDISfD3QucNeOzw) | openEuler Intelligence 服务引擎, 实现操作系统级的 Agent 智能体与 MCP 工具管理, 提供全局、高效、低噪的智能服务框架. | | 2026/01/11 | 利用大语言模型(LLM) 辅助解决 Linux 内核中的 Git 合并冲突 | [LLMinus: LLM-Assisted Merge Conflict Resolution](https://lore.kernel.org/all/20260111212915.195056-1-sashal@kernel.org) | Sasha Levin | 引入名为 **LLMinus** 的工具, 利用大语言模型( LLM) 辅助解决 Linux 内核中的 Git 合并冲突. LLMinus 通过构建历史冲突解决案例的数据库, 使用语义嵌入( 基于 BGE-small 模型) 查找相似冲突, 并为 LLM 构建包含上下文的提示以辅助解决当前冲突.
工具支持 `learn`、`vectorize`、`find`、`resolve`、`pull` 等命令, 可与任意支持标准输入的 LLM 配合使用. 新版本改进包括: 支持自适应 RAG 缩减的 token 限制、通过构建测试检测语义冲突, 以及更新 HTTP 客户端.
LLMinus 正在通过子系统集成分支进行实际测试, 相关仓库可供参考.该工具旨在辅助而非替代现有合并流程. | v2 ☐☑✓ | [2026/01/11, LORE v2, 0/7](https://lore.kernel.org/all/20260111212915.195056-1-sashal@kernel.org) | | 2025/02/25 | 通过 AI 生成 eBPF 程序 | [Kgent: Kernel Extensions Large Language Model Agent](https://dl.acm.org/doi/10.1145/3672197.3673434) | NA | Kgent 简化了传统上复杂的 eBPF 程序编写过程. 通过将用户提示语翻译成 eBPF 代码, 消除了对深厚作系统内核知识的需求. 该工具结合了程序理解、符号执行和反馈循环, 确保合成程序准确且符合用户意ds图. 参见 [Simplifying Kernel Programming: The LLM-Powered eBPF Tool](https://eunomia.dev/blog/2024/07/11/simplifying-kernel-programming-the-llm-powered-ebpf-tool) | | [](https://github.com/xlang-ai/OSWorld-G) | @@ -93,10 +93,19 @@ blogexcerpt: 虚拟化 & KVM 子系统 | 2025/09 | decode 阶段自适应选择 CPU 核 | [MNN-AECS: Energy Optimization for LLM Decoding on Mobile Devices via Adaptive Core Selection](https://arxiv.org/abs/2506.19884) | NA | 分析显示, 受内存限制的 LLM 解码阶段在能耗中占主导地位, 然而, 大多数现有工作都集中在加速预填充阶段, 忽视了能效问题. 引入了自适应能效核心选择(AECS), 并将其集成到 MNN 中, 创建了能效版本 MNN-AECS, 这是首个无需 root 权限或操作系统修改即可实现能效 LLM 解码的引擎级系统解决方案. MNN-AECS 旨在通过动态选择低功耗 CPU 核, 在保持解码速度在可接受的减速阈值内的同时, 降低 LLM 解码的能耗. 作者在 5 款安卓设备和 2 款 iOS 设备上, 对 5 种不同规模的流行 LLM 进行了 MNN-AECS 评估. 与原始 MNN 相比, MNN-AECS 在所有 7 款设备和 4 个数据集上的平均能耗降低了 23%, 且速度没有减慢. 与其他引擎(包括 llama.cpp、executorch、mllm 和 MediaPipe)相比, MNN-AECS 平均能节省 39% 至 78% 的能耗, 并实现 12% 至 363% 的速度提升. | | 2025/10 | Xsched 异构调度 | [支持 NPU 算力切分](https://gitee.com/openeuler/kernel/issues/IC5EHB) | openEuler | 基于 ARM64 + 910B 实现的 NPU 卡支持算力时分抢占特性, 支持 NPU share、带宽管控等特性.
算力时分抢占: 通过 AI 任务的算力抽象, 构建异构时分调度机制, 实现异构多任务毫秒级抢占, 多推理单卡调度抢占小于 10 毫秒;
算力带宽管控: 基于算力带宽标准化语义, 构建任务级的算力管控分配机制, 实现算力隔离与共享, 提升吞吐. | -| 2025/10 | GPU eBPF profiling | NA | NA | |[知乎--云微--GPU可观测性差距：为什么我们需要GPU上的eBPF](https://zhuanlan.zhihu.com/p/1962141761364301211), [迈向可编程观测：在GPU Kernel中构建类eBPF风格的性能探针](https://developer.aliyun.com/article/1681315), [Neutrino: Fine-grained GPU Kernel Profiling via Programmable Probing, OSDI '25](https://github.com/open-neutrino/neutrino) | +| 2025/10 | GPU eBPF profiling | NA | NA | |[知乎--云微--GPU可观测性差距: 为什么我们需要GPU上的eBPF](https://zhuanlan.zhihu.com/p/1962141761364301211), [迈向可编程观测: 在GPU Kernel中构建类eBPF风格的性能探针](https://developer.aliyun.com/article/1681315), [Neutrino: Fine-grained GPU Kernel Profiling via Programmable Probing, OSDI '25](https://github.com/open-neutrino/neutrino) | +| 2026/02 | [AgenticOS 2026, AgentCgroup: Understanding and Controlling OS Resources of AI Agents](https://arxiv.org/abs/2602.09345) | [AgenticOS 2026, AgentCgroup: Understanding and Controlling OS Resources of AI Agents]() | 这篇论文最有价值的地方, 不是单纯提出了一个叫 AgentCgroup 的新机制, 而是先用实验把一个长期被忽略的问题讲清楚了: 对于 AI coding agent 这类工作负载, 真正拖慢任务完成时间、真正限制并发密度、真正导致资源治理失效的, 已经不只是模型推理本身, 而是 Agent 在沙箱里不断调用工具、启动子进程、运行测试、安装依赖、反复重试 这一整套 OS execution path. 换句话说, Agent 问题已经不是"只要把模型换强一点就行", 而是"执行系统本身已经成为瓶颈". [mm: memcontrol: Add BPF hooks for memory controller](https://lore.kernel.org/linux-mm/cover.1770194182.git.zhuhui@kylinos.cn), [AgentCgroup: 理解与控制AI代理的操作系统资源](https://www.alphaxiv.org/zh/overview/2602.09345v2) [](https://github.com/eunomia-bpf/agentcgroup), [CSDN 博客--山河已无恙--AgentCgroup论文学习: AI Agent为什么需要新的OS资源控制](https://blog.csdn.net/sanhewuyang/article/details/159995329), [[论文评述] AgentCgroup: Understanding and Controlling OS Resources of AI Agents](https://www.themoonlight.io/zh/review/agentcgroup-understanding-and-controlling-os-resources-of-ai-agents) | -## 1.3 AI Tools +## 1.3 AgentOS +------- + +| 日期 | 概要 | 论文 / 链接 | 团队 | 描述 | +|:---:|:----:|----------:|:----:|:----:| +| 2026/07/26 | 提出 Agent 时代需要"Agent 操作系统", 像 POSIX 之于经典 OS、Kubernetes 之于云那样, 规定一套共识抽象. | [Towards an Agent Operating System - Lessons from Classical and Cloud OS](https://arxiv.org/abs/2607.25076) | Gosia Steinder, Hubertus Franke(IBM Research) | 本文提出: Agent 时代正处于 POSIX 出现前夜, 业界需要像 POSIX 统一经典操作系统、Kubernetes 统一云那样, 通过"语义差距"方法论从经典原语推导出 13 个 Agent-OS 原语并精确规定其语义, 才能让 Agent 应用可移植、平台可组合——并已在开源项目 rossoctl 中实现其中一部分. | + + +## 1.4 AI Tools ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | diff --git a/study/ai/TRANSFORMER.MD b/study/ai/TRANSFORMER.MD index bf78255..dd32988 100644 --- a/study/ai/TRANSFORMER.MD +++ b/study/ai/TRANSFORMER.MD @@ -54,7 +54,7 @@ blogexcerpt: 虚拟化 & KVM 子系统 华擎的 AI QuickSet WSL 旨在通过 WSL 下的自动 ROCm 设置以及安装/配置流行的 AI 软件包以在 WSL+ROCm 下加速执行, 从而轻松"在 Windows 上运行 Linux AI 应用程序". 参见 [phoronix, 2025/09/15, ASRock AI Quickset WSL Aims To Make It Easier Running ROCm + AI Linux Apps On Windows](https://www.phoronix.com/news/ASRock-AI-QuickSet-WSL) -[知乎--机器之心--跟不上、读不完？上万篇顶会论文，这个工具一键分析](https://zhuanlan.zhihu.com/p/1968619277394346770) +[知乎--机器之心--跟不上、读不完？上万篇顶会论文, 这个工具一键分析](https://zhuanlan.zhihu.com/p/1968619277394346770) # 2 模型 @@ -65,11 +65,11 @@ blogexcerpt: 虚拟化 & KVM 子系统 ------- -[2025 年大模型与 Transformer 架构：重塑 AI 未来的科技革命](https://blog.csdn.net/lifetragedy/article/details/146948744) +[2025 年大模型与 Transformer 架构: 重塑 AI 未来的科技革命](https://blog.csdn.net/lifetragedy/article/details/146948744) [Mamba 详细介绍和 RNN、Transformer 的架构可视化对比](https://blog.csdn.net/deephub/article/details/136250003) -[机器之心 - 盘一盘，2017 年 Transformer 之后，LLM 领域的重要论文](https://www.jiqizhixin.com/articles/2025-06-29-4) +[机器之心 - 盘一盘, 2017 年 Transformer 之后, LLM 领域的重要论文](https://www.jiqizhixin.com/articles/2025-06-29-4) | 编号 | 结构 | 描述 | @@ -77,7 +77,7 @@ blogexcerpt: 虚拟化 & KVM 子系统 | 1 | Transformer | NA | | 2 | Mamba | 线性复杂度的新星
Mamba 利用结构化空间状态对偶 (SSD/Structured Space-State Duality) 构建了一个稳健的理论框架, 使得原本为 Transformer 开发的算法和系统优化技术能够迁移应用于 SSM. Mamba 架构以其线性增长的低计算开销和硬件感知型算法, 在处理长序列数据方面表现出色, 显著提升了计算速度和性能. 与 Transformer 相比, Mamba 的计算开销随序列长度线性增长, 这使得它能够处理更长的文本序列, 同时大幅降低计算成本.
在 A100 GPU 上, Mamba 使用扫描进行循环计算, 能够将计算速度提升 3 倍. 不过, Mamba 架构也存在一些问题, 如记忆丢失、难以泛化到不同任务、在复杂模式方面的表现不及基于 Transformer 的语言模型等. | | 3 | RWKV | RNN 变体的新突破
RWKV 是循环神经网络 (RNN) 的一个创新变体. 它的架构由一系列堆叠的残差块组成, 每个残差块包含具有循环结构的时间混合 (time-mixing) 和通道混合 (channel-mixing) 子块. RWKV 采用了动态状态演化(Dynamic State Evolution), 具备恒定的显存占用、恒定的推理生成速度以及 "无限" 的上下文长度, 完全不含自注意力机制.
然而, RWKV 基底模型对提示词(prompt) 的格式非常敏感, 提示词的格式对生成结果有较大影响. 并且由于架构设计的原因, RWKV 模型在需要回顾的任务上表现较弱. | -| 4 | Hyena | 高效低复杂度的全新尝试
Hyena 由两个高效的二次基元递归定义的算子, 交织隐式参数化的长卷积和数据控制的门控组成, 构建了一个高效、灵活且计算复杂度低的注意力替代算法. Hyena 的时间复杂度为 O(n*log(n)), 远低于 Transformer 的 O(n²).
在实际应用中, Hyena 能够显著缩小与注意力机制的差距. 当序列长度为 64K 时, Hyena 算子的速度是高度优化注意力的 100 倍. 不过, Hyena 运算不支持 Mas, ，这使得使用 Hyena 架构进行生成式预训练建模时不够灵活. | +| 4 | Hyena | 高效低复杂度的全新尝试
Hyena 由两个高效的二次基元递归定义的算子, 交织隐式参数化的长卷积和数据控制的门控组成, 构建了一个高效、灵活且计算复杂度低的注意力替代算法. Hyena 的时间复杂度为 O(n*log(n)), 远低于 Transformer 的 O(n²).
在实际应用中, Hyena 能够显著缩小与注意力机制的差距. 当序列长度为 64K 时, Hyena 算子的速度是高度优化注意力的 100 倍. 不过, Hyena 运算不支持 Mas, , 这使得使用 Hyena 架构进行生成式预训练建模时不够灵活. | | 5 | Difussion | Difussion Language Model | @@ -89,7 +89,7 @@ blogexcerpt: 虚拟化 & KVM 子系统 | 编号 | 日期 | 模型 | 团队 | 详情 | |:---:|:---:|:----:|:---:|:----:| -| 1 | 2025/08/12 | [Lumina-mGPT 2.0](https://github.com/Alpha-VLLM/Lumina-mGPT-2.0) | 上海人工智能实验室 | [Lumina-mGPT 2.0: Stand-Alone AutoRegressive Image Modeling](https://arxiv.org/pdf/2507.17801), 上海人工智能实验室等团队提出 Lumina-mGPT 2.0, 一款独立的、仅使用解码器的自回归模型, 统一了包括文生图、图像对生成、主体驱动生成、多轮图像编辑、可控生成和密集预测在内的广泛任务. 参见 机器之心报道 [机器之心 - 自回归模型华丽复兴，媲美顶尖扩散模型](https://www.jiqizhixin.com/articles/2025-08-12). | +| 1 | 2025/08/12 | [Lumina-mGPT 2.0](https://github.com/Alpha-VLLM/Lumina-mGPT-2.0) | 上海人工智能实验室 | [Lumina-mGPT 2.0: Stand-Alone AutoRegressive Image Modeling](https://arxiv.org/pdf/2507.17801), 上海人工智能实验室等团队提出 Lumina-mGPT 2.0, 一款独立的、仅使用解码器的自回归模型, 统一了包括文生图、图像对生成、主体驱动生成、多轮图像编辑、可控生成和密集预测在内的广泛任务. 参见 机器之心报道 [机器之心 - 自回归模型华丽复兴, 媲美顶尖扩散模型](https://www.jiqizhixin.com/articles/2025-08-12). | #### 2.1.1.1 模型汇总 ------- @@ -150,29 +150,31 @@ blogexcerpt: 虚拟化 & KVM 子系统 [Diffusion LLMs (dLLMs): Introducing a New Generation of LLMs](https://markovate.com/diffusion-llms) -[近500页史上最全扩散模型修炼宝典，宋飏等人一书覆盖三大主流视角](https://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw==&mid=2650998605&idx=2&sn=84f6cb3603ca32053d0e2d84027bdf2c&poc_token=HD-2BWmje61whwOTJBJqElN1O1DNsNJpYNxbUqu3) +[近500页史上最全扩散模型修炼宝典, 宋飏等人一书覆盖三大主流视角](https://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw==&mid=2650998605&idx=2&sn=84f6cb3603ca32053d0e2d84027bdf2c&poc_token=HD-2BWmje61whwOTJBJqElN1O1DNsNJpYNxbUqu3) | 编号 | 日期 | 模型 | 团队 | 详情 | |:---:|:---:|:----:|:---:|:----:| -| 1 | 2025/02/14 | [LLaDA-8B](https://ml-gsai.github.io/LLaDA-demo) | ml-gsai | 参见论文 [Large Language Diffusion Models](Large Language Diffusion Models](https://arxiv.org/abs/2502.09992), [论文 | 2025 | 论文综述：大型语言扩散模型(LLDM)](https://mp.weixin.qq.com/s/W8lLo6BI1xKkj_1HfiH5pg) | -| 2 | 2025/03/02 | [Mercury](https://www.inceptionlabs.ai/introducing-mercury) | Inception Labs | [扩散模型驱动的下一代 LM 范式：Diffusion LLM - Mercury，“飞一般的生成速度”](https://zhuanlan.zhihu.com/p/26844666590) | -| 3 | 2025/03/06 | GIDD | NA | [Generalized Interpolating Discrete Diffusion](https://arxiv.org/abs/2503.04482), [AI 自我纠错，Diffusion 超越自回归！质量提升 55%，已达理论证据下界](https://mp.weixin.qq.com/s/pu2NmYixfwZq94qFDBZ_YQ) | +| 1 | 2025/02/14 | [LLaDA-8B](https://ml-gsai.github.io/LLaDA-demo) | ml-gsai | 参见论文 [Large Language Diffusion Models](Large Language Diffusion Models](https://arxiv.org/abs/2502.09992), [论文 | 2025 | 论文综述: 大型语言扩散模型(LLDM)](https://mp.weixin.qq.com/s/W8lLo6BI1xKkj_1HfiH5pg) | +| 2 | 2025/03/02 | [Mercury](https://www.inceptionlabs.ai/introducing-mercury) | Inception Labs | [扩散模型驱动的下一代 LM 范式: Diffusion LLM - Mercury, “飞一般的生成速度”](https://zhuanlan.zhihu.com/p/26844666590) | +| 3 | 2025/03/06 | GIDD | NA | [Generalized Interpolating Discrete Diffusion](https://arxiv.org/abs/2503.04482), [AI 自我纠错, Diffusion 超越自回归！质量提升 55%, 已达理论证据下界](https://mp.weixin.qq.com/s/pu2NmYixfwZq94qFDBZ_YQ) | | 4 | 2025/03/12 | [BD3-LMs](https://m-arriola.com/bd3lms/) | Cornell Tech | 论文 [Block Diffusion: Interpolating Between Autoregressive and Diffusion Language Models](https://arxiv.org/abs/2503.09573), [爆火 Block Diffusion 引发 LLM 架构变革？自回归 + 扩散模型完美结合 | ICLR 2025](https://zhuanlan.zhihu.com/p/32576344984) | | 5 | 2025/04/02 | [Dream-7B](https://hkunlp.github.io/blog/2025/dream/) | University of Hong Kong
Huawei Noah’s Ark Lab | 参见 GitHub [HKUNLP/Dream](https://github.com/HKUNLP/Dream) | | 6 | 2025/04/12 | [D1](https://dllm-reasoning.github.io) | UCLA
Meta AI | [dllm-reasoning/d1](https://github.com/dllm-reasoning/d1), 参见论文 [d1: Scaling Reasoning in Diffusion Large Language Models via Reinforcement Learning](https://arxiv.org/abs/2504.12216) | | 7 | 2024/10/24 | [SMDM](https://github.com/ML-GSAI/SMDM) | ML-GSAI | [Scaling up Masked Diffusion Models on Text](https://arxiv.org/abs/2410.18514) | -| 8 | 2024/10/24 | [Seed Diffusion](https://seed.bytedance.com/seed_diffusion) | ML-GSAI | [技术报告](https://lf3-static.bytednsdoc.com/obj/eden-cn/hyvsmeh7uhobf/sdiff_updated.pdf)
[项目地址](https://seed.bytedance.com/seed_diffusion)
[体验链接](https://studio.seed.ai/exp/seed_diffusion)
[量子位 - 字节 Seed 发布扩散语言模型，推理速度达 2146 tokens/s，比同规模自回归快 5.4 倍](https://qbitai.com/2025/08/316722.html) | -| 9 | 2025/08/08 | [DAEDAL](https://github.com/Li-Jinsong/DAEDAL) |[Beyond Fixed: Variable-Length Denoising for Diffusion Large Language Models](https://arxiv.org/abs/2508.00819) | 当前 DLLM 存在着在推理时必须采用预设固定长度的限制, 对于不同任务都需要专门调整才能达到最优效果.
为了解决这一本质的问题, 香港中文大学 MMLab, 上海 AI 实验室等提出 DAEDAL, 赋予 DLLM 可以根据问题的具体情况自主调整回答长度的能力, 弥补了 DLLM 与自回归 LLM 的关键差距, 为更灵活、高效、强大的扩散大语言模型打下了基石.
DAEDAL 作为一种 Training Free 的去噪策略, 从一个统一且很短的初始长度开始, 让模型根据自己的需求在生成中调节长度, 动态扩展, 达到了和现有去噪策略在每个评测基准上精心调整生成长度得到的最佳性能相当的表现, 有时甚至更胜一筹. 参见 [机器之心 -- 扩散 LLM 推理新范式：打破生成长度限制，实现动态自适应调节](https://www.jiqizhixin.com/articles/2025-08-08-5). | -| 10 | 2025/08/14 | [Discrete Diffusion Forcing(D2F)](https://arxiv.org/abs/2508.09192) | 上海交通大学 DENG Lab 联合 UCSD | [D2F：首个推理速度超过自回归的开源扩散语言模型](https://zhuanlan.zhihu.com/p/1939283118306604733) | -| 11 | 2025/09/14 | [LLaDA-MoE-7B](https://huggingface.co/inclusionAI/LLaDA-MoE-7B-A1B-Base) | 蚂蚁&人大 | [扩散语言模型也有 MoE 版本了！蚂蚁&人大从头训练 LLaDA-MoE，即将完全开源 ｜ 机器之心](https://www.bestblogs.dev/article/e6ee1e), LLaDA-MoE 有两个版本: 基础模型版 LLaDA-MoE-7B-A1B-Base 和指令微调版 LLaDA-MoE-7B-A1B-Instruct. | +| 8 | 2024/10/24 | [Seed Diffusion](https://seed.bytedance.com/seed_diffusion) | ML-GSAI | [技术报告](https://lf3-static.bytednsdoc.com/obj/eden-cn/hyvsmeh7uhobf/sdiff_updated.pdf)
[项目地址](https://seed.bytedance.com/seed_diffusion)
[体验链接](https://studio.seed.ai/exp/seed_diffusion)
[量子位 - 字节 Seed 发布扩散语言模型, 推理速度达 2146 tokens/s, 比同规模自回归快 5.4 倍](https://qbitai.com/2025/08/316722.html) | +| 9 | 2025/08/08 | [DAEDAL](https://github.com/Li-Jinsong/DAEDAL) |[Beyond Fixed: Variable-Length Denoising for Diffusion Large Language Models](https://arxiv.org/abs/2508.00819) | 当前 DLLM 存在着在推理时必须采用预设固定长度的限制, 对于不同任务都需要专门调整才能达到最优效果.
为了解决这一本质的问题, 香港中文大学 MMLab, 上海 AI 实验室等提出 DAEDAL, 赋予 DLLM 可以根据问题的具体情况自主调整回答长度的能力, 弥补了 DLLM 与自回归 LLM 的关键差距, 为更灵活、高效、强大的扩散大语言模型打下了基石.
DAEDAL 作为一种 Training Free 的去噪策略, 从一个统一且很短的初始长度开始, 让模型根据自己的需求在生成中调节长度, 动态扩展, 达到了和现有去噪策略在每个评测基准上精心调整生成长度得到的最佳性能相当的表现, 有时甚至更胜一筹. 参见 [机器之心 -- 扩散 LLM 推理新范式: 打破生成长度限制, 实现动态自适应调节](https://www.jiqizhixin.com/articles/2025-08-08-5). | +| 10 | 2025/08/14 | [Discrete Diffusion Forcing(D2F)](https://arxiv.org/abs/2508.09192) | 上海交通大学 DENG Lab 联合 UCSD | [D2F: 首个推理速度超过自回归的开源扩散语言模型](https://zhuanlan.zhihu.com/p/1939283118306604733) | +| 11 | 2025/09/14 | [LLaDA-MoE-7B](https://huggingface.co/inclusionAI/LLaDA-MoE-7B-A1B-Base) | 蚂蚁&人大 | [扩散语言模型也有 MoE 版本了！蚂蚁&人大从头训练 LLaDA-MoE, 即将完全开源 ｜ 机器之心](https://www.bestblogs.dev/article/e6ee1e), LLaDA-MoE 有两个版本: 基础模型版 LLaDA-MoE-7B-A1B-Base 和指令微调版 LLaDA-MoE-7B-A1B-Instruct. | | 12 | 2025/10/12 | [RND1-Base](https://github.com/RadicalNumerics/RND1) | Radical Numerics | RND1-Base 是 Radical Numerics 团队开发的 30B 参数扩散语言模型, 通过预训练的AR 模型转换生成扩散模型, 突破了传统扩散模型需要从零训练的局限. 采用稀疏混合专家模型架构, 由 3B 激活参数组成, 通过预训练的 AR 模型转换而来, 并在持续训练中累积了 500B 个 token 数据. 该模型在生成效果上实现了完整的扩散行为, 并同步开源了训练配方、推理代码及样例输出. | | 13 | 2025/11/23 | [dLLM: Simple Diffusion Language Modeling](https://github.com/ZHZisZZ/dllm) | 伯克利与 UIUC 团队基于自研的扩散语言模型工具 dLLM, 做了一个简单的实验: 让 BERT 通过离散扩散学会对话. 结果远超预期 —— 无需生成式预训练, 仅约 50 GPU 小时的监督微调, ModernBERT-large-chat-v0(0.4B 参数)在多项任务中的表现已逼近 Qwen1.5-0.5B, 证明「离散扩散 + 轻量级指令微调」即可赋予经典 BERT 强生成能力, 为社区提供了真正高效、低成本的方案. [项目报告](https://wandb.ai/asap-zzhou/dllm/reports/dLLM-BERT-Chat--VmlldzoxNDg0MzExNg), [项目模型](https://huggingface.co/collections/dllm-collection/bert-chat). 参见 [微信公众号-机器之心-通用的 dLLM 开发框架, 让 BERT 掌握扩散式对话](https://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw==&mid=2651003281&idx=3&sn=96891b328d3f36ae61a94cc85af6bf84&poc_token=HLT_Jmmjho01GZClV-kVzqxtwq5txGcA1IF8hj23) | -| 14 | 2026/01/15 | DLCM | 字节 Seed | [Dynamic Large Concept Models: Latent Reasoning in an Adaptive Semantic Space](https://arxiv.org/abs/2512.24617) 将大模型的推理单位从 token(词) 动态且自适应地推到了 concept(概念) 层级. [字节Seed：大概念模型来了，推理的何必是下一个token](https://www.qbitai.com/2026/01/366544.html). | +| 14 | 2026/01/15 | DLCM | 字节 Seed | [Dynamic Large Concept Models: Latent Reasoning in an Adaptive Semantic Space](https://arxiv.org/abs/2512.24617) 将大模型的推理单位从 token(词) 动态且自适应地推到了 concept(概念) 层级. [字节Seed: 大概念模型来了, 推理的何必是下一个token](https://www.qbitai.com/2026/01/366544.html). | +| 15 | 2026/04/15 | [Generative Refinement Networks for Visual Synthesis](ttps://arxiv.org/abs/2604.13030) | 扩散模型虽然生成质量高, 但不够智能. 它对所有样本, 无论复杂与否, 都分配相同的迭代步数, 缺乏自适应能力.
自回归模型: 通过似然估计, 天然具有复杂度感知能力. 但一方面, 受限于离散 token 化, 存在严重的信息损失. 另一方面, 存在误差累计和误差传播的问题, 早期错误无法修正, 于是越错越离谱. 论文中 GRN 则是对二者的扬长补短, 同时兼顾全局精调和内容复杂度感知. 其核心架构包括三个部分: ① 层次二叉树量化(HBQ), ② 全局精炼网络(GRN), ③ 复杂度感知采样. 参见 [2026/05/13, 量子化--挑战扩散自回归统治！字节提出视觉生成第三种路线, 让模型像人类一样边画边改](https://www.qbitai.com/2026/05/416978.html) +| 16 | 2026/05/18 | [chiennv2000/orthrus](https://github.com/chiennv2000/orthrus) | NA | 打破 LLM 自回归顺序生成的瓶颈, 用双架构扩散模型实现并行 token 生成, 在保证输出完全无损的前提下将推理速度提升 4-7.8 倍. Orthrus 给现有的 LLM 加了一个扩散解码的"并行视图". 两个视图读同一份 KV 缓存, 不需要重复存上下文, 内存开销可以忽略. 基座模型冻结不动, 只微调 16% 的参数就能跑起来. 实测在 Qwen3 的三个尺寸上平均加速 4-5 倍, 最高 7.8 倍. 比投机解码的接受率更高, 比别的扩散语言模型在数学推理等任务上没有精度损失. | | 编号 | 日期 | 框架 | 团队 | 详情 | |:---:|:---:|:----:|:---:|:----:| -| 1 | 2025/10/09 | [dInfer: An Efficient Inference Framework for Diffusion Language Models](https://arxiv.org/abs/2510.08666) | 蚂蚁集团 | dInfer 是一个用于 dLLM 推理的高效且可扩展的框架. 将推理管道分解为四个模块化组件--模型、扩散迭代管理器、解码策略和 KV 缓存管理器--并为每个组件集成了新颖的算法以及系统级优化. 通过算法创新和系统增强的结合, dInfer 在不影响 LLaDA-MoE 输出质量的情况下实现了显着的效率提升. 与以前的系统相比，dInfer 比 Fast-dLLM 更快, 同时保持相似的模型性能. 即使与采用最新 vLLM 推理引擎高度优化的自回归(Autoregressive, AR)模型(激活参数和性能相当) QWen2.5-3B 相比, dInfer 仍然能加速. 代码开源 [inclusionAI/dInfer](https://github.com/inclusionAI/dInfer). | +| 1 | 2025/10/09 | [dInfer: An Efficient Inference Framework for Diffusion Language Models](https://arxiv.org/abs/2510.08666) | 蚂蚁集团 | dInfer 是一个用于 dLLM 推理的高效且可扩展的框架. 将推理管道分解为四个模块化组件--模型、扩散迭代管理器、解码策略和 KV 缓存管理器--并为每个组件集成了新颖的算法以及系统级优化. 通过算法创新和系统增强的结合, dInfer 在不影响 LLaDA-MoE 输出质量的情况下实现了显着的效率提升. 与以前的系统相比, dInfer 比 Fast-dLLM 更快, 同时保持相似的模型性能. 即使与采用最新 vLLM 推理引擎高度优化的自回归(Autoregressive, AR)模型(激活参数和性能相当) QWen2.5-3B 相比, dInfer 仍然能加速. 代码开源 [inclusionAI/dInfer](https://github.com/inclusionAI/dInfer). | | 2 | 2025/07/03 | [Fast-dLLM: Training-free Acceleration of Diffusion LLM by Enabling KV Cache and Parallel Decoding](https://arxiv.org/abs/2505.22618) | NVIDIA 联合香港大学、MIT | 通过创新的分块KV缓存和置信度感知并行解码技术, 无需训练即可实现扩散模型 27.6 倍推理加速, 同时保持生成质量损失小于 2%, 为实时交互和长文本生成场景带来突破性解决方案.
1. 分块 KV 缓存(Block-Wise KV Cache): 激活重用率超 90% 的双向加速.
2. 置信度感知并行解码(Confidence-Aware Parallel Decoding). [博客](https://nvlabs.github.io/Fast-dLLM), [代码](https://github.com/NVlabs/Fast-dLLM) | @@ -186,11 +188,11 @@ blogexcerpt: 虚拟化 & KVM 子系统 MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Adaptive Mixture of Local Experts](https://www.cs.toronto.edu/~hinton/absps/jjnh91.pdf) 提出 MoE. -[群魔乱舞：MoE 大模型详解](https://www.zhihu.com/tardis/bd/art/677638939) +[群魔乱舞: MoE 大模型详解](https://www.zhihu.com/tardis/bd/art/677638939) -[【论文阅读】MOE，《OUTRAGEOUSLY LARGE NEURAL NETWORKS: THE SPARSELY-GATED MIXTURE-OF-EXPERTS LAYER》](https://blog.csdn.net/bylander/article/details/138139345) +[【论文阅读】MOE, 《OUTRAGEOUSLY LARGE NEURAL NETWORKS: THE SPARSELY-GATED MIXTURE-OF-EXPERTS LAYER》](https://blog.csdn.net/bylander/article/details/138139345) -[【论文速读】MOD，《Mixture-of-Depths: Dynamically allocating compute in transformer-based language models》](https://blog.csdn.net/bylander/article/details/139536003) +[【论文速读】MOD, 《Mixture-of-Depths: Dynamically allocating compute in transformer-based language models》](https://blog.csdn.net/bylander/article/details/139536003) [Mixture of Depths 论文解读](https://zhuanlan.zhihu.com/p/691324301) @@ -201,8 +203,8 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 编号 | 日期 | 模型/论文 | 团队 | 详情 | |:---:|:---:|:---------:|:---:|:----:| | 1 | 2025/03 | [Mixture of Lookup Experts](https://arxiv.org/abs/2503.15798) | NA | 由于 MoE 会动态选择 experts, 因此所有 EA 都需要加载到 VRAM 中. 它们的大参数大小仍然限制了部署, 而卸载 (仅在需要时将专家加载到 VRAM) 会显著增加推理延迟. 为了解决这个问题, 我们提出了 Mix of Lookup Experts(MoLE), 这是一种新的 MoE 架构, 在通信和 VRAM 使用方面都非常高效. 在 MoLE 中, 专家在训练期间是前馈网络(FFN), 将嵌入层的输出作为输入. 在推理之前, 这些专家可以重新参数化为查找表(LUT), 该查找表根据输入 ID 检索专家输出, 并卸载到存储设备. 因此, 我们不需要在推理过程中执行专家计算. 相反, 我们根据输入 ID 直接检索 EA 的计算结果并将其加载到 VRAM 中, 因此由此产生的通信开销可以忽略不计. 实验表明, 在相同的 FLOPs 和 VRAM 使用量下, MoLE 实现了与密集模型相当的推理速度, 并且在专家卸载的情况下明显快于 MoE, 同时保持与 MoE 相当的性能. | -| 2 | 2025/09 | [Qwen3-Next](https://huggingface.co/collections/Qwen/qwen3-next-68c25fd6838e585db8eeea9d) | 阿里 | [全新MoE架构！阿里开源Qwen3-Next，训练成本直降9成](https://www.jiqizhixin.com/articles/2025-09-12-2), 其模型结构相较 4 月底推出的 Qwen3 的 MoE 模型新增了多种技术并进行了核心改进, 包括混合注意力机制、高稀疏度 MoE 结构、一系列提升训练稳定性的优化, 以及提升推理效率的多 token 预测(MTP)机制等. | -| 3 | 2025/10 | [Expert-as-a-Service: Towards Efficient, Scalable, and Robust Large-scale MoE Serving](https://arxiv.org/abs/2509.17863) | NA | MoE 中的专家调用是动态稀疏的, 哪个专家被激活取决于输入内容, 在不同的工作负载下被激活的分布有很大区别. 固定的专家映射和资源分配策略难以适应这种波动. 某些专家所在 GPU 因频繁命中而过载, 而其他专家节点长期闲置, 造成资源利用低下. 通过观察, 作者发现这些问题其实有共同的根本原因: 整个系统被当作一个庞大的 "有状态整体" 去管理. 事实上, 专家层本质上是无状态的, 它对输入执行纯函数计算, 不依赖历史上下文. 作者利用这一特性, 将专家层的计算抽象为独立的无状态服务, 与维护 KV 缓存的 Attention 前端解耦部署. 尽管近期也有研究尝试解耦 Attention 层与专家层、按不同组件拆分部署, 但仍未根本解决伸缩僵化、大规模容错等问题. 为此, 本文作者提出了一种全新的 MoE 模型推理系统——Expert-as-a-Service(EaaS), 旨在通过架构层面的创新来提升大规模 MoE 推理的效率、扩展性和鲁棒性. 参见 [知乎--机器之心--为MoE解绑：全新「专家即服务」推理架构发布，超细粒度扩展锐减37.5%成本](https://zhuanlan.zhihu.com/p/1961085349108364663) | +| 2 | 2025/09 | [Qwen3-Next](https://huggingface.co/collections/Qwen/qwen3-next-68c25fd6838e585db8eeea9d) | 阿里 | [全新MoE架构！阿里开源Qwen3-Next, 训练成本直降9成](https://www.jiqizhixin.com/articles/2025-09-12-2), 其模型结构相较 4 月底推出的 Qwen3 的 MoE 模型新增了多种技术并进行了核心改进, 包括混合注意力机制、高稀疏度 MoE 结构、一系列提升训练稳定性的优化, 以及提升推理效率的多 token 预测(MTP)机制等. | +| 3 | 2025/10 | [Expert-as-a-Service: Towards Efficient, Scalable, and Robust Large-scale MoE Serving](https://arxiv.org/abs/2509.17863) | NA | MoE 中的专家调用是动态稀疏的, 哪个专家被激活取决于输入内容, 在不同的工作负载下被激活的分布有很大区别. 固定的专家映射和资源分配策略难以适应这种波动. 某些专家所在 GPU 因频繁命中而过载, 而其他专家节点长期闲置, 造成资源利用低下. 通过观察, 作者发现这些问题其实有共同的根本原因: 整个系统被当作一个庞大的 "有状态整体" 去管理. 事实上, 专家层本质上是无状态的, 它对输入执行纯函数计算, 不依赖历史上下文. 作者利用这一特性, 将专家层的计算抽象为独立的无状态服务, 与维护 KV 缓存的 Attention 前端解耦部署. 尽管近期也有研究尝试解耦 Attention 层与专家层、按不同组件拆分部署, 但仍未根本解决伸缩僵化、大规模容错等问题. 为此, 本文作者提出了一种全新的 MoE 模型推理系统——Expert-as-a-Service(EaaS), 旨在通过架构层面的创新来提升大规模 MoE 推理的效率、扩展性和鲁棒性. 参见 [知乎--机器之心--为MoE解绑: 全新「专家即服务」推理架构发布, 超细粒度扩展锐减37.5%成本](https://zhuanlan.zhihu.com/p/1961085349108364663) | ### 2.2.2 稀疏化 ------- @@ -213,12 +215,22 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad #### 2.2.2.1 动态剪枝 ------- +##### 2.2.2.1.1 Dense 模型减枝方案 +------- + | 编号 | 技术 | 团队 | 介绍 | |:---:|:----:|:---:|:---:| | 1 | [D-LLM: A Token Adaptive Computing Resource Allocation Strategy for Large Language Models](https://blog.csdn.net/paixiaoxin/article/details/145521305) | Huawei | 本文提出了一种名为 D-LLM 的新型动态推理机制, 旨在为大型语言模型 (LLMs) 自适应地分配计算资源. 当前, LLMs 对每个词元的处理是等同的, 但作者认为并非所有词语都同等重要, 某些词语在简单问题中并不需要过多的计算资源. D-LLM 通过为每个 Transformer 层设计动态决策模块, 决定是否执行或跳过该层, 从而提高推理速度. 此外, 本文还提出了一种有效的驱逐策略, 以解决跳过层时 KV 缓存缺失的问题. 实验结果表明, D-LLM 在问答、摘要和数学解题任务中可减少高达 45% 的计算成本和 KV 存储, 在常识推理任务中可减少 50%, 且性能未受影响. | -| 2 | [Mixture-of-Recursions: Learning Dynamic Recursive Depths for Adaptive Token-Level Computation](https://arxiv.org/abs/2507.10524) | KAIST、谷歌 DeepMind 等 | 提出了一种在统一的架构中, MoR 同时实现了三种效率优化
1. 参数共享: 通过共享权重压缩参数量, 减小模型体积, 如同让模型学会 "一法通、万法通";
2. 自适应计算: 不对所有 token 一视同仁, 让模型根据任务的难易度动态调整计算量 (推理时递归的深度)，好比 "好钢用在刀刃上", 通过小型路由器, 会为每个 token 的隐藏状态打分, 仅高分 token 的会继续循环, 其余的则提前退出. 简单 Token(比如标点, 常见字" 的 "," 在 "等) 仅需单次递归即可推出, 复杂 Token(比如数学符号, 专业术语等)会递归多层进行计算, 通过动态路由机制, MoR 让模型真正实现了「千人千面」的计算: 每个 Token 都能根据自己的实际需求, 获得恰到好处的「思考」深度, 从而大幅削减了不必要的计算开销.
3. 通过智能缓存减少内存开销: KV 缓存是 Transformer 推理时的内存大户, 尤其是在处理长序列和进行大批量推理时. 在动态深度模型中, 由于 Token 可能在不同深度退出, 如何确保缓存的一致性和效率, MoR 设计了两种针对性的 KV 缓存策略, 为不同的部署场景提供了灵活的选择. 无论是追求极致精度与批处理量, 还是追求极致内存节省与预填充速度, MoR 都能提供相应的优化方案.
[知乎 - 新智元 - Transformer 终结者！谷歌 DeepMind 全新 MoR 架构问世，新一代魔王来了](https://zhuanlan.zhihu.com/p/1929192855898951941)
[知乎 - tomsheep-MoR：共享 + 路由 + 缓存，递归混合模型为 LLM 瘦身](https://zhuanlan.zhihu.com/p/1929159784982086816)
[知乎 - 北方的郎 - 混合递归（MoR）：让大模型“量体裁衣”，为每个词元智能分配思考深度](https://zhuanlan.zhihu.com/p/1929175581800506290)
[github/mixture_of_recursions](https://github.com/raymin0223/mixture_of_recursions) | -| 3 | [CLONE: Customizing LLMs for Efficient Latency-Aware Inference at the Edge](https://arxiv.org/abs/2506.02847) | 澳门大学 | 边缘设备通常存在存储空间有限、计算能力弱等问题, 导致无法直接运行复杂语言模型. CLONE (Customizing LLMs for Efficient Latency-Aware Inference at the Edge) 是 澳门大学 团队开发的一种算法 - 硬件协同设计系统, 旨在解决在边缘设备上部署大型语言模型 (LLMs) 时面临的存储、计算资源限制问题. 该系统通过优化模型结构和硬件加速器设计, 平衡了延迟、能耗与模型精度, 并已在两种通用边缘平台上进行验证. 技术方案包括:
1. 硬件感知的模型剪枝优化: 通过剪枝、量化等技术减少模型体积和计算复杂度, 同时保持模型性能.
2. 硬件加速: 采用 28nm 工艺的专用硬件加速器, 进一步提升运算效率.
3. 在线延迟感知推理: 在算法层面融入实时优化和能量管理机制, 确保在低延迟场景中稳定运行. 使用基于请求的 MoE 路由器动态配置 Lora, 通过层间 DVFS 有效优化能效. +| 2 | [Mixture-of-Recursions: Learning Dynamic Recursive Depths for Adaptive Token-Level Computation](https://arxiv.org/abs/2507.10524) | KAIST、谷歌 DeepMind 等 | 提出了一种在统一的架构中, MoR 同时实现了三种效率优化
1. 参数共享: 通过共享权重压缩参数量, 减小模型体积, 如同让模型学会 "一法通、万法通";
2. 自适应计算: 不对所有 token 一视同仁, 让模型根据任务的难易度动态调整计算量 (推理时递归的深度), 好比 "好钢用在刀刃上", 通过小型路由器, 会为每个 token 的隐藏状态打分, 仅高分 token 的会继续循环, 其余的则提前退出. 简单 Token(比如标点, 常见字" 的 "," 在 "等) 仅需单次递归即可推出, 复杂 Token(比如数学符号, 专业术语等)会递归多层进行计算, 通过动态路由机制, MoR 让模型真正实现了「千人千面」的计算: 每个 Token 都能根据自己的实际需求, 获得恰到好处的「思考」深度, 从而大幅削减了不必要的计算开销.
3. 通过智能缓存减少内存开销: KV 缓存是 Transformer 推理时的内存大户, 尤其是在处理长序列和进行大批量推理时. 在动态深度模型中, 由于 Token 可能在不同深度退出, 如何确保缓存的一致性和效率, MoR 设计了两种针对性的 KV 缓存策略, 为不同的部署场景提供了灵活的选择. 无论是追求极致精度与批处理量, 还是追求极致内存节省与预填充速度, MoR 都能提供相应的优化方案.
[知乎 - 新智元 - Transformer 终结者！谷歌 DeepMind 全新 MoR 架构问世, 新一代魔王来了](https://zhuanlan.zhihu.com/p/1929192855898951941)
[知乎 - tomsheep-MoR: 共享 + 路由 + 缓存, 递归混合模型为 LLM 瘦身](https://zhuanlan.zhihu.com/p/1929159784982086816)
[知乎 - 北方的郎 - 混合递归(MoR): 让大模型“量体裁衣”, 为每个词元智能分配思考深度](https://zhuanlan.zhihu.com/p/1929175581800506290)
[github/mixture_of_recursions](https://github.com/raymin0223/mixture_of_recursions) | +| 3 | [CLONE: Customizing LLMs for Efficient Latency-Aware Inference at the Edge](https://arxiv.org/abs/2506.02847) | 澳门大学 | 边缘设备通常存在存储空间有限、计算能力弱等问题, 导致无法直接运行复杂语言模型. CLONE (Customizing LLMs for Efficient Latency-Aware Inference at the Edge) 是 澳门大学 团队开发的一种算法 - 硬件协同设计系统, 旨在解决在边缘设备上部署大型语言模型 (LLMs) 时面临的存储、计算资源限制问题. 该系统通过优化模型结构和硬件加速器设计, 平衡了延迟、能耗与模型精度, 并已在两种通用边缘平台上进行验证. 技术方案包括:
1. 硬件感知的模型剪枝优化: 通过剪枝、量化等技术减少模型体积和计算复杂度, 同时保持模型性能.
2. 硬件加速: 采用 28nm 工艺的专用硬件加速器, 进一步提升运算效率.
3. 在线延迟感知推理: 在算法层面融入实时优化和能量管理机制, 确保在低延迟场景中稳定运行. 使用基于请求的 MoE 路由器动态配置 Lora, 通过层间 DVFS 有效优化能效. | +##### 2.2.2.1.2 MoE 模型减枝方案 +------- + + +| 编号 | 技术 | 团队 | 介绍 | +|:---:|:----:|:---:|:---:| +| 1 | [2025/01/03, Instruction-Following Pruning for Large Language Models](https://arxiv.org/abs/2501.02086) | Apple AI/ML(Bairu Hou, UC Santa Barbara) | IFPruning 用一个 302M 的稀疏预测器读用户指令, 为待剪枝 LLM 的每一层 FFN 动态生成可微 top-k 掩码, 在解码开始前一次性选定并缓存为稠密子网络. 把 9B LLM 剪到 3B 激活后, 性能逼近 9B 稠密模型、超过 3B 稠密模型 5–14 个百分点, TTFT 降低 57%、比同等激活量的 MoE 快约 5 倍——专为 on-device 推理设计. | #### 2.2.2.2 弹性推理 ------- @@ -226,7 +238,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 编号 | 技术 | 团队 | 介绍 | |:---:|:----:|:---:|:---:| | 1 | [Matryoshka Representation Learning](https://arxiv.org/abs/2205.13147) | RAIVNLab | 取 embedding 的前 n 维作为降维后的 embedding, 并分别计算 loss 最后累加, 从而让模型把重要特征集中在 embedding 的头部. 代码 [RAIVNLab/MRL](https://github.com/RAIVNLab/MRL), 参见 [CSDN--爱编程真是太好了--揭秘2025 OpenAI LLM的黑科技](https://blog.csdn.net/u012526436/article/details/148720737). | -| 2 | [MatFormer: Nested Transformer for Elastic Inference](https://www.yiyibooks.cn/arxiv/2310.07707v1/index.html) | Google | MatFormer是一种新颖的"嵌套式" Transformer 架构, 其核心目标是实现极致的推理弹性. 它通过一次性的训练, 生成一个通用的"母体"模型, 并能从中免费、即时地提取出成百上千个规模更小、性能卓越且功能完整的子模型, 彻底改变了传统"为每个场景单独训练一个模型"的低效模式. 采用了 Matryoshka Representation Learning 的类似思想, MatFormer 思路类似, 实现 PLE(Per-Layer Embeddings) 技术, 把 FFN 层的激活值采用类似的思路进行训练, 该模型采用学习残差连接(LAuReL), FFN 层从 2048 维投射到 16384 维(GeGLU激活), 比例异常宽, 可能部分参数可选择性开关以实现 Matformer. 每层嵌入被用于 FFN 后的操作, 作为低秩投影的门控. 这样推理阶段, 就可以根据当前的请求量确认模型需要激活多少参数, 这种设计实现了 "一次部署，多档可用" 的灵活部署方案. 参见 [知乎--北方的郎--揭秘Gemma3n背后的引擎：MatFormer弹性架构深度解析](https://zhuanlan.zhihu.com/p/1930197318738633011) | +| 2 | [MatFormer: Nested Transformer for Elastic Inference](https://www.yiyibooks.cn/arxiv/2310.07707v1/index.html) | Google | MatFormer是一种新颖的"嵌套式" Transformer 架构, 其核心目标是实现极致的推理弹性. 它通过一次性的训练, 生成一个通用的"母体"模型, 并能从中免费、即时地提取出成百上千个规模更小、性能卓越且功能完整的子模型, 彻底改变了传统"为每个场景单独训练一个模型"的低效模式. 采用了 Matryoshka Representation Learning 的类似思想, MatFormer 思路类似, 实现 PLE(Per-Layer Embeddings) 技术, 把 FFN 层的激活值采用类似的思路进行训练, 该模型采用学习残差连接(LAuReL), FFN 层从 2048 维投射到 16384 维(GeGLU激活), 比例异常宽, 可能部分参数可选择性开关以实现 Matformer. 每层嵌入被用于 FFN 后的操作, 作为低秩投影的门控. 这样推理阶段, 就可以根据当前的请求量确认模型需要激活多少参数, 这种设计实现了 "一次部署, 多档可用" 的灵活部署方案. 参见 [知乎--北方的郎--揭秘Gemma3n背后的引擎: MatFormer弹性架构深度解析](https://zhuanlan.zhihu.com/p/1930197318738633011) | | 3 | [Chain-of-Model Learning for Language Model](https://arxiv.org/abs/2505.11820) | NA | 把权重分成了 N 个 Chain, 每一个位置的值只激活当前与其前面的 Chain 的值, 在 MHA 阶段, 则是把 Chain 的大小和 head 的大小统一, 这样就能直接复用 Multi Query Attention 的思路. | ## 2.3 模型压缩和量化 @@ -256,7 +268,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad [大模型推理框架概述](https://zhuanlan.zhihu.com/p/659792625) -[大模型推理部署：LLM 七种推理服务框架总结](https://blog.csdn.net/m0_59596990/article/details/135311245) +[大模型推理部署: LLM 七种推理服务框架总结](https://blog.csdn.net/m0_59596990/article/details/135311245) [29 种本地部署大模型和调用的工具平台分类与总结](https://blog.csdn.net/l35633/article/details/138379452) @@ -270,14 +282,14 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad |:---:|:-------:|:---:|:---:| | 1 | [vLLM](https://github.com/vllm-project/vllm) | UC Berkeley | vLLM 是一个开源的大模型推理加速框架, 通过 PagedAttention 高效地管理 attention 中缓存的张量, 实现了比 HuggingFace Transformers 高 14-24 倍的吞吐量. PagedAttention 是 vLLM 的核心技术, 它解决了 LLM 服务中内存的瓶颈问题. 传统的注意力算法在自回归解码过程中, 需要将所有输入 Token 的注意力键和值张量存储在 GPU 内存中, 以生成下一个 Token. 这些缓存的键和值张量通常被称为 KV 缓存. [vLLM(二) 架构概览](https://zhuanlan.zhihu.com/p/681716326) | | 2 | [Text Generation Inference(TGI)](https://github.com/huggingface/text-generation-inference) | HuggingFace | Text Generation Inference(TGI) 是 HuggingFace 推出的一个项目, 作为支持 HuggingFace Inference API 和 Hugging Chat 上的 LLM 推理的工具, 旨在支持大型语言模型的优化推理. | -| 3 | [FasterTransformer](https://github.com/NVIDIA/FasterTransformer) | NVIDIA | NVIDIA FasterTransformer (FT) 是一个用于实现基于 Transformer 的神经网络推理的加速引擎. 它包含 Transformer 块的高度优化版本的实现, 其中包含编码器和解码器部分. 使用此模块, 您可以运行编码器 - 解码器架构模型 (如：T5)、仅编码器架构模型 (如：BERT) 和仅解码器架构模型 (如: GPT) 的推理. FT 框架是用 C++/CUDA 编写的, 依赖于高度优化的 cuBLAS、cuBLASLt 和 cuSPARSELt 库, 这使您可以在 GPU 上进行快速的 Transformer 推理. | +| 3 | [FasterTransformer](https://github.com/NVIDIA/FasterTransformer) | NVIDIA | NVIDIA FasterTransformer (FT) 是一个用于实现基于 Transformer 的神经网络推理的加速引擎. 它包含 Transformer 块的高度优化版本的实现, 其中包含编码器和解码器部分. 使用此模块, 您可以运行编码器 - 解码器架构模型 (如: T5)、仅编码器架构模型 (如: BERT) 和仅解码器架构模型 (如: GPT) 的推理. FT 框架是用 C++/CUDA 编写的, 依赖于高度优化的 cuBLAS、cuBLASLt 和 cuSPARSELt 库, 这使您可以在 GPU 上进行快速的 Transformer 推理. | | 4 | [DeepSpeed-Mll](https://github.com/microsoft/DeepSpeed-MII) | MicroSoft | DeepSpeed-MII 是 DeepSpeed 的一个新的开源 Python 库, 旨在使模型不仅低延迟和低成本推理, 而且还易于访问. | | 5 | [FlexFlow Server](https://github.com/flexflow/FlexFlow) | Leland Stanford Junior University | 一个开源编译器和分布式系统, 用于低延迟、高性能 LLM 服务. | | 6 | [LMDeploy](https://github.com/InternLM/lmdeploy) | [MMDeploy](https://github.com/open-mmlab/mmdeploy) 和 [MMRazor](https://github.com/open-mmlab/mmrazor) 团队联合开发 | 一个 C++ 和 Python 库, 用于使用 Transformer 模型进行高效推理. | | 7 | [CTranslate2](https://github.com/OpenNMT/CTranslate2) | OpenNMT | 一个快速推理引擎, 适用于 Transformer 模型, 提供高效的推理能力和性能优化技术. 在本文中, 我们将探索与 CTranslate2 相关的关键功能、模型类型、安装过程、基准测试以及其他资源. | | 8 | OpenLLM | OpenLLM | 用于在生产中操作大型语言模型 (LLM) 的开放平台. 为核心模型添加 adapter 并使用 HuggingFace Agents, 尤其是不完全依赖 PyTorch | | 9 | Ray Serve | NA | 一个可扩展的模型服务库, 用于构建在线推理 API. Serve 与框架无关, 因此你可以使用单个工具包来服务深度学习模型中的所有内容. 稳定的 Pipeline 和灵活的部署, 它最适合更成熟的项目 | -| 10 | MLC LLM | NA | MLC LLM 是一种通用部署解决方案. 可在客户端 (边缘计算), 例如 Android 或 iPhone 平台上, 本地部署 LLM. [MLC LLM：将 LLMs 部署到消费类硬件的优势、挑战以及解决方案](https://blog.csdn.net/FrenzyTechAI/article/details/132340135) | +| 10 | MLC LLM | NA | MLC LLM 是一种通用部署解决方案. 可在客户端 (边缘计算), 例如 Android 或 iPhone 平台上, 本地部署 LLM. [MLC LLM: 将 LLMs 部署到消费类硬件的优势、挑战以及解决方案](https://blog.csdn.net/FrenzyTechAI/article/details/132340135) | | 11 | [PaddlePaddle/Anakin](https://github.com/PaddlePaddle/Anakin) | BaiDu | 一个高性能的跨平台推理引擎, 可以在 x86 CPU, ARM, NVIDIA GPU, AMD GPU, 比特大陆以及寒武纪等设备上运行. | | 12 | [mllm](https://github.com/UbiquitousLearning/mllm) | [UbiquitousLearning](https://ubiquitouslearning.github.io/mllm_website) | 一个快速轻量级的多模态 LLM 推理引擎, 适用于移动和边缘设备, C/C++ 实现, 无任何其他依赖, 并针对多模态比如 fuyu-8B 进行了优化, 支持 ARM NEON 和 x86 AVX2 加速, 以及 4BIT 和 8BIT 整数量化. | | 13 | [XiaoMi/Mace](https://github.com/XiaoMi/mace) | 小米 | MACE (Mobile AI Compute Engine) 是一个针对移动异构计算平台优化的深度学习推理框架. 它专注于以下目标: 性能、功耗、响应性、内存使用和库体积、模型保护以及平台覆盖. MACE 支持 TensorFlow、Caffe 和 ONNX 等多种模型格式, 并提供了丰富的示例和文档. | @@ -289,7 +301,10 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 19 | Core ML | Apple | NA | | 20 | MediaPipe | Google | NA | | 21 | ByteNN | 字节跳动 | [字节跳动ByteNN端智能业务落地背后的技术挑战.pdf](https://max.book118.com/html/2022/0725/5202242220004312.shtm), [QCon 上海 2021](https://time.geekbang.org/course/detail/100822501-811440) -| 22 | [JD/xllm](https://github.com/jd-opensource/xllm) | 京东 | [京东 xllm 功能介绍](https://xllm.readthedocs.io/zh-cn/latest/features/overview) | +| 22 | [JD/xllm](https://github.com/jd-opensource/xllm) | 京东 | [京东 xllm 功能介绍](https://xllm.readthedocs.io/zh-cn/latest/features/overview), [xLLM Technical Report](https://arxiv.org/html/2510.14686) | +| 23 | [Anbeeld/beellama.cpp](https://github.com/Anbeeld/beellama.cpp) | BeeLlama.cpp(或简称 Bee)是一个以性能为核心的 llama.cpp 分支, 旨在从本地 GGUF 推断中榨取更多速度和上下文. 它保留了熟悉的 llama.cpp 工具和服务器流程, 同时增加了 DFlash 投机解码、自适应草稿控制、TurboQuant/TCQ KV 缓存压缩和推理环保护, 并支持完整的多模态. | +| 24 | [z-lab/dflash](https://github.com/z-lab/dflash) | DFlash 是一种轻量级块扩散模型, 专为投机解码设计. 它能够高效且高质量地进行并行投机. | + ### 3.1.2 推理加速库 @@ -302,10 +317,10 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 2 | [SNPE](https://www.qualcomm.com/developer?redirect=qdn) | Qualcomm Snapdragon | SNPE 是 Qualcomm Snapdragon Neural Processing Engine 的简称. SNPE 是神经网络在骁龙平台上推理的开发套件, 方便开发者在使用高通芯片的设备上加速 AI 应用. 支持的模型框架: TensorFlow, CAFFE, ONNX, TensorFlowLite. 比如 [SNPE_Tutorial](https://github.com/gesanqiu/SNPE_Tutorial) | | 3 | [PX4/eigen](https://github.com/PX4/eigen) | PX4 | Eigen 是一个 C++ 模板库, 用于线性代数: 矩阵、向量、数值求解器和相关算法. 它提供了一个高效、灵活和易于使用的接口, 适用于各种应用程序.| | 4 | [Google/XNNPACK](https://github.com/google/XNNPACK) | Google | XNNPACK 是一个针对 ARM、x86、WebAssembly 和 RISC-V 平台的高度优化的神经网络推理解决方案. 它不是直接面向深度学习从业者和研究人员使用的, 而是为诸如 TensorFlow Lite、TensorFlow.js、PyTorch、ONNX Runtime 和 MediaPipe 等高级机器学习框架提供低级性能原语, 以加速它们的推理性能. | -| 5 | [OpenBLAS](https://github.com/OpenMathLib/OpenBLAS) | OpenBLAS | 开源的 CPU 线性代数库，支持多线程和 SIMD 加速, 广泛应用于科学计算和深度学习框架(如 PyTorch). | +| 5 | [OpenBLAS](https://github.com/OpenMathLib/OpenBLAS) | OpenBLAS | 开源的 CPU 线性代数库, 支持多线程和 SIMD 加速, 广泛应用于科学计算和深度学习框架(如 PyTorch). | | 6 | [Intel MKL(Math Kernel Library)]() | NA | 针对 Intel CPU 优化的数学计算库, 支持矩阵运算、FFT 等. 在 Intel 平台上性能优于 Eigen. | | 7 | [Arm Compute Library](https://github.com/ARM-software/ComputeLibrary) | ARM | Arm CPU/GPU 的加速库, 支持图像处理和机器学习算子. 针对 Cortex-A/Cortex-M 优化, 兼容 CMSIS-NN46. | -| 8 | [CuPy](https://github.com/cupy/cupy) | NA | 基于 NVIDIA GPU 的数值计算库，语法兼容 NumPy. 替代部分 Eigen 功能, 适合 GPU 加速场景. | +| 8 | [CuPy](https://github.com/cupy/cupy) | NA | 基于 NVIDIA GPU 的数值计算库, 语法兼容 NumPy. 替代部分 Eigen 功能, 适合 GPU 加速场景. | | 9 | [neon](https://github.com/NervanaSystems/neon) | Intel | neon 是英特尔公司开源的深度学习框架, 致力于在各种硬件上提供最佳性能. 它设计简单易用, 并且具有可扩展性. | | 10 | [lapack](https://github.com/Reference-LAPACK/lapack) | NA | LAPACK 是一个用于解决常见数值线性代数问题的 Fortran 子程序库. 它是一个免费提供的软件包, 可以包含在商业软件包中. LAPACK 包含了 Fortran 源代码、测试程序、基本线性代数子程序 (BLAS) 的 Fortran 参考实现, 以及 CBLAS 和 LAPACKE 的 C 接口. | | 11 | [Tencent/ncnn](https://github.com/Tencent/ncnn) | Tencent | ncnn 是一个为手机端极致优化的高性能神经网络前向计算框架. 它从设计之初就深入考虑了手机端的部署和使用. ncnn 无第三方依赖、跨平台, 在手机端 CPU 上的速度快于目前所有已知的开源框架. 开发者可以轻松将深度学习算法移植到手机端高效执行, 开发出人工智能 APP, 将 AI 带到用户的指尖. ncnn 目前已在腾讯多款应用中使用, 如 QQ、Qzone、微信、天天 P 图等. | @@ -318,9 +333,9 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad [bilibili-- 如何将大模型与小模型结合？这 8 种常用策略必看！附 17 篇案例论文和代码](https://www.bilibili.com/opus/887920175625535524) -[知乎 -- 刀刀宁聊大模型推理 -- 笔记：学习推理加速半年之总结与迷思](https://zhuanlan.zhihu.com/p/704938096) +[知乎 -- 刀刀宁聊大模型推理 -- 笔记: 学习推理加速半年之总结与迷思](https://zhuanlan.zhihu.com/p/704938096) -[知乎 - 锦年 - 全面解析 LLM 推理优化：技术、应用与挑战](https://zhuanlan.zhihu.com/p/18736565021) +[知乎 - 锦年 - 全面解析 LLM 推理优化: 技术、应用与挑战](https://zhuanlan.zhihu.com/p/18736565021) ### 3.2.1 KV Cache 压缩 ------- @@ -331,19 +346,41 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad [PyramidKV 学习资料汇总 - 动态 KV 缓存压缩技术](https://blog.csdn.net/m0_56734068/article/details/142382328) -[大模型推理加速：KV Cache Sparsity(稀疏化)方法](https://zhuanlan.zhihu.com/p/701580870) +[大模型推理加速: KV Cache Sparsity(稀疏化)方法](https://zhuanlan.zhihu.com/p/701580870) [聊聊大模型推理中的 KVCache 之异构缓存](https://zhuanlan.zhihu.com/p/714288577) [聊聊大模型推理中的 KVCache 压缩](https://zhuanlan.zhihu.com/p/708946312) -### 3.2.2 稀疏感知推理加速 +### 3.2.2 低内存推理加速 ------- -[论文笔记：DejaVu、LLM in Flash、PowerInfer](https://zhuanlan.zhihu.com/p/675585887) +#### 3.2.2.1 训推一体 +------- -[苹果极致 LLM 端侧方案：LLM in a flash](https://zhuanlan.zhihu.com/p/673775476) +[论文笔记: DejaVu、LLM in Flash、PowerInfer](https://zhuanlan.zhihu.com/p/675585887) + +[苹果极致 LLM 端侧方案: LLM in a flash](https://zhuanlan.zhihu.com/p/673775476) + + +| 编号 | 时间 | 论文 | 描述 | +|:---:|:----:|:---:|:----:| +| 1 | 2025/07/17 | [Apple Intelligence Foundation Language Models: Tech Report 2025](https://arxiv.org/abs/2507.13575v3) | 本文系统介绍了支撑 Apple Intelligence 的两代基础语言模型——3B 参数端侧模型(KV-cache 共享 + 2-bit QAT)与基于 Parallel-Track Mixture-of-Experts (PT-MoE) 的服务器模型(track 并行 + ASTC 硬件压缩), 通过架构、训练、推理三层的协同优化, 在公开基准与人类评估上达到与同规模开源基线相当或更优的水平, 同时显著降低内存、延迟与计算成本. | +| 2 | 2026/04/20 | [Efficient Mixture-of-Experts LLM Inference with Apple Silicon NPUs](https://arxiv.org/abs/2604.18788) | NPUMoE 是一个为 Apple Silicon NPU 设计的 MoE 推理引擎: 通过离线校准 + 静态容量分层 + 分组专家执行 + 负载感知图驻留三件套, 把 MoE 的稠密计算卸载到 NPU、把动态计算留给 CPU, 在 M2 Ultra 上把长上下文 prefill 延迟降 1.32x-5.55x、能效升 1.81x-7.37x、CPU 周期降 1.78x-5.54x, 精度损失 <1.1%. | + + +#### 3.2.2.2 系统垂直整合 +------- + +| 编号 | 时间 | 论文 | 描述 | +|:---:|:----:|:---:|:----:| +| 1 | 2024/09/09 | [Hermes: Memory-Efficient Pipeline Inference for Large Models on Edge Devices](https://arxiv.org/abs/2409.04249) | 多 Loading Agent 并行加载 + Daemon Agent 动态销毁已推理层, 在纯 CPU 边缘设备上同时缓解大模型推理的内存压力和 pipeline stall. 通过 Profiler + Planner + Execution Engine 协作, 将模型加载与推理进行流水线并行, Profiler 先把模型每一层都"摸一遍底",记录它的加载时间、推理时间、内存大小; Planner 拿着这份"层简历"在不同内存约束下挑出最优 LA 数; Execution Engine 才真正下场干活, 根据当前内存约束调度 LA + IA + DA + 信号机制. 这是一种典型的"先量体裁衣、再下场干活"的工程哲学. 实测对 BERT/ViT 最高 4.24× 加速、86.7% 内存下降,GPT 风格模型最高 2.58× 加速、90.3% 内存下降. | +| 2 | 2024/12/04 | [FlexNN: Efficient and Adaptive DNN Inference on Memory-Constrained Edge Devices](https://dl.acm.org/doi/10.1145/3636534.3649391) | FlexNN 针对边缘设备 DNN 推理的"内存瓶颈"问题, 提出 **slicing-loading-computing 联合规划**框架: 离线阶段用 bottleneck-aware layer slicing(按层瓶颈类型选 weights slicing 或 input slicing)切小瓶颈层, 用 preload-aware memory planning(2DBP 半固定时间变体)生成无碎片+零 I/O 等待的内存布局; 在线阶段用 dependency-based synchronization + type-based static allocator 把规划落地为多线程并发执行. 基于 NCNN 实现的 prototype 在 Pixel 6 Pro 上把 ResNet-152 峰值内存砍掉 93.81% 仅增 3.64% 延迟, 支持约 1 秒内动态适配内存预算变化, 是首个把"内存"作为第一优先级设计的移动推理框架. 对应专利 [面向内存受限设备的深度学习模型自适应推理方法及系统(CN118349492A, 202410279838.2)](https://patents.google.com/patent/CN118349492A) | +| 3 | 2025/09/23 | [Scaling Up On-Device LLMs via Active-Weight Swapping Between DRAM and Flash](https://arxiv.org/abs/2504.08378) | ActiveFlow 是首个支持现代非 ReLU 大模型在移动端实现自适应 DRAM 使用的推理框架, 通过跨层激活权重预加载、稀疏感知自蒸馏、DRAM-Flash 交换 Pipeline 三项技术, 在中端 Pixel 6 上首次部署 Mixtral-8x7B 4bit 模型(1.8 tokens/s @ 2.9GB), 相对原始 24.6GB 内存需求压缩 8.5×. | +| 4 | 2026/04/09 | [DuoServe-MoE: Dual-Phase Expert Prefetch and Caching for LLM Inference QoS Assurance](https://arxiv.org/abs/2509.07379)| DuoServe-MoE 是面向资源受限单 GPU MoE 大模型服务的双阶段专家调度系统. 采用双阶段调度核心思想——承认 prefill 与 decode 是"两种生意", 差异化调度. 系统的核心张力在于: prefill 不需要预测器(多 token 几乎激活所有专家), 却必须严格控制峰值内存; decode 只需 Top-k 个专家, 却必须把传输延迟彻底藏到计算背后.整体流程分三步: 离线 preprocess → prefill 调度 → decode 调度. 系统由离线预处理与在线服务两部分组成: ① 离线部分收集专家激活路径、统计 popularity 与 affinity、训练一个轻量 MLP 预测器; ② 在线部分则在 prefill 与 decode 两个阶段采用不同的专家调度策略——prefill 用双 CUDA 流在算非 MoE 层的同时流水化预取专家, decode 用三 CUDA 流把"预测下一层专家"与"传输权重"、"执行计算"三者并行起来.
① prefill 阶段所有专家激活密集, 不需要预测, 以双 CUDA 流水线, 把搬运藏进计算里, 一条 communication 流专门搬专家权重, 一条 computation 流同时跑非 MoE 层的计算. 进 MoE 层前同步一下确保权重到位, gate 算完后按专家分组 token, 每个专家只取一次权重; ② Decode 用三 CUDA 流并行, comp 流算 Layer N、pred 流预测 Layer N+1、comm 流在 Layer N 第一专家. 以轻量 MLP 预测器预取下一层专家隐藏传输延迟. 最终实现 TTFT 最高 5.34×、E2E 延迟最高 7.55× 提升. | +| 5 | [TurboFieldfare](https://github.com/drumih/turbo-fieldfare) | 开发者 Andrey Mikhaylov 推出的开源 macOS 专属 MoE 模型推理运行时, 7 月 29 日登顶 Hacker News 榜首. 利用 MoE 稀疏激活的天然特性, 搭配分层 LFU 缓存、Metal 异步 IO、SSD 专家权重流式加载, 仅用 2GB 常驻内存在任意 Apple Silicon Mac 本地跑通 Google Gemma 4 26B-A4B, 是端侧 MoE 推理的里程碑式工程实现; | +| 6 | 2026/06/05 | [FlashMoE: Fast Distributed MoE in a Single Kernel](https://arxiv.org/abs/2506.04667) | [](https://github.com/osayamenja/FlashMoE) ### 3.2.3 首 Token 时延优化 ------- @@ -363,15 +400,15 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad [最全 LLM 自投机算法汇总](https://zhuanlan.zhihu.com/p/706111755) -[LLM 推理提速 2.8 倍，CMU 清华姚班校友提出「投机式推理」引擎 SpecInfer，小模型撬动大模型高效推理](https://www.jiqizhixin.com/articles/2023-05-30-3) +[LLM 推理提速 2.8 倍, CMU 清华姚班校友提出「投机式推理」引擎 SpecInfer, 小模型撬动大模型高效推理](https://www.jiqizhixin.com/articles/2023-05-30-3) -[知乎 - LLM 推理加速新范式！推测解码（Speculative Decoding）最新综述](https://zhuanlan.zhihu.com/p/678404136) +[知乎 - LLM 推理加速新范式！推测解码(Speculative Decoding)最新综述](https://zhuanlan.zhihu.com/p/678404136) -[知乎 - 投机采样（Speculative Decoding），另一个提高 LLM 推理速度的神器（三）](https://zhuanlan.zhihu.com/p/681401656) +[知乎 - 投机采样(Speculative Decoding), 另一个提高 LLM 推理速度的神器(三)](https://zhuanlan.zhihu.com/p/681401656) [知乎 - 刀刀宁 - 聊聊大模型推理服务之投机推理](https://zhuanlan.zhihu.com/p/699166575) -[知乎 - hemingkx - 推测解码（Speculative Decoding）哪家强？-- 最新评测基准 Spec-Bench 分享](https://zhuanlan.zhihu.com/p/683995502) +[知乎 - hemingkx - 推测解码(Speculative Decoding)哪家强？-- 最新评测基准 Spec-Bench 分享](https://zhuanlan.zhihu.com/p/683995502) [知乎 - 有没有 speculative decoding 的综述？](https://www.zhihu.com/question/657854511) @@ -381,14 +418,14 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 编号 | 时间 | 文章 | 描述 | |:---:|:----:|:---:|:----:| | 1 | 2025/07/04 | [知乎 - Se7en - Speculative Decoding 推测解码方案详解](https://zhuanlan.zhihu.com/p/1920447613800547342) | 本文是 LLM 推理系列的第 4 篇, 介绍 Speculative Decoding 推测解码方案详解, 详细介绍了 EAGLE、Medusa、Lookahead 等主流的 Speculative Decoding 方案. | -| 2 | NA | [从 EAGLE-3 看 Tokenizer 对投机解码的影响](https://zhuanlan.zhihu.com/p/1916965162755285553) | EAGLE3 能带来如此高的加速比，除了它本身优秀的草稿模型和验证机制外，是不是还有其他 “玄机”？不同模型对不同语言的 tokenizer 优化程度不同, 导致它们在多语言场景下的表现差异. Vicuna 的 Tokenizer 在不同语言中普遍呈现出较细的粒度; 从“每步接受多少 Token” 的指标上来看是其他模型的 1.5~2 倍. | +| 2 | NA | [从 EAGLE-3 看 Tokenizer 对投机解码的影响](https://zhuanlan.zhihu.com/p/1916965162755285553) | EAGLE3 能带来如此高的加速比, 除了它本身优秀的草稿模型和验证机制外, 是不是还有其他 “玄机”？不同模型对不同语言的 tokenizer 优化程度不同, 导致它们在多语言场景下的表现差异. Vicuna 的 Tokenizer 在不同语言中普遍呈现出较细的粒度; 从“每步接受多少 Token” 的指标上来看是其他模型的 1.5~2 倍. | | 3 | 2025/05/24 | [大模型推理 & memory bandwidth bound (4) - Speculative Decoding](https://zhuanlan.zhihu.com/p/1899508608909162422) | 本篇讲解了 Speculative Decoding 的原理, 即以近似模型输出建议 tokens, 目标模型对齐进行并行验证的方式对模型推理进行了加速; 同时, 我们也证明了 Speculative Sampling 的采样方式使得其输出分布与目标模型原有的自回归输出分布保持一致. | -| 4 | 2025/05/05 | [三种投机解码方法对比：Vanilla Speculative Decoding ・ Medusa ・ EAGLE](https://zhuanlan.zhihu.com/p/1902847900742055126) | 作者分析了几个投机算法, 得出总结:
1. Vanilla 双模型最易落地, 维护成本在“小模型 + 双 KV Cache”.
2. Medusa 把草稿嵌回大模型顶层, 多头 + 树形一次核验, 无需小模型, 但须改写主模型.
3. EAGLE 草稿移至特征空间, 接受率最高, 代价是额外 Draft 训练与中间特征. | -| 5 | 2025/07/04 | [知乎 - AI 算法小喵 - 投机解码之 EAGLE：轻量级草稿模型实现 3-4 倍推理加速](https://zhuanlan.zhihu.com/p/1898466485095098162) | 分享了 Eagle, 一种利用目标模型的 feature, 并在 feature 层面结合 token 信息进行自回归的从而保证生成质量实现加速的草稿模型构建方法, 并在结尾对比了与之非常相似的 MTP. | -| 6 | 2025/06/29 | [大模型推理加速之 Speculative Decoding / 投机解码(上)](https://zhuanlan.zhihu.com/p/1922687688307377206) | 作者阅读了《Fast Inference from Transformers via Speculative Decoding》，后简单地分析了 speculative decoding 的处理流程以及其中涉及的一些细节 | +| 4 | 2025/05/05 | [三种投机解码方法对比: Vanilla Speculative Decoding ・ Medusa ・ EAGLE](https://zhuanlan.zhihu.com/p/1902847900742055126) | 作者分析了几个投机算法, 得出总结:
1. Vanilla 双模型最易落地, 维护成本在“小模型 + 双 KV Cache”.
2. Medusa 把草稿嵌回大模型顶层, 多头 + 树形一次核验, 无需小模型, 但须改写主模型.
3. EAGLE 草稿移至特征空间, 接受率最高, 代价是额外 Draft 训练与中间特征. | +| 5 | 2025/07/04 | [知乎 - AI 算法小喵 - 投机解码之 EAGLE: 轻量级草稿模型实现 3-4 倍推理加速](https://zhuanlan.zhihu.com/p/1898466485095098162) | 分享了 Eagle, 一种利用目标模型的 feature, 并在 feature 层面结合 token 信息进行自回归的从而保证生成质量实现加速的草稿模型构建方法, 并在结尾对比了与之非常相似的 MTP. | +| 6 | 2025/06/29 | [大模型推理加速之 Speculative Decoding / 投机解码(上)](https://zhuanlan.zhihu.com/p/1922687688307377206) | 作者阅读了《Fast Inference from Transformers via Speculative Decoding》, 后简单地分析了 speculative decoding 的处理流程以及其中涉及的一些细节 | | 7 | [知乎 - - 推测解码 - 从 draft model、Medusa、Recurrent Drafter、EAGLE、 Prompt Lookup 到 Lookahead Decoding](https://zhuanlan.zhihu.com/p/19701798414) | 按照 tensorRT-llm 支持的文档 Speculative Sampling 我们把推测解码分成四种类型:
1. draft model: 利用更小的 LLM 先快速生成 token 序列, 使用 LLM 进行一次性验证;
2. additional heads: 利用在原 LLM 上新增训练的 transformers 的注意力层来生成 tokens;
3. Prompt Lookup: 使用 prompt tokens as draft tokens
4. Lookahead Decoding: 用历史数据构成 tokens, 但一个批次的构造[ABC,BCD,CDE], 提高单批次推理速度的骚操作. | | 8 | 2025/05/25 | [知乎 - 笑渐不闻声渐悄 - Speculative Decoding: 总结、分析、展望](https://zhuanlan.zhihu.com/p/1904881828906668879) | Speculative Decoding: 总结、分析、展望 | -| 9 | 2025/01/25 |[知乎 - CarryPls - 大模型推理加速技术调研 - 投机采样](https://zhuanlan.zhihu.com/p/20233143567) | 现有的投机采样架构可以分为 drafter-scorer-sampler 3 层, 该观念来自 vLLM PR:1. drafter 生成 draft tokens: 关注 draft tokens 生成速度, 质量和组织形式.
2. scorer 利用 target model（大模型）评估生成的 draft tokens 的概率分布. 关注显存使用和验证速度.
3. sampler 根据前两步的结果选择接受的 token. 关注 token 接受率. | +| 9 | 2025/01/25 |[知乎 - CarryPls - 大模型推理加速技术调研 - 投机采样](https://zhuanlan.zhihu.com/p/20233143567) | 现有的投机采样架构可以分为 drafter-scorer-sampler 3 层, 该观念来自 vLLM PR:1. drafter 生成 draft tokens: 关注 draft tokens 生成速度, 质量和组织形式.
2. scorer 利用 target model(大模型)评估生成的 draft tokens 的概率分布. 关注显存使用和验证速度.
3. sampler 根据前两步的结果选择接受的 token. 关注 token 接受率. | | 10 | 2024/09/11 | [知乎 - Sjrrr 大蛇 - 最全 LLM 自投机算法汇总](https://zhuanlan.zhihu.com/p/706111755) | 对业界领先的多个投机算法进行了分析. | | 11 | 2025/06/08 | [知乎 - 罗西的思考 - 探秘 Transformer 系列之(30)--- 投机解码](https://zhuanlan.zhihu.com/p/1898466485095098162) | 对 BPD 投机论文的详细分析 | @@ -399,17 +436,16 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 1 | 2025/04/24 | [OPT-Tree: Speculative Decoding with Adaptive Draft Tree Structure](https://arxiv.org/abs/2406.17276) | [Jikai0Wang/OPT-Tree](https://github.com/Jikai0Wang/OPT-Tree), [微信公众号 - 机器学习算法与自然语言处理 - 一步生成超过 10 个 Tokens!! 无损模型解码加速最新工作](https://mp.weixin.qq.com/s?__biz=MzI4MDYzNzg4Mw==&mid=2247563973&idx=2&sn=a4d1f1a7ee39b11af74bdd020cbdd90c&chksm=ea702fbc79a360767cf3bbb1eb4102b1bb22f8e74f5a258cc3cce656cf88f11eb666f3c97917&scene=27) | | 2 | 2024/06/25 | [Optimizing Speculative Decoding for Serving Large Language Models Using Goodput](https://arxiv.org/abs/2406.14066) | 对于不同系统负载下的所有工作负载, 没有最佳推测长度工作. 根据观察结果, 作者开发了一个动态框架 SmartSpec. SmartSpec 根据一个名为 goodput 的新指标动态确定每个请求的最佳投机长度(从 0, 即无投机到许多代币)——因此相关的投机执行成本, 该指标表征了整个系统的当前观察负载和投机准确性. | | 3 | 2025/03/07 | [SpecServe: Efficient and SLO-Aware Large Language Model Serving with Adaptive Speculative Decoding](https://arxiv.org/abs/2503.05096) | 在本文提出了 SpecServe, 可根据实时请求负载和系统配置动态调整推测策略. SpecServe 提出了一个理论模型来理解和预测不同场景中推测解码的效率. 此外, 它还实现了智能绘图和验证算法, 以保证最佳性能, 同时实现高 SLO 实现. 在实际 LLM 跟踪上的实验结果表明, SpecServe 始终满足 SLO 并实现了实质性的性能改进, 与最先进的推测推理系统相比, 速度提高了 1.14. | -| 4 | 2024/05/26 | [Kangaroo: Lossless Self-Speculative Decoding via Double Early Exiting](https://arxiv.org/abs/2404.18911) | [华为诺亚 | 提出自推测解码框架：Kangaroo，降低成本，提升大模型推理效率！](https://cloud.tencent.com/developer/article/2415194) +| 4 | 2024/05/26 | [Kangaroo: Lossless Self-Speculative Decoding via Double Early Exiting](https://arxiv.org/abs/2404.18911) | [华为诺亚 | 提出自推测解码框架: Kangaroo, 降低成本, 提升大模型推理效率！](https://cloud.tencent.com/developer/article/2415194) #### 3.2.4.2 MTP/Multi-Token Prediction(多 token 预测) ------- | 编号 | 时间 | 论文 | 描述 | |:---:|:----:|:---:|:----:| -| 1 | 2025/07/16 | [Your LLM Knows the Future: Uncovering Its Multi-Token Prediction Potential](https://www.alphaxiv.org/abs/2507.11851) | 实现 MTP 框架, 使预训练的自回归大型语言模型能够执行多 token 预测, 在保持生成质量的同时, 为代码和数学任务提供高达 5.35 倍的推理加速, 以及为一般任务提供约 2.5 倍的推理加速.
-研究者们评估了自回归模型在语言模型有监督微调阶段对多 token 预测任务的适应能力. 未来值得探索的一个方向, 是在预训练阶段或下游任务自适应阶段引入该方法, 以进一步检验其适用性与效果. 另一个具有前景的研究方向是将基于扩散的生成方法应用于多 token 预测任务. 研究者们认为, 多 token 预测位于完全自回归生成与完全扩散生成之间, 能够在两者之间取得优势的平衡，兼具效率与质量的潜力. 参见 [机器之心 -- 五倍推理加速，激发自回归潜能，苹果新工作让 LLM 预测未来](https://www.jiqizhixin.com/articles/2025-07-24-9) | +| 1 | 2025/07/16 | [Your LLM Knows the Future: Uncovering Its Multi-Token Prediction Potential](https://www.alphaxiv.org/abs/2507.11851) | 实现 MTP 框架, 使预训练的自回归大型语言模型能够执行多 token 预测, 在保持生成质量的同时, 为代码和数学任务提供高达 5.35 倍的推理加速, 以及为一般任务提供约 2.5 倍的推理加速.
研究者们评估了自回归模型在语言模型有监督微调阶段对多 token 预测任务的适应能力. 未来值得探索的一个方向, 是在预训练阶段或下游任务自适应阶段引入该方法, 以进一步检验其适用性与效果. 另一个具有前景的研究方向是将基于扩散的生成方法应用于多 token 预测任务. 研究者们认为, 多 token 预测位于完全自回归生成与完全扩散生成之间, 能够在两者之间取得优势的平衡, 兼具效率与质量的潜力. 参见 [机器之心 -- 五倍推理加速, 激发自回归潜能, 苹果新工作让 LLM 预测未来](https://www.jiqizhixin.com/articles/2025-07-24-9) | | 2 | 2025/06/13 | [Improving Large Language Models with Concept-Aware Fine-Tuning](https://arxiv.org/abs/2506.07833) | 当前主流 LLM 都依赖 next-token prediction 进行训练,, 但它却让 AI 很难真正理解跨越多 token 的完整概念. 于是南洋理工大学最近提出了一项新技术——概念感知微调 (CAFT), 首次实现将 multi-token prediction(多 token 预测) 引入微调阶段, 让模型能够像人类一样理解和学习完整概念. 原来 LLM 只能碎片化理解每个 token, 现在 CAFT 可以为模型添加额外的辅助头, 在主模型学习下一个词的同时, 帮助学习后续 token, 并通过动态调整权重, 确保模型始终优先优化主要任务的损失. 最终 LLM 可以兼顾多 token 概念学习, 形成更为完整的认知, 在推理和生成能力增强的同时, 既不会影响模型本身, 也不会额外增加多余成本. 参见量子位报道 [知乎 - 量子位 - 突破单 token 预测局限！南洋理工首次将多 token 预测引入微调](https://zhuanlan.zhihu.com/p/1931778341473616685), [项目地址](https://github.com/michaelchen-lab/caft-llm). | -| 3 | 2025/09/13 | [FastMTP: Accelerating LLM Inference with Enhanced Multi-Token Prediction](https://github.com/Tencent-BAC/FastMTP/blob/main/FastMTP_technical_report.pdf) | 腾讯开源 LLM 推理加速项目: FastMTP, 主要在推理阶段通过增强多词元预测来改进投机解码, 比传统的逐词生成方式, 在保持输出质量无损的同时，实现平均2.03倍的加速. 其核心是微调一个共享权重的单 MTP 头, 使其在多个因果草稿步中复用, 从而捕捉更长距离的依赖关系, 提高投机解码的接受率. 同时, 在 MTP 头内引入语言感知的词表压缩, 来进一步降低草稿生成的计算开销.
1. 投机解码(Speculative Decoding): 借鉴"草稿+验证"的策略, 由一个快速的草稿模型生成多个候选标记, 用主模型进行批量验证, 实现并行处理, 提高推理效率.
2. 共享权重的单 MTP 头: 摒弃传统 MTP 的多独立模块设计, 改用共享权重的 MTP 头递归生成多个标记, 减少内存占用, 迫使模型学习更长距离的依赖关系, 提高草稿质量.
3. 自蒸馏训练: 使用主模型生成的数据对 MTP 头进行训练, 通过指数衰减的加权交叉熵损失函数, 让 MTP 头优先学习生成与主模型风格和逻辑一致的草稿, 提高草稿的接受率.
4. 语言感知词汇压缩: 在草稿生成阶段, 根据输入语境判断语言, 仅计算高频词汇的 logits, 减少计算量, 验证阶段用全量词汇, 确保输出质量不受影响. 参见 [FastMTP – 腾讯开源的大语言模型推理加速技术](https://ai-bot.cn/fastmtp) 和 [【LLM】大模型投机采样Speculative Sampling推理加速](https://blog.csdn.net/qq_35812205/article/details/149914702) | +| 3 | 2025/09/13 | [FastMTP: Accelerating LLM Inference with Enhanced Multi-Token Prediction](https://github.com/Tencent-BAC/FastMTP/blob/main/FastMTP_technical_report.pdf) | 腾讯开源 LLM 推理加速项目: FastMTP, 主要在推理阶段通过增强多词元预测来改进投机解码, 比传统的逐词生成方式, 在保持输出质量无损的同时, 实现平均2.03倍的加速. 其核心是微调一个共享权重的单 MTP 头, 使其在多个因果草稿步中复用, 从而捕捉更长距离的依赖关系, 提高投机解码的接受率. 同时, 在 MTP 头内引入语言感知的词表压缩, 来进一步降低草稿生成的计算开销.
1. 投机解码(Speculative Decoding): 借鉴"草稿+验证"的策略, 由一个快速的草稿模型生成多个候选标记, 用主模型进行批量验证, 实现并行处理, 提高推理效率.
2. 共享权重的单 MTP 头: 摒弃传统 MTP 的多独立模块设计, 改用共享权重的 MTP 头递归生成多个标记, 减少内存占用, 迫使模型学习更长距离的依赖关系, 提高草稿质量.
3. 自蒸馏训练: 使用主模型生成的数据对 MTP 头进行训练, 通过指数衰减的加权交叉熵损失函数, 让 MTP 头优先学习生成与主模型风格和逻辑一致的草稿, 提高草稿的接受率.
4. 语言感知词汇压缩: 在草稿生成阶段, 根据输入语境判断语言, 仅计算高频词汇的 logits, 减少计算量, 验证阶段用全量词汇, 确保输出质量不受影响. 参见 [FastMTP – 腾讯开源的大语言模型推理加速技术](https://ai-bot.cn/fastmtp) 和 [【LLM】大模型投机采样Speculative Sampling推理加速](https://blog.csdn.net/qq_35812205/article/details/149914702) | ### 3.2.5 并行解码 @@ -432,7 +468,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 1 | [b4rtaz/distributed-llama](https://github.com/b4rtaz/distributed-llama) | Bart Tadych(b4rtaz) | Distributed Llama 是一个开源项目, 旨在通过张量并行化技术在多台设备上分布式运行大型语言模型 (LLM). 它可以在普通的 CPU 设备上运行 LLM, 通过分布工作负载来提高推理速度, 并将 RAM 使用量分散到多个节点上, 以加速大型语言模型(LLM) 的推理. 该项目支持 Linux、macOS 和 Windows 操作系统, 并针对 ARM 和 x86_64 AVX2 CPU 进行了优化.
主要功能点:
1. 支持多个设备组成集群, 利用张量并行和高速以太网同步, 提高推理性能
2. 支持多种 Llama 模型, 包括 Llama 3.1 405B、Llama 3.3 70B 等
3. 提供简单的命令行工具, 可以快速启动根节点和工作节点
4. 支持 API 服务器, 方便集成到其他应用程序中 | | 2 | [exo-explore/exo](https://github.com/exo-explore/exo) | exo 实验室 | exo 是一个可以在家中使用普通设备运行自己的 AI 集群的项目
主要功能点:
1. 支持多种模型, 包括 LLaMA、Mistral、LlaVA、Qwen 和 Deepseek 等
2. 动态模型分区, 可根据当前网络拓扑和设备资源自动优化模型分布
3. 自动发现设备, 无需手动配置
4. 提供与 ChatGPT 兼容的 API
5. 采用对等连接架构, 设备之间地位平等. | | 3 | [NVIDIA Dynamo](https://developer.nvidia.cn/dynamo) | NVIDIA | NVIDIA Dynamo 是一个开源、低延迟的模块化推理框架, 用于在分布式环境中服务生成式 AI 模型. 它通过智能资源调度和请求路由、优化的内存管理和无缝的数据传输, 实现跨大型 GPU 集群的推理工作负载无缝扩展. NVIDIA Dynamo 支持所有主要的 AI 推理后端, 并提供专门针对大语言模型 (LLM) 的优化, 例如分解服务. | -| 4 | [prima.cpp](https://github.com/Lizonghang/prima.cpp) | NA | `prima.cpp` 是 `llama.cpp`(一个性能优异的大模型推理框架)的分布式实现, 它允许您在日常设备上运行 70B 级 LLM--💻 笔记本电脑，🖥️ 台式机，📱 手机和平板电脑(GPU 或没有 GPU), 都很好. 参见论文 [PRIMA.CPP: Speeding Up 70B-Scale LLM Inference on Low-Resource Everyday Home Clusters](https://arxiv.org/pdf/2504.08791) | +| 4 | [prima.cpp](https://github.com/Lizonghang/prima.cpp) | NA | `prima.cpp` 是 `llama.cpp`(一个性能优异的大模型推理框架)的分布式实现, 它允许您在日常设备上运行 70B 级 LLM--💻 笔记本电脑, 🖥️ 台式机, 📱 手机和平板电脑(GPU 或没有 GPU), 都很好. 参见论文 [PRIMA.CPP: Speeding Up 70B-Scale LLM Inference on Low-Resource Everyday Home Clusters](https://arxiv.org/pdf/2504.08791) | | 5 | [cake](https://github.com/evilsocket/cake) | evilsocket | 旨在将消费级硬件组合成异构集群, 其中消费级硬件采用多种操作系统, 包括: iOS、Android、macOS、Linux 和 Windows, 从而使 AI 更易于访问. 主要思路是将 transformer 块分片到多个设备, 以便能够让通常不适合单个设备 GPU 内存的模型运行推理. 对同一工作线程上的连续 transformer 块的推理是分批进行的, 以便最大限度地减少数据传输造成的延迟. | @@ -445,14 +481,14 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad | 日期 | 概要 | 论文 / 链接 | 团队 | 描述 | |:---:|:----:|----------:|:----:|:----:| | 2024/07 | 异构计算资源混合调度的大模型推理系统 llm.npu | [Fast On-device LLM Inference with NPUs, ASPLOS'2025](https://arxiv.org/abs/2407.05858v2) | 北京大学计算机学院 | 在端设备侧进行高性能的模型推理成为泛在计算环境下一个重要的应用场景. 然而, 即使是专为端侧设备设计的大语言模型(LLM), 如 Gemma-2B 在处理屏幕 UI 理解等任务时, 仍面临预填充阶段的高延迟瓶颈.
为了解决这一问题, 团队提出了 llm.npu 系统, llm.npu 是首个基于端侧设备的神经网络处理芯片(NPU) 来进行任务分载, 以降低预填充阶段的延迟/能耗以提升推理任务整体性能的系统, 通过 NPU(整数计算)和 CPU/GPU 上(浮点运算)的内存共享和乱序执行来确保计算精度.
1. 在 Prompt 层面, Chunk-sharing graph, 将可变长度的提示词分割为多个固定大小的块, 以保持数据依赖性;
2. 在 Tensor 层面, Shadow outlier execution, llm.npu 识别并提取重要的异常值在 CPU/GPU 上处理, 以保证推理的准确性;
3. 在 Block 层面, Out-of-order subgraph execution, 根据 Transformer 块的硬件适应性和对精度的敏感性, 将它们灵活调度到 CPU/GPU/NPU上. 实验显示, 在保持精度的同时, 相比 5 个主流的同期主流工作(llama.cpp、TFLite、MNN、MLC-LLM 和 PowerInfer-v2), llm.npu 在可以提升 7.3 到 43.6 倍, 并降低了 1.9 到 59.5 倍的能耗. 该工作为利用端侧异构计算资源来优化 LLM 推理性能探索了全新路径, 也为泛在计算环境下的 LLM 规模化应用提供了有效系统支撑. | -| 2024/07 | HeteroLLM 异构推理框架, CPU 用于调度 GPU 和 NPU, GPU 和 NPU 用于推理 | [HeteroLLM: Accelerating Large Language Model Inference on Mobile SoCs platform with Heterogeneous AI Accelerators](https://arxiv.org/abs/2501.14794) | 论文深入分析了 GPU 和 NPU 的硬件架构, 强调了 NPU 对张量形状敏感的性能特征. 遗憾的是, 现代 LLM 中的某些层(如 FFN-down 层)无法被 NPU 高效处理, 形成显著瓶颈. HeteroLLM 通过利用 GPU 弥补 NPU 的计算限制, 缓解了这些效率问题, 同时解决了 SoC 内存带宽未充分利用和静态图约束等挑战.
论文的核心设计理念是 CPU 用于调度 GPU 和 NPU, GPU 和 NPU 用于推理, 具体优化策略如下:
1. 计算资源调度: 设计了合理的张量分区求解器. 比如 prefill 和 decode 阶段执行不同的张量划分策略, prefill 阶段, 更多使用 NPU. decode 阶段更多使用 GPU, 根据硬件特性来进行张量的分配. 对于不同异构设备的利用也可以平衡渲染任务和推理任务的 GPU 资源调度. GPU 支持动态 shape 张量的计算优化, NPU 不支持, 所以 NPU 更适合使用固定大小张量的计算. 譬如将 300 的输入序列拆分为 256(NPU) + 44(GPU)来计算. 根据算子特性分配到不同设备进行计算.
2. 通过共享内存减少数据拷贝的开销. 苹果 M/A 系列、高通骁龙系列等支持 CPU、GPU 和 NPU 的统一地址空间, 可以通过 OpenCL 在 CPU 和 GPU 之间建立共享内存, 并使用 QNN API 在 CPU 和 NPU 之间建立共享内存, 通过采用 "CL_MEM_USE_HOST_PTR" 标志, 还可以将 NPU 的共享内存映射到 GPU; 另一方面, 通过 CPU 轮询机制实现微妙级别的同步, 在异构设备完成计算后快速通知其他异构设备进行后续执行. 参见 [微信公众号--NerualTalk--HeteroLLM：利用移动端 SoC 实现 NPU-GPU 并行异构 LLM 推理！以 高通8 Gen 3的NPU GPU为例](https://mp.weixin.qq.com/s/E3yQZZPZwGTYvTiKh0efIQ) | +| 2024/07 | HeteroLLM 异构推理框架, CPU 用于调度 GPU 和 NPU, GPU 和 NPU 用于推理 | [HeteroLLM: Accelerating Large Language Model Inference on Mobile SoCs platform with Heterogeneous AI Accelerators](https://arxiv.org/abs/2501.14794) | 论文深入分析了 GPU 和 NPU 的硬件架构, 强调了 NPU 对张量形状敏感的性能特征. 遗憾的是, 现代 LLM 中的某些层(如 FFN-down 层)无法被 NPU 高效处理, 形成显著瓶颈. HeteroLLM 通过利用 GPU 弥补 NPU 的计算限制, 缓解了这些效率问题, 同时解决了 SoC 内存带宽未充分利用和静态图约束等挑战.
论文的核心设计理念是 CPU 用于调度 GPU 和 NPU, GPU 和 NPU 用于推理, 具体优化策略如下:
1. 计算资源调度: 设计了合理的张量分区求解器. 比如 prefill 和 decode 阶段执行不同的张量划分策略, prefill 阶段, 更多使用 NPU. decode 阶段更多使用 GPU, 根据硬件特性来进行张量的分配. 对于不同异构设备的利用也可以平衡渲染任务和推理任务的 GPU 资源调度. GPU 支持动态 shape 张量的计算优化, NPU 不支持, 所以 NPU 更适合使用固定大小张量的计算. 譬如将 300 的输入序列拆分为 256(NPU) + 44(GPU)来计算. 根据算子特性分配到不同设备进行计算.
2. 通过共享内存减少数据拷贝的开销. 苹果 M/A 系列、高通骁龙系列等支持 CPU、GPU 和 NPU 的统一地址空间, 可以通过 OpenCL 在 CPU 和 GPU 之间建立共享内存, 并使用 QNN API 在 CPU 和 NPU 之间建立共享内存, 通过采用 "CL_MEM_USE_HOST_PTR" 标志, 还可以将 NPU 的共享内存映射到 GPU; 另一方面, 通过 CPU 轮询机制实现微妙级别的同步, 在异构设备完成计算后快速通知其他异构设备进行后续执行. 参见 [微信公众号--NerualTalk--HeteroLLM: 利用移动端 SoC 实现 NPU-GPU 并行异构 LLM 推理！以 高通8 Gen 3的NPU GPU为例](https://mp.weixin.qq.com/s/E3yQZZPZwGTYvTiKh0efIQ) | ### 3.2.7 注意力机制 ------- -[微信公众号 - 地学 AI 实验室 - 可解释 AI，在 Transformer 中可视化注意力（附代码）](https://mp.weixin.qq.com/s/vwJEBXCk6GrwN9-BVucoQA) +[微信公众号 - 地学 AI 实验室 - 可解释 AI, 在 Transformer 中可视化注意力(附代码)](https://mp.weixin.qq.com/s/vwJEBXCk6GrwN9-BVucoQA) -[LLM 推理的 Attention 计算和 KV Cache 优化：PagedAttention、vAttention 等](https://www.51cto.com/aigc/1703.html) +[LLM 推理的 Attention 计算和 KV Cache 优化: PagedAttention、vAttention 等](https://www.51cto.com/aigc/1703.html) | 编号 | 时间 | 论文 | 描述 | @@ -490,7 +526,7 @@ ARM-software/ComputeLibrary | 日期 | 概要 | 论文 / 链接 | 团队 | 描述 | |:---:|:----:|----------:|:----:|:----:| -| 2025/10 | 通过分块量化和查找表等技术, 动态分配推理计算资源, 提升推理性能 |[Scaling LLM Test-Time Compute with Mobile NPU on Smartphones](https://arxiv.org/abs/2509.23324) | NA | 本文指出, NPU 在典型的 LLM 推理过程中, 其计算资源(尤其是矩阵乘法单元)未被充分利用. 为了利用这部分被浪费的计算能力, 论文提出在移动 NPU 上应用并行测试时计算扩展(指在模型推理阶段通过增加计算量来提升性能的技术)技术, 以提升小模型的性能. 然而, 该方法面临着 NPU 固有的挑战, 包括对细粒度量化(分组更小、更精细)的硬件支持不足, 以及通用计算(指不针对特定 AI 任务的常规计算, 如 Softmax 激活函数计算, NPU 在这类计算上效率通常低于专用矩阵计算）效率低下. 为解决这些问题, 论文引入了两项关键技术: 一是硬件感知的分块量化方案, 该方案将分组量化与 NPU 的内存访问模式对齐;
二是基于查找表的高效替代方案, 用于处理 Softmax 和反量化等复杂操作. [微信公众号--NerualTalk--端侧 NPU 的 LLM 测试时计算扩展：硬件感知块量化与 LUT 优化实现 19.0×GEMM与 2.2×Softmax 加速](https://mp.weixin.qq.com/s/QZNb1IZMN8M-X3VW7ZCndQ), [主仓库](https://github.com/haozixu/llama.cpp-npu), [算子库](https://github.com/haozixu/htp-ops-lib) | +| 2025/10 | 通过分块量化和查找表等技术, 动态分配推理计算资源, 提升推理性能 |[Scaling LLM Test-Time Compute with Mobile NPU on Smartphones](https://arxiv.org/abs/2509.23324) | NA | 本文指出, NPU 在典型的 LLM 推理过程中, 其计算资源(尤其是矩阵乘法单元)未被充分利用. 为了利用这部分被浪费的计算能力, 论文提出在移动 NPU 上应用并行测试时计算扩展(指在模型推理阶段通过增加计算量来提升性能的技术)技术, 以提升小模型的性能. 然而, 该方法面临着 NPU 固有的挑战, 包括对细粒度量化(分组更小、更精细)的硬件支持不足, 以及通用计算(指不针对特定 AI 任务的常规计算, 如 Softmax 激活函数计算, NPU 在这类计算上效率通常低于专用矩阵计算)效率低下. 为解决这些问题, 论文引入了两项关键技术: 一是硬件感知的分块量化方案, 该方案将分组量化与 NPU 的内存访问模式对齐;
二是基于查找表的高效替代方案, 用于处理 Softmax 和反量化等复杂操作. [微信公众号--NerualTalk--端侧 NPU 的 LLM 测试时计算扩展: 硬件感知块量化与 LUT 优化实现 19.0×GEMM与 2.2×Softmax 加速](https://mp.weixin.qq.com/s/QZNb1IZMN8M-X3VW7ZCndQ), [主仓库](https://github.com/haozixu/llama.cpp-npu), [算子库](https://github.com/haozixu/htp-ops-lib) | ## 3.4 长上下文 @@ -505,7 +541,7 @@ ARM-software/ComputeLibrary | 编号 | 内容 | 详情 | |:---:|:----:|:---:| | 1 | [Interactive Tools for machine learning, deep learning, and math](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | 用于机器学习、深度学习和数学运算的交互式工具. | -| 2 | [Visual Guides to understand the basics of Large Language Models](https://towardsdatascience.com/visual-guides-to-understand-the-basics-of-large-language-models-0715701bdd20) | 一系列工具与文章的汇编, 直观易懂地解读复杂的 AI 概念. 译文 [深入浅出：大语言模型的视觉解析 [译]](https://baoyu.io/translations/llm/visual-guides-to-understand-the-basics-of-large-language-models). | +| 2 | [Visual Guides to understand the basics of Large Language Models](https://towardsdatascience.com/visual-guides-to-understand-the-basics-of-large-language-models-0715701bdd20) | 一系列工具与文章的汇编, 直观易懂地解读复杂的 AI 概念. 译文 [深入浅出: 大语言模型的视觉解析 [译]](https://baoyu.io/translations/llm/visual-guides-to-understand-the-basics-of-large-language-models). | | 3 | [MLVisuals](https://github.com/dair-ai/ml-visuals) | [科研必备——上手 ML Visuals - 神经网络画图神器](https://blog.csdn.net/weixin_43499292/article/details/127030792) | ## 4.1 Tokenizer @@ -522,9 +558,9 @@ ARM-software/ComputeLibrary ### 4.1.2 Tokenizer ------- -[大模型分词：sentencepiece vs titoken](https://zhuanlan.zhihu.com/p/691609961) -[tokenizer（一）训练一个 LLM 分词器](https://zhuanlan.zhihu.com/p/688792019) -[Tokenizer 的系统梳理，并手推每个方法的具体实现](https://cloud.tencent.com/developer/article/2327739) +[大模型分词: sentencepiece vs titoken](https://zhuanlan.zhihu.com/p/691609961) +[tokenizer(一)训练一个 LLM 分词器](https://zhuanlan.zhihu.com/p/688792019) +[Tokenizer 的系统梳理, 并手推每个方法的具体实现](https://cloud.tencent.com/developer/article/2327739) [各种中文分词工具的使用方法](https://blog.csdn.net/PolarisRisingWar/article/details/125388765) [五款中文分词工具在线 PK: Jieba, SnowNLP, PkuSeg,THULAC, HanLP](https://zhuanlan.zhihu.com/p/64409753) @@ -532,7 +568,7 @@ ARM-software/ComputeLibrary |:---:|:-----:|:----:|:---:| | 1 | [sentencepiece](https://github.com/google/sentencepiece) | Google | Unsupervised text tokenizer for Neural Network-based text generation.
SentencePiece 是谷歌开源的针对 NLP 场景提取词汇表 tokenizer 的开源项目, 它是谷歌推出的子词开源工具包, 其中集成了 BPE、ULM 子词算法. 除此之外, SentencePiece 还能支持字符和词级别的分词. 更进一步, 为了能够处理多语言问题, sentencePiece 将句子视为 Unicode 编码序列, 从而子词算法不用依赖于语言的表示.
SentencePiece 提出的目的是在给定词汇表大小的前提下, 最大化词表信息编码 (词频 + 多样性)subword 编码. 比如英语中的 simple 和 simplify 这两个词意思是一样的, 是为了适应语法需求而有的变化, 所以使用独立的 token 对这两个单词编码是有冗余的, 另外一种场景是, 词频不一样, 有常用汉字一说, 也有常用英语单词一说. 出现较少的词使用独立的 token 在训练的时候相比其他高频词由于出现的太少而造成深度学习 (信息压缩) 这一过程容易丢失该信息. | | 2 | [huggingface/tokenizers](https://github.com/huggingface/tokenizers) | Hugging Face | NA | -| 3 | [openai/tiktoken](https://github.com/openai/tiktoken) | OpenAI | [OpenAI 开源 GPT-2 的子词标记化神器——tiktoken，一个超级快的（Byte Pair Encoder，BPE）字节对编码 Python 库](https://zhuanlan.zhihu.com/p/592399697), [OpenAI 大模型高效 Tokenizer: tiktoken](https://zhuanlan.zhihu.com/p/631840697) | +| 3 | [openai/tiktoken](https://github.com/openai/tiktoken) | OpenAI | [OpenAI 开源 GPT-2 的子词标记化神器——tiktoken, 一个超级快的(Byte Pair Encoder, BPE)字节对编码 Python 库](https://zhuanlan.zhihu.com/p/592399697), [OpenAI 大模型高效 Tokenizer: tiktoken](https://zhuanlan.zhihu.com/p/631840697) | | 4 | [mlc-ai/tokenizers-cpp](https://github.com/mlc-ai/tokenizers-cpp) | mlc-ai | 一个跨平移台的 C++ 分词器, 包装并 bind 了 HuggingFace 以及 sentencepiece, 并提供了最小的通用 C++ API. | | 5 | [rust-tokenizers](https://github.com/guillaume-be/rust-tokenizers) | guillaume-be | Rust-tokenizers 是一个高性能的 tokenizer 库, 支持多种现代语言模型, 包括 WordPiece、Byte-Pair Encoding (BPE) 和 Unigram (SentencePiece) 模型. 这些 tokenizer 广泛应用于自然语言处理领域, 特别是在 transformer 架构中. | | 6 | [OpenNMT/Tokenizer](https://github.com/OpenNMT/Tokenizer) | OpenNMT | 一个快速, 通用, 可定制的文本分词器, 支持 C++/Python, 依赖最小. 提供了多种功能, 包括可逆分词, 子词分词, 高级文本分段, 大小写管理以及保护序列等. | @@ -546,8 +582,8 @@ ARM-software/ComputeLibrary | 1 | [Gemma Scope](https://www.163.com/dy/article/J8GVD23005566WT8.html) | Google DeepMind | [Google DeepMind 发布大模型可视化工具 Gemma Scope](https://www.163.com/dy/article/J8GVD23005566WT8.html) | | 2 | [Inspectus](https://github.com/labmlai/inspectus) | labmlai | [探索语言模型的奥秘 - 体验 Inspectus 的强大视觉洞察力](https://github.com/labmlai/inspectus) | | 3 | [Transformer Explainer](https://github.com/poloclub/transformer-explainer) | poloclub | 通过互动可视化的方式了解生成式 AI 中 Transformer 的工作原理. 他在浏览器中实时运行一个 GPT-2 模型, 允许用户使用自己的文本进行试验, 并实时观察 Transformer 的内部组件和操作如何协同工作来预测下一个 Token, 在线体验地址 [transformer-explainer/](https://poloclub.github.io/transformer-explainer) | -| 4 | [BertViz](https://github.com/jessevig/bertviz) | Jessevig | 使用交互式的方式, 可视化 Transformer 语言模型 (如 BERT, GPT2) 的注意力机制, 可在 Jupyter 或 Colab 中运行, 通过简单的 Python API 支持大多数 Hugging Face 预训练模型 (如 BERT, GPT2, T5 等), BertViz 扩展了 Llion Jones 的 Tensor2Tensor 可视化工具, 提供了头视图, 模型视图, 神经元视图等多个不同的可视化方式, 每个视图都提供了一个独特的视角来了解注意力机制. 参见 [2019/04/11, Human-Computer Interaction (cs.HC), Visualizing Attention in Transformer-Based Language Representation Models](https://arxiv.org/abs/1904.02679) 和 [可解释 AI，在 Transformer 中可视化注意力（附代码）](https://mp.weixin.qq.com/s/vwJEBXCk6GrwN9-BVucoQA). | -| 5 | [LLM Visualization](https://github.com/bbycroft/llm-viz) | bbycroft | 将 Transformer 原理的详细细节通过交互可视化的方式一步步显示出来, 详细的展示了每一步的数学原理, 模型的网格结构, 参数构造的运行过程, 可以精确到每一步观察大模型运行的运算以及数据的变化. 作者的 [仓库 bbycroft/llm-viz](https://github.com/bbycroft/llm-viz) 以及 [在线演示地址 bbycroft.net/llm](https://bbycroft.net/llm), [@HansChanX](https://x.com/HansChanX) LLM 可视化演的中文翻译版本: [仓库 czhixin/llm-viz-cn](https://github.com/czhixin/llm-viz-cn) 以及 [示](https://llm-viz-cn.iiiai.com/llm). 其他 [Vaaaas/llm-viz-CN](https://github.com/Vaaaas/llm-viz-CN), 知乎报道 [矩阵模拟！Transformer 大模型 3D 可视化，GPT-3、Nano-GPT 每一层清晰可见](https://zhuanlan.zhihu.com/p/670287271) | +| 4 | [BertViz](https://github.com/jessevig/bertviz) | Jessevig | 使用交互式的方式, 可视化 Transformer 语言模型 (如 BERT, GPT2) 的注意力机制, 可在 Jupyter 或 Colab 中运行, 通过简单的 Python API 支持大多数 Hugging Face 预训练模型 (如 BERT, GPT2, T5 等), BertViz 扩展了 Llion Jones 的 Tensor2Tensor 可视化工具, 提供了头视图, 模型视图, 神经元视图等多个不同的可视化方式, 每个视图都提供了一个独特的视角来了解注意力机制. 参见 [2019/04/11, Human-Computer Interaction (cs.HC), Visualizing Attention in Transformer-Based Language Representation Models](https://arxiv.org/abs/1904.02679) 和 [可解释 AI, 在 Transformer 中可视化注意力(附代码)](https://mp.weixin.qq.com/s/vwJEBXCk6GrwN9-BVucoQA). | +| 5 | [LLM Visualization](https://github.com/bbycroft/llm-viz) | bbycroft | 将 Transformer 原理的详细细节通过交互可视化的方式一步步显示出来, 详细的展示了每一步的数学原理, 模型的网格结构, 参数构造的运行过程, 可以精确到每一步观察大模型运行的运算以及数据的变化. 作者的 [仓库 bbycroft/llm-viz](https://github.com/bbycroft/llm-viz) 以及 [在线演示地址 bbycroft.net/llm](https://bbycroft.net/llm), [@HansChanX](https://x.com/HansChanX) LLM 可视化演的中文翻译版本: [仓库 czhixin/llm-viz-cn](https://github.com/czhixin/llm-viz-cn) 以及 [示](https://llm-viz-cn.iiiai.com/llm). 其他 [Vaaaas/llm-viz-CN](https://github.com/Vaaaas/llm-viz-CN), 知乎报道 [矩阵模拟！Transformer 大模型 3D 可视化, GPT-3、Nano-GPT 每一层清晰可见](https://zhuanlan.zhihu.com/p/670287271) | | 6 | [Machine-Learning-Tokyo/Interactive_Tools](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | Machine-Learning-Tokyo | 这个项目收集了各种用于机器学习、深度学习和数学的交互式工具. | | 7 | [hahnyuan/LLM-Viewer](https://github.com/hahnyuan/LLM-Viewer) | hahnyuan | 一个可视化语言与学习模型 LLMs 并分析在不同硬件平台上性能的工具. 可以进行网络级分析, 考虑峰值内存消耗和总推理时间成本等因素. 使用 LLM-Viewer, 可以获取 LLM 推理和性能优化的宝贵见解. 可以在 Web 浏览器或者命令行(CLI) 工具中使用. 在线体验地址 [LLM-Viewer Web](http://llm-viewer.com). 参见论文 [LLM Inference Unveiled: Survey and Roofline Model Insights](https://arxiv.org/abs/2402.16363). | | 8 | [A collection of my study notes for learners](https://www.k-a.in/notes.html) | k-a.in | Transformer/MoE Visualized | @@ -557,13 +593,19 @@ ARM-software/ComputeLibrary | 12 | Logit Lens | NA | [2023/03/14, Eliciting Latent Predictions from Transformers with the Tuned Lens](https://arxiv.org/abs/2303.08112), [AlignmentResearch/tuned-lens](https://github.com/AlignmentResearch/tuned-lens) 和 [2025/02/24, LogitLens4LLMs: Extending Logit Lens Analysis to Modern Large Language Models](https://arxiv.org/abs/2503.11667), [zhenyu-02/LogitLens4LLMs](https://github.com/zhenyu-02/LogitLens4LLMs), 其他 [SullivanCastro/Logit-Lens](https://github.com/SullivanCastro/Logit-Lens), [arnab-api/Logit-Lens-Interpreting-GPT-2](https://github.com/arnab-api/Logit-Lens-Interpreting-GPT-2), [msakarvadia/Attentionlens](https://github.com/msakarvadia/Attentionlens) | | 13 | [ReasonGraph](https://github.com/ZongqianLi/ReasonGraph) | NA | [ReasonGraph: Visualisation of Reasoning Paths](https://arxiv.org/abs/2503.03979) | | 14 | [torchvista](https://github.com/sachinhosmani/torchvista) | 可视化交互式工具, 可以直接在 NodeBook 中可视化 PyTorch 模型的前向传播过程. 支持拖拽 / 缩放等交互, 并且可以在出现错误时进行部分可视化, 用户可直接点击节点查看参数和属性信息. | -| 15 | [NN-SVG/](http://alexlenail.me/NN-SVG) | NA | [介绍两款生成神经网络架构示意图的工具：NN-SVG 和 PlotNeuralNet](https://blog.csdn.net/weixin_41896770/article/details/132733991) | -| 16 | [Machine Learning Visualized](https://ml-visualized.com) | NA | +| 15 | [NN-SVG/](http://alexlenail.me/NN-SVG) | NA | [介绍两款生成神经网络架构示意图的工具: NN-SVG 和 PlotNeuralNet](https://blog.csdn.net/weixin_41896770/article/details/132733991) | +| 16 | [Machine Learning Visualized](https://ml-visualized.com) | 机器学习入门时最常遇到的困境是什么? 要么是教程内容空洞无物, 看完依然不得要领; 要么是直接抛出代码, 运行后仍不理解其内在逻辑. [Machine Learning Visualized](https://github.com/gavinkhung/machine-learning-visualized), 它将算法的训练过程以可视化方式呈现, 权重如何更新、模型如何收敛, 都直观展示, 没有隐藏. 获得的内容包括: 1️⃣ 神经网络、逻辑回归、感知器的完整实现; 2️⃣ 从第一性原理出发的推导过程, 公式步骤完整; 3️⃣ 交互式笔记本, 可实时调整参数观察变化; 4️⃣ 涵盖PCA、K-means、梯度下降等核心算法; | | 17 | [AttentionViz]() | | | 18 | [DODRIO](https://poloclub.github.io/dodrio) |[DODRIO: Exploring Transformer Models with Interactive Visualization](http://arxiv-download.xixiaoyao.cn/pdf/2103.14625.pdf), [【NLP】可交互的 Attention 可视化工具！我的 Transformer 可解释性有救了？](https://blog.csdn.net/fengdu78/article/details/116617948) | -| 19 | [AttentionViz]() | NA | [AttentionViz: A Global View of Transformer Attention](https://arxiv.org/abs/2305.03210), [CSDN-AttentionViz: A Global View of Transformer Attention 论文学习，可视化、了解 Transformer 中的注意力机制](https://blog.csdn.net/weixin_48334973/article/details/137968878), [AttentionViz: 一个可视化 Transformer 注意力机制的强大工具](https://www.dongaigc.com/a/attentionviz-visualizing-transformer-attention)
AttentionViz 的核心理念是将 Transformer 模型中用于计算注意力的查询 (query) 和键 (key) 向量进行联合嵌入可视化. 与以往的注意力可视化技术不同, AttentionViz 能够分析多个输入序列的全局模式, 为研究人员提供了一个前所未有的视角来理解模型的内部运作. | +| 19 | [AttentionViz]() | NA | [AttentionViz: A Global View of Transformer Attention](https://arxiv.org/abs/2305.03210), [CSDN-AttentionViz: A Global View of Transformer Attention 论文学习, 可视化、了解 Transformer 中的注意力机制](https://blog.csdn.net/weixin_48334973/article/details/137968878), [AttentionViz: 一个可视化 Transformer 注意力机制的强大工具](https://www.dongaigc.com/a/attentionviz-visualizing-transformer-attention)
AttentionViz 的核心理念是将 Transformer 模型中用于计算注意力的查询 (query) 和键 (key) 向量进行联合嵌入可视化. 与以往的注意力可视化技术不同, AttentionViz 能够分析多个输入序列的全局模式, 为研究人员提供了一个前所未有的视角来理解模型的内部运作. | | 20 | [nndeploy](https://github.com/nndeploy/nndeploy) | NNDeploy | 基于工作流的多平台 AI 部署工具, 简化 AI 模型的部署流程. [nndeploy: 易用、高性能、支持多端的 AI 推理部署框架](https://zhuanlan.zhihu.com/p/1913542783903438653). | - +| 21 | [how-llms-work](https://github.com/ynarwal/how-llms-work) | 一个可视化、互动的大型语言模型构建指南——从原始互联网文本到对话式助手. [在线网站](https://ynarwal.github.io/how-llms-work) | +| 22 | [LLM Visualized](https://www.llm-visualized.com) | +| 23 | [](https://www.llmviz.studio) | +| 24 | [](https://github.com/sachinhosmani/torchvista) | +| 25 | [](https://github.com/ImagineAILab/ai-by-hand-excel) | +| 26 | [Awesome LLM Interpretability ](https://github.com/JShollaj/awesome-llm-interpretability) | 大语言模型内部是如何工作的, 为什么会产生幻觉, 为什么有时答非所问, 想深入了解这些. Awesome LLM Interpretability 这份资源合集, 提供一整套拆解 AI 黑盒的系统路径. 涵盖从注意力可视化、神经元分析到稀疏自编码器等研究方向, 帮我们了解大语言模型全貌. 还收录了 TransformerLens、LIT 可视化平台、Neuron Viewer 等大量可视化调试工具. 同时整理了可解释性、特征稀疏性、知识编辑等方向的论文, 并附带相关学习讨论入口. | +| 27 | [2020/12/17, Jay Alammar, Interfaces for Explaining Transformer Language Models](https://jalammar.github.io/explaining-transformers), [2026/07/09, 微信公众号-精博士小酒馆, 解释 Transformer 语言模型的交互界面](https://mp.weixin.qq.com/s/Ti63Dg3ACtv3W9SUWO1nIA)
[2021/01/19, Jay Alammar, Finding the Words to Say: Hidden State Visualizations for Language Models](https://jalammar.github.io/hidden-states). [2026/07/10, 微信公众号-精博士小酒馆, 语言模型的隐藏状态可视化](https://mp.weixin.qq.com/s/5FAO57YCl_MNaJ_9sDTxaw) | ## 4.3 评测平台 ------- @@ -603,6 +645,42 @@ ARM-software/ComputeLibrary | [浅显易懂地介绍 llm.c [译]](https://baoyu.io/translations/llm/explaining-llm-c-in-layman-terms) | [Explainable Language Models: Existing and Novel Approaches](https://twitter.com/karpathy/status/1778153659106533806) 的译文, 参见 [karpathy/llm.c](https://github.com/karpathy/llm.c). | | [DefTruth/Awesome-LLM-Inference](https://github.com/DefTruth/Awesome-LLM-Inference) | 收集了大量 LLM 推理相关的论文和仓库, 涵盖了并行计算, 量化压缩, 注意力机制优化, 上下文管理等. | | [SylphAI-Inc/llm-engineer-handbook](https://github.com/SylphAI-Inc/llm-engineer-handbook) | NA | +| [《动手学大模型》系列编程实践教程](https://github.com/Lordog/dive-into-llms) | 《动手学大模型》系列编程实践教程, 由上海交通大学《自然语言处理前沿技术》(NIS8021)、《人工智能安全技术》课程(NIS3353)讲义拓展而来(教师: 张倬胜), 旨在提供大模型相关的入门编程参考. | +| [大型语言模型的强化学习, 2025年春季](https://ernestryu.com/courses/RL-LLM.html) | 加州大学这课, 理论+实战, 把 RL 和 LLM 训练从零到一拆成渣. 教你 MDP、PPO 算法、RLHF 全流程, 还有 Jupyter 代码实操. UCLA教授主讲, 视频+作业都有, 学完直接上手. | +| [深度学习笔记](https://github.com/jshn9515/deep-learning-notes) | 《动手学深度学习》是很好的入门书, 但更新速度已经有些跟不上这个领域的发展. Transformer 之后, CLIP、Diffusion、vLLM 等等内容越来越多, 网上资料虽然丰富, 却很零散, 今天看 Attention, 明天学 LoRA, 后天又去读扩散模型. 最后留下的往往只是碎片, 很难真正串成体系. | +| [How to Train Your GPT](https://github.com/raiyanyahya/how-to-train-your-gpt) | 这是一本 12 章、7500 行+的互动教材, 教你如何从零开始构建、训练和运行现代语言模型. 除了章节外, 还有 15 个独立的主题解释, 深入介绍了所有技巧: RoPE、attention、RMSNorm、SwiGLU、KV 缓存、AdamW、混合精度等. 每个解释器都遵循相同的风格. +你不会只读到关于变形金刚的介绍. 你会自己写每一行: 分词器、嵌入、注意、训练循环、推理引擎. 每一行都有注释说明它的用途和存在原因. | +| [深度学习论文精读](https://github.com/mli/paper-reading) | 沐神逐段精读深度学习经典和新论文, 录成视频讲解, 已更新 3 年多. 项目收录了 GPT-4、Llama 3.1、Sora、DALL·E 2、Instruct GPT、Whisper、Chain of Thought 等重磅论文的精读视频, 每个视频都是 1 小时左右的深度讲解, 逐段拆解论文内容. 视频同步更新在 B 站和 YouTube, 还包括多模态论文串讲、CLIP 改进工作串讲等系列内容. 除了论文精读, 还有大模型时代下做科研的思路分享、研究方法论等内容. 适合想深入理解经典论文、跟进前沿进展的 AI 研究者和开发者. | +| [duoan/TorchCode](https://github.com/duoan/TorchCode) | 开源题库 TorchCode: 把"手写深度学习算子"做成 LeetCode 式训练. 基于 Jupyter, 精选 40 题: 从基础算子 → Attention → 完整 Transformer → 训练优化. ⚡ 自动评测: 实时核对输出、梯度流、数值稳定性. 💡 卡住看提示, 做完看参考实现. 🚀 Docker 一键起 / Hugging Face 在线跑 / Google Colab 直接开刷. | +| [v9ai/ai-engineer-roadmap](https://github.com/v9ai/ai-engineer-roadmap) | 学 AI 工程的资料散落在各处, 缺乏一条从基础到生产的清晰路径. 这个项目整理了 108 节课、15 个主题, 做成了一个带搜索、知识图谱和 AI 辅导的在线学习平台. 这套 AI 工程课程体系, 内容从 Transformer 底层一直讲到怎么在生产环境部署 RAG 和 Agent. 课程本身用语义搜索和全文搜索双引擎做检索, 知识图谱把概念按前置/后续关系连起来. | +| [AI Engineering from Scratch](https://aiengineeringfromscratch.com) | [Learn it. Build it. Ship it for others.](https://github.com/rohitg00/ai-engineering-from-scratch) | +| [500 artificial intelligence project list with code](https://github.com/ashishpatel26/500-AI-Machine-learning-Deep-learning-Computer-vision-NLP-Projects-with-code) | 把 500 多个 AI/机器学习项目全部汇总到了一起, 最关键的是: 全部附带源码. 无论你是想丰富简历, 还是单纯想通过实战进阶, 这一个仓库就够了: ① 覆盖面极广: 从时间序列预测、情感分析, 到目标检测、生成对抗网络(GAN), 几乎涵盖了所有主流方向; ② 实战导向: 每一个项目都不是空谈理论, 是直接给代码, 上手就能跑. ③ 新手友好: 包含了 30 个 Python 实战练习和大量的深度学习入门案例; ④ 进阶必备: 还有专门针对生产环境的 ML 系统构建指南, 含金量非常高. | +| [图解大模型算法](https://github.com/changyeyu/LLM-RL-Visualized) | 🌟100+ 原创 LLM / RL 原理图📚, 《大模型算法》作者巨献！ | +| [人工智能基础设施工程师——学习路径](https://github.com/ai-infra-curriculum/ai-infra-engineer-learning) | 该仓库包含了成为人工智能基础设施工程师的完整 、生产准备学习路径. 通过全面的模块、真实项目以及带有教育性待办事项注释的生产级代码小作品, 你将培养大规模构建、部署和维护机器学习基础设施所需的技能. | +| [机器学习/人工智能面试准备——完整指南](https://github.com/girijesh-ai/ai-interview-codex) | 一套全面的机器学习和人工智能面试准备材料, 涵盖机器学习编码、系统设计、大型语言模型/生成式人工智能和数据结构分析. | +| [AmberLJC/LLMSys-PaperList](https://github.com/AmberLJC/LLMSys-PaperList) | 一份精选的大型语言模型系统相关学术论文、文章、教程、幻灯片和项目列表. | +| [Hands-On Large Language Models](https://github.com/HandsOnLLM/Hands-On-Large-Language-Models) | 此外还有中文版本 [Hands-On Large Language Models CN(ZH) -- 动手学大模型](https://github.com/bbruceyuan/Hands-On-Large-Language-Models-CN). | +| [Train LLM From Scratch](https://github.com/FareedKhan-dev/train-llm-from-scratch) | [Master Full-Stack AI Engineering From First Principles to Production](https://dailydoseofds.github.io/ai-engg-book) 想学大语言模型的底层原理, 网上的教程要么纯讲理论, 要么直接丢个开源模型让你微调, 真正从零手写训练的实战教程太少了. 偶然找到 train-llm-from-scratch 这个项目, 手把手教你用 PyTorch 从零实现一个 Transformer 模型, 在单张显卡上就能完成训练. 从注意力机制、多层感知机到完整的 Transformer 架构, 每个模块都有详细的代码和原理图解, 跟着做就能训出一个能说人话的语言模型. 训练数据用的是 Pile 开源数据集, 涵盖书籍、论文、代码等多种来源. 如果你想搞懂大模型是怎么工作的, 而不只是停留在调用接口的阶段, 这份教程值得跟着动手练一遍. | +| [Resources to learn AI](https://github.com/ArturoNereu/AI-Study-Group) | 学习人工智能的资源. | +| [AI/ML Bookshelf](https://github.com/AniruddhaChattopadhyay/Books) | 13 本免费 AI 书籍.包括 LLM 基础、强化学习、深度学习面试、机器学习数学、OpenAI Agent指南、纸笔机器学习、微调大语言模型、多 Agent 强化学习、ML 系统工程. | +| [girijesh-ai/ai-interview-codex](https://github.com/girijesh-ai/ai-interview-codex) | ML/AI 面试综合技能库, 包含迭代系统设计、生产就绪代码和2026标准. 涵盖 LLM/GenAI、RAG 系统、Agentic AI 和算法从零实现. 包含 LLM 基础知识(推理优化等)、MCP 面试准备指南、系统设计、算法和实战代码示例. | +| [21 Lessons teaching everything you need to know to start building Generative AI applications](https://microsoft.github.io/generative-ai-for-beginners) | 微软的 《Generative AI for Beginners: 面向初学者的生成式人工智能课程》 | +| [AI Infrastructure Engineer - Learning Path](https://github.com/ai-infra-curriculum/ai-infra-engineer-learning) | 通过实践项目和实践学习, 掌握人工智能基础设施工程 | +| [强化学习的数学基础](https://github.com/MathFoundationRL/Book-Mathematical-Foundation-of-Reinforcement-Learning) | 开源书《强化学习的数学基础》 给你画出一条清清楚楚的路线: 从数学入手, 把 RL 的核心逻辑掰开揉碎了喂给你. 全书从头到尾就用一个经典的"网格世界"案例做示范, 每个算法的推导都一步步拆开来讲, 不跳步、不绕弯子. 数学深度的分寸拿捏得特别到位——该严格的地方绝不糊弄, 该简化的地方也不硬撑, 目标就是让你真正吃透每个知识点. | +| [AI 通识课 · AI Essentials](https://github.com/buynao/aipath) | [为中文学习者设计的 AI 入门课](https://aipath.buynao.com) +用可视化和交互演示, 把 AI 的核心原理装进你的直觉 —— 从"神经网络是什么"到亲手搭出 AI 应用, 每课 20 分钟. | +| [Learn AI/ML Interactively](http://github.com/genieincodebottle/generative-ai) | 想系统学习生成式 AI, 网上找到资料过于零散, 或者只讲理论没有实战, 学习效率很低. 在寻找的众多资料中, generative-ai 脱颖而出, 提供了一份全景式的 AI 学习与实战指南. 涵盖大语言模型基础、向量嵌入、提示词工程等核心概念, 每个知识点都配有文档和代码. 收录了 20 多个项目案例, 包括多种高级检索增强生成(RAG)模式、多智能体系统搭建、自然语言转 SQL 查询、情感分析等, 都能直接跑起来. 还整理了 AWS、Azure、Google Cloud 三大云平台的部署指南, 以及面试题库和职业路径建议. | +| [LLM Notes](https://github.com/Fyrgo8/llm-notes) | 大模型学习笔记仓库, 涵盖八股面试、Agent 工程、RL 训练、算法方向选择等主题. | +| [Build a Large Language Model (From Scratch)](https://github.com/rasbt/LLMs-from-scratch) | 想真正把 LLM 从零手写到能预训练 + 微调？ Stanford CS336《Language Modeling from Scratch》建立理论框架和 muscle memory, 今天补上这个工程实现神器——《Build a Large Language Model (From Scratch)》官方配套代码仓库. 两者结合, 基本能把 LLM 底层吃透. | +| [Introduction to Statistical Learning with Python - Study Journey](https://github.com/0xHadyy/isl-python) | 作者阅读 《An Introduction to Statistical Learning》这本经典统计学习入门书的学习过程笔记. 按章节把 ISL 和补充的 ESL 内容用 Python 实现出来. 涵盖回归、分类、重抽样、正则化、非线性模型等章节, 每章都配着对应代码实现和笔记, 还标了完成日期. 仓库里还整理了原书 PDF 链接和补充的机器学习数学推导资料, 方便对照着学. 适合正在看这本书、想找个进度参照或代码实现例子的朋友, 跟着一起学习. | +| [Intelligence for Beginners - A Curriculum](https://github.com/microsoft/AI-For-Beginners) | 一份 AI 入门课程, 12 周 24 课, 从符号主义讲到神经网络、CNN、RNN、GAN, 甚至还有遗传算法和多智能体系统. 之前一直觉得 AI 太庞杂不知道该从哪块切入, 结果这份课程把整个知识树按照"理解-动手-伦理"串起来了, 每个 lesson 都配了 PyTorch 和 TensorFlow 双版本 notebook, 还有 lab 和 quiz. 最惊喜的是连“经典 AI”那部分也没跳过, 知识表示和专家系统直接给了可运行的笔记本. 对于想系统补全 AI 知但怕碎片化的人来说, 等于拿到了一个经过精心编排的完整地图. | +| [《Agentic AI 漫游指南》 ](https://arxiv.org/pdf/2606.24937) | 虽然也有基础知识, 但作者明显没有把主要篇幅放在那些已经被反复讲过的概念上, 而是一路讲到强化学习 RL、推理 Reasoning、评测 Evaluation, 最后才进入 Agentic AI. 所以它更像一本帮你理解 AI 工作机制的书, 而不是一本教你「怎么用 AI 工具」的操作手册. 如果你已经不满足于只会用 ChatGPT、Claude、Cursor, 想进一步理解 AI 为什么能推理、怎么被训练、如何被评测, 以及 Agent 到底是怎么跑起来的, 这本书挺值得收藏. | +| [Advanced NLP Spring 2026 Code](https://github.com/cmu-l3/anlp-spring2026-code) | CMU 这门 NLP 课最硬核的地方: 第一份作业就让你从零手搓一个 LLaMA. 卡内基梅隆大学公开了 [2026 春季《Advanced NLP》课程](https://cmu-l3.github.io/anlp-spring2026), 教授是 Sean Welleck. 整套资源包括完整课程主页、课件、视频和配套代码, 内容从 Tokenizer、Transformer、语言模型基础, 一路讲到 RAG、多模态、RLHF、MoE、长上下文和 test-time scaling. 这门课最有价值的地方, 不仅是教你怎么调用大模型 API, 而且把大模型能力背后的工程路径也拆开给你看. 从「Build Your Own LLaMA」这种手搓模型作业, 到后面的推理、效率、评测和 Agent, 它训练的其实是一种更底层的能力: 你能不能理解模型为什么能工作, 为什么会变强, 为什么有时会失败. 这也很符合现在 AI 的技术拐点. 过去大家更关心参数规模, 谁的模型更大; 现在越来越多关键进展, 开始发生在推理侧、效率侧和系统侧: 怎么让模型更会思考, 怎么调度专家, 怎么检索外部知识, 怎么在有限算力下获得更好的输出. 所以这门课不只是 NLP 进阶课, 更像一份 2026 年大模型研究者的训练路线图. AI 时代真正的分水岭, 可能不只是会不会使用模型. [YouTube-CMU Advanced NLP Spring 2026](https://www.youtube.com/playlist?list=PLqC25OT8ZpD15emhQhNjRLym77-sp2kAx) | +| [大模型基础](https://github.com/ZJU-LLMs/Foundations-of-LLMs) | 分享一本通俗好读的开源书《大模型基础》. 从大语言模型入门到架构演化, 再到 Prompt 工程、参数高效微调、模型编辑、检索增强生成(RAG)等关键技术, 一本串起来. 全书 6 章, 每章以一种动物为线索, 配合案例讲透核心方法, 读起来更直观、更容易上手. | +| [Unpacking ChatGPT(拆开 GPT)](https://github.com/aa1143/unpacking-chatgpt) | 本仓库统一管理系列的公众号文章、视频脚本、白板与分镜、封面、社交平台文案、参考资料和发布记录. 用后端工程师的视角, 把 ChatGPT 从模型原理到工程应用讲明白. 《拆开 GPT》是一套面向非专业读者的中文科普系列. 每一期从一个具体问题出发, 只解释一个核心概念, 并把模型原理连接到真实的产品现象和工程实践.
1. 第一阶段: ChatGPT 怎么回答问题——Token、Embedding、位置、Attention、Transformer、生成.
2. 第二阶段: ChatGPT 怎么获得能力——预训练、损失函数、反向传播、指令微调、RLHF、DPO.
3. 第三阶段: ChatGPT 如何成为产品——幻觉、上下文、RAG、工具调用、Agent、AI 编程. | +| [2024/10/19, Rohit Patel, Understanding LLMs from Scratch Using Middle School Math](https://towardsdatascience.com/understanding-llms-from-scratch-using-middle-school-math-e602d27ec876/) | 本文来自于Rohit Patel，作者是Meta 数据科学总监兼 GenAI。用尽可能简单的描述，解释了LLMs的构建和工作原理. 经典长文, 内部有很多译文. 推荐阅读 [2026/05/04, 微信公众号--AI大模型应用实践, 中学生就能看懂：从零开始理解LLM内部原理【十四，大结局】｜理解 Transformer 架构](https://mp.weixin.qq.com/s/ixtL65L50QPmtaxRQ57drA), [2024/12/20, 微信公众号--数据派THU, 独家 | 用初中数学从零开始理解大语言模型(下)](https://mp.weixin.qq.com/s/Jf9TkeXgc5JpVelmvvNZTg), [2025/01/08, 微信公众号--丁师兄大模型, LLM工作原理，很直观很好懂!](https://mp.weixin.qq.com/s/iIZF58iFHXqU15n8_4nEOg)
其他类似的还有很多, [2024/11/30, 微信公众号--中国指挥与控制学会, CICC科普栏目｜用初中数学理解LLM工作原理](https://mp.weixin.qq.com/s/8BkNM2F0SYDJ4HPyk-ulHA), [2025/03/20, 微信公众号--数科纵横, 《使用中学数学从头开始理解LLM》](https://mp.weixin.qq.com/s/HjgOPRkbVFVBHJ4YKHzB9A), [2025/01/05, 微信公众号--林锵锵, 使用初中数学从零开始理解 LLMs](https://mp.weixin.qq.com/s/OEfhumiSYgLP5Tlmni-Rfw), [2025/09/05, 微信公众号--Ai学习的老章, 用初中数学从零理解大模型](https://mp.weixin.qq.com/s/PMJX7w_4-EPAjPUo9h0wHQ), [2024/11/30, 微信公众号--数学中国, 用初中数学理解LLM工作原理](https://mp.weixin.qq.com/s/vofXHc5UsM2izj_J9CJ16g). | +| [2026/07/02, 「用初中数学讲明白AI」连载系列](https://mp.weixin.qq.com/s/p5pKX9HRQATs8cpQXG_xEg) | 微信公众号--AI Native 启示录的连载博文, 从另外一个维度讲解 LLM 的原理, 其他类似文章 [2025/11/12, 微信公众号--林间有风, 白话Transformer（上](https://mp.weixin.qq.com/s/vqvr-1YVn9mIW2ZOdvfTDQ), [2026/01/08, 微信公众号--戴戴向前冲, 如何只用初中数学讲清楚大语言的原理](https://mp.weixin.qq.com/s/o30u71WGGgLvVIOvs-9hIw), [2024/01/01, 微信公众号--AINLPer, 揭秘 Transformer 的数学原理](https://mp.weixin.qq.com/s/qVZqwpD7ngdSX-UzIj68hw), [2025/09/24, 微信公众号--IRR 实验室, 如何用中学知识理解大模型技术原理](https://mp.weixin.qq.com/s/QyotH4Fw3Ybl72-eGSBnfA) | + ## 5.2 Survey ------- @@ -617,16 +695,16 @@ ARM-software/ComputeLibrary |:---:|:----:|:------:|:---:|:------:|:----:| | 2024/03/01 | 综述 | [NiuTrans/ABigSurveyOfLLMs](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | 一个关于大语言模型的综合性调研集合, 包含 150 多篇关于 LLM 的调研论文. 这些调研涵盖了 LLM 的各个方面, 包含通用调研, Transformer, 对齐, 提示学习, 上下文学习, 推理链, 提示工程, 数据, 评估, 社会问题, 安全性, 幻觉, 属性, 高效 LLM, 学习方法, 多模态 LLM, 基于知识的 LLM, 检索增强型 LLM, 知识编辑, LLM 扩展, LLM 与工具, LLM 与交互, 长序列 LLM, 以及 LLM 在教育, 法律, 医疗, 游戏, NLP 任务, 软件工程, 推荐系统, 图谱等领域的应用. | | 2024/01/16 | 多模态 | [A Survey of Resource-efficient LLM and Multimodal Foundation Models](https://arxiv.org/abs/2401.08092) | Mengwei Xu | [UbiquitousLearning](https://github.com/UbiquitousLearning/Efficient_Foundation_Model_Survey) | 一篇关于资源高效的大模型和多模态基础模型的综述论文. 论文涵盖了算法和系统两个方面的创新, 包括了高校的模型架构, 训练算法, 推理算法和模型压缩等内容. | -| 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. [知乎 - 无影寺 -【LLM / 大模型】大语言模型效率谱：算法综述(](https://zhuanlan.zhihu.com/p/671376104) | +| 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. [知乎 - 无影寺 -【LLM / 大模型】大语言模型效率谱: 算法综述(](https://zhuanlan.zhihu.com/p/671376104) | | 2024/04/22 | 效率提升 | [A Survey on Efficient Inference for Large Language Models](https://arxiv.org/abs/2404.14294) | Zixuan Zhou | NA | 1. [如何加速大模型推理？万字综述全面解析大语言模型高效推理技术](https://www.sohu.com/a/790365299_121119001)
2. [知乎 -- 罗清雨 -- 大语言模型高效推理综述](https://zhuanlan.zhihu.com/p/707685591)
3. [LLM 推理加速调研](https://zhuanlan.zhihu.com/p/699776257) | -| 2024/05/23 | 效率提升 | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等
1. [知乎 -- 黄浴 -- 高效大语言模型：综述](https://zhuanlan.zhihu.com/p/671710012)
2. [知乎 -- 磐石 -- 大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)
3. [知乎 -- 享享学 AI-- 大模型 LLM 微调技术方法汇总！](https://zhuanlan.zhihu.com/p/673675939)
4. [CSDN-rommel rain-Efficient Large Language Models: A Survey](https://blog.csdn.net/qq_52024723/article/details/143415741) | +| 2024/05/23 | 效率提升 | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等
1. [知乎 -- 黄浴 -- 高效大语言模型: 综述](https://zhuanlan.zhihu.com/p/671710012)
2. [知乎 -- 磐石 -- 大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)
3. [知乎 -- 享享学 AI-- 大模型 LLM 微调技术方法汇总！](https://zhuanlan.zhihu.com/p/673675939)
4. [CSDN-rommel rain-Efficient Large Language Models: A Survey](https://blog.csdn.net/qq_52024723/article/details/143415741) | | 2024/05/17 | 效率提升
多模态 | [Efficient Multimodal Large Language Models: A Survey](https://arxiv.org/abs/2405.10739), [CSDN - 星夜 Zn-Efficient Multimodal Large Language Models: A Survey (高效多模态大型语言模型综述 - 全文翻译)](https://blog.csdn.net/qq_29868553/article/details/144163118), [知乎 - 吕阿华 -【MLLM 研究综述】《Efficient Multimodal Large Language Models: A Survey》——腾讯最新多模态大模型综述](https://zhuanlan.zhihu.com/p/701495021) | -| 2023/06/23 | 多模态 | [A Survey on Multimodal Large Language Models](https://arxiv.org/abs/2306.13549) | Shukang Yin | [BradyFU](https://github.com/BradyFU/Awesome-Multimodal-Large-Language-Models) | 本综述中主要介绍了多模态幻觉、多模态上下文学习 (Multimodal InContext Learning，M-ICL)、多模态思维链(Multimodal Chain of Thought，M-CoT) 和 LLM 辅助的视觉推理 (LLM-Aided Visual Reasoning，LAVR) 等. | +| 2023/06/23 | 多模态 | [A Survey on Multimodal Large Language Models](https://arxiv.org/abs/2306.13549) | Shukang Yin | [BradyFU](https://github.com/BradyFU/Awesome-Multimodal-Large-Language-Models) | 本综述中主要介绍了多模态幻觉、多模态上下文学习 (Multimodal InContext Learning, M-ICL)、多模态思维链(Multimodal Chain of Thought, M-CoT) 和 LLM 辅助的视觉推理 (LLM-Aided Visual Reasoning, LAVR) 等. | | 2024/07/26 | 模型压缩 | [Comprehensive Study on Performance Evaluation and Optimization of Model Compression: Bridging Traditional Deep Learning and Large Language Models](https://arxiv.org/abs/2407.15904) | Aayush Saxena | [Comprehensive](https://arxiv.org/abs/2407.15904) | 近年来, 深度学习模型在大多数行业都取得了巨大成功. 这些模型的发展还导致模型大小和能源需求增加, 使其难以在低计算设备上的生产环境中进行部署. 全球互联设备数量的增加保证了压缩模型可以轻松部署在本地设备上, 但计算容量和电源可访问性较低. 不同的研究人员提出了广泛的解决方案来减小此类模型的大小和复杂性, 其中突出的是权重量化、参数修剪、网络修剪、低秩表示、权重共享、神经架构搜索、知识蒸馏等. 在这项研究工作中, 我们调查了使用量化和修剪技术进行压缩的各种训练有素的深度学习模型的性能影响. 我们在图像分类、对象检测、语言模型和基于生成模型的问题陈述中使用的常用深度学习模型上实施了量化和剪枝压缩技术. 我们还探讨了各种大型语言模型在量化和低秩适应后的性能. 我们对所有相关问题陈述使用了标准评估指标(模型的大小、准确性和推理时间), 并通过讨论挑战和未来的工作来总结本文. | -| 2024/06/04 | 投机 | [Unlocking Efficiency in Large Language Model Inference:A Comprehensive Survey of Speculative Decoding](https://arxiv.org/abs/2401.07851) | Heming Xia | [hemingkx/SpeculativeDecodingPapers](https://github.com/hemingkx/SpeculativeDecodingPapers) | [COLING 2025 Tutorial:Speculative Decoding for Efficient LLM Inference](https://speculative-decoding.github.io), [知乎 - LLM 推理加速新范式！推测解码（Speculative Decoding）最新综述](https://zhuanlan.zhihu.com/p/678404136) | +| 2024/06/04 | 投机 | [Unlocking Efficiency in Large Language Model Inference:A Comprehensive Survey of Speculative Decoding](https://arxiv.org/abs/2401.07851) | Heming Xia | [hemingkx/SpeculativeDecodingPapers](https://github.com/hemingkx/SpeculativeDecodingPapers) | [COLING 2025 Tutorial:Speculative Decoding for Efficient LLM Inference](https://speculative-decoding.github.io), [知乎 - LLM 推理加速新范式！推测解码(Speculative Decoding)最新综述](https://zhuanlan.zhihu.com/p/678404136) | | 2025/06/16 | 离散扩散 (Discrete Diffusion) | [Discrete Diffusion in Large Language and Multimodal Models: A Survey](https://arxiv.org/pdf/2506.13759) | xML 团队 | [LiQiiiii/DLLM-Survey](https://github.com/LiQiiiii/DLLM-Survey) | 本文全面综述了基于离散扩散范式的大语言与多模态模型, 揭示其通过并行解码和去噪策略实现加速推理与精细控制的核心机制, 构建了涵盖理论框架、实现技术与应用场景的完整技术体系. 本文系统梳理了基于离散扩散的大语言模型(dLLMs) 和多模态语言模型 (dMLLMs) 的技术发展脉络. 与传统的自回归模型相比, 这类模型通过并行解码机制和去噪生成策略, 实现了高达 10 倍的推理加速, 同时在细粒度输出控制和动态感知响应方面展现出独特优势. 研究揭示了该领域发展的两大驱动力: 一是自回归模型积累的海量数据和基础设施, 二是吸收状态扩散、转移矩阵优化等数学模型的突破. 论文从历史沿革、数学框架、模型分类三个维度构建技术体系, 特别阐述了全注意力机制与多标记预测的协同优化方法, 以及蛋白质序列生成等跨领域应用的实现路径. 实验分析表明, 当前领先的 d(M)LLMs 在保持同等生成质量的前提下, 通过并行解码实现了 3-10 倍的推理加速. 特别是工业级闭源模型与开源学术模型的双轨发展, 验证了该范式的实际部署价值. 研究最后指出硬件适配优化和高效训练策略将成为未来突破的关键方向. | -| 2025/08/13 | 效率提升 | [Speed Always Wins: A Survey on Efficient Architectures for Large Language Models](https://arxiv.org/abs/2508.09834) | 上海 AI Lab | [Awesome-Efficient-Arch](https://github.com/weigao266/Awesome-Efficient-Arch) | [唯快不破：上海 AI Lab 82 页综述带你感受 LLM 高效架构的魅力](https://www.jiqizhixin.com/articles/2025-08-25-12) | -| 2025/04/12 | 推理系统 | [A Survey of Frontiers in LLM Reasoning: Inference Scaling, Learning to Reason, and Agentic Systems](https://arxiv.org/abs/2504.09037) | 新加坡研究机构与高校 | 这篇综述的核心观点是, LLM 的推理研究正经历两大转变:
一是从 "推理时扩展"(Inference Scaling)向 "学习推理"(Learning to Reason)的范式转变, 即从依赖提示工程和复杂解码策略, 转向通过专门的训练来内化模型的推理能力;
二是从 "单一模型"(Standalone LLMs)向 "代理系统"(Agentic Systems)的架构演进, 即从单个 LLM 独立解决问题, 演变为利用外部工具或多个智能体协作来完成复杂任务. 论文通过其独特的二维分类法, 为理解这一快速发展的领域提供了一个全面的分析框架. 参见 [新加坡研究机构与高校发布最新 Reasoning 综述，从推理扩展、学习推理到 Agent 系统](https://blog.csdn.net/qq_27590277/article/details/147262739) | +| 2025/08/13 | 效率提升 | [Speed Always Wins: A Survey on Efficient Architectures for Large Language Models](https://arxiv.org/abs/2508.09834) | 上海 AI Lab | [Awesome-Efficient-Arch](https://github.com/weigao266/Awesome-Efficient-Arch) | [唯快不破: 上海 AI Lab 82 页综述带你感受 LLM 高效架构的魅力](https://www.jiqizhixin.com/articles/2025-08-25-12) | +| 2025/04/12 | 推理系统 | [A Survey of Frontiers in LLM Reasoning: Inference Scaling, Learning to Reason, and Agentic Systems](https://arxiv.org/abs/2504.09037) | 新加坡研究机构与高校 | 这篇综述的核心观点是, LLM 的推理研究正经历两大转变:
一是从 "推理时扩展"(Inference Scaling)向 "学习推理"(Learning to Reason)的范式转变, 即从依赖提示工程和复杂解码策略, 转向通过专门的训练来内化模型的推理能力;
二是从 "单一模型"(Standalone LLMs)向 "代理系统"(Agentic Systems)的架构演进, 即从单个 LLM 独立解决问题, 演变为利用外部工具或多个智能体协作来完成复杂任务. 论文通过其独特的二维分类法, 为理解这一快速发展的领域提供了一个全面的分析框架. 参见 [新加坡研究机构与高校发布最新 Reasoning 综述, 从推理扩展、学习推理到 Agent 系统](https://blog.csdn.net/qq_27590277/article/details/147262739) | [Mobile Edge Intelligence for Large Language Models: A Contemporary Survey](https://arxiv.org/abs/2407.18921) @@ -656,7 +734,7 @@ ARM-software/ComputeLibrary | 2024/09/23 | 日常论文精选 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | 日常论文精选 | | 2024/10/25 | 日常论文精选 | [xianshang33/llm-paper-daily](https://github.com/xianshang33/llm-paper-daily) | [xianshang33](https://github.com/xianshang33/llm-paper-daily) | [xianshang33/llm-paper-daily](https://github.com/xianshang33/llm-paper-daily) | 日常论文精选 | | 2024/11/25 | 日常论文速递 | NA | NA | [叶子的技术碎碎念 - 每周 AI 论文速递](http://leafw.cn) | NA | - +| 2026/06/02 | 日常论文速递 | NA | [Sophon Papers](https://sophon.at/papers) | 聚焦前沿 AI 大模型/智能体(Agent)领域的小众前沿论文收录平台, 主打最新预印本、实验室前沿技术论文汇总, 以 2026 年新发 AI 研究为核心, 收录全球高校、国内头部 AI 实验室、大厂研究院的 Agent、多模态、大模型推理、AI 安全、科研自动化等方向未正式见刊的前沿论文, 对标小型垂直版 arXiv(AI Agent 细分赛道). | ## 5.4 blog ------- @@ -664,12 +742,13 @@ ARM-software/ComputeLibrary | 文章 | 描述 | |:---:|:---:| | [零基础入门深度学习(8) - Transformer (1/3)](https://zybuluo.com/hanbingtao/note/2600518) | 详细介绍了全连接神经网络、卷积神经网络、循环神经网络等, 并继续从模型结构这个角度出发, 介绍 Transformer. 第一部分是基础知识的介绍; 第二部分重点讲述 transformer 的注意力机制, 这也是它的核心部分; 第三部分讲述模型的整体结构, 以及训练和推理. | -| [2026年AI学习路线图：AI硬核玩家必看！附100多篇经典论文免费下载](https://mp.weixin.qq.com/s/aM4Ma8NFobp8iBXNOSSv4g) | 对 [The 2025 AI Engineer Readling List](https://www.latent.space/p/2025-papers) 的解读, 对 Latent Space 推荐的的 2025 年必读论 50 篇论文以及提到的论文, 共计 123 篇. 涵盖了 AI 领域方方面技术, 从文本、生图、视频模型, 到 RAG、Prompt 等技术. | +| [2026年AI学习路线图: AI硬核玩家必看！附100多篇经典论文免费下载](https://mp.weixin.qq.com/s/aM4Ma8NFobp8iBXNOSSv4g) | 对 [The 2025 AI Engineer Readling List](https://www.latent.space/p/2025-papers) 的解读, 对 Latent Space 推荐的的 2025 年必读论 50 篇论文以及提到的论文, 共计 123 篇. 涵盖了 AI 领域方方面技术, 从文本、生图、视频模型, 到 RAG、Prompt 等技术. | | [The State Of LLMs 2025: Progress, Problems, and Predictions](https://magazine.sebastianraschka.com/p/state-of-llms-2025) | Ahead of AI 的 2025 总结. | - - - - +| [LLM 推理全过程的维度变化与核心公式](https://research.frankk.site/llm-inference-walkthrough) | LLM 在推理过程中, tensor维度的流转过程 | +| [逐层分解Transformer](https://v11enp9ok1h.feishu.cn/wiki/HkKlw30wpiGrSRkDncZclgN2nQd) | 这份文档逐层拆解了 Transformer 的结构与核心原理. Transformer 用词嵌入 + 位置嵌入做输入, 通过 6 层 Encoder + 6 层 Decoder和多头自注意力并行建模全局依赖, 实现高效序列建模. | +| [2026/06/28, Avi Chawla @_avichawla, How LLM Inference Works, Clearly Explained.](https://x.com/_avichawla/status/2071201619530956863) | 介绍 Transformer 是怎么运行的 | +| [2026/06/25, 程序员Left @coder_left, 大模型里面到底装了什么东西？都有哪些功能？](https://x.com/coder_left/status/2070058106210730362) | 用最通俗易懂的语言讲解 Transformer. | +| [2026/06/30, snowboat @snowboat84AI 大V人物小传(上)](https://x.com/snowboat84/status/2071743676649509122) | NA |
diff --git a/study/kernel/00-DESCRIPTION/ARCH.md b/study/kernel/00-DESCRIPTION/ARCH.md index 01120c0..90c5dfe 100644 --- a/study/kernel/00-DESCRIPTION/ARCH.md +++ b/study/kernel/00-DESCRIPTION/ARCH.md @@ -1460,7 +1460,10 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构, | 2019 | NA | [Make the Most out of Last Level Cache in Intel Processors, EuroSys '19](https://dl.acm.org/doi/10.1145/3302424.3303977) | NA | 在现代(Intel)处理器中, 最后一级缓存(LLC)被划分为多个切片, 并且未记录的哈希算法(又名复杂寻址)在这些切片之间映射内存地址空间的不同部分, 以增加有效内存带宽. 在仔细研究了英特尔的复杂寻址后, 我们引入了一种切片感知内存管理方案, 可以通过 LLC 更快地访问常用数据. 使用我们提出的方案, 我们表明, 对于 100% 和 95% 的 GET 工作负载, 键值存储可以分别将其平均性能提高 ~12.2% 和 ~11.4%. 此外, 我们提出了 CacheDirector, 这是一种网络 I/O 解决方案, 它扩展了直接数据 I/O(DDIO), 并将数据包的标头放置在最接近相关处理核心的 LLC 切片中. 我们将 CacheDirector 作为 DPDK 的扩展实施, 并评估了我们针对网络功能虚拟化(NFV)系统中延迟关键型应用程序提出的解决方案. 评估结果表明, CacheDirector 通过将以 100 Gbps 运行的优化 NFV 服务链的尾部延迟(90-99 个百分位数)减少多达 119 μs(~21.5%) 来加快数据包处理速度. 最后, 分析了切片感知内存管理实现缓存隔离的有效性. | | 2019 | NA | [CoPart: Coordinated Partitioning of Last-Level Cache and Memory Bandwidth for Fairness-Aware Workload Consolidation on Commodity Servers](https://dl.acm.org/doi/10.1145/3302424.3303963) | NA | 工作负载整合是一种广泛使用的技术, 用于最大限度地提高云和数据中心计算中的服务器资源利用率. 最近的商用 CPU 支持最后一级缓存(LLC) 和内存带宽分区功能, 可用于确保整合工作负载的公平性. 虽然先前的工作已经提出了多种资源分区技术, 但表征 LLC 和内存带宽分区对整合工作负载公平性的影响以及研究系统软件支持以协调方式动态控制 LLC 和内存带宽分区仍然没有探索. 为了弥合这一差距, 我们提出了 LLC 和内存带宽分区的深入性能和公平性表征. 在表征结果的指导下, 我们提出了 CoPart, 即 LLC 和内存带宽的协调分区, 用于商用服务器上的公平感知工作负载整合. CoPart 动态分析整合应用程序的特性, 并以协调的方式在应用程序之间分配 LLC 和内存带宽, 以提高整体公平性. 我们的定量评估表明, CoPart 显着提高了整合应用程序的公平性(例如, 公平性平均比将资源平均分配给合并应用程序的资源分配策略高 57.3%), 在各种应用程序和系统配置中稳健地提供了高公平性, 并且产生了较小的性能开销. | -# 7 GPU +# 7 GPU/NPU +------- + +## 7.1 GPU ------- [phoronix, 2024/12/11, How AMD Is Taking Standard C/C++ Code To Run Directly On GPUs](https://www.phoronix.com/news/AMD-Standard-C-Code-GPUs) @@ -1475,6 +1478,14 @@ AMD-pstate 驱动程序利用 ITMT 体系结构提供的功能和数据结构, | 2026/01/04 | HongleiHuang-amd | [New AMD Linux Driver Patches Posted For Batch Userptr Allocation Support](https://www.phoronix.com/news/AMDKFD-Batch-Userptr-Allocation) | AMDKFD 内核计算驱动最近正在开发的一项新功能是支持批处理用户指针"userptr"分配. 有了这个新的用户空间 API, 将可以支持分配多个非连续的 CPU 虚拟地址范围, 这些地址映射到一个连续的 GPU 虚拟地址. 参加 [phoronix, 2026/01/04, New AMD Linux Driver Patches Posted For Batch Userptr Allocation Support](https://www.phoronix.com/news/AMDKFD-Batch-Userptr-Allocation) | NA | [libhsakmt: Add batch userptr range registration API](https://github.com/ROCm/rocm-systems/commit/ac21716e5d6f68ec524e50eeef10d1d6ad7eae86) | +## 7.2 NPU +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2026/04/15 | Lizhi Hou | [accel/amdxdna: Add hardware scheduler time quantum support](https://lore.kernel.org/all/20260415171139.904947-1-lizhi.hou@amd.com) | 邮件主题为新增 AMD XDNA 驱动的硬件调度时间片支持. 主要由 Max Zhen 开发, Lizhi Hou 代提交. 该补丁为硬件调度器添加时间片( time quantum) 配置功能, 以提升多上下文并发执行时的公平性. 调度器通过限制每个上下文的执行时间, 防止长时间任务独占设备, 确保其他任务也能及时执行. 默认时间片设为 30 毫秒, 可通过模块参数 `time_quantum_ms` 调整.
补丁修改了多个文件, 新增 `MSG_OP_UPDATE_PROPERTY` 消息操作码及对应处理逻辑, 用于更新上下文执行时间配额. 在驱动初始化时调用 `aie2_update_prop_time_quota() ` 设置默认时间片. 此外, 更新固件特性表以支持该功能.
目标收件人包括 Oded Gabbay、Jorge Hugo 等相关维护者, 抄送 Linux 内核邮件列表. | v2 ☐☑✓ | [2026/04/15, LORE](https://lore.kernel.org/all/20260415171139.904947-1-lizhi.hou@amd.com) | + +
* 本作品 / 博文 ([AderStep - 紫夜阑珊 - 青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚(gatieme)](http://blog.csdn.net/gatieme) 创作. diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index a289989..749d784 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -618,6 +618,24 @@ glcc 则实现了 eBPF 驱动和 libbpf 的支持, 允许 eBPF 程序无需修 | [grafana/phlare](https://github.com/grafana/phlare) | 一个水平可扩展, 高可用, 多租户的持续性能分析聚合系统. 它已被 Grafana LAB 收购, 未来的 | | [maxgio92/yap](https://github.com/maxgio92/yap) | 一个基于 Go 和 eBPF 的低开销的采样 CPU Profiler, 它不需要在被分析的二进制文件中进行任何插装. [Unleashing the power of frame pointers pt.1 - The execution environment](https://blog.maxgio.me/posts/unleashing-power-frame-pointers-execution-environment), [Unleashing the power of frame pointers for profiling pt.2 - Writing a simple profiler](https://blog.maxgio.me/posts/unleashing-power-frame-pointers-writing-simple-continuous-profiler) | + +## 8.8 bpftrace +------- + + +| 项目 | 描述 | 支持 | 推荐星级 | Star 数量 | +|:---:|:----:|:---:|:-------:|:--------:| +| [multikernel/kernelscript](https://github.com/multikernel/kernelscript) | [2026/05/24, phoronix, KernelScript: A Programming Language For Kernel Customization & App Optimizations](https://www.phoronix.com/news/KernelScript) | NA | ⭐ | 479 | + +## 8.9 OTHER +------- + + +| 项目 | 描述 | 支持 | 推荐星级 | Star 数量 | +|:---:|:----:|:---:|:-------:|:--------:| +| [pandaadir05/snoop](https://github.com/pandaadir05/snoop) | 基于 eBPF 的现代系统调用跟踪工具, 类似 strace 但具有实时 TUI 界面、智能过滤器、TLS 解密和可读输出。支持多种输出格式(raw、json、explain)、60+ 系统调用参数解码、容器支持、TLS 捕获、堆跟踪、记录回放和火焰图生成. 使用 Rust 和 aya 编写 eBPF 程序, 无需内核模块和 C 工具链. | 系统调用跟踪、性能分析 | ⭐ | 150 | +| [pktz](https://github.com/immanuwell/pktz) | 基于 eBPF 的网络流量监控工具, 提供进程级和连接级的实时流量监控. 核心功能包括: 实时 RX/TX 速率显示、连接详情查看、Unicode 图表、GeoIP 标记 + ASN 信息、DNS 解析. 支持三种模式: TUI 交互模式、Log 模式(NDJSON 输出)、Prometheus metrics 模式. 技术上基于 Go 语言 + eBPF 技术, 直接挂钩内核, 无需轮询 /proc, 无采样, 每个字节每个进程都不放过. 适用于网络流量监控、调试、安全审计等场景. | Linux | ⭐ | 83 | + # 9 WASM(WebAssembly) ------- diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index e035bd3..0786c89 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -147,6 +147,8 @@ https://lwn.net/Articles/422487/ | 2009/08/05 | Arjan van de Ven | [Implement crashkernel=auto](https://lore.kernel.org/patchwork/cover/166256) | 实现 crashkernel=auto . | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/166256) | | 2022/08/28 | Baoquan He | [arm64, kdump: enforce to take 4G as the crashkernel low memory end](https://patchwork.kernel.org/project/linux-mm/cover/20220828005545.94389-1-bhe@redhat.com/) | 671768 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220828005545.94389-1-bhe@redhat.com) | | 2024/03/05 | Steven Rostedt | [tracing: Persistent traces across a reboot or crash](https://lore.kernel.org/all/20240306015910.766510873@goodmis.org) | [Experimental Linux Patches Allow Kernel Tracing To Work Past Reboots/Crashes](https://www.phoronix.com/news/Linux-Tracing-Post-Reboots). | v1 ☐☑✓ | [LORE v1,0/8](https://lore.kernel.org/all/20240306015910.766510873@goodmis.org) | +| 2025/11/19 | Eugen Hristev | [Introduce meminspect](https://lore.kernel.org/all/20251119154427.1033475-1-eugen.hristev@linaro.org) | Eugen Hristev 提出了一项名为 **meminspect** 的新机制, 用于在 Linux 内核中标记特定内存区域以进行调试、统计和内存转储. 该机制不依赖于 panic handler 或运行中的内核, 适用于 pstore、kdump 等机制无法使用的设备. meminspect 可生成类似 `/proc/vmcore` 的核心镜像, 供 crash 工具或 GDB 分析.
该补丁系列基于此前的 kmemdump 和 minidump 实现, 已重命名为 meminspect 并移至 `kernel/` 目录. 它引入了两个驱动: **Qualcomm Minidump** 和 **Debug Kinfo**( 用于 Android) . meminspect 利用 memblock 标志和 vmcoreinfo 注册内存区域, 并在系统运行时维护内存区域表.
补丁已基于社区反馈多次迭代, 包括移除 . section、整合进 vmcoreinfo、调整 API 和文档等. 作者将在 Plumbers 会议中进一步讨论该方案.
使用时需启用 `CONFIG_MEMINSPECT`、`CONFIG_CRASH_DUMP` 和相关驱动, 并通过工具( 如 qdl 或 edl) 提取内存区域后合并分析. | v1 ☐☑✓ | [2025/11/19, LORE v1, 0/26](https://lore.kernel.org/all/20251119154427.1033475-1-eugen.hristev@linaro.org) | + [crash extension modules](https://crash-utility.github.io/extensions.html) @@ -438,7 +440,7 @@ $reclaim = current\_mem \times reclaim\_ratio \times max(0,1 – \frac{psi_some} -## 11.3 Userspace counter access +## 11.3 Userspace Counter Access ------- x86 和 arm64 都支持直接访问用户空间中的事件计数器. 访问序列并不简单, 目前存在于 perf 测试代码 (tools/perf/arch/x86/tests/rdpmc.c) 中, 在 PAPI 和 libpfm4 等项目中有类似的用例程序. @@ -468,14 +470,14 @@ x86 和 arm64 都支持直接访问用户空间中的事件计数器. 访问序 | 2022/03/22 | Stephane Eranian | [perf/x86/amd: Add AMD Fam19h Branch Sampling support](https://lore.kernel.org/all/20220322221517.2510440-1-eranian@google.com) | 引入 CONFIG_PERF_EVENTS_AMD_BRS. perf 支持 BRS. AMD 系列 19h "Zen 3" 处理器新增了分支采样功能 BRS, 用于收集代码执行期间所采用分支的详细信息. 该功能可用于 AMD 处理器上的 AutoFDO 样式优化, 编译器利用收集的硬件数据来做出更明智和准确的优化决策. | v7 ☑✓ 5.19-rc1 | [LORE v7,0/13](https://lore.kernel.org/all/20220322221517.2510440-1-eranian@google.com) | -## 11.5 perf-KWork +## 11.5 perf kwork ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| | 2022/07/09 | Yang Jihong | [perf: Add perf kwork](https://lore.kernel.org/all/20220709015033.38326-1-yangjihong1@huawei.com) | 开发者经常需要分析内核工作的时间属性, 例如 irq、softirq 和工作队列, 包括特定中断的延迟和运行时间. 目前, 这些事件具有内核跟踪点, 但 perf 工具不直接分析这些事件的延迟. perf kwork 工具用于跟踪内核工作的时间属性(如 irq、softirq 和 workqueue), 包括运行时、延迟和时间历史, 使用 perf 工具中的基础设施来允许跟踪额外的目标, 我们还使用 bpf 跟踪来收集和过滤内核中的数据, 以解决大 perf 数据量和额外文件系统中断的问题. | v3 ☐☑✓ | [LORE v3,0/17](https://lore.kernel.org/all/20220709015033.38326-1-yangjihong1@huawei.com) | -## 11.6 perf-lock +## 11.6 perf lock ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | @@ -1305,7 +1307,7 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道 | 2025/05/12 | Nam Cao | [RV: Linear temporal logic monitors for RT application](https://lore.kernel.org/all/cover.1747046848.git.namcao@linutronix.de) |旨在为实时( RT) 应用引入基于线性时序逻辑( LTL)的运行时验证( RV) 监控机制. 补丁系列包括以下关键内容:
1. LTL监控支持: 新增 LTL 监控模块, 相比原先的确定性自动机, LTL 更简洁直观,适合表达实时规则;
2. RT 应用监控器(rtapp): 作为容器封装子监控模块;
3. 页错误监控( rtapp_pagefault): 用于检测实时任务中的页错误;
4. 睡眠监控( rtapp_sleep): 检测实时线程中可能引起延迟的睡眠行为;
5. 配置支持: 允许配置每任务监控器数量, 以同时启用多个监控;
6. 文档更新: 补充 LTL 和监控器相关文档;
7. 代码结构优化: 整合 dot2k 和 rvgen 工具, 重构模板与类结构, 提升代码可维护性.
各版本更新主要修复脚本问题、优化检测逻辑、处理边缘情况, 并调整部分架构的跟踪点. 补丁已覆盖 x86、ARM64 和 RISC-V 架构. 参见 [LWN, 2025/07/30, Extending run-time verification for the kernel](https://lwn.net/Articles/1030685). | v8 ☐☑✓ | [2025/05/12, LORE v8, 0/22](https://lore.kernel.org/all/cover.1747046848.git.namcao@linutronix.de) | | 2025/07/30 | Nam Cao | [rv: LTL per-cpu monitor type and real-time scheduling monitor](https://lore.kernel.org/all/cover.1753879295.git.namcao@linutronix.de) | 邮件提出了一组 5 个补丁, 旨在为 Linux 内核的 Roving( rv) 子系统添加对线性时序逻辑(LTL) 的 per-cpu 监控类型支持, 并新增一个用于验证实时调度(real-time scheduling) 的监控模块. 该系列补丁首先对现有 LTL 监控代码进行重构, 以支持多种监控类型; 随后实现 per-cpu 监控机制, 类似于现有的确定性自动机监控. 此外, 补丁还引入了新的 trace point 用于实时任务的入队与出队事件, 并通过 rvgen 工具生成LTL 监控代码. 最终新增的 rts 监控模块可检测实时调度行为是否符合预期. | v1 ☐☑✓ | [2025/07/30, LORE v1, 0/5](https://lore.kernel.org/all/cover.1753879295.git.namcao@linutronix.de) | | 2025/07/23 | Gabriele Monaco | [tools/verification: Improvements to rv and rvgen](https://lore.kernel.org/all/20250723161240.194860-1-gmonaco@redhat.com) | 改进 Linux 内核中的 rv 和 rvgen 验证工具. 主要内容包括:
1. 修复 rv 工具在使用 -s 选项时跳过 idle 任务的问题;
2. 增加 rv 对 SIGTERM 信号的优雅终止处理;
3. 修改 dot2c 脚本避免生成超过 100 列的代码行;
4. 调整 RV Kconfig 文件中嵌套监控模块的顺序;
5. 在 DA 监控初始化失败时返回正确错误码, 而非 0. | v1 ☐☑✓ | [2025/07/23, LORE v1, 0/5](https://lore.kernel.org/all/20250723161240.194860-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2025/08/06, LORE v2, 0/5](https://lore.kernel.org/all/cover.1754466623.git.namcao@linutronix.de)
*-*-*-*-*-*-*-*
[2025/08/11, LORE v3, 0/5](https://lore.kernel.org/all/cover.1754900299.git.namcao@linutronix.de) | -| 2025/08/14 | Gabriele Monaco | [rv: Add Hybrid Automata monitor type, per-object and deadline monitors](https://lore.kernel.org/all/20250814150809.140739-1-gmonaco@redhat.com) | 改进 Linux 内核中的 RV( Runtime Verification) 监控功能, 目标是增强内核运行时验证能力, 提升调度与实时性监控的准确性. 核心内容包括:
1. 混合自动机(Hybrid Automata) 监控类型: 扩展确定性自动机, 支持环境变量约束判断, 适用于定时自动机场景.
2. 对象级监控(Per-object Monitors): 支持为任意对象(如任务) 创建监控实例, 通过 ID 索引存储监控数据.
3. 期限(Deadline)监控集合: 新增 throttle 和 nomiss 监控模块, 用于验证 deadline 调度器的时间行为.
4. 对 da_monitor 进行宏清理与重构, 提升代码可维护性.
5. 多处文档更新与 rvgen 工具链改进, 支持新监控类型的生成与集成. | v1 ☐☑✓ | [2025/08/14, LORE v1, 0/17](https://lore.kernel.org/all/20250814150809.140739-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2025/09/19, LORE v2, 0/20](https://lore.kernel.org/all/20250919140954.104920-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2025/12/05, LORE v3, 0/20](https://lore.kernel.org/all/20251205131621.135513-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2026/01/22, LORE v3, 0/20](https://lore.kernel.org/all/20260122155500.362683-1-gmonaco@redhat.com) | +| 2025/08/14 | Gabriele Monaco | [rv: Add Hybrid Automata monitor type, per-object and deadline monitors](https://lore.kernel.org/all/20250814150809.140739-1-gmonaco@redhat.com) | 改进 Linux 内核中的 RV( Runtime Verification) 监控功能, 目标是增强内核运行时验证能力, 提升调度与实时性监控的准确性. 核心内容包括:
1. 混合自动机(Hybrid Automata) 监控类型: 扩展确定性自动机, 支持环境变量约束判断, 适用于定时自动机场景.
2. 对象级监控(Per-object Monitors): 支持为任意对象(如任务) 创建监控实例, 通过 ID 索引存储监控数据.
3. 期限(Deadline)监控集合: 新增 throttle 和 nomiss 监控模块, 用于验证 deadline 调度器的时间行为.
4. 对 da_monitor 进行宏清理与重构, 提升代码可维护性.
5. 多处文档更新与 rvgen 工具链改进, 支持新监控类型的生成与集成. | v1 ☐☑✓ | [2025/08/14, LORE v1, 0/17](https://lore.kernel.org/all/20250814150809.140739-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2025/09/19, LORE v2, 00/20](https://lore.kernel.org/all/20250919140954.104920-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2025/12/05, LORE v3, 00/20](https://lore.kernel.org/all/20251205131621.135513-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2026/01/22, LORE v3, 00/20](https://lore.kernel.org/all/20260122155500.362683-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2026/03/10, LORE v7, 00/15](https://lore.kernel.org/all/20260310105627.332044-1-gmonaco@redhat.com)
*-*-*-*-*-*-*-*
[2026/03/30, LORE v8, 00/12](https://lore.kernel.org/all/20260330111010.153663-1-gmonaco@redhat.com) | # 21 新语言支持 @@ -1410,6 +1412,13 @@ Fedora 尝试优化 systemd 开机以及重启的时间, 参见 phoronix 报道 [A look at dynamic linking](https://lwn.net/Articles/961117/) +# 25 API +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:---:|:----:|:---:|:----:|:---------:|:----:| +| 2026/05/29 | Sasha Levin | [Kernel API Specification Framework](https://lore.kernel.org/all/20260529233311.1901670-1-sashal@kernel.org) | 旨在为内核 API 提供形式化规范机制, 解决长期存在的用户空间接口稳定性问题. 该框架支持参数类型、取值范围、执行上下文、错误码等接口行为的描述, 并可嵌入代码中, 兼具可读性和可解析性.
该框架支持运行时检查( CONFIG_KAPI_RUNTIME_CHECKS) 、debugfs 导出、ftrace 跟踪、静态分析、自动化测试和文档生成. 实现包括 ELF 段存储、kerneldoc 集成、Rust 提取工具( 支持 JSON/RST/文本输出) 及 KUnit 和 TAP 测试套件. 已为 sys_open、sys_close、sys_read、sys_write 和 sys_madvise 添加示例规范.
此版本修复了构建问题、优化了内存布局、改进了 DSL 语法, 并更新了工具链. 补丁集已通过 LTP 测试验证. | v4 ☐☑✓ | [2026/05/29, LORE v4, 0/11](https://lore.kernel.org/all/20260529233311.1901670-1-sashal@kernel.org) | + # X 学习参考 ------- diff --git a/study/kernel/00-DESCRIPTION/LOCKING.md b/study/kernel/00-DESCRIPTION/LOCKING.md index a829613..b5ddac2 100644 --- a/study/kernel/00-DESCRIPTION/LOCKING.md +++ b/study/kernel/00-DESCRIPTION/LOCKING.md @@ -506,7 +506,8 @@ Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决 | 2024/02/02 | Metin Kaya | [sched: Add trace events for Proxy Execution (PE)](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) | 添加 `sched_[start，finish]_task_selection` 跟踪事件以测量 PE 补丁在任务选择中的延迟. 此外, 在 PE 中引入有趣事件的跟踪事件:
1. sched_pe_enque_sleeping_task: 一个任务在睡眠任务(互斥体所有者)的等待队列中排队.
2. sched_pe_cross_mote_cpu: 依赖链跨远程 cpu.
3. sched_pe_task_is_migration: 互斥所有者任务迁移. 可以通过以下命令测试新的跟踪事件: `perf record -e sched:sched_start_task_selection -e sched:sched_finish_task_selection -e sched:sched_pe_enque_sleeping_task -e sched:sched_pe_cross_mote_cpu -e sched:sched_pe_task_is_migration`. 此补丁基于 John 的 [Proxy Execution v7 补丁系列](https://lore.kernel.org/linux-kernel/CANDhNCrHd+5twWVNqBAhVLfhMhkiO0KjxXBmwVgaCD4kAyFyWw@mail.gmail.com). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) | | 2024/11/05 | John Stultz | [Single CPU Proxy Execution (v13)](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com) | 这组补丁的主要目的是实现单 CPU 代理执行(Single CPU Proxy Execution)机制, 这是一种通用形式的优先级继承(priority inheritance)方法, 旨在解决某些特定场景下的调度问题.
1. 实现单 CPU 代理执行机制, 支持作为构建和运行时选项.
2. 重新设计互斥锁的 blocked_on 结构, 以便更好地支持代理执行.
3. 处理代理执行带来的假设变化, 确保调度器的正确性.
4. 实现初始逻辑, 使锁持有者可以在同一 CPU 上代替等待任务运行.
通过这些改动, 调度器在处理某些特定场景下的优先级继承问题时更加高效和灵活, 提高了系统的整体性能和响应速度. 参见 [Paper](https://static.lwn.net/images/conf/rtlws11/papers/proc/p38.pdf) | v13 ☐☑✓ | [LORE v13,0/7](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2024/11/25, LORE v14,0/7](https://lore.kernel.org/all/20241125195204.2374458-1-jstultz@google.com) | | 2025/03/12 | John Stultz | [Single RunQueue Proxy Execution](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com) | 单运行队列(RunQueue)代理执行(Proxy Execution)的 V15 版本, 这是一种通用的优先级继承机制.
1. 问题: 在多核系统中, 当一个高优先级任务被低优先级任务阻塞时, 传统的优先级继承机制可能无法有效解决优先级反转问题, 尤其是在涉及多个运行队列(RunQueue)时.
2. 目标: 通过引入代理执行机制, 允许高优先级任务在等待锁时, 将执行权"代理"给其他任务, 从而减少高优先级任务的等待时间, 并提高系统的响应能力.
3. 核心思想: 当一个任务被阻塞时, 如果锁的持有者和等待者在同一个运行队列上, 那么可以将执行权"代理"给锁的持有者, 从而避免高优先级任务长时间等待. 参见报道 [phoronix, 2025/07/17, Single RunQueue Proxy Execution Appears Ready For Linux 6.17](http://phoronix.com/news/Linux-6.17-Proxy-Execution). | v15 ☐☑✓ | [2025/03/12, LORE v15,0/7](https://lore.kernel.org/all/20250312221147.1865364-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/04/12, LORE v16, 0/7](https://lore.kernel.org/all/20250412060258.3844594-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/05/16, LORE v17, 0/8](https://lore.kernel.org/all/20250516031814.1870508-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/06/02, LORE RESEND v17, 0/8](https://lore.kernel.org/all/20250602221004.3837674-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/06/25, LORE v18, 0/8](https://lore.kernel.org/all/20250625203110.2299275-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/07/07, LORE RESEND v18, 0/8](https://lore.kernel.org/all/20250707204409.1028494-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/07/12, LORE v19, 0/8](https://lore.kernel.org/all/20250712033407.2383110-1-jstultz@google.com) | -| 2025/07/22 | John Stultz | [Donor Migration for Proxy Execution](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com) | John Stultz 提交了 Proxy Execution 系列补丁的" Donor Migration" 部分(v20), 旨在实现阻塞等待任务的迁移, 以支持跨 CPU 代理执行锁拥有者. 该部分基于 Peter Zijlstra 已合入的 Single-RQ 补丁
主要新增了任务阻塞状态的序列化机制、三态 blocked_on_state 支持、平衡回调清理逻辑、以及支持 donor 迁移与链式迁移. 补丁还涉及对锁定机制和调度器的修改, 以防止任务在不合适的 CPU 上运行.
待解决问题包括: dl_server 导致的测试挂起、调度扩展( sched_ext) 兼容性、性能回归测试、以及链式迁移对 RT/DL 负载均衡的保证. | v20 ☐☑✓ | [2025/07/22, LORE v20, 0/6](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/09/04, LORE v21, 0/6](https://lore.kernel.org/all/20250904002201.971268-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/09/26, LORE v22, 0/6](https://lore.kernel.org/all/20250926032931.27663-1-jstultz@google.com) | +| 2025/07/22 | John Stultz | [(Simple/Optimized) Donor Migration for Proxy Execution](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com) | John Stultz 提交了 Proxy Execution 系列补丁的" Donor Migration" 部分(v20), 旨在实现阻塞等待任务的迁移, 以支持跨 CPU 代理执行锁拥有者. 该部分基于 Peter Zijlstra 已合入的 Single-RQ 补丁
主要新增了任务阻塞状态的序列化机制、三态 blocked_on_state 支持、平衡回调清理逻辑、以及支持 donor 迁移与链式迁移. 补丁还涉及对锁定机制和调度器的修改, 以防止任务在不合适的 CPU 上运行.
待解决问题包括: dl_server 导致的测试挂起、调度扩展( sched_ext) 兼容性、性能回归测试、以及链式迁移对 RT/DL 负载均衡的保证. | v20 ☐☑✓ | [2025/07/22, LORE v20, 0/6](https://lore.kernel.org/all/20250722070600.3267819-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/09/04, LORE v21, 0/6](https://lore.kernel.org/all/20250904002201.971268-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/09/26, LORE v22, 0/6](https://lore.kernel.org/all/20250926032931.27663-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2025/11/24, LORE v24, 00/11](https://lore.kernel.org/all/20251124223111.3616950-1-jstultz@google.com)
*-*-*-*-*-*-*-*
[2026/03/24, LORE v26, 00/10](https://lore.kernel.org/all/20260324191337.1841376-1-jstultz@google.com) | +| 2026/05/26 | Peter Zijlstra | [sched/proxy: doodles..](https://lore.kernel.org/all/20260526111609.433880331@infradead.org) | 旨在清理代码并尝试移除 PROXY_WAKING 标志, 改用 ->is_blocked 替代原有的 ->blocked_on 机制.补丁 4 中切换到 ->is_blocked 后, 在 schedule() 和 pick_next_task() 中运行良好, 但在 ttwu_runnable() 中遇到问题, 因缺乏锁保护, 导致延迟任务始终被完全阻塞.作者提到此前曾尝试过 ttwu-delayed 补丁, 或可结合该方案解决此问题.目前仅前 3 个补丁可能具备合入价值, 其余仍需调试. | v1 ☐☑✓ | [2026/05/26, LORE v1, 0/6](https://lore.kernel.org/all/20260526111609.433880331@infradead.org) | # 12 深入理解并行编程 diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 8be82a9..d9216d1 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -7388,6 +7388,7 @@ KFENCE 的灵感来自于 [GWP-ASan](http://llvm.org/docs/GwpAsan.html), 这是 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2016/02/03 | Christian Borntraeger | [Optimize CONFIG_DEBUG_PAGEALLOC (x86 and s390)](https://damonitor.github.io) | 优化 CONFIG_DEBUG_PAGEALLOC, 提供了 debug_pagealloc_enabled(), 可以动态的开启 DEBUG_PAGEALLOC. | v4 ☑ 4.6-rc1 | [PatchWork v4,0/4](https://lore.kernel.org/patchwork/patch/642851) | +| 2025/11/19 | Eugen Hristev | [Introduce meminspect](https://lore.kernel.org/all/20251119154427.1033475-1-eugen.hristev@linaro.org) | Eugen Hristev 提出了一项名为 **meminspect** 的新机制, 用于在 Linux 内核中标记特定内存区域以进行调试、统计和内存转储. 该机制不依赖于 panic handler 或运行中的内核, 适用于 pstore、kdump 等机制无法使用的设备. meminspect 可生成类似 `/proc/vmcore` 的核心镜像, 供 crash 工具或 GDB 分析. < br> < br> 该补丁系列基于此前的 kmemdump 和 minidump 实现, 已重命名为 meminspect 并移至 `kernel/` 目录. 它引入了两个驱动: **Qualcomm Minidump** 和 **Debug Kinfo**( 用于 Android) . meminspect 利用 memblock 标志和 vmcoreinfo 注册内存区域, 并在系统运行时维护内存区域表. < br> < br> 补丁已基于社区反馈多次迭代, 包括移除 . section、整合进 vmcoreinfo、调整 API 和文档等. 作者将在 Plumbers 会议中进一步讨论该方案. < br> < br> 使用时需启用 `CONFIG_MEMINSPECT`、`CONFIG_CRASH_DUMP` 和相关驱动, 并通过工具( 如 qdl 或 edl) 提取内存区域后合并分析. | v1 ☐☑✓ | [2025/11/19, LORE v1, 0/26](https://lore.kernel.org/all/20251119154427.1033475-1-eugen.hristev@linaro.org) | ## 13.5 tracepoint diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index fd2ca72..56d6fef 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -627,6 +627,8 @@ linux 调度器定义了多个调度类, 不同调度类的调度优先级不同 | 2021/11/16 | Peng Wang | [Add busy loop polling for idle SMT](https://lore.kernel.org/all/cover.1637062971.git.rocking@linux.alibaba.com) | SMT 级别的忙轮询等待. 当启用硬件 SMT 时, 在一个 CPU 的空闲和忙碌状态之间切换将导致同一核心上的同级 CPU 的性能波动. 在一个 SMT CPU 上需要稳定的性能时, 无论同一核心上的同级 CPU 是否空闲, 都需要一致的反馈, 而不期望有噪音. 原始 cpu_idle_force_poll 使用 cpu_relax() 等待被 IPI 唤醒, 而此 smt_idle_force_poll 使用忙循环来提供一致的 SMT 管道干扰. 可以使用 cgroup 的 cpu.smt_idle_poll 为特定任务配置启用忙循环轮询. | v1 ☐ | [PatchWork v1](https://lore.kernel.org/all/cover.1637062971.git.rocking@linux.alibaba.com) | | 2023/07/20 | Kenan.Liu | [Adjust CFS loadbalance to adapt QEMU CPU topology.](https://lore.kernel.org/all/1689842053-5291-1-git-send-email-Kenan.Liu@linux.alibaba.com) | 使用 Qemu 的 VM 中的多线程工作负载可能会遇到意外现象: 物理核心的一个超线程繁忙, 而其同级处于空闲状态. 主要原因是 qemu 原生 x86 CPU 型号中的超线程索引是连续的, 这与物理拓扑不同. 作为当前的内核调度程序实现, 在负载平衡和负载部署期间, 具有偶数 ID 号的超线程将以更高的概率被拾取. 此 RFC 旨在通过调整 CFS 负载平衡策略来解决此问题:
1. 探索 CPU 拓扑, 并在发现具有 qemu 本机 CPU 拓扑的机器时调整 CFS 负载均衡策略.
2. 导出 procfs 以控制选择空闲 CPU 时的遍历长度. 参见 [Alibaba Eyes Linux CPU Scheduler Changes To Better Handle QEMU With SMT/HT Threads](https://www.phoronix.com/news/Linux-Sched-QEMU-SMT-Better). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/1689842053-5291-1-git-send-email-Kenan.Liu@linux.alibaba.com) | | 2023/07/05 | Laurent Dufour | [Introduce SMT level and add PowerPC support](https://lore.kernel.org/all/20230705145143.40545-1-ldufour@linux.ibm.com) | [Linux 6.6 To Make It Easier To Enable Partial SMT For POWER](https://www.phoronix.com/news/Linux-6.6-Partial-SMT-Control). | v4 ☐☑✓ | [LORE v4,0/10](https://lore.kernel.org/all/20230705145143.40545-1-ldufour@linux.ibm.com) | +| 2026/05/09 | Andrea Righi | [sched/fair: SMT-aware asymmetric CPU capacity](https://lore.kernel.org/all/20260509180955.1840064-1-arighi@nvidia.com) | 通过引入 SMT 感知机制改进 Linux 调度器的 SD_ASYM_CPUCAPACITY 策略. 主要解决在 SMT 启用的情况下, 逻辑 CPU 容量可能高估实际计算能力的问题, 该问题会导致调度器误选负载较重的 CPU, 影响性能.
补丁集核心改进包括: 将 sched_domain_shared 附加到 sd_asym_cpucapacity, 优先选择完全空闲的 SMT 核心, 拒绝将任务拉到繁忙的 SMT 线程, 并在 select_idle_capacity() 中加入 SIS_UTIL 支持. 测试显示, 在 NVIDIA Vera Rubin 平台上, 该补丁显著提升了性能, 尤其在 CPU 密集型任务中, 性能提升最高达 2 倍.
补丁集还经过多轮代码优化和评审, 解决了 RCU 锁、命名、逻辑判断等问题, 并确保在不支持 SMT 的 NVIDIA Grace 平台上无性能退化. | v6 ☐☑✓ | [2026/05/09, LORE v6, 0/5](https://lore.kernel.org/all/20260509180955.1840064-1-arighi@nvidia.com) | +| 2026/04/07 | Zhang Qiao | [sched/fair: scale wake_wide() threshold by SMT width](https://lore.kernel.org/all/20260407063915.2034198-1-zhangqiao22@huawei.com) | 旨在优化 SMT(同步多线程)系统中 `wake_wide()` 函数的行为.当前 `wake_wide()` 使用 `sd_llc_size` 作为任务唤醒时的分布阈值, 但在 SMT 系统中, 该值基于逻辑 CPU 数量, 导致阈值偏高, 可能使多个任务集中于同一 LLC(最后一层缓存)域, 引发 SMT 干扰, 降低性能.
补丁通过将 `sd_llc_size` 按当前 CPU 的 SMT 宽度进行缩放, 使其更接近物理核心数量, 从而更早触发 `wake_wide()`, 避免任务过度集中.在非 SMT 系统中, 行为不变.
该修改提升了调度器在 SMT 架构下的任务分布合理性, 减少线程间资源竞争, 增强整体性能. | v1 ☐☑✓ | [2026/04/07, LORE](https://lore.kernel.org/all/20260407063915.2034198-1-zhangqiao22@huawei.com) | #### 1.5.4.2 SMT scheduling/core scheduling vs coscheduling @@ -796,6 +798,7 @@ CFS 用户反复在社区抱怨并行 kbuild 对桌面交互性有负面影响 | 2022/10/17 | Josh Don | [sched: async unthrottling for cfs bandwidth](https://lore.kernel.org/all/20221017234750.454419-1-joshdon@google.com) | CFS 带宽目前分配新的运行时, 并在 hrtimer 回调中取消 cfs_rq 的内联. 运行时分发是一个每个 CPU 的操作, 而取消节流是一个每个 cgroup 的操作, 因为需要 tg 遍历. 在拥有大量 CPU 和大型 cgroup 层次结构的机器上, CPU *cgroups 的工作可能在单个 hrtimer 回调中无法完成: 由于 IRQ 被禁用, 很容易发生 hard lockup. 具体来说, 我们发现在 256 个 CPU、O(1000) 个 cCGROUP 在层次结构中被限制以及高内存带宽使用的配置中存在可伸缩性问题. 要解决这个问题, 我们可以通过 CSD 异步取消 cfs_rq 的节流. 每个 CPU 负责自己进行节流, 从而在整个系统中更公平地划分总体工作, 并避免 hard lockup. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221017234750.454419-1-joshdon@google.com)
*-*-*-*-*-*-*-*
[LORE v2](https://lore.kernel.org/all/20221026224449.214839-1-joshdon@google.com) | | 2022/11/16 | Josh Don | [sched: async unthrottling for cfs bandwidth](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=8ad075c2eb1f6b4b33436144ea1ef2619f3b6398) | CFS 带宽当前分配新的运行时, 并在 hrtimer 回调中解除 cfs_rq 的 throttle 限制. 运行时分发是每个 CPU 的操作, 而解节流是每个组的操作, 因为需要执行 tg 遍历. 在具有大量 CPU 和大型 CGROUP 层次结构的机器上, 这种 CPU CGROUP 工作在单个 hrtimer 回调中可能做得太多: 由于 IRQ 被禁用, 可能很容易发生 Hard Lockup.
具体来说, 我们在 256 个 cpu 的配置中发现了这个可伸缩性问题, 层次结构中的 0(1000) 个 cgroups 被限制, 并且内存带宽使用率很高.
为了解决这个问题, 我们可以通过 CSD 异步地解除 cfs_rq 的限制. 每个 cpu 都负责解除自身的限制, 从而在整个系统中更公平地分配总工作, 并避免 Hard Lockup. | v3 ☐☑✓ 6.3-rc1 | [LORE](https://lore.kernel.org/all/20221117005418.3499691-1-joshdon@google.com) | | 2023/02/24 | Shrikanth Hegde | [Interleave cfs bandwidth timers for improved single thread performance at low utilization](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=41abdba9374734b743019fc1cc05e3225c82ba6b) | CPU CFS 带宽控制器使用 hrtimer. 目前没有初始值设置. 因此, 所有周期计时器将在到期时对齐. 当有多个 CPU CGROUP 时, 就会发生这种情况. 如果在每个 CPU CGROUP 组的利用率较低且所有 CPU CGROUP 组的总利用率低于 50% 时交错使用计时器, 则可以实现性能增益. 如果计时器是交错的, 那么不受限制的 CGROUP 组可以自由运行, 而不需要许多上下文切换, 并且还可以从 SMT 折叠中受益. 这个提交在初始化每个 hrtimer 后添加一个随机偏移量. 这将导致在过期时交错使用计时器, 这有助于实现上述性能增益. | v3 ☐☑✓ 6.4-rc1 | [LORE](https://lore.kernel.org/all/20230223185153.1499710-1-sshegde@linux.vnet.ibm.com) | +| 2026/04/13 | Fang Xiang | [sched/fair: Add per-cgroup CPU bandwidth slice control via cpuctl.slice_ns](https://lore.kernel.org/all/20260413024844.12864-1-fangxiang3@xiaomi.com) | 新增 cgroup 接口 `cpu.slice_ns`, 用于设置每个任务组的 CPU 调度时间片( 以纳秒为单位), 实现更精细的 CPU 带宽控制. 该功能与现有的 `cpu.weight` 和 `cpu.max` 配合使用, 增强资源管理能力.
时间片取值范围限定在 0.1ms 到 100ms 之间, 任务组内所有任务将继承该配置, 新加入任务也会在 `sched_change_group()` 中继承设置. 接口使用方式简单, 如 `echo 10000000 > cpu.slice_ns` 设置 10ms 时间片.
补丁修改了 `kernel/sched/core. c`、`fair. c` 和 `sched. h`, 新增 `slice_ns` 字段及相关读写函数, 并实现 `sched_group_set_slice()` 函数用于更新任务组的时间片设置. | v1 ☐☑✓ | [2026/04/13, LORE](https://lore.kernel.org/all/20260413024844.12864-1-fangxiang3@xiaomi.com) | 这个 bandwidth controller 提供了两个参数来管理针对各个 cgroup 的限制. @@ -870,13 +873,13 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些 | 2025/03/17 | Aaron Lu | [Defer throttle when task exits to user](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com) | [Valentin Schneider 工作"sched/fair: Defer CFS throttle to user entry"](https://lore.kernel.org/all/20231130161245.3894682-1-vschneid@redhat.com) 的续作.
1. 核心思想: 当一个任务的 CFS 配额耗尽时, 不是立即将其节流, 而是延迟到任务退出到用户空间时再进行节流. 这样可以避免任务在内核空间中被阻塞, 从而减少任务挂起的风险.
实现方式: 在 CFS 节流路径中, 为每个任务添加一个任务工作(task work), 以便在任务返回用户空间时执行节流操作. 在任务返回用户空间时, 任务工作会将任务从运行队列中移除, 并将其添加到 CFS 运行队列的 limbo 列表中, 以便后续恢复.
在 CFS 解除节流路径中, 将 limbo 列表中的任务重新加入运行队列. 参见 phoronix 报道 [phoronix, 2025/09/03, Linux Scheduler Adapted For A Latency Win & Avoiding An RT Deadlock](https://www.phoronix.com/news/Linux-CFS-Defer-Throttle) | v1 ☐☑✓ | [2025/03/17, LORE v1,0/7](https://lore.kernel.org/all/20250313072030.1032893-1-ziqianlu@bytedance.com)
*-*-*-*-*-*-*-*
[2025/04/09, LORE v2,0/7](https://lore.kernel.org/lkml/20250409120746.635476-1-ziqianlu@bytedance.com)
*-*-*-*-*-*-*-*
[2025/05/20, LORE v3, 0/7](https://lore.kernel.org/all/20250520104110.3673059-1-ziqianlu@bytedance.com)
*-*-*-*-*-*-*-*
[2025/07/15, LORE v3, 0/5](https://lore.kernel.org/all/20250715071658.267-1-ziqianlu@bytedance.com) | -### 2.1.4 leaf_cfs_rq +### 2.1.4 Flatten the pick ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/05/26 | Chengming Zhou | [sched/fair: optimize and simplify rq](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | TODO | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/ - +| 2022/05/26 | Chengming Zhou | [sched/fair: optimize and simplify rq](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | TODO | v3 ☐☑✓ | [LORE v3,0/2](https://lore.kernel.org/all/20220526103929.14976-1-zhouchengming@bytedance.com) | +| 2026/05/11 | Peter Zijlstra | [sched: Flatten the pick](https://lore.kernel.org/all/20260511113104.563854162@infradead.org) | 旨在改进 cgroup 调度中的权重分配与层级选取机制. 当前组调度的实现: ①多核 cgroup 权重分片规则: cgroup 的权重和配额分配, 把一个 cgroup 全局总配额(tg.w), 按照「各 CPU 上本组任务的负载占比」拆分到每一颗 CPU, 算出该 CPU 上组实体的有效调度权重; ② 选择任务时: 采用分层嵌套的任务 + 树形选择的方式. 先组和组之间抢 CPU, 再组内任务之间抢 CPU; 作者 Peter Zijlstra 指出当前 cgroup 调度在多 CPU 系统中存在权重碎片化问题(① 多核越多, 单 CPU 分到的权重和配额越小, 导致每 CPU 的 cgroup 权重过小. 64 核单 CPU 分组权重只剩10+, 256 核机器会被拆得更小), 影响调度效果(① CPU 上 `group->ge_i` 权重极低, 在 CPU 全局队列里竞争能力变弱; ② 同 cgroup 跨多 CPU 时, 全局 shares 被物理 CPU 切散, 整体拿不到标称的 CPU 配额; ③ 为了凑准全局比例, 必须实时汇总全 CPU 的 `∑grq_j->w`, 跨核读 remote CPU 的 cfs_rq 数据, 触发跨 NUMA / 跨 CPU 缓存失效、锁争抢, 性能开销高; 内核后期靠 load_avg 滑动负载近似替代全核求和(approximated reasonably well by now), 用平均负载规避频繁跨核求和, 但近似又带来公平性误差.). 为此, 补丁把树形递归选择逻辑重构成单层线性遍历, 消除嵌套、消除递归、减少分支, 大幅提升调度路径性能, 让调度延迟更稳定、代码更易维护.
1. 引入 `/debug/sched/cgroup_mode` 调试接口, 提供多种处理模式, 其中"concur"模式通过增加任务计数器提升负载更新准确性, 但带来更高开销.
补丁尝试"扁平化"层级选取机制, 在保留原有层级负载跟踪的同时, 将可运行实体统一至单一层次, 提升调度效率. 重加权操作在入队、选取任务和时钟中断时进行, 使调度更灵活.
作者通过运行游戏和多任务负载测试, 验证了调度改进效果, 结果显示在调整 slice 后游戏可流畅运行. | v2 ☐☑✓ | [2026/05/11, LORE v2, 0/10](https://lore.kernel.org/all/20260511113104.563854162@infradead.org)
*-*-*-*-*-*-*-*
[2026/06/05, LORE v3, 00/10](https://lore.kernel.org/all/20260605105513.354837583@infradead.org) | ## 2.2 实时进程的组调度支持 (RT Group Scheduling) @@ -889,7 +892,7 @@ Chang 的 patch set 采用了与之前不同的方法: 允许 cgroup 将一些 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2025/06/05 | Yuri Andriaccio | [Hierarchical Constant Bandwidth Server](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com) | 介绍了一个实现分层常量带宽服务器 (HCBS) 的补丁集 RFC, 旨在替代现有的 `RT_GROUP_SCHED` 机制, 使其更具鲁棒性和理论基础. 该补丁集已在 OSPM25 会议上展示, 相关机制详见[LWN 文章](https://lwn.net/Articles/1021332).
补丁内容包括代码重构、单层与多层调度支持、cgroup v2 支持, 并移除了 cgroup v1 的相关代码. 通过为每个 CPU 创建本地运行队列和 dl_server, 实现对 SCHED_FIFO/SCHED_RR 任务的带宽预留, 用户可通过 cgroup 接口配置 `rt_period_us` 和 `rt_runtime_us`.
测试代码已提供, 支持在 QEMU 或完整发行版中运行, 验证调度器的功能与时序保障. 作者表示后续将提交支持任务迁移、每 CPU 独立带宽、容量感知调度等特性. 参见 [LWN, 2025/06/18, The hierarchical constant bandwidth server scheduler](https://lwn.net/Articles/1024757) | v1 ☐☑✓ | [2025/06/05, LORE v1, 0/9](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/07/31, LORE RFC v2, 00/25](https://lore.kernel.org/all/20250731105543.40832-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/09/29, LORE v3, 00/24](https://lore.kernel.org/all/20250929092221.10947-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/12/01, LORE v4, 00/28](https://lore.kernel.org/all/20251201124205.11169-1-yurand2000@gmail.com) | +| 2025/06/05 | Yuri Andriaccio | [Hierarchical Constant Bandwidth Server](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com) | 介绍了一个实现分层常量带宽服务器 (HCBS) 的补丁集 RFC, 旨在替代现有的 `RT_GROUP_SCHED` 机制, 使其更具鲁棒性和理论基础. 该补丁集已在 OSPM25 会议上展示, 相关机制详见[LWN 文章](https://lwn.net/Articles/1021332).
补丁内容包括代码重构、单层与多层调度支持、cgroup v2 支持, 并移除了 cgroup v1 的相关代码. 通过为每个 CPU 创建本地运行队列和 dl_server, 实现对 SCHED_FIFO/SCHED_RR 任务的带宽预留, 用户可通过 cgroup 接口配置 `rt_period_us` 和 `rt_runtime_us`.
测试代码已提供, 支持在 QEMU 或完整发行版中运行, 验证调度器的功能与时序保障. 作者表示后续将提交支持任务迁移、每 CPU 独立带宽、容量感知调度等特性. 参见 [LWN, 2025/06/18, The hierarchical constant bandwidth server scheduler](https://lwn.net/Articles/1024757) | v1 ☐☑✓ | [2025/06/05, LORE v1, 0/9](https://lore.kernel.org/all/20250605071412.139240-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/07/31, LORE RFC v2, 00/25](https://lore.kernel.org/all/20250731105543.40832-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/09/29, LORE v3, 00/24](https://lore.kernel.org/all/20250929092221.10947-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2025/12/01, LORE v4, 00/28](https://lore.kernel.org/all/20251201124205.11169-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2026/04/03, LORE v5, 00/29](https://lore.kernel.org/all/20260430213835.62217-1-yurand2000@gmail.com)
*-*-*-*-*-*-*-*
[2026/06/08, LORE v6, 00/25](https://lore.kernel.org/all/20260608121546.69910-1-yurand2000@gmail.com) | | 2025/07/07 | Pan Deng | [sched/rt: mitigate root_domain cache line contention](https://lore.kernel.org/all/cover.1751852370.git.pan.deng@intel.com) | 这组补丁旨在缓解在云环境中运行多实例 FFmpeg 任务时, 因实时任务调度引发的 `root_domain` 缓存行争用问题. 测试环境为 2 路、240 核、480 线程的机器, 运行 60 个 FFmpeg 实例, 每个绑定 4 个物理核. 性能分析显示, 约 20% 的 CPU 周期消耗在内核调度函数, 主要由于 `root_domain` 和 `cpupri` 结构的缓存行争用.
补丁内容包括:
1. 优化 `cpupri_vec` 布局, 分离 `count` 和 `mask` 字段, 减少缓存行争用.
2. 重构 `root_domain` 结构, 合理重排字段以降低争用.
3. 将 `rto_count` 拆分为每个 NUMA 节点计数器.
4. 将 `cpupri_vec-> mask` 拆分为每个 NUMA 节点的位图.
实测结果显示, 各补丁带来了 3. 8%~11% 的 FPS 提升, 内核 CPU 使用率降至 11%~18. 7%, 缓存行争用显著下降. | v1 ☐☑✓ | [2025/07/07, LORE v1, 0/4](https://lore.kernel.org/all/cover.1751852370.git.pan.deng@intel.com) | | 2024/12/16 | Michal Koutný | [Add kernel cmdline option for rt_group_sched](https://lore.kernel.org/all/20241216201305.19761-1-mkoutny@suse.com) | [phoronix, 2025/05/27, Linux 6.16 Lands "rt_group_sched" Option, Faster Core Offlining & Scheduler Improvements](https://www.phoronix.com/news/Linux-6.16-Scheduler) | v1 ☐☑✓ | [LORE v1,0/9](https://lore.kernel.org/all/20241216201305.19761-1-mkoutny@suse.com)
*-*-*-*-*-*-*-*
[LORE v1,0/9](https://lore.kernel.org/all/20250210151239.50055-1-mkoutny@suse.com)
*-*-*-*-*-*-*-*
[LORE v2,00/10](https://lore.kernel.org/all/20250310170442.504716-1-mkoutny@suse.com/) | @@ -1407,7 +1410,7 @@ enqueue_task() | 2022/07/04 | Sudeep Holla | [arch_topology: Updates to add socket support and fix cluster ids](https://lore.kernel.org/all/20220704101605.1318280-1-sudeep.holla@arm.com) | [Impact of recent CPU topology changes on Android's phantom domains](https://lpc.events/event/16/contributions/1342) | v6 ☐☑✓ | [LORE v6,0/21](https://lore.kernel.org/all/20220704101605.1318280-1-sudeep.holla@arm.com) | | 2023/07/24 | Thomas Gleixner | [x86/cpu: Rework the topology evaluation](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=bcccdf8b30736250d5057e0940468a41d633e672) | [Cleaning Up A Mess: Linux 6.9 Likely To Land Rework Of x86 CPU Topology Code](https://www.phoronix.com/news/Linux-6.9-x86-CPU-Topology-Code) 和 [Linux 6.9 Lands Reworked Topology Code For Better Hybrid CPU Support](https://www.phoronix.com/news/Linux-6.9-APIC-x86-CPU-Topology). | v1 ☐☑✓ 6.9-rc1 | [2023/07/24 LORE v1,0/29](https://lore.kernel.org/all/20230724155329.474037902@linutronix.de)
*-*-*-*-*-*-*-*
[2024/02/13 V6,01/19] x86/cpu: Provide cpuid_read() et al.](https://lore.kernel.org/all/20240212153624.516965279@linutronix.de) | | 2023/08/07 | Thomas Gleixner | [x86/topology: The final installment](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=89b0f15f408f7c4ee98c1ec4c3224852fcbc3274) | APIC id 描述了多个域级别的系统拓扑. CPUID 拓扑解析器提供了 APIC ID 的哪一部分与各个级别 (英特尔术语) 相关联的信息: `[ROOT][PACKAGE][DIE][TILE][MODULE][CORE][THREAD]`, 如果不支持 SMT, 则仍然使用 THREAD 域. 然后, 它与 CORE 域具有相同的物理 ID, 并且是 CORE 域的唯一子域. 这允许独立于枚举域级别的系统统一视图, 而不需要代码中的任何条件. 参见 [Linux 6.9 Lands Reworked Topology Code For Better Hybrid CPU Support](https://www.phoronix.com/news/Linux-6.9-APIC-x86-CPU-Topology). | v1 ☐☑✓ 6.9-rc1 | [LORE v1,0/53](https://lore.kernel.org/all/20230807130108.853357011@linutronix.de)
*-*-*-*-*-*-*-*
[x86/topology: More cleanups and preparatory work, V3, 00/22, STEP1](https://lore.kernel.org/all/20240212154639.057209154@linutronix.de)
*-*-*-*-*-*-*-*
[x86/apic: Rework APIC registration, V1, 00/30, STEP2](https://lore.kernel.org/all/20240213210253.176147806@linutronix.de) | -| 2026/01/20 | K Prateek Nayak | [sched/topology: Optimize sd->shared allocation](https://lore.kernel.org/all/20260120113246.27987-1-kprateek.nayak@amd.com) | 旨在优化 Linux 调度器中 `sched_domain_shared`( `sd-> shared`) 的分配方式. 当前为每个调度域层级分配 `sd-> shared`, 但实际仅 `sd_llc_shared` 被使用, 造成内存浪费. 补丁将 `sd-> shared` 从每个调度域数据( `sd_data`) 中移出,改为在 `s_data` 中一次性分配, 仅在 LLC( Last Level Cache) 层级分配实际使用的 `sd-> shared`.

补丁还优化了调度域退化路径中对 `sd-> shared` 的处理, 并简化了空闲 CPU 扫描和唤醒路径中的 RCU 锁使用, 提升代码清晰度和性能. 此系列基于调度核心分支最新提交, 已去除 RFC 标签, 进入正式评审阶段. | v3 ☐☑✓ | [2026/01/20, LORE v3, 0/8](https://lore.kernel.org/all/20260120113246.27987-1-kprateek.nayak@amd.com) | +| 2026/01/20 | K Prateek Nayak | [sched/topology: Optimize sd->shared allocation](https://lore.kernel.org/all/20260120113246.27987-1-kprateek.nayak@amd.com) | 旨在优化 Linux 调度器中 `sched_domain_shared`( `sd-> shared`) 的分配方式. 当前为每个调度域层级分配 `sd-> shared`, 但实际仅 `sd_llc_shared` 被使用, 造成内存浪费. 补丁将 `sd-> shared` 从每个调度域数据( `sd_data`) 中移出,改为在 `s_data` 中一次性分配, 仅在 LLC( Last Level Cache) 层级分配实际使用的 `sd-> shared`.

补丁还优化了调度域退化路径中对 `sd-> shared` 的处理, 并简化了空闲 CPU 扫描和唤醒路径中的 RCU 锁使用, 提升代码清晰度和性能. 此系列基于调度核心分支最新提交, 已去除 RFC 标签, 进入正式评审阶段. | v3 ☐☑✓ | [2026/01/20, LORE v3, 0/8](https://lore.kernel.org/all/20260120113246.27987-1-kprateek.nayak@amd.com)
*-*-*-*-*-*-*-*
[2026/03/12, LORE v4,0/9](20260312044434.1974-1-kprateek.nayak@amd.com) | ### 4.1.2 3-hops 问题 @@ -2138,6 +2141,7 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能 | 2010/05/17 | Suresh Siddha | [sched: change nohz idle load balancing logic to push model](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83cd4fe27ad8446619b2e030b171b858501de87d) | 现有的 nohz 空闲负载平衡逻辑使用 PULL 模式, 在部分 CPU 空闲的系统上指定一个空闲的 CPU 来做负载均衡 (balancer CPU), 并且该平衡器 CPU 不进入 NO_HZ 模式. 通过周期性的 TICK, 平衡器在 NO_HZ 模式下代表所有 CPU 进行空闲平衡. 另一种选择是使用 PUSH 模式, 在这种模式下, 所有空闲 CPU 都可以进入 NO_HZ 模式, 任何忙碌的 CPU 都可以 kick 一个空闲 CPU, 以代表一组空闲 CPU 处理 idle balancing. 这个补丁就将 NOHZ Idle Balance 切换到了 PUSH 模式. | RFC ☑ 2.6.36-rc1 | [LORE v1,0/2](https://lore.kernel.org/all/20090617182649.604970000@intel.com)
*-*-*-*-*-*-*-*
[LORE 0/7](https://lore.kernel.org/all/20100517184027.862696498@sbs-t61.sc.intel.com), [LORE](https://lore.kernel.org/all/1273886490-15627-1-git-send-email-venki@google.com)
*-*-*-*-*-*-*-*
[COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83cd4fe27ad8446619b2e030b171b858501de87d) | | 2025/09/04 | K Prateek Nayak | [sched/fair: Distributed nohz idle CPU tracking for idle load balancing](https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com) | 旨在改进 Linux 调度器中 nohz idle CPU 的跟踪机制, 以支持更高效的空闲负载均衡. 目前的全局 cpumask 和 idle 状态跟踪机制在频繁访问时存在性能瓶颈, 补丁将跟踪机制分布化, 基于 sd_llc_shared 拓扑结构维护每个 LLC 的 idle 状态和 cpumask.
主要改进包括:
- 实现 per-LLC 的 nohz 跟踪和全局" nohz_shared_list" 管理;
- 减少原子操作, 仅在 idle 状态边界变化时更新全局计数;
- 支持热插拔和 cpuset 的状态修正;
- 逐步替代现有全局变量 "nohz. idle_cpus_mask" 和 "nohz. nr_cpus".
性能测试显示, 在部分场景下调度性能有所提升, 但部分测试中也出现延迟上升等回归问题, 作者指出这可能与运行环境噪声有关.

总结: 本 RFC 提出了一种分布式 nohz idle 跟踪机制, 旨在减少全局竞争, 提升调度性能, 适用于未来基于 push 的负载均衡机制. | v1 ☐☑✓ | [2025/09/04, LORE v1, 0/19](https://lore.kernel.org/all/20250904041516.3046-1-kprateek.nayak@amd.com) | | 2025/12/08 | K Prateek Nayak | [sched/fair: Push-based load balancing](https://lore.kernel.org/all/20251208083602.31898-1-kprateek.nayak@amd.com) | 旨在改进 Linux 调度器的负载均衡机制, 解决以下三个主要问题:
1. **忙时负载均衡不均**: 当前总是由组中第一个 CPU 承担负载均衡任务, 导致负载不均.
2. **nohz 全局变量扩展性差**: 全局变量在大规模系统中存在性能瓶颈.
3. **周期性负载均衡延迟高**: 在大型、扁平调度域结构中, 任务等待时间长, 尾延迟高.
**主要改进包括: **
- **忙平衡 CPU 轮换机制**: 在调度组中轮换负责忙平衡的 CPU, 减少单点负载.
- **nohz 本地化优化**: 将 idle CPU 掩码嵌入调度域层次结构, 减少全局原子操作.
- **[实验性] 推送式负载均衡**: 主动将任务推送到空闲 CPU, 提升性能但可能引入微基准测试回归.
- **[实验性] 优化 NUMA 内部新空闲平衡**: 改进新空闲负载均衡路径, 但存在锁竞争和性能波动.

**基准测试显示: **
在部分场景(如 deathstarbench) 中性能提升明显, 但部分微基准( 如 hackbench、tbench) 有小幅下降. 实验性功能仍需进一步优化与评估.

该工作将在 **LPC' 25** 的调度器与实时系统分会上讨论. | v2 ☐☑✓ | [2025/12/08, LORE v2, 0/29](https://lore.kernel.org/all/20251208083602.31898-1-kprateek.nayak@amd.com) | +| 2025/12/02 | Vincent Guittot | [sched/fair: Add push task mechanism and handle more EAS cases](https://lore.kernel.org/all/20251202181242.1536213-1-vincent.guittot@linaro.org) | 旨在改进 Linux 调度器的 EAS(Energy Aware Scheduling) 机制, 增强对任务迁移和负载均衡的支持. 主要内容包括:
1. 修复因 CPU 计算能力受限导致的误判为过载问题, 影响负载均衡决策;
2. 移除 cpu_overutilized 中对 uclamp_min 的依赖, 优化任务迁移触发条件;
3. 扩展 select_task_rq_fair() 调用场景, 支持无 fork/exec 的任务重调度;
4. 引入 push task 机制, 但默认未启用;
5. 在非 SMP 系统中启用 idle core 跟踪, 提升 LLC 内空闲 CPU 检测能力;
6. 增加 EAS 下任务 push 触发条件, 如任务卡住或系统过载时寻找空闲 CPU. | v8 ☐☑✓ | [2025/12/02, LORE v8, 0/6](https://lore.kernel.org/all/20251202181242.1536213-1-vincent.guittot@linaro.org) | ### 4.3.6 Migrations Rate Limits @@ -2156,7 +2160,11 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能 |:---:|:----:|:---:|:----:|:---------:|:----:| | 2025/03/25 | Peter Zijlstra | [sched: Cache aware load-balancing](https://lore.kernel.org/all/20250325120952.GJ36322@noisy.programming.kicks-ass.net) | 这个补丁旨在实现调度器中的缓存感知负载均衡功能. 以下是该补丁的主要内容和目标:
1. 缓存亲和性建模: 补丁尝试对缓存亲和性进行建模, 特别是针对 LLC(Last Level Cache) 层面. 虽然目前主要关注于 LLC, 但理论上也可以扩展到处理 L2 等其他缓存域的情况.
2. 选择最佳 CPU: 它计算在同一个 LLC 内的最近运行时间最长的 CPU, 并在唤醒路径中使用这个 CPU 来引导任务分配, 同时在 task_hot() 函数中限制从这个 CPU 迁移任务, 以保持缓存亲和性.
3. 潜在的扩展能力: 补丁中提到一个 XXX 标记, 表明未来可能需要考虑如何在一个节点内找到最佳的 LLC(与 NUMA_BALANCING 的交互), 这意味着该补丁有进一步发展的空间.
这个补丁的目标是通过改进 Linux 内核的调度器, 使其能够更加智能地考虑缓存的影响, 从而提高系统性能。具体来说, 就是通过优化任务到 CPU 的分配策略来减少由于频繁跨缓存域迁移导致的性能损失. | v1 ☐☑✓ | [2025/03/25, LORE](https://lore.kernel.org/all/20250325120952.GJ36322@noisy.programming.kicks-ass.net) | | 2025/04/21 | Chen Yu | [sched: Introduce Cache aware scheduling](https://lore.kernel.org/all/cover.1745199017.git.yu.c.chen@intel.com) | 该邮件由 Chen Yu 提交, 提出并更新了 "Cache-aware scheduling" (缓存感知调度) 的 RFC 补丁集(共 5 个补丁) , 旨在提升系统性能. 该调度机制通过将资源共享的进程集中调度到同一缓存域中, 提高缓存局部性, 减少缓存缺失. 补丁集修复了前一版本中的问题, 优化了任务迁移逻辑, 避免在缓存域过载时的性能下降, 并新增 ftrace 事件以辅助性能分析. 参见 [phoronix, 2025/04/21, Intel Posts Newest Code For Cache Aware Scheduling On Linux](https://www.phoronix.com/news/Linux-RFC-Cache-Aware-Sched), [lwn, 2025/04/29, Cache awareness for the CPU scheduler](https://lwn.net/Articles/1018334), [phoronix, 2025/06/18, Cache-Aware Scheduling For Linux Refined - Better AMD & Intel CPU Performance](https://www.phoronix.com/news/Linux-Cache-Aware-Sched-v3), [phoronix, 2025/10/13, Updated Intel Patches For Cache Aware Scheduling Net A 44% Win For AMD EPYC](https://www.phoronix.com/news/Cache-Aware-Scheduling-Go), [phoronix, 2025/10/17, New Linux Kernel Patches From Intel Delivering +18% Database Performance](https://www.phoronix.com/news/Linux-MM-CID-Faster-DBs), [phoronix, 2025/10/23, Linux's Proposed Cache Aware Scheduling Benchmarks Show Big Potential On AMD EPYC Turin](https://www.phoronix.com/review/cache-aware-scheduling-amd-turin). | v1 ☐☑✓ | [2025/04/21, LORE v1, 0/5](https://lore.kernel.org/all/cover.1745199017.git.yu.c.chen@intel.com)
*-*-*-*-*-*-*-*
[2025/06/18, LORE v3, 00/20](https://lore.kernel.org/all/cover.1750268218.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/08/09, LORE v4, 00/28](https://lore.kernel.org/all/cover.1754712565.git.tim.c.chen@linux.intel.com) | -| 2025/12/03 | Tim Chen | [Cache aware scheduling](https://lore.kernel.org/all/cover.1764801860.git.tim.c.chen@linux.intel.com) | 旨在引入**缓存感知调度( cache-aware scheduling) **基础设施, 目标是将共享数据的任务调度到同一**末级缓存( LLC) 域**, 以提升缓存局部性, 减少缓存一致性开销, 提高数据访问效率.
补丁主要改进包括:
- **LLC ID 连续化**, 便于统计和索引;
- **优先 NUMA 平衡**, 在 NUMA 与缓存调度策略冲突时以 NUMA 为准;
- **动态调整 LLC 统计结构大小**;
- **引入 per-LLC 统计与任务偏好机制**, 用于调度决策;
- **支持用户配置缓存调度参数**;
- **优化负载均衡中任务迁移策略**, 优先迁移偏好 LLC 的任务;
- **新增调试与统计功能**( 如 ftrace、proc 显示等) .未来计划包括:

- 支持跨进程任务分组;
- 引入可配置的缓存调度策略( 如通过 prctl) ;
- 支持 NUMA 组、waker/wakee 关系等场景.

补丁已获得初步反馈, 部分建议将作为后续改进. 参见 [phoronix, 2025/12/16, Intel's Cache Aware Scheduling Presentation At LPC 2025](https://www.phoronix.com/news/Cache-Aware-Scheduling-2025) | v2 ☐☑✓ | [2025/10/11, LORE v2, 00/19](https://lore.kernel.org/all/cover.1760206683.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/12/03, LORE v2, 0/23](https://lore.kernel.org/all/cover.1764801860.git.tim.c.chen@linux.intel.com) | +| 2025/12/03 | Tim Chen | [Cache aware scheduling](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=067a3135814334a8ea7241faef364cc48c6340bc) | 旨在引入**缓存感知调度( cache-aware scheduling) **基础设施, 目标是将共享数据的任务调度到同一**末级缓存( LLC) 域**, 以提升缓存局部性, 减少缓存一致性开销, 提高数据访问效率.
补丁主要改进包括:
- **LLC ID 连续化**, 便于统计和索引;
- **优先 NUMA 平衡**, 在 NUMA 与缓存调度策略冲突时以 NUMA 为准;
- **动态调整 LLC 统计结构大小**;
- **引入 per-LLC 统计与任务偏好机制**, 用于调度决策;
- **支持用户配置缓存调度参数**;
- **优化负载均衡中任务迁移策略**, 优先迁移偏好 LLC 的任务;
- **新增调试与统计功能**( 如 ftrace、proc 显示等) .未来计划包括:

- 支持跨进程任务分组;
- 引入可配置的缓存调度策略( 如通过 prctl) ;
- 支持 NUMA 组、waker/wakee 关系等场景.

补丁已获得初步反馈, 部分建议将作为后续改进. 参见 [phoronix, 2025/12/16, Intel's Cache Aware Scheduling Presentation At LPC 2025](https://www.phoronix.com/news/Cache-Aware-Scheduling-2025) | v2 ☐☑✓ v7.2-rc1 | [2025/10/11, LORE v2, 00/19](https://lore.kernel.org/all/cover.1760206683.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2025/12/03, LORE v2, 00/23](https://lore.kernel.org/all/cover.1764801860.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[2026/04/01, LORE v4, 00/22](https://lore.kernel.org/all/cover.1775065312.git.tim.c.chen@linux.intel.com) | +| 2026/05/13 | Tim Chen | [Cache aware scheduling enhancements](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=c99b8593b060931c5a0a4b701689f8d6a2c00dbf) | 该邮件由 Tim Chen 提交, 包含 16 个补丁, 旨在增强 Linux 调度器的缓存感知( cache-aware) 调度能力. 主要改进包括: 修复 v4 版本中遗留的过度聚合问题、优化 LLC( 最后一级缓存) 大小存储方式、使用 NUMA 平衡页错误统计估算工作集、减少 CPU 扫描开销等. 补丁还修复了多个竞态条件和潜在问题, 如 RCU 警告、空指针访问、负载均衡判断错误等. 测试表明性能与 v4 相当. 未来计划引入对特定任务的细粒度缓存调度控制. Chen Yu 将在 Tim 休假期间继续维护该补丁集. | v4 ☐☑✓ v7.2-rc1 | [2026/05/13, LORE v4, 00/16](https://lore.kernel.org/all/cover.1778703694.git.tim.c.chen@linux.intel.com) | +| 2026/07/23 | Luo Gengkun | [Cache aware scheduling: Reduce the overhead of task_cache_work](https://lore.kernel.org/all/20260723040429.630176-1-luogengkun2@huawei.com) | 降低 Cache aware scheduling 中 `task_cache_work()` 的调度开销, 提升多实例场景(如 Redis)性能. 核心改进在于通过记录已访问 CPU(visited_cpus)减少扫描的 CPU 数量, 从而显著降低 cache-aware 调度的开销.
测试结果显示, 在禁用 NUMA 平衡时, Redis 的 P99 延迟从 0.554ms 降至 0.441ms, 性能提升约 20%; `perf top` 显示 `task_cache_work()` 的 CPU 开销从 0.81% 降至 0.02%. 启用 NUMA 平衡后仍保持性能优势. Hackbench 测试表明该优化不影响调度准确性. | v8 ☐☑✓ | [2026/07/23, LORE v8, 0/2](https://lore.kernel.org/all/20260723040429.630176-1-luogengkun2@huawei.com) | + + ### 4.3.8 Predict load based ------- @@ -2202,7 +2210,7 @@ update_blocked_averages() 在多个场景都被发现成为非常严重的性能 -## 4.4 Idle Balance +## 4.4 (new)Idle Balance ------- @@ -2235,6 +2243,8 @@ idle balance 中执行 update_blocked_average 是很费时费力的, 可以做 [sched/fair: Rate limit calls to update_blocked_averages() for NOHZ](https://lkml.kernel.org/lkml/20210122154600.1722680-1-joel@joelfernandes.org) +#### 4.4.2.1 reduce the cost of newidle balance +------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:---:|:----------:|:----:| @@ -2243,16 +2253,16 @@ idle balance 中执行 update_blocked_average 是很费时费力的, 可以做 | 2022/06/08 | Josh Don | [sched: allow newidle balancing to bail out of load_balance](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=792b9f65a568f48c50b3175536db9cde5a1edcc0) | 在执行 newidle 负载平衡时, 可能会有新任务到达, 也可能有挂起的唤醒. 如果检测到这些情况, newidle_balance() 已经通过退出 sched_domain load_balance() 解决了这个问题. 这对于最小化唤醒延迟非常重要.
然而, 如果我们已经在 load_balance() 中, 在返回到 newidle_balance() 之前, 我们可能会在那里停留一段时间. 如果我们在 LBF_ALL_PINNED 情况下输入 "goto redo" 循环, 情况会更加恶化. 一个非常直接的解决方法是调整 should_we_balance(), 以便在执行 CPU_NEWLY_IDLE Balance 且检测到新任务时释放. 测试发现, 两个轮流休眠和相互唤醒的线程绑定到两个核上, 其他大量利用率为 100% 的线程被绑定到所有其他核上, 如果没有这个补丁, 这对线程的唤醒延迟约为 120us, 几乎全部花费在 load_balance() 中. 合入这个补丁后, 唤醒延迟降低到 6us. | v1 ☑✓ 6.0-rc1 | [LORE](https://lore.kernel.org/all/20220609025515.2086253-1-joshdon@google.com) | | 2023/07/27 | Chen Yu | [Optimization to reduce the cost of newidle balance](https://lore.kernel.org/all/cover.1690273854.git.yu.c.chen@intel.com) | 这是新空闲平衡优化 [Limit the scan depth to find the busiest sched group during newidle balance](https://lore.kernel.org/all/cover.1686554037.git.yu.c.chen@intel.com) 的新版本. 它旨在降低新空闲平衡的成本, 在一些高核计数系统上, 新空闲平衡被发现占用了明显的 CPU 周期. 例如, 当在 Intel Sapphire Rapids 上运行 sqlite 时, 它有 2 x 56C/112T = 224 个 cpu: newidle_balance 以及 update_sd_lb_stats 的热点达到 5% 以上. 为了减少这一开销, Tim 提出的问题启发了我们进行优化:
1. 第一个是 ILB_UTIL. 建议在 update_sd_lb_stats() 中限制扫描深度. 扫描深度取决于该调度域的总体利用率. 利用率越高, update_sd_lb_stats() 扫描的数据就越少. 亦然.
2. 第二个是 ILB_FAST. 与其总是在 update_sd_lb_stats() 中查找最繁忙的组, 不如降低标准并尝试查找相对繁忙的组. 当本地组为 group_has_spare 时, ILB_FAST 生效. 因为当有许多 cpu 并发地运行 newidle_balance() 时, 计划组应该有很高的空闲百分比.
3. 与 ILB_UTIL 和 ILB_FAST 相比, ILB_UTIL 抑制了系统繁忙时的调度组扫描. 后者在系统不忙时选择折衷的忙群. 它们相互补充, 独立工作. | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/cover.1690273854.git.yu.c.chen@intel.com) | | 2024/01/19 | K Prateek Nayak | [sched/fair: Skip newidle_balance() when an idle CPU is woken up to process an IPI](https://lore.kernel.org/all/20240119084548.2788-1-kprateek.nayak@amd.com) | 当使用 Anton Blanchard 的 [ipistorm 基准 BenckMark](https://github.com/antonblanchard/ipistorm) 的修改版本测量 IPI 吞吐量时, 配置为测量执行固定数量的 smp_call_function_single() 所花费的时间 (等待设置为 1), 在 v5.7 和 v5.8 之间观察到基准时间的增加. Bissection 指出, [commit b2a02fc43a1f ("smp:Optimize send_call_function_single_ip()")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b2a02fc43a1f40ef4eb2fb2b06357382608d4d84) 是运行时间增加的原因. 由于最新的内核不可能进行干净的恢复, 为了恢复旧的行为, 跳过了 send_call_function_single_prep_ipi() 中的 call_function_single_pip() 检查, 导致 send_call_function_single_ip() 始终调用 arch_send_call_formation_singe_ipi(). 这个相同提交在 do_idle() 中引入的 flush_smp_call_function_queue() 也被删除, 因为上述更改将无条件地在 TIF_POLLING 模式下向空闲 CPU 发送 IPI. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240119084548.2788-1-kprateek.nayak@amd.com) | +| 2021/10/19 | Vincent Guittot | [Improve newidle lb cost tracking and early abort](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=8ea9183db4ad8afbcb7089a77c23eaf965b0cacd) | 通过考虑更新阻塞负载 update_blocked_averages() 所花费的时间, 在没有机会运行至少一个负载平衡循环的情况下完全跳过负载平衡循环. 因此在 newidle_balance() 中, 当 this_rq 的第一个 sd 满足 `this_rq->avg_idle max_newidle_lb_cost` 时, 认为执行 update_blocked_averages() 是非常昂贵且没有收益的, 只会增加开销. 因此在 newidle_balance() 中尽早检查条件, 尽可能跳过 update_blocked_averages() 的执行. | v3 ☑ [5.16-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a7e0a90a454) | [2021/10/4 LKML v1](https://lkml.org/lkml/2021/10/4/1188)
*-*-*-*-*-*-*-*
[2021/10/04 PatchWork](https://lore.kernel.org/lkml/20211004171451.24090-1-vincent.guittot@linaro.org), [LKML](https://lkml.org/lkml/2021/10/4/1188)
*-*-*-*-*-*-*-*
[LKML v3,0/5](https://lkml.org/lkml/2021/10/19/590), [LORE v3,0/5](https://lore.kernel.org/all/20211019123537.17146-1-vincent.guittot@linaro.org), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d783c8dd112) | -### 4.4.2 Improve cost accounting of newidle_balance -------- +#### 4.4.2.2 proportional newidle balance(NI_TARGET/NI_RANDOM) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:---:|:----------:|:----:| -| 2021/10/19 | Vincent Guittot | [Improve newidle lb cost tracking and early abort](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=8ea9183db4ad8afbcb7089a77c23eaf965b0cacd) | 通过考虑更新阻塞负载 update_blocked_averages() 所花费的时间, 在没有机会运行至少一个负载平衡循环的情况下完全跳过负载平衡循环. 因此在 newidle_balance() 中, 当 this_rq 的第一个 sd 满足 `this_rq->avg_idle max_newidle_lb_cost` 时, 认为执行 update_blocked_averages() 是非常昂贵且没有收益的, 只会增加开销. 因此在 newidle_balance() 中尽早检查条件, 尽可能跳过 update_blocked_averages() 的执行. | v3 ☑ [5.16-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a7e0a90a454) | [2021/10/4 LKML v1](https://lkml.org/lkml/2021/10/4/1188)
*-*-*-*-*-*-*-*
[2021/10/04 PatchWork](https://lore.kernel.org/lkml/20211004171451.24090-1-vincent.guittot@linaro.org), [LKML](https://lkml.org/lkml/2021/10/4/1188)
*-*-*-*-*-*-*-*
[LKML v3,0/5](https://lkml.org/lkml/2021/10/19/590), [LORE v3,0/5](https://lore.kernel.org/all/20211019123537.17146-1-vincent.guittot@linaro.org), [关键 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d783c8dd112) | -| 2025/06/26 | Chris Mason | [sched/fair: bump sd->max_newidle_lb_cost when newidle balance fails](https://lore.kernel.org/all/20250626144017.1510594-2-clm@fb.com) | 邮用于修复 COMMIT `c5b0a7eefc sched/fair: Remove sysctl_sched_migration_cost condition` 条件导致的性能回归问题.使用 `schbench` 工具进行测试, 每秒请求数(RPS)从 5.4M 下降到 3.4M, 问题表现为 `newidle balance` 操作次数增加了约 100 倍, 这些操作大多失败, 未能找到负载可迁移的 CPU. 工作线程约 20% 的时间花在 `newidle balance` 上.
因此本补丁尝试在 newidle balance 失败时增大其成本(`domain_cost`), 从而抑制其频繁触发. 同时对成本的上限进行限制, 防止其无限增长.
补丁修改了 `update_newidle_cost( ) ` 和 `sched_balance_newidle( ) ` 函数逻辑.
sched_balance_newidle()` 函数中, 原逻辑: 无论 newidle balance 是否成功，均使用实际耗时更新 `max_newidle_lb_cost`. 新逻辑: 如果没有拉取到任务(`pulled_task == false`), 则将该次 balance 的 cost 提升为当前最大 cost 的 1.5 倍. 这样做的目的是: 提升失败操作的成本感知, 使得调度器在未来更谨慎地触发 newidle balance. `update_newidle_cost()` 函数中, 原逻辑: 直接更新 `sd->max_newidle_lb_cost = cost;`, 新逻辑: 增加上限限制, 使用 `sysctl_sched_migration_cost + 200` 作为最大值. 避免成本无限增长. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250626144017.1510594-2-clm@fb.com) | +| 2025/06/26 | Chris Mason | [sched/fair: bump sd->max_newidle_lb_cost when newidle balance fails](https://lore.kernel.org/all/20250626144017.1510594-2-clm@fb.com) | 邮用于修复 COMMIT `c5b0a7eefc sched/fair: Remove sysctl_sched_migration_cost condition` 条件导致的性能回归问题.使用 `schbench` 工具进行测试, 每秒请求数(RPS)从 5.4M 下降到 3.4M, 问题表现为 `newidle balance` 操作次数增加了约 100 倍, 这些操作大多失败, 未能找到负载可迁移的 CPU. 工作线程约 20% 的时间花在 `newidle balance` 上.
因此本补丁尝试在 newidle balance 失败时增大其成本(`domain_cost`), 从而抑制其频繁触发. 同时对成本的上限进行限制, 防止其无限增长.
补丁修改了 `update_newidle_cost()` 和 `sched_balance_newidle( )` 函数逻辑.
sched_balance_newidle()` 函数中, 原逻辑: 无论 newidle balance 是否成功，均使用实际耗时更新 `max_newidle_lb_cost`. 新逻辑: 如果没有拉取到任务(`pulled_task == false`), 则将该次 balance 的 cost 提升为当前最大 cost 的 1.5 倍. 这样做的目的是: 提升失败操作的成本感知, 使得调度器在未来更谨慎地触发 newidle balance. `update_newidle_cost()` 函数中, 原逻辑: 直接更新 `sd->max_newidle_lb_cost = cost;`, 新逻辑: 增加上限限制, 使用 `sysctl_sched_migration_cost + 200` 作为最大值. 避免成本无限增长. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250626144017.1510594-2-clm@fb.com) | | 2025/11/07 | Peter Zijlstra | [sched: The newidle balance regression](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=33cf66d88306663d16e4759e9d24766b0aaa2e17) | 解决由提交 `155213a2aed4 ("sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails")` 引入的调度器 newidle balance 逻辑的性能退化问题, 重新引入 newidle balance 的"目标+随机"(NI_TARGET + NI_RANDOM)策略的比例型 proportional newidle balance, 提供一个更加合理和高效的 newidle balance 机制, 以提高系统整体的负载均衡效果与性能.
为了控制 newidle 平衡的开销, 调度器维护了一个 `sd->max_newidle_lb_cost` 指标, 表示执行 newidle balance 的平均代价. 当 newidle balance 没有成功迁移任务时, 该值会增加, 从而降低后续触发 newidle 的频率. 这是 COMMIT `155213a2aed4` 的初衷. 然而, 这一改动导致了: 在某些负载下 newidle balance 过于保守, 错失负载均衡机会. 性能退化, 尤其是在需要快速响应负载变化的场景. Patch 1-2: Revert 回退到更早的 newidle 行为(NI_TARGET), 移除了 newidle balance 失败时对 domain_cost 的放大处理. 恢复使用实际测量值更新 max_newidle_lb_cost, 删除了 sysctl_sched_migration_cost 的上限限制, 着回到了 newidle 仅尝试迁移到目标调度组(target group)的方式, 该行为在旧版本中表现良好, 避免了不必要的平衡请求. Patch 3-4: 引入 proportional newidle balance, 在目标组失败后, 以一定概率尝试其他调度组(NI_RANDOM), 类似于 NI_TARGET + NI_RANDOM 的组合策略. | v1 ☐☑✓ v6.19-rc1 | [2025/11/07, LORE v1, 0/4](https://lore.kernel.org/all/20251107160645.929564468@infradead.org) | +| 2026/05/18 | Luo Gengkun | [sched/fair: Introduce half-idle retry mechanism in NI_RANDOM](https://lore.kernel.org/all/20260518124346.4010277-1-luogengkun2@huawei.com) | 邮件提出了一项针对 Linux 调度器中 `NI_RANDOM` 特性的改进补丁, 旨在解决新空闲负载均衡中可能跳过某些调度域而导致的空闲时间浪费问题.补丁引入了“半空闲重试机制”, 在首次均衡未拉取任务且剩余空闲时间超过 `avg_idle / 2` 时, 重新评估之前跳过的调度域.
重试机制受以下限制: 仅在剩余空闲时间充足时触发、动态调整重试窗口、限定在 LLC 域、仅重试首次被跳过的域.性能测试显示, 该机制在多线程负载下提升了每秒请求数(RPS)并降低了唤醒延迟. | v1 ☐☑✓ | [2026/05/18, LORE](https://lore.kernel.org/all/20260518124346.4010277-1-luogengkun2@huawei.com) | ### 4.4.3 Task Stealing From LLC @@ -2688,9 +2698,15 @@ void nohz_run_idle_balance(int cpu) | 2021/11/12 | Vincent Guittot | [avoid spurious blocked load update](https://lore.kernel.org/all/20211112095857.7016-1-vincent.guittot@linaro.org) | 20211112095857.7016-1-vincent.guittot@linaro.org | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20211112095857.7016-1-vincent.guittot@linaro.org) | +#### 4.5.6.2 其他 NOHZ Idle Balance 降负载操作 + | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:---:|:----------:|:----:| | 2014/1/28 | Mike Galbraith | [sched, nohz: Exclude isolated cores from load balancing](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d987fc7f3228) | isolated CPU 不再进行负载均衡. | v1 ☑ 3.15-rc1 | [LKML](https://lkml.org/lkml/2014/2/21/736) | +| 2026/04/21 | Imran Khan | [sched/fair: Reduce nohz_idle_balance CPU overhead on large systems](https://lore.kernel.org/all/20260421050622.19869-1-imran.f.khan@oracle.com) | 旨在减少大型系统( 700+ CPU) 中 `nohz_idle_balance` 引起的 CPU 开销. 问题一: 因 CPU 数量多, `nohz. next_balance` 常与当前 jiffies 接近, 导致几乎每次 tick 都触发空闲平衡工作. 补丁 1 通过根据空闲 CPU 数量调整 `nohz. next_balance` 解决此问题. 问题二: `find_new_ilb()` 总是从最低编号 CPU 开始分配空闲负载, 造成同一 CPU 承担大部分工作. 补丁 2 改进该逻辑, 将 `nohz ILB` 工作分散到多个空闲 CPU 上, 提升负载均衡. | v1 ☐☑✓ | [2026/04/21, LORE v1, 0/2](https://lore.kernel.org/all/20260421050622.19869-1-imran.f.khan@oracle.com) | + + + ### 4.5.7 NO_HZ Idle Balancing 的其他更新 @@ -4067,6 +4083,7 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其 | 2019/06/26 | subhra mazumdar | [Scheduler Soft Affinity](https://lore.kernel.org/lkml/20190626224718.21973-1-subhra.mazumdar@oracle.com) | 为任务提供 "软亲和力" 的概念, 向调度程序指定在调度任务时首选一组 CPU, 但如果它们不全都繁忙, 则使用其他 CPU. | RFC ☐ | [LORE RFC,0/3](https://lore.kernel.org/lkml/20190626224718.21973-1-subhra.mazumdar@oracle.com) | | 2025/05/02 | chris hyser | [sched/numa, mm/numa: Soft Affinity via numa_preferred_nid.](https://lore.kernel.org/all/20250502190059.4121320-1-chris.hyser@oracle.com) | 本补丁集合旨在实现一种称为 **Soft Affinity** 的机制, 通过用户空间接口 (prctl) 允许用户程序或管理员设置任务 (进程 / 线程) 的首选 NUMA 节点 (numa_preferred_nid), 并利用当前的 **Auto NUMA Balancing(自动 NUMA 平衡) 机制** 来倾向将任务调度到该节点、并优先在该节点分配内存. 该功能是对之前被拒绝的 "Soft Affinity" 提议的重新实现, 其核心思想是:
1. 允许用户设置一个 "偏好" 节点 (numa_preferred_nid);
2. 不强行绑定任务到该节点(不破坏调度灵活性);
3. 利用已有 NUMA 平衡机制, 引导任务和其访问频繁的内存尽量处于同一 NUMA 节点, 以优化性能;
4. 特别适用于有 **RDMA 内存缓冲区** 或 **内存锁定(pinned) 区域** 的高性能场景. | v2 ☐☑✓ | [2025/05/02, LORE v2, 0/2](https://lore.kernel.org/all/20250502190059.4121320-1-chris.hyser@oracle.com)
*-*-*-*-*-*-*-*
[2025/06/22, LORE v3, 0/2](https://lore.kernel.org/all/20250622191622.3296825-1-chris.hyser@oracle.com) | | 2023/12/25 | openEuler | [Support dynamic affinity scheduler](https://gitee.com/openeuler/kernel/pulls/3573) | [潮汐 affinity 调度特性](https://docs.openeuler.openatom.cn/zh/docs/23.09/docs/Releasenotes/关键特性.htm): 感知业务负载动态调整业务 CPU 亲和性, 当业务负载低时使用 preferred cpus 处理, 增强资源的局部性; 当业务负载高时, 突破 preferred cpus 范围限制, 通过增加 CPU 核的供给提高业务的 QoS. | NA | +| 2026/05/14 | Shrikanth Hegde | [sched: Introduce cpu_preferred_mask and steal-driven vCPU backoff](https://lore.kernel.org/all/20260514152204.481115-1-sshegde@linux.ibm.com) | 旨在通过引入 `cpu_preferred_mask` 和基于 steal 时间的机制来优化调度行为. 核心思想是根据 CPU 的 steal 时间动态调整 preferred CPU 集合, 优先将任务调度在 preferred CPU 上, 以减少跨 CPU 调度带来的性能损耗. 主要更新包括引入 `CONFIG_PREFERRED_CPU` 配置选项、创建 debugfs 接口、优化 SMT 支持、处理架构相关逻辑等. | v3 ☐☑✓ | [2026/05/14, LORE v3, 00/20](https://lore.kernel.org/all/20260514152204.481115-1-sshegde@linux.ibm.com) | @@ -4336,7 +4353,8 @@ y = (1 - \frac{pct^{2}}{10000^{2}} \times x^{2}) \times llc\_weight | 2023/04/10 | K Prateek Nayak | [arch/x86: Set L2 Cache ID on AMD processors](https://lore.kernel.org/all/20230410163527.1626-1-kprateek.nayak@amd.com) | 将 Cluster Scheduler 扩展到 AMD 处理器上. 将 "l2c_id" 与拓扑扩展 "TOPOEXT" 特性连接起来, 用于在 AMD 处理器上设置, 以便共享相同 L2 缓存的线程集可以正确地映射到相同的集群 ID. 参见 phoronix 报道 [Linux Cluster-Aware Scheduling Being Extended To AMD Processors](https://www.phoronix.com/news/AMD-Linux-L2-Cluster-Scheduler) | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230410163527.1626-1-kprateek.nayak@amd.com) | | 2023/05/04 | Tim Chen | [Enable Cluster Scheduling for x86 Hybrid CPUs]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=ed74cc4995d314ea6cbf406caf978c442f451fa5) | 当集群调度首次引入 x86 时, 人们注意到, 在混合 CPU 上进行集群调度时, 单线程任务通常会在 Atom 核 (或 E 核) 上完成, 而不是在空闲的 Big 核 (或 P 核) 上, 从而导致性能降低. 因此, x86 混合 CPU 上的集群调度被禁用. 参见: [Linux 5.16's New Cluster Scheduling Is Causing Regression, Further Hurting Alder Lake](https://www.phoronix.com/review/linux-516-regress) 和 [Intel Updates Cluster Scheduling Linux Patches For Hybrid CPUs](https://www.phoronix.com/news/Intel-Cluster-Sched-Hybrid-V2). Ricardo 最近推出了 [sched: Avoid unnecessary migrations within SMT domains](https://lore.kernel.org/lkml/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com) 系列, 极大地改进了 x86 混合 CPU 上 P 核和 E 核之间的负载平衡逻辑. 然而, 该补丁系列不足以允许在混合 x86 CPU 上启用集群调度. 此补丁系列提供了一些额外的修复程序, 用于在由 Big Core 的 SMT CPU 组成的集群调度组和由 Atom CPU 组成的群集调度组之间进行负载平衡. 在 Ricardo 的补丁系列之上继续 APPLY 当前补丁, 可以在 P 核和 E 核集群之间适当平衡负载. 空闲 CPU 按正确顺序使用: 1). 空闲 P 核上的 SMT CPU, 2). 空闲 E 核, 3). 未使用的 SMT CPU 和繁忙的同级.
在 x86 上, Cluster 中的 CPU 共享 L2. 现在, 在启用 Cluster Scheduling 的情况下, Cluster 之间的负载得到了平衡, 从而可能减少 L2 争用. 参见 [Intel Posts New Linux Patches For Cluster Scheduling With Hybrid CPUs](https://www.phoronix.com/news/Intel-Hybrid-CPU-Cluster-Sched) 和 [Intel Updates x86 Hybrid CPU Cluster Scheduling For The Linux Kernel](https://www.phoronix.com/news/Intel-Hybrid-Cluster-Sched-v3). | v1 ☐☑✓ 6.6-rc1 | [LORE v1,0/4](https://lore.kernel.org/lkml/20220825225529.26465-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/lkml/20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v3,0/10](https://lore.kernel.org/lkml/20230207045838.11243-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v4,00/12](https://lore.kernel.org/lkml/20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/all/cover.1683156492.git.tim.c.chen@linux.intel.com)
*-*-*-*-*-*-*-*
[LORE v3,0/6](https://lore.kernel.org/lkml/cover.1688770494.git.tim.c.chen@linux.intel.com) | | 2024/02/01 | alexs@kernel.org | [sched/fair: add SD_CLUSTER in comments](https://lore.kernel.org/all/20240201115447.522627-1-alexs@kernel.org) | TODO | v3 ☐☑✓ | [LORE v3,0/4](https://lore.kernel.org/all/20240201115447.522627-1-alexs@kernel.org) | -| 2025/06/27 | Ricardo Neri | [sched: Fix cluster scheduling in the presence of asymmetric capacity](https://lore.kernel.org/all/20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com) | 修复在存在不对称 CPU 容量的情况下, 集群调度(cluster scheduling) 的负载均衡问题. 当前调度逻辑在 Intel 混合架构处理器上, 无法正确地在小核(small CPUs) 集群间均衡任务负载. 问题根源在于负载均衡器中的多个判断逻辑错误, 包括未正确判断容量、拒绝在相同容量 CPU 间迁移任务、错误地移除 SD_PREFER_SIBLING 标志等. 补丁逐一修复这些问题, 确保在启用 CONFIG_SCHED_CLUSTER 时任务能在小核集群间合理分布. 作者已在禁用超线程的 Alder Lake 系统上验证补丁, 并确认关闭集群调度时的兼容性. | v1 ☐☑✓ | [2025/06/27, LORE v1, 0/4](https://lore.kernel.org/all/20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com) | +| 2025/06/27 | Ricardo Neri | [sched: Fix cluster scheduling in the presence of asymmetric capacity](https://lore.kernel.org/all/20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com) | 修复在存在不对称 CPU 容量的情况下, 集群调度(cluster scheduling) 的负载均衡问题. 当前调度逻辑在 Intel 混合架构处理器上, 无法正确地在小核(small CPUs) 集群间均衡任务负载. 问题根源在于负载均衡器中的多个判断逻辑错误, 包括未正确判断容量、拒绝在相同容量 CPU 间迁移任务、错误地移除 SD_PREFER_SIBLING 标志等. 补丁逐一修复这些问题, 确保在启用 CONFIG_SCHED_CLUSTER 时任务能在小核集群间合理分布. 作者已在禁用超线程的 Alder Lake 系统上验证补丁, 并确认关闭集群调度时的兼容性. | v1 ☐☑✓ | [2025/06/27, LORE v1, 0/4](https://lore.kernel.org/all/20250627-rneri-fix-cas-clusters-v1-0-121ffb50bbc7@linux.intel.com)
*-*-*-*-*-*-*-*
[2026/05/14, LORE v3, 0/4](https://lore.kernel.org/all/20260514-rneri-fix-cas-clusters-v3-0-0037869554bd@linux.intel.com) | +| 2026/06/08 | Ricardo Neri | [sched: Fix cluster scheduling in the presence of asymmetric capacity](https://lore.kernel.org/all/20260608-rneri-fix-cas-clusters-v4-0-1526711c944c@linux.intel.com) | 旨在修复在非对称 CPU 容量架构下集群调度(cluster scheduling)的问题. 当前调度器在处理包含大小核(big.LITTLE)架构的 Intel 处理器时, 无法在小核集群之间均衡负载, 导致性能下降. 主要修复了负载均衡器在选择最繁忙调度组、处理 misfit 任务、迁移任务到相同容量 CPU 以及调度域标志设置等方面的问题.补丁已在 Alder Lake、Lunar Lake 和 Panther Lake 等平台测试验证, SMT 开启与关闭状态下均有效. | v4 ☐☑✓ | [2026/06/08, LORE v4, 0/6](https://lore.kernel.org/all/20260608-rneri-fix-cas-clusters-v4-0-1526711c944c@linux.intel.com) | ### 5.5.2 Multiple LLCs @@ -5893,6 +5911,7 @@ CONFIG_SCHED_CORE_CTL 的方案, 不光通过 do_isolation_work_cpu_stop() 支 | 2021/10/25 | Frederic Weisbecker | [arm64: Support dynamic preemption v2](https://lore.kernel.org/patchwork/cover/1366962) | 增加了 PREEMPT_DYNAMIC 配置选项, 允许内核启动阶段选择使用哪种抢占模式 (none, voluntary, full) 等, 同时支持 debugfs 中提供开关, 在系统运行过程中动态的修改这个配置. | RFC v4 ☑ 5.12-rc1 | [PatchWork](https://lkml.org/lkml/2021/10/25/500) | | 2023/11/07 | Ankur Arora | [Make the kernel preemptible](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com) | TODO | v1 ☐☑✓ | [LORE v1,0/86](https://lore.kernel.org/all/20231107215742.363031-1-ankur.a.arora@oracle.com) | | 2023/11/07 | Shrikanth Hegde | [powerpc: enable dynamic preemption](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=6ad7751537e884c45b5340a4a24c25535f0d9c13) | [phoronix, 2025/05/26, POWER CPUs Ready With Dynamic Preemption For Linux 6.16](https://www.phoronix.com/news/POWER-Dynamic-Preempt-Linux-616) | v1 ☐☑✓ | [LORE v1,0/86](https://patch.msgid.link/20250210184334.567383-2-sshegde@linux.ibm.com) | +| 2026/01/12 | eter Zijlstra | [sched: Further restrict the preemption modes](https://lore.kernel.org/all/176820500332.510.37525067093416732.tip-bot2@tip-bot2) | 进一步限制了 Linux 内核的抢占模式. 该更改旨在解决 PREEMPT_RT 下的过度调度问题, 并减少对 cond_resched() 的依赖. 主要变化包括: 仅在不支持抢占的架构上启用 PREEMPT_NONE, PREEMPT_VOLUNTARY 仅限尚未支持 PREEMPT_LAZY 的架构, 并最终目标是完全移除自愿抢占. 目前, arm64、loongarch、powerpc、riscv、s390 和 x86 等主流架构仅支持 full 和 lazy 两种抢占模式. 此更改有助于简化内核调度逻辑, 减少不必要的调度开销和潜在的性能问题. | v1 ☐☑✓ | [20260/01/12, LORE](https://lore.kernel.org/all/176820500332.510.37525067093416732.tip-bot2@tip-bot2) | | 日期 | LWN | 翻译 | @@ -6459,7 +6478,7 @@ EEVDF 跟 CFS 一样, EEVDF 追求在任务之间公平使用 CPU 时间. 试图 事实上, 当且仅当计算出的 lag 值大于或等于零时, 才认为这个进程是 "合格的 (eligible)"; 任何具有负值的 lag 值的进程都都没有资格运行. 对于任何不合格的过程, 在未来的某个时间, 它有权得到的时间逐渐增长, 赶上它实际得到的时间, 于是可以再次成为合格的进程; 这个时间就被称为 "合格时间 (eligible time)". - +[2026/03/10, sched_ext: Partial mode priority and fallthrough to EEVDF](https://lore.kernel.org/all/20260310145213.1060649-1-matt@readmodwrite.com) | 关键因子 | 诉求原理 | 描述 | |:-------:|:------:|:----:| @@ -6475,7 +6494,7 @@ EEVDF 的核心理念就可以从它的名字中看出, 它将首先运行那些 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:-----:|:----:|:----:|:----:|:------------:|:----:| | 2009/09/16 | Ingo Molnar | [sched: Implement a gentler fair-sleepers feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) | 引入 GENTLE_FAIR_SLEEPERS sched_feature 只给睡眠的线程 50% 的 vruntime 补偿优待, 这使它们能够更快地奔跑, 但不会让他们窃取过多的补偿. | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) | -| 2023/04/01 | Xi Wang | [Morphing CFS into FDL, The Fair Deadline Scheduling Class](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | +| 2023/04/01 | Xi Wang | [Morphing CFS into FDL, The Fair Deadline Scheduling Class](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | **FDL(Fair Deadline Scheduling Class)**, 旨在将现有的 CFS 扩展为支持公平截止时间调度, 以满足共享服务器中对延迟和带宽保障的需求.
核心目标包括:
- 提供**调度延迟和CPU带宽保证**
- 支持**实时任务**, 具备**可配置截止时间**(微秒级).
- 实现**cgroup层级调度策略**(高层cgroup使用实时调度, 低层使用尽力而为)
- 保持**向后兼容性**, 对现有任务影响最小
FDL基于**排水桶模型**, 通过 deadline 树进行任务调度, 优先于原有 vruntime 树. 调度机制支持**多核调度**和**动态反馈调节**, 以平衡负载和带宽分配.
邮件中通过 **schbench 和 hackbench** 的测试对比显示, FDL 在有干扰任务时显著降低了99百分位延迟, 表现出比CFS更好的实时性能.
该补丁修改 CFS 实现 FDL, 而非新建调度类, 以减少对现有系统的冲击, 并与CFS的组调度机制兼容. 作者也提到该设计可为未来更彻底的调度器重构打下基础. | v1 ☐☑✓ | [2023/04/01, LORE v1, 0/1](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | | 2023/03/28 | Peter Zijlstra | [sched: EEVDF using latency-nice](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | [EEVDF Scheduler Patches Updated For The Linux Kernel](https://www.phoronix.com/news/Linux-EEVDF-EO-March) | v1 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20230306132521.968182689@infradead.org)
*-*-*-*-*-*-*-*
[LORE v1,0/17](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | | 2023/07/19 | Peter Zijlstra | [sched: EEVDF and latency-nice and/or slice-attr](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b41bbb33cf75d251a816768580819aec17be718d) | [Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS](https://www.phoronix.com/news/EEVDF-Scheduler-Linux-EO-May) 以及 [EEVDF Scheduler May Be Ready For Landing With Linux 6.6](https://www.phoronix.com/news/Linux-6.6-EEVDF-Likely), [EEVDF Scheduler Merged For Linux 6.6, Intel Hybrid Cluster Scheduling Re-Introduced](https://www.phoronix.com/news/Linux-6.6-EEVDF-Merged) | v1 ☐☑✓ 6.6-rc1 | [LORE v1,0/15](https://lore.kernel.org/all/20230531115839.089944915@infradead.org), [CGIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d07f09a1f99cabbc86bc5c97d962eb8a466106b5) | | 2024/01/11 | Ze Gao | [sched/eevdf: Use tunable knob sysctl_sched_base_slice as explicit time quanta](https://lore.kernel.org/all/20240111115745.62813-2-zegao@tencent.com) | 这组补丁使用可调的内核参数 `sysctl_sched_base_slice` 作为显式的时间量子 (time quanta), 可以更自由地选择请求长度范围, 同时避免过度或不足调度的问题, 以改善调度程序的性能和公平性.
EEVDF 的实现忽略了论文中时间量子(time quanta) 概念在 EEVDF 中的作用, 为了避免不公平的调度, 时间量子 (q) 和最大用户请求 (r_max) 都不应过大. 为了提高吞吐量, 目前的实现 [Re: schbench v1.0](https://lore.kernel.org/all/20230420150537.GC4253@hirez.programming.kicks-ass.net/T/#u) 选择在每个请求边界 (即一旦一个请求被满足) 进行 tick preemtion 的抢占式调度, 这意味着实际上没有定义时间量子. 当允许自定义切片时, 由于没有明确的时间量子, 可能会导致失去很多调度机会来维护公平性和响应性, 并可能导致意外的不公平性和延迟. 例如, 两个具有相同权重的 CPU 密集型进程绑定到同一个 CPU 上时, 如果没有时间量子, 调度的滞后界限将仅取决于用户请求的切片分布. 即使用自定义时间片可能会损害公平性. 但是, 如果让时间量子等于每个请求的长度 sysctl_sched_base_slice, 那么实际上会创建一个隐含的时间量子, 可以更好地控制分配的准确性和平均延迟, 这在当前情况下工作得很好. 此外, 通过调整这个参数, 可以在吞吐量和延迟之间找到更好的平衡. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240111115745.62813-2-zegao@tencent.com) | @@ -6618,6 +6637,7 @@ $deadline_{se} = vruntime_{se} + slice \times \frac{weight_0}{weight_{se}}$ | 2025/04/18 | Vincent Guittot | [sched/fair: Increase max lag clamping](https://lore.kernel.org/all/20250418151225.3006867-1-vincent.guittot@linaro.org) | 这个补丁旨在修正 `sched_entity` 的滞后(lag) 限制问题. 当前 lag 上限为 `TICK_NSEC` 或任务时间片的两倍, 但该限制在任务设置了较大自定义时间片(如 100ms) 时显得不足, 导致其他任务可能在等待时积累正 lag, 从而在出队时被不当地截断.
补丁将 lag 的上限改为统一使用系统允许的最大时间片(`SCHED_SLICE_MAX`) , 并定义了最小时间片(`SCHED_SLICE_MIN`) 用于约束设置. 此举确保了调度公平性, 避免因 lag 截断造成信息丢失.
代码修改包括更新 `update_entity_lag() ` 中的 lag 限制逻辑, 并在 `__setparam_fair() ` 中使用统一的宏定义. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250418151225.3006867-1-vincent.guittot@linaro.org) | | 2025/06/13 | Vincent Guittot | [sched/fair: Manage lag and run to parity with different slices](https://lore.kernel.org/all/20250613140514.2781138-1-vincent.guittot@linaro.org) | 旨在改进 Linux 调度器(sched/fair) 中任务 lag 的管理和公平性机制. 核心内容包括:
补丁 2: 基于 Peter Zijlstra 的建议, 通过追踪入队任务的最大 slice 来限制出队任务的 lag.
补丁 3: 修改当前任务 slice 的保护机制, 考虑短 slice 任务等待运行的情况.
补丁 4: 扩展 slice 保护机制至 NO_RUN_TO_PARITY 场景, 确保定期设置 resched, 且运行任务至少运行 0. 7ms, 除非触发 PREEMPT_SHORT. | v1 ☐☑✓ | [2025/06/13, LORE v1, 0/4](https://lore.kernel.org/all/20250613140514.2781138-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/07/04, LORE v2, 0/6](https://lore.kernel.org/all/20250704143612.998419-1-vincent.guittot@linaro.org)
*-*-*-*-*-*-*-*
[2025/07/08, LORE v3, 0/6](https://lore.kernel.org/all/20250708165630.1948751-1-vincent.guittot@linaro.org) | | 2025/06/19 | Huang Shijie | [sched/fair: set the se->vlag strictly following the paper](https://lore.kernel.org/all/20250619031942.25474-1-shijie@os.amperecomputing.com) | 修正 `se-> vlag` 的计算逻辑, 使其严格符合论文中的规定: `-r_max 为此, 补丁引入了 `limit_hi`、`limit_lo` 和 `r_max` 变量, 分别表示上限、下限与最大延迟基准值, 从而实现更精确的 `vlag` 限制. 修改后, `vlag` 被正确限制在 `[-limit_lo, limit_hi] ` 范围内.
该修改提升了调度器公平性计算的准确性, 并通过了相关测试. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250619031942.25474-1-shijie@os.amperecomputing.com) | +| 2026/03/31 | Vincent Guittot | [sched: fair: Prevent negative lag increase during delayed dequeue](https://lore.kernel.org/all/20260331162352.551501-1-vincent.guittot@linaro.org) | 旨在解决延迟出队(delayed dequeue) 机制中出现的负延迟(negative lag) 增加问题. 当前机制在任务睡眠期间尝试减少负延迟, 但新入队任务可能导致平均虚拟运行时间后移, 使延迟出队任务唤醒时负延迟反而增加, 影响公平性.
补丁修改了 `update_entity_lag()` 函数, 在更新 lag 时确保延迟出队任务的负延迟不会增加, 同时清除其在此期间可能获得的正延迟. 该问题在系统过载时对短时间任务影响较大.
通过在 Snapdragon RB5 平台进行测试, 使用 `hackbench` 和 `cyclictest` 工具验证, 结果显示调度延迟显著改善, 尤其在高百分位的延迟上有明显下降.
补丁还简化了 `finish_delayed_dequeue_entity()` 的逻辑, 将延迟调整整合到 `update_entity_lag()` 中处理.
版本更新: 相比 v1, 将延迟实体 lag 变化检查统一整合进 `update_entity_lag()`, 覆盖所有使用场景. | v2 ☐☑✓ | [2026/03/31, LORE](https://lore.kernel.org/all/20260331162352.551501-1-vincent.guittot@linaro.org) | #### 8.9.3.2 NEXT_BUDDY 优化 @@ -7233,7 +7253,7 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024, | 2025/06/30 | Marcos Garcia | [sched/ext: Implement cgroup idle state notification](https://lore.kernel.org/all/20250630184709.3831581-1-magazo2005@gmail.com) | 实现 cgroup 空闲状态通知机制. 该补丁新增 `scx_group_set_idle() ` 函数, 通过 RCU 机制安全调用 BPF 调度器的 `cgroup_set_idle` 回调函数, 通知任务组(cgroup) 进入空闲或活动状态. 这使调度器能够优化资源分配、实现节能策略并改善负载均衡决策. 该功能为可选机制, 不依赖此通知的调度器可不实现相关回调. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250630184709.3831581-1-magazo2005@gmail.com) | -#### 11.2.1.2 WAKE/LLC/NUMA 感知与支持 +#### 11.2.1.2 拓扑感知(WAKE/LLC/NUMA 感知与支持) ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | @@ -7243,6 +7263,7 @@ LSFMMBPF 2024 上对 sched_ext 进行了讨论 [LWN, 2024/05/23, LSFMMBPF-2024, | 2024/10/27 | Andrea Righi | [sched_ext: Introduce NUMA awareness to the default idle selection policy](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=860a45219bce09d9ebac883cfcf9b5b0b8a8a999) | 为 sched_ext 模块引入了 NUMA 意识, 使其在选择空闲 CPU 时优先考虑同一 NUMA 节点内的 CPU. 类似于之前对 LLC(Last Level Cache)意识的支持. 其目的是在选择空闲 CPU 时优先考虑同一 NUMA 节点内的 CPU, 以优化性能和减少跨节点的通信延迟. 扩展内置的空闲 CPU 选择策略, 使其也优先考虑同一 NUMA 节点内的 CPU, 始终优先考虑来自完全空闲的 SMT 内核的 CPU. 如果可能，请选择相同的 CPU, 选择同一 LLC 域内的 CPU, 选择同一 NUMA 节点中的 CPU. 目前的逻辑仅试图让任务在同一 NUMA 节点内运行. 如果节点内的所有 CPU 都忙 m 则随机选择下一个 NUMA 节点. 未来可以考虑改进 NUMA 节点的选择逻辑, 以考虑从当前 CPU 到目标 NUMA 节点的距离. 参见 phoronix 报道 [phoronix, 2024/10/28, Sched_ext Scheduler Idle Selection Being Extended For LLC & NUMA Awareness](https://www.phoronix.com/news/sched_ext-NUMA-Awareness) 和 [phoronix, 2024/11/22, Sched_Ext Changes Merged For Linux 6.13 With LLC & NUMA Awareness](https://www.phoronix.com/news/Linux-6.13-Sched_Ext).. | v3 ☐☑✓ v6.13-rc1 | [2024/10/27, LORE v4](https://lore.kernel.org/all/20241027174953.49655-1-arighi@nvidia.com)
*-*-*-*-*-*-*-*
[2024/10/25, LORE v5](https://lore.kernel.org/all/20241029101618.318812-1-arighi@nvidia.com) | | 2024/11/08 | Andrea Righi | [sched_ext: Do not enable LLC/NUMA optimizations when domains overlap](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f6ce6b949304bc7a54dbfea98402080c42bbc9a4) | 该补丁的主要目的是在 LLC(Last Level Cache)和 NUMA 域完全重叠时, 避免启用冗余的优化, 以提高调度器扩展策略的效率. 当 LLC 和 NUMA 域完全重叠时, 同时启用这两个域的优化是多余的, 因为这会导致两次在相同的域内搜索空闲 CPU. 此外, 如果所有在线 CPU 都在一个单一的 LLC 域内, 那么 LLC 优化也是不必要的. 因此, 此补丁通过检测重叠的域, 并仅在必要时启用拓扑优化来解决这个问题. | v3 ☐☑✓ v6.13-rc1 | [LORE](https://lore.kernel.org/all/20241108000136.184909-1-arighi@nvidia.com) | | 2025/02/26 | Andrea Righi | [selftests/sched_ext: Add NUMA-aware scheduler test](https://lore.kernel.org/all/20250226065057.151976-1-arighi@nvidia.com) | TODO | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250226065057.151976-1-arighi@nvidia.com) | +| 2026/04/29 | Tejun Heo | [sched_ext: Topological CPU IDs and cid-form struct_ops](https://lore.kernel.org/all/20260429182131.1780125-1-tj@kernel.org) | 为 sched_ext引入**拓扑 CPU ID( cid)** 和支持 cid 的 struct_ops 类型, 以提升 BPF 调度器在拓扑结构上的操作效率. 关键更新包括:
1. **cid 空间**: 通过 `scx_cid_init()` 构建密集、拓扑有序的 CPU 标识, 支持 BPF 调度器使用 `scx_bpf_cid_override()` 自定义映射.
2. **cmask**: 基于 cid 的位图结构, 用于任务亲和性与空闲 CPU 管理, 支持内核与 BPF 的一致操作.
3. **`cid-form struct_ops`**: 新增结构体类型, 其回调函数直接使用 `cid/cmasks`, 与原有 `cpu-form` 共享部分结构布局, 便于联合使用.
4. **cid 相关 kfuncs**: 新增多个 BPF 辅助函数(如 `scx_bpf_cid_to_cpu`、`scx_bpf_kick_cid` 等), 限制 cid-form 程序调用 cpu-only 函数.
5. **scx_qmap 移植**: 将 scx_qmap 调度器移植至 cid-form, 使用 cmask 进行空闲 CPU 选择与任务亲和性控制.
补丁已在 16 核 QEMU 虚拟机上测试, 包括负载测试、cid 覆盖模式与多次启用/禁用循环, 未发现异常. 补丁基于 sched_ext/for-7. 2 分支, 共修改 13 个文件, 新增 2387 行代码. | v4 ☐☑✓ | [2026/04/29, LORE](https://lore.kernel.org/all/20260429182131.1780125-1-tj@kernel.org) | #### 11.2.1.3 sched_ext per-node 数据拆分 @@ -7477,6 +7498,7 @@ YouTuBe 上 ASPLOS'23 关于 Plugsched 的介绍 [ASPLOS'23 - Session 7C - Effic | 2021/09/05 | Yafang Shao | [sched: support schedstats for RT sched class](https://lore.kernel.org/patchwork/cover/1403138) | 我们希望使用 schedstats 工具测量生产环境中 RT 任务的延迟, 但目前只支持公平调度类的 schedstats. 将 sched_statistics 修改为独立于 task_struct 或 task_group 的调度统计数据, 从而完成了 RT 的 schedstats 支持 | v6 ☑ 5.16-rc1 | [PatchWork v2](https://lore.kernel.org/patchwork/cover/1403138)
*-*-*-*-*-*-*-*
[PatchWork v3](http://patches.linaro.org/cover/502064)
*-*-*-*-*-*-*-*
[LORE v4,0/8](https://lore.kernel.org/all/20210905143547.4668-1-laoar.shao@gmail.com) | | 2024/05/08 | Ravi Bangoria | [perf sched: Introduce schedstat tool](https://lore.kernel.org/all/20240508060427.417-1-ravi.bangoria@amd.com) | 现有的 "perf-shed" 非常详尽, 并提供了对调度程序行为的许多见解, 但它很快就无法用于长时间运行或调度程序密集型工作负载. 例如, "perf-shed record" 在 hackbeek 上有约 7.77% 的开销(25 个组, 每个组在 2 个套接字的 128 核 256 线程的第三代 EPYC 服务器上运行 700K 循环), [它生成了巨大的 56G 性能数据, 性能准备和写入磁盘需要约 137 分钟](https://youtu.be/lg-9aG2ajA0?t=283). 与 "perf sched record" 不同的是, "perf sched schedstat record" 挂接到一组调度程序跟踪点并在跟踪点命中时生成样本, 它在工作负载前后拍摄 / proc/schedstat 文件的快照, 即对工作负载运行没有干扰. 此外, 解析 / proc/schedstat、将其转换为 perf 示例和将这些示例保存到 perf.data 文件中. 结果 perf.data 文件要小得多. 因此, 总体而言, 与 "perf sched record" 相比, "perf sched schedstat record" 要轻得多. 我们在 AMD 内部一直在使用它的一种变体, 称为 [调度记分板 Scheduler Scoreboard](https://github.com/AMDESE/sched-scoreboard), 并发现它对分析任何调度程序代码更改的影响非常有用 [Re: [PATCH] sched/fair: no sync wakeup from interrupt context](https://lore.kernel.org/lkml/c50bdbfe-02ce-c1bc-c761-c95f8e216ca0@amd.com), [Re: [PATCH v3 6/7] sched: Implement shared runqueue in CFS]. 参见 phoronix 报道 [AMD Linux Engineers Introduce New"schedstat"Tool](https://www.phoronix.com/news/AMD-Linux-perf-schedstat-Tool). | v1 ☐☑✓ | [2024/05/08, LORE v1,0/4](https://lore.kernel.org/all/20240508060427.417-1-ravi.bangoria@amd.com)
*-*-*-*-*-*-*-*
[2024/09/16, LORE 0/5](https://lore.kernel.org/all/20240916164722.1838-1-ravi.bangoria@amd.com)
*-*-*-*-*-*-*-*
[2024/11/22, LORE v2,0/6](https://lore.kernel.org/all/20241122084452.1064968-1-swapnil.sapkal@amd.com) | | 2024/12/20 | Swapnil Sapkal | [Fixes and improvements in /proc/schedstat](https://lore.kernel.org/all/20241220063224.17767-1-swapnil.sapkal@amd.com) | TODO | v2 ☐☑✓ | [LORE v2,0/6](https://lore.kernel.org/all/20241220063224.17767-1-swapnil.sapkal@amd.com) | +| 2026/05/08 | Frederic Weisbecker | [tick/sched: Refactor idle cputime accounting](https://lore.kernel.org/all/20260508131647.43868-1-frederic@kernel.org) | 该邮件由 Frederic Weisbecker 提交, 旨在解决 Linux 内核中 idle cputime 会计混乱的问题. 当前在线和离线 CPU 使用两种不同的会计机制, 各自存在缺陷, 如忽略中断时间、无法正确扣除空闲窃取时间、精度不一致等, 导致全局空闲时间可能出现倒退现象.
本次提交引入混合会计方法, 统一在线与离线 CPU 的空闲时间统计, 确保时间连续性与准确性. 主要改进包括:
- 在 tick 停止前后使用 tick 或 vtime 会计;
- 空闲循环中切换至 dynticks-idle 会计, 直接更新内核统计字段;
- 移除私有字段, 将相关代码移至通用调度器/时间统计模块;
- 正确处理 CONFIG_IRQ_TIME_ACCOUNTING=n 的情况;
- 修复空闲窃取时间扣除逻辑;
- 解决多个平台( 如 powerpc、s390) 相关问题.
共 15 个补丁, 涉及多个架构与核心调度/时间统计代码的修改. | v4 ☐☑✓ | [2026/05/08, LORE v4, 0/15](https://lore.kernel.org/all/20260508131647.43868-1-frederic@kernel.org) | ## 12.2 tracepoint @@ -7514,6 +7536,7 @@ ARM & Linaro 的内核团队针对 Android/linux 等做了大量的调度的优 | 2025/04/09 | Luis Machado | [sched/events: Improving scheduler debugging/testing tracing interfaces](https://lore.kernel.org/all/20250409151338.1046335-1-luis.machado@arm.com) | 提出了一项改进调度器调试 / 测试追踪接口的补丁提案, 旨在提升调度器 (尤其是能效调度) 可观测性, 同时避免引入长期维护的用户空间 ABI. 当前依赖已有 tracepoint 存在局限, 如无法访问内部结构体字段、需手动复制结构定义、无法自动处理内核逻辑(如 util_est 的位掩码处理) 等.
核心是为调度器 tracepoint 新增一个类型为 `struct sched_tp_callbacks` 的参数, 用于提供内核内部数据访问的 "getter()" 回调函数. 这些函数封装内核逻辑, 允许模块安全获取数据, 减少结构复制和维护成本. 补丁中提供了几个示例回调, 如获取 `cfs_rq` 或 `sched_entity` 的 util_est、获取 CPU 当前容量等.
作者请求社区反馈此方案是否可行, 以及如何改进其可维护性和扩展性. 目前已被 LISA 模块验证可行, 有助于提升自动化测试与性能分析效率. | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250409151338.1046335-1-luis.machado@arm.com) | | 2025/06/03 | Lukasz Luba | [sched/tp: Add new tracepoint for tracking uclamp set from user-space](https://lore.kernel.org/all/20250603120755.1028396-1-lukasz.luba@arm.com) | 新增一个 tracepoint 用于追踪用户空间设置任务 uclamp 值的变化. uclamp(Utilization Clamping) 机制允许用户空间动态调整任务的 CPU 利用率上下限, 从而影响调度器的任务分配决策. 新增的 tracepoint `uclamp_update_task` 可在任务 uclamp 值被修改时触发, 便于开发者分析系统行为, 优化内核与中间件的协同性能. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20250603120755.1028396-1-lukasz.luba@arm.com) | | 2025/07/03 | Thomas Weißschuh | [um/ptrace: Implement HAVE_SYSCALL_TRACEPOINTS](https://lore.kernel.org/all/20250703-uml-have_syscall_tracepoints-v1-0-23c1d3808578@linutronix.de) | 在用户模式 Linux(UML) 中实现 `HAVE_SYSCALL_TRACEPOINTS` 功能, 通过通用追踪框架支持系统调用追踪点. 此举旨在 UML 内运行实时性验证监控工具, 以测试应用的 PREEMPT_RT合规性. 补丁内容包括在 x86 架构的 UML 中添加系统调用表和相关头文件, 并在 ptrace 模块中实现追踪点支持. 补丁已获得相关开发者与社区关注, 目标为增强 UML 的调试与实时性检测能力. | v1 ☐☑✓ | [2025/07/03, LORE v1, 0/2](https://lore.kernel.org/all/20250703-uml-have_syscall_tracepoints-v1-0-23c1d3808578@linutronix.de) | +| 2026/05/17 | André Almeida | [sched: Add support for long task name](https://lore.kernel.org/all/20260517-tonyk-long_name-v1-0-3c282eaa91e2@igalia.com) | 旨在扩展 Linux 中进程名称长度支持至 64 字节, 以改善对复杂多线程程序的调试和追踪能力. 当前 `current-> comm` 限制为 16 字节, 已无法满足部分场景需求. 补丁引入新的 `PR_SET_EXT_NAME` 和 `GET` 接口, 允许设置更长的线程名, 同时保持原有接口返回 16 字节以维持兼容性. 补丁还引入 `strtostr() ` 函数以确保字符串复制安全, 并更新了相关 selftest 测试用例. 邮件中请求社区反馈, 特别是如何进一步压力测试字符串复制相关代码. | v1 ☐☑✓ | [2026/05/17, LORE v1, 0/6](https://lore.kernel.org/all/20260517-tonyk-long_name-v1-0-3c282eaa91e2@igalia.com) | ## 12.3 debug 接口 @@ -7657,13 +7680,14 @@ ECRTS 2020(32nd Euromicro Conference on Real-Time Systems) 上 Daniel 等人发 | 2025/10/18 | Muhammad Usama Anjum | [PM: Hibernate: Add hibernation cancellation support](https://lore.kernel.org/all/20251018142114.897445-1-usama.anjum@collabora.com) | 旨在支持在休眠过程中取消操作. 当前, 系统休眠需 15-20 秒, 期间无法中断, 影响用户体验. 作者 Muhammad Usama Anjum 提出通过检测电源键中断, 在休眠过程中允许用户中止该流程. 补丁共 4 个, 包括导出休眠状态函数、处理 ACPI 按钮事件、忽略休眠期间的电源键事件, 以及清除挂起标志. 测试表明, 修改后可在休眠中安全取消操作. [phoronix, 2025/10/20, Patches Posted To Allow Hibernation Cancellation On Linux](https://www.phoronix.com/news/Linux-Hibernation-Cancellation) | v1 ☐☑✓ | [2025/10/18, LORE v1, 0/4](https://lore.kernel.org/all/20251018142114.897445-1-usama.anjum@collabora.com) | -### 12.5.3 PM QOS +### 12.5.3 QOS ------- | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:---:|:----:|:---:|:----:|:---------:|:----:| +| 2024/08/20 | Qais Yousef | [sched/fair/schedutil: Better manage system response time](https://lore.kernel.org/all/20240820163512.1096301-1-qyousef@layalina.io) | 这组补丁集是不久前发布的 [Remove Hardcoded Margings](https://lore.kernel.org/lkml/20231208002342.367117-1-qyousef@layalina.io) 的翻版. 主要目标是解决硬编码的 fits_capacity() 迁移阈值(migration margin) 和 DVFS headroom(参见 apply_dvfs_headroom()) 而导致的响应时间相关问题. 具体来说, 硬编码的迁移边距和固定的 25% DVFS headroom 在高性能系统上对功耗和热管理不利. 这组补丁通过自动调整这些值到最小可能值, 基于预期的最坏情况场景, 来优化功耗和响应时间. 具体改动
1. 移除硬编码的迁移边距: 修改 fits_capacity() 函数中的硬编码迁移边距, 使其能够根据实际情况动态调整.
2. 移除固定的 DVFS headroom: 移除 sugov_apply_dvfs_headroom() 函数中的固定 1.25 倍的 headroom, 改为动态计算.
3. 引入新的响应时间管理机制: 添加新的可调参数来控制响应时间, 使系统可以根据实际需求动态调整.
4. 改进 PELT(Per Entity Load Tracking) 机制: 引入新的 PELT 乘数启动参数, 以改进任务的负载预测和响应时间.
5. 扩展 util_est 机制, 以更好地处理任务的启动时间和周期性任务.
6. 引入新的 QoS 接口: 添加新的 sched-qos 接口, 以支持更细粒度的调度质量控制.
7. 引入 rampup_multiplier QoS 参数, 以控制任务的启动速度.
8. 改进 waiting_avg 记录: 添加新的 waiting_avg 记录, 以记录任务在可运行但未运行时的状态.
9. 优化 apply_dvfs_headroom 函数: 在 apply_dvfs_headroom 函数中考虑 waiting_avg, 以更准确地调整 DVFS headroom.
10. 忽略衰减的利用率: 当利用率正在衰减时, 忽略 DVFS headroom, 以避免不必要的频率调整.
11. 禁用 util_est: 通过 rampup_multiplier 参数控制是否禁用 util_est, 以适应不同的应用场景. 参见 [phoronix, 2024/08/21, Experimental Schedutil Patches Yield 30% Boost To Web Browser Benchmark On Linux](https://www.phoronix.com/news/Schedutil-30p-Speedometer-Boost). | v1 ☐☑✓ | [LORE v1,0/16](https://lore.kernel.org/all/20240820163512.1096301-1-qyousef@layalina.io) | | 2025/11/25 | Ulf Hansson | [PM: QoS: Introduce a CPU system wakeup QoS limit for s2idle](https://lore.kernel.org/all/20251125112650.329269-1-ulf.hansson@linaro.org) | 邮件提出了一项针对 Linux 内核的补丁系列, 旨在为 s2idle 状态引入 CPU 系统唤醒延迟的 QoS(服务质量) 限制机制. 当前系统在进入低功耗状态时总是选择最深的节能状态, 可能不满足某些对唤醒延迟有严格要求的场景. 为此, Ulf Hansson 提供了一个用户空间接口, 允许设置 CPU 唤醒延迟上限, 从而在选择低功耗状态时兼顾能效与延迟约束. 补丁系列共 6 个, 涉及 PM domain、cpuidle、调度器等核心模块, 并附带文档说明. 此机制适用于需要控制系统唤醒延迟的平台, 如嵌入式或实时系统. | v4 ☐☑✓ | [2025/11/25, LORE v4, 0/6](https://lore.kernel.org/all/20251125112650.329269-1-ulf.hansson@linaro.org) | - +| 2026/04/17 | Barry Song | [Announcing Sched QoS v0.1-alpha](https://lore.kernel.org/all/20260415000910.2h5misvwc45bdumu@airbuntu) | Qais Yousef 发布了 Sched QoS v0. 1-alpha 版本, 这是一个用于用户空间辅助调度的工具, 目前仍处于概念验证阶段, 尚未可用于生产环境. 该项目旨在通过配置文件而非系统调用接口来描述任务优先级, 从而实现更灵活的资源管理. Sched QoS 采用零 API 方法, 通过 NETLINK 监听任务创建事件, 并基于用户空间描述自动标记任务.
Sched QoS 将任务角色分为四类: USER_INTERACTIVE( 需立即响应) 、USER_INITIATED( 容忍短延迟) 、UTILITY( 容忍较长延迟) 和 BACKGROUND( 容忍长时间延迟) , 默认为 UTILITY. 通过配置文件, 用户可指定任务的调度策略、nice 值、运行时间和 util_max. 例如, Chrome 可标记为 USER_INTERACTIVE, 而 gcc 编译任务标记为 BACKGROUND.
Barry Song 在测试中发现该工具在 arm64 平台崩溃, Qais Yousef 已修复. Christian Loehle 对 sched_util_max 的平台依赖性和 uclamp_max 的节能效果提出质疑, Qais 回应称配置文件可灵活调整, 适用于多种系统, 并可通过重启 daemon 生效.
Sched QoS 当前依赖线程名称( 通过 prctl 或 pthread_setname_np 设置) 进行细粒度控制, 鼓励开发者为线程命名. 未来计划支持组控制, 结合 cgroup 实现更精细的 QoS 管理, 并考虑 NUMA 等内存敏感任务的执行配置.
测试结果显示, 在 cyclictest + hackbench 和 schbench + 内核编译场景中, Sched QoS 显著提升了性能( 如平均延迟降低、RPS 提升) , 但部分高百分位延迟恶化, 需依赖 Vincent Guittot 正在修复的补丁. 此外, 多模态唤醒路径和调度器负载均衡改进也在进行中.
[项目地址](https://github.com/qais-yousef/schedqos)
| v0 ☐☑✓ | [2026/04/17, LORE](https://lore.kernel.org/all/20260415000910.2h5misvwc45bdumu@airbuntu) | # 13 其他 diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 5826028..7015dab 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -862,7 +862,7 @@ https://www.phoronix.com/news/cpufreq_ext-RFC#google_vignette https://www.github-zh.com/ [A new type of spinlock for the BPF subsystem](https://mp.weixin.qq.com/s/6pEk4PBnf6WXNdj4zmIeBA) -[LWN：GCC BPF 支持的进展！](https://mp.weixin.qq.com/s/hlXtGhkIhIhpgPQTnolVXg) +[LWN: GCC BPF 支持的进展！](https://mp.weixin.qq.com/s/hlXtGhkIhIhpgPQTnolVXg) @@ -930,30 +930,55 @@ https://ncnz67vv5cuy.feishu.cn/wiki/IN66w8dW8imkkUkKusMcy2jLnBb https://support.huaweicloud.com/bestpractice-ecs/zh-cn_topic_0141067581.html + +1. 开启 DOCKER + sudo docker run -it --name ubuntu22.04 ubuntu:22.04 bash sudo docker ps -a sudo docker start 665e1247f4c8 sudo docker exec -it ubuntu22.04 bash + +2. 处理 Qwen2.5-Coder-7B-Instruct-AWQ + sudo docker cp /home/chengjian/Work/Package/Miniconda/py310 ubuntu22.04:/root/Model sudo docker cp Qwen2.5-Coder-7B-Instruct-AWQ ubuntu22.04:/root/Model/QWEN/QWEN2.5 -sudo docker cp ubuntu22.04:/root/Model/QWEN/QWEN2.5/Qwen2.5-Coder-7B-Instruct-AWQ-PARAMS ./Qwen2.5-Coder-7B-Instruct-AWQ-PARAMS -sudo docker exec -it ubuntu22.04 bash - - mkdir -p /root/Model/QWEN/QWEN2.5/Qwen2.5-Coder-7B-Instruct-AWQ-HEADER python3 convert_awq.py /root/Model/QWEN/QWEN2.5/Qwen2.5-Coder-7B-Instruct-AWQ /root/Model/QWEN/QWEN2.5/Qwen2.5-Coder-7B-Instruct-AWQ-HEADER --group_size 128 --gen_model_header +sudo docker cp ubuntu22.04:/root/Model/QWEN/QWEN2.5/Qwen2.5-Coder-7B-Instruct-AWQ-PARAMS ./Qwen2.5-Coder-7B-Instruct-AWQ-PARAMS + mkdir -p /root/Model/QWEN/QWEN2.5/Qwen2.5-Coder-7B-Instruct-AWQ-HEADER-VERSION +3. 处理 Qwen2.5-Coder-7B-Instruct-AWQ + sudo docker cp Qwen2.5-0.5B-Instruct ubuntu22.04:/root/Model/QWEN/QWEN2.5/0.5B/Qwen2.5-0.5B-Instruct python3 convert_llama.py ~/Model/QWEN/QWEN2.5/0.5B/Qwen2.5-0.5B-Instruct/Qwen2.5-0.5B-Instruct ~/Model/QWEN/QWEN2.5/0.5B/Qwen2.5-0.5B-Instruct/Qwen2.5-0.5B-Instruct-Q4N0-HEADER --qwen2 --gen_model_header --qtype Q4_0 python3 convert_llama.py ~/Model/QWEN/QWEN2.5/0.5B/Qwen2.5-0.5B-Instruct/Qwen2.5-0.5B-Instruct ~/Model/QWEN/QWEN2.5/0.5B/Qwen2.5-0.5B-Instruct/Qwen2.5-0.5B-Instruct-Q40-HEADER-VERSION --qwen2 --qtype Q4_0 --gen_model_header --model_version "6.0.0.1" sudo docker cp ubuntu22.04:/root/Model/QWEN/~/Model/QWEN/QWEN2.5/0.5B/Qwen2.5-0.5B-Instruct/Qwen2.5-0.5B-Instruct-Q40-HEADER-VERSION ./Qwen2.5-0.5B-Instruct-Q40-HEADER-VERSION + +4. 2026/07/01 转 AWQ 模型 SDLLM-AWQ-ChatExcel_v2-20260701 + +cd /home/chengjian/Work/GitHub/AI/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/sdllmv2 +sudo docker cp SDLLM-AWQ-ChatExcel_v2-20260701 ubuntu22.04:/root/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2 + +mkdir -p ~/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/Qwen2.5-Coder-7B-Instruct-AWQ-SDLLMv2-HEADER-VERSION + +cd /root/Model/py310/test +python3 convert_awq.py /root/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/SDLLM-AWQ-ChatExcel_v2-20260701 ~/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/Qwen2.5-Coder-7B-Instruct-AWQ-SDLLMv2-HEADER-VERSION --group_size 128 --gen_model_header --model_version "6.0.0.1" +参见 cat config.json | grep "transformers_version", tranformers 需要 v4.56.2, 由于标准 transformer 不支持加载 SDLLM 的模型, 模型路径下需要 register_sdllm.py, configuration_sdllm.py, convert_to_hf_sdllm.py, modeling_qwen2_sdllm.py 这几个文件来支撑. + +sudo docker cp ubuntu22.04:/root/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/Qwen2.5-Coder-7B-Instruct-AWQ-SDLLMv2-HEADER-VERSION ./ + + +python3 convert_awq.py /root/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/SDLLM-AWQ-ChatExcel_v2-20260701 ~/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/Qwen2.5-Coder-7B-Instruct-AWQ-SDLLMv2-Embed_Token_FP16_HEADER-VERSION --group_size 128 --gen_model_header --model_version "6.0.0.2" +sudo docker cp ubuntu22.04:~/Model/QWEN/QWEN2.5/7B/Qwen2.5-Coder-7B-Instruct-SDLLMv2/Qwen2.5-Coder-7B-Instruct-AWQ-SDLLMv2-Embed_Token_FP16_HEADER-VERSION ./ + + XAMPP -git fetch --depth=100 # 拉取最近 100 次提交 +git fetch --depth=100 # 拉取最近 100 次提交出 git fetch --depth=1000 # 继续拉取更多 git fetch --unshallow @@ -973,6 +998,7 @@ https://github.com/ViffyGwaanl/papertok-reader https://github.com/linshenkx/prompt-optimizer + cartography: Repository understanding and hierarchical codemap generation 代码检视 @@ -992,28 +1018,28 @@ npx skills add https://github.com/anthropics/skills --skill pptx - -请根据当前最新代码和架构更新 REAMDE，包括整个项目的 README 以及各个 agent 以及子目录的 README；README 需要包括各个项目的项目介绍, 软件架构, 主要功能, -1. 架构图 - 所有模块都添加了清晰的 ASCII art 架构图 -2. 工作流程 - 详细说明了每个 Agent 的工作流程和步骤 -3. 技术细节 - 添加了状态类定义、API 说明、配置参数等 -4. 使用示例 - 包含了完整的使用方法和示例命令 -5. 代码规范 - 统一了命名约定和注释风格说明 -6. 扩展计划 - 为每个模块添加了未来发展方向 - -/ralph-loop:ralph-loop "这个仓库的代码包含了如下功能 -1. lkml 目录实现了一个分析指定 LKML 社区补丁的 agent。 -2. rss 目录是用 TRAE 生成的代码，它是用 langgraph 实现的一个 phoronix 和 lwn 解析的 AGENT。 -3. patchwork 目录是用 shell 实现的解析 patchwork 工程的脚本。 +这个仓库的代码包含了如下功能 +1. lkml 目录实现了一个分析指定 LKML 社区补丁的 agent. +2. rss 目录是用 TRAE 生成的代码, 它是用 langgraph 实现的一个 phoronix 和 lwn 解析的 AGENT. +3. patchwork 目录是用 shell 实现的解析 patchwork 工程的脚本. 4. cgit 目录是用分析内核 commit 的 agent -5. kde.py 计划是整个工程的入口。 +5. kde.py 计划是整个工程的入口. 6. test 目录下是整个项目的测试用例 -项目根目录以及每个子目录的 README 中有对相关代码架构以及功能的解析。 +项目根目录以及每个子目录的 README 中有对相关代码架构以及功能的解析. -请完成如下两个功能 +请完成如下个功能 +请根据已有的 agent 和脚本(主要是 @src/patchwork/get_patchwork_series.sh), 在 patchwork 目录下基于 langgraph 实现一个 patchwork 的 AGENT. +1. 支持获取指定日期, 指定 projects 的 id , 所有的补丁列表, 并通过 lkml agent 对其进行分析. +2. 格式保持原来的输出格式, 并参考 lkml_agent 的输出格式. +3. 在 test 用力补齐对应的测试用例, 要求测试用例全部通过, 功能才算完成. +参见 projects id 和邮件列表的索引参考 @src/patchwork/project/projects_list.md +请使用 superpowers brainstorm skill 对该任务进行 brainstorm, 将 brainstorm 生成到 .task/20260512-patchwork_agent/01-brainstorm.md -功能一： -请根据当前最新代码和架构更新 REAMDE，包括整个项目的 README 以及各个 agent 以及子目录的 README；README 需要包括各个项目的项目介绍, 软件架构, 主要功能, + +/ralph 将 .task/20260512-patchwork_agent/02-plan.md 转换为 .task/20260512-patchwork_agent/03-plan.json + +功能一: +请根据当前最新代码和架构更新 REAMDE, 包括整个项目的 README 以及各个 agent 以及子目录的 README; README 需要包括各个项目的项目介绍, 软件架构, 主要功能, 1. 架构图 - 所有模块都添加了清晰的 ASCII art 架构图 2. 工作流程 - 详细说明了每个 Agent 的工作流程和步骤 3. 技术细节 - 添加了状态类定义、API 说明、配置参数等 @@ -1021,87 +1047,57 @@ npx skills add https://github.com/anthropics/skills --skill pptx 5. 代码规范 - 统一了命名约定和注释风格说明 6. 扩展计划 - 为每个模块添加了未来发展方向 -功能二： -整个项目的 README 以及各个 agent 以及子目录的 README 中，包含了整个项目和各个 AGENT 的软件架构， -diagrams 目录下有 mermaid 和 excalidraw 架构图，但是并不美观。 -请参考 README 中的架构图, 重新生成更美观的 mermaid 和 excalidraw 架构图，更新到 diagrams 目录下，并将 excalidraw 架构图更到到 README 中. +功能二: +整个项目的 README 以及各个 agent 以及子目录的 README 中, 包含了整个项目和各个 AGENT 的软件架构, +diagrams 目录下有 mermaid 和 excalidraw 架构图, 但是并不美观. +请参考 README 中的架构图, 重新生成更美观的 mermaid 和 excalidraw 架构图, 更新到 diagrams 目录下, 并将 excalidraw 架构图更到到 README 中. -1. 请将生成的架构图保存在 diagrams 目录下. 包括 mermaid 代码, ASCII, svg, excalidraw 格式. 我发现之前的架构图中有
字样，这些无法正常显示为换行，请换种方式呈现。 +1. 请将生成的架构图保存在 diagrams 目录下. 包括 mermaid 代码, ASCII, svg, excalidraw 格式. 我发现之前的架构图中有
字样, 这些无法正常显示为换行, 请换种方式呈现. 2. 请通过 @beautiful-mermaid @pretty-mermaid 生成 mermaid 代码, ASCII, svg 格式的架构图(要求保留 mermaid 代码到对应的 mmd 文件中, SVG 配色使用浅色) -3. 请通过 @excalidraw-diagram-generator 和 @excalidraw-diagram，以及 @excalidraw 几个 SKILLS 生成【手绘风格的架构图+Excalidraw动画】，保存原始 JSON 格式和 SVG 格式。要求手绘风格：Excalifont字体、roughness:手绘线条、轻配色；动画顺序：标题→XX层→XX层→连接线，每步时长500ms；画布0-1200x0-800，元素间距≥30px。若为复杂架构图，请通过 excalidraw 子代理委托规则执行。 -4. 将最后生成的 excalidraw 手绘风格 SVG 架构图，更新到各个 README 中。 +3. 请通过 @excalidraw-diagram-generator 和 @excalidraw-diagram, 以及 @excalidraw 几个 SKILLS 生成【手绘风格的架构图+Excalidraw动画】, 保存原始 JSON 格式和 SVG 格式. 要求手绘风格: Excalifont字体、roughness:手绘线条、轻配色; 动画顺序: 标题→XX层→XX层→连接线, 每步时长500ms; 画布0-1200x0-800, 元素间距≥30px. 若为复杂架构图, 请通过 excalidraw 子代理委托规则执行. +4. 将最后生成的 excalidraw 手绘风格 SVG 架构图, 更新到各个 README 中. -每个功能使用 @git-commit 提交这个提交一个 COMMIT，要求 COMMIT 描述为纯英文" --completion-promise "DONE" --max-iterations 5 +/ralph-loop:ralph-loop " , 全部完成后输出 COMPLETE" --completion-promise "COMPLETE" --max-iterations 10 + +/ralph-loop:ralph-loop "当前 claude 的 statusline 使用了 claude-hud 插件. 如果我想继续补充 ccstatusline 插件. +让两个插件的信息都显示, 需要怎么做. ccstatusline 可以使用 npx -y ccstatusline@latest 在 command 字段中配置. 请帮我配置" --completion-promise "DONE" --max-iterations 10 -/plugin install skill-creator@claude-plugins-official +整个项目的 README 以及各个 agent 以及子目录的 README 中, 包含了整个项目和各个 AGENT 的软件架构, +diagrams 目录下有 mermaid 和 excalidraw 架构图, 但是并不美观. +请参考 README 中的架构图, 重新生成更美观的 mermaid 和 excalidraw 架构图, 更新到 diagrams 目录下, 并将 excalidraw 架构图更到到 README 中. -/plugin install clangd-lsp@claude-plugins-official - - -/ralph-loop:ralph-loop "当前仓库存在未提交代码，使用 @git-commit 提交这个提交一个 COMMIT，要求 COMMIT 描述为纯英文，全部完成后输出 COMPLETE" --completion-promise "COMPLETE" --max-iterations 10 - -/ralph-loop:ralph-loop "当前 claude 的 statusline 使用了 claude-hud 插件。如果我想继续补充 ccstatusline 插件。 -让两个插件的信息都显示，需要怎么做。ccstatusline 可以使用 npx -y ccstatusline@latest 在 command 字段中配置。请帮我配置" --completion-promise "DONE" --max-iterations 10 - - -整个项目的 README 以及各个 agent 以及子目录的 README 中，包含了整个项目和各个 AGENT 的软件架构， -diagrams 目录下有 mermaid 和 excalidraw 架构图，但是并不美观。 -请参考 README 中的架构图, 重新生成更美观的 mermaid 和 excalidraw 架构图，更新到 diagrams 目录下，并将 excalidraw 架构图更到到 README 中. - -当前 diagrams 目录下生成的架构图非常乱，而且不美观，都不如生成的 ASCII 图标，给了你那么多 skills，你干活这么垃圾还能不能行了，重新生成下 -1. 每个架构图都按照 ASCII 的图标重新生成，ASCII 如果不美观或者不完整的也需要重新生成一次。 +当前 diagrams 目录下生成的架构图非常乱, 而且不美观, 都不如生成的 ASCII 图标, 给了你那么多 skills, 你干活这么垃圾还能不能行了, 重新生成下 +1. 每个架构图都按照 ASCII 的图标重新生成, ASCII 如果不美观或者不完整的也需要重新生成一次. 2. 保留 mermaid 源代码(保存到 xxx.mmd), 以及生成的对应的 SVG(保存到 xxx.svg). -3. 保留 excalidraw 源代码(保存到 xxx.excalidraw.json), 以及生成的对应的 SVG(保存到 xxx.excalidraw.svg)，且文字要用手写体。 -4. 之前多次生成架构图，每次重新生成的都保留了旧的，新的被命名为 xxx_new，不要这样子，每个架构图的每个格式，只保留最美观的那个文件。 -5. 最后使用 @git-commit 提交这个提交一个 COMMIT，要求 COMMIT 描述为纯英文 +3. 保留 excalidraw 源代码(保存到 xxx.excalidraw.json), 以及生成的对应的 SVG(保存到 xxx.excalidraw.svg), 且文字要用手写体. +4. 之前多次生成架构图, 每次重新生成的都保留了旧的, 新的被命名为 xxx_new, 不要这样子, 每个架构图的每个格式, 只保留最美观的那个文件. +5. 最后使用 @git-commit 提交这个提交一个 COMMIT, 要求 COMMIT 描述为纯英文 -整个项目的 README 以及各个 agent 以及子目录的 README 中，包含了整个项目和各个 AGENT 的软件架构， -diagrams 下存储了架构图的素材信息，其中 -1. mermaid 源代码以及 SVG 文件， mermaid 源代码保存在 xxx.mmd, 对应的 SVG 保存在 xxx.svg. -2. excalidraw 源代码以及 SVG 文件， excalidraw 源代码保存在 xxx.excalidraw.json, 对应的 SVG 保存在 xxx.excalidraw.svg. +整个项目的 README 以及各个 agent 以及子目录的 README 中, 包含了整个项目和各个 AGENT 的软件架构, +diagrams 下存储了架构图的素材信息, 其中 +1. mermaid 源代码以及 SVG 文件, mermaid 源代码保存在 xxx.mmd, 对应的 SVG 保存在 xxx.svg. +2. excalidraw 源代码以及 SVG 文件, excalidraw 源代码保存在 xxx.excalidraw.json, 对应的 SVG 保存在 xxx.excalidraw.svg. -整个项目的 README 以及各个 agent 以及子目录的 README 中，包含了整个项目和各个 AGENT 的软件架构， +整个项目的 README 以及各个 agent 以及子目录的 README 中, 包含了整个项目和各个 AGENT 的软件架构, diagrams 下存储了架构图的素材信息 -1. mermaid 源代码以及 SVG 文件， mermaid 源代码保存在 xxx.mmd, 对应的 SVG 保存在 xxx.svg. -2. excalidraw 源代码以及 SVG 文件， excalidraw 源代码保存在 xxx.excalidraw.json, 对应的 SVG 保存在 xxx.excalidraw.svg. +1. mermaid 源代码以及 SVG 文件, mermaid 源代码保存在 xxx.mmd, 对应的 SVG 保存在 xxx.svg. +2. excalidraw 源代码以及 SVG 文件, excalidraw 源代码保存在 xxx.excalidraw.json, 对应的 SVG 保存在 xxx.excalidraw.svg. -其中当前 diagrams 目录下生成的 excalidraw 架构图非常乱，而且不美观，都不如生成的 ASCII 图标，给了你那么多 skills，你干活这么垃圾还能不能行了，重新生成下。 +其中当前 diagrams 目录下生成的 excalidraw 架构图非常乱, 而且不美观, 都不如生成的 ASCII 图标, 给了你那么多 skills, 你干活这么垃圾还能不能行了, 重新生成下. -1. 请自行选择 @excalidraw-diagram-generator 和 @excalidraw-diagram，@excalidraw-diagram-skill 以及 @excalidraw 几个 SKILLS 生成【手绘风格的架构图+Excalidraw动画】，保存原始 JSON 格式和 SVG 格式。要求手绘风格：Excalifont字体、roughness:手绘线条、轻配色；动画顺序：标题→XX层→XX层→连接线，每步时长500ms；画布0-1200x0-800，元素间距≥30px。若为复杂架构图，请通过 excalidraw 子代理委托规则执行。 -2. 最后使用 @git-commit 提交这个提交一个 COMMIT，要求 COMMIT 描述为纯英文 +1. 请自行选择 @excalidraw-diagram-generator 和 @excalidraw-diagram, @excalidraw-diagram-skill 以及 @excalidraw 几个 SKILLS 生成【手绘风格的架构图+Excalidraw动画】, 保存原始 JSON 格式和 SVG 格式. 要求手绘风格: Excalifont字体、roughness:手绘线条、轻配色; 动画顺序: 标题→XX层→XX层→连接线, 每步时长500ms; 画布0-1200x0-800, 元素间距≥30px. 若为复杂架构图, 请通过 excalidraw 子代理委托规则执行. +2. 最后使用 @git-commit 提交这个提交一个 COMMIT, 要求 COMMIT 描述为纯英文 + +我使用 architecture-diagram skill 生成了仓库的架构图 + +当前仓库还有未提交的代码, 最后使用 @git-commit 提交这个提交一个 COMMIT, 要求 COMMIT 描述为纯英文 +1. 注意请将我 git add 的代码提交, 没有 add 的请不要 COMMIT - -当前仓库还有未提交的代码，最后使用 @git-commit 提交这个提交一个 COMMIT，要求 COMMIT 描述为纯英文 - -当前仓库有未 COMMIT 的提交，使用 @git-commit 提交这个提交一个 COMMIT，要求 COMMIT 描述为纯英文 - - - -当前配置下 opencode 可以结合 oh-my-opencode 和 superpowers 进行协同工作。 -但是有一些问题，想进一步让 superpowers 和 Sisyphus 和 Sisyphus (Ultraworker) 模式联动起来 -1 Sisyphus (Ultraworker) 模式下，按照 superpowers 的规范和工作流程，自动化工作，不用每个步骤询问用户。 -1.2 Sisyphus 模式，按照 superpowers 的规范和工作流程，每个工作完成后询问用户，允许用户变更流程，变更计划，调整任务。 - -1. 可否在进行任务之前询问用户使用 Ultra 模式， Normal 模式 -1.1 Ultraworker 按照 superpowers 的规范和工作流程，自动化工作，不用每个步骤询问用户。 -1.2 Normal 模式，按照 superpowers 的规范和工作流程，每个工作完成后询问用户，允许用户变更流程，变更计划，调整任务。 -1.3 Simple 模式下，则不跟 superpowers 协作，按照 Ultraworker 原有的流程工作。 -2. 使用 Sisyphus agent 工作时，Sisyphus (Ultraworker) 模式下，自动进入 Ultra 模式，否则默认进入 Normal 模式工作。 - - - - - - - - - -[Superpowers插件完整使用指南（一文搞懂）](https://blog.csdn.net/bojinyuan00/article/details/158420712) [AI开发】—— OpenCode双插件协同开发指南](https://blog.csdn.net/Lvyizhuo/article/details/157686197) [[Question]: How to get the status of background agents? #917](https://github.com/code-yeongyu/oh-my-opencode/issues/917) @@ -1109,48 +1105,11 @@ diagrams 下存储了架构图的素材信息 -[everything-claude-code](https://github.com/affaan-m/everything-claude-code#) - -压缩 Token -[使用 rtk 压缩 token](https://github.com/rtk-ai/rtk/blob/master/INSTALL.md) - -记忆功能 -[supermemory](https://github.com/supermemoryai/supermemory) - [](https://github.com/eunomia-bpf/agentsight) [](https://github.com/aaupov/ebpf-bolt) [](https://github.com/solatis/claude-config/tree/main) -[next-ai-draw-io](https://github.com/DayuanJiang/next-ai-draw-io) - -README.md 中每个 skills 的描述建议进一步细化, 要求包括 skills.sh 地址以及 github 地址，安装方式提供 git 方式和 npx 方式 - -" - -请实现 script 脚本 sync.py，提供参数允许将本仓库配置文件更新到实际的安装目录，也支持将实际安装目录的文件备份回当前仓库 -要求 -1. 提交 tui 交互界面，允许用户通过 tab 选择 -~/.config/opencode 下的配置文件有多个副本时，提交 tui 交互界面，允许用户通过 tab 选择要更新或者备份的配置文件 -比如更新时，通过 tab 选择 oh-my-opencode-interactive.jsonc, oh-my-opencode-ultraworker.jsonc -oh-my-opencode.jsonc 具体哪个文件更新到 oh-my-opencode.jsonc, 单选 -比如备份时，通过 tab 选择 ~/.config/opencode 下的 oh-my-opencode-interactive.jsonc, oh-my-opencode-ultraworker.jsonc, oh-my-opencode.jsonc 等配置文件具体哪些到当前仓库的 opencode, .gitignore -目录下，多选 -2. 更新或者分备份请先diff 下两边目录的差异，并提示用户进行检视，请注意更新和备份时，diff 的顺序，并提示用户 Y/N -进行安装或者取消。 script/README.md - -3. 脚本请生成到 script 目录下。 - - -sync.py backup 的时候，用户 tab 选中需要 backup 的配置文件之后， -请允许用户手动选择备份的文件名字，同时允许用户自定义文件名字 -比如 oh-my-opencode-interactive.json 其实是想备份到 oh-my-opencode-interactive.json(已经存在，覆盖安装), 也可能想备份到新的文件 oh-my-opencode-xxxx.json -opencode.json 文件类似 - - - - - 1. 介绍下 这个 skills @@ -1163,7 +1122,7 @@ https://skills.sh/jimliu/baoyu-skills/baoyu-slide-deck /plugin uninstall everything-claude-code@everything-claude-code -对比下如下几个仓库的功能，用途，优势和缺点 +对比下如下几个仓库的功能, 用途, 优势和缺点 [wshobson/agents](https://github.com/wshobson/agents) [sangrokjung/claude-forge](https://github.com/sangrokjung/claude-forge) [ruvnet/ruflo](https://github.com/ruvnet/ruflo) | Ruflo(Claude-Flow) @@ -1171,43 +1130,94 @@ https://skills.sh/jimliu/baoyu-skills/baoyu-slide-deck [langchain-ai/deepagents](https://github.com/langchain-ai/deepagents) -plugin/README.md 中详细整列个各个插件的相关信息。 -但是部分 markdown 中字段未填写，请帮忙填写 -补全此内容，请继续进行解析，请访问对应的 github 简要分析其仓库的 README 等信息，获取其详细的信息。并对仓库进行推荐评级 +https://x.com/Voxyz_ai/status/2038237755654783107 Cliamp kanban - -补全此内容, 请访问对应的网站简要分析其仓库，分析其详细信息，然后总结出这个仓库的目标，技术和使用场景。 -请注意，一定要访问这个仓库，然后去分析，不要瞎编. 分析要尽可能详细 -要求只修改这几行，不要全量生成整个 README.md +everything-claude-code/skills/autonomous-loops/SKILL.md -我只是简单测试了下，你怎么消耗了那么多 token，当前目录下有 shell 脚本统计分析下 claude 消耗的上下文 token 的来源和量 -但是统计的不太对。请继续优化下 -Ctx: 30.1k -Total:62.0k Cached:0 In:31.2k Out: 151 -另外使用 claude --bare 消耗只有 4k -我已经确认了 skills 和 ruls 压根没消耗多少，因为我把 skills 和 rules 放到了 skills.bak 和 rules.bak 目录下，消耗的 token 还是 非常多 +plugin/README.md 中庸 markdown 表格的格式, 分析和记录了每个仓库的用户, 星级. + +1. ## 未补全内容 + +但是部分内容未补全. 比如如下内容就是未补全的. + +| [xyz](https://github.com/xxxx) | 260 | +| [xyz](https://github.com/xxxx) | +| [xyz](https://xxxx) | 260 | +| [xyz](https://xxxx) | +| [](https://github.com/xxxx) | 260 | +| [](https://github.com/xxxx) | +| [](https://xxxx) | 260 | +| [](https://xxxx) | -分析下这个仓库，请注意，一定要访问这个仓库，然后去分析，不要瞎编. 分析要尽可能详细 +这些行往往只表格中只有 URL (可能追加了 star 数量)但没有描述的行 + +2. ## 评分规则 + +### 阈值评分系统 + +本工具使用阈值评分算法, 根据仓库的多项指标计算综合评分: + +| 指标 | 权重 | 阈值(1星-5星) | +|------|------|-------------------| +| Stars | 60% | ≤5K, ≤10K, ≤50K, ≤100K, >100K | +| Forks | 15% | ≤100, ≤200, ≤1K, ≤5K, >5K | +| Watchers | 10% | ≤100, ≤300, ≤1K, ≤5K, >5K | +| Issues | 15% | ≤100, ≤200, ≤500, ≤1K, >1K | + +- ⭐⭐⭐⭐⭐ (5星): 综合得分 ≥ 4.5 +- ⭐⭐⭐⭐ (4星): 综合得分 ≥ 3.5 +- ⭐⭐⭐ (3星): 综合得分 ≥ 2.5 +- ⭐⭐ (2星): 综合得分 ≥ 1.5 +- ⭐ (1星): 综合得分 < 1.5 + +请遍历所有未补全的内容 +补全这部分内容, 请访问对应的网站简要分析其仓库, 分析其详细信息, 然后总结出这个仓库的目标, 技术和使用场景. +请注意 +1. 一定要访问这个仓库, 然后去分析, 不要瞎编. 分析要尽可能详细 +2. 要求只修改未补全的这几行, 不要全量生成整个 README.md +3. 访问 github 可能会失败, 如果访问失败, 请重试几次 +4. 输出中文 + + +领导要求每个项目绘制甘特图, 附件为2个合同及一个甘特图模板, 帮我按照模板分别绘制2个合同对应项目的甘特图, 时间未知的可以写时间待定. +1. 请使用 /pdf skills 来解析 PDF 文件 +2. 生成 HTML 格式的甘特图, 同时保存成 SVG/PNG 格式 + + + +下周计划:
1、天谷项目: 对接天谷下周正式评价准备工作(周一-周二);
2、部门规划: 根据领导要求进一步修改知识产权部26年年度规划(周一-周四);
3、价值评估: 进一步修改价值评估方案, 搜集2-3家专利价值评估机构(周二-周四);
4、对接西子航空29490项目并进行下一步动作(周二-周五);
5、对接杭州市局56005项目拜访工作并进行下一步动作(周二-周四);
6、对接钱塘区产业专利导航工作并进行下一步动作(周二-周四) + + +要求按照上述计划生成 HTML + CSS 格式的甘特图. + + + +★ + +歸藏(guizang.ai) +@op7418 +· +6小时 +最近有两个非常出圈、非常牛逼的短剧: + +一个是《Enemy》, 一个是《吉时已到》, 可以看看 + https://github.com/dontbesilent2025/dbskill https://github.com/hamelsmu/evals-skills - - - https://github.com/sstklen/trump-code -https://github.com/Lum1104/Understand-Anything | [DeusData/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp) | https://github.com/haris-musa/excel-mcp-server -[OpenCode Day11：5个让OpenCode记住一切的Memory插件](https://mp.weixin.qq.com/s?__biz=MzY4NDAwNDk0Ng==&mid=2247484210&idx=2&sn=9b83f311941fe23c05467f6bb1a4af25&chksm=f28b3ec43e284bf709d8503ff300c5de81a20ec2ee77dab269fc7092e7df5be8431ba7a79c17&mpshare=1&scene=1&srcid=0310TbDbuWzrVO2cHZCS9BzE&sharer_shareinfo=e8294db882b0a67f0d95a923d7d055ef&sharer_shareinfo_first=0b91e4e5cdcfe20d8de52fc7659e4407#rd) +[OpenCode Day11: 5个让OpenCode记住一切的Memory插件](https://mp.weixin.qq.com/s?__biz=MzY4NDAwNDk0Ng==&mid=2247484210&idx=2&sn=9b83f311941fe23c05467f6bb1a4af25&chksm=f28b3ec43e284bf709d8503ff300c5de81a20ec2ee77dab269fc7092e7df5be8431ba7a79c17&mpshare=1&scene=1&srcid=0310TbDbuWzrVO2cHZCS9BzE&sharer_shareinfo=e8294db882b0a67f0d95a923d7d055ef&sharer_shareinfo_first=0b91e4e5cdcfe20d8de52fc7659e4407#rd) -[Claude Code 600倍加速隐藏神器！LSP一键开启，代码查找50ms精准定位](https://mp.weixin.qq.com/s?__biz=MzcwNjA1ODkxOQ==&mid=2247484867&idx=3&sn=9eabafb46c8dca13d2ffb24eb282183d&chksm=f5f631981b2ed1136c4ef9d0ca16d5af9b365817ea7c9de1fafa888aeab077d1b474336c2ee8&mpshare=1&scene=1&srcid=0310iaugLaelp9RbOr2DMtpi&sharer_shareinfo=61f85b69f7978c63cb73cc7fd7617ffd&sharer_shareinfo_first=2d40e269eba4cdcdd264941dba56df3a#rd) +[Claude Code 600倍加速隐藏神器！LSP一键开启, 代码查找50ms精准定位](https://mp.weixin.qq.com/s?__biz=MzcwNjA1ODkxOQ==&mid=2247484867&idx=3&sn=9eabafb46c8dca13d2ffb24eb282183d&chksm=f5f631981b2ed1136c4ef9d0ca16d5af9b365817ea7c9de1fafa888aeab077d1b474336c2ee8&mpshare=1&scene=1&srcid=0310iaugLaelp9RbOr2DMtpi&sharer_shareinfo=61f85b69f7978c63cb73cc7fd7617ffd&sharer_shareinfo_first=2d40e269eba4cdcdd264941dba56df3a#rd) https://github.com/hesreallyhim/awesome-claude-code @@ -1216,18 +1226,632 @@ https://github.com/mikewarrior/sdd-orchestrator-skill -| [A-mem](https://github.com/agiresearch/A-mem) | 基于 Zettelkasten 原理的代理式内存系统，通过 ChromaDB 实现智能索引和链接，支持动态内存组织、互连知识网络和持续内存演变，适用于 LLM 代理的内存管理和知识组织 | 多模型支持 | ⭐⭐ | -| [Clawith](https://github.com/dydy-94/clawith) | 开源多智能体协作平台，为每个 AI 智能体提供持久身份、长期记忆和独立工作空间，支持智能体间协作和团队级管理。主要特点包括：数字员工身份系统、组织知识共享平台（Plaza）、任务监督机制、组织级控制、自进化能力、持久身份与记忆、私人工作空间等。技术栈：后端（FastAPI、SQLAlchemy、PostgreSQL/SQLite、Redis）、前端（React 19、TypeScript、Vite）、Docker 部署。适用于团队协作、企业级应用、多智能体协同工作、知识管理等场景 | 多模型支持 | ⭐⭐ | -| [Forge](https://github.com/antinomyhq/forge) | AI 增强的终端开发环境，是一个综合编码代理，将 AI 能力与开发环境集成。主要功能包括：代码理解、新功能实现、调试辅助、代码审查、学习新技术、数据库架构设计、重构遗留代码、Git 操作等。支持多提供商（OpenAI、Anthropic 等），具有零配置、无缝集成、安全设计（受限 shell 模式）等特点。技术栈：命令行工具，支持多种配置选项和 MCP 协议集成。适用于开发人员日常编码、问题解决、学习新技术等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ -| [graph-memory](https://github.com/adoresever/graph-memory) | OpenClaw 的知识图谱上下文引擎，解决了三个核心问题：上下文爆炸（通过结构化知识图谱压缩）、跨会话失忆（通过 FTS5/向量搜索 + 图遍历自动召回相关知识）、技能孤岛（通过连接相关技能）。主要功能包括：知识图谱构建（3 种节点类型、5 种边类型）、个性化 PageRank 排序、社区检测、向量去重等。技术栈：SQLite 数据库、TypeScript、OpenAI 兼容 API。适用于长对话场景、跨会话知识管理、技能学习与应用等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ -| [AutoResearchClaw](https://github.com/aiming-lab/AutoResearchClaw) | 完全自主的研究管道，将单个研究想法转化为会议级论文。主要功能包括：23 个阶段的完整研究流程、多源文献搜索（OpenAlex、Semantic Scholar、arXiv）、4 层引用验证、硬件感知执行、OpenCode 野兽模式、沙盒实验、会议级写作、质量门控等。技术栈：Python、Docker、LaTeX、OpenAI 兼容 API、MetaClaw 集成。适用于学术研究、论文写作、实验自动化、研究思路验证等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ -| [Notchi](https://notchi.app/) | Claude Code 的 macOS 伴侣应用，居住在设备的 notch 区域，实时响应每个想法、工具调用和错误。适用于 macOS Sequoia 系统，目前处于 beta v1.0.0 版本。适用于 Claude Code 用户在 macOS 上的实时辅助场景 | Claude Code | ⭐⭐⭐⭐ -| [memory-lancedb-pro](https://github.com/CortexReach/memory-lancedb-pro) | OpenClaw 智能体的 AI 记忆助手，为智能体提供跨会话、跨智能体、跨时间的持久记忆。主要功能包括：自动捕获、智能提取（6 类分类）、智能遗忘（Weibull 衰减模型）、混合检索（向量 + BM25 全文搜索 + 交叉编码器重排序）、上下文注入、多范围隔离、多提供商支持、完整工具包等。技术栈：LanceDB、OpenAI 兼容 API、TypeScript。适用于智能体记忆管理、跨会话知识保持、个性化偏好学习等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ -| [bozhou-skills](https://github.com/bozhouDev/bozhou-skills) | 私有仓库，无法获取详细信息 | 未知 | ⭐⭐⭐⭐ +| [A-mem](https://github.com/agiresearch/A-mem) | 基于 Zettelkasten 原理的代理式内存系统, 通过 ChromaDB 实现智能索引和链接, 支持动态内存组织、互连知识网络和持续内存演变, 适用于 LLM 代理的内存管理和知识组织 | 多模型支持 | ⭐⭐ | +| [Clawith](https://github.com/dydy-94/clawith) | 开源多智能体协作平台, 为每个 AI 智能体提供持久身份、长期记忆和独立工作空间, 支持智能体间协作和团队级管理. 主要特点包括: 数字员工身份系统、组织知识共享平台(Plaza)、任务监督机制、组织级控制、自进化能力、持久身份与记忆、私人工作空间等. 技术栈: 后端(FastAPI、SQLAlchemy、PostgreSQL/SQLite、Redis)、前端(React 19、TypeScript、Vite)、Docker 部署. 适用于团队协作、企业级应用、多智能体协同工作、知识管理等场景 | 多模型支持 | ⭐⭐ | +| [Forge](https://github.com/antinomyhq/forge) | AI 增强的终端开发环境, 是一个综合编码代理, 将 AI 能力与开发环境集成. 主要功能包括: 代码理解、新功能实现、调试辅助、代码审查、学习新技术、数据库架构设计、重构遗留代码、Git 操作等. 支持多提供商(OpenAI、Anthropic 等), 具有零配置、无缝集成、安全设计(受限 shell 模式)等特点. 技术栈: 命令行工具, 支持多种配置选项和 MCP 协议集成. 适用于开发人员日常编码、问题解决、学习新技术等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ +| [graph-memory](https://github.com/adoresever/graph-memory) | OpenClaw 的知识图谱上下文引擎, 解决了三个核心问题: 上下文爆炸(通过结构化知识图谱压缩)、跨会话失忆(通过 FTS5/向量搜索 + 图遍历自动召回相关知识)、技能孤岛(通过连接相关技能). 主要功能包括: 知识图谱构建(3 种节点类型、5 种边类型)、个性化 PageRank 排序、社区检测、向量去重等. 技术栈: SQLite 数据库、TypeScript、OpenAI 兼容 API. 适用于长对话场景、跨会话知识管理、技能学习与应用等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ +| [Notchi](https://notchi.app/) | Claude Code 的 macOS 伴侣应用, 居住在设备的 notch 区域, 实时响应每个想法、工具调用和错误. 适用于 macOS Sequoia 系统, 目前处于 beta v1.0.0 版本. 适用于 Claude Code 用户在 macOS 上的实时辅助场景 | Claude Code | ⭐⭐⭐⭐ +| [memory-lancedb-pro](https://github.com/CortexReach/memory-lancedb-pro) | OpenClaw 智能体的 AI 记忆助手, 为智能体提供跨会话、跨智能体、跨时间的持久记忆. 主要功能包括: 自动捕获、智能提取(6 类分类)、智能遗忘(Weibull 衰减模型)、混合检索(向量 + BM25 全文搜索 + 交叉编码器重排序)、上下文注入、多范围隔离、多提供商支持、完整工具包等. 技术栈: LanceDB、OpenAI 兼容 API、TypeScript. 适用于智能体记忆管理、跨会话知识保持、个性化偏好学习等场景 | 多模型支持 | ⭐⭐⭐⭐⭐ +| [bozhou-skills](https://github.com/bozhouDev/bozhou-skills) | 私有仓库, 无法获取详细信息 | 未知 | ⭐⭐⭐⭐ https://github.com/tickflow-org/tickflow https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools https://github.com/IsHexx/system-prompts-and-models-of-ai-tools-chinese +https://github.com/tangshimin/MuJing +https://github.com/JOYCEQL/magic-resume +https://github.com/decksters-lab/fastfetch/tree/main +https://github.com/mayukh4/linux-android +https://github.com/HKUDS/RAG-Anything +https://github.com/Lakr233/vphone-cli +https://github.com/thunderbird/thunderbolt +https://github.com/outcomeops/context-engineering + +askanyai.com +droidxai.com +https://github.com/thunderbird/thunderbolt + + +https://github.com/chatgptprojects/clear-code +https://github.com/aaif-goose/goose +[](https://x.com/bystander520/status/2042873263379091856) + +https://github.com/ninehills/blog/issues/97 +https://github.com/FradSer/dotfiles/blob/main/dot_claude/executable_statusline.sh +https://github.com/ChrisTitusTech/winutil + +===diff 工具=== +https://github.com/wong2/diffx +https://github.com/agavra/tuicr +https://madewithvuejs.com/ast-explorer +https://github.com/dannote/reach +https://github.com/CarterMcAlister/linear-code-review +https://github.com/bterwijn/memory_graph +https://tokennav.cc +https://github.com/pierrecomputer/pierre +https://github.com/modem-dev/hunk +https://docu.md +https://github.com/rockorager/comview +https://diffshub.com +https://github.com/nkzw-tech/codiff + +===GIT=== +https://github.com/affromero/gitpane +https://github.com/kitlangton/ghui +https://github.com/open-gitagent/gitagent +https://github.com/unnecessary-special-projects/ghist +https://github.com/JetpackDuba/Gitnuro +https://github.com/coffeejones/gitvision +https://github.com/Chronos778/git-rewind +https://github.com/abdosorour7/git-commands-cheatsheet +https://github.com/SSShooter/ebook-to-mindmap +https://checkmygit.com +https://github.com/DetachHead/rebased +https://github.com/github/github-mcp-server +https://github.com/AmintaCCCP/GithubStarsManager +[2026/06/08, 陈成 @chenchengpro, AI 写代码比人审代码快太多, 瓶颈早就从「produce diff」挪到了「validate diff」. no-mistakes 这个 Go 工具的思路很巧: 在你的仓库和真实远端之间塞一个本地裸仓库当「闸门」, 你 push 到 no-mistakes 这个 remote 而不是 origin(origin 永不被劫持, 普通 push 照常), 它就在一个一次性 worktree 里跑一条固定九步流水线 intent→rebase→review→test→document→lint→push→pr→ci, 全过了才转发上游并自动开干净 PR. ](https://x.com/chenchengpro/status/2063991395543859443) +https://github.com/521xueweihan/HelloGitHub +https://gh.jiayouvibe.com, 阿喵给你推荐这个工具: GitHub Open Data. 它做了一件很反常识的事: 把 GitHub 变成了一个“项目信息流”. 不再是搜索仓库, 而是直接刷开源项目. +https://github.com/Younesfdj/gitfut, 有点意思, 只要把 github 改为 gitfut 就可以把你的 GitHub 个人资料统计数据做成 FIFA 球员卡的样子, 谁看了都想点一下. +https://gitfut.com/gatieme +https://zaowujuzhen.com/maker/radar/github + +===REPO 分析=== +https://github.com/lirantal/repolyze [2026/04/20, Geek Lite @QingQ77, 在阅读代码之前, 用 git 命令快速摸底一个仓库的健康状况. ](https://x.com/QingQ77/status/2046048707284791322) +https://mintlify.wiki/ghostty-org/ghostty/introduction +https://github.com/rahulnyk/knowledge_graph +https://github.com/potpie-ai/potpie +https://github.com/trsoliu/mini-wiki +https://github.com/robert-mcdermott/ai-knowledge-graph +https://github.com/Done-0/fuck-u-code +https://github.com/Lum1104/Understand-Anything +https://github.com/study8677/awesome-architecture +https://github.com/Sidhant0707/codeautopsy +https://www.gitreverse.com 挖到一个有点逆天的玩意儿, 专门扒任何GitHub仓库背后的prompt提示词.用法简单到离谱, 压根不用装也不用配: 1️⃣ 把网址里的github直接手动换成gitreverse; 2️⃣ 它立马就把复刻这个项目的prompt甩到你脸上; 几秒钟就能逆向工程任何项目, 还是100%免费不用掏钱. + +说白了, 以后刷到别人的开源项目, 不光能抄代码, 连 + + +Computer Use +https://github.com/coasty-ai/open-computer-use +https://github.com/browser-use/video-use +https://github.com/remorses/usecomputer +https://github.com/iFurySt/open-codex-computer-use +https://github.com/injaneity/pi-computer-use +https://github.com/onesuper/tui-use +https://github.com/remorses/usecomputer +https://github.com/injaneity/pi-computer-use +https://github.com/trycua/cua +https://github.com/e2b-dev/surf +https://github.com/memohai/Autofish +https://github.com/DearVa/Everywhere +https://github.com/AmrDab/clawdcursor +https://github.com/google/agents-cli/ +https://github.com/bytedance/UI-TARS-desktop +https://github.com/Core-Mate/OpenGUI +https://github.com/opencyvis/opencyvis-phone +https://www.kimi.com/features/webbridge +https://github.com/simular-ai/Agent-S +https://github.com/agent-sh/computer-use-linux +Marvis +https://github.com/browser-use/bux +https://github.com/yb2460/harness-anything +[2026/06/03, 车厘子 @0xcherry, 两个 Coding Harness 合并起来, 等于一个 Coding Harness. 这是 Coding 任务的合并律.](https://x.com/0xcherry/status/2062006201928524164) + +开盒 +https://github.com/sherlock-project/sherlock +https://d2lang.com/ +https://github.com/HunxByts/GhostTrack +https://github.com/Z4nzu/hackingtool + +===英语学习=== +https://github.com/cuixueshe/earthworm +julebu.ai +https://github.com/UlionTse/translators +https://github.com/zyronon/TypeWords +https://github.com/xiaochong/hi-kid +https://engoo.com/app/materials/en +https://github.com/byoungd/English-level-up-tips +https://github.com/nicejade/gpt-wordbook +https://github.com/mengxi-ream/read-frog +https://github.com/Cuimao777/cuimao-translator +https://keybr.com +graker +https://github.com/hehonghui/awesome-english-ebooks +https://github.com/Cookee24/PairTranslate 配对翻译插件 +https://julebu.co/ +https://github.com/fishjar/kiss-translator +https://en.kyrgk.com +https://github.com/RealKai42/qwerty-learner +https://github.com/echo-loop/Echo-Loop +https://readto.ai/ +@midudev +从零开始 → http://curso-ingles.com +口语 → http://sesame.com +语法 → http://engvid.com +通过电影 → http://playphrase.me +剑桥 → http://cambridgeenglish.org +听力 → http://bbc.co.uk/learningenglish +https://github.com/HoraceLuBFA/en-zh-translation-polish +@tinyfool +https://github.com/forestai123456/hear-me-out, 听我解释 +Chrome / Edge 浏览器扩展 — 为网页视频生成实时 AI 字幕, 支持网页翻译和划词翻译. + +1」Trancy 官网 http://trancy.org +除了沉浸翻译, 还有 YouTube 双语字幕功能, UI 更好看, 目前搭配DeepSeek 主力在用. 免费, 高级功能付费, 闭源. +2」FluentRead 流畅阅读 ,免费开源 https://github.com/Bistutu/FluentRead +3」KISS Translator 简约翻译 , 免费开源 https://github.com/fishjar/kiss-translator +4」Read Frog 陪读蛙 免费开源 https://github.com/mengxi-ream/read-frog +http://github.com/tangshimin/MuJing, GitHub 上的开源工具 MuJing(幕境), 把电影、美剧、字幕和文档里的真实表达变成你的词汇课堂: 在情境中理解, 在反复出现中巩固, 再通过练习把记忆“锁死”. 在线地址: https://mujingx.com +[2026/07/01, 墓碑科技 @mubeitech, 学外语最省钱、也最粗暴的办法: 边快走, 边像疯子一样自言自语. 这套方法有个正经的名字, 叫“影子跟读法”(Shadowing). ](https://x.com/mubeitech/status/2072007624770424995) +https://github.com/deusyu/translate-book/tree/main Claude Code Skill, 使用并行 subagent 将整本书(PDF/DOCX/EPUB)翻译成任意语言. +[2026/07/08, Rey判断位｜英语自由 @ReynoldDai, 英语接入世界是判断位的第1块积木, 打开人生选项集的起点](https://x.com/ReynoldDai/status/2074814728376135913) +[2026/07/08, 董币哥 @NextBullReady, 个人认为目前实现全英交流最快的方式之一, 最快7天见效](https://x.com/NextBullReady/status/2074705283570602292) +[2026/07/07, 孤桜ETH @GYLQ520, 2017年, 有位朋友向他请教“高效学英语的路径”, 他当场梳理了一份实操指南. ](https://x.com/GYLQ520/status/2074487666389991700) +[Huan @Huanusa, 会英语-能用其实只需要这850个单词！](https://x.com/Huanusa/status/2075222778207162464), 我写了一个iOS的应用: 词骨英语850, http://lei-lei.org/850s, 有对应的单词游戏网站, 大家可以自由学习, 😂 巧了我这也有一个对应的网站: https://ogden-basic-english-7s7.pages.dev + + +===理财=== +https://www.wise-hold.com/ +https://github.com/komako-workshop/digital-oracle +https://wall-street-skill.com/ +https://github.com/XiaomingX/ai-money-maker-handbook +https://github.com/brokermr810/QuantDinger +[2026/04/05, 邦比快跑 @binbinmath, 两天时间, 我把巴菲特70年的股东信变成了知识图谱](https://x.com/binbinmath/status/2040690438122987762) +https://btcdca.me +http://tiatleak.com/sol +https://creao.ai/@Moyu +https://github.com/pingdj/Web3 +https://invest-nav.com/tools/investment-handbook/ai-optical-interconnect-chain/ +https://github.com/waditu/tushare +https://www.wise-hold.com/ +https://github.com/Open-Dev-Society/OpenStock +https://github.com/QuantConnect/Lean +https://www.slickcharts.com, https://x.com/YaelC_03/status/2060686265734066644 +https://github.com/ArvinLovegood/go-stock +https://github.com/zgwl/chinese-buy-us-stock-guide +https://github.com/TNT-Likely/PanWatch, https://x.com/eastweb3eth/status/2068157453251080498 +https://wise-etf.com +[Finviz](https://x.com/AYi_AInotes/status/2067904860486349263) https://x.com/YaelC_03/status/2067495682093764817 +https://aichainmap.com/serenity, 白毛速报: 有人根据白毛股神的推文做了一个产品. 你看这种产品都是 AI slop, 但没人在乎, 能获取到有用的信息就行. 拿别人的内容包装一下, 还可以做成盈利产品, 需要付费才能解锁全部内容. +https://www.ainvest.com/terminal/真诚推荐一个自用的美股交易工具 AInvest terminal mac 版本. 好用在哪里呢？一句话可以建设你自己的交易界面, 你想看什么, 想怎么调整就怎么调整, 很舒服. 最关键的是, 可以直接通过AI对话来帮助你在实时图表上画K线, 这个在其他的大模型上是很难做到的. +Machine Learning for Trading +Vibe-Research +[研究美股最应该关注的 10 个网站](https://x.com/spicycandy00/status/2074727556511838292) +[断浪 @waveking1314, 如果你连这 10 个网站都不知道, 真的别急着去炒美股. 美股的信息密度很高, 只靠 X 上几个 KOL 喊票, 很容易被情绪带着跑. ](https://x.com/waveking1314/status/2074512270017896603) +[鸟哥 | 蓝鸟会🕊️ @NFTCPS, 如果你连这10个网站都不知道就不要去炒美股了！](https://x.com/NFTCPS/status/2074380392195399942) +https://github.com/LLMQuant/quant-wiki +https://github.com/xuchonglang/investing-for-beginners 投资入门指南 +https://chatgpt.com/apps?q=longbridge, 长桥 Longbridge 已经在 ChatGPT 发布上线了. 超过 140 个 MCP tools, 涵盖: 全面的股票/期权行情、资讯、财报、分红派息、分析师预测、股东信息、机构持仓变动、经营回顾、完整的历史 K 线, 还有你的持仓订单 -- 你需要的都有. 让它帮你分析持仓、发现投资机会. +https://www.starterstory.com, 发现一个网站, 专门收集 starter idea 并公开收入. 里面有不少 idea 还挺有意思的 +https://invest.howlifeusa.com/zh, 美国投资指南, HowLifeUSA推出的《投资百科》 +[华尔街观察 Xtrader @cnfinancewatch, 十个短线客喜欢的A股 APP](https://x.com/cnfinancewatch/status/2074645568492904818) +stock-sdk +https://github.com/calesthio/BreakoutAnalysis, 研究股票的朋友多少有这个困扰, 平时不可能一直盯盘, 但又生怕错过突然放量拉升的票. BreakoutAnalysis 干的就是盯盘这个活, 开市期间每 15 分钟扫一遍全美股市场, 揪出放量大涨的股票. + +===可视化=== +https://github.com/drasimwagan/mdv +https://github.com/amit9838/brewlens +https://github.com/sqshq/sampler +https://github.com/neneodonkor/asciigraph-rs +https://regex-vis.com/ +https://github.com/Domenez-dev/lazy-cron +https://github.com/SurpriseDog/LazyCron +https://github.com/unhappychoice/splashboard +https://docu.md +https://github.com/pranshuparmar/witr +https://github.com/HarleyCoops/Math-To-Manim +https://github.com/HugeCatLab/ChatTutor +https://langsagne.vercel.app/ +https://visualgo.net/en +https://seeing-theory.brown.edu/cn.html +https://www.napkin.ai/ 可视化图表 +https://github.com/asciidraw/asciidraw.github.io +https://github.com/GordenSun/mathVideoMaker +https://github.com/HugeCatLab/ChatTutor +https://github.com/andyhuo520/aetherviz-master +https://github.com/charmbracelet/freeze +https://github.com/Makisuo/maple + +===Office=== +https://github.com/manpoai/AgentOfficeSuite +https://github.com/iOfficeAI/OfficeCLI +https://github.com/larksuite/cli +https://github.com/officecli/officedex + + +===安全=== +https://github.com/Armur-Ai/Pentest-Swarm-AI + +===软件=== +https://github.com/stackia/best-windows-apps +https://youmind.com/zh-CN/skills/x6ux3YCCI2qtaT +https://github.com/sindresorhus/awesome +https://github.com/scriptscat/scriptcat +https://github.com/SuperManito/LinuxMirrors +https://github.com/kimlimjustin/xplorer +https://github.com/ricocc/rico-md +https://github.com/bannedbook/fanqiang +https://github.com/appergb/openless +| [](https://github.com/karinushka/paneru) | 1,442 | 窗口管理器 +| [](https://github.com/niri-wm/niri) | 24,028 | 窗口管理器 +韩国某哥们为了戒网瘾, 把1119个"危险网站"全拉黑, 结果这份名单一上GitHub, 直接变成了全网最热宝藏导航—— https://github.com/wpzzz/blocked-sites-in-south-korea +https://github.com/eduwass/tmux-palette +https://github.com/jaywcjlove/awesome-mac +https://appstoreprice.org/zh/apps +https://github.com/LiuMengxuan04/shushu-internship-tool +https://github.com/tejas-raskar/noted.md +https://github.com/wangrongding/clash-kit +https://github.com/l0ng-ai/papr +https://github.com/plait-board/drawnix +https://appark.ai/en/top-charts/app-store +https://www.paywallpro.app/zh +https://github.com/clefspear/starcommand +https://github.com/Ponphil/LitePan +https://github.com/cccyd2003-qwq/pinkbin +https://app.liulian.ink/ +https://github.com/zakirullin/files.md +https://github.com/LOWERTOP/Shadowrocket-First#shadowrocket-%E9%85%8D%E8%89%B2%E6%96%87%E4%BB%B6 +https://github.com/superloglabs/superlog +https://github.com/hydropix/TranslateBooksWithLLMs +https://github.com/bannedbook/fanqiang +https://github.com/mikf/gallery-dl +https://github.com/ShadowArcanist/netviz +https://github.com/colinvkim/Radix +https://github.com/beltromatti/get-it +https://github.com/vid4l-07/Klip +https://v.bxkp.org/ +https://mineru.net/ +https://github.com/stardustai/dataset-viewer +https://github.com/opendataloader-project/opendataloader-pdf +[2026/06/04, 歸藏(guizang.ai) @op7418, 即览: 手机上看 Markdown 和 HTML, 怎么就这么难？](https://x.com/op7418/status/2062361524367401461) +https://github.com/MrsEWE44/musicDownload +https://github.com/code2rich/jpage, 拖入 HTML 或 Markdown 文件即得一个可分享的在线页面, 零配置、无需部署. 即页是个零配置的上传即预览工具. 把 HTML 或 Markdown 文件拖进去, 秒级生成在线页面, 自动给你一个短链接. 支持代码高亮、数学公式、流程图渲染, 还有版本历史、标签分类、多用户权限这些功能. +https://appstoreprice.org/zh/apps +https://fmhy.net [2026/06/19, Amto @XAMTO_AI, 听说了没, 闲鱼上那些卖家好多都跑这儿来进货！](https://x.com/XAMTO_AI/status/2067803303791260086) +https://github.com/rccyx/thyx Linux 登录管理器 +https://github.com/Milktang0128/Dob, 在 macOS 上选中文本后快速用 AI 朗读、解释、翻译、审校并留档的菜单栏工具. 一个安静的 macOS 菜单栏工具. 选中一段文字, 它就弹出工具条——朗读、翻译、解释、提炼、审校, 点一下就好. 支持拿当前页面的上下文一起发给 AI, 也能用多个模型比较结果. 看完觉得有用就留档, 存成本地 Markdown. 兼容 DeepSeek、OpenAI 和各种国产模型. +https://search-sharp.com/ +https://github.com/chess99/tab-out +[2026/06/30, 唐清乐 @tangqingyue, 刷知乎看到知乎开放AI接口了](https://x.com/tangqingyue/status/2071877502189138353) +https://github.com/ricocc/rico-bookmark-manager, 做了一个书签 SKill 来管理我乱糟糟的 3000 多条浏览器书签 +🔗 https://github.com/ricocc/rico-bookmark-manager, 支持生成一个内置的书签导航站, 可以在导航站上进行书签的管理和修改, 然后导出书签数据. +领哥LingGe, @shangdu2005 的个人网站; 卧槽！终于让我搞成了！https://lingge66.pages.dev/ +https://github.com/Ebullioscopic/Atoll, 苹果灵动岛 +最近开发了一个类似slideshare的 PPT共享网站: https://ppt.qiaomu.ai 大家可以注册上传 keynote、pdf、pptx、html ppt 成为全屏演示PPT, 以后出去分享可以不用带电脑, 哈哈哈. Demo: 动漫解读哲学是什么 https://ppt.qiaomu.ai/decks/zhexue-shishenme +Typeless +https://github.com/elebumm/RedditVideoMakerBot +https://github.com/NanmiCoder/MediaCrawler, MediaCrawler - 自媒体平台爬虫 🕷️ +[2026/07/08, Ren @Ryrenz, 用好这 6 个工具, 机票、路线、酒店全给你省一大笔](https://x.com/Ryrenz/status/2074705035389456863) +https://github.com/larlarua/AutoCVE +https://github.com/lzh-phd/topic-feasibility-screener 手头有个数据集但不知道该往哪个方向做？它直接帮你发散出多个选题. 然后自动去扒文献, 能搜出直接证据还是只有桥接文献——这种区分很实用. 还会拿你的数据跑个初步回归, 验证实证可行性. 最后给每个候选选题打0-100的分, 包含理论支持、证据缺口、创新价值. 等于把“选题–查文献–试回归”这一套前期试错流程自动走了一遍. +https://github.com/fmhy/edit GitHub 上的 FMHY 是一份把全网免费资源打包整理好的宝藏合集, 强烈建议直接收藏. 电影、动漫、音乐、书籍、下载、游戏、去广告等常用资源一应俱全, 找资源不再东翻西找. 不止资源, 它还汇总了系统、文件管理、网络、 +https://github.com/wickenico/WailBrew, WailBrew 就是为此而来: 一款开源的 Homebrew 可视化工具, 把 Homebrew 变成“App Store 式”操作——浏览、搜索、安装、管理, 一目了然、上手即用. +https://github.com/kalcaddle/kodbox, 直接把浏览器魔改成了一个完整的电脑桌面系统. GitHub 上挖出的 3.2k 星开源神器 kodbox, 名义上是个 Web 文件管理器, 实际上是个随身的云端 OS + 在线 IDE. 不管你人在哪, 用谁的电脑, 只要打开浏览器, 立马接管你的所有云盘和本地文件, 还能直接写代码建网站, 白嫖党狂喜！ +https://sobrief.com, 不再错过任何好书 +https://github.com/nilbuild/developer-roadmap, 一个由社区驱动的交互式开发者成长路线平台, 目前在GitHub上已狂揽360k+星标, 全球排名高居第7位. + + +===网站复刻=== +https://github.com/uxKero/anydesign +https://github.com/JCodesMore/ai-website-cloner-template + +===CLI=== +https://github.com/iOfficeAI/OfficeCLI +https://github.com/jackwener/wx-cli +https://down.mptext.top/dashboard/api +https://github.com/teng-lin/notebooklm-py +https://github.com/adithya-s-k/omniparse +https://github.com/can4hou6joeng4/boss-agent-cli +https://github.com/521xueweihan/HelloGitHub +https://github.com/lawrencewzen/imgen +[2026/06/01, yibie @yibie, 把 AI Agent 当普通 CLI 用——pipe in, pipe out.](https://x.com/yibie/status/2061466323306397956) +https://github.com/ntrospect0/glint +https://github.com/microsoft/intelligent-terminal +https://github.com/ruvnet/agent-harness-generator +https://github.com/langchain-ai/openwiki OpenWiki —— 让你的 AI Agent 拥有最新代码文档的工具 OpenWiki 是 LangChain 团队出品的 CLI 工具, 专为 AI Agent 设计, 能自动为代码库生成并持续维护高质量的 agent 文档. +https://tikhub.io, 面向具身智能的社交推理与情感智能数据集——以及驱动量化交易、政府与国防、营销广告领域 AI 智能体的实时社媒数据 API. + +===WeChat=== +https://github.com/wechat-article/wechat-article-exporter +微信公众号文章批量下载导出, 终于有了一个相对完整的开源方案: +wechat-article-exporter, GitHub 1.1 万+ stars. +在线版可以直接用: +https://down.mptext.top +GitHub: +https://github.com/wechat-article/wechat-article-exporter +它能通过公众号关键词定位文章, 批量拉取文章列表, 并导出为 html / excel / md / docx / json / txt 六种格式. +最实用的是 HTML 导出: 图片和样式会一起打包, 离线打开也能尽量保留原文排版. 对于做个人知识库、资料归档、内容研究的人, 这个功能非常直接. +如果配合抓包拿到 credentials, 还可以进一步导出阅读量、评论、评论回复、转发量等数据. 做公众号内容分析的人, 可以少写很多重复脚本. +不想依赖第三方服务, 也支持 Docker 或 Cloudflare 私有化部署. 文档在: +https://docs.mptext.top +最后提醒一句: 文章版权归原作者. 工具适合归档自己读过、需要研究和整理的内容, 不适合拿去商用侵权. +对长期做内容、研究、知识管理的人来说, 这类工具值得放进自己的工作流. +https://github.com/jackwu321/Wechat-Fav-Export +https://aichuhai.dev/ +https://github.com/Gloridust/WechatOnCloud +https://github.com/limin112/wechat-publish-template +https://github.com/extrastu/readneo +https://down.mptext.top +https://github.com/zjp1997720/wechat-article-search +https://github.com/wuchubuzai2018/expert-skills-hub +https://github.com/wuchubuzai2018/expert-skills-hub/blob/main/skills/wechat-article-search/SKILL.md +https://www.md2wechat.cn/features 内容表达系统, Agent 公众号创作与发布 CLI, 把 Markdown 排版成公众号草稿. md2wechat 覆盖微信 Markdown 编辑器、公众号排版、主题模块、封面配图、标题建议、API 转换和 md2wechat Skill, 帮助人和 Agent 稳定完成公众号发布流程. +https://mpbook.geekeditor.com, 公号书 MPBOOK, 把关注的公众号, 装进一座私人书房. + + +====雷达=== +https://github.com/Thysrael/Horizon +https://github.com/sansan0/TrendRadar +https://github.com/ourongxing/newsnow +https://sopilot.net/zh/hot-tweets +https://github.com/zarazhangrui/follow-builders +https://rebang.open2hub.com +https://ithome.com +1、今日热榜(类目最全) +常规平台都有, 更狠的是 GitHub Trending、Product Hunt、Hacker News 全给你聚合了——技术圈和产品圈的风向标, 一个顶十个. +https://tophub.today/c/tech +2、AI 今日热榜 +只盯 AI 圈, GitHub Trend、Product Hunt、HuggingFace 热门、OpenAI、Anthropic……做 AI 内容的每天必扫一遍. +https://aihot.today +3、SoPilot(X 爆帖专用) +只看 X 上真正爆了的推文, 抢前排评论、快速捕捉舆论风向全靠它. +https://sopilot.net/zh/hot-tweets +国外补充: Reddit / Hacker News 热门内容汉化版 +https://buzzing.cc +国外多平台聚合, 类似今日热榜的模式, 刷英文信息源用: +https://techurls.com +https://devurls.com +AttentionVC: 同时收录中英文爆火 X 热点和 github 热点, 追上英推的前沿热点 +https://attentionvc.ai +AI 论文简报: 不看最新的重量级论文怎能了解 AI 近况, AI 论文简报每天三分钟, 跟上学术圈最新突破！ +https://ai-brief.liziran.com/zh/ +中国独立开发产品合集: 一个每天更新的 github 仓库, 将国内独立开发产品一网打尽, 看看大家都在做什么, 模仿是通往成功最高效的路径. +https://github.com/1c7/chinese-independent-developer?tab=readme-ov-file +https://github.com/leiting-eric/DailyBrief +https://www.reddtrends.com/ +https://github.com/Pls-1q43/Dibao +https://news.mksaas.link +https://mkdollar.com/news +https://github.com/YD4223/aihub +https://aihot.virxact.com/ 数字生命卡兹克 @Khazix0918 的作品 +https://news.stormzhang.ai/ +https://liziran.com/zh/column/ 博客标题鼠标悬浮上去, 有封面, 挺好玩的. +https://best.xiaohu.ai/ AI 圈最新的东西, 用大白话讲透 +https://github.com/JaredYe04/news-bot +https://youtube.qiaomu.ai/ + +===论坛=== +https://x.com/wsl8297/status/2061001992752034140 +https://x.com/cxjwin/status/2056028025721090538 +[2026/06/16, Ren @FakeMaidenMaker, AI 内容创作的地基: 信息源(以 AI、投资、设计三个领域为例)](https://x.com/Ryrenz/status/2066724310929088601) +https://startup-radar-site.vercel.app/ 分享一个创业阅读网站, 是我做来消耗碎片时间的. 本来也没期望自己会常看, 一阵子后我发现自己还挺爱读的, 经常会打开看一看. 挺有助于创业者随机地去了解一下新的或热门的创业方向, 或了解下现在市场上有什么有意思的初创公司. 它选的文章也挺经典的. + +===科研=== +https://github.com/dw-dengwei/daily-arXiv-ai-enhanced +https://github.com/JOYCEQL/magic-resume +Palantir +https://github.com/hxdflying/paperbanana +https://totoro-jam.github.io/battle-tested-patterns/zh/ +[2026/06/14, paperpaper @paperpaper886, 最近在带入组的本科实习生, 发现怎么读论文其实是科研训练里最容易被忽略的一步. ](https://x.com/paperpaper886/status/2066148829439861016) +https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPaper.pdf +[2026/06/19, 黄小木 @ai_xiaomu, 写论文用这个工具: zgpaper, 省掉80%的废话时间: ](https://x.com/ai_xiaomu/status/2067926365412774011) +arXiv 生态系统里有一批非常好用的第三方工具, 每个解决一个特定痛点. +Semantic Scholar, 地址: http://semanticscholar.org, Semantic Scholar 对 arXiv 论文做了语义索引, 它的"Related Papers"功能比 arXiv 原生的好用得多. 输入一篇你觉得重要的论文, 它能找到内容真正相关(而不只是关键词匹配)的其他论文. 它还提供影响力指标——"Highly Influential Citations"只统计那些实质性引用了这篇论文的后续工作, 过滤掉了"Related Work 里随手一提"的水引用. +Connected Papers, 地址: http://connectedpapers.com, 输入一篇论文, 它会生成一张可视化的关联图谱. 节点是论文, 边表示相似度. 你能一眼看出一个研究方向的脉络——哪些是开创性工作, 哪些是最新进展, 哪些是连接不同方向的桥梁论文. 最适合的场景: 你刚进入一个新领域, 需要快速建立全景认知. +Papers With Code, 地址: http://paperswithcode.com, 这个工具的核心价值是把论文和代码实现对应起来. 看到一篇论文, 直接跳到它的 GitHub 仓库看实现. 它还维护了各个 benchmark 的排行榜(State-of-the-Art), 你能看到每个任务上当前最好的方法是什么. +ar5iv, 地址: http://ar5iv.labs.arxiv.org, 把 arXiv 论文的 LaTeX 源码渲染成 HTML 页面. 阅读体验比 PDF 好很多, 尤其在手机上. 用法很简单——把论文 URL 里的 http://arxiv.org 换成 http://ar5iv.labs.arxiv.org 就行. +Hugging Face Daily Papers, 地址: http://huggingface.co/papers, Hugging Face 社区每天投票选出最值得关注的 AI 论文. 如果你不想自己筛选, 这是一个高质量的"人肉过滤器". + + +===配色=== +https://github.com/nevertoday/zhongguo-traditional-colors +https://colorhunt.co +https://javii.tools, 它的功能很简单: 上传一张图片或一段视频, 输出由ASCII字符组成的画面. 每个像素点被替换成一个字符, 字符的密度和形状模拟原图的明暗和轮廓. + + +===求职=== +https://github.com/yuanzhongqiao/ai-interview-platform +https://github.com/vasu-devs/JustHireMe + + +===内核=== +https://github.com/tamnd/kernel-index +https://github.com/withesse/linux-kernel-analysis + + +https://www.llm-book.com/ +https://github.com/handsOnLLM/Hands-On-Large-Language-Models +https://github.com/Feather-2/Burner-X + +[无颜 @WY_mask, 突然注意到还分享了100多个开源的aiAgent项目](https://x.com/WY_mask/status/2053428837015343286) + + +obsidian +notebook navigator 插件 +https://docs.ollama.com/integrations/claude-desktop +https://github.com/danielrosehill/Awesome-Obsidian-AI-Tools +阅迹 Pro +bijitongbu.site + +===浏览器插件=== +https://x.com/Jolyne_AI/status/2071820285645586718 +https://github.com/027xiguapi/code-box 免登录复制代码: 不用扫码, 不用登录, 看到代码直接一键拿走. 强解关注限制: 什么“关注博主阅读全文”, 统统强制解锁, 懂的都懂. 一键文章扒站: 直接把整篇文章下载成 Markdown 或 HTML, 本地囤货爽翻. 流氓弹窗杀手: 恶心的登录弹窗、强制跳转 APP 提示, 全部干碎. +https://github.com/scriptscat/scriptcat, 在 GitHub 挖到一款比油猴(Tampermonkey)更狠的浏览器脚本插件: ScriptCat. 油猴脚本完全兼容不说, 最大杀手锏是支持后台脚本: 网页关了也照跑. 再加上云同步和脚本订阅, 从安装到管理一条龙, 脚本控直接省心. + +===爬虫=== +https://github.com/D4Vinci/Scrapling +https://github.com/withoneai/cli +https://github.com/jackwener/wx-cli +https://github.com/machinepulse-ai/world2agent +https://github.com/unclecode/crawl4ai +jina.ai/reader/ +markdowndown.vercel.app +https://youmind.com/zh-CN/landing/markdown-to-x-article +https://github.com/NanmiCoder/MediaCrawler 深度优化的爬虫工具 || 省时省心; 一个功能强大的多平台自媒体数据采集工具, 支持小红书、音、快手、B站、抖音微博、贴吧、知乎等主流平台的公开信息抓取. +https://github.com/miantiao-me/ssh-ai-chat, 813 +https://github.com/raiyanyahya/kit +https://github.com/1broseidon/ketch, ketch, 一个命令行工具, 集成了网页搜索、代码搜索、文档查询和网页抓取等功能. + + +电子书 +https://github.com/jbiaojerry/ebook-treasure-chest +https://github.com/bookorbit/bookorbit +https://github.com/LiuMengxuan04/shushu-internship-tool +https://lizabethli.github.io/markdown-to-wechat-converter/ +https://md.doocs.org/ +https://github.com/freeCodeCamp/freeCodeCamp 我的天神爷, 发现一个全球最硬核的免费编程大学, 新手转行找工作必备……😮 +https://github.com/TapXWorld/ChinaTextbook +https://github.com/jbiaojerry/ebook-treasure-chest +https://github.com/BryanHoo/FeedFuse + +bun update -g opencode-ai +opencode models --refresh +cd ~/.config/opencode && bun update oh-my-openagent + + +当前 opencode 有如下模型可用 +opencode models --refresh +opencode/big-pickle +opencode/gpt-5-nano +opencode/minimax-m2.5-free +opencode/nemotron-3-super-free +ZhiPuGLM-CGS/GLM-5 +ZhiPuGLM-CJ/GLM-5 + +帮我配置下 oh-my-openagent +配置文件在 ~/.config/opencode/oh-my-openagent.jsonc + + +解析当前仓库的整体架构, 输出"系统架构图 — Claude 官方风格" 输出路径: diagrams/v4/architecture.png 和 diagrams/v4/architecture.svg + + + + +阅读 plugin/TODO_PROMPT.md, 完成对应的工作 + + + +opencode 有如下模型可用, 帮我配置 oh-my-opencode-slim 插件中 OpenCode-Free preset +配置文件在 ~/.config/opencode/oh-my-opencode-slim.jsonc +OpenCode-Free preset 可用模型如下: + +opencode/big-pickle +opencode/deepseek-v4-flash-free +opencode/laguna-s-2.1-free +opencode/ling-3.0-flash-free +opencode/mimo-v2.5-free +opencode/nemotron-3-ultra-free +opencode/north-mini-code-free + +1. 配置 oh-my-opencode-slim 的各个 agent 为合适的模型 +2. 其中 opencode/big-pickle 模型是大概率不会失效的，将其加入到 fallback 序列 + +各模型的能力优先级 + +deepseek-v4-flash-free > laguna-s-2.1-free > ling-3.0-flash-free > big-pickle > mimo-v2.5-free > nemotron-3-ultra-free > north-mini-code-free + + + + + + +生成整个仓库的整体架构图, 以及各个子 AGENT 的架构图. + + + +1. 你已经实现了好多次, 但是我都不满意, 请参考 diagrams/kde-overview.html 的样式, 这个是我最满意的样式和架构 +2. HTML 格式即可. 保存在 diagrams 目录下. + + + + + + +参考 diagrams/kde-overview.html 生成整个仓库的动态架构图. 输出 GIF、PNG 和 Excalidraw. 放到 diagrams 目录下 +我 diagrams 目录下的各个图标有点乱, 请帮我创建子目录, 按照各 agent 划分子目录 + + + + + + + +《AI 时代的编码新范式》. 全系列共 9 篇, 基于 43 篇行业文献、学术论文与一线实践报告, 探讨 Spec-Driven Development 如何在 AI Agent 时代从边缘实践变为工程的基础设施. 每篇可独立阅读. +[2026/07/02, SagaSu @sujingshen, #01-Vibe Coding 的尽头是规划先行](https://www.sagasu.art/p/vibe-coding-end-is-planning-first) + + + + + + + + + +1. 详细分析下论文 https://arxiv.org/abs/2607.25076 +2. 论文下载到 ./arxiv/2607.25076/paper +2. 将分析结果保存在 ./arxiv/2607.25076/paper-analyzer +3. 按照 storytelling, academic, concise风格分别输出 +4. 需要配图, 建议优先使用论文中的图, 并结合配图进行分析讲解 + + + +1. 详细分析下论文 https://dl.acm.org/doi/10.1145/3636534.3649391 +2. 论文下载到 ./doi/10.1145_3636534.3649391/paper +2. 将分析结果保存在 ./arxiv/10.1145_3636534.3649391/paper-analyzer +3. 按照 storytelling 和 academic 风格分别输出 +4. 需要配图, 建议优先使用论文中的图, 并结合配图进行分解 + + + +公众号中有很多 [Understanding LLMs from Scratch Using Middle School Math](https://towardsdatascience.com/understanding-llms-from-scratch-using-middle-school-math-e602d27ec876) 的分析和翻译。 +1. 查找下所有相关相关的文章和技术分享，将文章保存到 wechat/Understanding-LLMs。标题不限于：初中数学/中学数学 理解 LLM 之类的。 +2. 我自己也列了一些文章，这些文档如果没在搜索的列表中的话，帮我加进去 + +3. 分析下这些文章，看下哪个文章讲的最好。 + + +当前目录下有 omlx 和 mlx 的源代码。 +1. 帮忙分析下 omlx 在 KVCache 以及长序列下有没有什么优化 +2. 将分析结果保存到 docs 目录下 + + + +分别生成 MLX 和 oMLX 格式 + + + +[`yizhiyanhua-ai/fireworks-tech-graph`](https://github.com/yizhiyanhua-ai/fireworks-tech-graph) +[`architecture-diagram`](https://skills.sh/cocoon-ai/architecture-diagram-generator/architecture-diagram) + +当前目录下有 omlx 和 mlx 的源代码。 +1. 整体架构分析 +1.1. 分析 mlx 和 oMLX 的源代码，分别输出 mlx 和 oMLX 的设计架构，保存到 docs 目录下 +1.2 使用 architecture-diagram skills 分别生成 mlx 和 oMLX 的架构图，保存成 html 格式，保存到 diagrams 目录下即可 +2. 再重点分析下两个框架在量化/KVCache/长序列等方向有没有什么优化 +2.1 针对两个框架分别输出详细的分析报告，保存到 docs 目录下。 +2.2 再分析下两个模块在这些方向上如何协作，结合前面的几份报告和架构图，输出一份整体的分析报告，保存到 docs 目录下 + + +当前目录下有 omlx 和 mlx 的源代码。 +docs 目录下有 omlx 和 mlx 的架构文档和相关技术的分析文档，请生成一个 PPT +1. 详细介绍下 omlx 和 mlx 的整体架构，以及之间的协作关系 +2. 针对两个框架量化/KVCache/长序列等方向的优化，详细展开下 + + +[2025/11/12, 微信公众号--林间有风, 白话Transformer（上）](https://mp.weixin.qq.com/s/vqvr-1YVn9mIW2ZOdvfTDQ) + + +[2026/01/08, 微信公众号--戴戴向前冲, 如何只用初中数学讲清楚大语言的原理](https://mp.weixin.qq.com/s/o30u71WGGgLvVIOvs-9hIw) +[2024/11/30, 微信公众号--中国指挥与控制学会, CICC科普栏目｜用初中数学理解LLM工作原理](https://mp.weixin.qq.com/s/8BkNM2F0SYDJ4HPyk-ulHA) +[2025/03/20, 微信公众号--数科纵横, 《使用中学数学从头开始理解LLM》](https://mp.weixin.qq.com/s/HjgOPRkbVFVBHJ4YKHzB9A) +[2024/01/01, 微信公众号--AINLPer, 揭秘 Transformer 的数学原理](https://mp.weixin.qq.com/s/qVZqwpD7ngdSX-UzIj68hw) +[2025/01/05, 微信公众号--林锵锵, 使用初中数学从零开始理解 LLMs](https://mp.weixin.qq.com/s/OEfhumiSYgLP5Tlmni-Rfw) +[2025/09/05, 微信公众号--Ai学习的老章, 用初中数学从零理解大模型](https://mp.weixin.qq.com/s/PMJX7w_4-EPAjPUo9h0wHQ) +[2026/05/04, 微信公众号--AI大模型应用实践, 中学生就能看懂：从零开始理解LLM内部原理【十四，大结局】｜理解 Transformer 架构](https://mp.weixin.qq.com/s/ixtL65L50QPmtaxRQ57drA) +[2025/09/24, 微信公众号--IRR 实验室, 如何用中学知识理解大模型技术原理](https://mp.weixin.qq.com/s/QyotH4Fw3Ybl72-eGSBnfA) +[2024/11/30, 微信公众号--数学中国, 用初中数学理解LLM工作原理](https://mp.weixin.qq.com/s/vofXHc5UsM2izj_J9CJ16g) +[2025/01/08, 微信公众号--丁师兄大模型, LLM工作原理，很直观很好懂!](https://mp.weixin.qq.com/s/iIZF58iFHXqU15n8_4nEOg) +[2024/12/20, 微信公众号--数据派THU, 独家 | 用初中数学从零开始理解大语言模型(下)](https://mp.weixin.qq.com/s/Jf9TkeXgc5JpVelmvvNZTg) \ No newline at end of file