SGLang 登上 TPU，CUDA 护城河松了一块
一套每天生成数万亿 token 的推理框架，刚刚决定认真跨过一堵墙。
7 月 30 日，RadixArk 和 Google Cloud 宣布合作，要把 SGLang 的完整推理能力带到 TPU。当前的 SGL-JAX 已经能跑 Gemma、Qwen、DeepSeek、GLM、Kimi、MiniMax、Grok 等模型，今年晚些时候还会再来一个 PyTorch 原生后端 SGL-torchtpu。
官方给出的目标更直接，新开源模型在 GPU 上获得 Day 0 支持的同一天，也要能在 TPU 上跑起来。对上层团队来说，API 尽量不变，Radix Cache、HiCache、量化、推测解码和几种并行方式也要跟过去。
好家伙，这不是多写了一个设备适配器。
它碰的是大模型推理里一个很现实的问题。大家嘴上都说硬件异构，真到生产环境，软件栈往往早就和某一种加速卡缠在一起。模型权重可以搬，服务接口可以仿，监控面板也能重画，真正难搬的是调度器、KV cache、算子内核、并行策略和一整套已经被流量折磨过的故障处理。
所以我看到这条消息时，最关心的不是 TPU 又支持了多少模型，而是 SGLang 试图把哪一层选择权还给开发者。
图源，LMSYS 官方发布页
这不是多支持一块芯片
很多朋友可能不知道，模型能在一块卡上完成一次前向计算，离它能稳定接住线上请求，中间还隔着一条很长的路。
请求有长有短，有人刚发来十几个字，有人把整份代码库塞进上下文。服务端得决定哪些请求一起算，哪些先等一会儿，显存快满时淘汰谁的缓存，某个 worker 掉线以后如何恢复。再往下还有张量并行、专家并行、流水线并行，稍微配歪一点，吞吐没上去，P99 延迟先飞了。
SGLang 做的就是这层。它不是模型，也不是芯片驱动，而是把模型变成在线服务的推理运行时。RadixAttention 会复用请求之间相同前缀的 KV cache，调度器负责持续批处理，路由层要在多个 worker 之间分配流量。你在外面看到的 OpenAI 兼容接口，只是门牌，屋里全是管道。
这也是为什么「同一套 SGLang API」比一句「TPU 也能跑」值钱得多。
假设一家公司已经用 SGLang 接好了鉴权、限流、观测、灰度和回滚，后面无论挂的是 NVIDIA GPU 还是 Google TPU，上层应用都继续发同一种请求。模型路由不用重写，Agent 调用端不用因为硬件变化改 SDK，评测平台也还能沿用原来的输入输出格式。
这种兼容不会让迁移变成零成本，但能把变化压在运行时下面。对生产团队来说，少改一层，就少一层凌晨出现 429、OOM 和请求卡死时没人知道该看哪里的概率。
有点子牛逼的地方在这里，SGLang 正在尝试把推理接口从某一种硬件的附属品，变成横跨多种加速器的公共层。
真正难搬的是内核和语义
看到这里很容易兴奋，然后把「同一个 API」理解成「同一种行为」。
先别急。
SGL-JAX 不是把原来的 CUDA 代码换个编译参数。它是一套针对 JAX 和 TPU 重新做的推理后端，有自己的调度、模型执行、注意力计算和 KV cache 管理。项目 README 里列出的连续批处理、张量并行、OpenAI 兼容接口看着很熟，但底下走的是另一条执行路径。
硬件结构不同，擅长的计算形状不同，内存层次也不同。GPU 上调得很顺的一组 batch size、并行度和量化配置，搬到 TPU 上未必还是最优。编译缓存的脾气、动态 shape 的代价、跨主机通信的峰值，都会重新来收学费。
官方博客提到的 Pallas 内核就是证据。Pallas 是 JAX 里编写高性能自定义内核的工具，开发者可以更贴近 TPU 或 GPU 的执行模型控制数据搬运和计算。听着像解锁性能的钥匙，另一面也很直接，没有一批懂硬件、编译器和模型结构的人持续维护，这把钥匙插进去也拧不动。
今年的一篇 Ragged Paged Attention 论文 把这个难度摊得很开。大模型在线推理的请求长度参差不齐，KV cache 也不是规规矩矩的一整块连续内存。研究团队为 TPU 设计了细粒度分块、软件流水线和按工作负载分布编译的专用内核，在 TPU7x 上把解码阶段的内存带宽利用率做到最高 86%，预填充阶段的模型算力利用率做到最高 73%。
数字很漂亮，但请注意它背后的动作。分块要重做，缓存更新要和注意力计算融合，预填充与解码还要生成不同的内核版本。迁移税没有被一句口号抹掉，它只是从每一家应用团队各交一遍，变成由 RadixArk、Google 和开源社区在运行时层集中支付。
这个转移非常重要。
过去每家公司自己养一套私有适配，遇到新模型就重复补算子、对齐精度、查性能回退。现在公共推理框架愿意扛这部分工作，普通团队才有机会把力气放回业务负载和成本评测。可别误会成后端已经完全等价，官方路线图里写着 SGL-torchtpu 要到今年晚些时候才推出，PyTorch 生态兼容、即时执行和 MPMD 支持都还是将来时。
坦率讲，工程师最该盯的就是这些将来时。发布日能启动服务很酷，连续滚动更新三个月不出玄学故障，才叫生产可用。
CUDA 的墙到底松了多少
现在聊最容易吵起来的部分。
SGLang 跨到 TPU，能不能说明 CUDA 的护城河正在松动？
我觉得能，但只松了一块。
CUDA 的优势从来不只是一套编程接口。上面有 PyTorch 习惯、算子库、性能分析工具、容器镜像、故障经验，还有大量工程师用报错信息就能猜出是哪层炸了的肌肉记忆。再往现实里走，采购周期、云资源供给、预留实例折扣和团队招聘，也都在这条河里。
一套推理框架无法一夜填平这些东西。SGL-JAX 今天支持的模型很多，但每个变体、每种量化格式、每个新算子是不是都对齐，还得看测试矩阵。新模型 Day 0 上线以后，是能吐出第一个 token，还是在真实并发下保持质量和吞吐，也不是同一道题。
可运行时层一旦稳定跨过去，变化会从上往下渗。
应用团队不再需要先押注硬件再设计服务，而是可以先固定 SGLang 的 API、评测和观测，再让不同后端用同一批真实请求比赛。GPU 的价格高了，就测 TPU。TPU 某个模型支持慢了，就暂时路由回 GPU。某种芯片擅长长上下文预填充，另一种更适合低延迟解码，也可以按任务拆。
这类选择以前不是完全做不到，只是胶水太多，维护成本会把纸面收益吃掉。现在公共运行时开始主动吃胶水，硬件之间才有更公平的机会站上同一张评测表。
同一层服务接口跨过硬件边界，迁移成本才有机会下降
你想想看，真正让供应商紧张的从来不是客户嘴上说不要锁定，而是客户真的保留了一套可切换、可验收、切完还能回滚的方案。
反正我觉得，SGLang 这次最有价值的词不是 TPU，而是 Day 0。能不能在新模型发布当天同时支持两类硬件，会决定选择权是真家伙，还是 README 里的装饰品。
工程团队现在该抄什么
如果你正在做大模型服务，这条新闻还没到让人立刻搬家的程度，但已经足够改几处设计。
先把应用和推理后端之间的合同收紧。固定请求格式、流式输出、工具调用、错误码和重试语义，别让业务代码直接依赖某块硬件才有的开关。OpenAI 兼容接口不是万能药，同样一个字段在不同后端是否被忽略、默认值是否一致，必须进合同测试。
再把验收从跑通一次改成持续对比。准备一批自己的真实请求，覆盖短问答、长上下文、结构化输出、并发突刺和多轮 Agent。每个后端都测正确率、首 token 延迟、每 token 延迟、吞吐、失败率和单位成功请求成本。只看每小时租金，会把缓存命中、重试和尾延迟藏掉。
这块需要注意一下，单位成功请求成本比 token 单价更接近真相。某个后端单价便宜 20%，却因为长上下文频繁重编译或输出不稳定多跑一轮，省下来的钱很快又交回去了。
还要把硬件特有参数关进配置层。张量并行度、专家并行、量化方案、KV cache 大小、推测解码模型都不该散落在业务仓库。配置集中以后，你才有资格谈切换，不然每次迁移都是全仓库搜索加祈祷。
再补一场故障演练。worker 重启时请求会不会丢，编译缓存失效会不会把延迟顶穿，某个模型在 TPU 上暂时缺算子时能不能自动退回 GPU，这些问题没有发布会照片，但它们决定凌晨谁被电话叫醒。
厉害了，硬件可移植性聊到末尾，还是落在最朴素的工程习惯上。
接口要干净，评测要可重复，配置要能替换，故障要能回滚。
SGLang 正在替行业搬走一部分迁移税。它没拆掉 CUDA 的整条护城河，也没有让 TPU 变成插上就跑的万能卡，但它把一块最厚的砖，从应用团队面前挪到了公共运行时里。
墙确实松了一块。
门把手还烫着，先别闭眼冲。