最近調(diào)試一個(gè) AI 智能體任務(wù)時(shí)我盯著控制臺(tái)里的 token 消耗數(shù)字看了很久。倒不是心疼那點(diǎn)計(jì)費(fèi)而是一個(gè)之前沒認(rèn)真想的問題突然變得具體token 在哪里被生產(chǎn)出來又在哪里被消耗掉今天你用的 token 幾乎全部來自云端如果 Perplexity CEO 那句“本地智能體硬件將成前沿 token 入口”的判斷成立未來會(huì)有相當(dāng)一部分 token 在本地設(shè)備上產(chǎn)生和消費(fèi)。這個(gè)判斷的分量不在某個(gè)硬件形態(tài)本身而在它背后 AI 價(jià)值鏈的一次重新分配。從工程實(shí)踐的角度看這件事不是單純“端側(cè)跑大模型”這么簡單。它牽涉到模型怎么部署、任務(wù)怎么分配、上下文怎么管理、異常怎么處理、硬件怎么選型甚至驅(qū)動(dòng)和權(quán)限這些看起來和 AI 無關(guān)的系統(tǒng)問題。這篇文章想把這條鏈路拆開來聊一聊。1. “token 入口”不是營銷詞它指向 AI 價(jià)值鏈正在發(fā)生的一次轉(zhuǎn)移1.1 一句話判斷token 從云端資源變成了設(shè)備資源在 AI 應(yīng)用普及的過程里token 早已不是一個(gè)冷門技術(shù)詞。普通用戶可能不知道它的底層原理但只要用過對(duì)話式 AI 產(chǎn)品就一定會(huì)間接碰到“上下文限制”“用量配額”“套餐包含多少 credits”這類和 token 強(qiáng)相關(guān)的設(shè)計(jì)。過去兩年token 的生成主要發(fā)生在云端。模型推理在數(shù)據(jù)中心完成用戶的設(shè)備只是一個(gè)輸入輸出終端。這種模式的優(yōu)勢是體驗(yàn)統(tǒng)一、升級(jí)方便模型一更新所有用戶立刻能用到新能力。它的代價(jià)也很明顯只要推理在云端每次交互都會(huì)產(chǎn)生網(wǎng)絡(luò)往返、云端算力成本、隱私暴露風(fēng)險(xiǎn)和可用性依賴。Perplexity CEO 在公開表述里提出本地智能體硬件會(huì)成為“前沿 token 入口”。這個(gè)詞組容易讓人誤解成“未來買硬件送 token”或者“每個(gè)硬件都塞一個(gè)大模型”。我更愿意把它理解成一種價(jià)值鏈判斷token 不再只是云端 API 的計(jì)量單位它會(huì)變成設(shè)備本身的一種資源屬性。設(shè)備能夠在用戶身邊生成 token、消化 token、決定哪些 token 留在本地、哪些必須上云。這個(gè)轉(zhuǎn)變之所以值得關(guān)注是因?yàn)樗淖兞苏麄€(gè)產(chǎn)業(yè)鏈的分配方式。過去是“模型廠商提供能力應(yīng)用廠商按 token 轉(zhuǎn)售”未來可能是“硬件廠商占據(jù)入口在本地完成第一道 token 處理再?zèng)Q定要不要向外調(diào)用”。入口前移一步話語權(quán)和利潤分配就移動(dòng)一大步。1.2 為什么智能體硬件會(huì)比手機(jī)更適合做“入口”普通手機(jī)也能裝大模型應(yīng)用但手機(jī)的問題在于它是通用設(shè)備。通用設(shè)備的資源調(diào)度以用戶手動(dòng)操作為主后臺(tái)任務(wù)的優(yōu)先級(jí)、傳感器的使用方式、通知交互的入口都不是天然為“主動(dòng)智能體”設(shè)計(jì)的。智能體需要的是長時(shí)間在線感知、隨時(shí)調(diào)用工具、在特定場景里持續(xù)工作的能力這些要求更接近一個(gè)專用設(shè)備的工作狀態(tài)。手表、耳機(jī)、眼鏡、桌面終端、車載設(shè)備這些形態(tài)的共同點(diǎn)是它們離人更近傳感器更單一任務(wù)邊界更清晰。比如一個(gè)用于會(huì)議場景的桌面終端它的核心任務(wù)就是錄音、轉(zhuǎn)寫、摘要、提取待辦硬件可以圍繞這條鏈路專門設(shè)計(jì)。相比之下手機(jī)上的智能體要處理的任務(wù)跨度太大反而很難把某個(gè)高頻場景做到極致。所以“本地智能體硬件成為 token 入口”這個(gè)判斷本質(zhì)上不是在預(yù)測哪一種硬件會(huì)贏而是在講一個(gè)趨勢AI 能力會(huì)從“云端統(tǒng)一供給”走向“端側(cè)按場景消耗”。哪個(gè)設(shè)備離特定場景更近哪個(gè)設(shè)備就能先接觸到第一手 token 需求。2. 本地智能體硬件到底要解決什么和普通 AI 硬件的區(qū)別在哪2.1 本地智能體的典型工作方式感知、規(guī)劃、調(diào)用、反饋一個(gè)本地智能體硬件的典型工作循環(huán)可以拆成四步感知通過麥克風(fēng)、攝像頭、傳感器或用戶輸入采集當(dāng)前環(huán)境信息。規(guī)劃把采集到的信息轉(zhuǎn)換成任務(wù)序列決定下一步調(diào)用哪個(gè)模型或工具。調(diào)用在本地執(zhí)行輕量推理或者調(diào)用系統(tǒng)里的其他組件完成具體操作。反饋把結(jié)果整理成用戶可以理解的輸出并以合適的交互方式呈現(xiàn)。這四步里每一步都可能產(chǎn)生 token。聽起來和云端智能體沒什么區(qū)別差別在于云端智能體的每一步都依賴網(wǎng)絡(luò)本地智能體的核心目標(biāo)就是盡量在本地完成前兩步只把必要部分上云。這也是“token 入口”這個(gè)說法有意思的地方。設(shè)備不再只是模型的展示窗口而是第一站處理器。它自己就能完成一部分“語言理解—任務(wù)拆解—結(jié)果生成”的工作相當(dāng)于把原來完全發(fā)生在數(shù)據(jù)中心的推理過程分了一部分到用戶手邊。2.2 硬件約束不止是算力內(nèi)存帶寬、功耗、傳感器和交互很多人評(píng)估本地 AI 硬件時(shí)第一反應(yīng)是看算力也就是 TOPS 或者 TFLOPS 這類數(shù)字。這個(gè)指標(biāo)重要但遠(yuǎn)不夠。第一內(nèi)存帶寬。大模型推理除了吃算力更吃內(nèi)存帶寬。模型參數(shù)要在推理時(shí)反復(fù)讀取如果內(nèi)存帶寬跟不上算力再高也只能空轉(zhuǎn)。這也是為什么很多端側(cè)設(shè)備只能跑小規(guī)模模型不是算力不夠而是帶寬和顯存容量受限。第二功耗和散熱。本地智能體硬件往往是連續(xù)工作設(shè)備不是在用戶玩大型游戲時(shí)才滿負(fù)荷運(yùn)行。功耗墻決定了芯片能穩(wěn)定跑多久也決定了設(shè)備是安靜地待在桌面還是需要風(fēng)扇不停轉(zhuǎn)動(dòng)。第三傳感器和交互。智能體硬件要感知環(huán)境就必須有麥克風(fēng)陣列、攝像頭、IMU 這類傳感器。這些部件不只是硬件選型問題還牽扯到信號(hào)處理、降噪、姿態(tài)融合、數(shù)據(jù)同步。比如做機(jī)器人或移動(dòng)設(shè)備時(shí)激光雷達(dá)數(shù)據(jù)、IMU 數(shù)據(jù)和攝像頭畫面要在時(shí)間軸上嚴(yán)格對(duì)齊否則后續(xù)規(guī)劃就會(huì)出錯(cuò)。FPGA 平臺(tái)做硬件在環(huán)測試時(shí)尤其要注意這類時(shí)間同步問題不是算法對(duì)就能跑出正確結(jié)果。第四安全與加密。設(shè)備涉及用戶隱私數(shù)據(jù)時(shí)硬件級(jí)加密往往比純軟件方案更可靠。一些嵌入式設(shè)備會(huì)集成安全芯片用來保存密鑰和執(zhí)行加密運(yùn)算。這類能力在云端的權(quán)重不高在本地設(shè)備上卻是必備項(xiàng)。2.3 用“跑模型”的思路評(píng)估智能體硬件會(huì)犯一個(gè)典型錯(cuò)誤我見過一個(gè)典型的評(píng)估誤區(qū)只看這臺(tái)設(shè)備能不能跑某個(gè)模型或者跑多少 token 每秒。這個(gè)指標(biāo)有意義但它只回答了“推理速度”一個(gè)問題沒有回答“智能體任務(wù)能否閉環(huán)”。智能體任務(wù)的難點(diǎn)往往不在單次推理而在多次推理之間的狀態(tài)管理。一次感知產(chǎn)生一段文本規(guī)劃模塊要基于這段文本做判斷然后再次調(diào)用模型反復(fù)迭代。整個(gè)過程中上下文怎么保存、任務(wù)怎么中斷、失敗怎么恢復(fù)都比單次推理速度更影響體驗(yàn)。另一個(gè)容易忽略的點(diǎn)是 token 的分層使用。一個(gè)本地智能體不可能在所有任務(wù)上都依賴本地模型。更合理的架構(gòu)是簡單、高頻、低風(fēng)險(xiǎn)任務(wù)盡量留在本地復(fù)雜、低頻、需要最新知識(shí)或強(qiáng)推理能力的高價(jià)值任務(wù)再上報(bào)云端。這樣本地 token 負(fù)責(zé)基礎(chǔ)能力云端 token 負(fù)責(zé)增強(qiáng)能力兩者用統(tǒng)一的成本模型和優(yōu)先級(jí)策略協(xié)調(diào)。如果只盯著“能不能本地跑大模型”這一個(gè)問題就很容易忽略這種分層設(shè)計(jì)把資源和成本都浪費(fèi)在錯(cuò)誤的地方。3. 從工程落地看本地 token 入口要過的四道關(guān)3.1 第一關(guān)模型能否塞進(jìn)目標(biāo)設(shè)備這一關(guān)是最基礎(chǔ)的。模型能不能放進(jìn)目標(biāo)設(shè)備取決于模型參數(shù)規(guī)模、量化方式、內(nèi)存空間和運(yùn)行框架四個(gè)變量。如果目標(biāo)設(shè)備是帶獨(dú)立 NPU 的開發(fā)板或嵌入式平臺(tái)通常要先確認(rèn) NPU 工具鏈支持哪類模型格式量化后精度損失是否可接受。很多項(xiàng)目在選型時(shí)會(huì)提前做一輪“模型裁剪實(shí)驗(yàn)”先用一個(gè)小規(guī)模模型在目標(biāo)設(shè)備上跑通再逐步增大模型觀察延遲和內(nèi)存占用。這里有一個(gè)非?，F(xiàn)實(shí)的建議不要一上來就追求最大的模型先讓一條完整鏈路在設(shè)備上轉(zhuǎn)起來再談效果提升。單條鏈路跑通后設(shè)備的內(nèi)存占用、發(fā)熱、功耗、穩(wěn)定性這些指標(biāo)會(huì)陸續(xù)暴露出來以它們?yōu)橐罁?jù)決定是否升級(jí)模型更合理。3.2 第二關(guān)上下文和任務(wù)能否在本地閉環(huán)本地智能體不是簡單地“塞一個(gè)模型進(jìn)去”而是要能把“感知—規(guī)劃—調(diào)用—反饋”這個(gè)循環(huán)在設(shè)備上跑通。這里最常見的問題是上下文管理。一次對(duì)話可能已經(jīng)消耗了很長一段上下文但智能體可能下一分鐘就要處理一個(gè)全新的任務(wù)。如果所有歷史都保留在上下文中設(shè)備內(nèi)存會(huì)被快速占滿token 消耗也會(huì)失控。實(shí)際工程里通常會(huì)做上下文裁剪、分塊、摘要壓縮。先判斷哪些信息對(duì)當(dāng)前任務(wù)有影響再?zèng)Q定保留原文本還是壓縮成摘要。如果原始設(shè)計(jì)沒有給出明確的上下文策略落地前最好先按任務(wù)類型區(qū)分單輪指令、短期多輪對(duì)話、長期記憶型任務(wù)分別設(shè)計(jì)不同的上下文保留方式。不要用同一種策略處理所有任務(wù)否則要么效果差要么內(nèi)存爆。3.3 第三關(guān)批量任務(wù)、異常重試和日志從原型到可用有一個(gè)容易被低估的跨越單次任務(wù)跑通不等于能穩(wěn)定反復(fù)運(yùn)行。本地智能體是長期運(yùn)行的設(shè)備它一天會(huì)處理幾十上百次任務(wù)其中必然出現(xiàn)識(shí)別失敗、模型輸出格式不對(duì)、調(diào)用工具出錯(cuò)、網(wǎng)絡(luò)波動(dòng)等異常。處理這些異常不能靠“重新試一次”這種直覺方案。需要有一層明確的重試策略先區(qū)分失敗類型。是輸入問題、模型問題、工具問題還是網(wǎng)絡(luò)問題。再?zèng)Q定重試方式。輸入問題要重新收集或提示用戶網(wǎng)絡(luò)問題可以間隔重試模型輸出格式問題可以加一層結(jié)構(gòu)化抽取或校驗(yàn)。最后做記錄。每次失敗都把輸入、輸出、錯(cuò)誤碼、設(shè)備狀態(tài)寫入日志否則排查會(huì)變成盲猜。日志這一步最容易被省掉也最容易被后續(xù)維護(hù)加倍懲罰。沒有日志的本地智能體就像一個(gè)沒有黑匣子的飛行器出了問題只能靠復(fù)現(xiàn)猜測。日志結(jié)構(gòu)可以先從最簡單的字段開始逐步補(bǔ)充{ task_id: agent_task_001, stage: planning, status: failed, error_code: TOOL_NOT_FOUND, input_tokens: 1280, output_tokens: 96 }有了這類日志你才能在出現(xiàn)問題時(shí)快速定位是哪個(gè)環(huán)節(jié)斷了而不是把整個(gè)系統(tǒng)翻一遍。3.4 第四關(guān)驅(qū)動(dòng)、權(quán)限、系統(tǒng)兼容這些“非 AI 因素”本地智能體硬件項(xiàng)目里很多致命問題不是出在模型上而是出在系統(tǒng)層面。嵌入式設(shè)備、開發(fā)板、邊緣網(wǎng)關(guān)安裝運(yùn)行環(huán)境時(shí)經(jīng)常遇到驅(qū)動(dòng)簽名、權(quán)限、依賴庫版本、系統(tǒng)內(nèi)核不匹配這類問題。比如某些 Windows 平臺(tái)上安裝 USB 設(shè)備或 NPU 驅(qū)動(dòng)時(shí)會(huì)遇到“Windows 無法驗(yàn)證此設(shè)備所需的驅(qū)動(dòng)程序的數(shù)字簽名”的提示。這類問題的本質(zhì)是驅(qū)動(dòng)沒有通過系統(tǒng)簽名驗(yàn)證并不一定是硬件壞了。常規(guī)處理路徑是確認(rèn)驅(qū)動(dòng)來源、檢查設(shè)備型號(hào)對(duì)應(yīng)的驅(qū)動(dòng)版本、按官方說明關(guān)閉強(qiáng)制簽名或更新驅(qū)動(dòng)、重新插拔設(shè)備并查看設(shè)備管理器狀態(tài)。如果設(shè)備是自研硬件還要提前規(guī)劃好驅(qū)動(dòng)簽名的流程否則每次換一臺(tái)機(jī)器部署都要面對(duì)同樣的問題。Linux 環(huán)境下另一類常見問題是 4G 模塊、加密芯片、傳感器這些外設(shè)沒有生成正確的設(shè)備節(jié)點(diǎn)或者權(quán)限不夠?qū)е聼o法訪問。排查順序一般是從內(nèi)核日志看是否識(shí)別到設(shè)備再檢查 dev 節(jié)點(diǎn)是否存在再確認(rèn)用戶組權(quán)限最后才考慮應(yīng)用層代碼。# Linux 下排查外設(shè)識(shí)別情況建議按這個(gè)順序來 dmesg | grep -i 設(shè)備名 ls /dev | grep 設(shè)備節(jié)點(diǎn) groups # 確認(rèn)當(dāng)前用戶是否有訪問權(quán)限不要一上來就懷疑模型或推理框架越底層的問題越要先排查。提醒遇到本地智能體運(yùn)行時(shí)崩潰或結(jié)果異常先按“輸入—環(huán)境—權(quán)限—驅(qū)動(dòng)—參數(shù)—日志”的順序排查不要直接重裝系統(tǒng)或重置整個(gè)開發(fā)環(huán)境。4. 一個(gè)可復(fù)用的評(píng)估框架什么時(shí)候該用本地智能體硬件4.1 四維驗(yàn)證成本、隱私、延遲、可控性判斷一個(gè)場景適不適合本地智能體硬件可以從四個(gè)維度打分成本如果每次交互都要上云長期 token 費(fèi)用是否高到不可接受本地推理的邊際成本更低如果交互頻率很高本地方案在成本上有優(yōu)勢。隱私任務(wù)數(shù)據(jù)是否包含語音、圖像、位置、聊天內(nèi)容等敏感信息數(shù)據(jù)不出設(shè)備會(huì)顯著降低隱私風(fēng)險(xiǎn)但也要評(píng)估設(shè)備本地存儲(chǔ)是否安全。延遲實(shí)時(shí)性要求有多高需要毫秒級(jí)響應(yīng)的場景例如即時(shí)通話、應(yīng)急反饋、閉環(huán)控制本地推理更容易滿足?？煽匦阅闶欠裥枰x線可用、不依賴供應(yīng)商服務(wù)、可自定義行為邏輯云端方案升級(jí)由供應(yīng)商決定本地方案的可控性更高但維護(hù)責(zé)任也轉(zhuǎn)移到自己身上。這四個(gè)維度不必全部滿足才考慮本地方案。更現(xiàn)實(shí)的做法是設(shè)定優(yōu)先級(jí)哪些場景對(duì)延遲和隱私是剛需哪些場景可以接受先上云后優(yōu)化。4.2 適合與不適合本地智能體的場景對(duì)比維度更適合本地智能體硬件更依賴端云協(xié)同任務(wù)類型高頻、范圍明確、低風(fēng)險(xiǎn)任務(wù)低頻、跨領(lǐng)域、需要最新知識(shí)數(shù)據(jù)敏感性語音、圖像、本地文件等隱私數(shù)據(jù)脫敏后可上傳的公開或低敏感數(shù)據(jù)網(wǎng)絡(luò)環(huán)境弱網(wǎng)、離線、移動(dòng)環(huán)境穩(wěn)定高帶寬網(wǎng)絡(luò)交互要求低延遲、秒級(jí)響應(yīng)可等待數(shù)秒可接受排隊(duì)能力需求已有小模型可覆蓋的中等能力需要前沿模型強(qiáng)推理能力維護(hù)資源有硬件調(diào)試和運(yùn)維能力希望盡量少維護(hù)愿意按量付費(fèi)表格之外還有一個(gè)更重要的事實(shí)絕大多數(shù)真實(shí)產(chǎn)品不會(huì)走極端而是分層組合。本地處理第一層感知和基礎(chǔ)對(duì)話云端處理復(fù)雜推理和知識(shí)檢索。這種模式里本地 token 負(fù)責(zé)高頻消耗云端 token 負(fù)責(zé)關(guān)鍵決策兩者通過明確的“上云閾值”銜接。4.3 對(duì)三類角色的行動(dòng)建議對(duì)軟件工程師來說不用急著等一個(gè)成熟的“本地智能體框架”出現(xiàn)可以先從 API 遷移到本地可運(yùn)行的模型開始把現(xiàn)有任務(wù)拆成“哪些必須云端、哪些可以本地”用一套統(tǒng)一的任務(wù)接口封裝切換邏輯。對(duì)產(chǎn)品經(jīng)理來說token 不該只是成本數(shù)字。它正在變成產(chǎn)品的體驗(yàn)分界線哪些功能可以離線承諾哪些能力依賴云端升級(jí)哪些數(shù)據(jù)承諾不出設(shè)備。這些決策會(huì)直接影響功能設(shè)計(jì)和市場溝通。對(duì)硬件工程師來說最大的變化不是學(xué)會(huì)部署模型而是把模型運(yùn)行時(shí)的資源需求納入硬件設(shè)計(jì)。內(nèi)存帶寬、散熱、供電、驅(qū)動(dòng)兼容、加密能力、外設(shè)同步這些原本屬于“電路設(shè)計(jì)”的問題現(xiàn)在都變成了“AI 產(chǎn)品體驗(yàn)”的問題。比如在嵌入式硬件上做感知數(shù)據(jù)同步時(shí)如果不提前規(guī)劃硬件層面的時(shí)鐘同步方案后續(xù)做傳感器融合時(shí)一定會(huì)遇到時(shí)間戳錯(cuò)位帶來的定位漂移或任務(wù)亂序問題。注意如果你的團(tuán)隊(duì)之前沒有做端側(cè) AI 的經(jīng)驗(yàn)最穩(wěn)妥的起步方式是采購成熟的開發(fā)板或模組先跑通業(yè)務(wù)邏輯再根據(jù)瓶頸決定是否自研硬件。自研硬件的周期和調(diào)試成本通常會(huì)比預(yù)估翻倍。5. 我更想提醒的事入口是結(jié)果不是起點(diǎn)5.1 先跑通一個(gè)最小的智能體閉環(huán)看到“本地智能體硬件將成為 token 入口”這類判斷時(shí)最容易產(chǎn)生的一種錯(cuò)覺是我需要趕緊預(yù)判下一代硬件形態(tài)提前卡位。實(shí)際工程經(jīng)驗(yàn)恰恰相反。無論是開發(fā)者還是硬件團(tuán)隊(duì)最應(yīng)該做的不是押注形態(tài)而是先把一個(gè)最小的智能體閉環(huán)跑通。選一個(gè)你真正高頻遇到的場景用一個(gè)本地可運(yùn)行的小模型配合一套簡單的工具調(diào)用邏輯在普通電腦上先完成“感知—規(guī)劃—調(diào)用—反饋”的閉環(huán)。等這個(gè)閉環(huán)穩(wěn)定后再嘗試把模型量化、部署到開發(fā)板、加入傳感器輸入。每往后走一步你都會(huì)更清楚地看到真正卡住系統(tǒng)的瓶頸是什么是模型效果不夠是內(nèi)存帶寬不足還是系統(tǒng)層面的外設(shè)兼容問題。5.2 長期維護(hù)才是真正的分水嶺本地智能體硬件作為一個(gè)長期運(yùn)行的設(shè)備它的維護(hù)成本和云端服務(wù)完全不同。云端方案里模型更新、服務(wù)擴(kuò)容、異常監(jiān)控都由平臺(tái)承擔(dān)本地方案里這些工作都要自己做。你需要提前考慮模型版本升級(jí)策略設(shè)備已經(jīng)部署了舊模型新模型來了怎么灰度切換怎么保證回滾你需要處理設(shè)備日志的上報(bào)和分析流程你需要設(shè)計(jì)一種機(jī)制讓設(shè)備在本地模型無法處理時(shí)能夠優(yōu)雅地上報(bào)云端而不是讓用戶卡在一個(gè)失敗的交互里你還要為硬件故障預(yù)留遠(yuǎn)程診斷通道。這些工程化能力才是本地智能體真正走向產(chǎn)品化的門檻。也正因?yàn)槿绱巳魏我粋€(gè)宣稱“本地智能體將取代云端”的判斷都需要謹(jǐn)慎對(duì)待。更現(xiàn)實(shí)的圖景是端云協(xié)同長期并存。本地設(shè)備成為 token 入口承擔(dān)高頻、低延遲、隱私敏感的第一層處理云端繼續(xù)承擔(dān)強(qiáng)推理、通用知識(shí)和跨場景協(xié)同。這兩者不是替代關(guān)系而是上下游關(guān)系。5.3 回到最開始那個(gè)觀察回到最開頭控制臺(tái)里的 token 數(shù)字。如果 Perplexity CEO 的判斷成真那么未來你看到的 token 計(jì)數(shù)器可能不再只屬于某一個(gè) API 平臺(tái)而是分散在各種設(shè)備里。有些 token 在云端產(chǎn)生有些 token 在本地產(chǎn)生有些按 API 計(jì)費(fèi)有些隨硬件一起交付有些追求極致性能有些追求隱私和離線可用。對(duì)普通開發(fā)者來說最重要的不是爭論哪種硬件會(huì)贏而是提前建立一種能力能夠判斷一個(gè)任務(wù)應(yīng)該消耗哪里的 token。這種判斷力會(huì)決定你在新一波 AI 應(yīng)用浪潮里是跟著別人的入口走還是自己占據(jù)一個(gè)入口。本地智能體是不是最終答案沒有人能確定。但有一點(diǎn)可以確定token 的消耗位置正在從云端唯一中心向端側(cè)多點(diǎn)擴(kuò)散。理解這個(gè)變化比記住任何單一硬件名字都重要。