哈嘍！伙伴們，我是小智，你們的AI向?qū)?。歡迎來到每日的AI學(xué)習(xí)時(shí)間。今天，我們將一起深入AI的奇妙世界，探索“小米黑科技！小愛同學(xué)竟在端側(cè)跑大模型”，并學(xué)會(huì)本篇文章中所講的全部知識(shí)點(diǎn)。還是那句話“不必遠(yuǎn)征未知，只需喚醒你的潛能！”跟著小智的步伐，我們終將學(xué)有所成，學(xué)以致用，并發(fā)現(xiàn)自身的更多可能性。話不多說，現(xiàn)在就讓我們開始這場(chǎng)激發(fā)潛能的AI學(xué)習(xí)之旅吧。

小米黑科技！小愛同學(xué)竟在端側(cè)跑大模型：

隨著大模型能力持續(xù)提升，如何將其有效部署到端側(cè)設(shè)備，成為產(chǎn)業(yè)界面臨的重要工程挑戰(zhàn)。手機(jī)、車載、IoT 等設(shè)備對(duì)模型體積、推理時(shí)延、功耗和更新機(jī)制都提出了極高要求，也讓端側(cè)推理成為融合系統(tǒng)優(yōu)化、模型壓縮和軟硬件協(xié)同的復(fù)雜問題。

近日，InfoQ 對(duì)話 小米 / 小愛同學(xué)端側(cè) AI 負(fù)責(zé)人楊永杰，帶你深入了解其團(tuán)隊(duì)如何從架構(gòu)、系統(tǒng)和算法三層著手，推進(jìn)大模型在端側(cè)的工程化落地。他們通過自研推理框架實(shí)現(xiàn)了 180 tokens/s 的實(shí)時(shí)推理性能，借助 LoRA 插件化 + 共享基座模型 支持多業(yè)務(wù)復(fù)用，并在推理性能和資源占用上實(shí)現(xiàn)了極致優(yōu)化。

面向未來，楊永杰認(rèn)為，端側(cè)大模型的突破將依賴兩方面：一是面向大模型優(yōu)化的硬件能力提升，二是模型架構(gòu)的演進(jìn)，比如 Linear Attention 架構(gòu)。

6 月 27～28 日，在即將于北京舉辦的 AICon 全球人工智能開發(fā)與應(yīng)用大會(huì)上，楊永杰將發(fā)表演講《小愛同學(xué)在高性能端側(cè)大模型推理的實(shí)踐》，分享其團(tuán)隊(duì)自研的大模型推理框架在實(shí)際業(yè)務(wù)中的落地實(shí)踐。圍繞架構(gòu)設(shè)計(jì)、量化策略、并行解碼、跨芯片兼容、熱更新策劃等方面展開，結(jié)合真實(shí)的系統(tǒng)優(yōu)化痛點(diǎn)，解析端側(cè)大模型商業(yè)化的關(guān)鍵路徑。

敬請(qǐng)期待：
https://aicon.infoq.cn/2025/beijing/presentation/6444

InfoQ：端側(cè)大模型已成為當(dāng)前 AI 部署的重點(diǎn)方向，尤其在隱私、安全和離線能力方面具備顯著優(yōu)勢(shì)。但從您的視角看，真正實(shí)現(xiàn)商業(yè)化部署仍面臨哪些核心技術(shù)門檻？
楊永杰： 確實(shí)現(xiàn)在大模型很火，端側(cè)也被很多人看作是未來的重要方向，但在商業(yè)化落地這方面推進(jìn)得還是比較慢的，這主要是受到一些客觀因素的影響。

第一個(gè)方面，是端側(cè)設(shè)備本身的資源限制。無論是算力還是帶寬，相比云端來說都是比較有限的。如果要把一個(gè)大模型部署到端上，就必須對(duì)模型進(jìn)行較低比特?cái)?shù)的量化，才有可能在這些設(shè)備上運(yùn)行。

但即使做了低比特量化，手機(jī)等端側(cè)設(shè)備上可商業(yè)化部署的模型可能也難以超過 4B 參數(shù)量，且低比特量化會(huì)導(dǎo)致模型效果損失。在這個(gè)量化精度下，大模型的整體效果相比云端仍有較大差距。畢竟云端的資源沒有這些限制，能夠支持更大、更強(qiáng)的模型。

第二個(gè)方面是，大模型本身的發(fā)展還處于快速變化的階段。現(xiàn)在模型的迭代節(jié)奏很快，幾乎每隔一段時(shí)間就有新的進(jìn)展。在云端，這種變化可以很快跟上，比如公司可以快速更新模型版本。

但端側(cè)的設(shè)備畢竟在用戶手上，模型更新相對(duì)滯后，往往會(huì)慢一拍。而且更新機(jī)制也受限，比如要看用戶是否主動(dòng)下載更新，或者依賴廠商推送更新包，整體更新策略沒有云端靈活，云端完全可以由公司自主控制。

所以，從目前來看，大模型的發(fā)展還沒有到一個(gè)“相對(duì)穩(wěn)定”的階段。不像傳統(tǒng)模型發(fā)展成熟之后，各家公司會(huì)因?yàn)槌杀净驁?chǎng)景要求，逐步考慮往端側(cè)遷移。現(xiàn)在的端側(cè)大模型更像是在做技術(shù)積累，是面向未來的準(zhǔn)備。

如果將來端側(cè)的計(jì)算能力進(jìn)一步提升，或者云端模型逐漸穩(wěn)定下來，那時(shí)可能就會(huì)從“探索”階段走向“部署”階段。尤其當(dāng)部署成本成為關(guān)鍵因素時(shí)，端側(cè)就會(huì)成為更有吸引力的選項(xiàng)。而我們現(xiàn)在做的更多是提前技術(shù)布局，為之后的落地做好準(zhǔn)備。

InfoQ：您所在團(tuán)隊(duì)自研了大模型推理框架，并實(shí)現(xiàn)了超過 180 tokens/s 的端側(cè)推理速度，在端側(cè)這一資源受限環(huán)境下達(dá)到該指標(biāo)，能否分享一下背后的系統(tǒng)級(jí)與模型級(jí)優(yōu)化策略？
楊永杰： 是的，我們團(tuán)隊(duì)自研了一個(gè)用于大模型推理的框架。之所以選擇自研，主要是因?yàn)槟壳搬槍?duì)端側(cè)的大模型推理框架非常少，開源的方案更是寥寥無幾，即使有，往往也是針對(duì)端側(cè) CPU 或 GPU 的。至于 NPU，由于各大芯片廠商通常不會(huì)開放接口，導(dǎo)致 NPU 上的推理框架往往只能由芯片廠商自己開發(fā)和維護(hù)。

但僅靠芯片廠商的解決方案，很多優(yōu)化手段往往無法做到云端那種深度。相比之下，云端框架（如 vLLM、SGLang 等）大多是開源的，有廣泛的社區(qū)貢獻(xiàn)，優(yōu)化手段也非常豐富。而端側(cè)不僅缺少統(tǒng)一的框架，而且設(shè)備差異性大，各個(gè)廠商的解決方案分散、實(shí)用性強(qiáng)，但往往缺乏系統(tǒng)性打磨與性能極致優(yōu)化。

我們做了從框架層全棧自研的工作，每一個(gè)模塊的性能都進(jìn)行了細(xì)致的優(yōu)化。此外，我們也借鑒了很多來自云端的成熟優(yōu)化手段，并針對(duì)端側(cè)進(jìn)行了適配和改進(jìn)。

舉幾個(gè)例子：

動(dòng)態(tài)輸入與動(dòng)態(tài) context 支持：云端推理天然支持動(dòng)態(tài)輸入，而端側(cè)的 NPU 通常只能使用靜態(tài)圖，輸入尺寸固定。傳統(tǒng)做法是將輸入 padding 到固定長(zhǎng)度，比如用 128 token 固定輸入長(zhǎng)度，即使真實(shí)輸入只有 100 也要補(bǔ)足，這樣會(huì)浪費(fèi)大量計(jì)算資源。我們通過框架級(jí)的能力，讓模型在保持靜態(tài)圖性能的前提下支持動(dòng)態(tài)輸入，自動(dòng)切分輸入尺寸，從而大幅提升了資源利用率和吞吐率。

投機(jī)推理（Speculative Decoding）優(yōu)化：在云端，像 Medusa 或 Eagle 等方案通常能做到 2～3 倍的加速。而我們通過自研策略，在端側(cè)實(shí)現(xiàn)了高達(dá) 7～10 倍的 decoding 加速，大幅緩解了端側(cè)推理慢的問題。舉例來說，原本在資源受限的設(shè)備上，推理速度可能只有二十幾 tokens/s，通過投機(jī)推理可以提升到 200 tokens/s，這一速度已經(jīng)可以媲美部分云端場(chǎng)景。

量化與指令級(jí)優(yōu)化：大部分 CPU 操作通過 Neon 指令集實(shí)現(xiàn)加速，比如量化與反量化、sampling 采樣等。

目前，我們的框架已在車載等端側(cè)場(chǎng)景中實(shí)現(xiàn)了落地，支持包括文本和多模態(tài)在內(nèi)的多個(gè)大模型能力。細(xì)節(jié)部分后續(xù)可以在大會(huì)分享時(shí)進(jìn)一步展開。

InfoQ：小愛同學(xué)作為一個(gè)語音助手，承載了語音控制、多輪對(duì)話、智能家居等多種任務(wù)。端側(cè)大模型在這些不同場(chǎng)景下對(duì)響應(yīng)時(shí)延、并發(fā)能力有何特殊要求？這些業(yè)務(wù)需求對(duì)推理架構(gòu)設(shè)計(jì)起到了怎樣的約束作用？
楊永杰： 對(duì)于小愛來說，目前我們還沒有非常強(qiáng)的并發(fā)需求，但這個(gè)在未來可能會(huì)出現(xiàn)。就現(xiàn)有業(yè)務(wù)來看，小愛一個(gè)完整的請(qǐng)求鏈路可以分為三個(gè)階段：感知、理解和滿足。也就是說，設(shè)備需要先感知到用戶的輸入，然后再進(jìn)行語義理解，最后給出響應(yīng)來滿足用戶需求。這個(gè)流程本身是串行執(zhí)行的，所以在同一條鏈路上，并發(fā)的需求并不強(qiáng)。

當(dāng)然，也不是說完全沒有并發(fā)，比如有些任務(wù)可能會(huì)涉及并發(fā)執(zhí)行，但這種情況目前還不多。另一方面，我們的模型能力也不僅服務(wù)于小愛本身，還會(huì)被其他業(yè)務(wù)共用，在不同業(yè)務(wù)之間就可能出現(xiàn)并發(fā)沖突。

為了應(yīng)對(duì)這種情況，我們?cè)诩軜?gòu)上做了并發(fā)管理。但目前端側(cè)設(shè)備的 NPU 本身不支持并發(fā)推理，它的硬件設(shè)計(jì)就是以串行執(zhí)行為主，不像云端那樣可以天然支持多個(gè)請(qǐng)求同時(shí)并發(fā)處理。

雖然理論上可以嘗試使用 multi-batch 的方式提升并發(fā)處理效率，但在端側(cè)這種算力受限的環(huán)境下，multi-batch 實(shí)際上的收益非常有限。我們也做過實(shí)驗(yàn)，因?yàn)槎藗?cè)單條請(qǐng)求已經(jīng)接近設(shè)備算力的上限，增加 batch 數(shù)反而會(huì)帶來額外負(fù)擔(dān)。例如，在預(yù)填階段（prefill）已經(jīng)接近滿負(fù)載，再加一條并不會(huì)帶來實(shí)質(zhì)提升，幾乎和一條條串行處理沒區(qū)別。

所以相較于云端，端側(cè)的并發(fā)能力天然就弱很多。但在實(shí)際業(yè)務(wù)調(diào)用中，我們還是會(huì)通過調(diào)度和切換機(jī)制，盡量保障各條業(yè)務(wù)鏈路在預(yù)期時(shí)間內(nèi)完成推理，避免某條請(qǐng)求因?yàn)橘Y源沖突而變得特別慢。

InfoQ：面對(duì)多任務(wù)、多業(yè)務(wù)的實(shí)際場(chǎng)景，您團(tuán)隊(duì)采用了“共享基座架構(gòu)”的方案。能否大概介紹一下，該架構(gòu)方案是如何支持多個(gè)業(yè)務(wù)并發(fā)推理的，同時(shí)又不犧牲系統(tǒng)性能？
楊永杰： 我們之所以要做共享基座架構(gòu)，主要是因?yàn)槎藗?cè)的資源確實(shí)有限，不僅是算力有限，存儲(chǔ)空間和內(nèi)存也很受限制。

比如一臺(tái) 12GB 內(nèi)存的手機(jī)，部署一個(gè) 4B 的大模型可能就需要接近 3GB 的內(nèi)存。表面上看可以放兩個(gè)模型，但實(shí)際上手機(jī)或車載設(shè)備上還有很多其他業(yè)務(wù)，它們也要占用內(nèi)存資源。真正能留給大模型使用的空間可能連 3GB 都不到。

在這樣的限制下，我們就無法為每個(gè)業(yè)務(wù)分別部署一個(gè)獨(dú)立模型。所以我們采用了“共享基座模型 + 插件化能力”的思路，讓多個(gè)業(yè)務(wù)共用同一個(gè)基礎(chǔ)模型。

具體做法是，我們?yōu)樗袠I(yè)務(wù)統(tǒng)一選擇一個(gè)基礎(chǔ)的大模型，然后針對(duì)不同業(yè)務(wù)單獨(dú)訓(xùn)練對(duì)應(yīng)的 LoRA 模塊。例如：

A 業(yè)務(wù)針對(duì)這個(gè)基礎(chǔ)模型訓(xùn)練一個(gè)專屬的 LoRA；

B 業(yè)務(wù)則訓(xùn)練另一個(gè) LoRA。

運(yùn)行時(shí)，如果是 A 業(yè)務(wù)的請(qǐng)求到來，我們就加載基礎(chǔ)模型 + A 的 LoRA 進(jìn)行推理；當(dāng) B 業(yè)務(wù)請(qǐng)求到來時(shí)，我們就卸載 A 的 LoRA，換上 B 的 LoRA。這樣，在只保留一個(gè)基礎(chǔ)模型的前提下，我們可以動(dòng)態(tài)切換不同的業(yè)務(wù)能力，從而支持多個(gè)任務(wù)的并發(fā)調(diào)用。

這套方案的核心就是借助 LoRA 插件化、輕量化的特性，實(shí)現(xiàn)“參數(shù)共享 + 差異定制”，從而在資源有限的設(shè)備上支持多個(gè)業(yè)務(wù)。這種共享基座架構(gòu)在內(nèi)存利用率和擴(kuò)展能力上都比較有優(yōu)勢(shì)。

當(dāng)然，里面還有不少實(shí)現(xiàn)上的細(xì)節(jié)和挑戰(zhàn)，實(shí)際落地過程并不像聽起來那么簡(jiǎn)單。

InfoQ：端側(cè)設(shè)備硬件異構(gòu)嚴(yán)重，適配難度大。你們的推理框架在跨芯片平臺(tái)部署上做了哪些模塊化、通用化的設(shè)計(jì)，以確保兼容性與性能的平衡？
楊永杰： 在這方面其實(shí)我們并沒有采用特別的方案。因?yàn)閺恼w設(shè)計(jì)思路上看，這跟傳統(tǒng)模型框架處理多后端的問題是類似的。

到了大模型階段，雖然模型規(guī)模變大了，但它在框架設(shè)計(jì)層面上，其實(shí)并沒有本質(zhì)性的變化。相反，很多大模型的優(yōu)化技術(shù)，更多是針對(duì)模型本身的結(jié)構(gòu)特性，或者是在框架層面做的，而與具體底層硬件綁定的程度反而沒有那么深。

這也意味著，框架層可以更容易抽象出一些通用的接口，使模型能夠在不同的硬件平臺(tái)、不同后端之間遷移。相比傳統(tǒng)模型框架，反而會(huì)更容易實(shí)現(xiàn)一定程度上的通用性和跨平臺(tái)部署能力。

所以我們的策略也是在此基礎(chǔ)上，進(jìn)行模塊化、后端解耦的設(shè)計(jì)，來適應(yīng)多種端側(cè)芯片平臺(tái)的部署需求。

InfoQ：在性能優(yōu)化方面，你們使用了如低比特量化、并行解碼、帶寬控制等技術(shù)。實(shí)際工程中，這些優(yōu)化組合的優(yōu)先級(jí)是如何確定的？是否有一些踩過的坑可以分享？
楊永杰： 我們現(xiàn)在在做優(yōu)化時(shí)，基本上不同的技術(shù)是可以同時(shí)作用的，不會(huì)出現(xiàn)只能用 A 而不能用 B 的情況。比如你提到的低比特量化、并行解碼、帶寬控制，這些技術(shù)我們都是盡可能組合使用的。

以并行解碼為例，我們內(nèi)部可能有多種策略，比如策略 A 和策略 B，我們不僅能分別使用，也可以將它們?nèi)诤显谝黄?。我們?huì)優(yōu)先實(shí)現(xiàn)那些技術(shù)價(jià)值較大、適用面更廣、和其他手段之間沒有沖突的優(yōu)化方式。

這背后的一個(gè)判斷標(biāo)準(zhǔn)是——這個(gè)優(yōu)化能不能在多個(gè)業(yè)務(wù)場(chǎng)景中復(fù)用，以及它是否容易與其他優(yōu)化組合應(yīng)用。如果能覆蓋更多業(yè)務(wù)，或者實(shí)現(xiàn)起來不增加系統(tǒng)復(fù)雜度，我們就會(huì)優(yōu)先采用。

當(dāng)然，未來也可能出現(xiàn)某些技術(shù)只適用于特定業(yè)務(wù)的情況，比如某項(xiàng)優(yōu)化只對(duì) A 業(yè)務(wù)有效，對(duì) B 業(yè)務(wù)沒有意義。遇到這種情況，我們會(huì)把該能力封裝成業(yè)務(wù)可選的配置項(xiàng)。部署時(shí)會(huì)提示這個(gè)業(yè)務(wù)適合用什么技術(shù)，但我們也會(huì)盡量避免讓這種“特定綁定”的優(yōu)化太多，否則會(huì)讓框架變復(fù)雜，降低整體的可維護(hù)性和易用性。

因此在框架設(shè)計(jì)上，我們做了模塊化、分層解耦的處理。比如你在上層調(diào)用一個(gè)能力時(shí)，底層的適配邏輯已經(jīng)統(tǒng)一封裝好了，不需要上層關(guān)心用的是哪套后端邏輯，開發(fā)時(shí)也不需要為每種技術(shù)寫一套邏輯。

舉一個(gè)更具體的例子：我們也實(shí)現(xiàn)了 prompt cache。它能緩存用戶輸入的 prompt 前綴，減少重復(fù)計(jì)算。但不是所有業(yè)務(wù)都需要用。比如有些業(yè)務(wù) prompt 很短，不緩存也無所謂；有些業(yè)務(wù)每次都要帶一大段前綴，那我們就建議他開啟 cache。

這項(xiàng)功能的配置也非常簡(jiǎn)單，就是在部署配置文件里啟用相關(guān)參數(shù)，工程人員不需要額外操作。你只需要告訴系統(tǒng)緩存哪個(gè) prompt、存在哪個(gè)地址即可，整個(gè)流程對(duì)使用方是透明的。

當(dāng)然，效果上也會(huì)因業(yè)務(wù)而異。有的業(yè)務(wù)用 cache 后能省幾十個(gè) token 的計(jì)算；有的長(zhǎng) prompt 場(chǎng)景則能節(jié)省上百 token，推理延遲可能能減少上百毫秒甚至幾百毫秒。我們一般會(huì)根據(jù)對(duì)業(yè)務(wù)的了解，給出推薦的優(yōu)化策略。

InfoQ：結(jié)合當(dāng)前產(chǎn)業(yè)需求與技術(shù)路徑，未來您認(rèn)為端側(cè)大模型最具突破性的方向或潛力業(yè)務(wù)場(chǎng)景會(huì)在哪里？下一階段技術(shù)突破的核心目標(biāo)可能集中在什么方向？
楊永杰： 前面提到的挑戰(zhàn)有相當(dāng)一部分其實(shí)都來自于端側(cè)硬件算力不足。這也直接導(dǎo)致我們?cè)诓渴饡r(shí)要做很多取舍，比如低比特量化、嚴(yán)格的資源控制等，都是為了適配端側(cè)有限的計(jì)算能力。

但這些優(yōu)化都有上限。舉例來說，現(xiàn)在即便我們可以在一些設(shè)備上跑起 7B 的大模型，但無法真正落地，因?yàn)樗\(yùn)行時(shí)會(huì)占用太多資源，比如功耗高，或擠占了其他業(yè)務(wù)的資源，導(dǎo)致系統(tǒng)卡頓。這些問題在端側(cè)是很現(xiàn)實(shí)的。

所以我認(rèn)為未來一個(gè)關(guān)鍵的突破方向，其實(shí)在于硬件本身的進(jìn)步。這也是很多芯片廠商已經(jīng)在做的事情——類似于當(dāng)年傳統(tǒng)模型興起時(shí)，芯片廠商紛紛推出支持的 NPU?，F(xiàn)在大模型熱度已持續(xù)兩年多，新一代面向大模型的端側(cè)芯片很可能即將出現(xiàn)。

一旦這類硬件可用，端側(cè)模型的能力會(huì)大幅增強(qiáng)，更多業(yè)務(wù)也就有機(jī)會(huì)真正落地。

另一個(gè)值得關(guān)注的方向，是模型架構(gòu)本身的變化。當(dāng)前主流大模型基本都基于 Transformer 架構(gòu)，它是自回歸式的，這帶來了一個(gè)問題：當(dāng) context 變長(zhǎng)時(shí)，資源占用會(huì)隨之顯著增加，特別是要保存 KV cache 時(shí)，內(nèi)存和算力壓力都會(huì)不斷上升。

現(xiàn)在業(yè)界在探索的一類新方向是 Linear Attention，代表性架構(gòu)如 Mamba、RWKV，它們嘗試在保持模型能力的同時(shí)，減少對(duì)內(nèi)存的增長(zhǎng)需求。

這類架構(gòu)的一個(gè)優(yōu)勢(shì)是：內(nèi)存使用與輸入長(zhǎng)度無關(guān)，可以更好地支持長(zhǎng)文本推理，特別適合資源敏感的端側(cè)場(chǎng)景。雖然目前這類架構(gòu)的效果整體還不如 Transformer，但由于研究熱度高、論文持續(xù)涌現(xiàn)，我個(gè)人也很期待未來會(huì)有實(shí)用級(jí)別的突破。

尤其在端側(cè)業(yè)務(wù)中，比如小愛目前的交互長(zhǎng)度普遍不長(zhǎng)，主要是一問一答形式，但我們也看到一些新趨勢(shì)，像多模態(tài)任務(wù)的輸入長(zhǎng)度會(huì)變得很長(zhǎng)。

例如：一張圖片轉(zhuǎn)成 token 可能就有 64 個(gè)；視頻場(chǎng)景中，多個(gè)幀一起輸入時(shí)，輸入長(zhǎng)度會(huì)成倍增長(zhǎng)，context 就會(huì)迅速拉長(zhǎng)。這種情況下，傳統(tǒng) Transformer 對(duì)資源的需求就成了瓶頸，而 Linear Attention 的方向可能會(huì)是一個(gè)很好的解法。

所以總結(jié)來看，一個(gè)是硬件層面的能力突破，一個(gè)是模型架構(gòu)的算法演進(jìn)，這兩個(gè)方向我都認(rèn)為非常關(guān)鍵，也都很值得期待。

嘿，伙伴們，今天我們的AI探索之旅已經(jīng)圓滿結(jié)束。關(guān)于“小米黑科技！小愛同學(xué)竟在端側(cè)跑大模型”的內(nèi)容已經(jīng)分享給大家了。感謝你們的陪伴，希望這次旅程讓你對(duì)AI能夠更了解、更喜歡。謹(jǐn)記，精準(zhǔn)提問是解鎖AI潛能的鑰匙哦！如果有小伙伴想要了解學(xué)習(xí)更多的AI知識(shí)，請(qǐng)關(guān)注我們的官網(wǎng)“AI智研社”，保證讓你收獲滿滿呦！