很少有 AI 廠商篤信發佈的產品能夠「以數量換質量」，OpenAI 偏偏是其中之一。

一如之前連開 12 天發佈會的豪舉，昨天，OpenAI Codex 負責人 Thibault Sottiaux（也就是大家熟悉的 Tibo）宣佈了一項持續 28 天的承諾：

接下來的每一天，團隊要麼發佈一項對大多數 Codex 或 ChatGPT Work 使用者有明顯價值的更新，要麼執行一次完整額度重設。

活動來到 Day 1，OpenAI 交出的答卷是提速。通過訂閱使用 GPT-6 Astra 和 GPT-6.1 Sol，默認速度將提高約 50%，使用者無需調整設定。

同一天，OpenAI 還公佈了兩項方向完全不同的變化。ChatGPT 和 Codex 的部分文字輸出將開始加入不可見水印，ChatGPT 的廣告業務則準備引入更直觀的圖片展示形式。

放在一起看，幾項更新很能說明 OpenAI 目前的處境。它需要讓付費使用者覺得訂閱更值，也需要向監管解釋 AI 內容從那裡來，同時還得讓越來越大的使用者規模，成為廣告主願意買單的生意。

模型之外，AI 平台要面對的日常事務，正在越來越接近我們熟悉的網際網路。

每天都要更新，使用者期待一份可用的改進

Tibo 的承諾有一個值得留意的限定，每天發佈的改進，需要與大多數 Codex 或 Work 使用者相關，而且效果足夠明顯。

換句話說，一項藏在角落裡的小功能，很難滿足使用者對這份承諾的期待。對於每天使用 AI 工作的人，等待時間、操作是否方便、額度夠不夠用，都會直接影響他們願不願意繼續付費。

Day 1 的提速，正好回應了這種需求。

按照 Tibo 的說明，GPT-6 Astra 和 GPT-6.1 Sol 的默認速度最佳化覆蓋 OpenAI 的訂閱產品，也覆蓋支援 Sign in with ChatGPT 的合作夥伴，包括 OpenCode、Pi、Amp 和 Devin。

使用者通過 ChatGPT 帳號在這些工具裡使用訂閱能力，也在此次調整的範圍內。他表示，變化會在公告發佈後的兩小時內逐漸被使用者感受到。

隨後，Tibo 又給出了一個更具體的數字，生成速度從每秒 30 token 提升到每秒 50 token。

對於需要連續與模型互動的工作，提速仍然有實際意義。寫程式碼需要反覆讀取檔案、修改、測試和糾錯，整理資料也可能經過多次搜尋與生成，單次等待縮短後，累積下來的體驗差異會更明顯。

不過，比起提速，或許重設額度來的更實在些，我們也期待這 28 天能看到多幾次。

給文字留下水印，也要承認水印的侷限

提速讓使用者更容易使用 AI，文字水印則回應了另一個問題。當生成內容進入郵件、文章、報告和公共討論，外界還能不能識別它與 AI 的關係？

同樣是今天，OpenAI 公佈了應對歐盟文字來源規則的方案。按照其公告，歐盟《AI Act》要求生成式 AI 提供商，讓生成文字能夠以機器可讀的方式被識別。

全球 API 客戶從當天起，可以為部分模型主動開啟文字水印，默認狀態仍然關閉。

未來幾周，OpenAI 會在歐盟範圍內，為符合條件的 ChatGPT 和 Codex 文字輸出加入不可見水印，覆蓋各類套餐，但首發階段不會將它設為全球默認功能。

OpenAI 將這項技術稱為 textGrain。它會在模型選擇詞語時加入不可見的統計訊號，檢測工具再尋找這些訊號，判斷一段文字是否含有 OpenAI 水印。OpenAI 還計畫將技術開源。

難點在於，文字太容易被改動，而可供模型選擇的表達方式，也因內容而異。

在目標誤報率為 1% 的測試條件下，對於心理學等內容，檢測工具能識別約 80% 的 200-token 水印文字，長度增加到 400 token 時，識別率約為 95%。數學內容的表達空間更小，檢測表現明顯更低。

編輯也會削弱訊號。在另一組 400-token 文字測試中，將 10% 的詞語取代為同義詞，檢測率會從約 92% 降至 66%；替換比例達到 25% 後，檢測率只剩 17%。

幾組數字說明，文字水印能提供線索，但距離可靠判斷一篇文章的創作過程，還有相當大的距離。OpenAI 也表示，在其用於評估 Astra 的基準測試中，沒有觀察到加入水印前後存在有意義的性能差異，不過這些測試仍然不能覆蓋所有實際寫作場景。

更關鍵的邊界，是水印無法衡量人類貢獻。

一個人自己完成文章，再讓 AI 調整表達，和讓 AI 生成全文，都可能涉及模型對文字的處理。檢測到水印，無法說明作者投入了多少判斷、編輯與創意，也不能據此判定版權、責任或內容真假。

水印同樣不會關聯具體使用者、帳號、提示詞或對話。反過來，沒有檢測到水印，也無法證明文字由人類獨立完成，文字過短、經過編輯或翻譯、來自不支援水印的模型，都可能讓訊號無法被識別。

由於誤報和漏報仍然存在，OpenAI 暫時只向獲批的研究人員和專業機構開放檢測工具的申請，沒有在上線時向公眾全面開放。

當 ChatGPT 每周觸達 12 億人，廣告開始長出熟悉的樣子

比起水印，視覺廣告更容易讓普通使用者感受到產品的變化。

OpenAI 在同日公告中稱，ChatGPT 每周觸達 12 億人。對於這樣規模的平台，訂閱之外的商業收入，已經成為產品發展的一部分。

此次公佈的新廣告形式，將通過圖片展示產品靈感、使用方式或相關體驗。首批測試計畫在本月晚些時候於美國啟動，與一組初始廣告主合作，展示場景選在 ChatGPT 生成圖片的過程中。

按照 OpenAI 的說明，廣告會被明確標註，並與正在生成的圖片保持分離，廣告也不會影響 ChatGPT 提供的回答。

選擇圖片生成作為測試場景，有它的商業邏輯。

使用者在構思房間佈置、活動方案或生活方式時，圖片能讓商品的使用場景變得更直觀，也更容易讓品牌進入使用者的考慮範圍。當然，是否能帶來足夠好的體驗，還要等測試給出答案。

OpenAI 同時擴充了廣告效果衡量工具，與 Hightouch、Tealium、LiveRamp 等平台合作，方便廣告主將已有系統中的轉化資料傳回 ChatGPT Ads，並引入更多歸因和效果評估夥伴。

對廣告主而言，真正需要回答的問題是，使用者看過廣告之後，是否產生了購買，以及這些購買有多少原本就會發生。

OpenAI 公佈了幾組合作夥伴提供的早期結果。

DV Rockerbox 稱，WeightWatchers 在 ChatGPT Ads 上的歸因獲客成本，比其綜合付費搜尋基準低 15.3%；WorkMagic 稱，健康品牌 Dose 的增量購買中，67% 來自全新客戶；Triple Whale 則稱，Portland Leather 從 ChatGPT Ads 獲得的訪問者中，93% 是新訪客。

此外，廣告展示的位置，也需要新的規則。OpenAI 表示，會評估對話是否適合展示廣告，避免在情緒脆弱、敏感或其他不適宜的語境中投放，並與 DoubleVerify、Integral Ad Science 探索品牌適配評估。

按照公告，這些合作方將在受控測試環境中評估相關保護機制，不會訪問真實使用者的私人對話。

傳統網站的廣告通常圍繞頁面內容，ChatGPT 的廣告則出現在一段持續變化的對話旁邊。平台越能理解使用者當前想做什麼，商業機會就越具體；同樣，使用者也會更在意，自己得到的建議究竟受到什麼影響。

OpenAI 承諾廣告不影響回答，未來我們也將拭目以待。

28 天更新承諾才剛開始，接下來每天會交出什麼，仍然值得關注。不過，首日的幾項變化已經讓競爭的範圍更清楚了，OpenAI 同時要經營付費使用者的效率、生成內容的透明度，以及廣告主的商業回報。  (APPSO)

智東西9月11日報導，上個月，MiniMax開源通用視訊模型MiniMax H3。在第三方評測平台Artificial Analysis上，該模型一度登頂有聲視訊編輯榜榜首，Elo得分達到1130。憑藉開放權重、視訊生成質量和性價比，H3很快在開發者社區內衍生出大量適配和新玩法。

模型開源解決了“能不能部署”的問題，但距離真正真正進入創作流程，中間還有一道速度門檻。對於需要反覆調整畫面的創作者來說，生成速度直接影響創作節奏。

針對這一痛點，RunningHub近期推出並開源了H3視訊生成加速方案H3 Lightning。在一組5秒視訊生成對照測試中，RunningHub將H3的生成耗時從348.8秒縮短至28.7秒，整體推理速度達到基礎方案的約12倍，等待時間減少約92%。

目前，相關技術方案和復現說明已經在GitHub公開。有多卡裝置的使用者可以參考方案進行本地部署，沒有裝置的普通創作者也可以直接在RunningHub上使用。

項目開源地址：https://github.com/RH-RunningHub/MiniMax-H3-MultiGPU-Lightning

01. 5秒視訊不到半分鐘生成等待時間減少92%

H3開源後迅速受到創作者關注，但實際部署後，一個問題隨之顯現：模型權重雖然可以下載，生成速度卻依然影響使用體驗。

在RunningHub的一組對照測試中，測試環境配備4張NVIDIA RTX 6000D專業顯示卡，生成一段5秒、1344×768解析度的視訊。採用BF16基礎方案，完成這一過程需要50步，耗時348.8秒，接近6分鐘。

RunningHub首先引入RH後訓練加速模型，將生成步數從50步壓縮至9步，用更少的計算輪次完成視訊生成。在這一配置下，生成耗時縮短至60秒，速度達到基礎方案的5.8倍。

在此基礎上，RunningHub進一步疊加算子和編譯最佳化，將生成耗時繼續壓縮至28.7秒。相較基礎方案，整體推理速度提高約12倍，等待時間減少約92%。

為驗證這一能力，智東西也在RunningHub平台進行了測試，我們先讓H3生成了一段5秒的視訊，內容是一隻流浪貓吃貓糧，平台用時28秒完成生成，整體過程較為流暢。

▲15秒視訊生成用時54秒（生成過程經倍速處理）

隨後，我們提高測試難度：將視訊時長增加到15秒，讓模型生成一段發生在高級餐廳的都市短劇，角色變多、還加上了台詞。

視訊中，一名身穿紅裙、披著西裝的女子帶著兩名保鏢憤怒地衝進餐廳，宣佈“在場的所有人，一個都不許走”，現場氣氛迅速變得緊張。實測來看，畫面整體完成度較高，角色動作銜接自然，人物表情能夠配合情節變化，台詞、口型與畫面基本匹配，聲音也較為清晰，很有短劇的感覺。

除了文生視訊，RunningHub這套加速方案還可用於多參考圖視訊生成。在另一組測試中，RunningHub使用8張RTX 6000D顯示卡，以4步生成15秒、768×1344解析度的豎屏視訊。其中，文生視訊耗時約48秒，根據兩張參考圖生成視訊耗時約73秒。

值得注意的是，H3 Lightning在提高速度的同時兼顧生成效果，仍保留BF16數值精度，且各項配置均經過組合測試和畫質驗收。

生成時長縮短，意味著創作者可以更快看到生成結果、調整提示詞並嘗試下一個版本。對於依賴反覆迭代的AI視訊創作，單次等待時間的縮短，最終會轉化為整個創作流程效率的提升。

02. 從50步壓到9步三層最佳化實現12倍提速

從近6分鐘縮短至不到30秒，背後是一套覆蓋模型計算和硬體協作的系統最佳化。

首先，視訊生成需要經過多輪計算逐步形成畫面，通常生成步數越多，耗費的時間越長。RH後訓練加速模型將對照測試的生成步數從50步壓縮至9步，使耗時由348.8秒縮短至60秒，率先實現5.8倍提速。

減少生成步驟之後，RunningHub繼續提高剩餘計算的執行效率。SageAttention2用於加快注意力計算，Cache-DiT通過快取復用部分中間結果，減少後續步驟中的重複計算，torch.compile則對模型的計算流程進行編譯最佳化，使其以更適合GPU的方式執行。

三項技術與RH後訓練加速模型疊加後，5秒視訊的生成耗時由60秒進一步縮短至28.7秒，相較BF16基礎方案實現約12倍的整體加速。

最後一層最佳化，是讓多張顯示卡配合得更好。多卡視訊生成不僅需要拆分計算任務，還需要在不同顯示卡之間交換資料。顯示卡之間如何分工，會直接影響生成速度、通訊開銷和視訊記憶體佔用。

針對主要通過PCIe連接、沒有NVLink高速互聯的多卡環境，RunningHub選擇了TP2＋Ulysses4的平行組合。在8張RTX 6000D的測試中，這一組合相比TP4＋Ulysses2快約12%，同時減少約14GiB視訊記憶體佔用。

RunningHub將後訓練加速、注意力最佳化、計算快取、編譯最佳化和多卡平行等方法統一整合進SGLang的multimodal_gen推理引擎，由同一套推理流程完成調度和執行。

03. 適配RTX 6000D多卡環境人人可用本地可部署

一套加速方案的實際價值，不只體現在跑得多快，也取決於它能落到什麼樣的硬體上，以及普通創作者能否真正用起來。

目前，不少視訊生成加速方案多建立在B300等高端資料中心GPU上。此類硬體雖然性能強，但採購和部署門檻較高，普通工作室和創作者較難按照公開配置復現。

在上面測試中，RunningHub採用8張RTX 6000D專業顯示卡，這些顯示卡主要通過PCIe連接，不依賴NVLink高速互聯，就實現了生成速度的大幅提升，成本更低，更貼近工作室的硬體條件。

為了讓本地部署更方便，RunningHub在GitHub中提供了環境安裝、模型下載、服務啟動和推理測試步驟。有多卡裝置的使用者可以參考公開方案，在自己的伺服器上部署H3，並將模型接入已有的創作流程。沒有多卡裝置的普通創作者，也可以直接在RunningHub上使用，可以說是實現了人人可用，本地可部署。

這也不是RunningHub第一次參與H3開源生態建設。H3上線後，RunningHub先完成模型接入，隨後開放全套ComfyUI節點，此次又進一步公開H3 Lightning加速方案。

據RunningHub披露，H3上線以來，RunningHub平台上已有上千名創作者開源近萬條相關工作流，覆蓋電商、短劇、漫劇、聲音克隆、動作克隆和音訊驅動等場景。節點、工作流和加速方案的持續開放，也為開發者進一步創作和開發提供了基礎。

目前，RunningHub的企業級API已接入上千家企業，日均呼叫量達到千萬級。從模型接入、工具封裝到推理最佳化，RunningHub在H3生態中的角色，也逐步轉向技術方案貢獻者。

04. 十年GPU調度積累搭建AI產品矩陣

H3 Lightning的推出，離不開RunningHub母公司海馬雲十餘年的GPU工程積累。海馬雲成立於2014年，是一家覆以GPUaaS為底座，業務覆蓋基礎設施、模型服務和智能體應用的原生AI公司。

隨著AI技術正從基礎設施建設走嚮應用爆發和原生應用形成，行業關注的問題也從智能能否被規模化供給，轉向這些智能如何被呼叫、如何被組織成真正能夠完成任務的產品。在這一過程中，算力始終是支撐模型運行和應用落地的基礎。

過去十餘年，海馬雲圍繞GPU容器調度、圖形虛擬化和即時串流媒體等環節進行技術投入，並在國內建設60余個邊緣節點，為超過3000萬月服務使用者提供雲渲染服務。在這一過程中，海馬雲積累了GPU資源調度、多工並行和內容即時分發等工程能力，並逐步將這些能力延伸至AI推理。

在此基礎上，海馬雲形成了從底層算力到上層應用的AI產品矩陣。其中，RunningHub已面向全球140多個國家和地區提供服務，接入170余個模型API；HaimaAPI面向企業聚合350余個主流模型；RHTV、RHStory和VibeX等智能體工具，則進一步將模型能力延伸到視訊及其他內容生產環節。

海馬雲不直接訓練基礎模型，其重點是解決模型發佈和開源之後的運行問題，包括新模型如何快速接入、如何在有限的硬體條件下提高推理效率，以及如何轉化為創作者可以直接使用的產品。

具體到H3，RunningHub先完成模型接入，隨後開放ComfyUI節點，再進一步公開H3 Lightning加速方案。這一過程也體現了海馬雲在發展過程中的能力演進：從解決高性能內容“怎麼跑”，到解決AI模型“怎麼呼叫、怎麼落地”。H3 Lightning正是其GPU工程能力在AI推理環節的一次具體應用。

05. 結語：開源之後  推理最佳化成為視訊生成提速的關鍵

模型開源，給了開發者自行部署、修改和二次開發的選擇；推理最佳化，則進一步影響每次生成需要等待多久、消耗多少計算資源。當視訊生成從嘗鮮走向日常生產，生成質量之外，速度、穩定性、成本和部署條件，也會直接影響創作者的選擇。

RunningHub的H3 Lightning，推進模型權重走向實際生產：有多卡裝置的創作者可以參考公開方案本地部署，沒有裝置的創作者也可以線上使用。隨著開源模型越來越多，推理加速、硬體適配和工作流生態，正在成為決定模型能否真正進入創作流程的關鍵環節。 (智東西)

彙整鉅亨號中所有使用「生成速度」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`

ChatGPT 推出文字水印，GPT-6 提速 50%

15秒視訊，54秒生成！AI視訊創作的“等待焦慮”，被RunningHub這套開源方案治好了