การปฏิวัติความเร็ว: TileRT ทำให้การหน่วงเวลาการอนุมานของโมเดลใหญ่ลดลงอย่างรวดเร็ว เปิดศักราชใหม่ของ Scaling Law

6 hours ago • การอนุมานโมเดลขนาดใหญ่ • 16 views

บทความนี้เจาะลึกถึง TileRT ซึ่งเป็นเอนจิ้นการอนุมานประสิทธิภาพสูง และชี้ให้เห็นว่าในด้านการอนุมานโมเดลขนาดใหญ่ ความเร็วกำลังกลายเป็น Scaling Law ใหม่ บทความได้สรุปวิวัฒนาการสามขั้นตอนของการอนุมาน AI เผยให้เห็นว่าความต้องการของอุตสาหกรรมกำลังเปลี่ยนจากคุณภาพโมเดลและปริมาณงาน Token ไปสู่การแสวงหาการตอบสนองที่หน่วงเวลาต่ำอย่างถึงที่สุด

เฟรมเวิร์กการอนุมานกระแสหลักในปัจจุบันต่างออกแบบโดยมีปริมาณงานเป็นเป้าหมายหลัก ส่งผลให้พลังการคำนวณจำนวนมากสูญเปล่าไปกับขอบเขตการดำเนินการต่างๆ เช่น การสลับโอเปอเรเตอร์ การซิงค์ข้ามการ์ด และการเดินทางไปกลับของหน่วยความจำ ทำให้ประสิทธิภาพของฮาร์ดแวร์ยากที่จะแปลงเป็นความเร็วในการตอบสนองที่แท้จริงได้อย่างมีประสิทธิภาพ

ความเร็ว: Scaling Law ถัดไปของการอนุมานโมเดลขนาดใหญ่
ลิงก์ต้นฉบับ: https://www.tilert.ai/blog/speed-as-the-next-scaling-law-zh.html
ที่อยู่โปรเจกต์: https://github.com/tile-ai/TileRT
เนื้อหาประมาณ 5,000 คำ ใช้เวลาอ่าน 26 นาที เวอร์ชันพอดแคสต์ยาว 21 นาที

คำแนะนำที่เกี่ยวข้อง

TileRT ปฏิรูปโมเดลการดำเนินการของการอนุมานอย่างสิ้นเชิง โดยใช้เทคโนโลยีต่างๆ เช่น เคอร์เนลที่อยู่ถาวรในระหว่างการคอมไพล์, ไพพ์ไลน์ระดับไทล์ และการเชี่ยวชาญเฉพาะของเธรด เพื่อลดการสูญเปล่าในระหว่างการดำเนินการบนการ์ดใบเดียวลงอย่างมาก ในขณะเดียวกัน กลไก Heterogeneous Worker ที่เป็นนวัตกรรมใหม่ สามารถแบ่งหน้าที่การคำนวณของ GPU เพื่อปรับให้เข้ากับสถานการณ์การคำนวณ Attention แบบกระจัดกระจายในโมเดล GLM-5.1 ได้อย่างสมบูรณ์แบบ

ปัจจุบันเอนจิ้นนี้ได้เปิดตัวอย่างเป็นทางการและรองรับปริมาณการใช้งานจริง ผ่านการอัปเดตเวอร์ชันหลายครั้ง ทำให้ได้รับการปรับปรุงอย่างต่อเนื่องในเรื่องของความหน่วงส่วนท้าย (tail latency), เส้นทางแบบไดนามิก และโหลดบริบทระยะยาว

สิ่งนี้แสดงให้เห็นอย่างชัดเจนว่าการเพิ่มประสิทธิภาพโอเปอเรเตอร์เพียงอย่างเดียวนั้นใกล้ถึงเพดานประสิทธิภาพแล้ว ทิศทางการพัฒนาในอนาคตจะต้องเป็นการผลักดันการออกแบบร่วมกันอย่างลึกซึ้งระหว่างโมเดล คอมไพเลอร์ และฮาร์ดแวร์ โดยใช้ความเร็วในการอนุมานที่สูงที่สุด เพื่อขับเคลื่อนแอปพลิเคชัน AI ขั้นสูง เช่น เอเจนต์และการโต้ตอบแบบเรียลไทม์

สารบัญบทความนี้

หนึ่ง: ความหน่วงกำลังกลายเป็นความฉลาดรูปแบบใหม่
- วิวัฒนาการสามขั้นตอนของการอนุมาน AI
สอง: ช่องว่างระหว่างประสิทธิภาพการอนุมานกับขีดจำกัดของฮาร์ดแวร์
- Runtime เริ่มเข้าสู่เส้นทางวิกฤต
สาม: TileRT: คิดใหม่เกี่ยวกับเอนจิ้นการอนุมาน
- จาก Runtime Scheduling สู่ Persistent Execution
- Warp Specialization และ Tile-Level Pipeline
- สิ่งที่ TileRT ต้องการแก้ไขคือ Execution Gap
- จาก Operator Runtime สู่ GPU-Resident Scheduling
สี่: จาก Warp Specialization สู่ Heterogeneous Worker
- ขยาย Specialization จาก SM ไปยังโดเมน NVL ทั้งหมด
- การดำเนินการแบบ Heterogeneous ใน GLM-5.1
- การสื่อสารเริ่มเข้าสู่ Tile Flow
ห้า: Production-Ready: จากเวอร์ชันความเร็วสูงในห้องแล็บสู่ปริมาณการใช้งานจริง
- จาก “วิ่งเร็ว” สู่ “วิ่งเร็วได้อย่างต่อเนื่อง”
- ปัญหาที่ยากอย่างแท้จริงเริ่มเป็น “ระบบ” มากขึ้นเรื่อยๆ
หก: ขั้นตอนถัดไป: การออกแบบร่วมกัน
- โมเดล คอมไพเลอร์ และฮาร์ดแวร์เริ่มเชื่อมโยงกันอีกครั้ง
- TileRT เป็นเพียงจุดเริ่มต้น
เจ็ด: The speed is all you need
- การแลกเปลี่ยนและความร่วมมือ

การปฏิวัติความเร็ว: TileRT ทำให้การหน่วงเวลาการอนุมานของโมเดลใหญ่ลดลงอย่างรวดเร็ว เปิดศักราชใหม่ของ Scaling Law

หนึ่ง: ความหน่วงกำลังกลายเป็นความฉลาดรูปแบบใหม่

นับตั้งแต่ LLM ถูกนำมาให้บริการ แกนหลักของความขัดแย้งในระบบการอนุมานได้ผ่านการเปลี่ยนแปลงหลายครั้ง

ปัญหาแรกเริ่มคือจะทำให้โมเดลขนาดใหญ่พิเศษ “ทำงานได้” จริงๆ อย่างไร ต่อมา จุดสนใจของอุตสาหกรรมเปลี่ยนไปสู่การแสวงหาปริมาณงานของคำขอที่สูงขึ้นภายใต้ต้นทุนต่อหน่วย Batch ที่ใหญ่ขึ้น คิวที่ลึกขึ้น และแคช KV หลายระดับ ค่อยๆ กลายเป็นแกนหลักของการออกแบบระบบการอนุมาน

อย่างไรก็ตาม การโต้ตอบ AI แบบเรียลไทม์กำลังเปลี่ยนแปลงสถานการณ์นี้อย่างสิ้นเชิง

วิวัฒนาการสามขั้นตอนของการอนุมาน AI

2023 — 2024 · ยุค Chat ผลิตภัณฑ์ตัวแทน: ChatGPT ลักษณะทางเศรษฐกิจ: value < cost ความต้องการหลัก: model quality
2025 — ปัจจุบัน · ยุค Agentic ผลิตภัณฑ์ตัวแทน: Cursor, Claude Code, Codex ลักษณะทางเศรษฐกิจ: value ≈ cost ความต้องการหลัก: token throughput
สองปีถัดไป · ยุค Autonomous สถานการณ์การใช้งาน: เอเจนต์ในโรงงาน, การเงิน, ระบบในรถยนต์ ลักษณะทางเศรษฐกิจ: value »» cost ความต้องการหลัก: SPEED

สามยุคของการอนุมาน AI — จากคุณภาพโมเดล สู่ปริมาณงาน Token สู่ความเร็ว มันกำลังกลายเป็นมิติ Scaling ถัดไป

ด้วยการเพิ่มขึ้นของ Agent, การโต้ตอบด้วยเสียง, การเติมโค้ดให้สมบูรณ์, การเรียกใช้เครื่องมือ และ Test-Time Scaling ระบบการอนุมานกำลังถูกผลักดันกลับไปสู่ยุคที่ “ให้ความสำคัญกับความหน่วง” ผู้ใช้ไม่เพียงแค่สนใจว่าระบบสามารถสร้าง Token ได้ทั้งหมดกี่ตัวอีกต่อไป แต่เริ่มให้ความสำคัญว่าการตอบสนองครั้งต่อไปจะเร็วพอหรือไม่ ซึ่งหมายความว่าค่าใช้จ่ายคงที่ที่เคยถูกบดบังด้วยปริมาณงานที่สูงในอดีต กำลังกลับมาอยู่บนเส้นทางวิกฤตของประสิทธิภาพอีกครั้ง

ในขณะเดียวกัน Test-Time Scaling ยังทำให้ความเร็วของระบบส่งผลโดยตรงต่อความสามารถของโมเดล: ภายใต้งบประมาณความหน่วงที่คงที่ การอนุมานที่เร็วขึ้นหมายถึงการทำ rollout ได้มากขึ้น สำรวจเส้นทางการอนุมานที่ลึกขึ้น และมีความสามารถในการตรวจสอบตนเองที่แข็งแกร่งขึ้น

อย่างไรก็ตาม ระบบการอนุมานที่มีอยู่ส่วนใหญ่ไม่ได้ถูกออกแบบมาเพื่อเป้าหมายนี้

ไม่ว่าจะเป็นเฟรมเวิร์กการอนุมานแบบดั้งเดิม หรือสแต็กคอมไพเลอร์ที่เน้นการเพิ่มประสิทธิภาพเคอร์เนลเดี่ยวๆ มาเป็นเวลานาน สมมติฐานการดำเนินการพื้นฐานของพวกมันยังคงเป็น “ให้ความสำคัญกับปริมาณงาน” โดยเนื้อแท้ พวกมันสามารถกระจายค่าใช้จ่ายได้อย่างมีประสิทธิภาพเมื่อมีคำขอเพียงพอ แต่ในสถานการณ์การโต้ตอบแบบเรียลไทม์ มันยากที่จะเปลี่ยนประสิทธิภาพของฮาร์ดแวร์ให้เป็นความเร็วในการตอบสนองแบบ end-to-end ได้อย่างแท้จริง

正是在此背景下，TileRT首次赋能GLM-5.1模型，在其官方极速版推理服务MaaS平台上线部署。从最初的实验性原型系统，到如今承载真实的生产流量，TileRT迈出了关键一步。这不仅是一次从prototype到production的跃迁，更代表着我们对大模型推理执行模型的一次系统性重构。

二、推理性能与硬件上限之间的鸿沟

今天，一台8×H200 NVL服务器的聚合内存带宽已接近38 TB/s。

对于GLM-5.1模型而言，单次decode过程中实际激活的参数量约为42 GB。仅从理论带宽估算，在不启用MTP的情况下，token生成速度的理论上限接近1000 token/s。

然而，在真实系统中，端到端的速度往往只有几十token/s，与理论上限之间仍隔着一个数量级的性能鸿沟。正是从这一巨大落差出发，TileRT团队开始追问：问题的根源究竟在哪里？

起初，我们以为问题仅仅在于kernel不够快。直到profiler揭示了一些反直觉的现象：GPU利用率并不低，理论FLOPS表现也不差，但token延迟依然居高不下。

这意味着，GPU并非缺乏算力。真正的问题在于，算力被困在了一道道执行边界之间。

Runtime 开始进入关键路径

今天的大多数推理框架，仍然沿用一种经典执行模型：模型被拆解成一连串独立的算子，每个operator单独启动、同步，并完成各自的内存往返。这套抽象在训练时代非常成功，因为kernel足够”大”，计算能够自然掩盖launch、同步与runtime调度的固定成本。

但decode改变了这一时间尺度。

在追求极低延迟（latency-first）的苛刻要求下，每一个单独 kernel 的生命周期已经缩短至微秒级别。过去在吞吐量优先场景中能被轻松摊薄或掩盖的固定开销，如今重新浮出水面，成为不可忽视的瓶颈：包括 kernel 启动（launch）、跨 kernel 的同步屏障（barrier）、全局内存的溢出（spill），以及网络通信的同步延迟。这些因素全部踏入了端到端延迟的关键路径。

在进行性能剖析时，我们频繁观察到一种反直觉的现象：许多 kernel 甚至还没来得及”热机”，就已经执行完毕。

GPU 被迫不断重复着如下僵化的执行流程：

launch → load → compute → store → synchronize

每一次 kernel 执行的边界，都会粗暴地打断数据流，破坏数据的局部性，并强制所有执行单元重新同步。很多时候，真正限制系统速度的，并非某个 GEMM 核心运算本身的快慢，而是另一个更致命的问题：下一次计算究竟何时才能开始？

在过去，运行时系统（runtime）是 GPU 编程的便利层；但在超低延迟推理的语境下，它正日益成为性能瓶颈本身。问题的核心不再局限于 kernel 内部，而是转移到了：kernel 与 kernel 之间的间隙。

这也正是 TileRT 诞生的起点。

unsetunset三、TileRT：重新构想推理引擎unsetunset

TileRT 的核心判断是：当运行时系统的任务编排开始占据延迟的关键路径时，解决方案或许不再是”继续优化运行时系统”，而是从根本上重新设计推理系统的执行模型。

在传统的推理框架中，GPU 执行的是一个个彼此孤立的 kernel。执行流被 kernel 启动、同步操作、算子边界以及频繁的内存往返（memory round-trip）切割得支离破碎。

而在 TileRT 中，我们尝试了一条截然不同的道路：GPU 不再执行一串离散的 kernel，而是持续运行一个长期驻留的任务流水线。

从运行时调度到持久化执行

TileRT 在编译期（AOT）将整个模型静态展开，生成一个常驻的 Engine Kernel。

Tile-level Task Scheduling：算子被拆解为 tile 级别的任务，调度到 warp group 上。CTA 通过 warp/block specialization 机制，转变为异构的工作单元（heterogeneous worker）。算子被分解为 tile，任务被调度到 warp group，CTA 通过 warp/block specialization 成为异构的 worker。

在整个解码生命周期中：

Host 端仅启动一次
任务执行流（execution flow）持续驻留在 GPU 内部
大量的运行时调度工作被前移至编译期完成

传统的执行模型更接近于”算子接算子”的连续调度，而在 TileRT 中，任务执行流被进一步组织成一个持续推进的 tile 计算流水线。

在这里，tile 的意义远不止是更细粒度的任务划分。它本质上是一种全新的任务调度抽象：计算、通信与异步 I/O 被统一拆解为 tile 级别的任务，并在 GPU 内部持续向前推进。

Warp Specialization 与 Tile-Level Pipeline

为了维持这种持续执行的模式，TileRT 在 Engine Kernel 内部采用了更为激进的 Warp / Block Specialization 策略。

不同的 warp group 被赋予不同的职责：

一部分负责异步数据搬运
一部分负责张量计算
一部分负责通信与计算的重叠

过去，许多执行阶段必须串行推进：

load → barrier → compute → barrier

而在 TileRT 中，数据搬运、张量计算与通信开始以 tile 为粒度持续重叠。大量的中间结果不再需要反复写回全局内存（global memory），而是直接停留在寄存器、共享内存（shared memory）以及 L2 缓存中，继续向后流动。

从性能分析器（profiler）的角度看，这种变化非常显著：GPU 不再表现得像”不断启动新 kernel”，而更像一个持续运行的执行流水线。

TileRT 的核心目标：消除 Execution Gap

随着解码（decode）延迟被不断压缩，我们逐渐发现，真正吞噬延迟的很多时候并非计算本身，而是：

kernel 与 kernel 之间的等待时间
通信与计算之间的停顿
运行时系统与设备之间的同步开销

TileRT 的诸多设计——持久化 kernel、tile 流水线、warp specialization——本质上都围绕着同一个目标：尽可能压缩执行间隙（execution gap）。

从算子运行时到 GPU 驻留式调度

当越来越多的调度逻辑被下沉到 kernel 内部后，推理系统本身也开始呈现出一种与传统推理运行时截然不同的形态。

过去的执行模式：

调度发生在 host 端运行时
同步发生在算子边界
通信由外部框架组织

当前的执行模式：
越来越多的执行编排（execution orchestration）开始驻留在 GPU 内部。

运行时不再需要不断地”驱动 GPU”，而是更像在初始化并维护一个持续运行的执行流水线。

unsetunset四、从 Warp Specialization 到异构工作单元unsetunset

持久化执行流解决了单卡内部的大量执行空泡。然而，当系统扩展到 8×NVL 规模后，我们遇到了另一种边界：同构并行抽象本身的局限性。

今天的大多数张量并行（TP）框架，都默认所有 GPU rank 执行相同的逻辑，并通过同步来共同推进执行流。这种方式在稠密训练时代非常自然，但推理场景开始改变这一点。

随着稀疏路由、Top-K 选择、动态索引、长上下文注意力机制以及 MTP 执行不断引入系统，越来越多的执行阶段开始表现出一种新特征：它们并不天然适合同构扩展。

很多阶段本身计算量不大，但高度依赖全局信息、动态依赖和同步。如果仍然强行让所有 rank 执行相同逻辑，往往会引入大量重复计算、广播和同步放大。

将 Specialization 从 SM 扩展到整个 NVL 域

我们后来意识到：既然 warp 可以实现 specialization，GPU 本身为什么不可以？

于是，TileRT 开始进一步将 specialization 的思想从 SM 内部向外扩展：

warp specialization → block specialization → GPU specialization

不同的 GPU 不再被视为完全对称的执行单元，而是根据计算密度、通信成本与数据依赖关系，承担不同的职责。从某种意义上说，异构工作单元（Heterogeneous Worker）本质上是 Warp Specialization 在更大尺度上的延伸。

GLM-5.1 中的异构执行

在下图中，GLM-5.1 的注意力机制被拆解为异构 worker：GPU 1–7 运行 MLA（包括 Projection、Q/K/V、Selection、Attention、All Reduce），GPU 0 运行 Sparse Indexer（包括 Index Q/K、Sparse Index Score、Top-K、Broadcast、All Reduce）。Sparse Index 的结果反馈给 Selection。

GLM-5.1 中注意力机制的异构拆分 — GPU 0 运行稀疏索引 Worker，GPU 1–7 运行 MLA Worker。

在 GLM-5.1 的执行流中，我们最终将 attention layer 拆解为两类异构工作单元。

GPU0：稀疏索引 Worker

GPU1–7：MLA Worker

稀疏索引 Worker 专司 Top-K 筛选、稀疏索引构建以及路由决策；而 MLA Worker 则承担 RMSNorm、GEMM、Flash Sparse Attention 与 AllReduce 等计算密集型环节。

这一拆分的核心价值，远不止于”功能划分”。更关键的是，不同的执行环节从此拥有了差异化的扩展策略。某些阶段对全局信息依赖极强，同步开销主导了计算，因此更适合集中式执行；另一些阶段则天然适配张量并行。

通信开始融入 Tile Flow

在传统推理框架中，通信通常仍然是执行流之外的独立阶段。但在 TileRT 中，通信被进一步下沉到执行流水线内部。整个 attention layer 在 host 侧仅对应一次 Engine Kernel 启动，大量广播、归约与同步直接在 tile 级任务流水线内部完成。

传统执行逻辑

compute → sync → compute

TileRT 重叠执行逻辑

compute ↔ communication ↔ compute

形成持续重叠的执行流水线。

五、Production-Ready：从实验室极速版到真实流量

极致的 benchmark 往往是脆弱的。

真正困难的问题，从来不是如何在实验室里跑出一个漂亮数字，而是如何让系统在真实生产流量下，持续稳定地逼近硬件极限。

从 prototype 走向 production 的过程中，TileRT 让我们愈发清晰地感受到：超低延迟推理，本质上是对执行流水线持续推进能力的极限维护。许多在 benchmark 环境下不会暴露的问题，一旦进入真实流量就会被迅速放大。在 benchmark 中，序列长度通常相对稳定，路由模式更理想，请求到达更规整，KV cache 生命周期也较短。

但真实生产流完全不同。

长短上下文会持续交织，KV cache 会不断增长、碎片化与迁移，不同请求间的路由模式也会持续波动。而在 MTP 场景下，accept/reject path 甚至会不断改变执行流本身。

从”跑得快”到”持续跑得快”

过去半年里，TileRT 经历了数轮关键的执行模型重构。但这些重构的核心目标，并非继续推高峰值速度，而是解决一个在真实生产环境中更为棘手的难题：如何让执行流持续稳定地运行下去。

在 v0.1.1 版本中，我们进一步压缩了执行流水线的空泡，引入了更细粒度的 overlap，并对 Engine Kernel 内部调度方式进行了重新组织。这类优化未必会显著抬高理论计算性能上限，却能切实改善端到端延迟，尤其是 tail latency。因为在真实服务中，用户感知到的往往是”最慢的那几次”，而非”最快的那一次”。

到了 v0.1.2-alpha.1，MTP（Multi-Token Prediction）开始融入 TileRT 的执行流。表面上看，MTP 是为了”一次生成更多 token”；但从系统视角看，它带来的真正挑战是执行流开始变得动态。accept/reject path 会持续改变 pipeline 的推进方式，而 draft/verify 之间也会引入新的 synchronization dependency。换句话说，系统不仅要跑得快，还要在执行路径不断变化时，依然保持流水线不断流。

当 v0.1.3 正式支持 GLM-5 模型后，新的系统问题进一步浮现。随着 FP8 与超长上下文场景进入生产环境，KV cache 压力、访存局部性、communication amplification 开始成为影响稳定低延迟的关键因素。此时，瓶颈已不再只是某个 kernel 是否足够快，而是整个系统能否在复杂负载下持续维持执行流的持续推进。

接下来，我们将公布 v0.1.4 版本。这个版本将进一步面向超长上下文生产环境进行优化，并引入全新的 Heterogeneous Worker 执行模型。它的目标，是让 TileRT 不仅能在理想条件下跑出漂亮数字，更能在真实流量、动态路径、长上下文和复杂通信模式交织的生产环境中，持续稳定地保持高效。

真正困难的问题，开始越来越”系统”

随着性能不断逼近硬件边界，我们愈发清晰地感受到，真正困难的问题已不再只是 GEMM 优化、kernel 调优或 operator 融合。

很多时候，系统不是”算得不够快”，而是任务执行流水线无法持续稳定地流动。

今天，TileRT 已正式承担 GLM-5 / GLM-5.1 的生产流量。但我们越来越觉得，benchmark 其实只是整个系统问题中相对容易的部分。真正困难的问题，开始越来越接近：

runtime architecture
distributed scheduling
memory system behavior
model-system co-design

而这，也正在推动推理系统从”算子优化”逐渐演化为真正的 AI execution infrastructure。

六、下一阶段：协同设计

当系统性能开始逼近硬件边界后，我们愈发清晰地感受到，许多问题已无法继续通过局部优化解决。

过去几年，大模型系统优化的大部分工作，本质上都发生在算子/kernel 层：更快的 GEMM、更激进的融合、更高效的 communication overlap，以及更复杂的 scheduling policy。但许多 bottleneck 已不再局限于某个 operator，而是存在于整个任务流水线本身。

我们开始越来越频繁地撞上”结构性边界”：