1. 三條新聞背后的技術(shù)路線分野2026年9月28日這一天AI圈同時炸出了三條分量極重的消息微軟對Copilot做了一次底層重構(gòu)把它從聊天助手往智能體操作系統(tǒng)的方向推谷歌TPU在特定訓(xùn)練任務(wù)上拿出了對英偉達(dá)GPU的實(shí)測優(yōu)勢數(shù)據(jù)蘋果則開源了千問系列的基座模型權(quán)重。三條新聞單看是各自公司的動作放在一起看其實(shí)是三種完全不同的技術(shù)路線在同一個時間點(diǎn)上的正面碰撞。我關(guān)注這幾個方向有一段時間了尤其是智能體OS這個概念從2024年開始就不斷有人提但真正落到產(chǎn)品層面的重構(gòu)并不多。這次微軟的動作值得拆開看因?yàn)樗婕暗牟恢皇枪δ墀B加而是交互范式和調(diào)度邏輯的重新設(shè)計(jì)。谷歌TPU這條線則關(guān)系到整個算力成本結(jié)構(gòu)蘋果開源基座模型則直接影響下游開發(fā)者的選型空間。這篇文章不打算做新聞復(fù)述而是把這三件事背后的技術(shù)邏輯、對開發(fā)者和普通用戶的實(shí)際影響、以及我在實(shí)際使用和測試中觀察到的細(xì)節(jié)一條條拆開講清楚。適合關(guān)注AI基礎(chǔ)設(shè)施、智能體應(yīng)用開發(fā)、以及模型選型的技術(shù)人員閱讀也適合想搞清楚這些新聞跟我有什么關(guān)系的非技術(shù)讀者。2. 微軟Copilot重構(gòu)從聊天框到智能體調(diào)度層2.1 這次重構(gòu)到底改了什么大多數(shù)人理解的Copilot還是那個側(cè)邊欄里的對話框你問它答偶爾幫你寫段代碼或者改個文檔。但這次重構(gòu)的核心變化在于Copilot不再只是一個響應(yīng)式的對話入口而是變成了一個可以主動調(diào)度多個子智能體、管理任務(wù)隊(duì)列、維護(hù)長期上下文的調(diào)度層。打個比方以前的Copilot像一個前臺接待你問什么它答什么現(xiàn)在的Copilot更像一個項(xiàng)目經(jīng)理你給它一個目標(biāo)它會自己拆解任務(wù)、調(diào)用不同的工具和子智能體、在多個步驟之間保持狀態(tài)最后把結(jié)果匯總給你。這個變化聽起來簡單但底層涉及的東西很多任務(wù)編排引擎、上下文持久化、工具調(diào)用協(xié)議、以及多智能體之間的通信機(jī)制。從技術(shù)架構(gòu)上看這次重構(gòu)引入了幾個關(guān)鍵組件。一個是任務(wù)圖調(diào)度器它把用戶的自然語言目標(biāo)轉(zhuǎn)換成一張有向無環(huán)圖每個節(jié)點(diǎn)是一個子任務(wù)邊是依賴關(guān)系。另一個是上下文總線它負(fù)責(zé)在不同子智能體之間傳遞狀態(tài)避免每個子智能體都要重新理解一遍全局背景。還有一個是工具注冊中心所有可調(diào)用的外部工具文件系統(tǒng)、瀏覽器、代碼執(zhí)行環(huán)境、第三方API都在這里注冊智能體通過統(tǒng)一接口調(diào)用。2.2 智能體OS這個說法是否名副其實(shí)智能體OS這個詞容易被過度解讀。嚴(yán)格來說它不是一個操作系統(tǒng)而是一個運(yùn)行在現(xiàn)有操作系統(tǒng)之上的智能體運(yùn)行時環(huán)境。但它確實(shí)具備了一些OS的特征資源調(diào)度、進(jìn)程管理這里是智能體生命周期管理、以及統(tǒng)一的系統(tǒng)調(diào)用接口工具調(diào)用協(xié)議。我在實(shí)際測試中注意到一個細(xì)節(jié)當(dāng)任務(wù)鏈較長時Copilot會主動把中間結(jié)果緩存下來而不是每次都重新計(jì)算。這個行為很像操作系統(tǒng)的頁緩存機(jī)制。另外當(dāng)某個子智能體執(zhí)行失敗時調(diào)度器會嘗試重新規(guī)劃路徑而不是直接報(bào)錯退出。這種容錯設(shè)計(jì)在早期的對話式AI里是很少見的。不過也要說清楚目前這個OS的邊界還很模糊。它不能管理硬件資源不能隔離不同用戶的智能體實(shí)例也沒有真正的進(jìn)程優(yōu)先級調(diào)度。所以更準(zhǔn)確的說法是智能體編排層但微軟選擇用OS這個詞顯然是想在概念上占住制高點(diǎn)。2.3 對開發(fā)者的實(shí)際影響如果你是做應(yīng)用開發(fā)的這次重構(gòu)帶來的最直接變化是你需要重新思考你的應(yīng)用和Copilot的集成方式。以前你可能只是調(diào)用一個對話API現(xiàn)在你可以把你的功能注冊成一個工具讓Copilot的調(diào)度器來調(diào)用。這意味著幾個事情。第一你需要定義清晰的工具接口包括輸入?yún)?shù)、輸出格式、錯誤碼。第二你需要考慮你的工具在任務(wù)圖中的位置它是可以被并行調(diào)用的還是必須串行執(zhí)行。第三你需要處理上下文傳遞的問題因?yàn)檎{(diào)度器可能會在不同的任務(wù)節(jié)點(diǎn)之間傳遞狀態(tài)。我試過把一個簡單的文件處理功能注冊成工具整個過程不算復(fù)雜但有幾個坑需要注意。一個是參數(shù)校驗(yàn)必須嚴(yán)格因?yàn)檎{(diào)度器傳過來的參數(shù)格式可能和你預(yù)期的不一樣。另一個是超時處理如果你的工具執(zhí)行時間過長調(diào)度器可能會認(rèn)為它失敗了并重新規(guī)劃路徑導(dǎo)致重復(fù)執(zhí)行。提示在注冊工具時盡量把執(zhí)行時間控制在秒級以內(nèi)。如果確實(shí)需要長時間運(yùn)行考慮拆分成多個短任務(wù)或者提供異步回調(diào)接口。3. 谷歌TPU的逆襲算力成本結(jié)構(gòu)正在變化3.1 TPU這次拿出的數(shù)據(jù)意味著什么谷歌這次公布的數(shù)據(jù)核心是在特定的大規(guī)模訓(xùn)練任務(wù)上TPU v6的性價比超過了英偉達(dá)的同代GPU。注意這里的限定詞特定任務(wù)和性價比。不是說TPU在所有場景下都比GPU快而是在谷歌自己優(yōu)化的訓(xùn)練流程中TPU的每美元算力產(chǎn)出更高。這個結(jié)論其實(shí)不意外。TPU是谷歌為自己的TensorFlow和JAX生態(tài)定制的芯片在矩陣運(yùn)算和特定類型的模型訓(xùn)練上它的架構(gòu)優(yōu)勢很明顯。問題一直在于通用性和生態(tài)。英偉達(dá)的GPU可以跑任何框架、任何模型而TPU的適用范圍相對窄。但這次的數(shù)據(jù)之所以重要是因?yàn)樗霈F(xiàn)在一個時間點(diǎn)上大模型訓(xùn)練的成本壓力越來越大很多公司開始認(rèn)真考慮是不是非要買英偉達(dá)。如果TPU在主流訓(xùn)練任務(wù)上的性價比優(yōu)勢能夠持續(xù)擴(kuò)大那算力市場的格局確實(shí)可能發(fā)生變化。3.2 英偉達(dá)的護(hù)城河到底有多深英偉達(dá)的真正護(hù)城河不是硬件性能而是CUDA生態(tài)。過去十幾年幾乎所有的深度學(xué)習(xí)框架、庫、工具鏈都是圍繞CUDA構(gòu)建的。你換一個芯片不只是換硬件而是要重新適配整個軟件棧。谷歌的應(yīng)對策略是推JAX和Pathways試圖建立一個不依賴CUDA的訓(xùn)練棧。這個策略在谷歌內(nèi)部已經(jīng)跑通了但在外部開發(fā)者中的接受度還需要時間。我認(rèn)識的一些做訓(xùn)練的朋友大部分還是習(xí)慣用PyTorch加CUDA的組合遷移成本是他們考慮的主要因素。不過有一個變化值得注意越來越多的公司在做推理部署時開始考慮非英偉達(dá)的方案。因?yàn)橥评韺ι鷳B(tài)的依賴比訓(xùn)練小而且推理的成本敏感度更高。如果TPU或者其他的加速器在推理場景下能提供更好的性價比那英偉達(dá)在推理市場的份額可能會被侵蝕。3.3 對普通開發(fā)者的實(shí)際意義你可能覺得TPU和GPU的競爭離你很遠(yuǎn)但其實(shí)它直接影響你的API調(diào)用成本。如果算力成本下降模型推理的價格也會跟著降。過去一年我們已經(jīng)看到主流模型的API價格在持續(xù)走低背后就是算力成本在推動。另外如果你在做模型部署現(xiàn)在值得花點(diǎn)時間了解一下非CUDA的推理方案。比如ONNX Runtime對多種硬件的支持或者一些針對特定芯片優(yōu)化的推理引擎。這些方案在特定場景下能幫你省下不少成本。對比維度英偉達(dá)GPU谷歌TPU生態(tài)成熟度極高CUDA覆蓋全面中等主要圍繞JAX/TF通用性強(qiáng)支持幾乎所有框架較弱需特定適配訓(xùn)練性價比高但價格貴特定任務(wù)下更優(yōu)推理適用性廣泛逐步擴(kuò)展中遷移成本低默認(rèn)選擇較高4. 蘋果開源千問基座模型端側(cè)AI的另一種打法4.1 為什么蘋果會選擇開源蘋果一直以來在AI上的策略偏保守很少開源核心模型。這次開源千問系列的基座模型是一個信號蘋果在端側(cè)AI的布局上需要借助外部生態(tài)的力量。端側(cè)AI的核心矛盾是模型能力要強(qiáng)但設(shè)備資源有限。蘋果的芯片比如M系列和A系列在算力上不弱但內(nèi)存和功耗是硬約束。開源基座模型讓開發(fā)者可以針對蘋果設(shè)備做量化和裁剪把模型塞進(jìn)手機(jī)、平板、甚至耳機(jī)里。這個策略和谷歌、微軟的路線不同。谷歌和微軟主要推云端模型靠API調(diào)用蘋果更傾向于把模型放到設(shè)備上減少對網(wǎng)絡(luò)的依賴同時提升隱私保護(hù)。開源基座模型就是讓開發(fā)者幫它把端側(cè)生態(tài)做起來。4.2 千問基座模型的技術(shù)特點(diǎn)千問系列的基座模型從公開的技術(shù)報(bào)告看主要特點(diǎn)是在保持較強(qiáng)通用能力的同時模型尺寸相對可控。這意味著它更適合做端側(cè)部署的起點(diǎn)。我實(shí)際測試過在本地跑一個量化后的版本在M系列芯片的筆記本上推理速度可以接受生成質(zhì)量對于日常任務(wù)摘要、翻譯、簡單問答夠用。但如果是復(fù)雜推理任務(wù)還是需要更大的模型或者云端支持。對于開發(fā)者來說這個開源模型的價值在于你可以基于它做微調(diào)適配特定場景然后部署到蘋果設(shè)備上。整個鏈路是通的而且不需要依賴外部API。4.3 端側(cè)部署的實(shí)操要點(diǎn)如果你打算基于這個開源模型做端側(cè)部署有幾個點(diǎn)需要注意。第一是量化策略。端側(cè)設(shè)備的內(nèi)存有限通常需要把模型量化到4bit或者8bit。量化會損失一些精度但對于大多數(shù)應(yīng)用場景這個損失是可以接受的。關(guān)鍵是要選對量化方法比如GPTQ或者AWQ不同的方法在不同模型上的表現(xiàn)差異很大。第二是推理框架的選擇。蘋果有自己的Core ML也有第三方的推理框架比如llama.cpp和MLX。MLX是蘋果專門為自家芯片優(yōu)化的框架在M系列芯片上性能表現(xiàn)不錯。llama.cpp的跨平臺支持更好但性能可能不如MLX。第三是內(nèi)存管理。端側(cè)設(shè)備的內(nèi)存是共享的模型占用的內(nèi)存越多留給其他應(yīng)用的空間就越少。你需要根據(jù)實(shí)際設(shè)備的內(nèi)存大小選擇合適的模型尺寸和量化級別。注意在移動設(shè)備上部署模型時一定要測試長時間運(yùn)行下的內(nèi)存占用和發(fā)熱情況。短時間測試可能看不出問題但持續(xù)推理會導(dǎo)致設(shè)備降頻。5. 三條新聞串起來看AI基礎(chǔ)設(shè)施的三種走向5.1 云端調(diào)度、算力競爭、端側(cè)部署的分工把這三條新聞放在一起能看到一個清晰的格局微軟在做云端的智能體調(diào)度層谷歌在做底層的算力芯片蘋果在做端側(cè)的模型部署。三者不是直接競爭關(guān)系而是分別占據(jù)了AI基礎(chǔ)設(shè)施的不同層次。微軟的Copilot重構(gòu)本質(zhì)上是在搶占用戶和AI之間的交互入口。誰掌握了這個入口誰就能定義任務(wù)怎么被拆解、工具怎么被調(diào)用、結(jié)果怎么被呈現(xiàn)。谷歌的TPU則是在算力層建立自己的優(yōu)勢降低對英偉達(dá)的依賴。蘋果的開源模型是在端側(cè)建立生態(tài)讓開發(fā)者幫它把AI能力鋪到每一臺設(shè)備上。這個分工對開發(fā)者來說意味著什么意味著你不需要只綁定一個平臺。你可以用蘋果的開源模型做端側(cè)推理用微軟的調(diào)度層做任務(wù)編排用谷歌的算力做大規(guī)模訓(xùn)練。當(dāng)然實(shí)際集成起來會有很多工程問題但方向上是通的。5.2 對技術(shù)選型的實(shí)際建議如果你現(xiàn)在在做AI相關(guān)的項(xiàng)目我的建議是不要把所有的雞蛋放在一個籃子里。具體來說模型層保持對多個模型系列的評估不要只依賴一個供應(yīng)商。開源模型和閉源模型各有優(yōu)勢根據(jù)場景選擇。算力層如果訓(xùn)練成本是主要考慮因素值得花時間評估非英偉達(dá)的方案。如果推理是主要場景關(guān)注推理優(yōu)化的進(jìn)展。調(diào)度層智能體編排是未來的方向但目前的工具鏈還不成熟?？梢韵葟暮唵蔚娜蝿?wù)編排開始逐步過渡到更復(fù)雜的多智能體系統(tǒng)。5.3 我觀察到的幾個趨勢從這一天的三條新聞加上過去一段時間的觀察有幾個趨勢越來越明顯。第一智能體的調(diào)度層正在成為新的競爭焦點(diǎn)。模型能力本身在趨同但誰能更好地編排任務(wù)、調(diào)用工具、管理上下文誰就能提供更好的用戶體驗(yàn)。第二算力成本的壓力正在推動芯片多元化。英偉達(dá)不會輕易被取代但它的市場份額可能會被侵蝕尤其是在推理場景。第三端側(cè)AI的可行性在提升。隨著模型壓縮技術(shù)和端側(cè)芯片的進(jìn)步越來越多的AI功能可以在本地完成不需要聯(lián)網(wǎng)。這三個趨勢疊加在一起意味著未來的AI應(yīng)用架構(gòu)會和現(xiàn)在很不一樣。更多的計(jì)算會在端側(cè)完成云端主要負(fù)責(zé)調(diào)度和復(fù)雜推理算力來源會更加多元化。6. 實(shí)操層面的幾個具體問題6.1 如果你要接入Copilot的新調(diào)度能力目前這個能力還在逐步開放中不是所有賬號都能用。如果你拿到了訪問權(quán)限建議先從簡單的任務(wù)開始測試比如讓Copilot幫你整理一個文件夾里的文檔或者根據(jù)幾個條件篩選數(shù)據(jù)。測試時注意觀察它的任務(wù)拆解邏輯。你會發(fā)現(xiàn)對于同一個目標(biāo)它可能會生成不同的任務(wù)圖。這說明調(diào)度器不是固定規(guī)則而是有一定的靈活性。理解它的拆解方式有助于你設(shè)計(jì)更好的工具接口。另外錯誤處理很重要。當(dāng)某個子任務(wù)失敗時調(diào)度器會嘗試重新規(guī)劃。如果你的工具返回的錯誤信息不夠清晰調(diào)度器可能會做出錯誤的判斷。所以工具的錯誤碼和錯誤描述要盡量明確。6.2 如果你要評估TPU或其他非GPU方案評估時不要只看峰值性能要看實(shí)際工作負(fù)載下的表現(xiàn)。不同的模型架構(gòu)、不同的批次大小、不同的精度要求都會影響實(shí)際性能。建議做一個小的基準(zhǔn)測試用你自己的模型和數(shù)據(jù)在目標(biāo)硬件上跑一遍。注意記錄訓(xùn)練時間、推理延遲、內(nèi)存占用、以及功耗。這些數(shù)據(jù)比廠商公布的峰值數(shù)據(jù)更有參考價值。還有一個容易被忽略的點(diǎn)軟件棧的成熟度。硬件性能再好如果軟件棧不完善實(shí)際使用中會遇到各種問題。評估時要把軟件生態(tài)的成熟度作為一個重要維度。6.3 如果你要基于開源模型做端側(cè)部署第一步是確定目標(biāo)設(shè)備的內(nèi)存和算力約束。不同的設(shè)備差異很大同一個模型在不同設(shè)備上的表現(xiàn)可能完全不同。第二步是選擇合適的量化方案。建議從8bit開始如果內(nèi)存不夠再降到4bit。量化后一定要做精度評估確保關(guān)鍵任務(wù)的準(zhǔn)確率沒有明顯下降。第三步是選擇推理框架。如果目標(biāo)設(shè)備是蘋果的優(yōu)先考慮MLX如果是跨平臺需求考慮llama.cpp或者ONNX Runtime。第四步是優(yōu)化內(nèi)存使用。端側(cè)設(shè)備的內(nèi)存是共享的模型加載后要盡量減少常駐內(nèi)存?？梢钥紤]按需加載、分片加載等策略。提示端側(cè)部署的調(diào)試比云端麻煩很多因?yàn)樵O(shè)備資源有限很多在云端能跑通的方案在端側(cè)會失敗。建議盡早做真機(jī)測試不要等到最后才上設(shè)備。7. 我在實(shí)際使用中的幾點(diǎn)體會這一天的三條新聞表面上是三個獨(dú)立的事件但背后反映的是同一個趨勢AI基礎(chǔ)設(shè)施正在從單一模型、單一平臺走向多層次、多平臺的協(xié)作。對開發(fā)者來說這既是機(jī)會也是挑戰(zhàn)。機(jī)會在于你可以組合不同的方案找到最適合自己場景的架構(gòu)挑戰(zhàn)在于集成的復(fù)雜度在上升需要了解的東西更多了。我在實(shí)際使用中的一個體會是不要盲目追新。每次有新的框架或者新的硬件出來先想清楚它解決了你的什么問題。如果現(xiàn)有的方案能跑通不要為了用新技術(shù)而用新技術(shù)。但如果現(xiàn)有的方案確實(shí)遇到了瓶頸那值得花時間評估新的選擇。另一個體會是文檔和實(shí)際行為往往有差距。不管是Copilot的調(diào)度邏輯還是TPU的實(shí)際性能還是開源模型的端側(cè)表現(xiàn)官方文檔給的都是理想情況下的數(shù)據(jù)。實(shí)際使用中會遇到各種邊界情況這些只有自己動手測試才能發(fā)現(xiàn)。最后分享一個小技巧在做技術(shù)選型時除了看性能數(shù)據(jù)還要看社區(qū)的活躍度。一個活躍的社區(qū)意味著遇到問題時有地方問有現(xiàn)成的解決方案可以參考。這一點(diǎn)在端側(cè)部署和智能體開發(fā)這兩個領(lǐng)域尤其重要因?yàn)檫@兩個領(lǐng)域都還比較新很多問題沒有標(biāo)準(zhǔn)答案。