金磊 發自 凹非寺
量子位 | 公眾號 QbitAI

AI啊，你這速度簡直是在噴射啊！

仔細看，千萬別眨眼：

視頻地址：
https://mp.weixin.qq.com/s/Wn1-SzjpEkQLTyZnJKDRwg

這么多的代碼，直接就是“啪的一下”噴出來的感覺。

之前AI寫代碼像CPU渲圖一樣，是一點一點打出來；但這個AI寫代碼，更像GPU：

這么快生成的代碼，能好用嗎？

答案是可以的：

這就是智譜剛剛新出的高速版API——GLM-5.1-highspeed。

按照官方的說法，這個旗艦版模型的API，是目前頂流模型里最快的，已經達到了400 tokens/s！

而且這個GLM-5.1啊，雖然已經出了一個多月了，但現在還是開源模型里Coding最強的那一個：

那么接下來，老規矩，一波實測走起~

一手實測GLM-5.1-highspeed

AI寫代碼像開了倍速

我們先來做一個比開頭更加復雜的例子，Prompt是這樣的：

做一個網頁，畫面中心是一個會呼吸的星云；用戶點擊播放后，粒子會隨著模擬音頻節奏擴散、聚合、變色；旁邊還要有幾個可調參數，比如速度、密度、拖尾、光暈強度。

視頻地址：
https://mp.weixin.qq.com/s/Wn1-SzjpEkQLTyZnJKDRwg

同樣的，如此多行的代碼，AI在思考了十幾秒后，依舊是一口氣給噴出來的。

這類任務的難點在于，它要同時處理前端結構、Canvas 動畫、狀態管理、視覺參數、交互邏輯，還要讓效果看起來不至于太low。

從結果上來看，確實也是達到了Prompt的要求：

像跟設計師坐在同一塊畫布前

第二個測試更有意思。

我們在上一個代碼基礎上，繼續提出更多要求：

“這個波紋再快一點。”

“光暈顏色偏暖一些。”

“粒子散開時別那么硬，柔一點。”

“背景不要全黑，稍微有一點深藍層次。”

視頻地址：
https://mp.weixin.qq.com/s/Wn1-SzjpEkQLTyZnJKDRwg

首先，我們的這些指令都是比較模糊的，并非像“把第42行的speed從0.6改成1.2”這么精確，所以模型需要先精準地理解我們的意圖。

其次，由于GLM-5.1-highspeed的速度夠快，我們做項目的體感都不一樣了——

更像是和AI坐一起，一塊盯著畫布調參。

這也是高速API容易被低估的地方，和AI一起共事做項目，現在更接近實時的感覺了。

讓模型當游戲導演

第三個測試，我們把場景再往前推一步。

如果模型足夠快，它能不能在游戲里實時改變世界？

比如做一個小型2D游戲：

玩家控制一個角色在3D地圖里移動，場景中有障礙、敵人、道具、天氣、光照和隨機事件。有對話框可以輸入文字，場景會根據輸入的文字實時改變。

然后我們不給模型固定腳本，而是不斷發出類似導演指令：

“下雪”、“下雨”、“爆炸”……

視頻地址：
https://mp.weixin.qq.com/s/Wn1-SzjpEkQLTyZnJKDRwg

這類測試比寫網頁更刁鉆。

因為模型要理解游戲狀態、代碼結構、交互邏輯，還要判斷什么改動會影響體驗。

而高速API讓此前因延遲而難以成立的產品形態變得可行，例如模型在游戲中實時改變游戲世界狀態。

當然，這里還有很多工程問題沒解決，比如穩定性、安全邊界、狀態一致性、成本和并發。但至少從速度維度看，400 tokens/s級別的API已經讓這類想象不再只停留在 PPT 里。

10秒處理萬字內容

第四個實測，我們回到內容行業。

我們用AI讀取一份萬字長文的內容素材，讓它一口氣執行下面的內容：

1. 提煉3句最吸睛的海報主標題；
2. 生成6條15字內短視頻口播文案；
3. 輸出三套產品宣傳語（適合官網首頁）；
4. 生成可直接發公眾號的文案（800字）；
5. 最后生成JSON格式匯總所有內容。

視頻地址：
https://mp.weixin.qq.com/s/Wn1-SzjpEkQLTyZnJKDRwg

只花了10秒鐘！

而且效果也是依舊穩穩地拿捏到位了：

在AI的速度上來之后，讓人類更快地進入到了判斷的環節；由此，人和AI的協作更接近來回打磨了。而非一次性下單。

Agent進入快時代

如果只看400 tokens/s這個數字，我們可能很容易把它理解成模型變小了，所以跑得快。

但實際上，GLM-5.1-highspeed更值得關注的點在于，它主打旗艦模型高速版，而不是一個單純追求低延遲的小模型。

這背后靠的是系統工程。

智譜GLM團隊與TileRT團隊聯合打造GLM-5.1-highspeed，在推理引擎、調度系統和底層基礎設施三個層面做了優化：

推理引擎針對GLM-5.1架構特點重寫核心推理路徑，調度系統通過動態批處理、請求合并、KV緩存調度等方式降低高并發場景尾延遲，基礎設施層面則圍繞推理集群部署、網絡鏈路和負載均衡做協同優化。

簡單理解，大模型推理不是GPU算一下就完事。

真實線上系統里，請求怎么排隊，怎么合并，KV 緩存怎么調度，多卡之間怎么通信，網絡鏈路怎么負載均衡，都會影響最終延遲。

TileRT的思路更進一步。

它把推理調度單元從傳統operator/kernel進一步下沉到tile級別，通過編譯期靜態編排、常駐GPU的persistent Engine Kernel、減少host調度和跨算子同步等方式，壓縮推理過程里的調度、搬運與同步開銷。

用一句更通俗的話，可以這樣理解：

過去像一群工人每搬一塊磚都要等工頭發一次指令；現在提前把路線、分工、節奏排好，讓工人持續在工地里流水線協作。

大模型推理速度的提升，很多時候不只來自更強的芯片，也來自對系統里每一個空轉環節的壓榨。

高速API的競爭，本質上是模型能力、推理引擎、調度系統和基礎設施的綜合戰。

當然，速度不能被神化。

一個API真要進入生產環境，還要看模型質量、穩定性、成本、上下文能力、工具調用可靠性、并發能力，以及復雜任務里的錯誤率。

尤其是400 tokens/s這樣的速度數字，也需要在更多任務、更多時段、更多并發條件下持續驗證。

但至少從這次測試可以看到一個明確趨勢：

國產大模型API的競爭，正在從能不能答得好，進一步走向能不能又快又穩地干活。

GLM-5.1-highspeed的意義，也正在這里。

它讓我們看到，當旗艦模型能力和高速推理系統疊在一起，AI Agent的體驗會出現一個很直觀的變化：等待變少，反饋變密，任務推進更連續。

Coding時代，速度是爽點。