無問芯穹曾書霖談 AI 2.0 時代的大模型推理：從模型到硬件的協同優化

演講嘉賓｜曾書霖 博士

編輯｜Kitty

策劃｜QCon 全球軟件開發大會

AI 2.0 模型對算力和數據的需求激增，導致硬件系統的能耗開銷逐漸“供不應求”，亟需軟硬協同為 AI 行業提供高質量的 AI 系統能效（ Tokens/J） 。本文整理自無問芯穹總經理曾書霖博士在 2025 年 QCon 全球軟件開發大會（上海站） 的演講 “AI 2.0 時代的大模型推理：從模型到硬件的協同優化”。他介紹了軟硬件協同優化以提升智能系統能效的研究成果，包括模型稀疏量化壓縮、高效推理系統設計與大模型加速器設計。并且結合華為昇騰集群的工程實踐，探討下一代 AI 推理系統的演進趨勢。

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

各位好，今天我想和大家介紹一下我們無問芯穹在大模型時代圍繞大模型推理所開展的一些實踐工作，以及我們觀察到的一些趨勢。我將主要從云和端兩個維度展開，并結合我們在華為昇騰集群上進行優化的實踐經驗進行分享。

在開始之前，我想先簡要回顧一下大的背景。我們相信，大家聚集在這里交流今天的工程實踐，是因為我們都認同我們正處于一個非常重要的時間節點。通過人工智能，尤其是大模型技術，我們有望對整個產業進行深刻的變革。在大模型時代，最核心的工具是一套大模型算法以及底層的算力芯片，它們共同實現新的勞動價值創造。而我們最核心的任務是通過軟硬協同，將上層的算法與底層的芯片通過中間的模型推理軟件棧連接起來，以此作為放大 AI 產業價值的關鍵。這涉及如何在各種芯片和算力集群上進行有效的資源調度，以及如何優化模型在芯片上的推理過程，包括模型壓縮、圖算融合以及云和端的協同。接下來，我將分別從云和端兩個維度詳細介紹我們所開展的工作。

1 以智能革命，引領大模型推理范式變革

快速回顧一下過去十年 AI 發展的一些重要節點。相信各位對大模型的典型發展趨勢也十分熟悉，無論是在國內還是國外。推動這些模型不斷演進、不斷涌現出新的創意結構的核心因素，其實是底層堅實的 AI 基礎設施，包括芯片的演進以及整個推理基礎設施的演進。

從發展歷程來看，2022 年大家還在關注如何制定一個良好的預訓練方案。隨后，通過 Post-Training 使模型能夠更好地適應各種垂直領域以及與人類思維方式對齊。如今，我們已經進入了一個新的階段，即推理的規模拓展階段。這一階段的關鍵是如何將更優質的模型應用于各種垂直領域場景，以及在長文本和更大規模的推理服務中進行拓展，從而真正實現不同行業的落地應用。

在這一過程中，我們觀察到一些重要的趨勢。首先是推理范式的變化。從最初的逐 Token 推理，到現在基于 Agent 和強化學習的引入，推理計算需求發生了顯著變化。從最初的幾倍增長，到現在由于引入了長上下文推理等因素，算力需求已經增長了 10 到 100 倍。這對于從事基礎設施建設，尤其是推理優化的我們來說，無疑帶來了更大的挑戰。

我們探討模型推理，從產業界的角度來看，未來對算力的需求正逐漸從訓練轉向推理。今年年初，在 NVIDIA 的 GTC 大會上，黃仁勛也提到，未來我們需要更大規模的集群來支撐大模型在各行業的落地。集群規模越大，優化空間越高，由此帶來的企業收益或 AI 應用的效益也會越大。然而，這一切都離不開一套強大的 AI 推理基礎設施的支撐。

接下來，我將從幾個方面展開分析。首先，我們來看優化的對象。端側包括手機、PC 等小型設備，而云側則涵蓋一體機和數據中心的集群。我們對應用及其理論性能進行了分析。從端側來看，現有的手機或 PC 設備在運行本地 3B 或 7B 模型時，推理性能大致在每秒 10 到 20 個 Token 左右，基本能滿足正常對話需求。但如今，人們不再滿足于單純的對話，還希望 AI 能處理更復雜的任務，如日程規劃、屏幕內容分析等。這些任務所需的 Token 量，隨著 Test-Time Scaling 和多模態的發展，相比現有能力存在 1 到 2 個量級的差距。如何彌補這一差距，是端側需要思考的問題。而在云側，無論是單臺機器還是大規模集群，核心都是要充分釋放芯片、存儲和互聯的能力，盡可能用滿集群的算力資源。目前，一些運行 DeepSeek 的推理系統，其實際性能與理論值仍有 2 到 3 倍的差距，這需要我們從基礎設施層面去提高利用率，挖掘芯片的每一分潛力。

從實際應用場景來看，端側和云側各有特點。端側主要針對單用戶、少請求場景，需要將單個模型、單個用戶請求的性能優化到極致。這是一個資源受限的場景，手機和 PC 的功耗、芯片算力、存儲和帶寬都是有限的。如何選擇合適的模型，使其與芯片協同，滿足端側需求，是一個關鍵問題。云側則從基礎設施角度出發，要考慮多用戶、資源搶占以及不同用戶上下文、模型和 Agent 場景的差異。這種差異化的訪問請求，為云側優化提供了更大的空間，也帶來了不同的優化目標和約束條件。

這些場景背后都繞不開幾個核心挑戰。如何提升計算利用率，以及如何充分利用存儲資源，無論是在筆記本還是集群中，都是關鍵問題。最近兩個月，內存價格幾乎翻了一倍，HBM、DRAM 等供應商也在控制產能。隨著模型規模增大、上下文變長，存儲挑戰將越來越大。在端側，我們還要關注 SOC 的異構調度，包括 CPU、GPU 和 NPU。而在云側，要在保證每個用戶的 SLO 以及低延遲和高吞吐量的前提下，盡可能用滿整個集群的資源。

2 以彈性算力集群，驅動云側智能升級

我們先回顧一下在云側進行大模型推理所面臨的基本挑戰，這些挑戰主要集中在計算、存儲和調度三個維度。

在計算方面，模型推理中的 Prefill（填充）和 Decode（解碼）階段本身就存在較大差異。Prefill 更傾向于計算密集型任務，而 Decode 則更偏向于訪存密集型任務。在存儲方面，盡管人們可能天然認為云側的存儲資源是充足的，但我們發現，許多端云推理引擎都存在存儲利用率低的問題。這主要是由于 Prefill 和 Decode 對顯存的占用不同，以及多用戶之間的碎片化導致的。此外，在云側，調度問題也是不可避免的，包括如何進行虛擬化、如何實現多用戶的性能隔離，同時還要盡可能提升資源利用率。這些就是目前我們在云側大模型推理中所面臨的一些挑戰。

從 2022 年大模型出現以來，無論是產業界還是學術界，都有一些代表性的工作，從計算、存儲、調度等多個不同維度對大模型在云側的推理服務進行了針對性的優化。今天，我將重點介紹其中一項工作，即圍繞 Prefill 和 Decode 分離（P/D 分離）的優化實踐。

最初，在進行大模型推理時，我們通常會將 Prefill 和 Decode 請求都放在同一張 GPU 卡或一個 GPU 節點內。在這種情況下，它們需要共享 GPU 的計算資源，同時它們的權重、激活值以及 KV Cache 都存儲在 GPU 的 HBM 中。這種融合式場景在早期被廣泛采用，包括 Kimi 和 DeepSeek 等項目，都是在 P/D 分離的基礎上進行大模型推理的實踐。P/D 分離的簡單邏輯是將 Prefill 實例和 Decode 實例進行分解，將 Prefill 實例部署在一些算力較高的 GPU 集群上，而將 Decode 實例部署在另一些存儲容量大、帶寬高的 GPU 集群上。例如，對于 Prefill 實例，我們可以選擇算力更強的 GPU 集群；而對于 Decode 實例，我們可以選擇像 H20 這樣算力稍小但 HBM 容量和帶寬較大的集群進行部署。這種方案目前在業界較為常見。

我們分析一下這兩種方案各自的優劣勢。對于融合式推理方案，它首先面臨的是我們在云上進行推理時不可避免的問題，即資源沖突和資源搶占。Prefill 和 Decode 請求本身對計算和存儲的需求就不一致。我們之前提到，Prefill 是一個算力密集型任務，而 Decode 是一個訪存密集型任務。將它們都放在同一張 GPU 卡或一個節點上，自然會面臨由于需求不同導致的延時干擾和計算資源分配不均的問題。在這種情況下，想要對它們進行細粒度的調控是非常困難的。然而，這種融合式方案也有它的優勢，即將存儲融合在一起，無需進行 KV Cache 之間的傳輸，相應地，存儲管理的實現會更加簡單。

再來看 P/D 分離的方式，它的核心優勢在于解決了融合式方案中 Prefill 和 Decode 計算資源搶占的問題。將 Prefill 和 Decode 拆開后，可以根據它們各自對計算和存儲的需求進行針對性的管理。如果 Prefill 實例對計算的要求比較一致，它們的行為和模式就更容易預測，因此在資源調度上可以采用更粗粒度、更可預測的方式進行管理，Decode 實例也是如此。此外，P/D 分離還可以更好地進行資源配比。然而，這種方式也引入了一些新的問題。首先，它對存儲的開銷和切換會帶來額外的挑戰。例如，P/D 分離后，P 實例和 D 實例之間的 KV Cache 存儲非常不均衡。在 P 實例上，可能只有 23% 的存儲用于 KV Cache，而在 Decode 實例上，可能有 70% 的存儲開銷都用于存儲 KV Cache。這就導致 P 實例和 D 實例之間需要頻繁進行 KV Cache 的傳輸，這就要求 GPU 之間以及節點之間的互聯帶寬需要更大，同時需要對通信庫進行更底層的優化支持。此外，由于 P 實例和 D 實例之間存儲的不均衡，在進行內存管理時，P 實例上可能會出現顯存浪費的情況。例如，除了存儲權重和 KV Cache 之外，可能有 30% 到 40% 的顯存無法被充分利用，這些未被利用的顯存會導致整個集群出現顯存浪費的問題。由于顯存成本較高，這種浪費會顯著增加整個推理系統的成本。

如何將兩者的優點結合起來，同時避免它們的不足。基于上述分析，我們提出了一個名為“P/D 半分離”的方式。在計算層面，我們對 Prefill 和 Decode 進行隔離，而在存儲層面則進行融合。我們希望既能享受計算隔離帶來的優勢，又能減少存儲融合導致的 KV Cache 傳輸開銷。

在 P/D 半分離的整體架構中，首先從計算層面來看，我們希望對 Prefill 和 Decode 進行分離。這種分離借鑒了云計算領域常用的虛擬化技術。早在 20 年云游戲興起時，就涉及如何在 GPU 的 SM 或其他計算單元上對不同游戲實例進行隔離式切分，當時采用了多種進程間虛擬化和隔離技術。類似地，在大模型出現之前，許多 AI 推理服務也在進程維度對多個任務進行隔離和虛擬化。因此，我們同樣以進程間的方式對 Prefill 和 Decode 實例進行隔離，并按照 SM 的粒度對資源進行分配。這樣做的好處是可以實現細粒度的資源管控，同時盡可能確保 P 實例和 D 實例之間有較好的分離。

在存儲維度，我們主要針對 Prefill 和 Decode 的不同需求進行了針對性優化。之前的主要問題是，如果將它們融合，由于 Prefill 和 Decode 對顯存的需求是動態的，核心邏輯是盡可能高效地利用顯存。這就需要了解當前顯存的使用情況以及任務所需的顯存量。具體來說，分為三個步驟：第一步是分析當前顯存的使用情況；第二步是確定當前是 Prefill 還是 Decode，以及該任務所需的顯存量；第三步是對顯存空間進行資源申請。如果將 Prefill 和 Decode 放在一起運行，它們之間可能會出現讀后寫依賴，以及細粒度訪存請求互相干擾的問題。因此，我們首先將 Prefill 和 Decode 的細粒度內存訪問融合成一個大的原子操作，然后在這個原子操作上對 Prefill 和 Decode 分別進行管理。這樣做的好處是，融合后 Prefill 和 Decode 之間不會出現讀后寫依賴沖突，同時也能更好地管理顯存碎片化。

在資源分配方面，我們舉了一個例子。在優化前，我們可能給 Prefill 分配了約 2/3 的資源，給 Decode 分配了 60% 的資源。但如果在下一時刻我們認為應該給 Prefill 分配更多資源，由于這兩個進程本身獲得的資源不同，理論上需要重新加載和拷貝 KV Cache、上下文等參數，這會產生額外的資源調整開銷。于是，我們想到引入一個常駐進程來管理 KV Cache 和模型權重的加載。這樣，原有的 Prefill 和 Decode 進程可以預先依托常駐進程進行資源加載，無需引入額外的拷貝開銷，從而減少 KV Cache 和資源分配方面的問題。

除了前面提到的方案，我們在實際生產環境中，也針對實例推理以及集群規模的 P/D 融合方式進行了支持。在實例級別，我們主要關注一臺或兩臺 8 卡、16 卡的服務器規模。在這種情況下，Prefill 實例和 Decode 實例分別進行通信，且 Prefill 和 Decode 之間采用異步方式，這樣可以更好地進行管理，并減少同步開銷。

在集群規模方面，我們主要與現有的框架，包括 Kimi 開源的一些 P/D 分離框架進行融合。你可以選擇直接使用現有的 Prefill 和 Decode 實例，也可以使用我們這種半分離的實例。核心目標是打開整個集群規模的優化空間，從而在上面進行更精細化的優化空間探索，找到一些更好的設計點。

與 SGLang 相比，我們的吞吐率提升了 10%，延時降低了兩倍。同時，我們的 TTFT 和 ITL 的整體延時都得到了顯著優化。從完成率曲線可以看出，與 SGLang 相比，我們在實際線上業務中完成請求的占比提升明顯快于 SGLang 的結果。

3 面向華為昇騰的推理優化部署實踐

最近，我們在華為昇騰平臺，特別是其 910B 的 384 超節點上，進行了一些探索。這些探索主要集中在百卡到千卡規模的集群推理實踐上。在開始之前，我們首先進一步分析了為什么需要超節點，以及華為開發超節點背后的邏輯。從下圖左邊可以看到，OpenAI 提出了從 L1 到 L5 的演進趨勢，橫軸代表智能水平。理論上，從 L1 到 L5，模型的智能水平應該越來越強。我們經過分析發現，要支撐這種智能水平的演進，整個推理的能效，即 Token/J，也需要持續迭代。我們之前介紹的實例推理主要圍繞 L1 到 L2，或接近 L3 的部分。但未來，如果要支持多智能體、超大的 MoE，就需要更強的系統能力。

從右邊的趨勢可以看出，首先，模型規模越來越大。DeepSeek、Llama、Kimi 等模型從千億規模演進到萬億規模，這意味著原來的實例推理已經無法滿足需求，需要更大的模型來提供支持。其次，目前大家都有意識地向 MoE 的超稀疏多專家方向發展，且專家數量越來越多。例如，DeepSeek 有 256 個專家，而 Kimi 有 384 個專家。這種多專家的變化與超節點多卡的方式天然契合，便于進行大規模 EP（Expert Parallelism，專家并行）部署。此外，超長上下文也是一個趨勢。現在，上下文長度已經從 8K、50K 發展到 128K，甚至更長。

接下來，我們來看在昇騰平臺上部署會面臨哪些問題。最近，昇騰的許多團隊圍繞 910B 和 920C 進行了一些具體的實踐，這是一個令人欣喜的過程。從最初的實例推理到現在的集群推理，性能有了量級的提升。然而，從“能用”到“好用”之間仍存在差距。這個差距主要體現在兩個方面：一方面，模型的上下文越來越長，這帶來了計算、存儲和通信的匹配問題；另一方面，華為的昇騰架構是一個 NPU 架構，其算子生態需要整個行業共同迭代。這自然會面臨開源社區和整個軟件棧迭代的問題。未來，模型肯定會逐步演進，如何將模型與集群更好地匹配起來，也是一個亟待解決的問題。

在這里，我想和大家分享一些我們在超節點上以及結合未來模型發展所遇到的挑戰。首先是長文本問題。長文本的需求在 Agent 以及未來的具身智能等領域肯定會不斷增加。長文本的核心特點是對 KV Cache 的占用會越來越大。如果文本較短，實例推理或許還能應對，最多支持 4K 到 8K 的上下文。但如果要支持 128K，甚至未來是 512K 以及更長的上下文，現有的實例推理顯存顯然已經無法滿足需求。因此，自然而然地需要從實例推理轉向集群推理，以獲得更大的存儲池來支持 KV Cache 的存儲。

這自然帶來了另一個問題：如何解決 KV Cache 之間的傳輸挑戰。從計算層面來看，上下文越長，對應的 KV Cache 以及在 Prefill 階段進行 Attention 計算時的計算需求也會越大。因為 Attention 計算本身是隨著上下文長度呈二次方增長的，這就必然涉及到 MLA 以及 MoE 算子的計算優化問題。在通信層面，KV Cache 越來越大，必然會帶來更多的通信和同步開銷。過去，我們更多關注的是實例推理中的 TP（張量并行）并行。但現在，我們可能需要從張量并行切換到序列并行，甚至融合序列并行和專家并行的方式，來解決計算和通信開銷問題。從框架層面來看，過去我們主要關注如何在 P 實例和 D 實例之間進行調度。但如今，超節點本身是一個融合方案，超節點與超節點之間如何協同支持，以及未來如何將不同模型部署到不同的超節點上，這都是框架層面需要考慮的模型適配問題。

在對昇騰架構的探索中，我們重點關注了計算層面的優化問題，尤其是與長文本處理和集群推理相關的挑戰。首先，從計算層面來看，隨著模型上下文長度的增加，注意力機制（Attention）的算力需求顯著增大。這不僅體現在對張量核心（Tensor Core）的計算需求上，還體現在對標量計算的需求上。在昇騰架構中，標量計算單元（Scalar Unit）和向量計算單元（Vector Unit）的算力與矩陣計算單元（Cube Unit）存在較大差距。我們通過分析發現，隨著上下文長度的增加，標量和向量計算的時間占比可能會從 10% 飆升到 30% 至 40%。這種非張量計算帶來的瓶頸需要從芯片層面進行針對性優化。

針對長上下文導致的 KV Cache 存儲不均問題，這與之前提到的 P/D 分離優化類似，但面向的是超節點內 NPU 和 NPU 之間，甚至是 GPU 和 GPU 之間的部署問題。在長上下文和云端推理場景中，計算力需求與存儲需求的綁定因素不同。算力需求與請求數（batch size）緊密相關，而存儲需求則與上下文長度相關。這種不一致性導致在集群推理和云端推理場景中，需要考慮的因素更多，且它們之間的相互影響也更為復雜。

資源匹配問題也是一個關鍵挑戰。例如，在 384 超節點上部署 DeepSeek 模型時，由于模型的專家權重數量（320）與超節點數量（384）無法整除，導致部分 NPU 或 GPU 資源浪費。這表明 384 超節點在設計時可能并未完全針對特定模型進行優化，未來新模型的出現將進一步加劇這一問題。

針對這些問題，我們與清華大學和上海交通大學的團隊進行了探索，并針對一些關鍵算子進行了底層優化。這些優化包括 L2、L1、L0 緩存之間的數據搬運和復用策略，以及基于昇騰 CCE 的底層支持。最近，我們還發表了一篇論文《FlashOverlap》 ，提出了針對昇騰架構的細粒度計算和通信流水優化方法，感興趣的朋友可以查閱。

總結來說，我們認為集群推理其實是一個更為復雜的優化問題。在進行 AI 推理優化時，本質上我們都在做各種各樣的多目標優化。我們既希望延時低，又希望吞吐量高，還希望資源利用率強，并且能夠盡可能地服務更多用戶。然而，在這個過程中，我們需要考慮諸多因素，包括模型的類型、規模，芯片的算力構成，可用的帶寬、顯存，以及整個節點的規模和節點之間的互聯帶寬等。我們一直強調軟硬協同，其本質便是在這樣一個龐大的優化空間里，嘗試對計算、通信以及框架等資源配比進行合理的映射和優化搜索。所以，我覺得這個領域是需要持續進行技術攻關的，而我們目前也正在不斷地探索，從計算到框架再到通信層面，我們都在持續地進行嘗試。

4 以有限算力架構，釋放終端應用潛能

在一些資源受限的芯片上，比如手機、PC 上，我們還能做哪些工作呢？大的背景是，我們堅信未來大模型將在更廣泛的智能終端設備上落地，包括大家手里的手機、筆記本電腦，以及現在比較火的機器人，還有各種新形態的終端，這些都將是未來重要的智能入口。這個智能入口不僅會影響到云側的配合，也會涉及到端側有一個更懂你的智能體來幫你處理越來越多的事情。所以，這塊帶來的想象空間是越來越大的。結合現在比較火的具身智能，不管是自動駕駛、無人機還是機器人的場景，其實對 Token 的需求還是很大的，至少是在 100 到 1000 個 Token 這個量級。那么，如何用一個比較好的芯片和基礎設施去支撐這樣大的 Token 需求，至少在端側這個場景是一個需要解決的問題。

在端側，我們也是從計算、存儲、通信這幾個方面做了一些分析，包括在 GPU 和 CPU 上的一些優化。這可能涉及到在 SOC 上，能否把上面的 NPU 也利用起來。因為端側本身就是一個存儲非常有限的設備，所以如何把一個很大的模型進行蒸餾、壓縮，壓縮完以后是否還能滿足需求，以及是否能在有限的空間里用計算去換存儲的方式做一些優化。

目前業界的優化也分為幾類。一類是做一些投機解碼等技術，本質上是因為端側存儲比較貴，而算力相對來說有一些富余。因為在端側，你不需要跑很大的 batch size，一般都是單 batch 和單用戶的推理，所以大部分情況下計算是有富余的。那么，多出來的計算就可以用來換取存儲。所以，現在所有的投機解碼方式都是在做這塊的事情。另一類是模型壓縮，不管是做稀疏量化還是蒸餾，都是為了讓模型在保持智能水平的情況下變得越來越小。其實，包括 MIT 和我們團隊之前都做了很多這種壓縮的工作。還有一類是端側本身是一個 SOC 平臺，那如何在上面做一些協同優化，也是一個重要的方向。

我們團隊最近開展了一項工作，這是一個典型的軟硬件協同優化方案。我們的思路是從投機采樣等技術入手，從模型和軟件兩個層面進行探索。簡單來說，正常情況下，模型推理包含多個層級。之前有早退技術的概念，即無需完成所有層級的計算就能輸出結果。例如，一個 32 層的模型，可能在計算到第 31 層時，結果的概率就已經接近閾值，可以提前結束。但關鍵問題在于，何時應該結束？這需要一個判斷過程。如果將這個判斷過程建模，實際上是在一個上萬規模的詞表中進行搜索分類。對于典型的大模型，詞表通常是萬級的，比如一個 3 萬詞表，這樣的搜索開銷非常大。我們希望在享受早退技術帶來的計算和存儲開銷減少優勢的同時，盡量使其可用，否則每次都要搜索一遍，可能會帶來不可接受的開銷。

核心問題在于如何構建一個中間預測模型，以縮短在線搜索的開銷。比如在某一層判斷是否可以結束時，能夠通過一個小的推測模型，在極低開銷下進行判斷。這個推測模型會根據輸入，將原本龐大的詞表縮減為一個非常小的詞表。因為在對話場景中，下一個詞相對比較確定，本質上不需要在大詞表中搜索。理論上，可以提前訓練一個小模型，讓它知道在什么范圍內找到這個詞，然后在這個小詞表下進行搜索，從而盡可能降低開銷。

如何以低開銷、高精度的方式進行這種級聯計算。由于我們本質上是在做軟硬件協同優化，修改算法不可避免地會引入一些開銷。因此，如果預測錯誤，就需要一些在線修正機制。我們在這方面也做了一些工程優化，以確保預測錯誤時能夠快速修正，從而保證精度不受損失。此外，針對頻繁調度的開銷問題，我們在端側開發了一個調度引擎，用于記錄早退的位置，并提前存儲早退的概率，結合離線調度和在線調度，優化整體的調度效率。

從結果來看，下圖黃色部分是基于一些稀疏化的優化，綠色部分是量化優化。我們可以看到，通過軟硬件協同的方式，在保證精度的同時提升了速度，使性能盡可能向右上角提升。在實際部署中，我們在聯想的 AI PC 上進行了部署，端到端的性能大約提升了兩倍。

5 以大模型推理技術創新，融合人工智能產業創新

我們與各位探討了在云和端側部署大模型時面臨的效率挑戰。我們的核心目標是無論在云端還是端側設備上，都能充分利用大模型的優勢，同時盡可能降低對硬件資源的需求，并滿足用戶對推理服務質量的要求。一直以來，我們致力于將推理系統部署到云端，推動整個產業鏈的運轉。因為，盡管從事基礎設施和技術工作的人員主要關注 Token 的性能，但僅靠 Token 性能是不夠的。我們還需要讓足夠多的應用企業參與進來，形成產業閉環。只有當大家廣泛使用大模型，探索其在各行業的應用，并在 Token 量大幅提升后，才能有足夠的需求推動基礎設施的發展。我認為這是一個良好的正向循環。在端側，我們則與聯想等企業以及各種端設備進行了探索，希望未來無論是 AI PC、AI 手機，還是其他終端設備，都能為用戶帶來使用體驗上的變革。

我們認為未來端和云并非解耦的，而是需要協同支撐的。在相當長的一段時間里，端和云將相互補充、共同存在。在端側，我們可以部署 3B、7B 或 13B 左右的模型，用于本地化處理和個人個性化助理功能。這些模型能夠了解用戶的想法，幫助管理個人日程，并分析個性化需求。由于涉及隱私性要求，這些功能需要在本地實現。而當用戶需要處理更復雜的任務時，端側設備可以調用云端的 Agent 和更強大的模型，為用戶提供輔助支持。我們相信，在未來很長一段時間里，需要探索出一個云與端協同的框架，以確保大模型在各行業的更好落地。

我們的愿景是，就像 30 年前水電走進千家萬戶一樣，如今我們希望通過端云協同和更高效的基礎設施，與上下游通力合作將大模型的成本降低萬倍，使其普及到更多領域。

演講嘉賓介紹

曾書霖，無問芯穹總經理，于 2018 年和 2023 年在清華大學電子工程系獲得工學學士和博士學位，師從清華大學電子工程系教授、IEEE Fellow 汪玉，研究領域為軟硬協同優化研究和 AI 加速器設計。在相關領域發表高水平國際會議和期刊論文 20 余篇，谷歌學術施引九百余次，包括以第一作者或共同一作發表高水平論文于可重構計算領域旗艦會議（ FPGA · 25, FPGA · 24）、體系結構領域頂級會議 (HPCA · 25, MICRO · 23)、以及頂級期刊 IEEE TC、ACM TRETS 等。曾獲 FPGA 2025 會議最佳論文獎（ FPGA 會議首次將該獎項授予完全由中國大陸科研團隊主導的研究工作，也是亞太國家團隊首次獲此殊榮）、IEEE TC 2023 Featured Paper of the Month、清華大學研究生國家獎學金等。在創新創業方面，作為創始成員參與創立上海無問芯穹智能科技有限公司，并作為智能終端業務負責人，帶領團隊打造“端模型 + 端軟件 + 端 IP ”的智能終端一體化解決方案。