愛好 AI Engineer 電子報 🚀 OpenAI 跟 Cursor 都在用的加速技術 Speculative Decoding  #19

歡迎訂閱 📬 愛好 AI Engineer 電子報 過往期數點這 📚

https://live.gaiconf.com/courses/cursorlive?affcode=ihower

Hello! 各位 AI 開發者大家好 👋

我是 ihower,感謝大家再次閱讀這期電子報!天氣漸涼了,大家注意保暖 ❄️

🔝 OpenAI Predicted Outputs

OpenAI 新推出了一項令人神奇的功能 Predicted Outputs: 如果輸出大部分的內容你已經知道,則可以大幅增加輸出的速度。這功能特別適合應用於需要重新生成文字或程式碼,但只有小幅修改的場景。

由於非常好奇其背後的原理,找到李宏毅老師在課堂中對這項技術 Speculative Decoding 的詳細解釋: 李宏毅老師的課程,非常推薦觀看。

透過預先提供 predicted tokens,讓 LLM 能夠平行預測多個 tokens,從而大幅提升速度。不過要注意的是,未被採用的 predicted tokens 會被額外收費。因此雖然速度變快,但成本也是會增加的。

以下我嘗試白話說明原理(看不懂就去看李宏毅老師的講解更清楚囉)

LLM 還是需要每個 tokens 都生成,只是原先是一個 token 一個 token 依序預測。這招則是你會給 predicted tokens,讓 LLM 可一次平行同時預測多個 tokens,LLM 跑出來之後再檢查結果是否和 predicted tokens 一樣,如果預測的 tokens 大部分都正確,那整個時間就節省下來了。

我舉個簡單的例子:

假設輸入 a,希望輸出的正確答案是 b c d e。而你給的預測 tokens 是 a b c x y z

在沒有此機制時,LLM 需要依序 4 個步驟:

  1. a ➡️ a b
  2. a b ➡️ c
  3. a b c ➡️ d
  4. a b c d ➡️ e

有了 Speculative Decoding 之後,我們再假設 LLM 能夠平行跑 3 個 tokens 預測。那麼第 1 步可以根據你給的預測 tokens,假設 b 跟 c 就是正確的,直接平行預測接下來的三個 tokens,分別是

  • a ➡️ b (跟預測的一致)
  • a b ➡️ c (跟預測的一致)
  • a b c ➡️ d (跟預測的不一致,預測的 x 是錯的)

此時我們發現預測的 b, c 跟實際跑出來一致是正確的,但預測的 x 不對。因此第二步要從正確的 a b c d 開始:

  • a b c d ➡️ e

你會發現本來需要四步,有了 Speculative Decoding 之後只需要兩步,速度不就快一倍了嗎。

🎯 Cursor 團隊訪談錄影

最近用 Cursor 來寫 code 非常熱門,也是我最近愛用的程式碼編輯器。這是他們團隊的訪談,逐字稿可查看這裡(英文)
討論內容包括 Cursor 的誕生、技術細節、對 AI coding 的看法以及未來發展方向。摘要可以參考 12 這兩份簡體整理。

另外也推薦付費購買 Cursor 的 2 號員工 Ian Huang 的直播回放來看(這是親切的台灣中文),不只是訪談也有 Cursor 的 live demo。

👍 Cursor 的 instant apply

Cursor 編輯器就有用到上述 Speculative Decoding 技術,並針對此開發了專門的小模型。實現了驚人的 1000 tokens/秒處理速度,比一般 Llama-3-70b 快約 13 倍。這項技術讓大規模程式碼編輯變得非常流暢,是讓 Cursor 好用的關鍵技術。

🧠 OpenAI Prompt generation

OpenAI API 在後台 Playground 提供了 Generate 按鈕,可以基於你的描述快速生成 prompt,以及 function calling 和 structured output 用的 json schema。

這份文件分享了 OpenAI 是怎麼做出來的,功能使用的 meta-prompt 長怎樣。我推薦大家都採用 meta-prompt 的方式來生成 prompt,不僅能節省手動撰寫的時間,產出的英文 prompt 也比手寫中文 prompt 效果好。

另外,這份文件還提及未來計劃整合更進階的技術如 DSPy 和 Gradient Descent 等 prompt 自動最佳化方式。

🌟 Gemini 支援 OpenAI API 格式

蠻特別的消息,Google 宣布 Gemini 支援 OpenAI API 格式來呼叫,因此可透過 OpenAI 的官方函式庫進行呼叫,初期支援 Chat Completions API 和 Embeddings API。只需更改 API endpoint 即可使用。

📚 15 Advanced RAG Techniques from Pre-Retrieval to Generation

數位產品顧問公司 WillowTree 發布了一本免費下載的小 PDF 電子書,介紹了 15 種進階 RAG 技術,講解還不錯清晰,又沒有什麼產品業配,推薦一看。

🛠️ 對於開源模型採用趨勢的討論

這場由 Swyx 對 Braintrust (做 LLMOps 的一家公司) 創辦人 Ankur Goyal 的Podcast 訪談中,有兩個觀點令我既感到意料之外,又在情理之中 😲

  1. 業界對開源模型的採用率不到 5%,且呈現下降趨勢 📉。幾乎沒有 Braintrust 的客戶會因為成本、有更多控制權或隱私問題而選擇微調開源模型
  • Ankur 認為實際上用戶更重視的是模型的可用性和穩定性
  • 雖然開源模型的理念很有吸引力,但在現實中並不實用,特別是當公司需要快速前進並隨時適應變化的環境時,開源模型的推論基礎設施並不像 OpenAI 的 API 平台那樣成熟
  • 相比 OpenAI 以及 Claude 團隊在模型品質、服務基礎設施、API、文件、定價和溝通方面的表現非常出色,開源模型難以競爭
  1. 透過雲端合作夥伴採用大模型的比例低很多 🌀 例如透過 AWS 使用 Claude 或透過 Azure 使用 OpenAI,更多用戶喜歡直接呼叫原廠 API
  • 直接透過公有雲來取得這些模型並不是那麼順利,雖然這種狀況正在改變並逐步追趕,但整體過程並非完全流暢
  • 有些問題是直接使用 OpenAI 時不必考慮的,但當你透過其他雲端合作夥伴進行部署時,卻必須應對這些挑戰
  • 例如模型的 load balancing 負載平衡(當有大流量時)、即時取得最新推出的模型和功能等等

當然,這是 Braintrust 的觀察,會採用 SaaS 服務的客戶本來就沒有一定要用地端模型的限制。但就我最近看到的案例,用地端模型基本上可說是事倍功半無誤 🏋️‍♂️🏋️‍♂️

📊 紅衫資本的 Generative AI’s Act o1 報告

紅衫資本的這份 Generative AI 報告,總結了最近了一些重大發展和未來預測,還不錯看。重點包括

  • OpenAI o1 模型帶來新的 scaling law: 通過增加推理時間,我們可以繼續增強模型推理能力
  • AI 應用不再只是套殼(wrapper),而是開發細分領域的認知架構: 您的系統如何思考,如何處理用戶輸入和模型互動
  • SaaS 的重新定義: SaaS 將從 Software as a Service 轉向 Service as a Software

摘要可以參考 12 這兩份簡體整理。


最後,再次推薦購買這場 Cursor 的 2 號員工 Ian Huang 的直播回放 (不只推薦也是業配啦,單純支持本電子報也可買!)

https://live.gaiconf.com/courses/cursorlive?affcode=ihower

– ihower

發佈留言

發表迴響