晶片即模型

晶片即模型 – 將 AI 推理搬到使用者的裝置

「晶片即模型」的意思是,當每台裝置都內建一顆刻進晶片的 AI 小模型,模型不再是需要載入的軟體,而是隨時待命的運算晶片,應用程式所需的 LLM 推理可直接在訪客裝置端就地完成,讓網站主的 AI 運算成本歸零,這正是 RAG Chatbot 的終極目標。

由於網站上的 Chatbot 是提供給訪客的免費公共設施,AI 成本全由網站主承擔,因此我們從最小模型出發,將任務拆解到最細,讓每個 AI 節點都能由最輕量的小模型完成,網站知識則交由 RAG Sitemap 提供;這套架構在今天已經讓小模型順利運作,一旦邊緣晶片普及,「晶片即模型」落地,網站主的維運成本歸零只是水到渠成。

為什麼這套 RAG Harness 架構押注最小模型

這套架構從最小模型出發,不是技術上的將就,而是一個現實問題逼出來的答案,「讓網站主長期負擔得起」。網站上的 Chatbot 不是站長個人用的 ChatGPT,是要免費服務訪客的公共設施,一般網站主不像 Google 或 OpenAI 那樣家大業大,可以讓全世界數億人免費呼叫前沿大模型。訪客的 AI 帳單全由網站主承擔,網站越大成本越高,這條成本曲線決定了 Chatbot 能不能在一個站上長期跑下去。

我們所開發的 RAG Chatbot 在每個 AI 運作的節點上都往最小模型靠攏,因為只要將任務拆得夠細,每一段 AI 節點就只剩單純的工作,即使是最便宜的小模型也能勝任。本產品把 2024 年的 Llama 3.2 3B 當成開發與測試的規格基準,就像遊戲廠商會挑一張入門顯卡當作最低門檻來打磨,連最弱的模型都跑得動,換上更強的模型就會讓顧客體驗更好。同等參數量級的最新小模型已經比當時強上數倍,網站主未來能用到的小模型只會比現在更強。

終端裝置的硬體也在朝小模型靠攏

NPU 這種專門為 AI 推理設計的小晶片,早在 2023 年就悄悄進到消費級的 CPU 裡,只是當時效能太低,跑不動什麼有意義的模型。近一兩年算力跨過門檻,才真正能在本地跑起小模型,如今低功耗、佔空間小的 NPU 已經是新裝置的標準規格。Windows 上的 Copilot+ PC 內建了 Phi Silica 這個 3B 參數的小模型,Apple 從 iPhone 到 Mac 的晶片裡都有 Neural Engine,Android 陣營的高通、聯發科也各自把 NPU 做進手機晶片。裝置端開始長出能就地推理的小模型,這條軌跡成立,意味著把網站 AI Chatbot 的運算交給訪客的裝置、讓網站主成本歸零,不是空想,而是有真實基礎的方向。

但機會出現,不等於今天就能靠它。對一個要服務任意訪客的網站來說,問題歸結成一件事,網站無法假設訪客的瀏覽器裡,有一個能直接呼叫的裝置端模型。一來入口還沒齊,網頁端目前唯一摸得到裝置模型的路是 Chrome 的內建模型,但它還在實驗階段,預設關著、要手動開啟才能用,Safari、Firefox 也都還沒有對等的東西;二來就算瀏覽器支援,模型也要在使用時透過背景下載好幾 GB。你的 Chatbot 面對的是任意瀏覽器,沒辦法假設訪客手上那台裝置既開得了這道門、模型又剛好在那裡。

所以方向已定、機會已現,但今天還在過渡期。在這個入口普及到每一台裝置之前,RAG Chatbot 依然靠雲端的免費 API 與便宜的小模型在跑,而這套搭配今天就走得通。裝置端不是現在要依賴的方案,是這套架構從一開始就為它預留的去處。缺的從來不是模型的能力,導航這個角色,最便宜的小模型早就夠用;還沒到位的,是讓模型在訪客自己的裝置上就地推理的入口,它還沒出現在每一台裝置裡。接下來的問題,是這個入口會從哪裡來,而最徹底的答案,是讓模型不再是需要載入的軟體。

晶片即模型

把 AI 推理搬回使用者的裝置,網站主的運算成本歸零。

今天
雲端 API
推理在雲端完成,答案送回訪客裝置 推理

推理在雲端完成,網站主承擔帳單。任務拆得夠細,便宜的小模型就能勝任,這套搭配今天就走得通。

推理位置 · 雲端推理速度 · 快網站主帳單 · 付費
過渡
瀏覽器內建模型
模型內建進瀏覽器,每次推理都要載進記憶體 模型 記憶體 每次推理載入

模型內建進瀏覽器、一次下載所有網站共用,推理回到訪客裝置。但模型仍是軟體,每次推理都要把幾 GB 權重載進記憶體。

推理位置 · 訪客 - 下載模型推理速度 · 慢網站主帳單 · 歸零
終局
晶片即模型
權重刻進晶片電路,不載入、不佔記憶體

權重不再是載進記憶體的資料,而是刻在晶片上的電路。不載入、不佔記憶體,AI 像 Wi-Fi 一樣隨時待命。

推理位置 · 訪客 - LLM 晶片推理速度 · 極快網站主帳單 · 歸零

三階段不變的前提

模型只負責讀懂與導航,網站知識由 RAG Sitemap 提供。正因為知識不靠模型內建,最便宜的小模型就足以勝任,這套架構也才得以一路走進邊緣晶片。

更徹底的一步,是讓模型變成晶片本身

讓權重不再是載進記憶體的資料,而是刻在晶片上的電路。不佔記憶體、不用載入,推理快得像刻在腦海裡的九九乘法表,張口就來。Taalas 已經在做這件事,他們的第一顆晶片 HC1 把 Llama 3.1 8B 刻進矽晶片裡,但這只是揭開序幕,他們之所以選 8B 的模型是因為它夠小、方便作為 MVP。而技術本身正一代一代往更強的模型推進,剩下的只是「晶片即模型」什麼時候走進終端裝置。

刻進晶片的會是一個小模型,因為邊緣裝置的本質就是小、輕、低功耗。消費端的手機、筆電,使用者的需求五花八門,晶片裡那顆模型必須什麼都能問,是一顆能處理文字、影像、語音的通用模型。如果為每種功能各刻一款專用晶片,等於又走回碎片化的老路,每一款都要重新開發、成本高到撐不起市場。唯有一顆能被所有應用共用的小模型晶片,才有足夠的經濟價值被裝進每一支手機、每一台筆電,成為跟記憶體模組一樣的標準配件。當它遍地都在,開發者才有動機在它上面開發,規模與生態也才從這個基礎上長出來。刻進晶片的模型不能改,但這不是缺陷,裝置本來就逐代換新,模型跟著裝置世代更新,和 CPU、鏡頭、電池、Wi-Fi 模組每一代規格往上走是同一回事。

終局是 AI 在使用者終端隨時待命,網站主帳單歸零

當每台裝置都內建一個刻進晶片的小模型,AI 就跟 Wi-Fi 一樣在背景隨時待命,這也正是這套 RAG Chatbot 等待的那一天。刻進晶片的小模型世界知識有限,但邊緣場景要的本來就不是世界知識,而是眼前這個應用、這個網站的相關知識,網站知識交給 RAG Sitemap 提供,模型只負責讀懂與導航。從那一刻起,它可以直接交給使用者端的邊緣模型來跑,連線上 API 都不再需要,訪客的提問在自己的裝置裡就地完成。

網站主這一端,只需要專注在把網站內容經營好、裝上 RAG Chatbot、定義好網站的個性(SOUL.md),剩下的 AI 推理成本歸零,運作成本進一步壓縮到接近免費。打遊戲靠自己的顯示卡,看影片靠自己的螢幕,問 AI 終究也會回到自己的裝置裡推理。

軟體層面,已經先向前一步

把模型刻進晶片之所以是終點,是因為權重直接成了電路,沒有東西要從記憶體搬進搬出,又快又省電到了極限。但在那一天到來之前,軟體層面已經先向前一步。Chrome 的 Prompt API 讓瀏覽器自己內建一個小模型,一次下載、所有網站共用,訪客不必自備模型,提問就在自己的裝置上完成運算。這正是這套 RAG Chatbot 在等的存取方式,只是把「內建在瀏覽器」當成是「晶片即模型」之前的過渡,而這個方式今天在技術層面上已經跑得起來。

但能跑不代表是時候。瀏覽器在背景自己下載一個以 GB 為單位的模型,一般應用程式還在以 MB 計,它一口就吃掉好幾 GB 的硬碟,多數使用者沒同意過,且空間不足時還會被自動清掉、要用時得重新下載。然而這些都是會被磨平的稜角,未來下載可以更省、同意流程可以更清楚、儲存可以再優化。但有一件事磨不掉,只要模型還是軟體,每次推理就得把這幾 GB 的權重載進記憶體,本來就不夠用的 RAM 永遠要被佔走一塊。隱私與佔空間的疑慮會隨技術成熟而平息,但記憶體這條稅不會,因為它不是哪個版本沒做好,是軟體模型的宿命。真正能跨越障礙的,就是讓模型不再是載入的軟體,而是刻進晶片的模型。

相關文章

你以為 RAG 是訓練 AI Chatbot 讀懂網站?其實是在反向校準你的網站 SEO 體質。RAG Sitemap 捨棄黑箱向量庫,直接讀取 WordPress 裡面,你早已寫好的標題、分類與描述,生成 TXT 網站地圖給 AI。當 AI 找不到答案時,問題往往就出在某篇文章的標題、摘要或分類歸屬上,你只需要用平常做 SEO 的方式進後台修正,不需要學新工具,也不需要通靈演算法。

llms.txt 是一份專為 AI 閱讀設計的 sitemap,但它的局限在於只有一層,對有組織、有架構的網站不夠用。這份檔案的標準格式是網站名稱當 H1、一段摘要,底下每一列是一個 [標題](連結):描述,指向網站裡的一個頁面。但它分不出這一列是分類頁、單一頁面、文章還是商品頁,每一列都被當成同一種東西。初衷沒有錯,目標是讓 AI 更容易地讀懂你的網站。但是問題不在描述,而是在於它把網站壓平成一層,破壞了網站原本的敘事能力與內容脈絡。

向量資料庫不是 RAG 的必要條件,它只是其中一種把資料餵給 AI 的方式。當資料本來是混亂的、缺乏清楚邊界的,向量化可以幫助模型從大量文字中猜測語意相關性,這種做法有它的價值。但如果內容本來就有秩序,問題就不再是「怎麼從混亂中硬算相關」,而是「怎麼讓 AI 先看到最重要的判讀線索」。真正有效的 RAG,不一定是先把全文切碎、壓成向量再回頭猜答案;也可以是先把內容整理成 AI 能逐層理解的路徑,先降低上下文的不確定性,再展開細節。