// genius_challenges.md · AI frontier tasks

真正难的问题，
留给真正想做的人

这不是课程作业。这些是 AI 领域工程师和研究员真正在解决的问题。 你不需要全部做完——找到一个让你停不下来的，然后冲进去。

Lv.1 探索者
Lv.2 构建者
Lv.3 突破者
Lv.4 传说
15个挑战任务
4个难度等级
5个技术方向
∞Token 无限量供给
// track_01

Transformer 架构

从 Attention 到 KV Cache，理解现代大模型的核心机制。读懂这里，你就读懂了 GPT、Claude、LLaMA 的心脏。

Lv.1 · 探索者
Transformer
#C01
Mini-Transformer 从零实现
Build a Character-Level Transformer from Scratch
不用 HuggingFace，不用封装好的 API。用纯 Python + NumPy（或 PyTorch 基础算子）实现一个完整的 Transformer，训练它学会生成中文古诗或代码片段。
必须实现的模块
  • ▸Token Embedding + Positional Encoding（理解为什么需要位置信息）
  • ▸Multi-Head Self-Attention（矩阵乘法手推一遍）
  • ▸Feed-Forward Network + LayerNorm
  • ▸训练循环、损失曲线可视化、采样生成
挑战加成
  • +解释：为什么是 Q·Kᵀ / √d_k？把 √d_k 去掉会发生什么？
  • +可视化不同注意力头在关注什么
⏱ 预计 1–2 周
交付：GitHub + 生成样本
Lv.1 · 探索者
Transformer
#C02
注意力地图解析器
Attention Head Specialization Visualizer
不同的注意力头学到了不同的东西：有的关注语法依存，有的关注实体指代，有的关注标点。用 BertViz 或者自己写提取逻辑，找到这些规律并写报告。
研究问题
  • ▸用 GPT-2 或 LLaMA 提取所有层所有头的注意力权重
  • ▸哪个头专注于"主语→动词"关系？哪个关注代词消解？
  • ▸更深的层 vs 浅层，注意力模式有何不同？
  • ▸剪掉某个头，模型性能下降多少？（注意力头剪枝实验）
⏱ 预计 1 周
交付：可视化报告
Lv.2 · 构建者
KV Cache
#C03
KV Cache 可视化与内存分析
KV Cache Memory Profiler
KV Cache 是让 LLM 推理不慢死的关键——每个 token 生成都需要重用之前所有 token 的 K、V。但它会吃掉大量显存。理解它，然后量化它。
实现任务
  • ▸Hook 进 transformers 库，实时记录 KV Cache 的形状和显存占用
  • ▸画出：随序列长度增长，KV Cache 显存占用曲线
  • ▸对比：有 KV Cache vs 无 KV Cache 的推理速度（latency per token）
  • ▸计算：一个 7B 模型，4096 上下文，KV Cache 需要多少 GB？推导公式
核心公式推导
KV_memory = 2 × n_layers × n_heads × d_head × seq_len × dtype_bytes
// 推导这个公式，然后用真实模型验证它
⏱ 预计 1–2 周
交付：分析报告 + 可视化
Lv.2 · 构建者
Attention
#C04
GQA vs MHA：缩减 KV Cache 的代价
Grouped Query Attention vs Multi-Head Attention
LLaMA-2 用了 GQA，把 KV head 数量从 32 降到 8，KV Cache 缩小 4×。但质量下降了多少？实现两种注意力机制，做严格的对比实验。
实验设计
  • ▸实现 MHA（32 heads）和 GQA（groups=1,2,4,8,32），代码可互换
  • ▸在小规模语言模型上训练，对比 perplexity、推理速度、显存
  • ▸画出：KV groups 数量 vs 质量 vs 速度 的三维权衡图
  • ▸复现 GQA 论文中的 scaling law 曲线（部分）
⏱ 预计 2–3 周
交付：实验报告 + 代码
// track_02

推理优化

让模型跑得更快、更省显存，同时不（太）损失质量。Speculative Decoding、量化、Paged Attention——这些技术让 ChatGPT 能服务百万用户。

Lv.2 · 构建者
推理优化
#C05
Speculative Decoding 实现与分析
Speculative Decoding: Draft + Verify
大模型生成很慢，因为每次只能生成一个 token。Speculative Decoding 用小模型（draft）先猜 k 个 token，再用大模型（verifier）一次性验证。对的就用，错的就丢——平均加速 2-3×。
实现任务
  • ▸实现 speculative decoding 的验证接受/拒绝逻辑（论文 Algorithm 1）
  • ▸测量：token 接受率（acceptance rate）随 draft 模型大小的变化
  • ▸测量：端到端 latency，与 greedy decoding 对比
  • ▸探索：如果 draft 和 target 模型的词表不一样怎么办？
关键问题
  • ?什么类型的任务接受率最高？（重复性文本 vs 创意写作）
  • ?k 设成多少最优？存在 optimal k 吗？
⏱ 预计 2–3 周
交付：代码 + benchmark 数据
Lv.2 · 构建者
量化
#C06
INT8 量化从零实现
Post-Training Quantization: FP32 → INT8
把模型权重从 32位浮点压缩到 8位整数，显存减半，推理加速。但精度会损失。自己实现量化，找到损失的边界。
实现路径
  • ▸实现 per-tensor、per-channel、per-group 三种量化粒度
  • ▸对比：对称量化 vs 非对称量化，精度差异
  • ▸找到"精度悬崖"：量化到什么程度模型开始胡说？
  • ▸尝试混合精度：只量化权重，激活保持 FP16
挑战加成（Lv.3 方向）
  • +实现 GPTQ（基于 Hessian 的逐层量化），对比 naive 量化
  • +为什么 outlier 激活值会破坏量化？LLM.int8() 怎么解决这个问题？
⏱ 预计 2 周
交付：量化库 + 精度报告
Lv.3 · 突破者
KV Cache
#C07
KV Cache 驱逐策略设计
KV Cache Eviction Policy: Beyond H2O
当上下文超过显存限制，必须丢弃一些 KV。H2O 丢低注意力分数的，StreamingLLM 只保留最近的。但这两种都是事后策略。 你能设计一个预测性的驱逐策略吗？
研究问题（没有标准答案）
  • ?哪些 token 的 KV 是"必须保留"的？能在需要它之前就预测到吗？
  • ?不同任务（推理题 vs 对话 vs 代码）的最优保留策略一样吗？
  • ?能训练一个小模型来预测"这个 KV 还会被 attend 到"吗？
交付要求
  • ▸实现至少一种新驱逐策略
  • ▸在 RULER 或 LongBench 上对比 H2O 和 StreamingLLM
  • ▸写清楚：你的策略在什么情况下比现有方法好，在什么情况下更差
⏱ 预计 3–5 周
交付：论文草稿水平
Lv.3 · 突破者
Attention
#C08
稀疏注意力：为任务设计 Attention 模式
Task-Specific Sparse Attention Patterns
全注意力是 O(n²)——序列长度翻倍，计算量翻四倍。Longformer 用了滑动窗口，BigBird 用了随机稀疏。但这些是通用的。 如果你针对一个特定任务设计稀疏模式，能做得更好吗？
选择一个领域，设计专属稀疏模式
  • ▸代码生成：函数调用关系需要 attention，注释可以稀疏
  • ▸数学推理：每一步需要 attend 到前面的推导链
  • ▸结构化文档：章节标题需要全局 attention，正文可以局部
评估
  • ▸质量：在该任务上 vs 全注意力，perplexity / task accuracy
  • ▸速度：实际 FLOPs 减少量，实测 wall-clock time
⏱ 预计 3–4 周
交付：实验报告 + 代码
// track_03

Agent Memory

Agent 如何记忆？如何从海量过去经验中检索有用信息？如何在多 Agent 之间共享和同步记忆？这是 AI 从工具变成"伙伴"的核心问题。

Lv.1 · 探索者
RAG
#C09
RAG 记忆系统：从零到能用
Build a Long-Term Memory System for an AI Agent
不用 LangChain，不用 LlamaIndex。用 Python + 向量数据库（FAISS 或 Chroma），给一个 AI Agent 装上长期记忆，让它能记住几十次对话前你说过的事。
实现任务
  • ▸文本 → Embedding → 向量存储（FAISS）
  • ▸用户提问 → 向量检索 → 注入上下文 → 回答
  • ▸解决记忆冲突：Agent 记住了"我喜欢猫"，又记住了"我不喜欢猫"，怎么办？
  • ▸记忆老化：旧的记忆应该比新的权重低吗？怎么实现？
⏱ 预计 1–2 周
交付：可运行系统
Lv.2 · 构建者
Memory
#C10
Agent 记忆压缩
Hierarchical Memory Compression for Long Agents
长对话的 Agent 会撑爆 context window。简单截断会丢失重要信息。设计一个分层记忆压缩系统：工作记忆（当前）→ 短期记忆（自动摘要）→ 长期记忆（向量检索）。
核心设计问题
  • ?什么信息值得压缩保留，什么可以丢弃？（重要性评分怎么做）
  • ?压缩后的记忆 vs 原始记忆，信息损失有多少？怎么量化？
  • ?何时触发从短期到长期的记忆转移？
评估指标
  • ▸在 100 轮对话后，Agent 能回答多少早期对话的问题？
  • ▸对比 naive 截断：信息保留率 vs context 使用效率
⏱ 预计 2–3 周
交付：系统 + 评估报告
Lv.3 · 突破者
Multi-Agent
#C11
多 Agent 记忆共享协议
Distributed Memory Consistency for Multi-Agent Systems
多个 Agent 同时工作、共享记忆——但如果两个 Agent 同时写入冲突的信息怎么办？这是分布式系统中的经典问题（CAP 理论），在 AI Agent 里有了新的变体。
设计挑战
  • ▸设计一套 Agent 记忆写入/读取协议（参考 CRDT 或 Operational Transformation）
  • ▸当 Agent A 认为"客户偏好X"，Agent B 认为"客户偏好Y"，如何合并？
  • ▸实现冲突检测 + 仲裁机制（谁的记忆更可信？依据是什么？）
  • ▸压力测试：10 个 Agent 并发写入，记忆一致性能保证吗？
⏱ 预计 4–6 周
交付：协议设计文档 + 实现
Lv.2 · 构建者
Fine-tuning
#C12
LoRA 从零实现 + 变体探索
Low-Rank Adaptation: Implementation & Variants
LoRA 是当前最主流的大模型微调方法：冻结原始权重，只训练低秩矩阵，参数量减少 99%。自己实现它，然后问：rank 应该怎么选？能不能自适应？
实现路径
  • ▸实现 LoRA 层（W → W₀ + BA，B初始化为0，A随机初始化）
  • ▸在 GPT-2 上微调一个特定风格的文本生成任务
  • ▸实验：rank=1,2,4,8,16,64，质量 vs 参数量曲线
  • ▸尝试 AdaLoRA：rank 在训练中自动调整（根据奇异值重要性）
思考题
  • ?为什么只加在 Q、V 矩阵上，而不是全部权重？
  • ?LoRA 合并回原始权重后，推理速度和原始模型一样吗？
⏱ 预计 2 周
交付：代码 + 实验报告
// track_04

推理时计算缩放

o1、DeepSeek-R1 告诉我们：让模型"多想一会儿"，它会更聪明。但多思考多少才够？什么问题值得多思考？这些是现在最热的研究方向。

Lv.2 · 构建者
推理缩放
#C13
思考 Token 的边际收益实验
Test-Time Compute Scaling: Where Does Thinking Stop Helping?
给模型更多 token 思考，它会更准确——但到什么时候停止有帮助？设计一组实验，找到"思考 token 数量 vs 准确率"的缩放曲线。
实验设计
  • ▸任务：数学题（AMC/AIME）、代码调试、逻辑推理
  • ▸控制变量：强制模型在 N tokens 内给出答案（N = 100,500,1000,5000）
  • ▸画出：每类任务的 accuracy vs thinking tokens 曲线
  • ▸找到"拐点"：超过多少 token 之后准确率不再提升？甚至下降？
更深的问题
  • ?模型是"真的在想"还是在"填充文字"？怎么区分？
  • ?给定固定的 compute budget，是跑 1 次长思考 vs 跑 N 次短思考再投票，哪个更好？
⏱ 预计 2–3 周
交付：实验数据 + 分析
Lv.3 · 突破者
推理缩放
#C14
难度自适应计算分配
Difficulty-Adaptive Compute Allocation for Reasoning
简单的问题不需要想很久。复杂的问题需要更多 token。能不能在回答之前，先预测这道题的难度，然后动态分配计算资源？
核心设计
  • ▸训练一个难度预测器（或用启发式方法）：看问题 → 预测需要多少 thinking tokens
  • ▸实现 early stopping：如果模型"已经确定了"（低熵），提前结束思考
  • ▸对比 fixed budget vs adaptive budget，相同平均计算量下的准确率
挑战
  • ?模型对自己的难度判断可靠吗？什么类型的题容易判断错？
  • ?过度自信的模型会在简单题上思考不够，从而出错——怎么检测和防止？
⏱ 预计 4 周
交付：系统 + 论文草稿
// track_05 · legendary_only

⚡ 传说挑战

这些挑战没有参考答案，也没有已知的最优解。完成任何一个，就已经接近研究员水平。

Lv.4 · 传说
Systems
#C15
Flash Attention Triton 实现
Implement Flash Attention from Scratch in Triton/CUDA
Flash Attention 是近五年对 Transformer 效率影响最大的工作之一。它把注意力计算改写成 IO-aware 的形式：通过分块计算，避免把整个注意力矩阵写入 HBM，让显存带宽不再是瓶颈。 用 Triton（OpenAI 开源的 GPU kernel 语言）实现它。
学习路径（必须按顺序）
  • 1GPU 内存层次：HBM vs SRAM，带宽差距有多大？为什么 IO 是瓶颈？
  • 2Naive 注意力的 IO 分析：读写了多少次 HBM？
  • 3Flash Attention 算法（Dao et al.）：分块 + online softmax 的数学推导
  • 4用 Triton 实现 forward pass，对比 PyTorch naive 实现的速度和显存
  • 5（挑战加成）实现 backward pass（反向传播）
成功标准
  • ▸在长序列（4096+）上，显存占用接近 O(n) 而不是 O(n²)
  • ▸数值结果与 PyTorch naive 实现一致（误差 < 1e-3）
  • ▸能解释：为什么 online softmax 在数值上是稳定的？
⏱ 预计 6–10 周（真的很难）
交付：可运行 Triton kernel + 性能报告
// required_reading.papers

必读论文

不用都读懂。但每做一个挑战，先把对应的论文读一遍——哪怕只读 Abstract 和 Introduction。

Attention · 2017
Attention Is All You Need
所有 Transformer 的起点。读完你就知道 Q/K/V 是怎么来的。
arxiv.org/abs/1706.03762 →
Flash Attention · 2022
FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness
做挑战 #C15 的核心论文。理解 IO-aware 算法设计思维。
arxiv.org/abs/2205.14135 →
GQA · 2023
GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints
做挑战 #C04 的论文。LLaMA-2/3 用的技术。
arxiv.org/abs/2305.13245 →
Speculative Decoding · 2022
Fast Inference from Transformers via Speculative Decoding
做挑战 #C05 的论文。Google 的推理加速方法，现在是标配。
arxiv.org/abs/2211.17192 →
KV Cache Eviction · 2023
H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models
做挑战 #C07 的起点。理解 KV 驱逐的现有方法。
arxiv.org/abs/2306.14048 →
LoRA · 2021
LoRA: Low-Rank Adaptation of Large Language Models
做挑战 #C12 的论文。最广泛使用的微调方法，原理极简但效果出众。
arxiv.org/abs/2106.09685 →
MemGPT · 2023
MemGPT: Towards LLMs as Operating Systems
做挑战 #C10 的参考。把 Agent 的记忆管理类比成操作系统内存层次。
arxiv.org/abs/2310.08560 →
Test-Time Compute · 2024
Scaling LLM Test-Time Compute Optimally
做挑战 #C13/#C14 的核心论文。Deepmind 的工作，证明了推理时计算缩放定律。
arxiv.org/abs/2408.03314 →
Quantization · 2022
LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale
做挑战 #C06 后的进阶读物。解决了量化中的 outlier 问题。
arxiv.org/abs/2208.07339 →

找到你停不下来的那个问题

不需要全部做完。找到一个让你着迷的挑战，进去，冲到你能冲到的最深处。

了解 Project School →