作者:阿中哥 + AI 協助彙整。 【本文約有4775字】
AI 的下一場競爭,不只比晶片算力:從 CUDA 與 NPU 看開發生態、能源與普惠運算
2026 年 11 月 8 日|技術觀察與產業評論
觀看《邦妮區塊鏈》訪問耐能創辦人劉峻誠(Albert Liu)後的技術觀察與延伸思考。本文聚焦技術生態系。
寫在前面:一場專訪引發的生態系思考
最近看完《邦妮區塊鏈》對耐能(Kneron)創辦人劉峻誠(Albert Liu)的專訪,心中留下的不是哪一種晶片必然勝出,而是一個更大的問題:當 AI 成為日常基礎設施,我們能不能用更合理的成本與能源,讓更多人享有它的好處?
訪談來源: 《股市血崩,政府救市!科技財報猛創新高,但市場為什麼突然這麼害怕?》|YouTube 專訪
訪談中,受訪者以農耕的開墾、插秧、收割比喻 AI 運算的不同階段:模型訓練、推論,以及逐漸走向裝置端的實體 AI。他也用廚房裡不同刀具的比喻,說明 CPU、GPU、NPU 與客製化 ASIC 可能各有適合的任務,而不必由同一種硬體包辦一切。這個觀點促使我重新思考:未來的 AI 運算平台,是否應該由多種架構分工,而不是只追求單一晶片的最高算力?
另一段令我印象深刻的內容,是受訪者談到 CUDA 軟體生態的力量。他認為 GPU 之所以在 AI 時代佔有重要地位,不只因為硬體,也因為多年累積的開發工具與使用習慣。這讓我想進一步比較:NVIDIA 的 CUDA、耐能的 NPU Toolchain,以及 GitHub 上可觀察到的開發者參與,究竟呈現出什麼樣的生態差異?
訪談也談到 AI 資料中心的投資、電力需求、散熱與環境負擔,並提出 CPU、GPU、NPU 混合部署的想像。這些問題值得嚴肅討論;但受訪者對能源節省幅度、單次 AI 提問耗電量,以及異常天氣成因的比喻或主張,不能直接視為已經完成獨立驗證的科學結論。本文會將「專訪中的觀點」、「公開技術資料」與「我自己的延伸判斷」分開處理。
我希望這篇文章不是對任何人或企業的評分,而是一份看完專訪後的技術筆記:如果生態系能更開放、模型能更容易移植、硬體能各司其職,是否就有機會降低 AI 的電力與總持有成本,讓中小企業、教育、醫療與一般家庭都能真正受惠?
一、AI 的競爭,為什麼不能只看晶片?
談到人工智慧運算,最容易吸引目光的是硬體數字:多少 TOPS、多少 TFLOPS、能容納幾百億參數、每秒生成多少 Token,以及耗電多少瓦。然而,真正決定一種技術能否走進千百家企業的,往往不是規格表最亮眼的數字,而是規格表之外的整套「生態系」。
試想,一家中小企業想建立內部知識庫,讓員工能用自然語言查詢產品規格、作業流程與歷史文件。企業不會先問:「你使用哪一種矩陣乘法指令?」它會問:「能不能安裝?模型能不能換?資料會不會外洩?速度夠不夠?明年還有人維護嗎?」這些問題的答案,主要來自軟體工具、模型支援、文件、社群、供應商與服務體系,而不只是一顆晶片。
因此,討論 NVIDIA GPU 與耐能(Kneron)NPU 時,我們不妨把焦點從企業或人物移開,回到一個更具公共價值的問題:什麼樣的 AI 運算生態,才能讓更多人以可負擔的價格使用人工智慧,同時降低能源與環境負擔?
二、CUDA 的真正力量:從訓練一路走到推論
NVIDIA 的重要優勢,不只是 GPU 具備高度平行運算能力,更在於 CUDA 長期累積的開發環境。研究者可以利用 PyTorch 等框架在 GPU 上訓練模型;訓練完成後,再透過 Transformers、vLLM、TensorRT-LLM 或其他工具部署推論。這不表示訓練與推論完全不需要轉換,而是許多必要步驟已被成熟的工具鏈包裝、整合與自動化。
CUDA 也不等於 Transformer。前者是運算平台與軟體生態,後者是神經網路架構;同樣地,Ollama、vLLM 和 SGLang 是模型執行與服務工具,並非模型本身。把這些層次區分清楚,才不會誤以為換一個推論框架,就能把模型的 Attention 架構變成另一種神經網路。
成熟生態的價值還包括「遇到問題時有替代道路」。某個推論引擎尚未支援新模型,可以先試其他框架;某個量化格式表現不佳,可以更換精度;某個部署環境出錯,網路上通常找得到文件、討論與範例。這些看似零碎的便利,會累積成企業真正感受到的時間成本與風險差異。
當開發者越多,第三方工具越容易出現;工具越完整,更多企業願意採用;企業採用越多,又能反過來吸引開發者。這是一種正向循環,也是生態系的網路效應。
三、NPU 的不同路線:讓專用推論更有效率
相較於通用 GPU,NPU 的設計通常更強調特定神經網路運算的效率。對於長時間、重複執行、模型相對固定的工作,例如人流計數、影像分類、設備監測或特定問答服務,專用加速器有機會以較低功耗完成任務。
耐能的公開 Toolchain 文件展示了一條典型路徑:將相容的模型準備為指定格式,檢查運算子支援,進行量化與編譯,最後部署到 NPU 執行。這個流程不是把任意 Transformer 自動改造成 Mamba,而是讓原本相容的模型轉成硬體能理解的執行形式。
這裡存在一個重要取捨:專用硬體若能針對固定工作負載充分最佳化,可能取得很好的每瓦效能;但若模型架構更新、出現新運算子,或使用者想快速切換不同 LLM,硬體與編譯器的支援範圍就會變成關鍵。晶片有算力,不代表任何模型都能直接跑;能載入模型,也不代表輸出品質、上下文長度與實際吞吐量一定符合需求。
所以我們不應把 GPU 與 NPU 簡化成「前者訓練、後者推論」。GPU 同樣大量用於推論,NPU 也不是所有推論工作的最佳解。更合理的問題是:在相同品質、相同延遲與相同工作量下,哪一種架構能以更低的總成本完成任務?
四、Mamba 的啟示:演算法與硬體必須一起進步
近年來,Mamba 受到關注,是因為它採用選擇性狀態空間模型(Selective State Space Model)處理序列資訊,與主流 Transformer 的 Attention 路線不同。對某些長序列任務,Mamba 的狀態更新方式可能降低記憶體需求,帶來效率上的新可能。
耐能曾公開宣稱,KL1140 可支援 Mamba 類型模型,並提出多晶片串接支援大型參數模型的方向。這是值得研究的技術訊號,但不能據此推論所有 Qwen、Llama 或 MoE 模型都能直接部署,也不能把「可支援 120B」等同於「已在相同條件下證明比 GPU 更快、更省電」。模型類型、量化精度、上下文長度、首字延遲、Token 吞吐量與整機功耗,都必須列出來才能比較。
尤其需要澄清:模型編譯不等於模型架構轉換。把 Transformer 的運算圖編譯到 NPU,與把 Transformer 重新設計、蒸餾成 Mamba,是兩個不同層次的工程。後者通常涉及重新訓練與能力驗證,不能假設一套 Compiler 就能自動完成。
這件事帶來更深的啟示:未來降低 AI 能耗,不一定只能依賴更先進的製程或更大的晶片。模型架構、量化方法、記憶體管理、推論排程與硬體協同設計,都可能是突破口。
五、GitHub 星星數:可以觀察生態,卻不能直接當成市占率
如果想觀察開發生態是否成熟,GitHub 是一個有用的窗口。公開 Repository 數量、Stars、Forks、Issue、Pull Request、Commit 活動,以及第三方整合案例,都能反映某種程度的開發者參與。
以 NVIDIA 的 TensorRT、TensorRT-LLM 與耐能的 ONNX_Convertor、host_lib 等公開專案相比,兩者的社群規模確實呈現明顯差異。這個差異對開發者很實際:搜尋範例、排查錯誤、尋找現成整合套件時,公開資源越多,通常越容易自行解決問題。
但我們也必須避免過度解讀。GitHub Stars 不是活躍使用者數,Forks 不是企業訂單,公開 Repository 數量也不是晶片出貨量。企業可能使用私有 SDK、簽署保密協議,甚至將 NPU 整合進設備,完全不在 GitHub 留下足跡。一般訪客也無法取得他人 Repository 完整的 Clone 歷史統計。
更公平的比較方式,是把 GitHub 當作「開放程度與開發者可取得性」的觀察指標之一,再搭配模型相容清單、SDK 更新頻率、可重現的效能測試、文件品質與第三方實際部署案例。這樣才能避免把公開聲量誤認為全部市場實力。
六、企業專案與標準產品:兩種不同的生態發展方式
AI 晶片廠商面對的客戶可能是設備製造商、醫院、工廠或大型企業。這些客戶的需求差異極大,從攝影機辨識到私有知識庫,從單機離線運作到多使用者服務,往往都需要現場驗證與系統整合。因此,採用專案洽談、配置設備、提供客製化報價,並不罕見。
但從中小企業的角度來看,標準化產品仍有難以取代的價值。假如能清楚提供 A、B、C 方案,列明支援模型、同時使用人數、推論速度、電力需求、資料保護、保固及年度維護費,企業就更容易評估投資報酬率,也更容易在不同供應商之間比較。
標準化的意義,不是所有客戶都只能用同一套設備,而是把最常見的需求整理成可重複交付、可驗收、可維護的服務。當安裝門檻下降,AI 才能從少數大型專案走向更多小型工廠、診所、零售店與教育機構。
對系統整合業者而言,這也創造了機會:上游專注晶片與推論引擎,下游則把它包裝成真正解決問題的工具。客戶買的不是 TOPS,而是節省多少工時、降低多少錯誤、改善多少服務品質。
從專訪的「三階段」看互補,而不是取代
專訪將 AI 算力發展描述為訓練、推論與實體/端側 AI 三個階段。這個比喻有助於理解運算需求如何擴散,但不宜理解成「進入第二階段後,第一階段就結束」:大型模型仍需持續訓練,GPU 也會繼續承擔大量推論工作。更可能出現的是不同工作負載同時存在,由不同硬體承接。
受訪者也提到 Kneo Rack、Kneo 350,以及醫療機構的私有化 AI 應用。這些案例提醒我們:企業需要的往往不是一顆晶片,而是模型、資料、介面、安全性與維護服務共同構成的解決方案。不過,訪談並未提供足以比較的採購價格、模型名稱、每秒 Token 數或整機功耗,因此不能只憑案例就判斷哪一種架構最便宜。
七、省電不能只看晶片瓦數:要看整個生命週期
談到 NPU,最吸引人的主張之一就是低功耗。這個方向值得肯定,但也最容易被過度簡化。一顆晶片標示只有幾瓦,不代表整套系統只耗幾瓦。攝影機、CPU、記憶體、SSD、網路設備、電源轉換、散熱與待機時間,都會影響實際電力使用。
比較兩套 AI 系統時,應至少同時記錄:完成相同任務所需時間、整機平均功耗、閒置功耗、模型品質,以及硬體採購和維護成本。若一台設備雖然瞬間功耗低,卻要花十倍時間才能完成工作,最後耗電未必比較少。相反地,若工作負載固定、推論需求持續穩定,專用加速器的每次推論耗能就可能很有競爭力。
還有一個常被忽略的問題:訓練成本與推論成本是不同的帳。大型模型訓練可能集中在少數資料中心,但一旦模型被數百萬人每天使用,長期累積的推論用電同樣重要。模型壓縮、快取、批次排程、合理的模型大小、邊緣運算與避免不必要的推論,可能共同降低總能耗。
如果討論環境影響,也不能只計算電費。硬體製造涉及原物料、晶圓製程與運輸;資料中心可能需要用水冷卻;設備淘汰又會形成電子廢棄物。能源來源的碳排強度也會影響結果。同樣一度電,在不同地區與不同時段,對氣候的影響可能不同。
因此,真正負責任的指標應該是:在符合品質與服務需求的前提下,盡可能降低每項有效 AI 任務的總能源與生命週期環境負擔。
八、AI 與氣候變遷:技術效率是解方之一,不是全部答案
我們確實需要正視 AI 基礎設施帶來的電力需求。資料中心擴建可能增加電網負荷,而在依賴化石燃料發電的地區,也可能增加溫室氣體排放,進一步加劇全球暖化風險。全球暖化會影響極端高溫、強降雨等氣候風險,但不能把單一異常天氣事件直接歸因於某一家 AI 公司或某一種晶片。
另一方面,更有效率的運算也未必自動帶來總耗電下降。當每次推論變得便宜,人們可能使用更多 AI,企業也可能部署更多服務。這是所謂的「反彈效應」:單位效率提高,總需求卻可能同步增加。
因此,我們期待的不是只靠某一種晶片拯救地球,而是一個能持續改進的生態:更節能的模型、更有效率的軟硬體、更透明的能耗測量、更乾淨的電力、更長的設備使用壽命,以及對不必要運算的節制。
如果這些條件能一起前進,AI 的普及就不必只能依賴持續堆疊更昂貴、更耗電的設備。
九、真正值得期待的是多元、互通、可選擇的 AI 生態
從產業發展來看,GPU 與 NPU 不一定要是零和競爭。研究機構可以繼續利用通用 GPU 訓練與探索新模型;企業可以選擇 GPU 來支援頻繁更新的 LLM;固定任務、低功耗設備則可能採用 NPU;必要時也能透過 CPU、GPU、NPU 協作完成服務。
關鍵在於能否降低轉換成本。如果模型有公開規格,推論服務有標準 API,效能測試可重現,開發工具有清楚文件,企業就不必因為更換硬體而重寫整套系統。當供應商之間能在合理範圍內互通,市場競爭就有機會從「綁定使用者」轉向「提供更好的品質、成本與效率」。
我期待未來的 AI 運算平台,不論採用哪一家的晶片,都能清楚回答幾個基本問題:支援哪些模型?更新要多久?每秒可以服務多少使用者?每千個有效輸出 Token 需要多少電?軟體維護能持續幾年?資料是否能留在企業內部?
這些問題看似不如晶片發布會的數字耀眼,卻直接決定 AI 能否被真正信任與長期使用。
十、結語:最好的 AI 生態,是讓更多人用得起,也讓地球負擔得起
一個成熟的 AI 生態系,不應只有最先進的晶片,也要有足夠好的工具、清楚的文件、持續更新的模型支援、容易取得的設備,以及能把技術轉化成實際價值的服務業者。
我們不必預設 GPU 一定勝出,也不必期待 NPU 立即取代所有 GPU。更有意義的方向,是讓不同架構在適合的工作上發揮長處,讓開發者有選擇,讓企業有能力比較,讓市場以可驗證的效能與成本推動進步。
如果未來能以更少的電、更合理的硬體投入,完成同樣甚至更好的 AI 任務,那麼受益者不應只是大型科技公司。中小企業可以減輕數位轉型成本,學校可以提供更好的教學資源,醫療機構可以改善行政與資訊服務,一般家庭也能更安心地使用在地端 AI。
AI 的下一場競爭,不只是誰擁有最快的晶片,而是誰能建立一個更開放、更節能、更容易負擔、讓更多人共同受惠的生態系。
這才是值得我們持續關注的長期方向。
延伸閱讀與查證入口
以下提供可持續追蹤的原始資料入口;各家產品支援範圍、數據與價格會更新,實際採購仍應以最新文件及同條件實測為準。
- 引發本文思考的 YouTube 專訪
- NVIDIA CUDA Toolkit
- NVIDIA TensorRT-LLM(GitHub)
- NVIDIA TensorRT(GitHub)
- Kneron 官方 GitHub
- Kneron ONNX_Convertor
- Kneron KneoEdge
- Mamba 原始論文(arXiv)
- 國際能源總署 IEA:Energy and AI
註:本文為技術與產業觀察,不是產品效能認證或企業投資建議。文中對未來發展的討論屬分析與推論。