2025年9月29日 星期一

Gemini 最新生圖模型「Nano Banana」強勢登場!一次學會 10 種不同應用,商品設計、人像合成、裝潢布置、甚至是照片秒變真實模型都能做到!效果堪稱當今最強!|泛科學院

Gemini 最新生圖模型「Nano Banana」強勢登場!一次學會 10 種不同應用,商品設計、人像合成、裝潢布置、甚至是照片秒變真實模型都能做到!效果堪稱當今最強!|泛科學院

https://www.youtube.com/watch?v=93fYXstDrjc

https://www.youtube.com/watch?v=93fYXstDrjc值得閱讀的理由 深入了解Google Gemini最新生圖模型Nano Banana的強大功能與免費使用方法。 掌握Nano Banana在角色調整、背景更換、風格轉換、圖片修復等多達十種實用應用,激發無限創意。 學習使用AI圖像生成工具的實用技巧,包括指令撰寫、保持圖像一致性以及數據保存的重要性,避免常見錯誤。 摘要 前言:Google Gemini Nano Banana 強勢登場 Google最新推出的Gemini 2.5 Flash Image Preview模型,又稱Nano Banana,被作者形容為前所未有的強大生圖工具。儘管ChatGPT曾推出圖像生成模型吸引目光,Google的Nano Banana憑藉其免費且功能「離譜」的特點,再次贏得關注。用戶現在可以透過免費版的Gemini或Google AI Studio平台,體驗其卓越的圖像生成能力。作者AJ將帶領觀眾深入探索Nano Banana的十大有趣應用。 在開始實測前,作者也提及了泛科學院的訂閱服務,提供獨家影片內容與AI線上課程折扣,邀請觀眾一同探索更狂野的AI功能。 應用一:角色與肖像編輯 作者首先演示了Nano Banana在角色調整上的能力。透過上傳一張照片,模型能夠迅速將角色頭部擺正、看向鏡頭,甚至調整為大笑表情,同時精準保留眼鏡等細節與浮水印。它還能將短髮改成長粉紅色挑染,且鬍子顏色不變,展現對面部特徵的精細控制。此外,Nano Banana更令人驚訝的是,能夠將角色姿勢調整為雙手叉腰,甚至生成不同角度的肖像,如側面照、俯視照和最令人驚嘆的背面照,這些細節在原始圖片中並未呈現,展現了模型對未知內容的強大預測能力。 應用二:圖像內容與風格轉換 Nano Banana在圖片修正方面也表現出色,能將「大特賣」圖片中的中文改為英文字「store closing 80% off」,雖然中文字處理仍不如ChatGPT,但已有所進步。它也能有效地移除圖片中的文字。作者提到,移除浮水印功能曾成功,但在影片錄製後不久即被加上保護機制,暗示了AI工具的快速演進與限制。 在背景更換方面,Nano Banana表現得非常厲害,能將室外自拍照的背景替換成精緻的室內教堂,或是在台北象山拍攝台北101,且手部動作和邊緣合成都非常自然,展現其對複雜背景的幻化能力。 風格轉換方面,模型能將人物照片(如工頭堅)修改成花襯衫、平頭、金絲眼鏡的風格。更令人印象深刻的是,它能將新垣結衣夫婦的照片轉換為中式婚紗,並將捧花改為向日葵,同時保持其他細節和輪廓不變。作者建議,為確保修改精準,最好一次只要求模型修改一項內容。 在修復照片方面,Nano Banana能將有折痕、過曝的老照片成功修復,不僅上色,還能將照片風格調整為近代拍攝的冷色調,讓老照片煥然一新。 應用三:場景與商品應用 Nano Banana的多圖合成功能允許用戶將兩張獨立的圖片(例如OpenAI的CEO和作者自己)中的人物,合成到一張圖片中,讓他們勾肩搭背微笑,且手指、臉部、頭髮和衣服褶皺等細節都維持得很好,令人難辨真偽。 在商品Mock-up方面,用戶可以輕鬆地將圖片中的服飾設計(如品牌Logo)套用在人物身上,實現商品展示。此功能也適用於各種配件、髮型和手錶。 對於裝潢布置,模型可以將提供的家具添加到房間空景中。作者提醒,如果沒有明確要求保留房間格局或輪廓,模型可能會在添加家具時改變原有的房間配置。透過明確的指令,模型能夠精準地將家具擺放到位,展現多張圖片合成的理解能力。 商品設計方面,Nano Banana能將浮世繪風格應用到球鞋上,創造出獨特的設計。設計完成的球鞋還可以被放置到不同的展示環境中,例如高櫃展示台、雜亂的美術工作台,甚至法拉利車頂,並更改拍攝角度。模型的一致性表現出色,即使修改過顏色的球鞋也能在不同場景中保持原貌。 應用四:創意與概念生成 最後,作者展示了角色轉換的創意應用。他將自己的Q版AI生成圖片,轉換成桌面公仔模型,並搭配電腦螢幕顯示其設計圖,呈現像素風到照片風的轉變,同時保留拍照的散景效果。此外,還能將角色變成毛茸茸的玩具公仔放在床邊,背景牆上則貼滿該角色不同風格姿勢的海報,展現了模型在細節處理和指令依循上的高水準表現,甚至能從Q版角色生成逼真的公仔細節與影子。 心得與建議 在實測之後,作者歸納出三點心得:首先,在混搭多張圖片時,務必在指令中額外要求模型維持圖片一致性,避免背景等元素被改變。其次,建議每次開始新的圖像生成任務時,開啟一個新的對話串,以避免之前的對話上下文參數影響新圖片的穩定性與一致性。最後,由於Google AI Studio是一個實驗室環境,其對話紀錄不會永久保留,因此作者強調,看到喜歡的圖片務必立即存檔。 ================================================# Gemini Nano Banana 震撼登場! 這根本不是更新,這是 AI 生圖的革命現場!來了Gemini又出大招了。這一次他推出了一個前所未有的強大生圖模型Nano Banana。今天呢 我們就來帶大家看看這個模型的強大之處。以及跟各位分享十個有趣的應用。讓你們用好又滿 嗨各位 又是我AJ。Google在年初推出了Gemini2.5的模型之後呢。原本大家已經被他的圖片修改功能嚇到 但好巧不巧的是呢。ChatGPT冷不防接著推出了GPT的圖像生成模型。當大家開心的玩吉卜力的時候呢。Google生圖直接被大家忘光 但最近Google終於又扳回一城。Google推出這個Gemini 2.5 flash image Preview aka Nano Banana 模型。只能用離譜來說 一句話來形容的話是。你想得到的他都辦得到。重點來了。他免費啊各位。你現在用免費版的Gemini。或者是去Google AI studio這個網站就可以免費玩到這個最新的圖像生成模型。那今天呢我們會主要使用Google AI studio這個平台來做測試跟操作。畢竟免費的最香。話不多說讓我們就直接開始吧。等等 是不是泛科學院每週一次的更新看的不過癮啊。沒事的 一個月只要三張100塊 你就可以擁有跟其他人沒有的專屬影片。我們會將頻道里面不曾出現的東西展現給各位看 讓大家知道更狂野的AI功能。順帶一提 你還能獲得泛科學院AI線上課程的折扣碼990 還在等什麽呢。趕快加入跟我們一起玩爆AI吧。好 那我們就來開始測試吧。# 免費爽用的方法曝光! 手把手教你在 Google AI Studio 馬上玩到最強生圖功能首先呢你要幫我搜尋Google的AI studio。進來之後 點選這個Google的AI studio。那各位可以看到右邊已經出現了這個Gemini 2.5 flash image preview的這個模型。那你這邊中間就會看到這個Try Nano Banana這個模型。你就點它一下。他這邊會預設給你一些這個生成的提示詞 那這個我們不用管他。我們第一個應用是角色的調整 那你可以做什麽事。# 【應用一:角色調整】臉部一致性爆炸高!表情超自然,換人種都能毫無違和比如說我們可以上傳一張圖片上去。好 上傳圖片 比如說我們想要請把這個角色的頭擺正。看向我。所以可以看到 首先速度非常的快好。那再來他的原本的這個眼鏡跟轉過來這個眼鏡。細節看起來都有保留。然後因為我們這個是這個線上的免費的圖庫。所以他這個圖庫的浮水也保留了。所以你可以簡單的傳一張照片上去。然後要求他去調整角色里面的這些姿勢 這是非常簡單的一個用法。當然你也可以跟他說改成大笑。這邊大笑了 好。所以你看眼鏡的一致性都還維持得不錯 然後該有的浮水印也都還有。那你也可以跟他說。比如說。我覺得短髮可能不太好看 我想要幫我把頭髮改成短長髮。並且改成粉紅色。所以他就有了粉紅色挑染了。而且胡子的顏色沒有變 我覺得做的非常好 那角色的這個面部表情。五官 頭髮 什麽的這都調了差不多了。# 【應用一延伸:姿勢轉換】 一張照就能衍生上百種視角、動作,根本照片製造機!另外一張照片。然後請讓角色的姿勢。改成雙手叉腰。成功改了姿勢。這臉看起來沒有沒有變得太離譜。一致性做的很好。衣服也沒有問題。那除了改姿勢之外。其實這個Gemini的這個AI的Banana模型還可以做到一些有趣的事情。比如說我們把它改成生成側面照。他就完美的進行了90度的旋轉。姿勢都維持的還不錯。深層俯視照。類似的鏡位就改了從上面往下拍。那甚至呢。你也可以生成背面照 背面這就厲害了吧。這個他背面一開始的照片是完全沒有沒有帶到的。但是這個Banana的模型呢可以去生成。背面的這個照片你看鞋子還是對的。衣服也沒有問題。然後換成背面的這個頭髮 這都是前面的這張照片里面沒有呈現這些細節。你應該就可以感受到這個模型他對於未知內容的預測能力。他真的是做的非常非常非常的強。# 【應用二:圖片修正】所有文字想改就改,浮水印也能挑戰?看結果就知道!第二個 圖片修正 比如說我們有傳的一張這樣子的一個大特賣的照片。然後想把里面的字改掉。比如說將圖片中的文字改成store closing 80% off。所以可以看到呢。英文字的顯示基本上看起來沒有什麽太多的問題。好那中文字 當然就。當然就還是不如chatGPT。但我覺得這模型還會在進步當中。之前是完全不行了。現在還勉強可以 去除圖片里面的文字。模型的理解能力我覺得還是不錯的。那你就自己把該打的字 用這個PPT之類的軟體把它P上去哦。這都是很簡單。可以做到的事情。那其實我們在測試的時候我們要求他移除浮水印是可以成功的。但是就當我們錄製的時候。也就過不到24小時。如果已經加上了浮水印移除的保護機制。那如果你有成功的玩出一些有趣的圖像修正的應用的話得一些提示語的話。歡迎你在里面下面留言跟大家做一些分享跟討論。# 【應用三:背景更換】一鍵秒換,景深、光影全都完美契合,P 圖仔直接失業接下來是背景更換我們剛剛在改的是他前景這些內容。那其實Nano Banana 還有一個非常厲害的功能就是背景更換。比如說這個背景看起來就是一個室外。請把背景改成室內教堂。所以你可以看到出來的結果非常的厲害。他的手在做自拍這件事情還是對的。然後那手機里面糊掉的背景這個就沒辦法真是太細節。然後可是 他的這個散景的教堂。而且他的這個邊緣的合成都做的非常非常的厲害。改成在台北象山拍台北101。所以你就可以看到這個女生就馬上變成了在象山的觀景台。看起來這個細節維持都還做的還不錯。就我自己的測試 他的背景真的是可以幻化千奇百怪的背景。# 【應用四:人像風格轉換】衣服、眼鏡、髮型,全部一鍵替換,真假難分!那我們第四個是風格轉換。比如說我們放上了旅行長工頭堅的照片。然後請幫我改成花襯衫平頭金絲眼鏡。攝影棚還在。眼鏡也換了。平頭很厲害。工頭堅應該不會來殺我吧。# 【應用四延伸:服裝大改造】只用一句話,整個造型立刻大變身!好接下來 這張各位應該也蠻熟悉的 是那個新垣結衣和他老公。那我就可以跟他說請將角色內的新人改成中式婚紗。捧花改成向日葵。其他細節跟輪廓不要更動 送出。其實我們在測試的時候其實有發現說當這些圖像裡面的這些細節。有時候他還是會改的不太好。原則就是 你不要一次叫他改太多東西。一次叫他改一個里面的東西。這樣就可以比較好的去抑制 確認他改的地方只會改到對的地方。不會改到錯的地方。所以我們就成功的新垣結衣跟星野原穿上了這個中式的這個婚紗。然後捧花改成向日葵。上面還帶了這個中式的皇冠。第五個 修復照片 那老照片里面其實就會很多一些折痕。# 【應用五:老照片修復】模糊、曝曬、破損一鍵還原,連上色都美到不像話或者是他當初拍的時候就有點過曝。好所以呢 就直接跟AI說請修復這張照片。你看照片就成功的幫你修復了而且還連上色都幫你做了一下。然後旁邊這折痕又做了一些保留。把照片的風格修復 調整 成近代拍攝的冷色調風格。這樣就看起來越來越接近這個從60年前的照片然後變成了30年前的照片。第六個 多圖合成 比如說呢。# 【應用六:多圖合成】把不同照片的人放一起合照,連跟明星合影都無破綻!我這邊是簡單的上傳一張這個這個Open AI的CEO的照片。然後我還可以傳一張我的照片。請讓第一張圖人站在第二張圖的人旁邊兩個人勾肩搭背微笑。還不錯吧。還不錯吧。手指的細節。臉部的表情的細節 頭髮的細節都維持的還不錯。衣服的褶皺 還不錯。以後你的好朋友說他跟某某名人合照你可能要懷疑一下他是不是用AI。做成照片。第七個商品mock up 比如說呢。# 【應用七:商品取樣】LOGO、圖案隨便套,商品展示照真實度100分!你可能常看到這種 就是為了商品啊拍攝的一些公關照片。那你現在就可以很簡單的請讓人物換上圖片中的衣服。所以你就成功的把logo換到了這個角色的上面。那衣服只是其中一個很簡單的案例。那各位可以自己去試試看去把人物身上這些配件。衣服 髮型 手錶 來去做這樣的一個合成。我相信一定成功的幾率都還蠻高的 第八個裝潢布置 比如說呢。# 【應用八:裝潢布置】空房秒變夢幻居家,連家具擺設 AI 都幫你想好我們就直接傳一個房間的空景上去。有了房間空景之後。我還要再加上一些家具。請把桌子放到房間當中 靠墻。好 做的還不錯。一張不夠。只有桌子怎麽可以。請把我提供的家具通通放到房間照片當中。好 這邊可以看到房間突然間變了 對不對。這個是還蠻常見的一個AI幻覺的現象。提示語只要你沒有要求他維持原有的房間的格局或是配置之類的要求。那他就有可能會塞東西進去的時候。就不小心把你原本的房間的圖片改掉了。那如果你覺得剛剛那個圖片有點跑掉的話。沒有關係。我們還可以重新來試一次。這個房間格局。請把我提供給你的家具放到房間當中。要保留房間格局輪廓不變。那我們再給他個家具。好 送出。這里可以看到房間的格局輪廓還是在這樣那個90度的這個角落。然後幫你把剛剛的這幾個家具通通都把它擺到。該擺的位置上面去了。所以這就是他的這個圖像。他不是只有一張一張合成。你也可以多張一次丟去給他做合成。然後他會根據他的理解 去幫你把該放的東西放進去里面。第九個是商品的設計 比如說我們這邊有準備一些有趣的東西一雙球鞋。# 【應用九:商品設計】風格 + 樣品圖,直接生成可賣的產品,還附形象照!然後我們可以去把浮世繪的風格放進來。請把第二張圖片的設計風格轉換到球鞋上。浮世繪風格球鞋就做好了。商品設計師是不是快要失業。到這邊其實還沒完 這雙球鞋放在這邊覺得有點無聊對吧。我們可以把它換個換地點。比如說把這雙球鞋放在高櫃展示台上。高櫃展示台上 做好了 還有玻璃還有倒影。把球鞋放在雜亂的美術工作台上。所以我們可以發現他的一致性 球鞋還是那雙球鞋。而且是被我改過顏色的球鞋 然後我不需要重新上傳那張圖片。我就可以原本從一個鞋子加上圖。然後有圖的鞋子放到這個地方。又直接幫我拿到那個地方去。那當然我還可以把它散落在比如說法拉利的車頂上。然後更改拍攝角度從上往下拍。所以 他又把剛剛的那個畫室里面的一些元素拉出來。除了球鞋之外。包括這些畫板。還有這些插圖。搭配這雙球鞋放在這個車子上。不過這車子顯然就是有點小小的問問題。這個車子跟鞋子的比例好像有點不太搭嘎。你看這鞋子這肯定要LBJ來穿吧。# 【應用十:超好玩玩法】照片秒變模型、Q 版公仔、毛絨玩偶,還能把電影角色玩出新花樣!最後一個我們來分享一個好玩的東西 比如說這是我的Q版的AI生成的圖片。把這個角色變成了公仔模型放在桌面。然後右邊有角色包裝和Q版手辦。左邊有電腦螢幕。然後里面有角色正在做Photoshop的設計圖。所以你可以看到。從像素風又改成了相片風 在電腦的螢幕里面有一點點的模糊。這個是拍照的散景的現象。可是前面的這個公仔 是一個非常漂亮乾凈的這個就像真的公仔一樣。然後左邊還有一個。這個就有點小小變形了。因為它是Q版的。所以要變得更加的可愛一點。這樣子將照片里的角色變成毛茸茸的玩具公仔放在床邊。同時背景墻上有各種角色不同風格姿勢的海報。這出處各位應該也都認得出來。所以他把貼滿了車力巨人的海報。然後有車力巨人的這個像是Labubu的公仔 好哦。但是床上的這些細節沒有變化。他的指令依循性真的是做的非常非常的好。我們在測試的時候 還有生成過這一張。你可以看到他的這些毛茸茸的感覺 還有他的那個影子。還有里面的這些公仔的細節我覺得都處理的還不錯。雖然說里面疑似混進了一個獵人的角色 不過這應該是阿爾敏。那以上就是我們的測試。其實我們在測試之後 我們歸納出3個心得。第一個你今天在上傳圖片給他的時候。在很多圖片在混搭的時候。如果你需要去維持圖片的一致性的話。你就必須要在指令里面去額外的要求他。比如說要保持背景的一致性。不要有改變背景的行為。但是你如果 這一批圖片做完之後那你要做下一個工作的話。建議你直接開一個新的對話串。你在這個對話串里面有可能他會把之前的圖片的一些參數變成上下文。塞到你的圖片里面去。可能會讓你的圖片的穩定性跟一致性沒有辦法很好的去做控制。第三個也是最重要的一件事情。AI studio 畢竟是一個測試的實驗室的環境。你跟他在做對話的時候如果看到這張圖片喜歡記得馬上要把它存下來。你的圖片重新整理之後或者是你今天電腦關掉之後再重開。那個對話記錄就不會留。好 以上就是我們這一集的影片。我希望你有學到一些東西。希望你可以把你的創意在影片下面跟網友做一些分享。那我們下次影片再見嘍拜拜。  ============= https://www.youtube.com/watch?v=93fYXstDrjc這次的 Nano Banana 真的毫無懸念榮登今年最強的生圖模型,無論是品質、速度或者是理解文字的程度都已經來到一個新高度,ChatGPT 的生圖功能相比之下真的就遜色了一些。特別要提一下人像合成的部分,真的是 超! 扯! 這個功能幾乎已經到了以假亂真的程度了,之前ChatGPT 的人像合成生圖雖然說已經很接近現實的程度了,但難免還是有一些可以被偵測出來的地方,好比說那個永遠都看起來黃黃的色調,但是這次 Gemini 的 Nano Banana 幾乎把這些 ChatGPT有的問題全部修正,只能說 AI 市場的競爭激烈遠超我們想像而且,這次只是 Nano (奈米)而已,後面再更新的 Mini 、Small 甚至到 Large,究竟會離譜到什麼程度呢? 讓我們繼續看下去...00:00 Gemini Nano Banana 震撼登場! 這根本不是更新,這是 AI 生圖的革命現場!01:25 免費爽用的方法曝光! 手把手教你在 Google AI Studio 馬上玩到最強生圖功能01:51 【應用一:角色調整】臉部一致性爆炸高!表情超自然,換人種都能毫無違和03:23 【應用一延伸:姿勢轉換】 一張照就能衍生上百種視角、動作,根本照片製造機!04:47 【應用二:圖片修正】所有文字想改就改,浮水印也能挑戰?看結果就知道!05:55 【應用三:背景更換】一鍵秒換,景深、光影全都完美契合,P 圖仔直接失業06:52 【應用四:人像風格轉換】衣服、眼鏡、髮型,全部一鍵替換,真假難分!07:16 【應用四延伸:服裝大改造】只用一句話,整個造型立刻大變身!07:58 【應用五:老照片修復】模糊、曝曬、破損一鍵還原,連上色都美到不像話08:40 【應用六:多圖合成】把不同照片的人放一起合照,連跟明星合影都無破綻!09:20 【應用七:商品取樣】LOGO、圖案隨便套,商品展示照真實度100分!09:53 【應用八:裝潢布置】空房秒變夢幻居家,連家具擺設 AI 都幫你想好11:38 【應用九:商品設計】風格 + 樣品圖,直接生成可賣的產品,還附形象照!13:21 【應用十:超好玩玩法】照片秒變模型、Q 版公仔、毛絨玩偶,還能把電影角色玩出新花樣!#ai #aitools #gemini #google #nanobanana

-- gReader Pro 

【免費AI證書】Google Gemini 教師認證開放!不只老師能考,20分鐘為你的履歷加分!

【免費AI證書】Google Gemini 教師認證開放!不只老師能考,20分鐘為你的履歷加分!

https://www.youtube.com/watch?v=aVVMcliYJIw

https://www.youtube.com/watch?v=aVVMcliYJIw值得閱讀的理由了解如何免費獲得 Google Gemini 認證教師證書,提升個人專業技能。深入理解 Google 在推廣 AI 負責任使用及AI 應用於教育領域的重點。快速掌握考試內容與常見題型,為有意報考者提供實用準備方向。摘要引言與認證簡介作者分享了 Google 最近推出的「Gemini 認證教師證書」,旨在推廣 AI 的負責任使用及將 AI 應用於教育。這張證書雖然名為「教師認證」,但並未限制報考者身份,所有人皆可參與,藉此驗證對 Google Gemini 及 NotebookLM 等工具的理解程度。這項考試僅有 37 題,作者約花 20 分鐘完成,建議有興趣的觀眾不妨一試,多一份免費證書。認證目標與能力面向該證書的目標受眾為 K12 教師(幼稚園、小學、國高中),但 Google 未來也規劃為大學生及高中以下學生推出相關認證。本次教師認證主要驗證四個面向的能力:如何有效應用 Gemini 與 NotebookLM 提升工作效率;如何下 Prompt 使 AI 生成內容符合需求;對 Google Gemini 及 NotebookLM 功能的了解程度;以及如何將 AI 融入教學,並引導學生負責任地使用 AI。證書獲取流程要獲取這張證書,需先造訪 educertifications.google 網站並登入 Google 帳號。接著點擊「Gemini Educator」考試註冊,填寫基本資料並勾選底部兩項同意聲明後即可進入考試。作者指出,目前考試語言僅提供英文,建議可搭配翻譯工具輔助閱讀,如「沉浸式翻譯」。考試內容與實例解析影片中,作者舉例說明了幾道考題。例如,當 AI 總結歷史事件並給出可疑日期時,最佳解決方案是驗證資訊的真實性,因為 AI 存在「幻覺」問題。其他題目包括教師如何幫助學生理解 AI 輸出可能含有錯誤訊息或偏見,以及 NotebookLM 的語音摘要功能是否可調整音訊長度(答案為「是」)。此外,考題也涵蓋了 NotebookLM 的「學習指南」等基本功能操作。進階考題與道德議題更深入的考題探討了如何利用 Gemini 減少行政文書工作,以及學生使用 AI 輔助或生成功課報告的道德問題。對於後者,教師能做的就是要求學生若有使用 AI 進行腦力激盪或起草,需註明引用。還有題目是關於新教練如何利用 NotebookLM 結合戰術手冊與比賽摘要,分析出最成功的戰術。作者表示,熟悉 Google AI 工具的觀眾應能輕鬆作答。考試結果與證書取得作者在考試中僅答錯一題,原因為看錯題目中的「不適合」。考完後,Google 會將證書連結寄送到註冊的 Email 中。這張證書效期為三年,可下載為 PDF 或公開分享。================================================# Gemini 教師認證是什麼?Hello 大家好 這裡是步行魚的頻道。今天來跟大家分享一個消息。Google 最近推出了 Gemini 認證教師的證書。主要算是在推廣如何負責任的使用AI。以及應當使用什麼方式。將AI應用在教育方面。今天我們就來帶大家簡單看一下。如何獲得這張免費的證書。以及大約看一下。它考試裡面的內容是在問些什麼。當然 雖然今天這個證書叫做。# 誰適合考?考試內容與難度Gemini 認證教師證書。但它並沒有限制只有教師才能夠獲得。它的考試內容也能夠稍微驗證一下。我們對AI的理解。主要是對Google的 Gemini 以及 NotebookLM。這兩個方便的工具它的熟悉程度。所以有興趣的觀眾。建議大家都可以稍微考一下。它考起來並不難。總共只有37題。我大概花20分鐘左右的時間就考完了。就當作多拿一份免費的證書。# 證照目標對象與四大驗證能力這次的證照(證書)它的目標對象。是提供給K12的教師。也就是幼稚園 小學 國高中的教師。但Google並沒有限制只有教師才能夠報考。未來也有規劃要推出大學生與高中以下學生的 Gemini 認證。而本次的教師認證。它主要要驗證的能力分為四個面向。分別為如何有效的應用 Gemini 與 NotebookLM 提升工作效率。如何下Prompt讓AI的生成符合需求。對Google Gemini 以及 NotebookLM的功能了解程度。以及如何將AI融入教學。並引導學生負責任的使用AI。# 手把手教學:如何註冊考試?接下來我們就來看看如何獲得這張證書。首先我們需要先進到這個網頁。educertifications.google. 這個網頁最開始會叫我們要先登入Google帳號。登入後我們就可以看到目前下方。有一個 Gemini Educator 的考試可以註冊。點下去後。它會先要求我們要填入一些基本資訊。這些大致填一下就好了。不影響後續的考試。填完後滾到底部。在送出前我們要勾選底部兩個Checkbox。只需要勾選底部兩個就好了。上面兩個是問你願不願意收到新聞以及被聯絡。進到下一步。這邊我們就可以按 Take Exam。然後它的語言目前就只有英文。這邊有一個比較麻煩的事情。不知道未來Google會不會把它整合好。但我們按下 Take Exam。進到下一個頁面後。我們還需要再重新填一次。我們剛剛填過的基本資料。就有點不知道到底在幹嘛。總之這些資料都填完之後。我們終於可以點進 Gemini Certification for Educators 的測驗。開始考取這張證書了。# 正式測驗開始!考試介面與翻譯技巧點進來之後可以看到。因為它目前只有英文這個語言選項。大家可以當作練練英文。或者是如果真的不想讀英文的話。就直接開翻譯吧。推薦大家可以用我之前介紹過的沉浸式翻譯。讓我們在它翻譯出來的東西有點怪怪的。看不太懂時。還可以比對一下原文。# 考試題目解析 (1):AI 幻覺與事實查核那接下來我們來看一下它的問題。這邊它的問題是。一位老師要求生成式AI。總結一個歷史事件。但裡面提到了一場戰役的具體日期。但老師覺得這個日期怪怪的。應該怎麼解決比較好。這邊最好的解決方式當然就是。要再去驗證這些資訊的真實性。由於AI多少會有一些幻覺的問題。它所提供的具體數字、具體日期。有時候會出一些差錯。那我們就需要再去驗證一下。這些日期是否是正確的。甚至有一些模型幻覺比較嚴重的話。還會自己瞎掰一些歷史事件。# 考試題目解析 (2):教育應用與 NotebookLM 功能接下來我們看到下一題。這邊它的內容就比較偏向教育方面了。問教師要如何幫助學生了解。AI的輸出可能包含錯誤的訊息或是偏見。接下來下一題。它要問的是 NotebookLM 的語音摘要。是否可以調整它生成的音訊長短。答案是「是」。它沒有什麼好疑問的。最開始版本的語音摘要。我們可能還要用自訂的Prompt。讓它嘗試能不能縮短一點或變長一點。但現在它已經有按鈕可以讓我們直接按了。再來接下來就是考 NotebookLM 的基本功能。叫做學習指南。我們只需要將檔案全部都傳上去之後。在右側的報告裡點擊學習指南。讓它建立就可以了。後續的問題大約也都是這樣的類型。考使用者對Google家AI工具的了解程度。以及AI在教育領域需要解決的一些問題。# 考試題目解析 (3):AI 道德與行政應用我再來挑幾題我覺得比較有趣的給大家看一下。首先就是這邊這一題。要如何使用 Gemini 來減少一些行政文書的工作。再來就是一個難以避免的道德問題。學生使用AI輔助。或者是直接使用AI生成功課與報告。那該怎麼辦。那教師能做的也就只有要求學生。有使用到AI進行腦力激盪或起草的話。需要註明引用。再來是新來的教練該如何使用 NotebookLM。結合戰術手冊與上季的比賽摘要。整理出哪些戰術在比賽中最為成功。對於AI議題。Google的 Gemini 與 NotebookLM 比較熟悉的觀眾。應該都可以蠻輕鬆答出來的。# 測驗結果出爐!我的分數與答錯的題目最終答完後提交我的總得分是錯一題。稍微有點可惜。回去看一下錄影發現是有一題我看錯了。他是問哪一項不適合。用來為學生生成單字表。但我以為是適合就直接選錯了。# 考完後呢?如何領取與分享證書在考完之後他會將證書的連結寄送到我們的Email中。至此我們就得到這張證書了。證書的效期是三年。我們可以將它以PDF下載下來。或者是將證書公開。然後分享出去。# 影片總結OK 以上就是今天影片全部的內容。基本上就是簡單跟大家分享一下。有這個證書可以考。那麼各位觀眾。我們就下隻影片見w。  ============= https://www.youtube.com/watch?v=aVVMcliYJIw最近 Google 推出了一個免費證書 ── Gemini AI 教師認證證書,主要是考驗教師在教學領域應用AI,與引導學生正確使用AI的相關能力,也考驗對於 Gemini、NoteBookLM這些AI工具的熟悉程度。因為算是蠻有趣的,所以今天來跟大家分享一下。(P.S. 官方說明測驗主要有3大核心領域,但因為它實際測驗的內容有稍微超出他的描述,所以影片中我才會說是4個)==================【The Walking Fish的程式小站】https://the-walking-fish.com/【在LBRY上訂閱步行魚的頻道】https://odysee.com/@The-Walking-Fish【也可以點此接受我的LBRY邀請】https://odysee.com/$/invite/@The-Walking-Fish:2==================證書報名網址:https://educertifications.google/本集的文章版:https://the-walking-fish.com/p/gemini-certification-for-educators/【推★薦★影★片】我開發的 LLM 分佈式推理專案https://www.youtube.com/watch?v=UtaDMH_EZuw什麼是開源?GPL 如何「感染」你的專案?【開源簡史與授權詳解】https://www.youtube.com/watch?v=ZVKZ9DIFQakFLUX.1 介紹影片https://www.youtube.com/watch?v=eyM_GTytfXg==================也可以使用BTC或使用我的Pionex、FreeBitcoin推薦連結來贊助我的頻道【Donate Me With Bitcoin】16PTGbq3JxupPA89YPb2kWi6Yv9z7fSHqw【Pionex推薦連結】 https://www.pionex.com/zh-TW/signUp?r=0nWTXbvRL5V【FreeBitcoin推薦連結(我有設定將推薦收入50%給使用我推薦連結的人)】https://freebitco.in/?r=4393852==================00:00 Gemini 教師認證是什麼?00:23 誰適合考?考試內容與難度00:50 證照目標對象與四大驗證能力01:25 手把手教學:如何註冊考試?02:25 正式測驗開始!考試介面與翻譯技巧02:43 考試題目解析 (1):AI 幻覺與事實查核03:15 考試題目解析 (2):教育應用與 NotebookLM 功能04:02 考試題目解析 (3):AI 道德與行政應用04:41 測驗結果出爐!我的分數與答錯的題目04:54 考完後呢?如何領取與分享證書05:07 影片總結

-- gReader Pro 

Dify 2.0 Beta發布:知識管線與佇列圖引擎,編排知識、驅動工作流

Dify 2.0 Beta發布:知識管線與佇列圖引擎,編排知識、驅動工作流

https://github.com/langgenius/dify/releases/tag/2.0.0-beta.1

🚀 Introduction In Dify 2.0, we are introducing two major new capabilities: the Knowledge Pipeline and the Queue-based Graph Engine. This is a beta release, and we hope to explore these improvements together with you and gather your feedback. The Knowledge Pipeline provides a modularized and extensible workflow for knowledge ingestion and processing, while the Queue-based Graph Engine makes workflow execution more robust and controllable. We believe these will help you build and debug AI applications more smoothly, and we look forward to your experiences to help us continuously improve.  📚 Knowledge Pipeline ✨ Introduction With the brand-new orchestration interface for knowledge pipelines, we introduce a fundamental architectural upgrade that reshapes how document processing are designed and executed, providing a more modular and flexible workflow that enables users to orchestrate every stage of the pipeline. Enhanced with a wide range of powerful plugins available in the marketplace, it empowers users to flexibly integrate diverse data sources and processing tools. Ultimately, this architecture enables building highly customized, domain-specific RAG solutions that meet enterprises' growing demands for scalability, adaptability, and precision. ❓ Why Do We Need It? Previously, Dify's RAG users still encounter persistent challenges in real-world adoption — from inaccurate knowledge retrieval and information loss to limited data integration and extensibility. Common pain points include:  🔗 restricted integration of data sources 🖼️ missing critical elements such as tables and images ✂️ suboptimal chunking results  All of them lead to poor answer quality and hinder the model's overall performance. In response, we reimagined RAG in Dify as an open and modular architecture, enabling developers, integrators, and domain experts to build document processing pipelines tailored to their specific requirements—from data ingestion to chunk storage and retrieval. 🛠️ Core Capabilities 🧩 Knowledge Pipeline Architecture The Knowledge Pipeline is a visual, node-based orchestration system dedicated to document ingestion. It provides a customizable way to automate complex document processing, enabling fine-grained transformations and bridging raw content with structured, retrievable knowledge. Developers can build workflows step by step, like assembling puzzle pieces, making document handling easier to observe and adjust. 📑 Templates & Pipeline DSL   ⚡ Start quickly with official templates 🔄 Customize and share pipelines by importing/exporting via DSL for easier reusability and collaboration  🔌 Customizable Data Sources & Tools   Each knowledge base can support multiple data sources. You can seamlessly integrate local files, online documents, cloud drives, and web crawlers through a plugin-based ingestion framework. Developers can extend the ecosystem with new data-source plugins, while marketplace processors handle specialized use cases like formulas, spreadsheets, and image parsing — ensuring accurate ingestion and structured representation. 🧾 New Chunking Strategies In addition to General and Parent-Child modes, the new Q&A Processor plugin supports Q&A structures. This expands coverage for more use cases, balancing retrieval precision with contextual completeness. 🖼️ Image Extraction & Retrieval  Extract images from documents in multiple formats, store them as URLs in the knowledge base, and enable mixed text-image outputs to improve LLM-generated answers. 🧪 Test Run & Debugging Support Before publishing a pipeline, you can:   Execute a single step or node independently 🔍 Inspect intermediate variables in detail 👀 Preview string variables as Markdown in the variable inspector  This provides safe iteration and debugging at every stage. 🔄 One-Click Migration from Legacy Knowledge Bases Seamlessly convert existing knowledge bases into the Knowledge Pipeline architecture with a single action, ensuring smooth transition and backward compatibility. 🌟 Why It Matters The Knowledge Pipeline makes knowledge management more transparent, debuggable, and extensible. It is not the endpoint, but a foundation for future enhancements such as multimodal retrieval, human-in-the-loop collaboration, and enterprise-level data governance. We're excited to see how you apply it and share your feedback.  ⚙️ Queue-based Graph Engine ❓ Why Do We Need It? Previously, designing workflows with parallel branches often led to:  🌀 Difficulty managing branch states and reproducing errors ❌ Insufficient debugging information 🧱 Rigid execution logic lacking flexibility  These issues reduced the usability of complex workflows. To solve this, we redesigned the execution engine around queue scheduling, improving management of parallel tasks. 🛠️ Core Capabilities 📋 Queue Scheduling Model All tasks enter a unified queue, where the scheduler manages dependencies and order. This reduces errors in parallel execution and makes topology more intuitive. 🎯 Flexible Execution Start Points Execution can begin at any node, supporting partial runs, resumptions, and subgraph invocations. 🌊 Stream Processing Component A new ResponseCoordinator handles streaming outputs from multiple nodes, such as token-by-token LLM generation or staged results from long-running tasks. 🕹️ Command Mechanism With the CommandProcessor, workflows can be paused, resumed, or terminated during execution, enabling external control. 🧩 GraphEngineLayer A new plugin layer that allows extending engine functionality without modifying core code. It can monitor states, send commands, and support custom monitoring.  Quickstart  Prerequisites  Dify version: 2.0.0-beta.1 or higher   How to Enable  Enabled by default, no additional configuration required. Debug mode: set DEBUG=true to enable DebugLoggingLayer. Execution limits:  WORKFLOW_MAX_EXECUTION_STEPS=500 WORKFLOW_MAX_EXECUTION_TIME=1200 WORKFLOW_CALL_MAX_DEPTH=10   Worker configuration (optional):  WORKFLOW_MIN_WORKERS=1 WORKFLOW_MAX_WORKERS=10 WORKFLOW_SCALE_UP_THRESHOLD=3 WORKFLOW_SCALE_DOWN_IDLE_TIME=30   Applies to all workflows.     More Controllable Parallel Branches <div data-snippet-clipboard-copy-content="Execution Flow:  Start ─→ Unified Task Queue ─→ WorkerPool Scheduling  ├─→ Branch-1 Execution  └─→ Branch-2 Execution  ↓  Aggregator  ↓  End  Improvements: 1. All tasks enter a single queue, managed by the Dispatcher. 2. WorkerPool auto-scales based on load. 3. ResponseCoordinator manages streaming outputs, ensuring correct order.">Execution Flow:  Start ─→ Unified Task Queue ─→ WorkerPool Scheduling  ├─→ Branch-1 Execution  └─→ Branch-2 Execution  ↓  Aggregator  ↓  End  Improvements: 1. All tasks enter a single queue, managed by the Dispatcher. 2. WorkerPool auto-scales based on load. 3. ResponseCoordinator manages streaming outputs, ensuring correct order.   Example: Command Mechanism <div data-snippet-clipboard-copy-content="from core.workflow.graph_engine.manager import GraphEngineManager  # Send stop command GraphEngineManager.send_stop_command(  task_id="workflow_task_123",  reason="Emergency stop: resource limit exceeded" )">from core.workflow.graph_engine.manager import GraphEngineManager  # Send stop command GraphEngineManager.send_stop_command(  task_id="workflow_task_123",  reason="Emergency stop: resource limit exceeded" ) Note: pause/resume functionality will be supported in future versions.  Example: GraphEngineLayer GraphEngineLayer Example  FAQ   Is this release focused on performance? No. The focus is on stability, clarity, and correctness of parallel branches. Performance improvements are a secondary benefit.   What events can be subscribed to?  Graph-level: GraphRunStartedEvent, GraphRunSucceededEvent, GraphRunFailedEvent, GraphRunAbortedEvent Node-level: NodeRunStartedEvent, NodeRunSucceededEvent, NodeRunFailedEvent, NodeRunRetryEvent Container nodes: IterationRunStartedEvent, IterationRunNextEvent, IterationRunSucceededEvent, LoopRunStartedEvent, LoopRunNextEvent, LoopRunSucceededEvent Streaming output: NodeRunStreamChunkEvent    How can I debug workflow execution?  Enable DEBUG=true to view detailed logs. Use DebugLoggingLayer to record events. Add custom monitoring via GraphEngineLayer.     Future Plans This beta release is just the beginning. Upcoming improvements include:  Debugging Tools: A visual interface to view execution states and variables in real time. Intelligent Scheduling: Optimize scheduling strategies using historical data. More Complete Command Support: Add Pause/Resume, breakpoint debugging. Human in the Loop: Support human intervention during execution. Subgraph Functionality: Enhance modularity and reusability. Multimodal Embedding: Support richer content types beyond text.  We look forward to your feedback and experiences to make the engine more practical.  Upgrade Guide ImportantAfter upgrading, you must run the following migration to transform existing datasource credentials. This step is required to ensure compatibility with the new version: uv run flask transform-datasource-credentials  Docker Compose Deployments  Back up your customized docker-compose YAML file (optional)  <div data-snippet-clipboard-copy-content="cd docker cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak">cd docker cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak  Get the latest code from the main branch  <div data-snippet-clipboard-copy-content="git checkout 2.0.0-beta.1 git pull origin 2.0.0-beta.1">git checkout 2.0.0-beta.1 git pull origin 2.0.0-beta.1  Stop the service. Please execute in the docker directory  docker compose down  Back up data  tar -cvf volumes-$(date +%s).tgz volumes  Upgrade services  docker compose up -d  Migrate data after the container starts  docker exec -it docker-api-1 uv run flask transform-datasource-credentials Source Code Deployments   Stop the API server, Worker, and Web frontend Server.   Get the latest code from the release branch:   git checkout 2.0.0-beta.1  Update Python dependencies:  <div data-snippet-clipboard-copy-content="cd api uv sync">cd api uv sync  Then, let's run the migration script:  <div data-snippet-clipboard-copy-content="uv run flask db upgrade uv run flask transform-datasource-credentials">uv run flask db upgrade uv run flask transform-datasource-credentials  Finally, run the API server, Worker, and Web frontend Server again.

-- gReader Pro 

WinBoat使用教學,在Linux無縫執行Windows程式的工具(Docker KVM + FreeRDP)

WinBoat使用教學,在Linux無縫執行Windows程式的工具(Docker KVM + FreeRDP)

https://ivonblog.com/posts/winboat-windows-apps/

今天要分享的軟體叫做WinBoat,它能讓你在Linux執行Windows程式。要在Linux跑Windows軟體,最穩定的方法便是透過虛擬機,譬如Virt Manager + QEMU/KVM跑Windows虛擬機。但是透過Virt Manager視窗來操作Windows顯得有些不便,所以有許多開發者提出了透過RDP遠端桌面的方式,讓虛擬機內的程式與Linux桌面更好的整合,讓Windows程式的視窗繪製在Linux桌面上。例如在Linux桌面,開啟Microsoft Office視窗。宛如原生應用程式一樣的操作。類似WinBoat的軟體有WinApps和Cassowary。WinBoat跟WinApps的差別在於,它是在Docker裡面跑Windows 11虛擬機,而非直接透過Libvirt(WinApps允許你選取Docker或Libvirt作為後端,彈性較高,能GPU直通),不過它還是有用到KVM。WinBoat界面比較漂亮,設定過程比較直覺,只要裝好Docker與KVM的前置依賴套件,這個圖形程式就會自動幫你建立Windows虛擬機,在虛擬機內部安裝與Linux溝通的伺服器程式winboat_guest_server。並且會自動將Linux家目錄掛載到Windows檔案總管,共享資料夾。不過,WinBoat本質上是跑一個Windows虛擬機,目前無法GPU直通,圖形效能低落,只適合跑文書程式。我覺得比較有趣的是作者使用的發行版。試想:Steam Deck可以不裝Windows系統,也能跑Windows exe程式嗎?比如說Office 365?WinBoat作者是用Bazzite測試的,這個是專為Steam Deck設計的玩遊戲系統。既然這種immutable distro都能裝了,一般Linux發行版更不用說。1. 安裝前置依賴#跑WinBoat建議電腦要有8GB RAM,因為要分配給虛擬機至少4GB RAM。再考慮到Windows 11的吃資源程度,分配8GB RAM最為保險。否則用起來會很卡。以Ubuntu來說,需要安裝:開啟KVM虛擬化,不用安裝Libvirt安裝Docker,並將自身加入docker群組安裝FreeRDPsudo apt install freerdp3-x11 設定開機載入iptables模組echo -e "ip_tables iptable_nat" | sudo tee /etc/modules-load.d/iptables.conf 重開機。2. 安裝WinBoat#到Github下載AppImage,點二下執行。如果不能開啟,嘗試安裝.deb或.rpm版本。初次開啟,確認已經符合前置條件選取安裝Windows 11系統,安裝Windows的時候只有英文和簡體中文,稍後可以到系統設定自行下載語言套件改成繁體中文。設定Windows帳號和密碼,這裡是離線帳號,不用輸入Microsoft帳號建議分配2核心以上CPU與4GB以上RAM等待安裝完成。安裝的時候可以在瀏覽器輸入http://127.0.0.1:8006/檢視Windows畫面。WinBoat安裝後的Windows似乎已經是啟用狀態?不需要授權?WinBoat內部能夠設定Windows的縮放。目前的比例有點太大了,建議維持100%就好。3. 視窗操作邏輯#在Apps列表會看到Windows所有的程式。這個界面也允許你自訂exe啟動捷徑。預設模式下是一個程式一個視窗,透過FreeRDP控制。中文輸入法不能使用Linux端的,只能用Windows的。目前FreeRDP的視窗在Wayland桌面會亂跳的樣子。建議使用X11桌面。需要完整Windows桌面的,點選「Windows Desktop」就行。在瀏覽器輸入http://127.0.0.1:8006也能透過noVNC登入Windows。在開啟Windows桌面的時候,其餘的RDP視窗會被關閉。有時候RDP視窗沒有關乾淨,用指令強制殺掉。killall xfreerdp 有時候虛擬機不能從WinBoat的界面關閉,用指令關docker ps  docker stop WinBoat WinBoat建立的Windows虛擬機容器會在Linux開機後自動啟動,可能會佔用一部分宿主機資源。不用的話記得關掉。共享資料夾#在Windows檔案總管 → 網路 → host.lan → Data ,可以看到Linux家目錄的檔案,檔案可以直接複製貼上。當然,你也可以用SSHFS或者SAMBA的方式,與Linux宿主機共享檔案。

-- gReader Pro 

總統:AI與生醫強強聯手 醫療照護品質必大幅提升

總統:AI與生醫強強聯手 醫療照護品質必大幅提升

https://www.cna.com.tw/news/aipl/202509040236.aspx

(中央社記者溫貴香台北4日電)總統賴清德今天表示,人工智慧(AI)是新時代的倚天劍、屠龍刀,也是台灣持續引領未來科技走向的重要關鍵,相信只要台灣的AI高科技產業與生醫產業強強聯手,不但產業能夠壯大,醫療照護服務品質,也必定能大幅提升。為因應內閣調整,賴總統也宣布,健康委員會執行秘書由行政院秘書長張惇涵與衛福部長石崇良擔任;委員之一沈靜芬出任國民健康署長,將由台大醫院長余忠仁接任委員。總統賴清德今天下午主持「健康台灣推動委員會第5次委員會議」致詞時表示,健康台灣推動委員會運作已經滿1年,非常感謝各位委員這1年來積極參與,讓跨領域、公私協力的合作,能夠更加落實,也感謝行政院的支持以及衛福部團隊的努力,整合跨部會力量,一步一腳印推動「健康台灣」各項工作。總統表示,因應行政團隊的隊形調整,委員會的執行秘書將由行政院秘書長張惇涵與衛福部長石崇良擔任,國發會主委因職務異動,由新主委葉俊顯擔任。總統說明,張惇涵熟稔府院溝通、處事明快,能夠讓政策加速落實。石崇良行政經歷豐富,兼具醫療專業與對外溝通能力。葉俊顯熟稔國內外產業政策,善於政策分析。石崇良與葉俊顯在疫情期間,為台灣奠定堅實的防疫基礎,並且對紓困政策提出良好解方。總統指出,健康台灣委員沈靜芬出任國民健康署長、請辭委員,感謝沈靜芬對委員會的付出,也期待在石崇良及沈靜芬的帶領下,將健康促進的核心概念落實於政策,實踐於生活。總統宣布,台大醫院長余忠仁將接任委員,余忠仁在台大醫院首創「星月計畫」,結合超過500家社區基層院所,建立醫院與社區共同照護體系,並在台大醫院新竹分院院長任內有諸多貢獻,相信余忠仁的加入,對於分級醫療、醫院評鑑等面向,都能提供許多寶貴的意見。總統談及,今天議程除報告上次會議列管事項處理情形外,衛福部也將提出,「智慧醫療結合健康照護」,以及「推動台灣生醫產業創新發展」兩項報告。總統解釋,AI是新時代的倚天劍、屠龍刀,也是台灣持續引領未來科技走向的重要關鍵,相信只要台灣的AI高科技產業與生醫產業強強聯手,不但產業能夠壯大,醫療照護服務品質,也必定能大幅提升。總統強調,台灣正面臨超高齡社會、慢性病激增,以及極端氣候變遷的挑戰,必須啟動健康照護的政策轉型,善用數位科技與人工智慧,打造一個涵蓋全年齡層、全場域、能主動預警,且能及時介入管理的智慧健康體系。如此一來,台灣才能從以疾病治療為主的醫療模式,轉型升級為以預防和健康促進為主的健康照護。(編輯:張若瑤)1140904

-- gReader Pro 

Google釋出嵌入模型EmbeddingGemma,主打裝置端離線RAG與語義搜尋

Google釋出嵌入模型EmbeddingGemma,主打裝置端離線RAG與語義搜尋

https://www.ithome.com.tw/news/171022

Google發布開源嵌入模型EmbeddingGemma,定位在裝置端離線情境下,提供語義搜尋與檢索增強生成(RAG)所需的文字向量。官方指出,該模型以3.08億(308M)參數在MTEB多語榜單中,為5億(500M)參數以下的開源模型最高排名,支援100多種語言,並透過量化感知訓練降低記憶體占用,可在低於200 MB記憶體環境執行,目標是讓行動裝置、筆電與桌機在無網路下也能完成檢索與問答。 EmbeddingGemma以Gemma 3架構為基礎,由約1億(100M)模型參數與約2億(200M)嵌入參數組成。模型提供約2,000 Token上下文長度,並與Gemma 3n共用分詞器,便於在同一裝置上以EmbeddingGemma完成檢索,再交由Gemma 3或Gemma 3n生成回答,縮短系統整體記憶體使用量。官方強調在EdgeTPU上處理256 Token輸入時,嵌入推論延遲可低於15 ms,對即時互動式應用具參考價值。 EmbeddingGemma採用Matryoshka Representation Learning(MRL),單一模型即可輸出多種維度的向量,提供768、512、256與128等尺寸選擇,讓開發者在檢索品質、延遲與儲存成本之間調整取捨。對RAG流程而言,檢索階段的相似度計算仰賴嵌入品質,嵌入越能刻畫語意與語境,越有助於找出與查詢最相關的段落並減少離題或錯誤回答。 EmbeddingGemma以離線與隱私為設計重點,文件與查詢的向量化皆在本地硬體完成,可用於搜尋個人檔案、簡訊、電子郵件與通知等資料來源,或建立企業知識庫本地檢索入口。模型與常見工具鏈整合,包含llama.cpp、MLX、Ollama、transformers.js、LM Studio、LlamaIndex與LangChain,並提供瀏覽器端的互動展示以視覺化文字嵌入。 Google將EmbeddingGemma定位為裝置端的嵌入解決方案,對需要離線運作、注重資料主權或希望在終端快速回應的應用較為合適,而面向大規模伺服器端服務,官方建議改採Gemini Embedding。

-- gReader Pro 

NotebookLM可以生成中文的影片摘要,聲音摘要也可以自訂格式

NotebookLM可以生成中文的影片摘要,聲音摘要也可以自訂格式

https://isvincent.pixnet.net/blog/post/51158504

Google NotebookLM 最近已經開放給學生使用,而且可以產生語音摘要、影片摘要、心智圖、報告等,其中語音摘要和影片摘要都已經支援中文了!對於教師備課也是不錯的好工具,可以讓 AI 來協助產生一些課程內容的簡介,能在課程開始前來協助介紹課程,或是在課程中協助整理或摘要某些段落,因為是影音呈現,所以在課堂中引起動機、帶動氣氛也很好用。並且可以下載影片為MP4檔。你可以在影片摘要的選項目自訂語言,選擇:中文(繁體)。你也可以生成語音摘要:自訂語音摘要可以設定多種格式,愈來愈有趣了:(目前在 Pro 版中呈現)👍深入探索:兩位主持人熱烈討論,解說並連結來源中的主題👍摘要:簡短摘要,讓你快速掌握來源的核心概念👍評論:根據來源提供專業評論和建設性意見,協助改善內容👍辯論:兩位主持人深入辯論,提供對來源的不同觀點

-- gReader Pro 

Baïkal:自架CalDAV行事曆同步伺服器,在Thunderbird與Android手機間同步

Baïkal:自架CalDAV行事曆同步伺服器,在Thunderbird與Android手機間同步

https://ivonblog.com/posts/baikal-caldav-server/

我想要搞一個類似Nextcloud Calendar的開源行事曆,但又不想安裝繁重的整套服務,故挑了一個輕量的替代方案。在同步行事曆方面,行之有年的方案就是CalDAV協定了,這是各大作業系統都支援的東西。只要架設一個託管CalDAV的伺服器,就能用各個裝置的行事曆客戶端同步。在這裡,負責同步的這套軟體叫做Baïkal(意思為),使用PHP寫成,它提供同步CalDAV與CardDAV的功能,可以同步行事曆、聯絡人。1. 撰寫docker-compose#Baïkal的原始碼位於Github。作者沒有做Docker映像,要用第三方打包的。安裝Docker新增一個目錄存放資料mkdir ~/baikal  cd ~/baikal 新增docker-compose.yml:services:  baikal:  image: ckulka/baikal:nginx  restart: always  ports:  - "8080:80"  volumes:  - ./config:/var/www/baikal/config  - ./data:/var/www/baikal/Specific 啟動容器docker compose up -d 開啟http://Linux伺服器IP:8080進入網頁界面,設定admin的密碼。將authentication type設定為Basic,允許以帳號密碼登入。資料庫選用SQLite新增一個使用者,這個使用者的行事曆就是之後要用來同步的。使用者的公開月曆網址是為https://Linux伺服器IP:8080/dav.php/calendars/帳號名稱2. 連接CalDAV#電腦端#以Thunderbird為例,點選行事曆側邊欄 → 開新行事曆 → 存放於網際網路網路,輸入Baikal伺服器的網址(https://Linux伺服器IP:8080/dav.php),以及帳號密碼。隨後Baïkal的行事曆就會顯示在Thunderbird上。Android手機#我使用DAVx⁵負責登入CalDAV內容。再用Fossify Calendar讀取裝置上的CalDAV。3. 網頁版CalDav客戶端#我希望能有一個網頁的行事曆介面能查看Baïkal的月曆,不依賴任何客戶端,所以額外部署了AgenDAV。但不知道為什麼,這個無法登入。docker-compose如下services:  agendav:  image: ghcr.io/nagimov/agendav-docker:latest  container_name: agendav  environment:  - AGENDAV_SERVER_NAME=127.0.0.1  - AGENDAV_TITLE=Welcome to Agendav Server  - AGENDAV_FOOTER=Hosted on Agendav Server  - AGENDAV_CALDAV_SERVER=http://Baiakl伺服器的IP/cal.php  - AGENDAV_CALDAV_PUBLIC_URL=http://Baiakl伺服器的IP:8075  - AGENDAV_TIMEZONE=Asia/Taipei  - AGENDAV_LANG=en  - AGENDAV_LOG_DIR=/tmp/  - AGENDAV_WEEKSTART=1  ports:  - "80:8080"

-- gReader Pro 

【引進多元化記憶體架構,擴展LLM記憶體資源】打破LLM的記憶體容量瓶頸

【引進多元化記憶體架構,擴展LLM記憶體資源】打破LLM的記憶體容量瓶頸

https://www.ithome.com.tw/tech/170995

短短幾年,大型語言模型(Large Language Model,LLM)技術不斷突破,能處理的內容,可輸出的對話複雜度與篇幅,都有大幅增長,能一次輸入與處理數百、上千頁篇幅、包含複雜內容的資料,並生成長達數萬、數十萬字的對話。 但LLM能力的進展,是以消耗硬體資源為代價,運算參數越多,處理的文字量越大,消耗的GPU運算能力與記憶體空間也越大。 隨著LLM能力急速進步,這兩年開始出現硬體資源擴展速度,追不上LLM能力增長的情況,特別是記憶體容量。LLM的記憶體需求正以10倍、100倍的幅度不斷暴漲,但GPU供給的記憶體容量,僅以每世代最多提高50%的程度增加,促使需求與供給之間的落差不斷擴大,以致在LLM應用形成「記憶體容量瓶頸」。 當GPU記憶體空間不足時,GPU將被迫等待資料從緩慢的外部儲存裝置載入,或被迫重新計算無法保存在記憶體中的資料,不僅導致LLM運作遲緩,甚至停頓,也造成GPU運算能力與維運成本的浪費。 這樣的情況,也促成以打破記憶體容量瓶頸為目的的一系列新技術,以及新解決方案誕生。 我們在6月底的封面故事《AI硬體架構新變革:KV快取產品崛起》,先從KV快取的角度,檢視LLM的記憶體瓶頸問題,以及相關解決方案的發展。 不過,KV快取只涉及LLM應用中的推論部分,還不是LLM記憶體瓶頸問題的全貌,這次我們將從更完整的LLM記憶體應用需求出發,檢視相關產品技術現況,涵蓋LLM架構與規格演進,以及各式各樣的LLM記憶體擴充解決方案。 影響LLM記憶體需求的因素 在訓練與推論階段,影響LLM記憶體占用容量的因素有所不同。 在訓練階段,影響記憶體需求的主要因素包括:模型權重(Weights)、梯度(Gradients)、追蹤與保存計算過程狀態的啟動反應表徵(Activations),優化器狀態(Optimizer States)等。在推論階段,影響記憶體需求的因素,則有模型權重,以及KV快取等。 其中最基本的影響因素是模型權重,也就是模型的參數數量與其精度,其他因素如梯度與優化器狀態的記憶體占用量,都與模型參數的數量、精度直接相關,模型參數數量越多,使用的計算精度越高,占用記憶體容量也成比例增加。 而占用記憶體容量最大宗的來源,則是訓練階段的Activations,以及推論階段的KV快取這兩項因素。其中Activations的記憶體占用量與自注意力機制(Self-Attention),以及資料內容長度等相關,特別是內容長度的記憶體占用量,呈現平方增長規模(訓練32K長度內容所需記憶體容量,是訓練4K長度內容的64倍);而且,AI推理階段對KV快取記憶體的需求量,直接取決於模型的輸入與輸出內容長度。總的來說,兩者都與輸入與輸出Token數量呈正比關係,也就是LLM的上下文區間(Context Window)的大小,越大的上下文區間,可保存越多的輸入與輸出內容,但需要的記憶體空間也越大。 所以,我們透過觀察LLM參數總數,以及支援的上下文區間大小演變,就能看出LLM的記憶體需求增長趨勢。 急速膨脹的LLM記憶體需求 以OpenAI的GPT模型為例,在參數數量方面,2018年問世的GPT-1僅1.17億個參數,2019年的GPT-2就增加到15億個參數,增加超過12倍,2020年的GPT-3又一舉增加到1,750億個參數,較最早版本增加1,500倍,2022年的GPT-3.5也是1,750億個參數,此後OpenAI不再公開後續GPT版本的參數數量,不過外界估計2023年推出的GPT-4,約含有17,600億個參數,2025年發表的GPT-4.5則估計有40,000億到50,000億個參數,從這個數字來看,GPT模型參數數量,在8年內增加了3萬倍以上。如果只看2020年GPT-3以後情況,則到GPT-4.5為止的總參數量,也增加20到30倍。 在上下文區間方面,為了生成篇幅更長、複雜且更精確的對話內容,上下文區間的大幅提高是所有LLM共通趨勢。 例如,GPT-1只支援512個Token,接下來幾個版本都以倍數增加,GPT-2為1,024個Token,GPT-3為2,048個Token,GPT-3.5為4,096個Token;到了GPT-4一舉提高到32,768個Token,GPT-4 Turbo又增加到128,000個Token,250倍於最初的GPT-1,接下來GPT-4o與GPT-4.5都維持在128,000個Token。接著OpenAI為了因應其他LLM競爭,在2025年4月發表的GPT-4.1上,將支援的上下文區間提高到100萬個Token,相較於最早的GPT-1,提高至將近2,000倍,從GPT-3起算,也提高將近500倍。 我們再以開源的Meta Llama模型作為對照,相對於GPT,Llama一開始是以較少參數量,但仍能達到足夠效能為訴求,2023年初發表的最早版本Llama擁有652億個參數,只相當於GPT-3.5的1/3,比起同時期問世的GPT-4,參數數量更相差30倍。後來2023年中與2024年初推出的Llama 2與Llama 3,參數量也維持在700億個上下,不過2024年中推出的Llama 3.1,最大參數量增加到4,050億個,較最初版本提高6倍,2025年4月發布的Llama 4,目前最大參數量也維持在4,000億個(Maverick版),但另有1個擁有20,000億個參數的版本(Behemoth版)還未正式推出,相較於最初的Llama提高超過30倍,參數量已達OpenAI同時期推出GPT-4.5的同一層次。 在上下文區間方面,最初的Llama支援2,048個Token,只相當於早了3年推出的GPT-3,不過Meta追趕腳步很快,接下來Llama 2與Llama 3支援的上下文區間,依序成倍增加到4,096個與8,192個,然後Llama 3.1一舉提高到128,000個Token,追上同時期GPT-4o、GPT-4.5的水準。 緊接著Meta更在最新的Llama 4上,將上下文區間大幅提高到100萬個Token(Maverick版),以及1,000萬個Token(Scout版),分別較最初的Llama增加將近500倍與5,000倍,為當前LLM的最高規格。 總的來說,就算不計入2020年以前的早期版本LLM,只看2020年以後問世的較新版本LLM,在過去5年內,LLM的參數數量已從數百億到1千多億個,增加到數萬億個,幅度增長30倍以上。 這意味著:在其他條件不變的前提下,光是載入模型本身,需要的記憶體空間也跟著增加30倍以上;而LLM所能支援的上下文區間大小,也從2,048個Token提高到100萬個Token,最大還能達到1,000萬個Token,增長500倍到數千倍。也就是說,為了應付越來越長的上下文區間,訓練與推論過程中的記憶體耗用量,也將隨著膨脹數百倍至數千倍以上。 所以,要運行當前最新世代LLM,運算系統需要的記憶體容量,較4、5年前的LLM至少增加數十到數百倍以上。 MOE架構的記憶體需求 一些較晚推出的LLM,為了在擴大模型規模的同時,抑制運算資源的膨脹,而採用混合專家模型架構(Mixture of Expert model,MOE)。MOE架構LLM是由多個較小型專家單元(Expert)組成,對每個Token的計算只需啟用一部分專家單元與活躍(active)參數來進行,從而可大幅節省運算資源、時間與成本。 例如OpenAI在2023年推出的GPT-4,據稱就採用8 x 220B或16 x 110B的MOE架構,由8個220B規模(2,200億個參數),或16個110B規模(1,100億個參數)的專家單元組成,總參數量達到17,600億個,十倍於上一代GPT-3.5,但GPT-4並不同時啟用所有參數,據稱一次只需啟用2,800億個活躍參數,顯著減少了運算量。 類似的,Meta今年上半年發表的Llama 4也改用MOE架構,由16個或128個專家單元組成,雖然總參數量達到1,090億(Scout版)、4,000億個(Maverick版)與20,000億個(Behemoth版),但實際啟用參與運算的活躍參數僅170億個與2,880億個。 問題在於,MOE架構確實能顯著減少運算量,卻不能節省記憶體占用。MOE架構是透過路由器元件(router)來檢視輸入內容token,然後選擇交由合適的專家單元處理,每1個輸入token可能分別交由不同專家單元處理,而會選擇哪一個專家單元是無法預先確定的。所以,若非一開始就將所有專家單元的參數全部載入記憶體,一旦路由器選用到未將參數載入記憶體的專家單元,此時,就必須等待緩慢的底層儲存裝置載入參數,導致運作緩慢、反應遲鈍。 所以,為了確保訓練與推理作業的順暢,MOE架構LLM還是必須將全部參數載入記憶體,而不能只載入活躍參數,相較於既有的密集型(dense model)LLM,並沒有節省多少記憶體空間。 GPU的記憶體容量增長 看完需求端方面,也就是LLM記憶體需求增長狀況後,接下來我們檢視供給端方面,也就是GPU配置的記憶體容量增長情況。 以Nvidia的HGX資料中心級GPU為基準,過去7、8年來,每一代新產品大致都能提供較上一代多出30到50%的HBM記憶體容量,2017年推出的V100配置最大32GB的HBM2記憶體,2020年的A100則擁有80GB的HBM2e,2022年發表的H100最初也是配置80GB HBM2e(後來有升級到94GB HBM3的版本),2023年的H200增加到141GB HBM3e,2024年初與2025年初發表的B200(Blackwell)與B300(Blackwell Ultra),則分別配置192GB與288GB的HBM3e記憶體,除了A100到H100之間,記憶體容量增長有所停滯,其餘產品都維持近50%的記憶體容量增長,在8年內一共提升了9倍。 作為對照,我們再來看AMD Instinct系列GPU記憶體配置情況,從2020年底推出,擁有32GB HBM2記憶體的MI100起算,2021年底發表的MI200系列增加到128GB HBM2e,2023年底推出的MI300系列,又增加到192GB HBMe3。2024年底AMD推出MI325X,記憶體容量提升到256GB HBMe3。不久前於2025年6月發表的MI350,記憶體容量則進一步升級到288GB HBM3e,與Nvidia的B300同等。 總計過去5年來,AMD Instinct系列的記憶體配置容量也增長9倍,超過Nvidia同時期的GPU記憶體增長幅度——單論2020到2025年,Nvidia從H100到B300的GPU記憶體容量,其實僅提高3.6倍。 緊迫的GPU記憶體不足問題 無論是8年內提高9倍,或是5年內提高9倍,單從數字上來看,GPU記憶體容量都有相當可觀的增長,但問題在於,同一時期,LLM的記憶體需求卻是以數十倍、數百倍的幅度提高,顯然GPU的記憶體供給增長幅度,遠遠落後於LLM的記憶體需求。 LLM不僅需耗用大量運算力,同時也是記憶體密集型應用。事實上,在LLM訓練與推論過程中,要有效發揮GPU運算能力,不可或缺的前提,是GPU能即時地從記憶體饋入運算資料,也就是說,記憶體必須要有充足空間載入運算所需資料,並以足夠高的頻寬持續將資料饋入GPU,才能維持GPU的利用率,避免閒置。 所以,足夠的GPU記憶體容量與傳輸頻寬,是LLM應用的必要條件。 而隨著LLM複雜度與規模的急速膨脹,即便是較小規模版本的LLM,記憶體容量需求也相當可觀。 舉例來說,訓練一個80億參數量(8B)的小規模LLM模型,在FP16精度下,載入參數需要16 GB記憶體,即便消費型GPU的記憶體容量也足以承載,但加上參數梯度後,記憶體占用就會加倍,如果再加上Activations與自注意力機制等需求,總記憶體需求量會膨脹到上百至數百GB,甚至TB等級,即便高階的資料中心型GPU,也無法獨力承載這樣大的記憶體需求。 如果換成中、大規模模型,耗用的記憶體容量,將比前述數字高出10倍、數十倍。對於175B規模的GPT-3,或405B規模的Llama 3.1模型,在FP16精度下,光是載入參數就要占用350GB與800GB記憶體,加上訓練過程中的其他記憶體開銷,將會耗用數以TB計的記憶體。 而對於推論作業來說,GPU記憶體除了必須載入模型參數,由於當前LLM支援的上下文區間都達到128K個Token以上,KV快取的記憶體需求會隨著輸入、輸出內容長度增加而迅速膨脹,甚至會占用比模型參數本身高出數倍的記憶體空間。即便是中、小規模的LLM,當設定的輸入、輸出內容長度較長,或同時處理的資料批次較大時,推論時需要的KV快取記憶體往往也會達到數百GB等級或更多。 當GPU的記憶體空間不足時,將連帶造成LLM運作效率大幅下降,甚至停擺。GPU須時常等待資料從緩慢的外部儲存裝置載入到記憶體,導致GPU閒置,以及LLM運作遲緩;若記憶體容量不足以充分保存訓練與推論過程中的資料(如運算過程狀態或KV快取等),當後續需要這些資料時,GPU必須重新計算這些資料,造成大量GPU時間耗費在重新計算上。 「開源節流」克服LLM記憶體瓶頸 要克服LLM龐大的記憶體需求,以及GPU有限的記憶體供應量之間落差,方法不外乎「節流」與「開源」。 所謂「節流」,就是設法減少LLM訓練與推論過程中的記憶體耗用。而「開源」則是增加記憶體供給量。  節省記憶體消耗 過去數年來,開發商與研究人員已發展一系列技術,來節約LLM訓練與推論過程中占用的記憶體。 例如:在訓練階段可採取Activation重新計算(Recomputation),放棄保存部分運算過程狀態,以重新計算來換取節省記憶體占用。針對KV快取,常用作法則有:將高精度浮點數轉換為低精度,以損失精度換取節省記憶體的量化技術(Quantization),或在維持一定精度下,只保存部分KV快取值的稀疏技術(Sparsification);還有允許輸入內容不斷增加,而仍確保KV快取不致溢出GPU記憶體容量的滑動窗口技術等。 改進自注意力機制,也是節約KV快取記憶體占用的一大重點方向,例如:藉由共用KV快取、節省記憶體占用的多查詢注意力(Multi Query Attention,MQA)與分組查詢注意力(Grouped Query Attention,GQA),可以在非連續的記憶體空間,保存KV快取資料,減少記憶體浪費的分頁式PagedAttention技術,以及能夠壓縮注意力輸入、只儲存潛在向量,藉此大幅減少KV快取的多頭潛在注意力機制(Multi-head Latent Attention,MLA)等。 前述技術能在訓練與推論過程中的不同環節,節約數十百分比到數倍的記憶體消耗,但本質上其實是不同面向的折衷與妥協,是以精度、運算時間、模型能力等方面為代價,來換取節省記憶體,並非適用所有應用方式,必須視情況取捨。 另一方面,各式記憶體節約技術的成效,又會被LLM持續進化所帶來的記憶體需求增長所抵銷。為追求更完善的資訊處理與生成能力,LLM的規模依舊持續擴大,新一代LLM還藉由引進多模式學習技術(Multimodal learning),已不限於處理文字訊息,而能處理文字、圖像、語音等多元資料內容,也帶來不斷膨脹的記憶體需求。 因此,僅僅依靠軟體或運算架構來節約記憶體耗用的「節流」手段,已不足以面對記憶體需求不斷成長的壓力,必須搭配擴展記憶體資源的積極「開源」手段。  增加記憶體資源 既然單一GPU的記憶體,不足以承載LLM的訓練與推論工作,那麼最最簡單、粗暴的解決辦法,就是使用更多GPU組成叢集,藉此匯聚更大的記憶體空間。 多GPU叢集是AI與LLM應用的標準硬體架構,當前GPU伺服器主流配置是8路組態,8組GPU之間透過NVLink或Infinity Fabric之類專屬高速介面相互直連。以當前資料中心級GPU規格來說,1臺8路GPU伺服器可匯聚1到2 TB的HBM記憶體,足以載入大規模LLM的數千億個參數,考慮到訓練與推論過程中的其他記憶體開銷,這樣的記憶體規格可能還是不敷所需,可再加入第2臺、第3臺,或更多GPU伺服器,進一步擴展LLM可用的HBM記憶體容量。 顯而易見的,這種作法存在兩大副作用,一是缺乏成本效益,二是未精準對應實際需求。 當瓶頸發生在「記憶體容量不足」,而非「GPU運算能力不足」時,引進更多GPU,確實能獲得更多HBM記憶體,但考慮到GPU昂貴的成本,這是非常沒有成本效益的記憶體瓶頸解決手段,形成浪費。 兩種解決手段 只依靠LLM軟體架構與演算法改進手段,所得到的節約記憶體效果,不足以應付持續增長中的記憶體需求;但透過增加GPU數量,為LLM提供更多HBM記憶體資源,又欠缺成本效益。 所以,更合理的手段,是為LLM尋求與GPU「脫鉤」的記憶體資源擴展方式,不需為了增加記憶體而引進1整組GPU,而可單獨、靈活地擴展記憶體。 這也是當前大多數LLM記憶體擴展解決方案的發展方向——從GPU外部,提供可獨立擴展更大規模的記憶體空間,藉此將原本完全由GPU記憶體承擔的工作負載,卸載到GPU以外的記憶體裝置上,如CPU DRAM,或透過網路介接的NVMe快閃儲存設備,代價是這些裝置的傳輸頻寬,明顯不如與GPU直接整合的HBM,算是以較低頻寬,換取不被GPU綑綁的記憶體擴展能力。 另一些廠商則重視傳輸頻寬更甚於擴展能力,沿用HBM與GPU的晶片整合架構,但改用儲存密度高出數倍的NAND快閃記憶體,來取代基於DRAM的HBM,這便是目前發展中高頻寬快閃記憶體(High Bandwidth Flash,HBF),擁有相當於HBM的高傳輸頻寬,但容量高出HBM十多倍,同樣能為LLM提供更大記憶體空間,但不具備與GPU脫鉤的擴展靈活性。 基於外部記憶體裝置的擴展方案,以及直接與GPU整合的高頻寬快閃記憶體(HBF),構成當前LLM記憶體擴展解決方案的兩大類型。 接下來我們便從這兩條技術路線出發,檢視這領域當前的發展。  LLM總參數數量增長趨勢 自LLM問世以來,模型總參數量便以指數爆發性增長,連帶導致記憶體需求量暴漲。 以最具代表性的OpenAI GPT為例,自2018年推出的GPT-1起,到2025年初發表的GPT-4.5,模型包含的參數量在8年內增加3萬倍以上。如果只看2020年以後,從GPT-3到GPT-4.5的總參數量也增加20到30倍。對照開源LLM最具代表性的Meta Llama,總參數數量也在兩年半內增加30倍。 當LLM的總參數量增加30倍,意味著要以相同精度將參數載入記憶體,需要的記憶體空間也將增加30倍。連帶的,訓練與推論過程中其他需求耗用的記憶體量,也會成比例增加。*GPT-4以後的參數數量為外界估計,非官方公布數字。 **含20,000個參數的Behemoth版Llama 4,尚未正式推出。 資料來源:iThome整理,2025年8月  LLM上下文區間增長趨勢 越大的上下文區間(Context Window),可讓LLM容納更多輸入與輸出內容,保存更多計算資料,顯著提高處理與生成長篇幅內容的能力,但連帶也需消耗更多記憶體空間。 以Open AI的GPT為例,自最早的GPT-1,到今年初發表的GPT-4.1,支援的上下文區間從512個Token提高到100萬個Token,提高將近2,000倍,從GPT-3起算,也提高將近500倍。而開源領域的Meta Llama,更從Llama的2,048個Token提高到Llama 4的1,000萬個Token,增長近5,000倍。 隨著上下文區間大幅提高,耗用的記憶體空間也將以成百、上千倍的比例大幅增加。資料來源:iThome整理,2025年8月  GPU記憶體容量的增長趨勢 過去7、8年來,資料中心級GPU的HBM記憶體容量,大致以每一世代提升30%到50%的幅度增長,以Nvidia HGX系列GPU為例,從V100到B300的記憶體容量足足提高9倍,對照AMD的Instinct系列GPU,從MI100到最新的MI350,在5年內也提高9倍,都稱得上相當顯著的增長。 問題在於,同一時期內,LLM的記憶體需求是以數十倍、數百倍幅度暴漲,遠超過GPU記憶體容量提升幅度,需求與供給之間出現巨大的落差,形成LLM應用中的記憶體容量瓶頸。資料來源:iThome整理,2025年8月

-- gReader Pro 

ONLYOFFICE 9.0.4 開源辦公套件登場:AI 助理加持、替代MS Office好選擇

ONLYOFFICE 9.0.4 開源辦公套件登場:AI 助理加持、替代MS Office好選擇

https://www.techbang.com/posts/124806-onlyoffice-9-0-4-released-with-ai-and-dark-mode

ONLYOFFICE 9.0.4版本推出,重點在於整合 AI 助理外掛,讓使用者體驗 AI 功能。本次更新讓ONLYOFFICE更像整合AI的全能辦公平台,值得關注。開源辦公軟體戰場又有新動作。跨平台辦公套件 ONLYOFFICE 推出 9.0.4 版本,不只修正多項錯誤,還把 AI 助理直接塞進外掛系統,讓它不只是 Office 替代方案,還更像一款整合 AI 的全能辦公平台。  AI 助理外掛一次上線 這次更新的最大亮點,就是官方直接提供 AI 助理外掛工具。用戶只要在外掛管理器中安裝,連接 OpenAI、Mistral、Groq 或本地 AI 模型,輸入 API 金鑰,就能讓 AI 幫忙做文字摘要、改寫文章、生成新內容、產圖、甚至解釋專業術語。對於要處理大量文件、會議紀錄或需要快速產出內容的用戶來說,等於直接內建了 ChatGPT 類型的功能。 除了 AI 助理,這次還新增了圖片編輯器、DeepL 翻譯外掛,並支援 .woff2 字型格式,讓排版更有彈性。 編輯體驗與安全性升級 文件編輯器方面,ONLYOFFICE 針對「限制編輯區域」功能進行優化,能更精準地設定哪些段落可編輯,哪些保持保護狀態。另一個細節是新增了檔案鎖定機制,避免同一文件被多個應用同時開啟造成損壞,對團隊協作環境特別有幫助。 安全性部分,開發團隊修補了允許在文件自訂屬性中執行 JavaScript 的漏洞,防止惡意代碼攻擊,算是一次低調但重要的安全更新。 多項錯誤修復 9.0.4 版本修正了深色模式下滾動條顯示異常、DOCX/PPTX/ODS 轉換時的隨機崩潰問題,以及特定 XLSX 資料透視表的記憶體錯誤。此外,也解決了:   複製資料列/欄位導致編輯器在特定瀏覽器中凍結   儲存電子表格為圖片時,RTL 文字與圖形錯位   macOS 上粗體 emoji 顯示錯誤   ODS 檔案在 Microsoft Excel 開啟時出錯   從 GNOME 連結的 Google Drive 開啟文件無法編輯   含 SVG 圖檔的二進位檔轉 XLSX 時崩潰   微軟 Office 強力競爭對手 ONLYOFFICE 是近年來微軟 Office 的熱門替代方案之一,也是 LibreOffice 的主要競爭對手,主打免費開源、多平台支援(Windows、Linux、macOS、Android、iOS),以及與雲端協作服務的高度相容性。對企業與教育機構來說,它既能降低授權成本,又保有高相容度與擴充性。 隨著 AI 成為生產力工具的核心,這次的 9.0.4 更新,等於讓 ONLYOFFICE 提前把 AI 整合進日常辦公流程,對習慣開源環境、想嘗鮮 AI 應用的使用者來說,值得立即更新體驗。  延伸閱讀:Google 推出 Docs、Sheets 獨立辦公軟體APP,iOS 及 Android 版同時上線 延伸閱讀:微軟 Office 突然頻頻跳出證書過期警告?原因可能是「忘記續簽」 延伸閱讀:微軟澄清:含廣告 Office 版本僅為小規模測試,無意推出免費版 延伸閱讀:繼 Office 365 後再更名!Microsoft 365 全新名稱 365 Copilot 登場   加入T客邦Facebook粉絲團

-- gReader Pro 

【兩大路線擺脫GPU記憶體容量有限的束縛】LLM記憶體擴展解決方案概覽

【兩大路線擺脫GPU記憶體容量有限的束縛】LLM記憶體擴展解決方案概覽

https://www.ithome.com.tw/tech/170998

為了設法克服當前大型語言模型(LLM)面臨的記憶體容量瓶頸問題,過去1年多以來,湧現一大批記憶體擴展解決方案,各自從不同技術路線出發,為LLM提供額外記憶體資源。 LLM記憶體擴展產品類型 從記憶體資源的來源,我們可將LLM記憶體擴展方案分為兩條路線:外部擴展、內部擴展。  外部擴展形式產品 HBM記憶體與GPU的連接,是透過專門的中介層(Interposer)基板,HBM與GPU之間是晶片層級的整合,在製造階段就被嵌入為GPU單元的一部分,受GPU晶片封裝與接腳布線的物理限制,HBM記憶體容量是固定的,用戶不能視需要額外擴充。 解決這個問題最直接的方法,就是利用GPU外部的其他記憶體資源,來擴充LLM可用記憶體空間,將LLM的記憶體工作負載,從GPU的HBM記憶體,卸載(Offload)到外部記憶體裝置上。 而這些外部記憶體資源,包括GPU伺服器本身的DRAM、SSD,或是透過網路介接的外接式DRAM裝置,以及快閃儲存設備等。 這便是「外部擴展」路線,也是當前大部分LLM記憶體擴展方案的做法,優點是導入門檻低,以及不受GPU綑綁的靈活擴充能力。 首先,這類擴展方案與GPU之間,是軟體層次的整合,在記憶體管理軟體控制下,將這些外部的DRAM或快閃記憶體,構成可供LLM存取的虛擬記憶體空間,不涉及深層次的硬體整合,便於部署。其次,這些記憶體裝置都獨立於GPU之外,終端用戶可視需要靈活配置,隨插即用,擴展能力與部署彈性都更大。 而這類方案的缺點,則是傳輸頻寬受限於PCIe。除了採用GPU至CPU直連整合架構的伺服器,多數應用環境下,GPU與伺服器DRAM,或其他外部記憶體裝置之間的資料傳輸,都必須透過PCIe介面,資料傳輸頻寬低於與GPU直連的HBM記憶體,或GPU互連專用的介面(如NVLink或Infinity Fabric)。即便是PCIe 5.0 x16介面,頻寬也只相當於HBM3或HBM3e的1/7到1/10,或NVLink的1/5。 也就是說,外部擴展方案是「以較低的頻寬交換更大的擴展能力」。  內部擴展型式產品 「內部擴展」形式的LLM記憶體擴展路線,目前只有高頻寬快閃記憶體(High Bandwidth Flash,HBF)這一種產品。HBF架構與HBM相似,都是與GPU在晶片層級整合,但採用儲存密度更高的NAND快閃記憶體,取代基於DRAM而成的HBM,從而提供較HBM高出十多倍的容量。 HBF這種「內部擴展」路線,同樣能達到大幅擴展LLM可用記憶體資源的目的,優點是具備與HBM相當的傳輸頻寬,而且由於更接近GPU,存取延遲也低於外部擴展類型方案,缺點則是與GPU深度綑綁,終端用戶不具備配置與擴充的自由與靈活性,特徵與外部記憶體擴展方案正好相反。 擴展記憶體的效益 外部與內部擴展這兩種架構,雖然技術路線與著眼點有異,但應用上互不衝突,可以並存,而且根本目的相同,都是為了幫助LLM擺脫GPU HBM容量有限的束縛,大幅增加可用記憶體空間。 無論HBF,還是基於DRAM或快閃儲存裝置的擴展方案,效能都遜於HBM,但遠勝過讓GPU耗費在重新計算Token,或是從速度更慢的底層儲存裝置載入資料。 而且,這些擴展記憶體裝置的單位成本,都比HBM低了數個層次,DDR DRAM單位容量成本不到HBM的1/5,而快閃記憶體的成本低於DRAM的1/10,因此可「以量取勝」,輕易為LLM提供數十TB、數百TB等級的額外記憶體空間,從而帶來2大效益: (1)顯著提高LLM執行訓練與推論的能力。 透過擴展方案提供的額外記憶體空間,可以容納只靠GPU HBM無法容納的大規模LLM參數,也能採用更高的計算精度,或是保存更多的運算過程內容,以及支援數量更多的輸入與輸出Token等。 (2)大幅改善LLM基礎設施的成本效益。 原本需要匯聚大量GPU單元,才能獲得TB等級,或是數十、數百TB等級記憶體空間,現在只需少數GPU單元,搭配外部記憶體擴展方案就能獲得,整體成本大為降低。 接下來,我們便逐一檢視當前已發表的LLM記憶體擴展方案與產品。 高頻寬快閃記憶體 Sandisk在2025年2月投資者日,率先揭露的高頻寬快閃記憶體(HBF),可視為高頻寬記憶體(HBM)的快閃記憶體版本,是針對頻寬最佳化的快閃記憶體概念。 現有快閃記憶體是基於成本最佳化設計,數萬個快閃記憶體儲存單元(Cell)組成大型陣列,構成基本讀寫存取的分頁(Page),並共用1條I/O通道,HBF則細分為多個較小型的陣列,每個小型陣列各有獨立的I/O通道,從而大幅提高I/O頻寬。 在實作上,HBF架構十分類似HBM,將16層垂直堆疊的裸晶(Die)先連接邏輯晶片(Logic Die),然後再透過中介層基板與GPU連接。 Sandisk利用其CMOS直接鍵結至陣列(CMOS directly Bonded to Array)技術,將3D NAND快閃記憶體的核心裸晶(Core Die)連接到邏輯晶片上,邏輯晶片再透過中介層基板連接GPU。而這些堆疊的晶片之間,也像HBM一樣透過矽穿孔(silicon vias,TSV)互連,但容量比HBM更大。Sandisk聲稱,HBF可在頻寬相當於HBM的同時,以相似成本提供8到16倍容量。 Sandisk設想可在單個GPU上,整合8個512 GB的HBF晶片,從而提供高達4 TB記憶體容量,比起當前HBM容量最高的GPU(如Nvidia B300或AMD MI350均配置288 GB HBM),高出14倍以上,從而讓單一GPU即可容納GPT-4的1.8萬億個參數(FP16精度下需耗用3.6TB記憶體)。 大容量的HBF,也能配合MOE架構LLM運作,例如512 GB HBF記憶體可承載640億規模(64B)參數的MOE模型,並區分為8個64 GB的小型記憶體陣列,每個小陣列分別為MOE的1個專家單元提供記憶體空間服務。 Sandisk表示,他們發展HBF架構已有1年以上,並獲得主要AI應用用戶的反饋。在稍早的今年8月,Sandisk與HBM記憶體主要供應商SK海力士共同發布消息,表示正在合作進行HBF的標準化與供應來源多元化,也就是說,除Sandisk外,SK海力士未來也能產製HBF,最終促成HBF成為業界標準。 Sandisk預期2026年下半推出首批HBF樣品,至於應用HBF的AI推理設備則預計於2027年初上市。 LLM外部記憶體擴展產品 將LLM的記憶體工作負載,卸載到GPU外部記憶體裝置上的外部記憶體擴展方案,又可依應用型態與產品構成,細分為多種類型。 從應用型態來看,可分為通用型與KV快取卸載型等2大類。前者可同時LLM訓練與推論階段的記憶體卸載,後者則主要針對LLM推論階段的KV快取卸載應用。 接下來我們便以應用型態作為基本區分,來檢視當前的LLM外部記憶體擴展產品。 通用型LLM記憶體擴展產品 原則上,LLM外部記憶體擴展產品,應能同時用於訓練與推論階段的記憶體工作負載,但目前絕大多數產品都聚焦推論階段的應用,目前公開資料中,聲稱能同時涵蓋LLM訓練與推論應用的產品,我們已知只有群聯(Phison)在2023年7月發表的aiDAPTIV+。 aiDAPTIV+由aiDAPTIVLink中介軟體,aiDAPTIVCache快取用SSD,以及aiDAPTIV+ Pro Suit附屬軟體套件等3部分構成。 整個方案的核心,是部署在GPU伺服器上的aiDAPTIVLink中介軟體,用於統一管理GPU伺服器的記憶體存取,可將GPU伺服器的各式記憶體裝置,包括GPU的HBM或GDDR記憶體,CPU的DRAM,或NVMe SSD,設定為跨不同類型記憶體的虛擬化記憶體池。 當GPU伺服器載入AI模型時,aiDAPTIVLink會分析記憶體需求,將資料切分,分別載入GPU HBM、CPU DRAM,或SSD,並隨著AI模型運行,視存取需求在3個虛擬記憶體層之間移動資料,以維持GPU利用率,避免重新計算Token。 aiDAPTIV+主要訴求是可大幅降低用戶端LLM訓練設施門檻,讓只配備較少GPU與HBM記憶體的環境,利用CPU DRAM與SSD作為額外記憶體空間,從而運行較大規模的LLM。也能改善推論效能,縮短第1個Token產生時間(Time to First Token,TTFT),擴展上下文Token長度。 而利用外部記憶體參與執行LLM訓練的代價,則是較慢的存取速度。所以,這類方案適合對成本敏感,但對於運算時間較不敏感的用戶。 KV快取卸載型產品 絕大多數LLM記憶體擴展方案,都將應用面向局限在推論過程中的KV快取卸載,而非用於載入模型參數,以免速度較慢的外部記憶體,對LLM運作效能帶來太多衝擊。 KV快取卸載的目的,是將存取頻率較低的KV快取資料,從GPU的HBM記憶體移到外部記憶體,藉此可容納更多KV快取資料,大幅提高GPU伺服器可處理的上下文區間,也大幅減少GPU重複計算Token的需要,以及降低處理上下文的成本。 我們在6月的封面故事《AI硬體架構新變革:KV快取產品崛起》,曾初步介紹KV快取卸載產品情況,時隔近3個月後,情況又有所變化,出現新的廠商與新的產品型態,促使我們重新梳理這個領域的現況。 依產品部署型態,可以是否搭配特定儲存平臺或硬體裝置,將KV快取卸載產品分為純軟體形式,以及結合特定硬體平臺裝置等2大類型。  軟體式產品 如Mooncake、AIBrix、LMCache、Alluxio等開源的KV快取卸載軟體專案,還有Nvidia的Dynamo推理軟體框架,以及GridGain的共享記憶體等,這類方案無須搭配特定的外部記憶體裝置,或儲存硬體,而是利用GPU伺服器叢集中的可用DRAM與SSD空間,來作為額外KV快取記憶體。 這些軟體透過安裝在GPU伺服器的中介層軟體,橫跨多臺GPU伺服器,將閒置的DRAM與SSD空間,組成多階層、分散架構的外部KV快取記憶體池,作為原有KV快取記憶體的額外補充。 這類產品特點是利用既有GPU伺服器資源,無須搭配外部設備,還可以橫跨GPU叢集的多臺節點,平行處理上下文長度較長的Token,縮短Token產生時間。不過,這類產品擴展能力相對有限,僅限於使用GPU伺服器叢集自身的DRAM與SSD資源。  硬體式產品 須搭配個別廠商的專屬儲存平臺與設備,或是外部記憶體裝置,將外部裝置的儲存空間,透過網路掛載到GPU伺服器上,作為外部的KV快取儲存空間,並搭配安裝在GPU伺服器上的推論記憶體管理中介軟體,將LLM的KV快取需求發送到這些外部KV快取空間上,卸載GPU HBM的負荷。 這類產品又可依搭配的儲存媒體,區分為兩大類型: 第一類是搭配全快閃儲存裝置的產品,包括:WEKA結合WekaFS檔案系統的增強型記憶體網格(Augmented Memory Grid,AMG),VAST Data搭配自家儲存平臺的VUA(VAST Undivided Attention),焱融科技(YanRong)搭配YRCloudFile 分散式檔案系統的KV快取,Pliops搭配其XDP LightningAI儲存伺服器的KV快取平臺,還有華為整合在OceanStor A800高階儲存陣列的KV快取卸載功能等。另外,華為日前透露即將推出的AI SSD,也屬於這類硬體型KV快取卸載產品。 這些外部儲存平臺提供的KV快取記憶體空間,都是由NVMe SSD構成,儘管存取速度相對較慢,但可透過底層儲存平臺的分散式架構,提供PB等級的龐大擴展能力,還能透過SSD的非揮發儲存特性,持久地保存KV快取資料,構成可長期保存與重複利用的Token儲存庫。 第二類是搭配外接DRAM記憶體設備而構成的產品,例如,PEAK:AIO基於CXL技術的外接式KV快取記憶體設備,還有Enfabrica基於其ACF-S乙太網路/CXL交換器,所發表的的EMFASYS外接式記憶體解決方案。 這類產品的本體,是外接式DRAM記憶體裝置,也就是安裝了大量DRAM的機箱,透過CXL/RDMA網路掛載到GPU伺服器上,作為擴展的KV快取記憶體空間。優點是存取延遲比基於NVMe SSD的方案低了10倍以上,但擴展容量也相對較低,而且,由於DRAM的揮發性,這類方案不具備長期保存KV快取資料能力。 部署、效能與擴展性的權衡 LLM記憶體擴展是處於蓬勃發展階段的新興領域,不過1年多時間,就已問世將近20款解決方案與產品。 我們前面介紹的產品中,除了Sandisk的高頻寬快閃記憶體(HBF),華為AI SSD,以及PEAK:AIO與Enfabrica的外接式CXL記憶體池等產品仍在研發階段外,其餘多已實際可用。 這些產品的目的雖然相同,但效能、擴展能力與部署門檻相差很大。 就部署便利性來說,Mooncake、LMCache這些開源軟體,無疑是最便利的,無須任何配套設備,直接利用現有GPU伺服器即可部署,群聯aiDAPTIV+與華為AI SSD的部署門檻也很低,只需中介軟體加上幾臺SSD即可運作,適合對成本敏感的用戶。 部分產品則須搭配一整套多節點儲存叢集來運作,門檻相對較高,如WEKA、VAST Data等的解決方案,不過,這些搭配儲存叢集的方案,可憑藉底層的分散式檔案系統,提供PB等級的KV快取擴展空間,擴展能力遠勝其他產品型式。 至於效能方面,不同類型產品各有優劣,就KV快取部署位置來說,使用GPU伺服器內部資源(DRAM或SSD)的方案,存取延遲與頻寬大多優於透過網路介接的外接裝置,但部分外接裝置也能透過平行存取,匯聚出不遜於伺服器本機DRAM的龐大傳輸頻寬。 就儲存媒體形式來說,基於DRAM的方案,存取延遲與頻寬都優於基於NVMe SSD的方案,但SSD有著更低的成本與更大的容量與密度,所以,理想選擇是同時混用DRAM與SSD的分層架構,視存取需求移動資料位置,從而兼顧效能、成本與擴展性。也就是說,不同類型記憶體擴展方案,彼此並不互斥,而可並存。 至於Sandisk的高頻寬快閃記憶體(HBF)則獨樹一格。就部署來說,完全視Sandisk與GPU廠商間的合作而定,若合作不成,自然無法部署;若合作成功,則直接整合在GPU內部,用戶端直接可用。就效能與擴展能力,HBF傳輸頻寬相當於HBM(但存取延遲仍遜於HBM),高於所有外部形式擴展方案,不過,只能提供數TB等級的記憶體空間,遠低於外部擴展方案。 LLM記憶體擴展應用的擴散 隨著LLM持續發展,記憶體需求依舊持續增加。新一代模型的規模將會更大,混合專家模型(MOE)則須需大量各自掌握不同技能的專家單元,還有迅速發展中的多模式(Multimodal)模型,將文字、圖像、語音等訊息融合在一起,這些應用全都是記憶體密集型,將帶動LLM記憶體需求進一步提高,這也意味著,與GPU HBM記憶體供給能力之間的落差,將持續擴大。 我們認為,在LLM龐大的記憶體需求壓力下,除了擁有大型GPU運算設施的用戶,絕大多數用戶的GPU記憶體配置,都難以充分滿足新一代LLM應用所需,都會有一定程度的記憶體擴展與卸載需求。 另一方面,LLM記憶體卸載解決方案不僅發展非常迅速,且類型十分多樣化,從開源的純軟體解決方案,到搭配各式外部裝置的方案,可因應不同用戶環境。 儘管將記憶體卸載應用於LLM訓練,仍有一些疑慮,不過,用於推論的KV快取這個面向,已普遍被認為是可行做法,特別是隨著Nvidia Dynamo推理架構的推出,KV快取卸載可望出現標準的應用框架,並吸引更多廠商投入。 特別是在這三個產品領域:SSD、高效能儲存,以及外接式CXL記憶體池,都已有廠商先行推出整合LLM KV快取卸載應用的產品套件,例如:群聯與華為都有基於SSD的KV快取卸載產品,WEKA、VAST Data與華為則已為旗下高效能儲存平臺整合KV快取功能,還有PEAK:AIO與Enfabrica基於CXL記憶體池的KV快取卸載方案等,未來很可能形成一股潮流,讓KV快取卸載成為這幾類產品普遍支援的功能。  LLM記憶體的兩大擴展形式   LLM記憶體的擴展分為兩條技術路線:「內部擴展」與「外部擴展」,前者類似HBM,與GPU在晶片層次整合,但改用容量更高,成本更低的記憶體顆粒。如上圖中SanDisk的HBF高頻寬快閃記憶體,號稱可提供8到16倍於HBM的容量。 後者則是以GPU外部的記憶體資源,來卸載GPU HBM記憶體的工作負載。如下圖中群聯的AIDAPTIV+方案,就可以透過CPU DRAM與SSD,作為補充HBM容量的額外記憶體空間,並且構成階層式的記憶體應用架構。圖片來源/Sandisk,Phison  高頻寬快閃記憶體的基本架構  Sandisk發展的高頻寬快閃記憶體(HBF),是HBM的快閃記憶體版本,基本架構類似,由堆疊在邏輯晶片上的16層快閃記憶體裸晶構成,堆疊的晶片透過矽穿孔(TSV)互連,再透過中介板連接GPU。主要訴求是透過快閃記憶體較低的成本與更高的儲存密度,在與HBM相當的成本與空間下,提供8到16倍容量。圖片來源/Sandisk  結合外部儲存的KV快取卸載  WEKA的增強型記憶體網格(AMG),是結合外部儲存設備的KV快取卸載解決方案,可將WEKA平行檔案系統平臺的NVMe SSD儲存空間,透過RDMA網路掛載到GPU伺服器,作為擴展的KV快取記憶體空間,從而加速推理工作。而透過GPUDirect直連與平行存取架構,WEAK宣稱AMG可提供不遜於GPU伺服器本機DRAM的頻寬與延遲表現。圖片來源/WEKA  LLM記憶體擴展與卸載的成效 我們以群聯的AIDAPTIV+為例,來看LLM記憶體擴展方案的成效。 下方第1張圖表顯示,透過AIDAPTIV+將記憶體負載卸載到CPU DRAM與SSD後,可讓配備較少GPU與HBM/GDDR記憶體的系統,執行原本跑不動的模型訓練工作。  圖片來源-Phison 1套只配備4張GPU、只有192 GB HBM的伺服器,僅依靠GPU GDDR記憶體時只能執行7B模型(70億參數)的訓練,或是容納140 GB大小的訓練資料集,而透過AIDAPTIV+記憶體卸載功能,便能執行13B與70B模型訓練,並容納原本需要6張與30張GPU才能容納的260 GB與1,400 GB訓練資料集。 不過,使用AIDAPTIV+也需付出效能方面的代價,群聯另一份資料顯示,與作為對比的8節點、30張GPU卡、1,440 GB GDDR記憶體系統,透過AIDAPTIV+的記憶體卸載輔助,可讓只有4節點、16張GPU與512GB GDDR的系統,或單節點、4張GPU與128GB GDDR系統,執行同樣的70B模型與10萬個Token訓練工作,硬體成本各自節省了37%與85%,但訓練耗時也分別增加50%與5.5倍。也就是以更長的訓練時間,換取節省GPU記憶體資源。 下方第2張圖表則顯示,對於LLM推論作業,透過AIDAPTIV+將KV快取卸載到CPU DRAM與SSD,可以加速推論、並擴大Token長度。  圖片來源-Phison 當測試系統單純依靠GPU執行推論時,受限於GDDR記憶體容量,KV快取只能保存有限的Token資料,當Token長度增加到512個以後,GPU產生第1個Token所需時間(TFTT)便顯著增加。而透過AIDAPTIV+,利用DRAM與SSD來存放更多KV快取時,Token長度即便增加到16384個,TFTT仍不致明顯增加,在2048個Token時的TFTT耗時能減少24倍。 此外,受限於GDDR容量,測試系統原本只能支援最大2,048個Token,而透過AIDAPTIV+的KV快取卸載,則能支援多達32,768個以上的Token,提高16倍。

-- gReader Pro 

【引進多元化記憶體架構,擴展LLM記憶體資源】打破LLM的記憶體容量瓶頸

【引進多元化記憶體架構,擴展LLM記憶體資源】打破LLM的記憶體容量瓶頸

https://www.ithome.com.tw/tech/170995

短短幾年,大型語言模型(Large Language Model,LLM)技術不斷突破,能處理的內容,可輸出的對話複雜度與篇幅,都有大幅增長,能一次輸入與處理數百、上千頁篇幅、包含複雜內容的資料,並生成長達數萬、數十萬字的對話。 但LLM能力的進展,是以消耗硬體資源為代價,運算參數越多,處理的文字量越大,消耗的GPU運算能力與記憶體空間也越大。 隨著LLM能力急速進步,這兩年開始出現硬體資源擴展速度,追不上LLM能力增長的情況,特別是記憶體容量。LLM的記憶體需求正以10倍、100倍的幅度不斷暴漲,但GPU供給的記憶體容量,僅以每世代最多提高50%的程度增加,促使需求與供給之間的落差不斷擴大,以致在LLM應用形成「記憶體容量瓶頸」。 當GPU記憶體空間不足時,GPU將被迫等待資料從緩慢的外部儲存裝置載入,或被迫重新計算無法保存在記憶體中的資料,不僅導致LLM運作遲緩,甚至停頓,也造成GPU運算能力與維運成本的浪費。 這樣的情況,也促成以打破記憶體容量瓶頸為目的的一系列新技術,以及新解決方案誕生。 我們在6月底的封面故事《AI硬體架構新變革:KV快取產品崛起》,先從KV快取的角度,檢視LLM的記憶體瓶頸問題,以及相關解決方案的發展。 不過,KV快取只涉及LLM應用中的推論部分,還不是LLM記憶體瓶頸問題的全貌,這次我們將從更完整的LLM記憶體應用需求出發,檢視相關產品技術現況,涵蓋LLM架構與規格演進,以及各式各樣的LLM記憶體擴充解決方案。 影響LLM記憶體需求的因素 在訓練與推論階段,影響LLM記憶體占用容量的因素有所不同。 在訓練階段,影響記憶體需求的主要因素包括:模型權重(Weights)、梯度(Gradients)、追蹤與保存計算過程狀態的啟動反應表徵(Activations),優化器狀態(Optimizer States)等。在推論階段,影響記憶體需求的因素,則有模型權重,以及KV快取等。 其中最基本的影響因素是模型權重,也就是模型的參數數量與其精度,其他因素如梯度與優化器狀態的記憶體占用量,都與模型參數的數量、精度直接相關,模型參數數量越多,使用的計算精度越高,占用記憶體容量也成比例增加。 而占用記憶體容量最大宗的來源,則是訓練階段的Activations,以及推論階段的KV快取這兩項因素。其中Activations的記憶體占用量與自注意力機制(Self-Attention),以及資料內容長度等相關,特別是內容長度的記憶體占用量,呈現平方增長規模(訓練32K長度內容所需記憶體容量,是訓練4K長度內容的64倍);而且,AI推理階段對KV快取記憶體的需求量,直接取決於模型的輸入與輸出內容長度。總的來說,兩者都與輸入與輸出Token數量呈正比關係,也就是LLM的上下文區間(Context Window)的大小,越大的上下文區間,可保存越多的輸入與輸出內容,但需要的記憶體空間也越大。 所以,我們透過觀察LLM參數總數,以及支援的上下文區間大小演變,就能看出LLM的記憶體需求增長趨勢。 急速膨脹的LLM記憶體需求 以OpenAI的GPT模型為例,在參數數量方面,2018年問世的GPT-1僅1.17億個參數,2019年的GPT-2就增加到15億個參數,增加超過12倍,2020年的GPT-3又一舉增加到1,750億個參數,較最早版本增加1,500倍,2022年的GPT-3.5也是1,750億個參數,此後OpenAI不再公開後續GPT版本的參數數量,不過外界估計2023年推出的GPT-4,約含有17,600億個參數,2025年發表的GPT-4.5則估計有40,000億到50,000億個參數,從這個數字來看,GPT模型參數數量,在8年內增加了3萬倍以上。如果只看2020年GPT-3以後情況,則到GPT-4.5為止的總參數量,也增加20到30倍。 在上下文區間方面,為了生成篇幅更長、複雜且更精確的對話內容,上下文區間的大幅提高是所有LLM共通趨勢。 例如,GPT-1只支援512個Token,接下來幾個版本都以倍數增加,GPT-2為1,024個Token,GPT-3為2,048個Token,GPT-3.5為4,096個Token;到了GPT-4一舉提高到32,768個Token,GPT-4 Turbo又增加到128,000個Token,250倍於最初的GPT-1,接下來GPT-4o與GPT-4.5都維持在128,000個Token。接著OpenAI為了因應其他LLM競爭,在2025年4月發表的GPT-4.1上,將支援的上下文區間提高到100萬個Token,相較於最早的GPT-1,提高至將近2,000倍,從GPT-3起算,也提高將近500倍。 我們再以開源的Meta Llama模型作為對照,相對於GPT,Llama一開始是以較少參數量,但仍能達到足夠效能為訴求,2023年初發表的最早版本Llama擁有652億個參數,只相當於GPT-3.5的1/3,比起同時期問世的GPT-4,參數數量更相差30倍。後來2023年中與2024年初推出的Llama 2與Llama 3,參數量也維持在700億個上下,不過2024年中推出的Llama 3.1,最大參數量增加到4,050億個,較最初版本提高6倍,2025年4月發布的Llama 4,目前最大參數量也維持在4,000億個(Maverick版),但另有1個擁有20,000億個參數的版本(Behemoth版)還未正式推出,相較於最初的Llama提高超過30倍,參數量已達OpenAI同時期推出GPT-4.5的同一層次。 在上下文區間方面,最初的Llama支援2,048個Token,只相當於早了3年推出的GPT-3,不過Meta追趕腳步很快,接下來Llama 2與Llama 3支援的上下文區間,依序成倍增加到4,096個與8,192個,然後Llama 3.1一舉提高到128,000個Token,追上同時期GPT-4o、GPT-4.5的水準。 緊接著Meta更在最新的Llama 4上,將上下文區間大幅提高到100萬個Token(Maverick版),以及1,000萬個Token(Scout版),分別較最初的Llama增加將近500倍與5,000倍,為當前LLM的最高規格。 總的來說,就算不計入2020年以前的早期版本LLM,只看2020年以後問世的較新版本LLM,在過去5年內,LLM的參數數量已從數百億到1千多億個,增加到數萬億個,幅度增長30倍以上。 這意味著:在其他條件不變的前提下,光是載入模型本身,需要的記憶體空間也跟著增加30倍以上;而LLM所能支援的上下文區間大小,也從2,048個Token提高到100萬個Token,最大還能達到1,000萬個Token,增長500倍到數千倍。也就是說,為了應付越來越長的上下文區間,訓練與推論過程中的記憶體耗用量,也將隨著膨脹數百倍至數千倍以上。 所以,要運行當前最新世代LLM,運算系統需要的記憶體容量,較4、5年前的LLM至少增加數十到數百倍以上。 MOE架構的記憶體需求 一些較晚推出的LLM,為了在擴大模型規模的同時,抑制運算資源的膨脹,而採用混合專家模型架構(Mixture of Expert model,MOE)。MOE架構LLM是由多個較小型專家單元(Expert)組成,對每個Token的計算只需啟用一部分專家單元與活躍(active)參數來進行,從而可大幅節省運算資源、時間與成本。 例如OpenAI在2023年推出的GPT-4,據稱就採用8 x 220B或16 x 110B的MOE架構,由8個220B規模(2,200億個參數),或16個110B規模(1,100億個參數)的專家單元組成,總參數量達到17,600億個,十倍於上一代GPT-3.5,但GPT-4並不同時啟用所有參數,據稱一次只需啟用2,800億個活躍參數,顯著減少了運算量。 類似的,Meta今年上半年發表的Llama 4也改用MOE架構,由16個或128個專家單元組成,雖然總參數量達到1,090億(Scout版)、4,000億個(Maverick版)與20,000億個(Behemoth版),但實際啟用參與運算的活躍參數僅170億個與2,880億個。 問題在於,MOE架構確實能顯著減少運算量,卻不能節省記憶體占用。MOE架構是透過路由器元件(router)來檢視輸入內容token,然後選擇交由合適的專家單元處理,每1個輸入token可能分別交由不同專家單元處理,而會選擇哪一個專家單元是無法預先確定的。所以,若非一開始就將所有專家單元的參數全部載入記憶體,一旦路由器選用到未將參數載入記憶體的專家單元,此時,就必須等待緩慢的底層儲存裝置載入參數,導致運作緩慢、反應遲鈍。 所以,為了確保訓練與推理作業的順暢,MOE架構LLM還是必須將全部參數載入記憶體,而不能只載入活躍參數,相較於既有的密集型(dense model)LLM,並沒有節省多少記憶體空間。 GPU的記憶體容量增長 看完需求端方面,也就是LLM記憶體需求增長狀況後,接下來我們檢視供給端方面,也就是GPU配置的記憶體容量增長情況。 以Nvidia的HGX資料中心級GPU為基準,過去7、8年來,每一代新產品大致都能提供較上一代多出30到50%的HBM記憶體容量,2017年推出的V100配置最大32GB的HBM2記憶體,2020年的A100則擁有80GB的HBM2e,2022年發表的H100最初也是配置80GB HBM2e(後來有升級到94GB HBM3的版本),2023年的H200增加到141GB HBM3e,2024年初與2025年初發表的B200(Blackwell)與B300(Blackwell Ultra),則分別配置192GB與288GB的HBM3e記憶體,除了A100到H100之間,記憶體容量增長有所停滯,其餘產品都維持近50%的記憶體容量增長,在8年內一共提升了9倍。 作為對照,我們再來看AMD Instinct系列GPU記憶體配置情況,從2020年底推出,擁有32GB HBM2記憶體的MI100起算,2021年底發表的MI200系列增加到128GB HBM2e,2023年底推出的MI300系列,又增加到192GB HBMe3。2024年底AMD推出MI325X,記憶體容量提升到256GB HBMe3。不久前於2025年6月發表的MI350,記憶體容量則進一步升級到288GB HBM3e,與Nvidia的B300同等。 總計過去5年來,AMD Instinct系列的記憶體配置容量也增長9倍,超過Nvidia同時期的GPU記憶體增長幅度——單論2020到2025年,Nvidia從H100到B300的GPU記憶體容量,其實僅提高3.6倍。 緊迫的GPU記憶體不足問題 無論是8年內提高9倍,或是5年內提高9倍,單從數字上來看,GPU記憶體容量都有相當可觀的增長,但問題在於,同一時期,LLM的記憶體需求卻是以數十倍、數百倍的幅度提高,顯然GPU的記憶體供給增長幅度,遠遠落後於LLM的記憶體需求。 LLM不僅需耗用大量運算力,同時也是記憶體密集型應用。事實上,在LLM訓練與推論過程中,要有效發揮GPU運算能力,不可或缺的前提,是GPU能即時地從記憶體饋入運算資料,也就是說,記憶體必須要有充足空間載入運算所需資料,並以足夠高的頻寬持續將資料饋入GPU,才能維持GPU的利用率,避免閒置。 所以,足夠的GPU記憶體容量與傳輸頻寬,是LLM應用的必要條件。 而隨著LLM複雜度與規模的急速膨脹,即便是較小規模版本的LLM,記憶體容量需求也相當可觀。 舉例來說,訓練一個80億參數量(8B)的小規模LLM模型,在FP16精度下,載入參數需要16 GB記憶體,即便消費型GPU的記憶體容量也足以承載,但加上參數梯度後,記憶體占用就會加倍,如果再加上Activations與自注意力機制等需求,總記憶體需求量會膨脹到上百至數百GB,甚至TB等級,即便高階的資料中心型GPU,也無法獨力承載這樣大的記憶體需求。 如果換成中、大規模模型,耗用的記憶體容量,將比前述數字高出10倍、數十倍。對於175B規模的GPT-3,或405B規模的Llama 3.1模型,在FP16精度下,光是載入參數就要占用350GB與800GB記憶體,加上訓練過程中的其他記憶體開銷,將會耗用數以TB計的記憶體。 而對於推論作業來說,GPU記憶體除了必須載入模型參數,由於當前LLM支援的上下文區間都達到128K個Token以上,KV快取的記憶體需求會隨著輸入、輸出內容長度增加而迅速膨脹,甚至會占用比模型參數本身高出數倍的記憶體空間。即便是中、小規模的LLM,當設定的輸入、輸出內容長度較長,或同時處理的資料批次較大時,推論時需要的KV快取記憶體往往也會達到數百GB等級或更多。 當GPU的記憶體空間不足時,將連帶造成LLM運作效率大幅下降,甚至停擺。GPU須時常等待資料從緩慢的外部儲存裝置載入到記憶體,導致GPU閒置,以及LLM運作遲緩;若記憶體容量不足以充分保存訓練與推論過程中的資料(如運算過程狀態或KV快取等),當後續需要這些資料時,GPU必須重新計算這些資料,造成大量GPU時間耗費在重新計算上。 「開源節流」克服LLM記憶體瓶頸 要克服LLM龐大的記憶體需求,以及GPU有限的記憶體供應量之間落差,方法不外乎「節流」與「開源」。 所謂「節流」,就是設法減少LLM訓練與推論過程中的記憶體耗用。而「開源」則是增加記憶體供給量。  節省記憶體消耗 過去數年來,開發商與研究人員已發展一系列技術,來節約LLM訓練與推論過程中占用的記憶體。 例如:在訓練階段可採取Activation重新計算(Recomputation),放棄保存部分運算過程狀態,以重新計算來換取節省記憶體占用。針對KV快取,常用作法則有:將高精度浮點數轉換為低精度,以損失精度換取節省記憶體的量化技術(Quantization),或在維持一定精度下,只保存部分KV快取值的稀疏技術(Sparsification);還有允許輸入內容不斷增加,而仍確保KV快取不致溢出GPU記憶體容量的滑動窗口技術等。 改進自注意力機制,也是節約KV快取記憶體占用的一大重點方向,例如:藉由共用KV快取、節省記憶體占用的多查詢注意力(Multi Query Attention,MQA)與分組查詢注意力(Grouped Query Attention,GQA),可以在非連續的記憶體空間,保存KV快取資料,減少記憶體浪費的分頁式PagedAttention技術,以及能夠壓縮注意力輸入、只儲存潛在向量,藉此大幅減少KV快取的多頭潛在注意力機制(Multi-head Latent Attention,MLA)等。 前述技術能在訓練與推論過程中的不同環節,節約數十百分比到數倍的記憶體消耗,但本質上其實是不同面向的折衷與妥協,是以精度、運算時間、模型能力等方面為代價,來換取節省記憶體,並非適用所有應用方式,必須視情況取捨。 另一方面,各式記憶體節約技術的成效,又會被LLM持續進化所帶來的記憶體需求增長所抵銷。為追求更完善的資訊處理與生成能力,LLM的規模依舊持續擴大,新一代LLM還藉由引進多模式學習技術(Multimodal learning),已不限於處理文字訊息,而能處理文字、圖像、語音等多元資料內容,也帶來不斷膨脹的記憶體需求。 因此,僅僅依靠軟體或運算架構來節約記憶體耗用的「節流」手段,已不足以面對記憶體需求不斷成長的壓力,必須搭配擴展記憶體資源的積極「開源」手段。  增加記憶體資源 既然單一GPU的記憶體,不足以承載LLM的訓練與推論工作,那麼最最簡單、粗暴的解決辦法,就是使用更多GPU組成叢集,藉此匯聚更大的記憶體空間。 多GPU叢集是AI與LLM應用的標準硬體架構,當前GPU伺服器主流配置是8路組態,8組GPU之間透過NVLink或Infinity Fabric之類專屬高速介面相互直連。以當前資料中心級GPU規格來說,1臺8路GPU伺服器可匯聚1到2 TB的HBM記憶體,足以載入大規模LLM的數千億個參數,考慮到訓練與推論過程中的其他記憶體開銷,這樣的記憶體規格可能還是不敷所需,可再加入第2臺、第3臺,或更多GPU伺服器,進一步擴展LLM可用的HBM記憶體容量。 顯而易見的,這種作法存在兩大副作用,一是缺乏成本效益,二是未精準對應實際需求。 當瓶頸發生在「記憶體容量不足」,而非「GPU運算能力不足」時,引進更多GPU,確實能獲得更多HBM記憶體,但考慮到GPU昂貴的成本,這是非常沒有成本效益的記憶體瓶頸解決手段,形成浪費。 兩種解決手段 只依靠LLM軟體架構與演算法改進手段,所得到的節約記憶體效果,不足以應付持續增長中的記憶體需求;但透過增加GPU數量,為LLM提供更多HBM記憶體資源,又欠缺成本效益。 所以,更合理的手段,是為LLM尋求與GPU「脫鉤」的記憶體資源擴展方式,不需為了增加記憶體而引進1整組GPU,而可單獨、靈活地擴展記憶體。 這也是當前大多數LLM記憶體擴展解決方案的發展方向——從GPU外部,提供可獨立擴展更大規模的記憶體空間,藉此將原本完全由GPU記憶體承擔的工作負載,卸載到GPU以外的記憶體裝置上,如CPU DRAM,或透過網路介接的NVMe快閃儲存設備,代價是這些裝置的傳輸頻寬,明顯不如與GPU直接整合的HBM,算是以較低頻寬,換取不被GPU綑綁的記憶體擴展能力。 另一些廠商則重視傳輸頻寬更甚於擴展能力,沿用HBM與GPU的晶片整合架構,但改用儲存密度高出數倍的NAND快閃記憶體,來取代基於DRAM的HBM,這便是目前發展中高頻寬快閃記憶體(High Bandwidth Flash,HBF),擁有相當於HBM的高傳輸頻寬,但容量高出HBM十多倍,同樣能為LLM提供更大記憶體空間,但不具備與GPU脫鉤的擴展靈活性。 基於外部記憶體裝置的擴展方案,以及直接與GPU整合的高頻寬快閃記憶體(HBF),構成當前LLM記憶體擴展解決方案的兩大類型。 接下來我們便從這兩條技術路線出發,檢視這領域當前的發展。  LLM總參數數量增長趨勢 自LLM問世以來,模型總參數量便以指數爆發性增長,連帶導致記憶體需求量暴漲。 以最具代表性的OpenAI GPT為例,自2018年推出的GPT-1起,到2025年初發表的GPT-4.5,模型包含的參數量在8年內增加3萬倍以上。如果只看2020年以後,從GPT-3到GPT-4.5的總參數量也增加20到30倍。對照開源LLM最具代表性的Meta Llama,總參數數量也在兩年半內增加30倍。 當LLM的總參數量增加30倍,意味著要以相同精度將參數載入記憶體,需要的記憶體空間也將增加30倍。連帶的,訓練與推論過程中其他需求耗用的記憶體量,也會成比例增加。*GPT-4以後的參數數量為外界估計,非官方公布數字。 **含20,000個參數的Behemoth版Llama 4,尚未正式推出。 資料來源:iThome整理,2025年8月  LLM上下文區間增長趨勢 越大的上下文區間(Context Window),可讓LLM容納更多輸入與輸出內容,保存更多計算資料,顯著提高處理與生成長篇幅內容的能力,但連帶也需消耗更多記憶體空間。 以Open AI的GPT為例,自最早的GPT-1,到今年初發表的GPT-4.1,支援的上下文區間從512個Token提高到100萬個Token,提高將近2,000倍,從GPT-3起算,也提高將近500倍。而開源領域的Meta Llama,更從Llama的2,048個Token提高到Llama 4的1,000萬個Token,增長近5,000倍。 隨著上下文區間大幅提高,耗用的記憶體空間也將以成百、上千倍的比例大幅增加。資料來源:iThome整理,2025年8月  GPU記憶體容量的增長趨勢 過去7、8年來,資料中心級GPU的HBM記憶體容量,大致以每一世代提升30%到50%的幅度增長,以Nvidia HGX系列GPU為例,從V100到B300的記憶體容量足足提高9倍,對照AMD的Instinct系列GPU,從MI100到最新的MI350,在5年內也提高9倍,都稱得上相當顯著的增長。 問題在於,同一時期內,LLM的記憶體需求是以數十倍、數百倍幅度暴漲,遠超過GPU記憶體容量提升幅度,需求與供給之間出現巨大的落差,形成LLM應用中的記憶體容量瓶頸。資料來源:iThome整理,2025年8月

-- gReader Pro 

【引進多元化記憶體架構,擴展LLM記憶體資源】打破LLM的記憶體容量瓶頸

【引進多元化記憶體架構,擴展LLM記憶體資源】打破LLM的記憶體容量瓶頸

https://www.ithome.com.tw/tech/170995

短短幾年,大型語言模型(Large Language Model,LLM)技術不斷突破,能處理的內容,可輸出的對話複雜度與篇幅,都有大幅增長,能一次輸入與處理數百、上千頁篇幅、包含複雜內容的資料,並生成長達數萬、數十萬字的對話。 但LLM能力的進展,是以消耗硬體資源為代價,運算參數越多,處理的文字量越大,消耗的GPU運算能力與記憶體空間也越大。 隨著LLM能力急速進步,這兩年開始出現硬體資源擴展速度,追不上LLM能力增長的情況,特別是記憶體容量。LLM的記憶體需求正以10倍、100倍的幅度不斷暴漲,但GPU供給的記憶體容量,僅以每世代最多提高50%的程度增加,促使需求與供給之間的落差不斷擴大,以致在LLM應用形成「記憶體容量瓶頸」。 當GPU記憶體空間不足時,GPU將被迫等待資料從緩慢的外部儲存裝置載入,或被迫重新計算無法保存在記憶體中的資料,不僅導致LLM運作遲緩,甚至停頓,也造成GPU運算能力與維運成本的浪費。 這樣的情況,也促成以打破記憶體容量瓶頸為目的的一系列新技術,以及新解決方案誕生。 我們在6月底的封面故事《AI硬體架構新變革:KV快取產品崛起》,先從KV快取的角度,檢視LLM的記憶體瓶頸問題,以及相關解決方案的發展。 不過,KV快取只涉及LLM應用中的推論部分,還不是LLM記憶體瓶頸問題的全貌,這次我們將從更完整的LLM記憶體應用需求出發,檢視相關產品技術現況,涵蓋LLM架構與規格演進,以及各式各樣的LLM記憶體擴充解決方案。 影響LLM記憶體需求的因素 在訓練與推論階段,影響LLM記憶體占用容量的因素有所不同。 在訓練階段,影響記憶體需求的主要因素包括:模型權重(Weights)、梯度(Gradients)、追蹤與保存計算過程狀態的啟動反應表徵(Activations),優化器狀態(Optimizer States)等。在推論階段,影響記憶體需求的因素,則有模型權重,以及KV快取等。 其中最基本的影響因素是模型權重,也就是模型的參數數量與其精度,其他因素如梯度與優化器狀態的記憶體占用量,都與模型參數的數量、精度直接相關,模型參數數量越多,使用的計算精度越高,占用記憶體容量也成比例增加。 而占用記憶體容量最大宗的來源,則是訓練階段的Activations,以及推論階段的KV快取這兩項因素。其中Activations的記憶體占用量與自注意力機制(Self-Attention),以及資料內容長度等相關,特別是內容長度的記憶體占用量,呈現平方增長規模(訓練32K長度內容所需記憶體容量,是訓練4K長度內容的64倍);而且,AI推理階段對KV快取記憶體的需求量,直接取決於模型的輸入與輸出內容長度。總的來說,兩者都與輸入與輸出Token數量呈正比關係,也就是LLM的上下文區間(Context Window)的大小,越大的上下文區間,可保存越多的輸入與輸出內容,但需要的記憶體空間也越大。 所以,我們透過觀察LLM參數總數,以及支援的上下文區間大小演變,就能看出LLM的記憶體需求增長趨勢。 急速膨脹的LLM記憶體需求 以OpenAI的GPT模型為例,在參數數量方面,2018年問世的GPT-1僅1.17億個參數,2019年的GPT-2就增加到15億個參數,增加超過12倍,2020年的GPT-3又一舉增加到1,750億個參數,較最早版本增加1,500倍,2022年的GPT-3.5也是1,750億個參數,此後OpenAI不再公開後續GPT版本的參數數量,不過外界估計2023年推出的GPT-4,約含有17,600億個參數,2025年發表的GPT-4.5則估計有40,000億到50,000億個參數,從這個數字來看,GPT模型參數數量,在8年內增加了3萬倍以上。如果只看2020年GPT-3以後情況,則到GPT-4.5為止的總參數量,也增加20到30倍。 在上下文區間方面,為了生成篇幅更長、複雜且更精確的對話內容,上下文區間的大幅提高是所有LLM共通趨勢。 例如,GPT-1只支援512個Token,接下來幾個版本都以倍數增加,GPT-2為1,024個Token,GPT-3為2,048個Token,GPT-3.5為4,096個Token;到了GPT-4一舉提高到32,768個Token,GPT-4 Turbo又增加到128,000個Token,250倍於最初的GPT-1,接下來GPT-4o與GPT-4.5都維持在128,000個Token。接著OpenAI為了因應其他LLM競爭,在2025年4月發表的GPT-4.1上,將支援的上下文區間提高到100萬個Token,相較於最早的GPT-1,提高至將近2,000倍,從GPT-3起算,也提高將近500倍。 我們再以開源的Meta Llama模型作為對照,相對於GPT,Llama一開始是以較少參數量,但仍能達到足夠效能為訴求,2023年初發表的最早版本Llama擁有652億個參數,只相當於GPT-3.5的1/3,比起同時期問世的GPT-4,參數數量更相差30倍。後來2023年中與2024年初推出的Llama 2與Llama 3,參數量也維持在700億個上下,不過2024年中推出的Llama 3.1,最大參數量增加到4,050億個,較最初版本提高6倍,2025年4月發布的Llama 4,目前最大參數量也維持在4,000億個(Maverick版),但另有1個擁有20,000億個參數的版本(Behemoth版)還未正式推出,相較於最初的Llama提高超過30倍,參數量已達OpenAI同時期推出GPT-4.5的同一層次。 在上下文區間方面,最初的Llama支援2,048個Token,只相當於早了3年推出的GPT-3,不過Meta追趕腳步很快,接下來Llama 2與Llama 3支援的上下文區間,依序成倍增加到4,096個與8,192個,然後Llama 3.1一舉提高到128,000個Token,追上同時期GPT-4o、GPT-4.5的水準。 緊接著Meta更在最新的Llama 4上,將上下文區間大幅提高到100萬個Token(Maverick版),以及1,000萬個Token(Scout版),分別較最初的Llama增加將近500倍與5,000倍,為當前LLM的最高規格。 總的來說,就算不計入2020年以前的早期版本LLM,只看2020年以後問世的較新版本LLM,在過去5年內,LLM的參數數量已從數百億到1千多億個,增加到數萬億個,幅度增長30倍以上。 這意味著:在其他條件不變的前提下,光是載入模型本身,需要的記憶體空間也跟著增加30倍以上;而LLM所能支援的上下文區間大小,也從2,048個Token提高到100萬個Token,最大還能達到1,000萬個Token,增長500倍到數千倍。也就是說,為了應付越來越長的上下文區間,訓練與推論過程中的記憶體耗用量,也將隨著膨脹數百倍至數千倍以上。 所以,要運行當前最新世代LLM,運算系統需要的記憶體容量,較4、5年前的LLM至少增加數十到數百倍以上。 MOE架構的記憶體需求 一些較晚推出的LLM,為了在擴大模型規模的同時,抑制運算資源的膨脹,而採用混合專家模型架構(Mixture of Expert model,MOE)。MOE架構LLM是由多個較小型專家單元(Expert)組成,對每個Token的計算只需啟用一部分專家單元與活躍(active)參數來進行,從而可大幅節省運算資源、時間與成本。 例如OpenAI在2023年推出的GPT-4,據稱就採用8 x 220B或16 x 110B的MOE架構,由8個220B規模(2,200億個參數),或16個110B規模(1,100億個參數)的專家單元組成,總參數量達到17,600億個,十倍於上一代GPT-3.5,但GPT-4並不同時啟用所有參數,據稱一次只需啟用2,800億個活躍參數,顯著減少了運算量。 類似的,Meta今年上半年發表的Llama 4也改用MOE架構,由16個或128個專家單元組成,雖然總參數量達到1,090億(Scout版)、4,000億個(Maverick版)與20,000億個(Behemoth版),但實際啟用參與運算的活躍參數僅170億個與2,880億個。 問題在於,MOE架構確實能顯著減少運算量,卻不能節省記憶體占用。MOE架構是透過路由器元件(router)來檢視輸入內容token,然後選擇交由合適的專家單元處理,每1個輸入token可能分別交由不同專家單元處理,而會選擇哪一個專家單元是無法預先確定的。所以,若非一開始就將所有專家單元的參數全部載入記憶體,一旦路由器選用到未將參數載入記憶體的專家單元,此時,就必須等待緩慢的底層儲存裝置載入參數,導致運作緩慢、反應遲鈍。 所以,為了確保訓練與推理作業的順暢,MOE架構LLM還是必須將全部參數載入記憶體,而不能只載入活躍參數,相較於既有的密集型(dense model)LLM,並沒有節省多少記憶體空間。 GPU的記憶體容量增長 看完需求端方面,也就是LLM記憶體需求增長狀況後,接下來我們檢視供給端方面,也就是GPU配置的記憶體容量增長情況。 以Nvidia的HGX資料中心級GPU為基準,過去7、8年來,每一代新產品大致都能提供較上一代多出30到50%的HBM記憶體容量,2017年推出的V100配置最大32GB的HBM2記憶體,2020年的A100則擁有80GB的HBM2e,2022年發表的H100最初也是配置80GB HBM2e(後來有升級到94GB HBM3的版本),2023年的H200增加到141GB HBM3e,2024年初與2025年初發表的B200(Blackwell)與B300(Blackwell Ultra),則分別配置192GB與288GB的HBM3e記憶體,除了A100到H100之間,記憶體容量增長有所停滯,其餘產品都維持近50%的記憶體容量增長,在8年內一共提升了9倍。 作為對照,我們再來看AMD Instinct系列GPU記憶體配置情況,從2020年底推出,擁有32GB HBM2記憶體的MI100起算,2021年底發表的MI200系列增加到128GB HBM2e,2023年底推出的MI300系列,又增加到192GB HBMe3。2024年底AMD推出MI325X,記憶體容量提升到256GB HBMe3。不久前於2025年6月發表的MI350,記憶體容量則進一步升級到288GB HBM3e,與Nvidia的B300同等。 總計過去5年來,AMD Instinct系列的記憶體配置容量也增長9倍,超過Nvidia同時期的GPU記憶體增長幅度——單論2020到2025年,Nvidia從H100到B300的GPU記憶體容量,其實僅提高3.6倍。 緊迫的GPU記憶體不足問題 無論是8年內提高9倍,或是5年內提高9倍,單從數字上來看,GPU記憶體容量都有相當可觀的增長,但問題在於,同一時期,LLM的記憶體需求卻是以數十倍、數百倍的幅度提高,顯然GPU的記憶體供給增長幅度,遠遠落後於LLM的記憶體需求。 LLM不僅需耗用大量運算力,同時也是記憶體密集型應用。事實上,在LLM訓練與推論過程中,要有效發揮GPU運算能力,不可或缺的前提,是GPU能即時地從記憶體饋入運算資料,也就是說,記憶體必須要有充足空間載入運算所需資料,並以足夠高的頻寬持續將資料饋入GPU,才能維持GPU的利用率,避免閒置。 所以,足夠的GPU記憶體容量與傳輸頻寬,是LLM應用的必要條件。 而隨著LLM複雜度與規模的急速膨脹,即便是較小規模版本的LLM,記憶體容量需求也相當可觀。 舉例來說,訓練一個80億參數量(8B)的小規模LLM模型,在FP16精度下,載入參數需要16 GB記憶體,即便消費型GPU的記憶體容量也足以承載,但加上參數梯度後,記憶體占用就會加倍,如果再加上Activations與自注意力機制等需求,總記憶體需求量會膨脹到上百至數百GB,甚至TB等級,即便高階的資料中心型GPU,也無法獨力承載這樣大的記憶體需求。 如果換成中、大規模模型,耗用的記憶體容量,將比前述數字高出10倍、數十倍。對於175B規模的GPT-3,或405B規模的Llama 3.1模型,在FP16精度下,光是載入參數就要占用350GB與800GB記憶體,加上訓練過程中的其他記憶體開銷,將會耗用數以TB計的記憶體。 而對於推論作業來說,GPU記憶體除了必須載入模型參數,由於當前LLM支援的上下文區間都達到128K個Token以上,KV快取的記憶體需求會隨著輸入、輸出內容長度增加而迅速膨脹,甚至會占用比模型參數本身高出數倍的記憶體空間。即便是中、小規模的LLM,當設定的輸入、輸出內容長度較長,或同時處理的資料批次較大時,推論時需要的KV快取記憶體往往也會達到數百GB等級或更多。 當GPU的記憶體空間不足時,將連帶造成LLM運作效率大幅下降,甚至停擺。GPU須時常等待資料從緩慢的外部儲存裝置載入到記憶體,導致GPU閒置,以及LLM運作遲緩;若記憶體容量不足以充分保存訓練與推論過程中的資料(如運算過程狀態或KV快取等),當後續需要這些資料時,GPU必須重新計算這些資料,造成大量GPU時間耗費在重新計算上。 「開源節流」克服LLM記憶體瓶頸 要克服LLM龐大的記憶體需求,以及GPU有限的記憶體供應量之間落差,方法不外乎「節流」與「開源」。 所謂「節流」,就是設法減少LLM訓練與推論過程中的記憶體耗用。而「開源」則是增加記憶體供給量。  節省記憶體消耗 過去數年來,開發商與研究人員已發展一系列技術,來節約LLM訓練與推論過程中占用的記憶體。 例如:在訓練階段可採取Activation重新計算(Recomputation),放棄保存部分運算過程狀態,以重新計算來換取節省記憶體占用。針對KV快取,常用作法則有:將高精度浮點數轉換為低精度,以損失精度換取節省記憶體的量化技術(Quantization),或在維持一定精度下,只保存部分KV快取值的稀疏技術(Sparsification);還有允許輸入內容不斷增加,而仍確保KV快取不致溢出GPU記憶體容量的滑動窗口技術等。 改進自注意力機制,也是節約KV快取記憶體占用的一大重點方向,例如:藉由共用KV快取、節省記憶體占用的多查詢注意力(Multi Query Attention,MQA)與分組查詢注意力(Grouped Query Attention,GQA),可以在非連續的記憶體空間,保存KV快取資料,減少記憶體浪費的分頁式PagedAttention技術,以及能夠壓縮注意力輸入、只儲存潛在向量,藉此大幅減少KV快取的多頭潛在注意力機制(Multi-head Latent Attention,MLA)等。 前述技術能在訓練與推論過程中的不同環節,節約數十百分比到數倍的記憶體消耗,但本質上其實是不同面向的折衷與妥協,是以精度、運算時間、模型能力等方面為代價,來換取節省記憶體,並非適用所有應用方式,必須視情況取捨。 另一方面,各式記憶體節約技術的成效,又會被LLM持續進化所帶來的記憶體需求增長所抵銷。為追求更完善的資訊處理與生成能力,LLM的規模依舊持續擴大,新一代LLM還藉由引進多模式學習技術(Multimodal learning),已不限於處理文字訊息,而能處理文字、圖像、語音等多元資料內容,也帶來不斷膨脹的記憶體需求。 因此,僅僅依靠軟體或運算架構來節約記憶體耗用的「節流」手段,已不足以面對記憶體需求不斷成長的壓力,必須搭配擴展記憶體資源的積極「開源」手段。  增加記憶體資源 既然單一GPU的記憶體,不足以承載LLM的訓練與推論工作,那麼最最簡單、粗暴的解決辦法,就是使用更多GPU組成叢集,藉此匯聚更大的記憶體空間。 多GPU叢集是AI與LLM應用的標準硬體架構,當前GPU伺服器主流配置是8路組態,8組GPU之間透過NVLink或Infinity Fabric之類專屬高速介面相互直連。以當前資料中心級GPU規格來說,1臺8路GPU伺服器可匯聚1到2 TB的HBM記憶體,足以載入大規模LLM的數千億個參數,考慮到訓練與推論過程中的其他記憶體開銷,這樣的記憶體規格可能還是不敷所需,可再加入第2臺、第3臺,或更多GPU伺服器,進一步擴展LLM可用的HBM記憶體容量。 顯而易見的,這種作法存在兩大副作用,一是缺乏成本效益,二是未精準對應實際需求。 當瓶頸發生在「記憶體容量不足」,而非「GPU運算能力不足」時,引進更多GPU,確實能獲得更多HBM記憶體,但考慮到GPU昂貴的成本,這是非常沒有成本效益的記憶體瓶頸解決手段,形成浪費。 兩種解決手段 只依靠LLM軟體架構與演算法改進手段,所得到的節約記憶體效果,不足以應付持續增長中的記憶體需求;但透過增加GPU數量,為LLM提供更多HBM記憶體資源,又欠缺成本效益。 所以,更合理的手段,是為LLM尋求與GPU「脫鉤」的記憶體資源擴展方式,不需為了增加記憶體而引進1整組GPU,而可單獨、靈活地擴展記憶體。 這也是當前大多數LLM記憶體擴展解決方案的發展方向——從GPU外部,提供可獨立擴展更大規模的記憶體空間,藉此將原本完全由GPU記憶體承擔的工作負載,卸載到GPU以外的記憶體裝置上,如CPU DRAM,或透過網路介接的NVMe快閃儲存設備,代價是這些裝置的傳輸頻寬,明顯不如與GPU直接整合的HBM,算是以較低頻寬,換取不被GPU綑綁的記憶體擴展能力。 另一些廠商則重視傳輸頻寬更甚於擴展能力,沿用HBM與GPU的晶片整合架構,但改用儲存密度高出數倍的NAND快閃記憶體,來取代基於DRAM的HBM,這便是目前發展中高頻寬快閃記憶體(High Bandwidth Flash,HBF),擁有相當於HBM的高傳輸頻寬,但容量高出HBM十多倍,同樣能為LLM提供更大記憶體空間,但不具備與GPU脫鉤的擴展靈活性。 基於外部記憶體裝置的擴展方案,以及直接與GPU整合的高頻寬快閃記憶體(HBF),構成當前LLM記憶體擴展解決方案的兩大類型。 接下來我們便從這兩條技術路線出發,檢視這領域當前的發展。  LLM總參數數量增長趨勢 自LLM問世以來,模型總參數量便以指數爆發性增長,連帶導致記憶體需求量暴漲。 以最具代表性的OpenAI GPT為例,自2018年推出的GPT-1起,到2025年初發表的GPT-4.5,模型包含的參數量在8年內增加3萬倍以上。如果只看2020年以後,從GPT-3到GPT-4.5的總參數量也增加20到30倍。對照開源LLM最具代表性的Meta Llama,總參數數量也在兩年半內增加30倍。 當LLM的總參數量增加30倍,意味著要以相同精度將參數載入記憶體,需要的記憶體空間也將增加30倍。連帶的,訓練與推論過程中其他需求耗用的記憶體量,也會成比例增加。*GPT-4以後的參數數量為外界估計,非官方公布數字。 **含20,000個參數的Behemoth版Llama 4,尚未正式推出。 資料來源:iThome整理,2025年8月  LLM上下文區間增長趨勢 越大的上下文區間(Context Window),可讓LLM容納更多輸入與輸出內容,保存更多計算資料,顯著提高處理與生成長篇幅內容的能力,但連帶也需消耗更多記憶體空間。 以Open AI的GPT為例,自最早的GPT-1,到今年初發表的GPT-4.1,支援的上下文區間從512個Token提高到100萬個Token,提高將近2,000倍,從GPT-3起算,也提高將近500倍。而開源領域的Meta Llama,更從Llama的2,048個Token提高到Llama 4的1,000萬個Token,增長近5,000倍。 隨著上下文區間大幅提高,耗用的記憶體空間也將以成百、上千倍的比例大幅增加。資料來源:iThome整理,2025年8月  GPU記憶體容量的增長趨勢 過去7、8年來,資料中心級GPU的HBM記憶體容量,大致以每一世代提升30%到50%的幅度增長,以Nvidia HGX系列GPU為例,從V100到B300的記憶體容量足足提高9倍,對照AMD的Instinct系列GPU,從MI100到最新的MI350,在5年內也提高9倍,都稱得上相當顯著的增長。 問題在於,同一時期內,LLM的記憶體需求是以數十倍、數百倍幅度暴漲,遠超過GPU記憶體容量提升幅度,需求與供給之間出現巨大的落差,形成LLM應用中的記憶體容量瓶頸。資料來源:iThome整理,2025年8月

-- gReader Pro 

〈GFE〉- Gemini生成個人化插畫故事書Storybook

〈GFE〉- Gemini生成個人化插畫故事書Storybook

https://tinywhitesir.blogspot.com/2025/09/gfe-geministorybook.html

 1. Storybook目前只能提供給18歲以上的帳號使用 2. 每次生成的AI故事書目前為10頁的數量 3. 目前仍尚處於"實驗性"階段,可支援45種不同的語言Google不久前發佈了Gemini更新後的新功能-Storybook(官方介紹)故名思義它就是一本故事書,而且是一本有聲的AI故事書不過它不像引導式學習還是Canvas一樣在對話視窗下方就可以找到它而是在Gemini的『探索Gem』功能中可以發現它的蹤跡點進去Gem裡面,就可以看到 Storybook的功能,下方有文字說明:根據指定的主題、目標讀者年齡 (如有) 和希望的圖畫風格 (如有),創作專屬繪本給大人或小孩。所以Storybook的功能其實很簡單,就是幫大家生成一個故事的繪本!而且重點是生成的繪本可以像Canvas一樣透過對話來修改它不管是故事的劇情、繪本的風格以及旁白都可以客製化讓你短短一分鐘就可以變身成為兒童繪本的出版作家!至於要怎麼使用呢?就讓我們繼續看下去吧...Step 1:Storybook的功能在Gem裡面可以發現它,如果想要快速的找到它的話,可以將它釘選後,就會出現在Gemini首頁左上角的Gem選單中!Step 2:要使用Storybook有兩種方式,一種是直接在Storybook的Gem當中下指令生成;另一種方式則是在Gemini的對話視窗中,直接下『幫我創作一本.....的故事書』,也是可以直接請Gemini生成故事書喔!方法一:直接在Storybook的Gem模式中輸入提示詞方法二:直接在Gemini對話視窗中下指令生成故事書,會在生成結果的下方出現建立故事書的選項Step 3:和其他的Gem使用方式一樣,我們可以上傳附件檔案當作是生成故事書的參考資料Step 4:接下來我們可以給予提示詞,請Gemini幫我們生成AI故事書Storybook,Gemini就會在短短的時間裡頭幫我們生成一本長度為10頁的有聲的故事書喔!(※註:教育帳號目前無法分享故事書喔!)在生成的界面上,我們可以看到有些操作控制項。我們可以『手動設定翻頁』、『全螢幕顯示』、『列印故事書』、『共用故事書』、『設定朗讀方式』等圖:我們也可以將故事書列印輸出成PDF檔或是可以直接輸出成紙本Step 5:生成後的AI有聲故事書,可以直接播放請AI幫我們唸出來喔!而且在唸的時候也會自動翻頁,在分享給小孩子閱讀的時候語音也非常的自然喔!基本上,Storybook的操作非常直覺也簡單如果覺得生成的結果不滿意,都可以繼續看Gemini進行迭代問答修正譬如說故事書的劇情啦、還是插畫的風格等等當然目前還是有一些使用上的限制像是無法針對某一頁的內容進行編輯修改、重新下指令會生成一本新的故事書等老師們在使用上要稍微適應一下,但不至於造成太大的影響。因此,這邊舉幾個我覺得可以在教學上使用的例子供大家參考:1. 提供相關的情緒背景生成故事書,以SEL的教育方法引導學生進行自我覺察。2. 提供一個故事的開頭,請Gemini幫你完成後續的故事創作;或是透過既有的故事來進行改編。3. 將文學詩集請Gemini生成Storybook,讓原本生硬難懂的文言文、詩詞絕句變成圖像化的故事書加深學生理解印象。4. 將科學概念或是歷史事件,透過Storybook的呈現,協助學生理解抽象的概念或是史實。5. 設計情境式對話的內容,透過Storybook的呈現,協助學生練習英語詞彙及單字,透過故事書的呈現來訓練情境式英文口語對話。好啦!以上大概是針對Storybook的基本介紹老師們也可以動手在自己的Gemini玩玩看相信這個功能融入自己的學科中一定能夠創造出不同的使用方式的。但需要留意的是,目前Storybook仍屬於實驗性的階段大家可以從後方的(實驗)字樣看的出來如果真的要使用在教學層面,還是建議教師要扮演好「引導者」的角色既然是AI工具,難免還是會出現幻覺或是偏見的內容因此,工具再好用,還是回歸到教育者本身的引導和管理教導學生如何「負責任」的使用AI,讓工具成為輔助學習而不是取代學習的角色才是使用AI工具最重要也是最急迫的事情喔! 😃

-- gReader Pro 

中國AI生成內容新規上路,要求平臺與用戶標註來源與技術資訊

中國AI生成內容新規上路,要求平臺與用戶標註來源與技術資訊

https://www.ithome.com.tw/news/170952

中國對人工智慧生成內容的規範進入正式實施階段,從9月1日開始《人工智慧生成合成內容標識辦法》要求規範生成式AI服務的業者以及內容傳播平臺,必須在文字、圖片、音訊、影片與虛擬場景等各類生成內容上,加註來源標示並留下技術性資訊。根據外媒South China Morning Post報導,抖音、微信和小紅書等平臺都已經推出措施來符合人工智慧內容標示的新規範。 新規要求雙層標示,顯式標示必須直接呈現在內容中,像是文字開頭或結尾的提示、音訊片段的語音提示、圖片上的清楚標註,或影片播放介面的顯眼符號,而隱式標示則嵌入檔案的後設資料,包含生成來源、服務提供者代碼與內容編號等,並建議同步加入數位浮水印。這些隱藏資訊主要提供平臺與監管單位在後續檢驗與追蹤時使用。 內容平臺被賦予更多義務,當上傳內容的檔案中繼資料標明為人工智慧生成,平臺必須在發布頁面加上提示,要是來源無隱式標示,但使用者聲明為生成內容,平臺同樣需要註記。如果沒有標示也無聲明,但系統偵測到生成痕跡,仍需標示為「疑似」生成內容提醒使用者,且平臺還須把相關資訊寫回檔案後設資料,確保後續內容傳播的可追溯性。 除了《人工智慧生成合成內容標識辦法》,中國政府同時發布了強制性國家標準《網路安全技術人工智慧生成合成內容標識方法》,並提供服務供應商編碼規則的配套指南。技術標準的重點在於,不同格式檔案中嵌入屬性資訊的方法,以及規範生成內容的標記方式,讓業者在實作時有明確依據。 中國並非唯一要求人工智慧生成內容標註的國家,歐盟於2024年通過的《人工智慧法案》已對文字、圖片、音訊與影片的生成內容訂下透明義務,要求部署者在內容中揭露人工智慧的參與。西班牙則希望進一步推動高額罰則,擬對未正確標示的企業處以最高3,500萬歐元或全球營收7%的罰鍰。 美國目前沒有聯邦層級的強制標示義務,2023年科技公司與白宮簽署自願性承諾,承諾投入數位浮水印等機制標示生成內容。部分州針對選舉深度偽造立法,但也出現如加州違憲爭議並被法院暫時禁止之案例。

-- gReader Pro 

Make Graph 免費圖表製作工具:簡單、安全的數據視覺化解決方案

Make Graph 免費圖表製作工具:簡單、安全的數據視覺化解決方案

https://free.com.tw/makegraph-app/

簡單、安全且高效的數據視覺化利器 Make Graph 是一款很實用的免費圖表製作工具,可以在瀏覽器建立美麗的圖表,以視覺化方式呈現數據,或將資料直接轉換為令人驚嘆的圖表。這項服務無需下載任何應用程式,也不用註冊或登入帳號就能使用,更重要的是在過程中資料只保留在瀏覽器,服務不會存取或是儲存資料,提供更好的隱私與安全性。  支援多種專業圖表類型 這項服務支援超過八種專業的圖表類型,包括:  長條圖(Bar Charts) 折線圖(Line Charts) 圓餅圖(Pie Charts) 散布圖(Scatter Plots) 雷達圖(Radar Charts) 漏斗圖(Funnel Charts) 盒鬚圖(Box Plots) 熱圖(Heat Maps) 文字雲(Word Clouds) 地圖(Maps)  簡單易用的圖表模板與配色調整 Make Graph 提供一些預設的圖表模板(Templates),可將看到的圖表快速帶入編輯器,透過簡單修改數值就能夠生成圖表,使用上非常簡單,不需要太多摸索時間。本身也支援調整圖表主題配色,讓生成的圖表和品牌或展示風格更有一致性。 提升易讀性的視覺紋理效果 亦可啟用「Aria Decal」模式為圖表元素加入視覺紋理效果,以提供更好的易讀性,即使是色覺差異的使用者在查看圖表時也能正確閱讀。 更重要的是它可以正確顯示中文,生成圖片不會無法顯示或產生亂碼等問題。 在 Make Graph 製作的圖表最終可匯出、保存為 PNG 和 SVG 格式,選擇性轉換為透明背景,也能依照需求讓圖片的尺寸變大,整體來說是個非常實用、安全且有助於提高生產力的免費工具。 網站資訊  網站名稱:Make Graph網站鏈結:https://makegraph.app/  使用教學 操作步驟 開始使用與模板探索 開啟 Make Graph 網站後可以從首頁看到特色及功能介紹,如果想看看這項服務可以做出哪些圖表,建議直接前往圖表模板頁面,這裡收錄不少使用 Make Graph 製作出來的專業圖表,也能直接帶入修改。 從首頁點選「Start Creating」就會開啟圖表編輯功能,沒有中文介面,不過操作上並不會太困難,而且前面介紹有提到所有資料都只會在使用者瀏覽器上,不會被服務端保存或取得。  從編輯器左下角可以匯入數據資料,支援 CSV、Excel(.xlsx / .xls)格式。   靈活的數據輸入與範例資料 無論是否匯入資料,都可從編輯器左上角來調整數據,即使輸入中文也能正確顯示。 此外,Make Graph 也提供各種「範例」可快速匯入資料,例如:單一系列、多系列、時間序列、大型資料集、百分比資料、地理資料、世界人口、按國家計算的 GDP 等,手邊沒有數據資料但又想測試一下可以善用這項功能。   調整圖表配色與主題 編輯器右側主要是一些和圖表相關的編輯選項,例如調整佈景主題配色,Make Graph 預設有多種圖表配色,也提供深色模式,使用於暗色投影片就會更適合。   快速切換圖表類型 使用「Chart Type」選項快速切換不同的圖表類型,很棒的是在切換後無需重新匯入資料,所有數據依然都會保存在使用者的瀏覽器上,這個工具支援的圖表包括:長條圖、折線圖、圓餅圖、散布圖、雷達圖、漏斗圖、盒鬚圖、熱圖、文字雲、地圖。    啟用視覺紋理效果(選用) 啟用「Aria Decal」模式後會對圖表上的元素加入視覺紋理效果,在區分不同資料時更清楚,對於色覺差異的使用者來說也有幫助,直接切換開啟關閉就能對照前後差異。   自訂圖表細節 Make Graph 也提供使用者自訂圖表的各項細節,例如呈現的方向、寬度、間距、圓角等。  就連圖表元件的填充顏色都可以自訂,預設是以「主題」配色為主(也就是上面選擇的 Theme 顏色),若有需要也可調整成透明或自訂色碼。   匯出與保存圖表 最後從右上角點選「Export」即可將圖表匯出、保存,支援 PNG 和 SVG 兩種格式,也能將背景設定為透明色或是調整圖片大小。  下圖就是使用 Make Graph 製作的圖表範例,中文部分也能正常顯示,如果想看更多圖表,建議可以直接前往網站的模板頁面,收錄大約 20 種不同類型的顯示效果,幫助使用者快速上手喔!    我的心得 對於需要快速製作簡易圖表的使用者來說,Make Graph 是一個不可多得的免費工具,無需額外安裝軟體,直接在瀏覽器就能使用,更重要的是相關資料不會離開電腦,也不會被保存,提供更安全、隱私的使用環境。 製作後的圖表也相當有專業感,可自訂功能很多,亦可正確顯示中文,無論是要製作成一般圖片或生成 SVG 向量圖都很好用,內建許多範例圖表可供參考,帶入模板後修改後即可完成。

-- gReader Pro 

跨平台桌寵軟體 XR Animator,讓MMD角色在桌面動起來!支援動態捕捉

跨平台桌寵軟體 XR Animator,讓MMD角色在桌面動起來!支援動態捕捉

https://ivonblog.com/posts/xr-animator/

XR Animator是一個支援Linux、Windows、macOS的開源桌寵軟體,可以在桌面放3D模型,讓他與你打招呼。內建動態捕捉技術,能夠透過電腦鏡頭,讓3D模型跟著你的身體移動,能夠作為實況主直播時候的虛擬形象工具,算是一種廉價版VTuber吧。我個人認為,這個軟體可以作為Live2DViewerEX和Desktop Mate的Linux版替代品。因為這二個軟體無法使用Steam Proton轉譯執行,而XR Animator是原生的Electron程式,效能比較好。此外,XR Animator提供網頁版,能夠在Android與iOS手機上使用。透過AR技術,讓3D人物出現在真實世界,跟她們互動!1. 準備3D模型#XR Animator的模型支援.pmx與.vrm格式的3D模型。動作檔則是.vmd與.fbx格式。要取得模型,最好的來源就是到ニコニ立体下載了。模型下載後不需要解壓縮,請維持.zip檔的形式。2. 安裝XR Animator#到Github,依照作業系統下載壓縮檔。例如Ubuntu就是將檔案解壓縮之後,使用指令賦予執行權限:cd "XR-Animator_v0.30.0_linux-x64/XR Animator - electron-v33.2.0-linux-x64_SA/"  chmod +x electron 接著點兩下electron啟動程式。3. 基本用法#初始啟動的時候,將含有.pmx的.zip檔拖曳進視窗,載入模型。或者直接按Start,載入內建模型。現在可以跟人物互動了,比如點一下腳部就會跌倒~ 將鏡頭轉到頭部就會給你一個吻。點二下重置鏡頭。右鍵拖曳視窗位置。點下方的姿勢按鈕能夠切換許多動作~還能將動作儲存起來。系統匣的選單也有很多光影選項能開,不過這就會額外耗費顯示卡計算資源了,沒有獨顯得別開太高級的光影選項。點選Always on Top將視窗永遠置頂。4. 設定動作捕捉#可以使用攝影機或者傳入單張照片進行動態捕捉,讓3D人物做出想要的姿勢。VRM動作捕捉的資料能夠與其他軟體共享,不過似乎限定Windows系統使用的樣子。我這邊只有要用上半身動態捕捉,因此先點一下XR Animator的工具列,按姿勢,調整為上半身動態捕捉。然後再按一下動態捕捉,設定身體部分這樣人物就會根據你的臉部表情與手部動作跟著作動了。5. 在手機上使用網頁版AR#因為需要用到智慧型手機的AR功能,所以Android手機最好用Chrome,iPhone則是得用Safari。用手機打開這個網頁:https://sao.animetheme.com/XR_Animator.html載入模型的用法跟電腦版一樣,點一下左上角的手機符號開啟AR模式。 讓鏡頭掃描一下平面,放置人物,二指縮放 現在你能夠跟人物互動了~!小心走太近會撞倒她。 工具列裡面有接球遊戲,至少要站離模型5公尺遠才能玩!

-- gReader Pro 

IETF 提出草案:網頁標頭應註明是否由人工智慧生成,否則未來「用AI教AI」問題將更嚴重

IETF 提出草案:網頁標頭應註明是否由人工智慧生成,否則未來「用AI教AI」問題將更嚴重

https://www.techbang.com/posts/125169-ai-generated-content-ietf-draft

網路內容真假難辨?IETF提案網站揭露是否使用人工智慧生成內容,標示模型與來源,助你判斷資訊真偽。這項AI披露機制,有助減少AI資訊污染問題。當你在網路上讀到一篇新聞、文章、甚至一則產品評論,你知道它到底是人寫的,還是 AI 生成的嗎? 面對 AI 內容越來越多、真假難辨的問題,負責網際網路標準制定的 IETF(Internet Engineering Task Force)近日提出一份草案,建議未來網站在回應標頭(HTTP Header)中,主動揭露是否使用了人工智慧生成內容,並提供相關模型與來源資訊。 為什麼需要這種「AI 披露」? 根據草案內容,目前許多 AI 生成的文章仍存在品質不穩、事實錯誤甚至「幻覺」(AI 胡亂編造)等問題,尤其當這些內容被其他 AI 系統再度抓取、引用時,就可能產生連鎖性的錯誤資訊流通。 例如:AI 模型 A 寫了一篇錯誤的文章 → AI 模型 B 抓去當資料使用 → 更多人從 B 得到錯誤內容。 這對於像是網路搜尋引擎、資料爬蟲、AI 使用者代理(user agent)、以及像「網路檔案館」(Internet Archive)這類歸檔機構而言,就會造成判斷與儲存上的困難與負擔。 標準草案怎麼規定? 草案建議可在 HTTP 標頭中加入 AI-Disclosure 標籤,說明下列資訊: AI-Disclosure: mode=ai-originated;  model="gpt-4";  provider="OpenAI";  reviewed-by="editorial-team";  date=@1745286896  其中可包含:   是否由 AI 生成(ai-originated)   使用哪個模型(如 GPT-4)   提供者(OpenAI)   是否有人審核(如 editorial-team)   時間戳記   這項做法並非強制,而是「自願揭露」機制。換言之: 有標籤=內容由 AI 生成 沒標籤=不代表不是 AI 寫的,只是沒說明 下一步會成為標準嗎? 目前該草案仍在提案階段,預計討論至 2025 年 11 月 1 日,若獲得業界與各方同意,將有機會正式成為網際網路的標準之一,未來各大網站、媒體、平台都可以選擇性實作這項規範。 這項機制若落實,將有助於讀者判斷資訊真偽,亦可減少 AI 間相互「誤學」所導致的資訊污染問題。  加入T客邦Facebook粉絲團

-- gReader Pro 

清华与东北大学联合推出 UltraRAG 2.0

清华与东北大学联合推出 UltraRAG 2.0

https://www.oschina.net/news/369915

清华大学 THUNLP 实验室、东北大学 NEUIR 实验室与 OpenBMB 及 AI9Stars 联合发布了 UltraRAG2.0,这是首个基于 Model Context Protocol(MCP)架构设计的检索增强生成(RAG)框架。 该框架致力于简化 RAG 系统的构建过程,使科研人员可以在短时间内实现复杂的多阶段推理系统。UltraRAG2.0的亮点在于用户只需通过编写 YAML 文件,即可轻松声明复杂的逻辑,如串行、循环和条件分支,从而显著减少代码量,降低实现的门槛。 在当前的 RAG 发展趋势中,许多系统逐渐融入了自适应知识组织、多轮推理及动态检索等复杂特性,代表项目包括 DeepResearch 和 Search-o1。然而,这些复杂特性也给开发者带来了高昂的工程成本,制约了新想法的快速迭代与复现。UltraRAG2.0应运而生,它通过将 RAG 的核心组件封装为独立的 MCP 服务器,实现了功能的灵活调用和扩展。 具体而言,与以往的实现方式相比,UltraRAG2.0在代码量上大幅减少。例如,经典方法 IRCoT 的官方实现需要近900行代码,而使用 UltraRAG2.0只需约50行代码就能完成同等功能。其中一半的代码是用于流程编排的 YAML 伪代码,极大降低了开发门槛。框架支持通过简洁的声明式方式来构建多阶段推理流程,使得复杂的推理逻辑不再需要冗长的手动编码。  UltraRAG2.0还支持动态检索、条件判断及多轮交互等高级功能,科研人员可以在短时间内搭建出高性能的实验平台,满足复杂多跳问题的需求。其性能较传统的 Vanilla RAG 提升约12%。该系统的设计旨在让研究者在工程实现方面节省时间和精力,将更多的注意力放在算法创新和实验设计上。 此外,UltraRAG2.0的 MCP 架构允许不同模块间的无缝复用,并支持模块的灵活扩展和接入,方便科研人员快速适配新的模型和算法。这一设计极大提升了系统开发的效率和可复现性。

-- gReader Pro 

一个视频速通Nano Banana,解锁10种邪修玩法

一个视频速通Nano Banana,解锁10种邪修玩法

https://www.youtube.com/watch?v=7775oNO2wXM

https://www.youtube.com/watch?v=7775oNO2wXM值得閱讀的理由 快速掌握「Nano Banana」這款近期熱門的AI繪圖工具的免費使用方法,省去摸索時間。 一次性學習十種實用且令人驚豔的進階玩法,包括3D手辦、多圖融合、服裝搭配及故事生成等,極大拓展創作潛力。 瞭解如何利用提示詞(Prompt)精準控制AI生成結果,有效提升個人或商業專案的視覺呈現品質。 摘要 Nano Banana 使用方法概覽 這段影片中,作者首先介紹了近期備受歡迎的AI繪圖模型「Nano Banana」,它能夠生成3D手辦、卡通貼紙和人物換裝等各式圖片,效果令人驚艷。作者承諾將分享如何在國內免費使用此工具,並解鎖十種創意玩法。作者也提及已準備好相關的提示詞文檔,方便觀眾直接操作。 隨後,作者詳細介紹了三種使用「Nano Banana」模型的方法。第一種是透過Google的AS Studio,選擇「Juggernaut XL 2.5 Flash」模型直接輸入提示詞即可生成圖片,這是作者最推薦的方式。第二種是利用API調用「Juggernaut XL 2.5 Flash Image」模型,並特別指出在OpenRouter平台有提供免費額度,讓使用者能更靈活地進行開發。第三種方式則是在像Cozze這樣的平台上,將「Nano Banana」模型整合到個人的工作流程中進行使用。 Nano Banana 的十種邪修玩法 在介紹完使用方法後,作者便進入了這段影片的核心內容,即「Nano Banana」的十種邪修玩法,每一種都極具創意和實用性。 1. 3D卡通形象與3D手辦圖 作者首先展示了如何將人物圖片轉換成3D卡通形象,特別適合製作Q版卡通,只需替換提示詞中的特定元素即可。接著,他介紹了近期最受歡迎的玩法:將人物圖片生成3D手辦圖,強調背景和人物越簡單,效果越好。 2. 多圖融合與等軸模型 第三種玩法是多圖融合,使用者可以一次性上傳多張圖片(如人物、配飾、車輛),讓AI將其組合成一張最終的圖片,甚至可以讓兩個人物同框。第四種玩法是創建等軸模型,例如上傳建築圖片,AI便能生成精緻的高樓等軸模型。 3. 自定義動作姿勢與每日穿搭(OOTD) 第五種玩法是自定義動作姿勢,透過上傳兩個人物圖片及一張姿勢參考圖,即可讓人物擺出指定的動作。第六種是「今日的OOTD」(Outfit of the Day),上傳人物圖片後,Nano Banana能自動生成該人物的穿搭元素。 4. 一鍵修圖與像素風3D圖標 第七種是便捷的「一鍵修圖」功能,對於不理想的照片,只需簡單提示即可讓其變得生動精彩,甚至能替換照片中的衣服。第八種玩法則是製作像素風格的3D圖標,透過上傳一張簡潔的參考圖,便能生成個性化的像素風圖標,還能應用於Emoji的改造。 5. 髮型設計與完整故事生成 第九種是髮型設計,當使用者不確定該剪什麼髮型時,上傳人物頭像後,AI會直接生成多種髮型圖片供選擇。最後,第十種玩法是「一次生成完整的故事」,可以上傳兩個人物圖片,並指定AI生成12張包含故事情節的圖片,甚至這些圖片還能進一步用於生成AI影片。 總結 作者在影片結尾再次強調了「Nano Banana」出色的生成效果,並指出它在眾多AI模型中表現優異。他鼓勵所有感興趣的朋友都能親自上手嘗試這款工具,體驗其強大的功能。最後,他預告下次再見,並提及了頻道名稱「IT咖啡館」。 ============= https://www.youtube.com/watch?v=7775oNO2wXM最近的nano Banana实在太火了,而且效果真的太炸裂了,今天总结下实用的玩法分享。

-- gReader Pro 

大里掩埋場遠眺可見半山腰裸置垃圾 綠議員憂惡夢

大里掩埋場遠眺可見半山腰裸置垃圾 綠議員憂惡夢

https://www.cna.com.tw/news/aloc/202509020121.aspx

民進黨台中市議會黨團2日召開記者會,指出大里掩埋場垃圾嚴重堆置,直接暴露陽光下,未依照規定覆土,市府規劃2042年才能全數清運。中央社記者趙麗妍攝 114年9月2日(中央社記者趙麗妍台中2日電)民進黨台中議會黨團今天指出,大里掩埋場目前垃圾暫置量逾34萬噸,自快速道路上遠眺,就可看到半山腰裸露堆置垃圾;環保局表示,加速焚化廠汰舊換新,提升去化量能。民進黨台中市議會黨團今天召開記者會,總召王立任指出,大里掩埋場中的垃圾量已嚴重超載,市長盧秀燕上任後不願處理,如今台中市境內掩埋場即將全數達到滿載,市府規劃2042年才有可能全數清運完成,台中市民被迫承受長達18年垃圾惡夢。他指出,從民眾提供的現場畫面可看到大里掩埋場垃圾嚴重堆積,直接暴露陽光下,未依規定覆土,須等延宕多年的文山焚化廠汰舊換新工程完工後,才有可能在2042年清運完成。市議員林德宇說,大里掩埋場在2017年垃圾暫置量是1309噸、2018年是7082噸,2019年盧秀燕上任市長第一年來到3萬7000多噸,盧秀燕上任6年多,目前已暫置逾34萬噸;從74號快速道路上遠眺大里山區,可看見露天裸露掩埋場現況,相當突兀。議員張芬郁也提到,依據環保局估算,在文山焚化爐興建期間,大里掩埋場每年增加7萬噸,最高會達到84萬噸;李天生、蔡耀頡、謝家宜都認為,大里掩埋場6年內堆積三十幾萬噸,成為大里唯一一座山,市府用掩蓋、暫存等名詞掩飾,欺騙民眾。台中市環保局透過文字稿回覆,大里掩埋場並無滿載情形,依規作為焚化廠年度歲修時,垃圾暫時調度去化的替代管道之一;當焚化爐歲修結束後,即可將掩埋場中垃圾運回焚燒,有進有出。環保局說明,文山焚化廠汰舊換新招商在8月25日截標,共3家廠商投標,預期2029年文山焚化廠可完成首座新爐建造,提升處理效率;另外,也透過加強廚餘回收、樹枝堆肥及破袋檢查等措施,使2024年度垃圾焚化缺口較2023年每天234噸減少至208噸,並持續與外縣市合作,將大里掩埋場垃圾回運焚化廠去化。(編輯:陳仁華)1140902民進黨台中市議員林德宇2日指出,大里掩埋場垃圾嚴重堆置,車子行經74號快速道路,遠眺都能看見半山腰垃圾場。中央社記者趙麗妍攝 114年9月2日

-- gReader Pro 

韓國議員提交「完全轉蛋」營利模式禁止法案 在過度助長賭博的批評聲浪中強化消費者保護

韓國議員提交「完全轉蛋」營利模式禁止法案 在過度助長賭博的批評聲浪中強化消費者保護

https://gnn.gamer.com.tw/detail.php?sn=291584

 韓國執政黨共同民主黨黨內代表金炳基(音譯)議員近日提交了一項法案,旨在禁止「完全轉蛋(英文名稱為:Complete Gacha」營利模式的法案。這項以《遊戲產業振興法》部分修正案形式提出的法案,核心內容包括禁止操作機率型道具的中獎率,以及全面禁止「完全轉蛋」方式。   所謂「完全轉蛋」是指為了獲得最終結果,玩家難以預測實際需要投入多少金錢的抽卡模式;一旦中途放棄,之前投入的金額將全數淪為沉沒成本。該營利模式長期以來被批評會刺激玩家的賭博心理,誘導過度消費。   金炳基議員表示:「遊戲具有即使在銷售後,賣方也能隨意更改商品內容的特性,因此僅憑現有的《電商法》等法律難以徹底保障消費者權益。我們未來將透過考量市場獨特性的細緻保護措施,保護國民權益。」   金炳基議員     事實上,在第 21 屆國會時,民主黨議員柳東秀(音譯)也曾提出過類似的禁止「Complete Gacha」法案,但因任期屆滿自動廢案。當時國會文化體育觀光委員會的專門委員曾指出:「若要從根本上禁止『完全轉蛋』,必須在立法政策上承認其危害性已嚴重到等同賭博遊戲的程度,因此需先行進行事前調查及實證研究。」   主管機關文化體育觀光部也曾表明以法律禁止遊戲公司的營利模式,必須慎重檢討。因此未來在國會審查過程中,勢必會展開深入討論。公平交易委員會自去年起,已多次查獲國內遊戲公司進行機率操作並予以制裁。值得一提的是,該營利模式最早發源的日本目前早已明文禁止。此次修正案除禁止「完全轉蛋」外,還包含多項使用者保護措施,主要條款如下:   正確資訊提供義務:遊戲公司必須向使用者提供關於付費遊戲內容的正確資訊。    完整退款保障:若因遊戲公司過失導致需退款或回收付費內容,須明確保障使用者能全額退還購買金額。    政府調查權限賦予:若有合理根據懷疑遊戲公司公告的機率資訊與實際不符,文化體育觀光部長有權直接進行調查。    次要內容與服務中斷時的保護強化:針對以遊戲貨幣等獲得的次要內容,遊戲公司必須公告可供交換、退款等保護措施,並在服務終止時制度化補償。

-- gReader Pro 

台公共媒體啟動「AIChatbot」 建置聊天機器人提供可信資訊【涉己新聞】

台公共媒體啟動「AIChatbot」 建置聊天機器人提供可信資訊【涉己新聞】

https://news.pts.org.tw/article/768428

台公共媒體啟動「AIChatbot」 建置聊天機器人提供可信資訊【涉己新聞】  聊天機器人 媒體 資訊 新聞 ... 民主國家 啟動                              發布時間:2025/9/1 19:31 更新時間:2025/9/1 20:58     黃姵涵 陳柏諭 吳嘉堡 張梓嘉 歐芸榕 謝政霖  / 綜合報導      AI科技相當便利,不過假訊息也跟著升級,資訊真假難辨,台灣公共媒體今(1)日代表齊聚,宣布啟動「AIChatbot 合作計畫」,將共同建置提供可信資訊的AI聊天機器人,以2026年底為完成目標。另外,在9月1日記者節這天,有超過20家媒體共同發起成立「台灣網路新聞自律聯盟」,希望提升新聞品質與公信力。 AI科技日新月異帶來挑戰與機遇,為讓AI發揮正面潛能,台灣公共媒體代表齊聚,共同宣布啟動「公共媒體 AIChatbot 合作計畫」,將集結台灣具公信力的媒體機構,共同建置提供可信資訊的AI聊天機器人。公廣集團董事長胡元輝表示,「最大的不同就是,其他的聊天機器人會把網路上,不管你是正確、不正確,好的、不好的資訊,全部作為它解釋的來源,可是這個可信資訊的AI聊天機器人,只會限定在我們公共媒體所提供的資料。」此項計畫將結合公廣集團、中央社、央廣、原視等公共媒體的新聞資料庫,以及政府、NGO 等可授權的可信資料,以2026年底為完成目標。團隊也邀請中研院資訊所古倫維教授擔任技術顧問,未來將建置供社會大眾免費使用的大眾版聊天機器人,以及供專業工作者使用的專業版聊天機器人。中研院資訊所教授古倫維指出,「對我們來說的話,我們就是一步一步地把它做完,包括說先從文字開始再到影像聲音。」而在9月1日記者節這天,有超過20家媒體共同發起成立「台灣網路新聞自律聯盟」,結合媒體內部治理與公民外部監督,建立多方治理平台。台灣網路新聞自律聯盟副召集人莊勝鴻表示,「新聞自律了,我是不是很多新聞我都不能做?其實不是的,每個媒體可以從新聞自律做起,讓台灣的新聞媒體可以重生。」數位發展部長林宜敬指出,「民主國家不能沒有言論自由,但是民主國家也不能放任錯假訊息流竄,以至於危害到整個國家的安全,最好的方法就是有一個健康自由而且自律的媒體生態。」聯盟強調,透過制度化的自律原則、透明的申訴與更正機制等,提升新聞品質和公信力,促進媒體和民眾之間的良性溝通。   姜筑/編輯    台灣 公廣集團 聯盟 記者節 ... 網路 假訊息 數位發展部 中研院 言論自由

-- gReader Pro 

3 local LLM workflows that actually save me time

3 local LLM workflows that actually save me time

https://www.xda-developers.com/local-llm-workflows-that-actually-save-me-time/

Local large language models are having a moment. Much as I love online AI models like Perplexity, I care about my data and have been using local AI models to boost productivity. Over the past few months, I've been running these models entirely on my own machine, and not a massively powerful one at that, and it has completely transformed how I work. Using a local model via Ollama instead of relying on cloud services has many benefits. Chief among those, of course, is offline access and privacy. While there are many ways to amplify your productivity using AI, here are three ways I'm using a local LLM to boost mine. Knowledge management  Your personal research assistant      This one's a no-brainer, but one of my favorite use cases is as an accompaniment to my personal knowledge management app. While I'm big on Obsidian and Notion, a local LLM can go a long way towards helping you manage that information better. For example, I make a lot of meeting notes, articles, research documents, and, usually, I'd have to go through these manually. One document at a time. Now, I can feed all the documents into a tool like TL/DW or Obsidian Copilot and get it to process them using a large local language model. This lets me create summaries, pull out action points, and even have a conversation with my own documents for better learning. It's basically a cheat sheet for creating Cliff Notes, and I love it. Of course, there are the usual benefits, like retaining ownership of all the data, not just my documents, but also all the summarization data created by the LLM. This is data that I cannot afford to have on the internet as training data, so public LLMs are out of the question. Having my own LLM also lets me play around with formats, like creating flashcards for learning or getting them to create a summarized digest of multiple research papers that I can read up on using my Kindle. It's the best personal research assistant I've ever had. Content management  Saving time without losing control and context        The second workflow is perhaps the most controversial. As a journalist, I'm vehemently opposed to the idea of using AI slop. But I do feel that AI has a place in modern workflows to accelerate productivity. Drafting a boilerplate contract email? Get the local LLM to create a template for you. Need to create an outline for talking points to cover in a pitch deck? LLM to the rescue. Or how about asking it to poke holes in a write-up? Grammar checks. Ideating headlines. Making sure the best SEO practices have been followed. These are all tasks that an LLM excels at. It doesn't need creativity; it just needs the model to hit check marks. As in the case of knowledge management, this is original data that I do not want on the internet, so a local LLM works best. Yes, a local LLM is nowhere near as good at text generation, but I don't need it to be. On average, I save at least ten to fifteen minutes in research and basic outlining because I can get the LLM to tell me if I've hit all the relevant talking points in my first draft. Home automation  When Home Assistant gets an AI brain        I love Home Assistant. It's the center of my smart home. But as powerful as Home Assistant is, it truly comes into its own when you pair it with an LLM. With recent updates, Home Assistant has made the task incredibly easy, which means I can get it to generate everything from routines to automations. When in a pinch, I've asked the local LLM to create a boilerplate YAML file that I can further work with for my dashboard. This is data I absolutely do not want exposed to the internet, so the ability to connect with an Ollama instance on my computer offers me both features and privacy. It's a win-win situation in my books. Adding a local LLM is the ultimate productivity hack  Of course, there are dozens of other ways to use local LLMs to your advantage, but for me, these three use-cases have stood out the most to accelerate my productivity. It's transformed how I handle everything from my personal life to my home and my work. I'm now able to gather information faster than I ever could, and wrangle that into a form that is best suited for the task at hand. The local LLM stands by me as I write and pokes holes in my work to make it better, while also offering basic grammar checking to make my editor's life easier. And to make my life easier, it taps into my smart home to offer more contextual advice. All of which to say, adding a local LLM to my daily setup has been the best productivity boost I could've hoped for. Not only am I faster than ever, but it also gives me more time and mental space to focus on everything else beyond work.

-- gReader Pro 

苹果开源两大模型家族:FastVLM 与 MobileCLIP2

苹果开源两大模型家族:FastVLM 与 MobileCLIP2

https://www.oschina.net/news/369583

苹果在 Hugging Face 上开源了 FastVLM 和 MobileCLIP2 两大模型家族:  FastVLM 是一种视觉语言模型(VLM),专为高分辨率图像设计,旨在减少 token 输出并压缩编码时间,可以高效地理解图像和文本之间的关系。 MobileCLIP2 是 CLIP 模型的轻量化、移动端优化版本,专注于在手机或边缘设备上进行高效推理。  FastVLM系列包含0.5B、1.5B、7B三个参数规模,全部基于新提出的FastViTHD混合视觉编码器,专为高分辨率图像输出更少token、压缩编码时间。FastVLM-7B在DocVQA达到93.2,在ScienceQA达到96.7,表现领先。 MobileCLIP2系列同样上线,提供相应 Hugging Face Collections 页面。 CVPR 2025论文《FastVLM: Efficient Vision Encoding for Vision Language Models》已公开,引用信息随模型仓库一并提供。 https://huggingface.co/collections/apple/fastvlm-68ac97b9cd5cacefdd04872e https://huggingface.co/spaces/apple/fastvlm-webgpu https://huggingface.co/collections/apple/mobileclip2-68ac947dcb035c54bcd20c47

-- gReader Pro 

[AI]教你做 AI 3D人物公仔圖,免費還無限次數

[AI]教你做 AI 3D人物公仔圖,免費還無限次數

https://dacota.tw/blog/post/gemini-ai-3d

繼AI吉卜力風格,最近各大社群又吹起 AI個人手辦照,就是下圖這種把自己照片變成3D模型還帶包裝盒的照片。怎麼做呢? 接下來請按圖施工  [AI]教你做 AI 3D人物公仔圖,免費還無限次數 1. 先準備好個人全身照,並在手機安裝Google Gemini,電腦版直接使用網頁即可 Android | iOS | 電腦版   2. 上傳照片,輸入以下提示詞 繪製圖中角色的1/7比例的商業化手辦,寫實風格,真實環境,手辦放在電腦桌上,手辦使用圓形透明壓克力底座,底座上無文字,電腦螢幕裡的內容為該手辦的Zbrush建模過程,電腦營幕旁放著印有原畫的BANDAI風格的玩具包裝盒 記得選擇圖像   2. 等候一下,自動生成圖片 稍等一下就自動生成,速度非常快!   再拿啦啦隊~一粒試試,也一樣很快就生成出來 不過偶爾會出現無圖片的狀況,可能是線上人數過多,多試幾次就好   另外,社群上也有很多正妹會貼跟風照 但網友詢問都會回覆要微信掃碼安裝APP,那個就不建議去安裝喔~ 用Gemini 即可免費使用,免費還無限次數 The post [AI]教你做 AI 3D人物公仔圖,免費還無限次數 first appeared on 雲爸的私處.

-- gReader Pro 

UltraRAG 2.0 发布,基于 MCP 架构设计的开源 RAG 框架

UltraRAG 2.0 发布,基于 MCP 架构设计的开源 RAG 框架

https://www.oschina.net/news/369659

清华大学 THUNLP 实验室、东北大学 NEUIR 实验室、OpenBMB 与 AI9Stars 联合推出 UltraRAG 2.0 (UR-2.0),这是首个基于 Model Context Protocol (MCP) 架构设计的开源 RAG 框架。 UltraRAG 2.0 框架示意图:  这一设计让科研人员只需编写 YAML 文件,就可以直接声明串行、循环、条件分支等复杂逻辑,从而以极低的代码量快速实现多阶段推理系统。 UltraRAG 2.0 亮点一览  组件化封装:将 RAG 的核心组件封装为标准化的独立 MCP Server; 灵活调用与扩展:提供函数级 Tool 接口,支持功能的灵活调用与扩展; 轻量流程编排:借助 MCP Client,建立自上而下的简洁化链路搭建;与传统框架相比,UltraRAG 2.0 显著降低了复杂 RAG 系统的技术门槛与学习成本,让研究者能够将更多精力投入到实验设计与算法创新上,而不是陷入冗长的工程实现。  ➤ 相关链接 Github 链接:https://github.com/OpenBMB/UltraRAG 项目主页:https://openbmb.github.io/UltraRAG/ 教程文档:https://ultrarag.openbmb.cn/ 开源数据集:https://huggingface.co/datasets/UltraRAG/UltraRAG_Benchmark

-- gReader Pro 

Cloudflare 宣布“AI爬取控制”功能正式 GA

Cloudflare 宣布"AI爬取控制"功能正式 GA

https://www.oschina.net/news/369240/cloudflare-ai-crawl-control

Cloudflare 全新的"AI爬取控制"(AI Crawl Control)功能已正式 GA,所有付费用户现可通过该功能对 AI 爬虫发送可自定义的 402 Payment Required 状态码,而非简单封禁。  过去,内容创作者只能二选一:彻底阻止爬虫,或放任其免费抓取。AI Crawl Control 在仪表板内提供"阻断并附带消息"选项,用户可填写如"如需内容,请邮件联系partnerships@yoursite.com或致电1-800-LICENSE"或"高级内容请访问api.yoursite.com/pricing"等文本。返回的 402 响应将包含该自定义信息,为潜在授权谈判开辟直接沟通渠道。 Cloudflare 披露,平台每天已为用户返回逾十亿次 402 状态码,显示市场对"先谈条件后抓取"模式的强烈需求。未来,团队计划进一步在 402 响应中嵌入内容价值、更新频率、授权条款等结构化数据,同时继续推进 Pay Per Crawl 功能,为内容方提供按次计费的自动化变现基础设施。

-- gReader Pro 

國教院中研院研究 近7成國三生曾用生成式AI

國教院中研院研究 近7成國三生曾用生成式AI

https://www.cna.com.tw/news/ahel/202509010071.aspx

根據國家教育研究院與中央研究院合作研究顯示,近7成國三生曾使用生成式AI(人工智慧)。(中央社檔案照片)(中央社記者許秩維台北1日電)根據國教院與中研院合作研究顯示,近7成國三生曾使用生成式AI(人工智慧),學校教使用生成式AI普及率達5成,而學生用生成式AI用途包括寫作業、聊天、找資料或製作圖片等。國家教育研究院今天發布新聞稿表示,國教院「台灣學生成就長期追蹤評量資料庫(TASAL)」與中央研究院「台灣數位世代青少年的成長歷程追蹤研究(TIGPS)」合作,根據長期追蹤調查研究,94.2%9年級學生(國三生)知道什麼是生成式AI(如ChatGPT等),顯示生成式AI在國中生群體中有極高知名度。調查顯示,約69%9年級生有使用經驗,以每週使用1到2次居多(46%);學校普及率方面,53.2%9年級學生表示學校老師有教如何使用生成式AI,顯示約一半學校已開始相關教學,但普及率須再提升。至於9年級學生使用生成式AI主要用途,包括寫作業、各國語文翻譯、查找資料、製作圖片、影片、學語言、聊天與其他應用,顯示9年級學生已將生成式AI整合到學習與日常生活多個面向。國教院表示,透過調查反映數位原生世代對新興科技高度接受度,但認知與實際使用存在落差,多數學生知道生成式AI,高度使用者比例相對仍低;學校教育角色重要,已半數學校著手進行生成式AI教育;應用場景從學業輔助到創意發揮,學生展現多面向運用AI工具能力。(編輯:李明宗)1140901

-- gReader Pro 

【iThome 2025 CIO大調查(下)|新興技術熱門趨勢】2025年金融業新興技術雷達圖

【iThome 2025 CIO大調查(下)|新興技術熱門趨勢】2025年金融業新興技術雷達圖

https://www.ithome.com.tw/article/170652

金融業是IT資源最充沛的產業,不論是IT人力或IT預算,都居各產業之冠。金融業平均IT部門規模超過3百人,今年IT預算更高達12億9千多萬元,比去年增加了13%,更可以推估2026年IT投資將再次創新高,推測可以再成長14%,推測IT預算有機會超過14億元。比其他產業更寬裕的資源,讓金融業可以嘗試更多不同形式的創新和GenAI應用。 今年金融業在五大IT領域的投資金額上,公雲費用超過3千2百萬元,地端IT架構則仍高達2億7千多萬元,AI投資超過了3千7百萬元,行動應用投資超過5千6百萬,資安投資更是高達7千6百萬元。若比照去年DevOps預算的比重,可以推測今年金融業投入DevOps的預算約9百萬元。 金融CIO今年前四大目標是資安、GenAI、IT維運效率和營運不中斷。若從不同類型IT預算的成長率來看,更容易看到金融IT投資和發展策略的變化。在五大IT投資中,金融今年在AI預算的成長率最高,達到74%之多,凸顯出金融大力衝擊AI技術的力道和決心,這也是CIO今年被賦予的重要任務。其次,公雲預算今年也高達56%的大幅成長,甚至連地端IT架構預算也比去年足足多了近5成,換句話說,金融整體IT基礎架構的預算比去年足足多了5成之高,這與不少銀行展開IT現代化,甚至是進行核心系統升級(或部分翻新)的計畫有關。 在這樣的目標和資源配置下,金融業今年在四大類新興技術的採用上,有五項爆紅技術,都集中在AI類技術,包括了ChatGPT/Gemini類應用、RAG架構、代理型AI、提示工程、負責任AI。AI類技術中,金融對於各種GAI模型的採用率也提高了不少。ChatGPT/Gemini類應用和GAI模型的採用率都接近5成,平均每兩家銀行就有一家會用。RAG架構也從去年開始快速普及,今年金融業採用率達到4成多。但是,傳統的分析式AI技術,今年的採用率則些微下滑,從去年的43%,今年下滑到41%,雖然和RAG架構採用率相當,但是這個下滑趨勢,透露出,更多金融業開始將資源聚焦到GAI相關技術上。 在IT基礎架構類技術上,K8s容器技術是主流,超過4成金融業者導入,隨著金融業今年大幅加碼公雲預算,對於雲端費用的管理也更迫切,今年要採用FinOps(雲端維運成本管理)做法的金融業也增加了不少,大約有18%金融業採用,FinOps做法不只可以用於公雲費用,國外越來越多企業也開始用同一套做法來管理地端的資料中心,例如Meta。也有約2成金融業,想要善用AI來優化IT維運,這個比例比去年提高了不少,值得觀察後續發展。值得留意的是技術退燒趨勢是,金融業今年SRE(網站可靠性工程)的採用率明顯下滑了許多,此外,雖然雲原生和多雲混合雲仍有超過2成的金融業者採用,但今年金融業對平臺工程、雲原生架構、多雲混合雲的採用率也些微下滑。 在AP架構和開發類技術上,用AI增強軟體工程是成長幅度最大的一項,今年有3成5的金融業者要用,另外也有3成7的金融業要採用DevSecOps,借助GAI來輔助開發同時,金融業也更注重開發預設安全的配套。雖然微服務架構、DevOps和OpenAPI架構仍舊是金融業AP架構的主流,但是今年的採用率都比去年些微下滑,中臺架構設計的金融業今年更是明顯減少了許多。部分原因是因為金融業今年更積極採用SaaS形式的生成式AI應用,降低了一部分自行開發的工作負擔。 值得留意的是,採取新式身分驗證技術FIDO或Passkeys(免密碼登入)的金融業者比去年更多了,甚至多了快2成金融業今年開始採用,這也有助於改善數位通路的使用者體驗,這也是金融業CIO今年的重要目標之一。   圖表說明 35項新興技術分為四類,包括了「IT基礎架構」、「AP架構與開發」、「AI技術」和「新興科技」,再按照2024與2025年的熱門程度變化,分為四個圈,每個圈中的技術代表不同的等級:爆紅技術(去年到今年的排名上升5名者)、主流技術(今年預估採用率超過平均採用率)、崛起技術(今年預估採用率低於平均採用率)和最外圈是退燒技術(今年比去年的排名下滑5名者)。同一圈中2025年預估採用率越高者,越靠近核心。紅色三角形代表企業採用率的增加幅度(超過10%者2個紅三角,超過15%者3個,後續每多5%,就多1個紅三角),綠色三角代表該項今年採用率減少者,減少5%者1個綠三角,超過5%者2個綠三角。兩年相比,採用率相同者,以黑色三角來代表。位於第四圈外者代表今年採用率降到0%。2025年金融業技術平均採用率27.1%。 資料來源:2025 iThome CIO大調查,2025年8月。執行說明: 2024年12月30日到2025年2月3日,調查臺灣2千大規模大型企業,有效問卷395家,72%填答者為企業IT最高主管。

-- gReader Pro 

NVIDIA Jet-Nemotron:LLM速度狂飆53倍,訓練成本與KV Cache大減

NVIDIA Jet-Nemotron:LLM速度狂飆53倍,訓練成本與KV Cache大減

https://www.facebook.com/1196130575859670/posts/1275395837933143

NVIDIA開發的Jet-Nemotron能提升LLM速度53倍,大幅降低訓練成本!🚀 LLM處理長文本生成時面臨O(n²)計算複雜度和大量KV Cache的挑戰。⚡ Jet-Nemotron使用PostNAS,不用從頭開始訓練,而是凍結現有模型部分權重,只調整注意力機制。這樣能大幅降低訓練成本。🔧 PostNAS有四個步驟:決定哪裡放全注意力層、選擇最好的線性注意力設計、開發新的JetBlock架構、針對硬體優化。📋 Jet-Nemotron 通過線性注意力機制將計算複雜度從O(n²)降低到O(n)。JetBlock 的創新在使用動態卷積核,能根據輸入內容動態調整特徵提取模式,而不是使用傳統的固定卷積核,簡化不必要的計算。🧠 研究發現解碼時主要受記憶體頻寬限制,所以影響處理速度的關鍵是KV Cache大小而不是參數量,減少Cache能大幅提升速度。💡 實驗結果顯示,Jet-Nemotron-2B在MMLU-Pro測試中準確率39.0%,超過Qwen3的37.8%,同時速度快47倍。在256K長文本處理中,速度提升53.6倍,Cache需求從7,168MB降到154MB。📊 (Feed generated with FetchRSS)

-- gReader Pro 

微軟發表兩款自製AI模型

微軟發表兩款自製AI模型

https://www.ithome.com.tw/news/170912

微軟AI(Microsoft AI,MAI)周四(8/28)發表兩款自製AI模型,分別是語音生成模型MAI-Voice-1與基礎模型MAI-1-preview。前者已整合至Copilot Daily、Podcasts與Copilot Labs,後者則於LMArena進行公開測試,並將逐步導入Copilot文字應用。 其中的MAI-Voice-1在單個GPU上不到1秒就能生成1分鐘的語音,標榜擁有自然的聲線,帶有情感及抑揚頓挫,同時支援單人或多人對話場景。外界認為MAI-Voice-1的問世代表微軟想把文字助理進化成語音夥伴,讓使用者不只是看文字,而是能聽到更自然的交流。 MAI-1-preview則是個基於混合專家(MoE)結構的模型,可於不同任務中調用專有模型,藉由資料挑選及開源技術,它僅以1.5萬顆的Nvidia H100 GPU進行訓練,遠低於採用10萬顆以上GPU的xAI Grok。MAI-1-preview的專長為指令遵循,可用來回答日常問題。 MAI負責人Mustafa Suleyman在接受Semafor採訪時解釋,微軟是全球最大的公司之一,需要內部能力來建立頂級模型,原因包括AI在未來數十年的戰略重要性令微軟不得缺席,且微軟也想要更多的模型選擇權。Suleyman表示,未來微軟會持續強化與OpenAI的合作關係,這並不代表雙方的關係會疏遠或冷卻。 此外,MAI也已經著手開發下一代的MAI-2模型,它的規模更大,設定將有所調整,可能會利用微軟正在建立的超大型GB200/GB300叢集進行訓練。

-- gReader Pro 

Improving the experience with public Wi-Fi hotspots

Improving the experience with public Wi-Fi hotspots

https://jbb.ghsq.de/kde/2025/08/29/freewifid.html

When travelling, I tend to rely on public Wi-Fi hotspots a lot, for example on trains, while waiting at the station, in cafe's and so on. Accepting the same terms and conditions every time gets annoying pretty quickly, so a few years ago I decided to automate this. The project that came out of that is freewifid. It continously scans for Wi-Fi networks it knows, and sends you a notification when it found one it can automatically connect to. You can then allow it to connect to that network automatically in the future.  Adding support for new captive portals Adding support for a new kind of captive portal is pretty easy. You just need to implement a small rust trait that includes a function that sends the specific request for the captive portal. Often this is very simple and looks like this: pub struct LtgLinkProvider {} impl LtgLinkProvider { pub fn new() -> LtgLinkProvider { LtgLinkProvider {} } } impl CaptivePortal for LtgLinkProvider { fn can_handle(&self, ssid: &str) -> bool { ["Link WIFI"].contains(&ssid) } fn login(&self, http_client: &ureq::Agent) -> anyhow::Result&lt;()> { // Store any cookies the landing page might send common::follow_automatic_redirect(http_client)?; http_client .post("http://192.168.1.100:8880/guest/s/default/login") .send_form([ ("checkbox", "on"), ("landing_url", crate::GENERIC_CHECK_URL), ("accept", "PRISIJUNGTI"), ])?; Ok(()) } }  For finding out what needs to be sent, you can use your favoute browser's inspection tools. For testing, Plasma's feature for assigning a random MAC-address comes very handy. Integration with Plasma It could be interesting to write a KCM for freewifid, so you can graphically remove networks again. Support for ignoring public networks in the presence of a given SSID is also already implemented, but currently needs to be enabled by editing the config file. Writing a KCM is not high on my list of priorities right now, but if this sounds like something you'd like to do, I'd happily help with with the freewifid interfacing parts. Project The project is hosted on Codeberg. I'll happily accept merge requests for additional captive portals there. There are some prebuilt release binaries, but I'm not too certain they'll work on every distribution. With a rust compiler installed, the project is very simple to build (cargo build). A systemd unit is provided in the repository, which you can use to run freewifid as a user unit. Freewifid also supports running as a system service non-interactively for use in embedded projects.

-- gReader Pro 

Meta 提出“Active Reading”框架,让大模型像人一样“精读”

Meta 提出"Active Reading"框架,让大模型像人一样"精读"

https://www.oschina.net/news/369160

Meta FAIR 与伯克利今日联合发布最新研究——Active Reading 框架,首次把"主动学习"概念搬进大模型训练流程,让模型以自我生成的学习策略研读指定材料,从而在大规模场景下可靠地吸收知识。 简单来说,模型拿到一篇文档后,会先自己设计"学习策略"(如摘要、联想、自测题等),再用这些策略生成大量高质量训练数据,最终把知识"吃干榨尽"。  https://www.arxiv.org/abs/2508.09494 实测成绩亮眼  金融垂类基准 FinanceBench:准确率从 16% 飙到 26%,相对提升 160%。 长尾知识基准 SimpleQA:准确率由 16% 暴涨至 66%,相对提升 312%。 用框架合成的 1 T tokens 训练出 8B 模型 Meta WikiExpert,事实问答表现超越 405B 的 Llama 3.1 与 236B 的 DeepSeekV2。  研究亮点  全流程自动化:无需人工设计问答模板。 数据多样性:一次文档可衍生释义、类比、填空、多轮 QA 等多种形式。 可扩展:已验证在预训练阶段直接放大到万亿 token 规模。  下一步,团队计划把 Active Reading 与检索增强(RAG)结合,探索"边读边查"的新范式。论文已上线 arXiv,代码与数据即将开源。

-- gReader Pro 

AgentFly:AI Agent像人類學習,免微調LLM,經驗記憶提升5-10%!

AgentFly:AI Agent像人類學習,免微調LLM,經驗記憶提升5-10%!

https://www.facebook.com/1196130575859670/posts/1272786161527444

可以讓AI Agent像人類一樣從過去的經驗中學習,而不需要重新微調LLM?!🤔 研究團隊推出AgentFly,這套系統的設計靈感來自人類的學習方式,當我們遇到新問題時,大腦會自動搜尋過去遇到的類似情況,然後參考當時的解決方法。AgentFly會把每次處理任務的過程記錄下來,包括做了什麼決定、用了哪些工具、最後成功還是失敗。下次遇到相似問題時,系統就會翻閱這些「經驗」,選擇最有用的案例來參考。📚 AgentFly採用規劃器-執行器設計:一個負責思考規劃的「大腦」和一個負責執行操作的「手腳」。🛠️ 🧠 系統整合了三種不同的記憶庫: - 案例記憶,存儲所有的歷史經驗 - 子任務記憶,追蹤正在進行的任務 - 工具記憶,記錄使用過的工具和結果 系統還能自動判斷哪些經驗最有價值,優先參考最相關的案例。⚙️ 測試結果相當驚人。在各種AI能力測試中,AgentFly都表現優異,特別是在需要長期規劃和複雜推理的任務上。比如在GAIA測試中拿到第一名,在回答事實性問題時達到95%的準確率。最重要的是,當面對全新類型的問題時,有了經驗記憶的幫助,表現比沒有記憶的版本提升了5-10%!🏆 (Feed generated with FetchRSS)

-- gReader Pro 

不想讓創作變AI飼料?全新開源字型「ShieldFont」登場,靠這招讓爬蟲抓到滿頭包 | T客邦

https://www.techbang.com/posts/131901-shieldfont-anti-ai-crawler-glyph-substitution