<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>運算效能 &#8211; 科技島-掌握科技新聞、科技職場最新資訊</title>
	<atom:link href="https://www.technice.com.tw/tag/%e9%81%8b%e7%ae%97%e6%95%88%e8%83%bd/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.technice.com.tw</link>
	<description>專注於科技新聞、科技職場、科技知識相關資訊，包含生成式AI、人工智慧、Web 3.0、區塊鏈、科技職缺百科、生物科技、軟體發展、雲端技術等豐富內容，適合熱衷科技及從事科技專業人事第一手資訊的平台。</description>
	<lastBuildDate>Fri, 21 Aug 2026 09:39:25 +0000</lastBuildDate>
	<language>zh-TW</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.4.2</generator>

<image>
	<url>https://www.technice.com.tw/wp-content/uploads/2022/12/cropped-wordpress_512x512-150x150.png</url>
	<title>運算效能 &#8211; 科技島-掌握科技新聞、科技職場最新資訊</title>
	<link>https://www.technice.com.tw</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>為何記憶體效能比以往更關鍵？AI、遊戲到SSD都面臨的「資料搬運戰」</title>
		<link>https://www.technice.com.tw/issues/semicon/262267/</link>
					<comments>https://www.technice.com.tw/issues/semicon/262267/#respond</comments>
		
		<dc:creator><![CDATA[黃仁杰]]></dc:creator>
		<pubDate>Fri, 21 Aug 2026 09:39:25 +0000</pubDate>
				<category><![CDATA[半導體]]></category>
		<category><![CDATA[AI人工智慧]]></category>
		<category><![CDATA[產業應用]]></category>
		<category><![CDATA[記憶體]]></category>
		<category><![CDATA[資料搬運]]></category>
		<category><![CDATA[運算效能]]></category>
		<guid isPermaLink="false">https://www.technice.com.tw/?p=262267</guid>

					<description><![CDATA[<p><img width="1672" height="941" src="https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36.png" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="ChatGPT Image 2026年8月21日 下午05 35 36" decoding="async" srcset="https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36.png 1672w, https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36-300x169.png 300w, https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36-1024x576.png 1024w, https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36-768x432.png 768w, https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36-1536x864.png 1536w, https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36-390x220.png 390w" sizes="(max-width: 1672px) 100vw, 1672px" title="為何記憶體效能比以往更關鍵？AI、遊戲到SSD都面臨的「資料搬運戰」 1"></p>
<p>過去談到電腦效能，往往只需要看幾個關鍵數字，CPU看時脈與核心數、GPU看運算單元與TFLOPS、記憶體看頻率、SSD則看循序讀寫速度。但隨著現代處理器的運算能力大幅提升，真正限制效能的因素正在改變。CPU、GPU與AI加速器都能在極短時間內完成大量運算，但前提是資料必須及時送到運算單元。<content>記者黃仁杰／編譯</p>
<p class="PDq2pG_selectionAnchorContainer" data-start="40" data-end="108">過去談到電腦效能，往往只需要看幾個關鍵數字，CPU看時脈與核心數、GPU看運算單元與TFLOPS、記憶體看頻率、SSD則看循序讀寫速度。</p>
<p>[caption id="attachment_262362" align="aligncenter" width="1672"]<img class="wp-image-262362 size-full" src="https://www.technice.com.tw/wp-content/uploads/2026/08/ChatGPT-Image-2026年8月21日-下午05_35_36.png" alt="" width="1672" height="941" /> 想理解現代運算效能，已經不能只看CPU或GPU本身，還必須理解整個記憶體系統如何運作。（圖／AI生成）[/caption]</p>
<p class="" data-start="110" data-end="200">這些規格至今仍有參考價值，但隨著現代處理器的運算能力大幅提升，真正限制效能的因素正在改變。CPU、GPU與AI加速器都能在極短時間內完成大量運算，但前提是資料必須及時送到運算單元。</p>
<p class="" data-start="202" data-end="251">現在的效能瓶頸愈來愈不是「算得夠不夠快」，而是資料能不能在正確時間送到正確位置。</p>
<p class="" data-start="253" data-end="361">現代CPU單一核心每個時脈週期就能執行多個指令，高階GPU擁有數千個平行運算單元，AI加速器的矩陣運算能力甚至進入PFLOPS等級。然而，這些運算資源都必須取得指令、模型權重、貼圖、幾何資料、中間結果等資料才能工作。</p>
<p class="" data-start="363" data-end="446">問題就在於，運算能力的成長速度遠超過資料搬移能力。資料傳輸牽涉延遲、頻寬、能源以及晶片面積，因此許多現代工作負載真正花費大量資源的地方，是如何避免運算單元「餓肚子」。</p>
<p class="" data-start="448" data-end="510">這並不代表所有程式都受到記憶體限制，但想理解現代運算效能，已經不能只看CPU或GPU本身，還必須理解整個記憶體系統如何運作。</p>
<h2 class="" data-section-id="160tphj" data-start="512" data-end="539"><strong>記憶體效能不只是頻率 延遲、頻寬與資料位置都重要</strong></h2>
<p class="" data-start="541" data-end="569">所謂「記憶體效能」，並不只等於DDR記憶體跑多少MHz。</p>
<p class="" data-start="571" data-end="681">包括延遲（Latency）、頻寬（Bandwidth）、快取容量、資料區域性（Locality）、可同時進行多少記憶體操作、資料存取模式、預取能力，以及資料究竟位於快取、DRAM、VRAM還是儲存裝置，都會影響最終效能。</p>
<p class="" data-start="683" data-end="716">其中首先必須理解的，就是循序存取與隨機存取之間的巨大差異。</p>
<h2 class="" data-section-id="11cutz4" data-start="718" data-end="744"><strong>循序與隨機存取 同樣搬1GB資料速度大不同</strong></h2>
<p class="" data-start="746" data-end="804">假設電腦從頭到尾讀取一個1GB檔案，下一筆資料的位置完全可以預測。系統一旦辨識出這種模式，就能提前把後續資料抓進來。</p>
<p class="" data-start="806" data-end="830">這就是循序存取，而現代硬體非常擅長處理這類工作。</p>
<p class="" data-start="832" data-end="928">CPU具有硬體預取器，可以偵測規律的記憶體資料流；DRAM控制器可以同時處理多筆請求並重新排序；SSD控制器則能把資料分散到多個NAND晶粒與通道；GPU也能將相鄰執行緒的記憶體請求合併處理。</p>
<p class="" data-start="930" data-end="963">簡單來說，只要資料位置可預測，硬體就能建立一條高效率的資料流水線。</p>
<p data-start="965" data-end="975">但隨機存取完全不同。</p>
<p class="" data-start="977" data-end="1040">例如程式正在遍歷一條鏈結串列，每一筆資料才會告訴處理器「下一筆在哪裡」。CPU必須先完成上一筆讀取，才能知道下一筆記憶體地址。</p>
<p data-start="1042" data-end="1059">在這種情況下，預取幾乎派不上用場。</p>
<p data-start="1061" data-end="1095">因此，即使兩個程式總共搬動完全相同的資料量，執行速度仍可能相差數倍。</p>
<p data-start="255" data-end="377">「AI履歷健檢」看見自己優勢：<a href="https://campaign.1111.com.tw/resume-review/"><span style="color: #33cccc;"><strong>https://campaign.1111.com.tw/resume-review/</strong></span></a></p>
<p data-start="255" data-end="377">更多科技工作請上科技專區：<a href="https://techplus.1111.com.tw/"><strong><span style="color: #33cccc;">https://techplus.1111.com.tw/</span></strong></a></p>
<h2 class="" data-section-id="zun2iw" data-start="1097" data-end="1119"><strong>「指標追逐」讓CPU無法藏住記憶體延遲</strong></h2>
<p data-start="1121" data-end="1139">現代CPU其實很擅長隱藏記憶體延遲。</p>
<p data-start="1141" data-end="1198">如果CPU同時需要4條互不相關的Cache Line，它可以把多筆記憶體請求一起送出去，藉由平行處理降低等待時間。</p>
<p class="" data-start="1200" data-end="1225">但如果請求B必須等待A的結果才能開始，就完全不同。</p>
<p class="" data-start="1227" data-end="1289">這種情況常被稱為「Pointer Chasing（指標追逐）」。每次記憶體讀取才會產生下一個地址，因此CPU只能一次等一筆。</p>
<p class="" data-start="1291" data-end="1344">資料庫的小型隨機查詢，就是典型案例；GPU中數千個執行緒若各自尋找完全不同的記憶體位置，也會遇到類似問題。</p>
<p class="" data-start="1346" data-end="1441">因此軟體工程師會盡可能重新排列資料，例如資料庫重組索引、遊戲引擎批次處理工作、GPU演算法重新排序請求，或將Array of Structures改成Structure of Arrays。</p>
<p class="" data-start="1443" data-end="1491">目的不是徹底消除隨機存取，而是讓昂貴的資料存取更少發生、更容易預測，並且盡可能同時進行。</p>
<h2 class="" data-section-id="1agunom" data-start="1493" data-end="1514"><strong>為什麼快取有效？關鍵在「資料區域性」</strong></h2>
<p data-start="1516" data-end="1539">幸好，真實世界的程式通常不會完全隨機存取資料。</p>
<p data-start="1541" data-end="1603">大多數程式都具備兩種特性：空間區域性（Spatial Locality）與時間區域性（Temporal Locality）。</p>
<p class="" data-start="1605" data-end="1668">空間區域性代表當程式讀取某一筆資料後，很可能很快會需要旁邊的資料；時間區域性則代表剛剛使用過的資料，很可能不久後又會再用一次。</p>
<p class="" data-start="1670" data-end="1721">例如程式依序處理陣列，就具有很好的空間區域性；遊戲中頻繁更新的角色或場景資料，則具有很強的時間區域性。</p>
<p class="" data-start="1723" data-end="1740">這正是CPU快取能發揮作用的原因。</p>
<p class="" data-start="1742" data-end="1821">CPU從DRAM讀取資料時，通常不會只拿一個Byte，而是一次搬入一整條Cache Line。主流x86 CPU的Cache Line通常為64 Bytes。</p>
<p class="" data-start="1823" data-end="1851">因此，如果接下來程式需要附近資料，它很可能已經在快取裡。</p>
<h2 class="" data-section-id="wmbs3i" data-start="1853" data-end="1876"><strong>工作集一旦超過快取 效能恐大打折扣</strong></h2>
<p class="" data-start="1878" data-end="1905">另一個重要概念是「Working Set（工作集）」。</p>
<p class="" data-start="1907" data-end="1946">一個程式可能配置數十GB記憶體，但某個階段真正頻繁使用的資料可能只有幾十MB。</p>
<p class="" data-start="1948" data-end="2016">如果這些資料全部塞得進CPU快取，效能會非常好；但只要工作集稍微超過快取容量，大量資料就必須重新從較慢的DRAM取得，效能可能突然下滑。</p>
<p class="" data-start="2018" data-end="2050">這也是為什麼增加快取有時會帶來巨大效能提升，但有時幾乎沒有差別。</p>
<p class="" data-start="2052" data-end="2128">例如工作集約60MB，把快取從32MB增加至96MB就可能非常有效；但如果程式不停地串流讀取數GB資料，而且每筆資料只用一次，再大的快取也難以發揮作用。</p>
<p data-start="2130" data-end="2161">快取最有價值的情況，是程式真的有值得被「記住」的資料。</p>
<h2 class="" data-section-id="1kwbnlc" data-start="2163" data-end="2198"><strong>CPU為何需要L1、L2、L3？又大又快又便宜的記憶體不存在</strong></h2>
<p data-start="2200" data-end="2230">如果快取這麼有效，為什麼不乾脆做一個超大的L1 Cache？</p>
<p data-start="2232" data-end="2246">因為記憶體設計永遠存在取捨。</p>
<p class="" data-start="2248" data-end="2315">CPU最接近運算核心的快取通常採用SRAM，延遲低、頻寬高，但占用大量晶片面積，而且容量愈大，線路愈長、查找邏輯愈複雜，功耗也會增加。</p>
<p class="" data-start="2317" data-end="2329">因此才形成多層快取架構。</p>
<p class="" data-start="2331" data-end="2404">L1容量最小但最快，L2容量更大、速度稍慢；L3通常容量更大，而且可能由多核心共享，但延遲又更高。如果三層快取全部未命中，最後才必須進入DRAM。</p>
<p data-start="2406" data-end="2477">快取設計還涉及關聯度（Associativity）、Bank配置、讀寫埠數量、私人與共享快取，以及多核心之間的Cache Coherence。</p>
<p data-start="2479" data-end="2497">所以「快取愈大愈好」並不是沒有代價。</p>
<h2 class="" data-section-id="1cvohc5" data-start="2499" data-end="2535"><strong>AMD 3D V-Cache成代表經典 在CPU上堆疊更多資料</strong></h2>
<p class="" data-start="2537" data-end="2579">AMD的3D V-Cache，就是利用3D堆疊解決快取容量與晶片面積衝突的代表技術。</p>
<p class="" data-start="2581" data-end="2640">AMD將額外64MB L3快取晶粒直接堆疊在CPU上，利用銅對銅接合與TSV連接，而不必單純把CPU核心晶粒做得更大。</p>
<p class="" data-start="2642" data-end="2682">Ryzen X3D處理器在遊戲市場的成功，也證明這種設計在特定工作負載非常有效。</p>
<p class="" data-start="2684" data-end="2756">遊戲會頻繁處理世界狀態、物理資料、動畫、Draw Call、可視性資訊等內容，如果能把更多常用資料留在CPU附近，就可以減少前往DRAM的次數。</p>
<p class="" data-start="2758" data-end="2807">但不同遊戲提升幅度差異很大，有些遊戲的關鍵資料本來就能塞進普通快取，有些則受限於GPU或其他因素。</p>
<p data-start="2809" data-end="2840">這正符合記憶體階層理論，快取是否有效，取決於工作負載。</p>
<h2 data-section-id="2v242i" data-start="2842" data-end="2861"><strong>DRAM也不能只看MHz與CL值</strong></h2>
<p data-start="2863" data-end="2889">當資料不在CPU快取時，就必須進入主記憶體DRAM。</p>
<p data-start="2891" data-end="2947">DRAM容量遠高於SRAM，而且每Bit成本較低，但速度也慢得多。因此現代DRAM會利用大量平行化方式提高效能。</p>
<p data-start="2949" data-end="2991">DRAM內部被分成多個Bank與Bank Group，每個Bank又包含大量Row。</p>
<p data-start="2993" data-end="3035">讀取資料時，通常必須先將某一Row啟動並放入Row Buffer，才能存取其中資料。</p>
<p data-start="3037" data-end="3119">如果需要的Row已經打開，就是Row Buffer Hit；如果目前沒有開啟，就必須Activate；若錯誤的Row正處於開啟狀態，甚至可能需要先關閉再開啟另一個。</p>
<p data-start="3121" data-end="3200">因此記憶體控制器並不是單純把CPU請求送給DRAM，而是持續重新排列大量讀寫操作，試圖在Channel、Rank、Bank Group和Bank之間提高效率。</p>
<h2 class="" data-section-id="1rftyoa" data-start="3202" data-end="3216"><strong>頻寬與延遲不能混為一談</strong></h2>
<p data-start="3218" data-end="3240">這也解釋為什麼記憶體頻寬與延遲不能混為一談。</p>
<p class="" data-start="3242" data-end="3273">延遲代表完成一筆操作需要多久；頻寬代表一段時間內能搬多少資料。</p>
<p class="" data-start="3275" data-end="3315">一套系統可能擁有非常高的總頻寬，但面對一連串彼此依賴的隨機存取時，效能仍然很差。</p>
<p class="" data-start="3317" data-end="3372">反過來，如果一個工作負載可以同時送出數百筆互不依賴的記憶體請求，即使單筆延遲不低，也可以靠平行化取得高吞吐量。</p>
<p data-start="3374" data-end="3388">DDR5便高度依賴這種思維。</p>
<p class="" data-start="3390" data-end="3483">相比DDR4，DDR5增加Bank Group數量、將預設Burst Length從8提高至16，也把DIMM拆成兩個獨立Subchannel，目的就是提高同時處理更多記憶體工作的能力。</p>
<p data-start="3485" data-end="3519">這也是為什麼更換高頻DDR記憶體後，不同程式的效能提升可能完全不同。</p>
<h2 data-section-id="1og85w4" data-start="3521" data-end="3549"><strong>為了餵飽GPU GDDR與HBM成解方</strong></h2>
<p data-start="3551" data-end="3583">GPU擁有數千個平行運算單元，因此需要遠高於CPU的記憶體頻寬。</p>
<p data-start="3585" data-end="3624">消費型GPU通常採用GDDR，透過較寬的記憶體介面與極高傳輸速度取得大量頻寬。</p>
<p data-start="3626" data-end="3645">AI與高效能運算則更進一步採用HBM。</p>
<p data-start="3647" data-end="3701">HBM把多層DRAM垂直堆疊，並透過先進封裝放在非常靠近GPU或AI加速器的位置，再利用極寬的介面傳輸資料。</p>
<p data-start="3703" data-end="3742">代價是成本與封裝複雜度大幅增加，但可以換取非常高的頻寬與較佳每Bit能源效率。</p>
<p data-start="3744" data-end="3822">例如AMD Instinct MI355X單顆就搭載288GB HBM3E，理論記憶體頻寬最高可達8TB/s；一套8 GPU系統甚至擁有2.3TB HBM。</p>
<p data-start="3824" data-end="3871">對桌上型CPU而言，這種數字看似誇張，但對現代AI來說，如何餵飽運算核心已經成為核心架構問題。</p>
<h2 data-section-id="4rz3vh" data-start="3873" data-end="3896"><strong>AI讓「資料搬移」成為第一級效能瓶頸</strong></h2>
<p data-start="3898" data-end="3917">大型語言模型更清楚展現現代運算的矛盾。</p>
<p class="" data-start="3919" data-end="3975">GPU與AI加速器非常擅長矩陣乘法，但每一次計算以前，都必須先取得模型權重、Activation與其他中間資料。</p>
<p class="" data-start="3977" data-end="4052">AI訓練尤其吃記憶體，除了模型權重之外，還可能需要儲存Gradient、Optimizer State、反向傳播所需Activation以及暫存資料。</p>
<p data-start="4054" data-end="4087">推論雖然需求不同，卻仍面臨模型權重與KV Cache等記憶體壓力。</p>
<p data-start="4089" data-end="4152">以70億參數模型為例，如果採16-bit精度，光模型權重就需要約14GB記憶體，還沒有算KV Cache與Runtime成本。</p>
<h2 data-section-id="v6njjz" data-start="4154" data-end="4176"><strong>AI量化不只省容量 也等於少搬很多資料</strong></h2>
<p data-start="4178" data-end="4207">這也是AI量化（Quantization）如此重要的原因。</p>
<p data-start="4209" data-end="4271">如果把參數從16-bit降低到8-bit甚至4-bit，不僅模型占用的容量下降，每次從記憶體搬進運算單元的資料量也同步減少。</p>
<p data-start="4273" data-end="4308">當工作負載受到記憶體頻寬限制時，少搬一半資料，本身就可能直接提高效能。</p>
<p data-start="4310" data-end="4342">這揭示重新計算與搬資料其實可以互相交換。</p>
<p data-start="4344" data-end="4395">有時候，把某個結果儲存起來比重新計算划算；有時候重新算一次，反而比從很遠的記憶體抓回來更快、更省能源。</p>
<p data-start="4397" data-end="4420">現代晶片設計愈來愈需要判斷究竟哪一邊比較便宜。</p>
<h2 data-section-id="1kly2g2" data-start="4422" data-end="4441"><strong>遊戲是最混亂的記憶體工作負載之一</strong></h2>
<p data-start="4443" data-end="4459">遊戲沒有單一固定的資料存取模式。</p>
<p data-start="4461" data-end="4564">CPU可能正在處理場景可視性、物理、AI與Draw Call；GPU則同時讀取幾何、貼圖、材質、Render Target與Shader資料。開放世界遊戲還需要不斷從SSD把新資產搬進系統記憶體與VRAM。</p>
<p data-start="4566" data-end="4583">部分工作高度規律，部分卻非常隨機。</p>
<p data-start="4585" data-end="4647">因此CPU端的大型快取可以降低DRAM存取，而GPU同樣持續擴大Last-Level Cache，希望減少外部VRAM流量。</p>
<p data-start="4649" data-end="4708">輝達、AMD與Intel近年的GPU架構，都不斷改變快取設計，因為「少去一次VRAM」有時比單純增加記憶體頻寬更有效。</p>
<h2 data-section-id="1fehxih" data-start="4710" data-end="4727"><strong>光線追蹤讓記憶體存取更加混亂</strong></h2>
<p data-start="4729" data-end="4742">即時光線追蹤更是典型案例。</p>
<p data-start="4744" data-end="4795">光線需要遍歷BVH（Bounding Volume Hierarchy）結構，判斷可能與哪些物件相交。</p>
<p data-start="4797" data-end="4856">問題在於，每條光線可能朝完全不同的方向前進，因此相鄰GPU執行緒不只執行不同程式路徑，也可能讀取完全不同的記憶體地址。</p>
<p data-start="4858" data-end="4903">輝達稱這種情況為Execution Divergence與Data Divergence。</p>
<p data-start="4905" data-end="4975">Shader Execution Reordering等技術，就是嘗試重新排列光線追蹤工作，讓相似的任務重新聚集，提高執行效率與資料區域性。</p>
<p class="" data-start="4977" data-end="5017">這說明記憶體問題不一定只能靠「更快的記憶體」解決，有時重新安排工作本身更加有效。</p>
<h2 data-section-id="19rkem8" data-start="5019" data-end="5040"><strong>顯示記憶體容量不足 高頻寬也救不了</strong></h2>
<p data-start="5042" data-end="5070">遊戲也可能不是受到頻寬或延遲限制，而是單純「容量不夠」。</p>
<p class="" data-start="5072" data-end="5148">如果貼圖、幾何資料與Render Resource超過GPU的顯示記憶體（VRAM）容量，系統就必須透過PCIe從系統記憶體搬資料，或者不斷將舊資源踢出去再重新載入。</p>
<p class="" data-start="5150" data-end="5192">此時即使GPU本身擁有極高的VRAM頻寬也沒有用，因為需要的資料根本不在VRAM裡。</p>
<p data-start="5194" data-end="5228">因此記憶體效能其實同時包含容量、延遲、頻寬、快取命中率與資料區域性。</p>
<h2 class="" data-section-id="qnat8b" data-start="5230" data-end="5253"><strong>SSD為前鑑 循序速度不代表真實效能</strong></h2>
<p data-start="5255" data-end="5270">儲存裝置也是最容易理解的例子。</p>
<p class="" data-start="5272" data-end="5323">現在PCIe NVMe SSD動輒宣稱10GB/s以上循序讀寫，但這只代表大型連續資料傳輸的理想情況。</p>
<p class="" data-start="5325" data-end="5363">作業系統、遊戲、資料庫與各種應用程式，經常要求SSD讀取大量分散的小型資料。</p>
<p class="" data-start="5365" data-end="5406">因此SSD規格除了循序速度，也會列出隨機IOPS、Queue Depth以及延遲。</p>
<p class="" data-start="5408" data-end="5464">大型循序工作可以讓控制器把工作分散到多個NAND Channel、Die與Plane；而小型隨機IO則完全不同。</p>
<p data-start="5466" data-end="5512">Queue Depth提高時，可以透過更多平行操作增加吞吐量，但代價往往是單筆請求延遲提高。</p>
<h2 class="" data-section-id="wp11b8" data-start="5514" data-end="5537"><strong>SSD也建立了「記憶體階層」</strong></h2>
<p class="" data-start="5539" data-end="5560">NAND SSD內部同樣具有大量平行架構。</p>
<p class="" data-start="5562" data-end="5630">SSD控制器需要處理地址轉換、Wear Leveling、Garbage Collection等工作，讓NAND看起來就像一般儲存裝置。</p>
<p class="" data-start="5632" data-end="5692">這些操作也會造成Write Amplification，也就是SSD實際寫入NAND的資料量，比作業系統要求寫入的更多。</p>
<p class="" data-start="5694" data-end="5747">此外，許多消費型SSD會把部分NAND暫時當成SLC快取使用，先高速寫入，之後再慢慢整理到TLC或QLC。</p>
<p data-start="5749" data-end="5812">部分SSD還會搭載DRAM儲存映射表，DRAM-less SSD則可能利用Host Memory Buffer借用系統記憶體。</p>
<p data-start="5814" data-end="5839">也就是說，SSD本身其實又建立了另一套記憶體階層。</p>
<p data-start="5841" data-end="5891">因此一旦高速快取用完，SSD的長時間寫入速度可能與產品規格表上的短時間Benchmark差距非常大。</p>
<h2 class="" data-section-id="k3c2n8" data-start="5893" data-end="5916"><strong>換個工作負載 硬體效能截然不同</strong></h2>
<p class="" data-start="5918" data-end="5948">這也是為什麼記憶體Benchmark一定要搭配使用情境來看。</p>
<p data-start="5950" data-end="6021">大型檔案複製重視持續循序頻寬；資料庫可能更在意隨機讀取與尾端延遲；科學模擬可以大量利用循序頻寬與向量化；編譯器則可能需要頻繁追逐複雜資料結構。</p>
<p class="" data-start="6023" data-end="6077">CPU受限的遊戲，如果工作集剛好塞進更大的L3 Cache，可能得到巨大提升；另一款遊戲則可能完全沒有感覺。</p>
<p data-start="6079" data-end="6140">AI訓練則同時需要算力、容量與頻寬；低併發LLM推論往往更依賴記憶體頻寬，而長上下文推論又會把KV Cache容量推上來。</p>
<p data-start="6142" data-end="6192">因此即使只是「頻寬」這個詞，也可能包含介面理論頻寬、快取頻寬、DRAM頻寬、儲存頻寬與晶片互連頻寬。</p>
<p data-start="6194" data-end="6229">真正決定效能的，是程式的資料存取方式如何與整套記憶體階層互動。</p>
<h2 class="" data-section-id="1lgkir4" data-start="6231" data-end="6260"><strong>現代運算真正的方向 把資料搬運變少</strong></h2>
<p data-start="6262" data-end="6305">回頭看現代CPU、GPU與AI加速器的架構變化，就會發現大量技術其實都在解決同一件事。</p>
<p data-start="6307" data-end="6390">快取是把常用資料留在運算核心附近；預取器提前猜測下一筆資料；記憶體控制器重新排列請求；GPU排程試圖提高資料一致性；Tiling則把大型問題切成能塞進小型快取的區塊。</p>
<p class="" data-start="6392" data-end="6487">資料壓縮減少需要傳送的Byte數，AI量化也是同樣概念；HBM透過先進封裝把超高頻寬記憶體搬到加速器旁邊；3D堆疊則增加容量又降低距離；Chiplet讓運算、快取與I/O模組可以更靈活組合。</p>
<p data-start="6489" data-end="6506">這些技術的共同目標，就是<strong data-start="6508" data-end="6529">盡可能提高昂貴資料搬移的使用效率。</strong></p>
<h2 class="" data-section-id="1qz01wo" data-start="6531" data-end="6554"><strong>算力持續成長 「記憶體牆」不會消失</strong></h2>
<p class="" data-start="6556" data-end="6635">未來CPU與GPU算力仍會繼續提高，記憶體頻寬也會繼續增加，HBM會變快、快取會變大、SSD可能進一步突破每秒數十GB，先進封裝也會讓原本分離的元件靠得更近。</p>
<p class="" data-start="6637" data-end="6666">但物理距離、能源、成本、容量與延遲之間的基本矛盾不會消失。</p>
<p class="" data-start="6668" data-end="6705">沒有一種記憶體可以同時做到容量巨大、頻寬無限、零延遲，而且又幾乎不花成本。</p>
<p class="" data-start="6707" data-end="6733">因此，記憶體階層不但不會消失，反而只會變得更加複雜。</p>
<p data-start="6707" data-end="6733">CPU如果花上數百個Clock等待記憶體，它擁有再高的理論算力都沒有意義；GPU如果數千個運算單元都在等待VRAM，TFLOPS再高也只是閒置；AI加速器即使擁有PFLOPS級運算能力，如果拿不到模型資料，一樣無法工作。</p>
<p class="" data-start="6735" data-end="6818">現代運算的關鍵，已經逐漸變成在處理器真正要求資料以前，就先把正確的資料放到正確的位置，並透過軟體與硬體設計，讓同一份資料盡可能被重複利用，而不是一次又一次重新搬運。</p>
<p class="" data-start="6820" data-end="6930">來源：<a href="https://wccftech.com/why-memory-performance-is-more-important-than-ever-in-modern-computing/"><span style="color: #33cccc;"><strong>wccftech</strong></span></a></p>
<p></content></p>
<p>這篇文章 <a rel="nofollow" href="https://www.technice.com.tw/issues/semicon/262267/">為何記憶體效能比以往更關鍵？AI、遊戲到SSD都面臨的「資料搬運戰」</a> 最早出現於 <a rel="nofollow" href="https://www.technice.com.tw">科技島-掌握科技新聞、科技職場最新資訊</a>。</p>
]]></description>
		
					<wfw:commentRss>https://www.technice.com.tw/issues/semicon/262267/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
