推理在YC投资中的核心地位与成本瓶颈
在Y Combinator的投资视野中，推理（Inference） 是一个被高度重视的领域。过去十年间，专注于推理优化的公司创造了高达 2200亿美元 的市场市值。演讲者曾运营一家AI公司，深刻体会到推理往往是业务扩展中的最大瓶颈。难以在大规模下高效执行推理且不导致销售成本（COGS）失控，是行业公认的挑战。 尽管训练模型备受瞩目，但推理的经济性和效率直接决定了模型的商业可持续性。演讲者提到：“Inference was always the bottleneck. It's so hard to do inference well at scale and without losing your shirt on cost of goods sold.” 这种对成本结构的敏感度，使得推理优化成为评估AI初创公司潜力的关键指标。
训练FLOPs与推理FLOPs的12倍差异分析
理解推理重要性的最佳视角是比较训练算力（Train FLOPs）与推理算力（Inference FLOPs）。以DeepSeek V3为例，其训练消耗了约 280万 H1/H800小时。尽管这是旧数据，且当前实际消耗可能更高，但DeepSeek每天约处理 43,000 H800小时的推理负载。基于这些数据，仅按年度计算，该权重文件的推理FLOPs就是训练FLOPs的 6倍。如果假设模型权重的有效生命周期为2年，那么推理的重要性将是训练的 12倍。随着用户基数扩大和AI普及，这一比例还会进一步上升。因此，在评估模型选择（如Nerf论文中的对比）时，不应仅关注最小化训练FLOPs，而应将 12倍于训练的权重赋予推理FLOPs 的考量。目前多数研究（如Chinchilla论文）仍以训练FLOPs为横轴，行业亟需转向关注 ISO推理FLOPs。
高利润率背后的推理创新与KV缓存策略
DeepSeek高达 80% 的毛利率，主要归功于其在推理侧的创新。实现这一效率的关键在于复杂的缓存机制和KV Cache保留策略。系统并非简单调用 model.forward，而是需要精细管理提示词（Prompt）的处理流程。对于已缓存的输入部分，系统应避免重复运行预填充（Prefill），而是利用 LRU缓存、DRAM或Redis/SSD中的热数据。DeepSeek通过保留用户 72小时 的KV Cache，实现了极高的缓存命中率。数据显示，其输入缓存命中率达到 96%。这种策略在Agent场景中效果显著，但在用户频繁开启全新对话（如询问天气等无上下文问题）时，由于缺乏KV Cache支持，预填充必须反复执行，导致性能大幅下降。这种对缓存命中率的极致追求，是降低推理成本的核心手段。
硬件利用率低下与解码阶段的性能瓶颈
尽管GPU厂商承诺极高的理论算力（如Jensen Huang提到的 2万亿 FP8 FLOPs），但实际模型FLOP利用率（MFU）远低于此。在训练和预填充阶段，MFU可能仅为 50%；而在解码（Decode）阶段，利用率更是低至约 5%。这种巨大的效率落差使得推理成为真正的性能瓶颈。关键KPI包括：首字延迟（Time to First Token）、每输出令牌时间、吞吐量以及Good Put。DeepSeek的数据显示，排除缓存命中时，GPU预填充吞吐量为 60,000 令牌/秒；但在包含缓存命中时，吞吐量飙升至 1.5百万 令牌/秒。相比之下，解码阶段的GPU吞吐量仅为 14,000 令牌/秒。首字延迟平均约为 400毫秒，P99延迟为 1秒。预填充与解码吞吐量从 150万 到 1.4万 的巨大反差，凸显了当前芯片创新主要集中在加速解码阶段的原因。此外，算术强度（Arithmetic Intensity）也是关键指标，即从DRAM传输少量数据时能执行多少计算，这在推理中因频繁访问权重而变得尤为复杂。
推理效率的核心瓶颈：算术强度与带宽利用率
在大型语言模型（LLM）的部署中，推理阶段的性能表现往往比训练阶段更为关键且复杂。与图像模型不同，LLM 的算术强度（Arithmetic Intensity）较差，这意味着计算单元无法持续满载。演讲者 Volo 指出这一特性是扩散模型和 LLM 面临的共同挑战，而新一代的 Next Concept Model 则通过更高的算术强度试图改善这一状况。评估推理效率时，必须关注两个核心指标：模型浮点运算利用率（MFU）和模型带宽利用率。当用户购买 H100 显卡时，厂商宣称其拥有 2万亿 FP8 FLOPS的峰值算力，但在实际推理测试时，用户获得的性能通常远低于此数值，MFU 正是衡量这一差距的关键指标。同时，模型带宽利用率反映了在拥有 1TB/s 内存带宽等硬件条件下，实际在测试时平均能获取到的数据吞吐量。为了理解理论极限，业界采用Roofline 分析模型，即取芯片峰值 FLOPS 与内存带宽乘以 FLOPS 之间的最小值作为性能上限。这种分析框架揭示了硬件资源在推理阶段的实际转化效率。
模型层面的创新：稀疏化与量化压缩
为了突破推理瓶颈，研究人员在模型架构层面提出了多种创新方案。首先是混合专家模型（MoE），通过引入 K 个专家网络，可以将测试时的 FLOPS 开销分摊到所有专家上，从而将单次推理的计算量降低至原来的 1/K。其次是状态空间模型（SSM），它允许在某些层跳过完整的注意力机制计算，例如仅在每第五或第十层执行全量注意力操作，从而显著减少推理所需的总计算量。此外，多头潜在注意力（Multi-headed latent attention）通过在序列维度上进行压缩来降低 FLOPS。在模型轻量化方面，量化技术（Quantization）已将模型精度压缩至低至 2字节。同时，通过从大型复杂模型中进行知识蒸馏（Distillation），可以生成体积更小但性能相当的小型模型，从而降低服务成本。这些创新共同构成了提升推理效率的第一道防线。
内核与运行时优化：借鉴数据库理论
除了模型结构的改进，内核和运行时的创新同样至关重要。Radix Attention、Flash Attention 以及 Page Attention 等技术，其核心思想借鉴了经典操作系统和数据库理论。正如演讲者所言："> If you have taken intro databases, where how do you make a production database really fast?"。Radix Attention 类似于数据库中的前缀树或基数树结构；Flash Attention 由 TriDao 提出，利用 GPU Tiling（分块）技术极大提升了效率；而 Page Attention 则引入了虚拟内存分页和缓冲区池的概念，允许数据在 DRAM 中进行高效交换。这些技术通过优化内存访问模式和计算调度，显著提升了 GPU 的实际利用率。
推理服务编排与未来展望
在更高层级的Harness（框架/引擎）创新中，路由策略成为关键。例如在 Focal 项目中采用的智能路由机制："> Not everything should go to the big gory model"。通过水瀑布式调用或工具调用，将简单任务分流至小模型，复杂任务才交由大模型，从而节省大量 FLOPS。推测解码（Speculative Decoding）利用草稿模型进行验证，进一步加速生成过程。演讲者特别推崇递归语言模型（Recursive Language Model）的理念："> Just let the LLM decide what it needs and when"，即不让完整上下文填满 KV Cache，而是由模型自主决定所需信息，从而大幅减少内存占用。此外，压缩技术（Compaction）如 Cartridges 也是框架的必要组成部分。为了深入理解这些领域，推荐参考 Percy Liang 在 CS336 课程中的讲座以及 Dan Fu、Jeffrey Morgan 等专家的研究。Together AI 的 Dan Fu 随后将详细讲解 Token 从 API 请求到 GPU 内核执行的全生命周期，特别是在开源模型日益普及、流量占比显著提升（如 Together AI 月处理 40万亿 Token，达到 Google Gemini 流量的 1/8）的背景下，如何更高效地生成和服务 Token。
推理在AI原生公司构建中的核心地位
At Together团队致力于探索如何从零开始构建一家AI原生的科技公司。这一过程涵盖了预训练（pre-training）、微调（fine-tuning）以及他们重点关注的推理服务（inference），还包括为智能体提供沙盒环境以进行各种尝试。At Together正在构建能够支持所有这些环节的云平台，并特别专注于优化推理性能。
为了实现这一目标，At Together组建了一支由约80名研究人员（包括众多博士）组成的强大团队。虽然他们过去在多个领域有所建树，但目前的战略重心已明确转向推理优化和GPU性能提升。正如Francois在讨论中提到的，理解不同用户的工作负载特征是优化的前提。团队需要深入分析各种场景下的具体需求：例如，当运行代码生成工作负载时，缓存命中率（cache hit rate）和请求间的延迟至关重要。用户在使用Claude Code、Open Code或Cursor等工具时，需要知道在发出指令后多久能收到响应，以及代码生成的速度是否满足特定的服务等级协议（SLAs）。团队的目标就是针对这些响应速度和完成时间的要求，对各个组件进行精细化优化。
请求路由与KV缓存的协同机制
当一个REST API请求进入系统时，它会经过Cloudflare、DNS等常规互联网基础设施，最终抵达数据中心。面对成千上万块GPU和全球各地的请求，基础请求级路由（request-level routing）成为首要环节。这不仅涉及负载均衡，更关键的是要管理KV缓存（Key-Value Cache）的状态。
在传统数据库或Web服务时代，负载均衡通常采用轮询（round-robin）策略，将流量分配给负载较轻的服务器。但在大语言模型时代，这种简单策略不再适用。如果将相同的请求反复发送到同一块GPU上，性能表现会更好。这是因为在处理如代码库等复杂输入时，首次请求需要处理大量信息并建立缓存；而后续针对同一上下文的请求可以直接利用已驻留在GPU中的KV缓存，无需重复计算。因此，路由策略变成了一门艺术：既要平衡数据中心和GPU间的负载，又要确保请求被发送到KV缓存已驻留的位置。这种策略能显著减少冗余计算，提升整体效率。
标记化中的工具调用复杂性
进入标记化（tokenization）阶段后，系统需要将人类文本转换为模型可处理的二进制数据。这一过程看似简单，实则充满挑战，主要源于请求中常包含的工具调用（tool calls）。用户不仅是在提问，还在指示模型执行特定操作，例如搜索文件系统、运行grep命令构建应用或测试代码，甚至联网查询。
"The model is just some abstract, you know, combination of like mathematical things. It's like a bunch of matmuls and some attention modules."
模型本身仅由矩阵乘法（matmuls）和注意力模块组成，不具备直接搜索互联网或执行命令的能力。因此，系统必须通过复杂的标记化流程，将用户的意图转化为模型可理解的指令列表。例如，用户发送包含10种可用工具的请求后，模型需判断何时调用互联网搜索或文件系统工具。这一过程涉及大量的正确性保障（correctness things），确保模型在生成调用指令时准确无误。正如Jeff将在后续讨论中提到的，从用户端管理这些复杂性需要极高的工程精度，而标记化阶段正是确保工具调用正确工作的关键防线。
调度器循环与预填充/解码阶段
请求进入后，便进入模型的核心调度器循环（core scheduler loop）。多个流式请求在此等待，以便批量处理或分配空闲GPU资源。调度器的决策直接决定了系统的总吞吐量：是优化单位GPU上的用户数量，还是追求极致的响应速度？例如，Google Gemini的首次回复往往极快，而后续对话可能变慢，这背后可能是不同的调度策略甚至后端模型在起作用。
随后进入两个核心阶段：预填充（prefill）和解码（decode）。预填充类似于提示词处理，当输入整个代码库时，模型需深入理解内容并构建上下文。这是一个计算密集型（compute-bound）操作，GPU的算术强度极高，模型利用率（MFU）处于高位。相比之下，解码阶段则是生成单个或少数几个令牌的过程。每次生成一个词，都需要将完整的模型权重从GPU内存加载到计算单元。因此，解码是内存密集型（memory-bound）操作。At Together团队花费大量时间思考如何高效服务这两种截然不同的计算模式，以平衡性能与资源消耗。
推理优化的六大核心维度与架构分离
在大型语言模型的推理阶段，从输入到最终文本流出的过程中存在多个可优化的环节。尽管将 token ID 转换回文本并流式传输给用户相对简单，但在此之前涉及复杂的内存管理决策，例如 KV cache 的释放时机、保留时长以及 token 驻留策略。为了提升整体效率，作者指出存在大约六个关键优化方向：内核（Kernels）、解耦架构选择（Disaggregation choices）、并行策略（Parallelism）、路由机制（Routing），以及针对模型层的 投机解码（Speculative decoding） 和 量化技术（Quantization）。
其中，解耦架构尤为重要，因为预填充（prefill）和解码（decode）是两种截然不同的工作负载。将这两者分配给不同的 GPU 可以显著影响用户体验和总吞吐量。内核本质上是运行在 GPU 上的程序，如注意力机制、MoE（混合专家）或 Mega 内核的优化；并行策略则解决模型过大无法单卡容纳的问题，例如 Chimera K3 这种拥有 1.5 TB（FP4格式下）参数的模型，必须跨越多个 GPU 进行拆分；而 投机解码则是通过一个小模型预演大模型的输出，若预测正确则免费获取 token。鉴于时间限制，本次讨论将聚焦于内核、并行性和量化这三个核心领域。
内核优化：从手工调优到自动化编译器
内核优化的核心在于处理模型前向传播中的数学运算，如矩阵乘法（matmuls）和注意力机制。然而，并非所有操作都同等容易优化。Layer Norms、RMS Norms 和 Softmaxes 等独立操作具有极低的算术强度（arithmetic intensity），单独编写内核会导致 FLOP 利用率极低。历史上，这导致训练时的端到端 FLOP 利用率仅为 50%，而解码阶段更是低至 5%。传统的行业做法是依靠顶尖的内核工程师团队手动挤压和优化这些操作，但这效率低下且难以扩展。
Together AI 近期推出了内部项目 Together Compiler，旨在利用智能体（Agents）自动优化这一核心循环。该项目的核心理念是建立一种 递归自我改进（RSI）循环，驱动优化的关键因素包括目标模型、特定硬件以及 真实流量模式。作者强调：“不同的交通或编码工作负载与聊天工作负载实际上会以非常不同方式激活内核。” 因此，必须基于生产环境中的实际运行数据进行迭代研究。虽然该项目目前被命名为 Together Compiler，但作者意识到它可能并不完全符合传统编译器的定义，未来可能会更名。这种自动化方法试图取代过去依赖人力密集型的内核优化模式。
并行性策略：张量、流水线与数据并行的演进
当模型权重过大无法放入单个 GPU 时，必须将模型拆分到多个 GPU 上以利用更多的计算能力和带宽。常见的并行方案包括：张量并行（Tensor Parallelism），即将矩阵乘法拆分并在末尾进行归约；流水线并行（Pipeline Parallelism），按层将模型切割并分配给不同 GPU；以及 数据并行（Data Parallelism），即向不同 GPU 发送不同的序列但保持模型参数一致。选择哪种方案取决于 GPU 内存大小、内核支持速度以及可用资源。
近年来，一个显著的趋势是利用更大规模的 Up-domain（域内互联）。作者指出：“如果你最近尝试购买 GPU，你应该听说过这些 Blackwell 芯片和 GB 芯片。” 传统 Nvidia 架构中，高带宽互联通常限制在 8 张 GPU 之间。Blackwell 架构打破了这一限制，允许更大规模的集群高效通信。这种硬件层面的扩展能力是推动推理成本降低的关键驱动力之一，例如 DeepSeek V3 每小时 $38 的低推理成本便得益于此类大规模并行架构的优化。通过更高效的互联和并行策略，系统能够处理更大规模的模型并维持高吞吐量。
量化与投机解码：降低存储与计算开销的模型层优化
除了底层内核和系统架构，模型层的优化同样至关重要。量化（Quantization） 关注的是如何减少每个 token 所需的存储位数以及权重的比特数。通过降低精度（如从 FP16/BF16 降至 INT8/FP4），可以显著减少内存占用并提高数据传输效率，从而加速推理过程。这是应对超大模型参数规模（如前述 1.5 TB 模型）的直接手段。
另一种关键技术是 投机解码（Speculative Decoding）。其基本思想是利用一个较小的“草稿模型”并行运行，尝试预判大模型的输出。如果小模型的预测准确，这些 token 就可以被“免费”获取，从而绕过部分大模型的计算开销。这种方法特别适用于那些不需要极高精度即可快速响应的场景（如简单的加法运算）。结合量化技术，投机解码进一步降低了推理延迟。作者提到：“你并不真正需要那个非常大的模型来回答‘一加一等于几’。” 这种分层策略允许系统根据任务复杂度动态调整资源使用，实现效率与精度的最佳平衡。这些模型层优化手段与前文提到的内核、并行性共同构成了现代高效推理系统的基石。
专家并行与硬件带宽的权衡
在模型推理服务中，将模型切分的粒度直接影响系统性能。如果尝试将模型切分为 16 份，数据必须通过带宽较低的路径传输，导致服务速度变得难以忍受。为了解决这一瓶颈，Nvidia 推出了能够以更高带宽连接 72 块 GPU 的机架架构。这种高带宽互联使得一种新的部署策略成为可能：将模型中的各个“专家”（Experts）单独放置在不同的 GPU 上。这种专家并行（Expert Parallelism）策略的核心优势在于，它允许在相同的 GPU 资源上服务更高数量的请求。
这一策略背后的理论基础是算术强度（Arithmetic Intensity）。当单个 GPU 仅服务于一个专家并处理大量 Token 时，计算过程表现为大型矩阵乘法运算，这正是 GPU 架构最擅长的操作类型。尽管专家并行的概念在几年前就已出现并有相关演示，但近期技术团队重点解决了其在生产环境中的可靠性问题。由于硬件故障（如单个 GPU 或节点宕机）是不可避免的，如果缺乏完善的容错机制，单点故障可能导致整个 72 GPU集群的计算能力失效。因此，构建能够优雅应对硬件故障、保持服务连续性的弹性系统成为关键工程挑战。
量化技术的复杂性：从算法到用户体验**
模型量化的核心目标是在保持精度的前提下减少计算资源消耗。通常，大型语言模型使用 BF16（每个参数 2 字节）进行训练。以拥有 3万亿个参数的模型为例，其权重数据量高达 6 TB。然而，机器学习计算具有“模糊性”，并非精确数学运算，因此不需要所有位数的精度即可得出正确结果。理论上，可以通过算法将 16 位压缩至 8 位或 4 位，从而显著提升吞吐量。
尽管量化算法本身看似简单（有数百篇论文可供选择），但在实际工程中却极为复杂，因为它直接触及最终用户体验的质量。技术团队不仅关注硬件层面的吞吐量优化（即每块 GPU 处理的 Token 数量），更重视如何确保模型在量化后依然保持智能水平。为此，团队建立了一套严格的质量红队测试循环（Measurement Quality Red Teaming Loop）。在模型发布前，内部会进行大量的“狗食”（Dog Food）测试，即员工像普通用户一样使用模型。这种机制能迅速捕捉到因量化导致的细微质量下降，例如工具调用失败或逻辑能力退化。
案例：MiniMax M3 模型的量化优化实践**
一个典型的成功案例是与开源模型提供商 MiniMax 合作，为其 M3 及即将发布的 M3.1 模型提供推理服务。MiniMax 在将模型量化为 Nvidia NVFP4格式时遇到了困难，而 NVFP4 是从内核和服务视角来看，在 Nvidia GPU上实现最高吞吐量的理想量化格式。为了验证不同方案的效果，团队进行了对比测试：
| 模型版本/量化方案 | 颜色标识（原文描述） | 性能表现 |
|---|---|---|
| MiniMax 原始模型 (FP8) | 淡紫色 (Lilac purple) | 基准性能 |
| MiniMax 自研量化方案 | 亮粉色 (Hot pink) | 存在质量损失 |
| Together AI 优化方案 | 橙色 (Orange) | 匹配原始模型性能 |
通过应用 Together AI 的量化配方，团队成功使 MiniMax 模型的推理性能匹配原始 FP8 模型的表现。这不仅帮助 MiniMax 显著增加了每块 GPU 处理的 Token 数量，还帮助他们实现了从模型训练到盈利性服务的闭环。这种技术赋能使得 MiniMax 能够更快地回收收入，进而投入下一代更强大模型的研发中。这一案例证明，严格的评估循环、基准测试以及内部狗食文化是确保量化技术既高效又高质量的关键，而不仅仅是依赖单一的算法优化。
推理系统的复杂架构与开源模型的商业价值
视频演讲的结尾部分深入探讨了现代大语言模型推理（Inference）背后的技术复杂性，并强调了其对企业的实际商业意义。演讲者指出，一个高效的推理系统并非简单的模型调用，而是由多个精密协作的组件构成的复杂工程。这包括核心的队列管理与批处理机制（queuing and batching），以及针对不同阶段优化的调度工作。特别是在计算资源分配上，预填充（prefill）和解码（decode）阶段通常被分配到不同的 GPU 上运行，并采用不同的内核优化策略和并行方案。这种细粒度的资源隔离与调度旨在最大化 GPU 的利用率，确保其真正发挥价值。只有当这些底层基础设施稳固运行后，生成的 token 才能顺畅地返回给用户，支撑起代码生成、聊天等我们熟悉的交互体验。
"the core queuing and batching, uh, scheduling work, um, prefill and decode often on different GPUs with different kernels, uh, different parallelism schemes"
从商业角度来看，演讲者特别提到了开源模型在成本控制方面的巨大潜力。许多企业的 CFO 正面临云代码支出过高的压力，迫切希望寻找替代方案以降低运营成本。在这种情况下，采用开源模型不仅是一个技术选择，更是一个关键的财务决策。演讲者通过展示相关的二维码和职业页面链接，暗示了开源生态不仅服务于技术爱好者，也为寻求成本优化和企业级支持的组织提供了切实可行的路径。这种从底层硬件调度到顶层商业价值的完整链条，构成了推理技术吸引力的核心。
量化质量评估的多维基准测试体系
在问答环节，针对 NVFP4 等量化技术的质量评估方法，演讲者详细阐述了其多维度的验证体系。传统的基准测试如 GSM8K 或 MMLU 虽然常用，但演讲者指出这些指标已经趋于饱和（saturated）。例如，某些模型在特定基准上的得分已超过 90%，这意味着微小的分数波动（如 1% 或更高的变动）往往意味着模型出现了严重问题，而非性能提升。因此，仅依赖这些静态基准不足以全面评估量化后的模型质量。
为了更精准地捕捉模型在真实场景中的表现，演讲者团队引入了层激活的 KL 散度（KL divergence）分析。这种方法用于衡量量化前后各层激活值的具体变化程度，从而从微观层面评估模型内部状态的稳定性。此外，他们还构建了端到端的代理（agentic）管道测试。目前，团队已经积累了数百个不同的测试用例，这些案例来源于历史上所有模型出现过的问题。通过将这些真实世界的错误场景纳入自动化测试循环，确保任何新发布的量化版本都能在这些复杂任务中保持正常运作。这种从宏观基准到微观激活，再到端到端代理任务的立体评估体系，确保了量化模型在现实世界活动（real world activity）中的可靠性。
硬件互联技术与免训练量化策略解析
关于 Grace Blackwell 架构中超越八卡限制的互连技术，演讲者坦诚表示其个人背景并非硬件设计专家。但他通过观察机架结构描述了数据流动的物理路径：每个包含四张 GPU 的托盘都连接着粗大的电缆（really thick cables），这些电缆汇聚到一个大型交换机。数据位通过这些厚重的线缆传输至交换机，进而实现全归约（all reduces）等分布式计算操作。这种物理层面的互联设计是实现大规模集群扩展的基础。
在量化策略方面，演讲者重点介绍了其团队采用的完全免训练（training-free）方法。市面上许多量化方案要求在模型完成后进行额外的微调或重新预训练，但这通常需要访问原始的完整训练数据集。由于大多数用户并非模型提供商，无法获取这些数据，且重新训练可能导致模型遗忘（model will forget things）原有知识。因此，演讲者团队选择了一种不依赖额外训练数据的方案。
"So, this is entirely a training-free approach. Um it's uh it's a combination of stuff that is, I think, publicly out there... being very careful about which ones you use and being uh very sedulous about how you evaluate them."
该方案结合了公开的校准数据和如 "Scale Search" 等前期研究成果。关键在于极其谨慎地选择量化配方（recipes），并从上百种免训练方法中筛选出最优组合。通过细致地评估（very sedulous about how you evaluate them），团队能够在不牺牲模型性能的前提下实现高效的量化压缩。
新架构在主流大模型中的复兴与应用
针对未来值得期待的模型架构，演讲者分享了一个有趣的行业现象：曾经被视为“死胡同”的技术往往最终被主流采纳。他在博士期间研究过的状态空间模型（SSMs）曾被认为无法取代 Transformer，但如今却已融入顶级大模型的架构中。例如，Kimmy K3 模型中包含的 KDA（基于 SSM 线性注意力风格的层），证明了这一架构在高性能开源模型中的实际价值。
此外，稀疏注意力（sparse attention）技术也从无人问津变为标配。更引人注目的是，演讲者指出扩散语言模型（DLLMs）目前已成为推测性解码（speculative decoding）中的最佳选择。这些曾经边缘化的架构技术，如今不仅没有被淘汰，反而在解决解码效率等关键问题上提供了显著优势。这一趋势表明，大模型架构的发展并非线性替代，而是多种技术的融合与复兴。
"So Kimmy K3 has this thing called KDA which is basically an SSM layer... sparse attention being used... we use the diffusion language models the DLLMs in all the speculators. That's the best thing to do now"
演讲者最后总结，尽管 Transformer 曾被视为唯一路径，但 SSM、稀疏注意力及 DLLM 等技术的成功应用表明，推理侧的架构创新仍在持续演进。这些技术不仅丰富了模型的设计空间，也为解决特定计算瓶颈提供了多样化的解决方案。
循环模型（Looped Models）的意外崛起与快速迭代
近期，学术界和工业界对“循环模型”（Looped Models）的关注度显著上升。这种架构的核心逻辑是在基础计算图中，将生成的token重新送回相同的网络层进行多次处理。其理论优势在于能够在不增加模型权重规模的前提下，通过增加计算步骤来提升训练时的FLOPs（浮点运算次数）。起初，这种设计被视为一种非主流甚至怪异的想法，认为市场不会接受。然而现实情况发生了反转，OpenAI和Anthropic等头部公司实际上已经在使用这种架构。这一现象揭示了当前人工智能领域的一个关键趋势：在当前的技术环境下，提出优秀的模型架构思想并经过充分的实证工作证明其有效性后，该技术能够极快地被主流大模型（如GPT-6或GPT-7）所采纳。反馈周期和影响力的实现速度变得前所未有的短，这为架构创新者提供了巨大的机遇窗口。
Ollama的演进与开放模型云服务的兴起
Ollama作为由Jeff创立并担任CEO的项目，自2023年发布以来，始终致力于为开放模型提供媲美OpenAI和Anthropic级别的开发者体验。在2023年，主流的开放模型（如Llama）参数规模较小，用户可以在单张H100显卡、笔记本电脑或小型服务器上本地运行这些模型。然而，随着技术演进，今年年初Kimmy、Jill M和MiniMax等机构推出了参数规模在5000亿至1万亿之间的超大规模模型，这促使Ollama推出了云服务。该服务旨在将本地运行的便捷体验延伸至云端，目前已成为美国及欧洲地区最大且独立的开放模型访问云服务之一。这一转变不仅反映了模型规模的爆炸式增长，也体现了开发者对跨平台、多提供商环境下一致体验的强烈需求。Ollama的云架构设计重点在于确保获取最新模型、提供高速响应以及保障服务可靠性，其核心路由机制与许多使用Ollama的Fortune 500企业客户所采用的架构高度相似。
多提供商路由的核心挑战：质量与一致性的困境
在构建基于开放模型的应用时，开发者面临的最大难题是如何在不同推理提供商之间衡量质量并实现高效路由。理想的架构是通过组合多个提供商来“集众家之长”，但现实是并非所有开放模型的Token都是等价的，且不同提供商的服务方式存在巨大差异。这种异构性带来了严峻挑战：单个表现不佳的提供商可能会破坏整体用户体验，导致服务降级为“最低公分母”。这种不一致性可能源于多种技术细节：
- 模型精度与权重版本：提供商可能对模型进行了过度量化，或者使用了有缺陷的硬件、不同版本的权重文件。
- 工具调用（Tool Calling）的复杂性：尽管看似只是解析JSON和字符串，但在实际工程中，从恢复工具调用失败、强制执行特定Schema到确保分词器层面的正确解析，环节众多且极易出错。
- 采样技术与推理引擎差异：不同的提供商采用不同的采样技术，且推理引擎内部存在深度定制（如自定义内核、KB cast精度等），这些差异往往只在读取超长上下文等特殊场景中才会显现。
- 配置错误风险：甚至可能出现提供商提供错误模型名称的“愚蠢”错误，导致用户以为自己访问的是A模型，实际却是B模型。
正如演讲者所强调的：“不同团队在性能优化方面各有所长，但客户最终关心的是成本、智能程度、速度以及地域和隐私。如果无法有效管理这些差异，单一提供商的短板将直接影响整体服务质量。” 因此，建立一套能够穿透底层技术差异、准确评估并路由流量的机制，是开放模型生态发展的关键瓶颈。
开放模型服务质量的巨大波动
在讨论开源与闭源模型的差距时，行业往往关注两者之间的性能鸿沟，但实际的服务提供商差异比模型本身的差距更大。研究表明，对于开源模型的推理服务而言，表现最差的提供商与最佳提供商之间的体验差距，实际上超过了闭源模型（如 OpenAI、Anthropic）与开源模型之间的性能差距。这种不一致性源于用户习惯于闭源 API 提供的稳定体验，而开源模型生态中缺乏统一标准。例如，2024年的一项研究测试了 31 个不同的 Llama 端点，发现不同提供商提供的相同模型版本（如 Llama），其表现差异巨大：某些端点的性能甚至更接近 GPT-3.5，而另一些则表现平平。这意味着用户很难在事前预判服务质量，服务质量的波动性已成为比模型架构差异更严峻的问题。 >
基于日志概率的漂移检测与局限性
监控推理服务质量的一个有效手段是随时间追踪Log Probs（日志概率），以确保用户获得一致性的体验。然而，这种方法存在明显的局限性：目前许多主流 API 并不提供 Log Probs 数据接口。此外，该方法的本质是对比当前输出与过去数据的差异来检测漂移（Drift）。如果服务初期就存在偏差，这种基于历史对比的方法将难以发挥作用。
"Log Probs isn't on a lot of the APIs these days, so that's one downside. And you're really only detecting drift from the past versus..."
在没有日志概率数据的情况下，另一种流行策略是通过无数据保留的内省（Introspection）来监控请求形状的变化。例如，观察工具调用的数量、错误率以及输入输出长度的分布情况。不同提供商可能提供不同的输出长度，这种差异往往能揭示共性问题。演讲者提到曾观察到 DeepSeek 等服务因模型陷入无限循环（Infinite Loop）而导致的问题，通过监控请求形状即可在数据层面之前捕捉到这些异常。Open Router 采用的 Exacto 模型方法也遵循了类似的监控逻辑，通过持续评分来逐请求地监测服务质量。
开放模型生态的服务质量挑战与基础设施共享
要获得像 OpenAI 或 Anthropic 那样高质量的用户体验，开放模型生态需要解决底层基础设施的差异。Anthropic 曾因 TPU kernel 中的微小 bug 导致大规模停机，这凸显了对推理服务质量的极致关注。在开放模型领域，一种解决方案是实验室分享更完整的推理栈（Inference Stack）。目前大多数情况下，模型权重发布在 Hugging Face 或 Llama 上时附带的是示例代码，而非实际生产环境使用的推理栈。
DeepSeek 最近推出了 DeepInfer，这是他们自己的推理堆栈。用户可以使用 DeepSeek 权重并在自有 GPU 上以约 $38/GPU hour（原文提及的具体成本参考）运行，从而获得与官方服务一致的推理环境。这种一致性对于新成立的推理提供商尤为重要，因为它提供了高质量的基准保障。通过共享完整的运行栈而非仅权重和示例代码，开放模型社区可以更接近专有模型的稳定性与性能表现。
量化优化、低级 API 调用与安全验证
模型量化（Quantization）策略正在发生根本性转变。过去，量化通常由缺乏训练数据的第三方在模型发布后进行，目的是适配本地硬件（如 MacBook）。现在越来越多的实验室会在发布前与专家团队合作进行量化，确保 API 服务的模型与服务开源模型的版本一致。通过低级 API 将工具调用、推理提取和思维链处理提升到应用层（Harness），可以在不同提供商之间获得更一致的准确性，而不是完全依赖底层模型。
"This is very different than what happened originally which is quantization tend to be done by post... This is much more increasingly common that the labs will actually publish their own quantized versions of the model."
此外，新兴的监控机会在于建立 LLM 质量监测体系。一个前沿的安全验证思路是利用 Nvidia GPU 自带的可信执行环境（Trusted Execution Environment, TEE）。该环境可以对运行中的权重和服务软件进行认证（Attestation），生成指纹以证明模型正在被正确、安全地服务。尽管这一技术较为先进，但它为验证开放模型的推理完整性提供了新的可能性。
长上下文与多轮对话的 admission 策略探讨
在问答环节，针对预填充（Pre-fill）与解码阶段 Admission 的权衡问题进行了讨论。特别是在多轮 Agent 工作负载中，是优先处理工具调用还是长上下文预填充？演讲者指出，通过发送单 token 提示并测量输出的 Log Probs 并与基线对比，可以随时间监测偏差。虽然这不特定于上下文长度，但可以通过逐渐增加提示词长度来测试 Log Probs 的偏差变化。
值得注意的是，许多提供商会对模型的上下文窗口进行硬性限制（Cap）。特别是在超过 200, 000 token 的长上下文范围内，测试下一个 token 预测的一致性至关重要。这表明在超长上下文中保持推理稳定性是衡量服务质量的关键指标之一，而不仅仅是关注短期的工具调用准确率。
推理质量评估：从通用基准到客户专属测试
在开源模型市场日益激烈的竞争中，提供商为了争夺最低 token 价格，往往倾向于迎合某些特定的流量模式或使用案例。这种环境下，通用的公开评测容易被“刷分”或优化，导致模型实际质量无法保证。为了解决这一问题，一种更优雅且有效的方案是与特定客户合作，针对其独特的数据或流量模式设计专属的测试集（Evals）。这种定制化评估对于单一提供商来说很难通过通用手段进行作弊，因为它具有高度的私密性和针对性。
采用独特的编译器架构与 Egglog 引擎
与传统基于 MLIR（Multi-Level Intermediate Representation）的编译栈不同，该团队采取了一种独特的编译器方法。这种方法在处理大型语言模型、扩散模型以及生物模型等当前主流且能产生商业价值的深度学习应用时表现优异。其核心驱动力来自于 Egglog 引擎，该引擎为编译器提供了强大的等式饱和（Equality Saturation）能力。通过这种机制，系统能够更灵活地探索代码优化的可能性，而不是依赖预设的固定转换路径。这种架构设计旨在解决传统编译器在面对复杂多变的硬件和模型结构时，难以兼顾通用性与性能优化的痛点。
基于 RISC 风格的极简原语操作集
为了应对 PyTorch 中高达 2,000 种操作的复杂性，团队并未尝试将所有操作直接映射到硬件，而是采用了一种类似 RISC（精简指令集）的策略。他们将 PyTorch 中的操作分解为仅包含 14 或 15 种基本原语操作的集合，如加法、乘法、求和等。这种极简的操作集被称为“PyTorch 完备”（PyTorch complete），意味着只要模型能在 PyTorch 中表示，就能被系统摄入并编译到所有支持的后端。例如，矩阵乘法（matmul）这一常见操作并不直接存在于该原语集中，而是被分解为广播乘法（broadcasted multiply）和求约简（sum reduction）。这种设计在 PyTorch 操作与硬件实现之间建立了一个关键的瓶颈层，有效遏制了模型复杂度的爆炸式增长。
超越传统规则：等式饱和搜索机制
传统的编译器优化往往依赖工程师预先编写复杂的重写规则，这导致随着支持的应用、硬件和数据类型增多，编译器团队规模呈指数级增长。为了解决这一问题，该方案引入了“超级优化”（Super Optimization）的概念，即通过搜索程序的所有可能形式并借助成本函数来确定最优解。具体实现上，系统使用 E-graph（等式图）作为中间表示结构。E-graph 采用非破坏性重写规则，这与传统模式匹配替换不同。在传统方式中，一旦应用规则就会丢失原始信息；而在 E-graph 中，系统会同时保留方程的两边（重写前和重写后），不断应用所有可能的规则直到图达到饱和状态。
硬件实测驱动的最优代码提取
当 E-graph 完全饱和后，系统会从中提取出大量代表不同程序形态的具体图结构。这些图随后被编译为硬件上的可执行文件，并在真实硬件上运行以测量耗时。最终目标是最小化在硬件上的运行时间。这一过程通过一个直观的示例得以说明：对于表达式 A * 2 / 2，系统应用各种规则（如将乘以 2 视为左移一位）扩展图结构。最终，饱和图中包含了所有等价形式，系统能够自动识别出 A * 2 / 2 等同于简单的 a，从而简化表达式。正如团队所述：
"We take a matmul, for instance. We don't even have a matmul operation... we decompose that into a broadcasted multiply and then a sum reduction."
这种由数据驱动、无需人工预设启发式规则的方法，使得编译器能够自动发现最优的代码形态。
基于Lisp的编译器规则与常量折叠
该编译器的核心内部逻辑深受 Lisp 语言的影响，这意味着所有的优化和转换规则都必须用 Lisp 编写。这些规则本质上是对数学等价性的描述，例如基础的交换律（Commutativity），即 $x + y = y + x$。虽然对于 IEEE 浮点数而言，结合律和交换律的应用存在细微的陷阱（这是一个独立且复杂的话题），但在整数或理想情况下，这种等价性是编译器优化的基石。更实用的技术是常量折叠（Constant Folding）：如果编译器在编译阶段能够确定操作数 $a$ 和 $b$ 的具体数值，它可以直接计算 $a + b$ 的结果，并将整个加法操作从程序中移除。这种优化将原本需要在运行时执行的计算提前到了编译时完成，从而显著减少了运行时的开销。通过这种基于等价性的重写规则系统，编译器能够在不改变程序语义的前提下，对代码结构进行深层优化。
硬件后端抽象与多级IR架构
为了支持多种不同的硬件加速器，编译器采用了一套简化的核心中间表示（Core IR），这套基础原语被所有后端共享。然而，具体的硬件实现往往提供不同层级的操作指令。以 GPU 为例，其底层可能包含如 Tensor Core MMA（矩阵乘法累加）这样的高级操作，这些操作直接从 SRAM 读取输入并写入输出。引入新的硬件后端时，开发者只需定义一组重写规则（Rewrite Rules），将新硬件的操作映射到编译器已理解的核心 IR 操作上。这种机制使得即使面对与现有支持差异巨大的新硬件，集成工作也相对轻松，无需组建庞大的编译器团队进行复杂的重写开发。此外，现代硬件具有明显的层级结构：从单线程、Warp（束）、Thread Block（线程块，对应一个 CUDA Core 或 SM），到整个 GPU 甚至节点。因此，该编译器采用多级 IR（Multi-level IR）来显式建模这些不同的抽象层级。这种设计允许编译器整合来自社区或供应商库（如 Nvidia 的 cuBLAS、CUTLASS，以及 Hazy Research 的 ThunderKit）在不同层级实现的操作。编译器能够推理这些不同层级的操作，将低级别的子图组合成一个大型的“超级内核（Mega Kernel）”。虽然超级内核听起来很先进，但对于大型模型而言，它们并不总是最优解；因此，编译器可以在任何时刻混合使用普通内核和超级内核来实现前向传播。
基于实测的搜索空间与商业化突破
一旦定义了包含各种内核组合的搜索空间，下一步就是如何评估哪个程序更优。这通常需要一个成本模型（Cost Model）作为适应度函数来评估程序的执行时间或资源消耗。然而，为现代 GPU 等复杂硬件构建精确的成本模型极其困难，往往需要多年博士级别的研究工作才能在不实际运行代码的情况下准确预测耗时。鉴于此，团队采取了“最好的成本模型就是没有成本模型”的策略（源自 Bitter Lesson 理念），即直接在目标真实硬件上运行代码并测量实际耗时。这种方法虽然看似简单，却非常有效：它揭示了程序员直觉认为无益、但在 GPU 上实际表现优异的程序变体。尽管为了效率会结合早期剪枝（Early Pruning）技术——例如通过简单的 Roofline 模型评估子程序，如果其最佳情况下的性能已低于已知等效方案则提前剔除——但核心策略仍是依赖真实硬件的实测数据。最后，演讲者提到公司成功解决了编译器行业的罕见难题：实现盈利。历史上许多编译器公司因无法找到商业模式而倒闭，而他们通过提供基于云的推理服务，成功闭环了从编译器优化到商业变现的过程。
异构硬件上的通用编译器与规模化部署
Luminos 的核心优势在于其作为通用编译器（general purpose compilers）的灵活性，使其不仅能运行主流模型，还能支持各种“怪异”或小众（wacky）的模型架构。目前，该平台每月处理约 80万亿个 token 和数百万张图像，涵盖了蛋白质折叠模型、生物医学模型及图像处理等多种应用场景。尽管团队目前仅有 8人，但公司正处于快速扩张期，正在积极招聘以应对增长需求。其战略核心是利用先进的编译器技术将异构硬件商品化（commoditize），认为计算资源的未来在于通用化和标准化。
数值精度与硬件特性对编译器重写规则的影响
在机器学习中，结合律（associativity）和交换律等数学性质对数值精度至关重要。例如，在进行求和归约（sum reduction）时，树状结构求与纯顺序求会得出不同结果。若数值精度处理不当，将直接影响输出 token 的质量。因此，编译器必须显式建模数值准确性（numerical accuracy）。
此外，硬件实现细节也决定了重写规则的适用性。以 Nvidia Tensor Cores 为例，输入 A 和输入 B 可能来自不同的内存空间（如 SRAM 与 HBM）。编译器需根据硬件对输入数据的实际消费方式，制定相应的优化策略。> “So, you know, associativity commutativity they do matter so much as they do affect numerical accuracy.”
搜索空间扩展与编译时间的权衡策略
针对编译器搜索空间扩大导致的性能问题，Luminos 采取了以下应对机制： 1. 快速原型验证：单次前向传播及配置分析（profiling iteration）可在 10毫秒以内 完成，这意味着每秒可进行上千次配置测试。 2. 启发式搜索算法：虽然搜索空间扩大了十倍，但团队主要使用遗传算法等标准搜索策略。目前仅探索了 1% 的 1% 的空间，因为目标并非全局最优解（global optima），而是寻找接近 99% 性能的全局最优的局部最优解。 3. 时间预算机制：推理场景用户更关注运行时性能而非编译耗时。因此，系统允许设置 1小时或10小时 的编译时间预算，以换取运行时性能提升（如 5%或10%），并在边际收益递减时停止。
基于真实数据分布的调试与错误溯源
为解决编译器优化中的调试难题，Luminos 结合了 PyTorch 的工具链与 Egglog 的推理能力： * 元数据追踪：利用 PyTorch Profiler 跟踪高层操作（high level ops）的元数据，识别瓶颈。 * 反向证明溯源：当输出程序错误时，Egglog 能提供从输入到输出的重写规则链（chain of rewrites），从而快速定位无效的重写规则。 * 真实数据驱动：编译器使用接近真实的张量形状（tensor shapes）和数据分布进行配置分析，确保时序预测的准确性。由于已知输入特征，只要重写规则正确，无需额外检查输出正确性。
“We end up only searching like 1% of 1% of the space, but uh and people are I think surprised to hear that, but we never are targeting a global optima.”
编译器优化：基于非图灵完备性的分析性推导
在深度学习编译器的设计中，核心挑战在于如何将高级算子转化为高效的底层指令。编译器通过搜索各种降级（lowering）形式，最终生成高度融合的操作符（fused ops）。为了评估性能优劣，系统采用了一种基于Roofline模型启发式规则的判断标准：如果一个内核在DRAM之间移动的数据量比另一个内核多出一个数量级，那么这种设计通常被认为是低效的。因此，编译器的目标是在中间层展开操作后，通过模式匹配将这些操作重新融合，以减少内存带宽压力。
这一优化策略的理论基础在于所使用的语言并非图灵完备（Turing complete）。演讲者指出，这一特性至关重要，因为它意味着该语言不受Rice定理（Rice's theorem）的限制。在20世纪90年代，Super Optimization技术在C语言等通用图灵完备编程语言上失败的主要原因，正是由于存在近乎无限的编译可能性，导致难以对程序行为进行推理。相比之下，PyTorch虽然完备但非图灵完备，其编译空间被严格限制在密集线性代数程序（dense linear algebra programs）这一狭窄领域内。
"It is not subject to Rice's theorem... We compile dense linear algebra programs, and that's a very narrowed space versus like all possible programs."
利用这一非图灵完备的特性，编译器能够解析性地（analytically）计算出不同内存空间之间的字节移动量。这意味着系统可以在不实际运行模型的情况下，推导出性能的Roofline界限。这种能力使得编译器能够执行大量的早期剪枝（early pruning），从而在庞大的搜索空间中大幅减少所需的配置文件迭代次数，显著提升了编译效率。
优化边界：专注前向传播与并行拓扑的复杂性
在探讨编译器的搜索空间时，一个关键问题是其是否包含量化、推测解码（speculative decoding）或并行性等高级优化技术。演讲者明确表示，该编译器的解决方案空间主要集中在内核级别（kernel level）的处理上，通常不包含推测解码等高层策略。系统的设计哲学是专注于处理前向传播（forward pass），即用户指定一个前向传播图，编译器对其进行端到端的编译。
"We try to basically just handle the forward pass... We're able to, you know, just go and directly piggyback on them."
这种设计选择基于一个核心论点：推理引擎（如vLLM和SGLang）已经提供了成熟的推测解码等解决方案，编译器可以直接搭便车（piggyback）利用这些现有创新。演讲者认为，推理性能提升的主要贡献因子（alpha）在于处理极其复杂的并行拓扑结构（parallelism topologies）以及前向传播中的复杂性管理。因此，编译器将精力集中在解决底层的计算和内存访问效率问题，而将更高层的算法创新留给上层推理引擎去实现和优化。
SGLang架构演进：从Agent工作负载到Radix Attention
SGLang的创始人Leon Shaw回顾了该框架诞生的背景。故事始于2023年底，当时开源模型如Llama刚刚兴起，业界对Agent工作负载（agent workload）的形态尚处于猜测阶段。当时的设想包括工具调用和并行子Agent，类似于Cloud Code中的场景：当在云端分叉出子Agent时，它们会共享一个巨大的上下文（KV pool）。由于每个查询和提示词都非常短，且需要多次进出推理引擎，传统的内存管理方式无法高效处理前缀重用（prefix reuse）。
为了解决这一问题，SGLang引入了Radix Attention（基数注意力机制）。其核心理念是将所有Agent的上下文在引擎系统的内存中像树一样进行管理，具体实现为Radix Tree（基数树）结构。在这种架构下，多个Agent可以共享相同的前缀系统提示词，例如一个用于身份验证，另一个用于审查。这种结构不仅支持共享前缀的计算，还允许不同的Agent在相同的上下文中执行不同的后续操作。
内存管理与驱逐策略：基于Radix树的调度优化
在Radix Tree的管理系统中，内存管理（memory management）是核心设计之一。由于显存资源有限，当需要为新请求分配空间时，系统必须执行驱逐（eviction）操作。SGLang采用的策略是优先驱逐未使用的叶子节点（unused leaves），以确保活跃Agent的上下文不被中断。这种基于树的调度算法能够灵活适应不同的工作负载需求。
"The eviction policy is we uh we evict the unused leaves when the memory is needed."
这种设计的必要性在于Agent场景的特殊性：多个子任务共享长前缀，但后缀部分差异巨大且可能频繁变更。通过Radix Tree结构，系统可以精确地追踪哪些上下文片段是共享的、哪些是独占的。当内存紧张时，系统能够智能地识别并移除那些不再被任何活跃Agent引用的后缀部分，从而最大化显存利用率。SGLang的核心设计、调度算法以及后续的优化工作，均围绕这一前缀保护（prefix protection）和高效的内存驱逐机制展开。
请求重排序与上下文复用策略
在构建推理引擎时，处理多个 Agent 或用户发送的交错请求（interleaving prompts）是常见挑战。如果直接按到达顺序处理，不同请求的上下文可能无法复用，导致缓存驱逐风险。因此，引擎需要对等待中的请求进行重排序（reorder），将它们按照缓存感知顺序（cache-aware order）进行批处理。这种策略允许引擎优先执行具有相同前缀的请求，从而最大化上下文复用（context reuse）。通过避免 A 和 B 请求的交错处理，系统能显著减少因缓存未命中而产生的额外计算开销。这一理念源自论文中提出的在内存管理系统内部构建红黑树（Red Tree）的构想，旨在优化键值对（KV）缓存的管理效率。随着 2024 年中后期 Llama 8B、Llama 70B（原文误读为4.405B，实指大模型）等模型的普及，这种通用的推理引擎设计开始支持在线和离线服务。
CPU 瓶颈与重叠调度机制的演进
随着 GPU 推理速度的不断提升，传统的 Vanilla Scheduling（基础调度策略）暴露出明显的性能瓶颈。在旧有架构中，系统需等待 GPU 完成当前批次、获取数据后，再准备下一批次的输入。当 GPU 较慢时，这种GPU Bubble（气泡时间）通常控制在 10% 以内且可接受；但在 Blackwell 等高性能 GPU 时代，CPU 的处理效率未同步提升，导致 CPU 准备时间成为主要瓶颈。为解决此问题，团队设计了重叠调度（Overlap Scheduling）机制。该策略通过延迟设备到主机（Device-to-Host）的同步操作，将其推迟至下一轮执行，确保关键路径上无阻塞操作。这意味着在 GPU 运行第一批次的同时，CPU 可以提前准备第二批次的数据。“We delay all the device to host synchronization... to make sure that there's no blocking operations in the critical path.” 这种零等待（Zero-overhead）调度在 Hopper 架构下带来约 1.5-1.1 倍的吞吐量提升，而在 Blackwell 架构下甚至可实现两倍（2x）的性能增益。
多级缓存体系与 TRFT 优化
鉴于 GPU 内存有限，且用户可能在数分钟至数天内发送长上下文请求，系统必须高效存储和恢复之前的前缀（prefix）。为此，引擎引入了高缓存命中率设计，将寄存器、GPU 内存、主机内存及内部存储划分为 L1、L2、L3 Cache。每个 Token 可存在于不同层级的缓存中，并通过特定策略管理层级间的数据加载（如 L3 到 L2、L2 到 L1），以最大化缓存命中率（Cache Hit Rate）。实验数据显示，这种多级缓存管理策略能将 TRFT（推测为某种推理时间或相关指标）降低 56%。这一优化对于支持长上下文和长时间跨度的对话场景至关重要，确保了历史信息的快速检索与复用。
统一 Radix Tree 解决混合架构缓存难题
传统 Transformer 在处理长上下文时效率低下，新兴模型如采用滑动窗口（Sliding Window）或递归状态空间（Mamba, RWKV 等）架构，使得缓存共享变得极其复杂。例如，若要在位置 10 实现缓存命中，不仅需匹配完整注意力池的 KV Token，还需确保滑动窗口内的前 4 个 Token（位置 7-10）完整保留；若仅保留到位置 8，则因窗口缺失需重新计算全注意力。此外，递归状态需在特定位置精确匹配才能共享前缀。“If you want to cache hit at the position 10... you have to match the full KV tokens for the full attention pool.” 若将各组件独立管理，协调跨层、跨窗口的缓存锁定策略将面临巨大兼容性挑战。因此，团队提出了统一 Radix Tree（Unified Radix Tree）方案。该方案不再将各组件视为独立实体，而是基于语义 Token（Semantic Token）构建统一的树结构。这种设计简化了跨滑动窗口层和递归层的协调协议，实现了高效的缓存共享。“We used a semantic token ideas tree to which was based on the full token.” 这种统一架构避免了传统独立 Radix Tree 带来的兼容性问题，大幅提升了混合内存池和计算环境下的灵活性。
统一Radix树作为核心协调器
演讲者首先介绍了系统架构中的关键组件——统一的Radix树（Unified Radix Tree）。该结构被设计为控制器和协调器，旨在管理全Token、窗口Token以及循环状态（如AStates）等不同类型的内部维护组件。通过这种统一的设计，系统能够确保各个模块在匹配、驱逐和内存规则上遵循各自的逻辑，同时实现最佳的缓存命中率。这种架构将所有边缘分析推理工作负载中的边界情况整合在一起，有效避免了内存泄漏或浪费。正如演讲者所述：>
结论
推理是AI商业可持续性的核心瓶颈，其算力消耗可达训练的12倍。DeepSeek等案例证明，通过KV缓存、量化及内核优化可实现高毛利与低延迟。然而，硬件利用率在解码阶段极低（约5%），且开源生态存在严重的质量波动与标准缺失。尽管编译器自动化、Radix Attention及统一路由策略显著提升了效率，但通用基准已饱和，需依赖专属测试与底层API一致性来保障体验。未来竞争焦点在于异构硬件的通用编译能力及对长上下文和Agent工作负载的高效编排，而非单纯的模型规模扩张。