這項由高通AI研究院的Ramchalam Kinattinkara Ramakrishnan、Zhaocong Yuan等七位研究人員共同完成的研究，發(fā)表于2025年7月3日，論文編號為arXiv:2507.02659v1。感興趣的讀者可以通過arXiv平臺獲取完整論文內(nèi)容。這項研究解決了一個在人工智能領(lǐng)域頗為頭疼的問題：如何讓一個小巧的AI模型為各種不同的大型AI模型提供高效的"草稿服務(wù)"。

當我們使用ChatGPT、Claude這樣的大型語言模型時，它們需要逐字逐句地生成回答，就像一個作家在稿紙上一個字一個字地寫作。這個過程很慢，特別是在手機或其他移動設(shè)備上使用時更是如此。為了解決這個問題，研究人員想出了一個巧妙的辦法：讓一個小而快的"草稿員"模型先快速寫出初稿，然后讓大模型來檢查和修正這個初稿。這就像是讓一個速記員先快速記錄，然后讓專業(yè)編輯來潤色一樣。

然而，現(xiàn)實中存在一個棘手的問題。不同的AI模型就像來自不同國家的人，它們使用著不同的"詞匯表"。一個專門為Llama模型訓(xùn)練的草稿員，無法直接為Qwen或其他模型提供草稿服務(wù)，因為它們對同一個詞匯的理解方式不同。這就好比一個習慣了美式英語的速記員，突然要為一個只懂英式英語的編輯工作，兩者之間的詞匯差異會造成很多誤解。

高通AI研究院的團隊提出了一個名為OmniDraft的解決方案，它的核心思想是創(chuàng)建一個"萬能翻譯官"，讓同一個小型草稿模型能夠為任何大型目標模型提供服務(wù)。這個方案包含了三個巧妙的創(chuàng)新。

一、跨詞匯表的智能翻譯系統(tǒng)

研究團隊首先解決的是不同模型之間的"語言障礙"問題。他們設(shè)計了一個叫做"n-gram緩存"的翻譯系統(tǒng)，這個系統(tǒng)就像是一個智能詞典，能夠記住不同模型之間的詞匯對應(yīng)關(guān)系。

傳統(tǒng)的做法是只處理兩個模型詞匯表中完全相同的詞匯，這就像兩個人只能用共同認識的詞匯交流，大大限制了交流的豐富性。而OmniDraft的n-gram緩存更加聰明，它能夠處理更復(fù)雜的對應(yīng)關(guān)系。比如，草稿模型可能將"snowflake"（雪花）分解為"snow"、"f"、"la"、"ke"四個部分，而目標模型可能將其識別為"snow"和"flake"兩個部分。n-gram緩存能夠?qū)W會這種對應(yīng)關(guān)系，將草稿模型的四個片段正確地組合成目標模型能理解的兩個詞匯。

這個過程就像一個經(jīng)驗豐富的翻譯官，不僅能翻譯單個詞匯，還能理解不同語言中詞匯組合的方式。當草稿模型提出一系列詞匯片段時，翻譯系統(tǒng)會查看緩存，看看這些片段是否能組合成目標模型更喜歡的形式。如果找到了匹配的組合，就會將多個小片段合并成一個完整的詞匯，大大提高了被目標模型接受的可能性。

更重要的是，這個緩存系統(tǒng)是動態(tài)學(xué)習的。每當系統(tǒng)遇到新的詞匯對應(yīng)關(guān)系時，都會將其記錄下來，供將來使用。這就像一個翻譯官在工作中不斷積累經(jīng)驗，遇到的對應(yīng)關(guān)系越多，翻譯能力就越強。

二、在線混合蒸餾訓(xùn)練

解決了翻譯問題后，研究團隊面臨的第二個挑戰(zhàn)是如何讓草稿模型更好地理解目標模型的"思維方式"。他們開發(fā)了一種叫做"在線混合蒸餾"的訓(xùn)練方法。

這個過程可以比作師傅帶徒弟的學(xué)習方式。草稿模型（徒弟）在實際工作中觀察目標模型（師傅）的表現(xiàn)，然后調(diào)整自己的行為來更好地配合師傅。具體來說，當目標模型接受了草稿模型的建議時，草稿模型會記住這次成功的經(jīng)驗；當目標模型拒絕建議并給出修正時，草稿模型也會從這次"糾錯"中學(xué)習。

傳統(tǒng)的訓(xùn)練方法通常是離線進行的，就像學(xué)生在考試前突擊復(fù)習一樣。而OmniDraft采用的是在線學(xué)習方式，更像是邊工作邊學(xué)習的學(xué)徒制。這種方法的優(yōu)勢在于，草稿模型能夠根據(jù)具體的使用場景和用戶數(shù)據(jù)不斷調(diào)整自己，而不是一成不變地使用固定的知識。

混合蒸餾的"混合"體現(xiàn)在訓(xùn)練方法的靈活性上。對于可以直接對應(yīng)的詞匯，系統(tǒng)使用一種叫做"逆向KL散度"的方法來對齊兩個模型的概率分布，這就像讓徒弟學(xué)習師傅對同一個問題的判斷方式。對于需要通過n-gram緩存翻譯的詞匯，系統(tǒng)則使用"最大似然估計"的方法，重點提高這些詞匯被正確預(yù)測的概率。

研究團隊還引入了一個動態(tài)權(quán)重參數(shù)λ，用來平衡這兩種訓(xùn)練方式的重要性。這個參數(shù)可以根據(jù)實際情況調(diào)整，比如當遇到的翻譯詞匯較多時，可以增加翻譯相關(guān)訓(xùn)練的權(quán)重；當直接對應(yīng)的詞匯較多時，則增加概率對齊訓(xùn)練的權(quán)重。

三、自適應(yīng)草稿長度調(diào)整

OmniDraft的第三個創(chuàng)新是智能的草稿長度調(diào)整機制。這個機制就像一個經(jīng)驗豐富的秘書，能夠根據(jù)不同情況調(diào)整匯報的詳細程度。

在實際應(yīng)用中，草稿模型需要決定每次應(yīng)該提供多少個詞匯建議。提供太少的建議可能無法充分利用加速的潛力，而提供太多的建議則可能導(dǎo)致大部分被拒絕，反而浪費計算資源。傳統(tǒng)的做法是使用固定的草稿長度，但這顯然不夠靈活。

OmniDraft引入了一個"接受率預(yù)測頭"，這個小型神經(jīng)網(wǎng)絡(luò)能夠預(yù)測每個詞匯建議被目標模型接受的可能性?；谶@些預(yù)測，系統(tǒng)會動態(tài)計算繼續(xù)提供更多建議的風險。如果預(yù)測顯示后續(xù)建議被拒絕的概率很高，系統(tǒng)就會提前停止，避免浪費計算資源。

這個預(yù)測機制使用了一種叫做"sigmoid函數(shù)"的數(shù)學(xué)工具來估計接受概率，然后計算所有建議中至少有一個被拒絕的總體概率。當這個概率超過預(yù)設(shè)的閾值時，系統(tǒng)就會停止生成更多建議。這就像一個精明的銷售員，能夠判斷客戶的興趣程度，在合適的時候結(jié)束推銷。

在在線學(xué)習環(huán)境中，這個預(yù)測頭面臨著一個特殊的挑戰(zhàn)：隨著草稿模型不斷改進，詞匯被接受的概率也在變化，這意味著預(yù)測頭需要同步調(diào)整。研究團隊提出了兩種解決方案。

第一種是"聯(lián)合訓(xùn)練"方法，讓草稿模型和預(yù)測頭同時更新。這種方法簡單直接，但可能因為兩個組件的學(xué)習速度不同而產(chǎn)生不穩(wěn)定性。第二種是"交替訓(xùn)練"方法，為預(yù)測頭維護一個更大的數(shù)據(jù)緩沖區(qū)，包含歷史數(shù)據(jù)，這樣可以提供更穩(wěn)定的訓(xùn)練環(huán)境。實驗表明，交替訓(xùn)練方法通常能獲得更好的性能。

四、實驗驗證與性能表現(xiàn)

為了驗證OmniDraft的有效性，研究團隊進行了大量的實驗測試。他們選擇了一個僅有68M參數(shù)的Llama小模型作為草稿員，并測試了它與多個不同大型模型的配合效果，包括Llama3-8B、Qwen2-7B和Vicuna-7B。

實驗涵蓋了四個不同的任務(wù)領(lǐng)域。在數(shù)學(xué)推理任務(wù)中，他們使用了GSM8K數(shù)據(jù)集，這個數(shù)據(jù)集包含了各種小學(xué)數(shù)學(xué)應(yīng)用題。在編程任務(wù)中，他們結(jié)合了MBPP和HumanEval兩個代碼生成數(shù)據(jù)集。在文本生成方面，他們使用了Alpaca指令跟隨數(shù)據(jù)集。在文本摘要任務(wù)中，他們采用了XSum新聞?wù)獢?shù)據(jù)集。

實驗結(jié)果令人印象深刻。在跨詞匯表的場景中，傳統(tǒng)的直接映射方法（SpDDM）幾乎無法工作，接受率通常在0.1左右，加速比甚至低于1，這意味著不僅沒有加速反而變慢了。而使用OmniDraft的LDM（直接映射訓(xùn)練）方法能將接受率提升到0.2-0.4的范圍，加速比達到1.2-1.6倍。

當加入n-gram損失項后，性能進一步提升。LDM + λLN-gram方法在所有任務(wù)上都表現(xiàn)出色，接受率通常能達到0.2-0.4，加速比在1.2-1.7倍之間。特別值得注意的是，在GSM8K數(shù)學(xué)推理任務(wù)上，無論是Llama3-8B還是Qwen2-7B作為目標模型，都能獲得最大的加速效果，這可能是因為數(shù)學(xué)推理任務(wù)具有更強的結(jié)構(gòu)性和可預(yù)測性。

研究團隊還測試了使用LoRA（Low-Rank Adaptation）技術(shù)的效果。LoRA是一種參數(shù)高效的微調(diào)方法，只需要更新模型的一小部分參數(shù)。實驗顯示，即使使用LoRA這種"輕量級"的訓(xùn)練方式，OmniDraft仍然能夠獲得顯著的性能提升，雖然效果略低于全參數(shù)微調(diào)，但對于資源受限的邊緣設(shè)備來說，這種方案提供了很好的性能和效率平衡。

在自適應(yīng)草稿長度調(diào)整的實驗中，研究團隊發(fā)現(xiàn)了一些有趣的現(xiàn)象。聯(lián)合訓(xùn)練方法雖然能夠獲得更高的接受率，但在某些任務(wù)上的加速比反而不如交替訓(xùn)練方法。這表明高接受率不一定直接轉(zhuǎn)化為更好的加速效果，可能是因為聯(lián)合訓(xùn)練方法容易低估接受概率，導(dǎo)致過早停止生成建議。

五、技術(shù)細節(jié)與實現(xiàn)要點

OmniDraft的實現(xiàn)涉及許多精巧的技術(shù)細節(jié)，這些細節(jié)的處理直接影響系統(tǒng)的最終性能。

在跨詞匯表映射方面，系統(tǒng)需要處理一個微妙的概率分布問題。當多個草稿詞匯片段被合并成一個目標詞匯時，如何計算這個合并詞匯的概率分布是一個關(guān)鍵問題。研究團隊提出了一個近似解決方案：對于合并后的n-gram詞匯，使用所有組成片段概率的乘積作為其概率；對于原本的前綴片段，從其原始概率中減去n-gram的概率，這樣可以避免概率質(zhì)量的重復(fù)計算。

這種處理方式雖然不是理論上的完美解決方案，但在實踐中證明是有效的。它避免了重新運行草稿模型來計算完整分布的計算開銷，同時保證了概率分布的基本合理性。

在在線學(xué)習的實現(xiàn)中，研究團隊采用了小批量更新的策略。系統(tǒng)不會在每個樣本后立即更新模型，而是積累一定數(shù)量的樣本后再進行批量更新。這種做法既保證了學(xué)習的及時性，又避免了過于頻繁的模型更新帶來的計算開銷。

對于n-gram緩存的管理，系統(tǒng)實現(xiàn)了一個高效的查找和更新機制。緩存使用哈希表結(jié)構(gòu)存儲，鍵是草稿詞匯序列，值是對應(yīng)的目標詞匯。為了控制內(nèi)存使用，系統(tǒng)還可以實現(xiàn)緩存淘汰策略，比如刪除使用頻率最低的條目。

在自適應(yīng)草稿調(diào)整中，停止閾值γ的選擇對性能有重要影響。研究團隊發(fā)現(xiàn)，不同任務(wù)需要不同的閾值設(shè)置。對于結(jié)構(gòu)化程度較高的任務(wù)（如數(shù)學(xué)推理和代碼生成），可以使用較為激進的閾值（γ=0.7），而對于更加開放性的任務(wù)（如文本生成），則需要更保守的閾值（γ=0.3）。

六、實驗深度分析與發(fā)現(xiàn)

通過深入的消融實驗，研究團隊揭示了OmniDraft各個組件的具體貢獻和相互作用。

n-gram緩存的有效性分析顯示了一個有趣的現(xiàn)象：即使在沒有專門訓(xùn)練的情況下，僅僅使用n-gram緩存作為后處理步驟，就能顯著改善跨詞匯表場景下的性能。在GSM8K任務(wù)的子集測試中，基礎(chǔ)的SpDDM方法接受率只有0.16，而加入n-gram后處理后，接受率提升到0.20，加速比從1.04x提升到1.16x。這證明了詞匯翻譯本身就是一個重要的瓶頸。

當進一步加入針對n-gram的專門訓(xùn)練后，性能得到更大幅度的提升。LDM + λLN-gram方法能夠?qū)⒔邮苈侍嵘?.46，加速比達到1.66x。這表明僅僅解決詞匯映射問題是不夠的，還需要通過訓(xùn)練來對齊概率分布。

研究團隊還分析了n-gram緩存中詞匯的分布特征。他們發(fā)現(xiàn)，雖然大部分n-gram的出現(xiàn)頻率很低，但確實存在一些高頻的有用模式。在編程任務(wù)中，常見的編程語法結(jié)構(gòu)（如"def "、"return "、"import "等）會被頻繁地從多個片段合并為單一詞匯。在數(shù)學(xué)任務(wù)中，數(shù)學(xué)符號和操作符的組合也表現(xiàn)出類似的模式。

關(guān)于不同損失函數(shù)的比較實驗揭示了另一個重要發(fā)現(xiàn)。研究團隊測試了多種訓(xùn)練目標的組合，包括純n-gram訓(xùn)練、直接映射KL散度訓(xùn)練、以及各種混合方案。結(jié)果顯示，純n-gram訓(xùn)練往往不穩(wěn)定，這可能是因為n-gram詞匯在數(shù)據(jù)中的占比相對較小，缺乏足夠的監(jiān)督信號。而混合訓(xùn)練方案不僅性能更好，訓(xùn)練過程也更加穩(wěn)定。

在LoRA微調(diào)的秩選擇實驗中，研究團隊測試了從8到128的不同秩值。結(jié)果顯示，隨著秩的增加，性能確實有所提升，但在秩達到32之后，改善變得很小?？紤]到參數(shù)效率和部署便利性，秋值32提供了最佳的性能-效率權(quán)衡。

七、應(yīng)用前景與實際意義

OmniDraft技術(shù)的意義遠超出了技術(shù)層面的創(chuàng)新，它為人工智能的實際應(yīng)用開辟了新的可能性。

在邊緣計算場景中，OmniDraft特別有價值。手機、平板電腦等移動設(shè)備的計算能力有限，無法高效運行大型語言模型。通過OmniDraft，用戶可以在設(shè)備上運行一個小型的通用草稿模型，然后將其與云端的各種大型模型配合使用。這種架構(gòu)既保證了響應(yīng)速度，又提供了模型選擇的靈活性。

對于企業(yè)級應(yīng)用，OmniDraft解決了模型部署和維護的復(fù)雜性問題。傳統(tǒng)上，如果一個組織想要使用多種不同的大型模型，就需要為每種模型單獨訓(xùn)練和維護對應(yīng)的草稿模型。有了OmniDraft，只需要維護一個通用的草稿模型即可，大大降低了運維成本。

在個性化服務(wù)方面，OmniDraft的在線學(xué)習能力使得系統(tǒng)能夠根據(jù)特定用戶或應(yīng)用場景進行定制化優(yōu)化。比如，一個專門處理法律文件的應(yīng)用可以讓草稿模型逐漸學(xué)習法律術(shù)語的使用模式，提高在該領(lǐng)域的效率。

研究團隊還展示了LoRA適配器切換的可能性。通過為不同的任務(wù)和目標模型訓(xùn)練不同的LoRA適配器，單個草稿模型可以快速切換到不同的"專業(yè)模式"。這就像一個多面手，能夠根據(jù)需要快速轉(zhuǎn)換角色。

八、技術(shù)挑戰(zhàn)與未來方向

盡管OmniDraft取得了顯著的成果，但研究團隊也誠實地指出了當前方案的一些局限性和未來需要解決的問題。

首先是穩(wěn)定性問題。由于系統(tǒng)只在數(shù)據(jù)流的單次迭代中進行學(xué)習，對于分布差異較大的新數(shù)據(jù)，仍然可能出現(xiàn)性能不穩(wěn)定的情況。未來的改進可能需要引入更sophisticated的適應(yīng)策略，比如元學(xué)習或少樣本學(xué)習技術(shù)。

內(nèi)存管理是另一個實際部署中需要考慮的問題。雖然n-gram緩存通常不會太大，但在資源極度受限的邊緣設(shè)備上，仍然需要精心設(shè)計緩存淘汰策略。研究團隊建議可以基于使用頻率、最近訪問時間或任務(wù)相關(guān)性來設(shè)計智能的緩存管理算法。

特殊詞匯的處理也是一個挑戰(zhàn)。當前的方案主要針對常規(guī)文本詞匯設(shè)計，對于特殊符號、多語言混合文本或者多模態(tài)內(nèi)容（如包含圖像的輸入），還需要額外的處理機制。

在跨詞匯表場景中明確結(jié)合自適應(yīng)草稿長度調(diào)整也是一個有趣的未來方向。當前的實驗主要在同詞匯表場景中測試了自適應(yīng)調(diào)整，而在跨詞匯表場景中，由于n-gram合并的存在，自適應(yīng)調(diào)整的策略可能需要相應(yīng)的修改。

九、技術(shù)實現(xiàn)的工程細節(jié)

對于想要復(fù)現(xiàn)或應(yīng)用這項技術(shù)的開發(fā)者，研究團隊提供了詳細的實現(xiàn)指導(dǎo)。

在硬件要求方面，實驗使用了NVIDIA A100 GPU，但研究團隊指出，對于實際部署，特別是邊緣設(shè)備部署，硬件要求可以大大降低。草稿模型本身只有68M參數(shù)，即使在CPU上也能獲得可接受的推理速度。

訓(xùn)練超參數(shù)的選擇經(jīng)過了仔細的調(diào)優(yōu)。學(xué)習率設(shè)置為1e-4到2e-5之間，使用AdamW優(yōu)化器，權(quán)重衰減根據(jù)是否使用LoRA進行調(diào)整。批大小設(shè)置為8，這在內(nèi)存使用和訓(xùn)練穩(wěn)定性之間提供了良好的平衡。

在數(shù)據(jù)預(yù)處理方面，所有實驗都使用了極低的溫度設(shè)置（0.01），這確保了生成過程的確定性，便于分析和調(diào)試。對于實際應(yīng)用，可能需要根據(jù)具體場景調(diào)整溫度參數(shù)。

混合損失中的λ參數(shù)統(tǒng)一設(shè)置為0.2，這個值在所有測試任務(wù)中都表現(xiàn)良好。研究團隊指出，雖然針對特定任務(wù)可能可以找到更優(yōu)的λ值，但0.2提供了很好的通用性。

代碼實現(xiàn)使用了PyTorch 2.1.0框架，支持混合精度訓(xùn)練（FP16）以提高訓(xùn)練效率。整個系統(tǒng)的模塊化設(shè)計使得各個組件可以獨立測試和優(yōu)化。

說到底，OmniDraft代表了人工智能系統(tǒng)設(shè)計中的一個重要理念轉(zhuǎn)變：從專用化轉(zhuǎn)向通用化，從靜態(tài)優(yōu)化轉(zhuǎn)向動態(tài)適應(yīng)。這項由高通AI研究院開發(fā)的技術(shù)不僅解決了一個具體的技術(shù)難題，更為整個AI加速領(lǐng)域提供了新的思路。

通過巧妙的跨詞匯表翻譯、在線蒸餾學(xué)習和自適應(yīng)草稿調(diào)整，OmniDraft證明了一個小型模型確實可以成為多個大型模型的"萬能助手"。實驗結(jié)果顯示，僅有68M參數(shù)的草稿模型就能為各種7B-8B參數(shù)的大型模型提供1.5到2倍的加速效果，這在邊緣計算和資源受限環(huán)境中具有重要的實用價值。

更重要的是，這項技術(shù)的開源友好設(shè)計和詳細的實現(xiàn)指導(dǎo)，為整個社區(qū)提供了一個可以直接應(yīng)用和進一步改進的基礎(chǔ)。隨著移動設(shè)備算力的不斷提升和AI應(yīng)用的日益普及，OmniDraft這樣的通用加速技術(shù)將在讓AI更加普惠和易用方面發(fā)揮重要作用。對于任何對AI加速技術(shù)感興趣的研究人員或開發(fā)者，這項研究都提供了寶貴的參考和啟發(fā)。感興趣的讀者可以通過arXiv:2507.02659v1獲取完整的技術(shù)細節(jié)和實現(xiàn)代碼。

Q&A

Q1：OmniDraft是什么？它解決了什么問題？ A：OmniDraft是高通AI研究院開發(fā)的通用AI加速框架，它讓一個小型"草稿員"模型能夠為多種不同的大型AI模型提供加速服務(wù)。主要解決了傳統(tǒng)方案中草稿模型只能配合特定目標模型使用的局限性，實現(xiàn)了"一個草稿員服務(wù)所有大模型"的目標。

Q2：OmniDraft會不會替代現(xiàn)有的AI加速方案？ A：不會完全替代，但會顯著改善現(xiàn)有方案的靈活性和效率。它特別適合需要在多種AI模型間切換的應(yīng)用場景，以及資源受限的邊緣設(shè)備。對于單一模型的專用加速，傳統(tǒng)方案仍然有其價值。

Q3：普通開發(fā)者能使用OmniDraft嗎？有什么技術(shù)要求？ A：可以使用。研究團隊在論文中提供了詳細的實現(xiàn)指導(dǎo)，代碼基于PyTorch框架。雖然實驗使用了高端GPU，但實際部署時硬件要求不高，甚至可以在CPU上運行小型草稿模型。開發(fā)者可以通過arXiv獲取完整技術(shù)文檔。