AI量產真相：省硬體、拚即時、防造假的工程實戰課

🧭 本單元白話講

這門課的第一站，不從『AI有多聰明』開始講，而是從兩則工程新聞開始，因為它們剛好回答了一個更貼近你生活的問題：為什麼我們現在用的AI助理，講話終於比較不會『卡卡的』、也終於能塞進一台普通筆電裡跑？答案不是模型突然變聰明了，而是背後有一群工程師，花了好幾個月，把『能在展示會上驚艷全場的demo』，硬生生改造成『天天能用、不會當機、不會燒錢』的產品。

第一則新聞主角是 Liquid AI 推出的 LFM2.5，一個只有 26 億參數（比很多主流模型小好幾倍）的 agent能自己判斷要用哪個工具、分好幾個步驟去完成一件任務的AI程式，不是只會回答一句話模型。它厲害的地方不是『考試分數贏過大模型』，而是能在一台 Apple 筆電上跑到每秒 220 個字、在一般 AMD 筆電 CPU 上也有 113 個字，而且只吃不到 2.5GB 記憶體——這代表它可以直接裝進你的筆電、甚至更小的裝置裡運作，不必遠端連到昂貴的伺服器機房。要做到『小但不弱』，團隊用了四階段訓練：先讓模型大量模仿範例（監督式微調），再訓練幾個『某個領域特別強』的老師模型，接著把這些老師的功力蒸餾（distillation）讓小模型反覆看大模型的解題過程來學習，把大模型的能力『濃縮』進體積小很多的模型裡進一個學生模型，最後再丟進真實的工具箱環境裡做強化學習讓AI實際動手做任務、依照做得好不好給獎勵分數，一步步調整它下次的行為，而不是只靠人工寫死規則，逼它在真的會呼叫工具、會犯錯、會被扣分的環境裡把動作練熟。

第二則新聞主角是 OpenAI 的新一代語音系統 GPT-Live。過去的語音AI有個很不自然的毛病：它得先靠一個專門的『turn detector專門判斷『使用者是不是講完了、AI可以開始接話了』的小模型，過去語音AI靠它來決定何時開口』猜你講完了沒，猜早了會打斷你，猜晚了就會讓對話變得慢半拍。GPT-Live 直接把這個猜測步驟從對話流程裡拿掉，改用全雙工（full-duplex）AI可以同時『聽』和『說』，就像真人聊天一樣可以隨時插話或接話，不必像對講機一樣『你講完換我講』的架構，讓AI能一邊聽你說話一邊準備回應。遇到需要深度思考或動用工具的複雜問題時，它才會悄悄去問更強的模型（例如 GPT-5.5）幫忙，而且不會讓你感覺對話卡住。這背後是OpenAI花了半年時間，重寫模型推論、上下文管理、語音傳輸三大塊架構才做到的。

把這兩則新聞放在一起看，你會發現一個共通的工程套路：不是把模型做得更大、更聰明就好，而是先想清楚『使用者實際會遇到什麼限制』——筆電記憶體不夠大、對話不能卡頓——然後針對這個限制，把系統拆解重組：該省的資源狠狠省下來（LFM2.5瘦身到2.5GB還能跑贏4倍大的模型），該拿掉的瓶頸直接拿掉（GPT-Live拿掉turn detector），真正需要重兵力的時候才動用大模型支援。這就是『量產』和『demo』最大的差別：demo只要在鎂光燈下順一次，量產卻要撐住成千上萬個使用者、天天在用、還不能燒爆雲端帳單。

這也是接下來這堂課要一路帶你拆解的主題：當AI從『看起來很厲害』走向『真的能撐住』，工程師到底在忙些什麼、又是靠什麼取捨做到的。下一站，我們會繼續問一個更直接的問題——為什麼現在整個產業拼的重點，好像從『誰的模型比較聰明』，變成『誰的工程做得比較扎實』？

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元看到，新模型一款接著一款發布、參數量一路飆高，乍看是「模型比賽」愈演愈烈的量產時代。但當你把鏡頭拉近，會發現真正逼著工程師天天加班的，不是「模型夠不夠聰明」，而是三個很現實的限制：顯卡裝不裝得下、回應快不快得起來、內容可不可以信任。這三關過不了，模型再聰明也只是實驗室裡的展示品，到不了使用者手上。這一集用兩個真實案例，帶你看懂為什麼現在的戰場早就從「誰的模型比較大」，轉移到「誰能把大模型真正撐起來、跑得動、講真話」。

先看硬體這一關。AirLLM 這個開源工具解決的問題很直白：一個要價數萬美元顯卡才跑得動的 70B（700億參數）大模型，能不能塞進一張只有 4GB VRAM顯示卡上專門暫存模型和運算資料的記憶體，GPU要算東西全靠它，裝不下模型就直接當機或算不出來 的入門顯卡？答案是能，靠的不是把模型變小，而是「逐層串流」——把模型切成一片一片，GPU 算完這一片就把它換掉，換下一片進來，全程沒有人真的把整個模型塞進顯卡。2026 年 7 月的最新版本更進一步，支援目前參數量最大的開源模型 Kimi K3（2.8兆參數），靠的是同樣邏輯的 MoE把一個超大模型拆成很多位「專家」，使用者的問題丟進來時只挑最合適的幾位專家出來工作，不必整組人馬同時上場 「逐專家串流」，讓一台顯卡用不到 4GB 記憶體就能推論這個巨獸模型。

但這裡藏著一個工程師才會在意的代價：模型參數不再一次全部躺在顯卡裡，而是要一片一片從硬碟或主記憶體現搬過來，這代表每算一步都多了一趟「搬家」的時間。省下硬體成本，換來的是速度變慢——這正是課程標題講的「省硬體」和「拚即時」互相拉扯的現場。AirLLM 選擇的解法是用「預先抓取」蓋掉搬運等待時間、加上量化壓縮加速三倍運算，盡量在省顯卡跟跑得快之間找到能用的平衡點，而不是硬要兩邊都拿滿分。這種取捨判斷，本身就是「拼工程」而非「拼模型」的具體展現。

再看信任這一關，案例換成一家寫標案文件的 AI 新創 Lucius。他們發現，模型只要抓不到「自己有沒有資格說這句話」的界線，預設行為就是編。有一次內部稽核發現，AI 幫一份 NHS 標案生成的草稿裡，竟然憑空發明了一個根本不存在的合作夥伴，還把 42 項資格要求都算在這個「幻影夥伴」頭上——這就是典型的 hallucination（幻覺）AI 在沒有事實根據時，仍然自信地編出聽起來合理但其實是假的內容。更麻煩的是，他們自己寫的合規檢查工具也被騙過去了：檢查工具只靠「關鍵字有沒有出現」來判斷合不合格，而幻覺出來的文字剛好用對了關鍵字，於是兩個各自看起來都合理的元件，組合起來變成一套會說謊又會幫自己蓋章通過的系統。

Lucius 團隊事後承認，解法不是換一個「比較誠實」的模型，而是重新設計系統結構：先讓 AI 逐條核對「這項資格我方有沒有實際證據」，沒有證據的項目直接標示成「還沒有人可以回答」，而不是讓模型自己腦補接龍。這跟 AirLLM 用逐層／逐專家串流解決硬體限制，是同一種思路——問題不是模型不夠強，是系統沒有幫模型把守住現實的邊界。這也是為什麼現在人人都在拼工程：模型的原始能力早就夠用，真正決定一個 AI 產品能不能上線、能不能讓人放心用的，是工程師怎麼在硬體、速度、誠實這三條紅線之間，把系統搭得撐得住。

⚙️ 脈絡拆解

🔍 程式碼漫遊（點有 ● 的行看白話講解）

AirLLM 的重點不在演算法多花俏，而在「一行程式碼呼叫超大模型」背後，悄悄把「逐層串流」這件麻煩事都做掉了。

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元說到，現在AI圈拚的是工程而不是模型——這句話聽起來像是口號，但工程師的辦公桌上，究竟長什麼樣子？這一單元，我們直接翻開三個真實案例的施工紀錄：一個工程師怎麼把三千億參數的模型硬塞進一張顯卡，一家公司怎麼讓終端機裡跑著的多個AI分身互相接力不出錯，以及另一家公司怎麼硬生生教會AI「不准說謊」。三個案例，剛好對應工程師最常打的三場硬仗：硬體瘦身、多代理協作、防止AI一本正經胡說八道。

先看硬體這一場。DeepSeek V4 Flash是一個3040億參數的巨型模型，官方建議的跑法是用NVIDIA顯卡或是更新款的AMD晶片。但這篇文章的作者偏偏只用一張舊一代的AMD MI300X顯卡，就把整個模型完整塞進去——不做任何量化(quantization)把模型參數壓縮成更省空間的數字格式，犧牲一點準確度換取更小的檔案跟更快速度，也不用把部分參數搬到硬碟上減輕負擔。關鍵在於這張卡有192GB的HBM顯卡內建的高速記憶體，容量與頻寬直接決定能塞下多大的模型、同時處理多少人的請求，比NVIDIA H100多出2.4倍。但硬體夠大只是及格線，真正的工程活是修正AMD晶片跟NVIDIA晶片對FP8把數字用8位元的省空間格式儲存的技術，AMD跟NVIDIA兩家對這個格式的定義其實不一樣的定義落差——如果照抄NVIDIA的假設去寫程式，算出來的數字可能整整錯一倍。作者形容得很清楚：先求正確，再談效能調校，順序不能顛倒。

第二場硬仗是多代理協作。Meta推出的終端機編碼工具Muse Code，讓一個主要AI助手底下常駐好幾個背景子代理(background agent)主要AI助手底下持續運作、專門處理特定任務的輔助AI分身，整個工作階段都不下線，不必每次都重新了解專案背景，彼此分工同時進行，不必每次任務都重新摸索一次專案架構。更關鍵的設計是事件日誌(event log)把每一次模型呼叫、每一個工具執行、每一次核准跟修改都完整寫進的紀錄檔——每個模型呼叫、工具執行、核准、修改都完整寫進log，就算當機，也能照著紀錄精準接回原本卡住的那一步，不必整個重來。這解決的正是長時間、多步驟任務最怕的問題：跑到一半斷線，心血歸零。

第三場硬仗最貼近多數人會遇到的風險：AI胡說八道。Lucius這家公司做的是幫忙寫標案文件的AI，而標案文件裡的每一句「我方持有五百萬英鎊的專業責任險」都是要被查核的正式承諾，寫錯不是扣分而已，是直接被取消投標資格。作者花了一年抓出的最痛案例，是AI自己憑空生出一個根本不存在的「合作夥伴」，把42項本來答不出來的資格要求都掛在這個虛構夥伴名下，寫得煞有其事，連自家的查核系統都被唬過去——因為查核系統只比對關鍵字，而虛構段落裡剛好塞滿了正確的關鍵字。團隊後來的修法不是調整提示詞去「勸」AI不要騙人，而是在系統裡加上一道結構性關卡，逐項核對業主要求的資格跟投標方實際擁有的證明文件，沒有證據就直接擋下、禁止寫進草稿。

三個案例乍看領域天差地遠，做的卻是同一件事：先找出模型「原廠設定」沒覆蓋到的落差，再用紮實的系統結構把那個落差補起來，而不是寄望模型自己學乖。這就是「拼工程」真正的日常樣貌——不是寫出更聰明的提示詞，而是蓋出更嚴謹的系統。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元你看到AI工程師到底在忙什麼——不是在讓模型變聰明，而是在跟資源、中斷、時間賽跑：把模型壓小、幫代理裝上記錄本、把語音系統整套重寫。這些辛苦看起來都是工程師自己的事，但其實它們才是決定一個AI產品到你手上時「能不能用」的真正關鍵。這一單元，你要學的是怎麼把這套眼光借過來，變成你自己判斷任何AI工具的方法。

先看第一個問題：這東西撐不撐得住你的硬體？Liquid AI的代理模型能自己規劃、呼叫工具、完成多步驟任務的AI，不只是被動回答問題LFM2.5-2.6B只有26億參數，卻拿去跟大到9.7B、幾乎4倍大的模型比賽工具使用和多步驟任務，還打得有來有回。它做到的辦法不是用更貴的硬體硬撐，而是四階段訓練：先用工具使用、網頁搜尋這類實戰資料做兩輪監督式微調，再讓每個領域各自訓練一個專家老師，用蒸餾讓大模型當老師，把它的能力壓縮教給一個小模型，讓小模型也學會類似的判斷力把好幾個專家老師的能力教給同一個學生模型，最後放進真實的agent環境裡跑強化學習練習跟工具、系統提示互動。結果是在Apple M5 Max上跑到每秒220個字、AMD Ryzen CPU上113個字，還吃不到2.5GB記憶體——這代表它可以直接塞進你的筆電，不必依賴雲端伺服器才能動。

第二個問題：斷線、當機了會怎樣？Meta的Muse Code是一個終端機編碼代理，遇到複雜的工程任務時，不是自己一個人硬扛，而是協調好幾個常駐的背景子代理一起分工，這些子代理整個工作階段都活著，不用每次任務重新叫醒、重新蒐集資訊，還能自己判斷什麼時候該回報主代理。但真正撐住長時間任務的關鍵，是它的事件日誌把系統每一個動作都寫進一份記錄檔，這樣當機或斷線後可以從記錄檔接續，不用從頭來過設計——每一次模型呼叫、每一次工具執行、每一次核准、每一次編輯，都被寫進一份本地記錄。這讓整套系統重播即準確、重啟不怕死：就算當機，也能從上次停下的地方精確接回去，不用整個專案打掉重練。

第三個問題：跟不跟得上真實世界的節奏？OpenAI的GPT-Live在這件事上花了六個月。過去的語音AI靠一個小小的轉折偵測器判斷現在輪到誰講話，猜太早就打斷使用者，猜太晚就顯得遲鈍，而且只有偵測器點頭之後，更大的語言模型才能開始工作——這一整套等待，就是延遲的來源。GPT-Live直接把轉折偵測器從語音路徑裡拿掉，改用一個全雙工可以同時邊聽邊講，不必等對方講完才能開口，就像真人對話一樣的語音模型，能一邊聽一邊講，需要深度推理或呼叫工具時再去問GPT-5.5，卻不打斷對話的流暢度。為了做到這件事，OpenAI重寫了模型推理、上下文管理、語音傳輸整套架構，把語音路徑和應用邏輯切開，讓客製化功能不會拖慢反應速度。

把這三個故事放在一起看，你會發現它們拚的從來不是誰的AI比較會聊天，而是誰扛得住真實世界的重量：扛得住你的破筆電和有限記憶體、扛得住斷線和當機、扛得住即時對話的節奏。下次你遇到任何打著AI旗號的工具或服務，與其被「很聰明」「很流暢」這類形容詞說服，不如換一個問法——它敢不敢公開資源用量的具體數字？斷線或出錯時它有沒有辦法接得回來？它是真的即時反應，還是靠等待和猜測硬撐出來的流暢感？能答得出這三題，才算是真正撐得住的AI產品。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

✅ 離開前自測（全勾＝這課真的學會了）