本文将从外设中断请求（IRQ）如何到达 CPU、CPU 如何决定是否响应中断、Linux 内核如何处理中断以及中断处理完成后如何返回用户态等全过程进行详细解析。通过对 RISC-V 架构的中断机制和 Linux 内核中断处理流程的深入分析，帮助读者理解从外设发出中断请求到 Linux ISR 执行的完整路径。

前面在分析 FlashAttention、Paged KV Cache 和 Paged Attention 时，我一直在研究 Qwen3 推理过程中的局部模块：Attention 是怎么计算的、KV Cache 为什么要保存、Decode 为什么需要分页访问历史 KV。把这些模块单独拆开以后，反而容易丢掉一个更基础的问题：一个输入句子究竟是怎样经过 Qwen3，最后变成下一个 Token 的？

大模型推理里，大家一提优化，最容易先想到的是 FlashAttention、Tensor Core、Kernel Fusion。但在实际的 LLM Serving 场景里，另一个同样关键的问题往往更“系统”一些：

大模型推理中，Attention 的计算优化只是问题的一部分。进入 Decode 阶段以后，另一个越来越重要的问题是：历史 Token 的 Key 和 Value 应该放在哪里，又应该怎样管理？

在大模型推理中，用户输入一段 Prompt 后，模型并不是立即进入逐 Token 生成。完整推理通常可以分成两个阶段：Prefill 和 Decode。

Prefill 一次处理整段 Prompt，拥有较长的 Query 序列，Attention 更接近矩阵乘法；Decode 每一步通常只有一个 Query Token，却需要不断读取增长的历史 KV Cache。两者虽然都在计算 Attention，但计算形态和优化重点完全不同。

CUDA（Compute Unified Device Architecture）是 NVIDIA 推出的并行计算平台和编程模型。它允许程序员使用类似 C/C++ 的语法编写在 GPU 上运行的函数，将同一项计算分配给大量线程并行完成。本文不会只罗列 CUDA API，而是沿着“GPU 硬件 → CUDA 线程模型 → Kernel 调度 → 内存层次 → 基础优化”这条主线，建立一个完整的 CUDA 编程认知。