一顆 64GB DDR5 RDIMM 在 2026 年第一季報價還在 $873，Citi 五月的研究預估到第四季會拉到 $1,586——九個月漲八成。這只是契約價，現貨市場更誇張，Bloomberg 七月的報導寫 DRAM 現貨價一年內拉了近 700%。SK Hynix 十月法說會直接說 2026 年整年的 HBM、DRAM、NAND 產能「本質上已經賣光」，Micron 更狠，直接宣布退出消費記憶體市場，把產能整批轉去接 AI 客戶。這波記憶體荒不是短期波動，而是 HBM 對整條 DRAM 供應鏈的結構性擠壓，跑 VPS、跑自架伺服器、做機房代管的人都得重新算一次帳。
HBM 為什麼能把整條 DRAM 產能吸走
問題的根源在晶圓分配。HBM（High Bandwidth Memory）跟一般 DDR5 用的都是同一批 DRAM 晶圓，但 HBM 是把多顆 die 用 TSV（Through-Silicon Via）疊起來加中介層封裝，同樣一片晶圓最後能生產的 GB 容量大概只有 DDR4/DDR5 的三分之一。換算下來，每交出 1TB HBM 給 NVIDIA 或 AMD 的 AI 加速器，就等於少了 3TB 的伺服器 RDIMM 產能。
Samsung、SK Hynix、Micron 三家的抉擇很直接——AI 客戶願意用高於 DDR5 五到八倍的單價買 HBM，且訂單一簽就是兩三年。相較之下 DDR5 賣消費 PC、企業伺服器、雲端服務商，價格敏感、需求波動大。三家在 2025 年底陸續把先進製程的晶圓分配從一般 DRAM 挪去 HBM，2026 年進一步擴大這個比例，直接的後果就是 server DRAM 在第一季漲了 80%~110%。
Samsung 記憶體部門負責人 Kim Jaejune 在十月的談話直接把時間軸講清楚：「significant shortages」預期會延續到至少 2027 年。SK Hynix CEO 在七月更把話講死，說這波短缺可能撐到 2030 年之後才會緩解。這不是那種等半年就能過去的週期性波動。
VPS 產業被夾在中間
上游擠壓下游的邏輯在 VPS 這一層被放大。AWS、GCP、Azure 這些超大規模雲端業者跟記憶體廠有長期合約跟優先供應保證，他們拿到貨的價格跟中小型 VPS 服務商拿到的完全不是同一回事。實務上供應商採取所謂「selective allocation」，優先滿足大 OEM 跟 hyperscaler 的訂單，中小型買家能拿到的量跟報價都是次等。
這也是為什麼 2026 年很多 VPS 服務商調整方案的手法變得比較保守——同樣月費不再加大記憶體規格、或者把大記憶體規格單獨拉高價格、甚至用 CPU 跟儲存空間的甜蜜點來吸引客戶。這不是行銷策略問題，是採購成本結構被 HBM 擠壓後的必然結果。對於自架伺服器的人也一樣，過去買一支 128GB DDR5 RDIMM 的預算現在只能買到 64GB，甚至剛好卡在缺貨列表上。
用 refurbished DDR4 撐一波是有人在做，尤其是那些不吃最新 CPU 平台的舊機房、colocation 客戶。二手企業級 DDR4 RDIMM 在 2026 年反而變成價格洩壓閥，但這條路對新採購的 Intel Xeon Sapphire Rapids 或後續平台沒用——這些平台只認 DDR5。
選 VPS 規格時該重新算的帳
過去憑感覺選 8GB、16GB、32GB 記憶體規格的邏輯在 2026 年得改。當記憶體單價變成主機成本的最大宗，多買一倍記憶體不再是「保險起見多留 buffer」的便宜選項，而是實實在在讓月費翻倍的決定。
一個常見的浪費模式是 Docker 或 Kubernetes 部署裡每個容器都給了記憶體上限但用量遠低於上限。實務上跑 docker stats 或 kubectl top pod 觀察一週的實際峰值，多數容器的 RSS 只用到限額的三到五成。把上限往下修，讓 kernel 有更多空間做 page cache 才是划算做法。
另一個坑是 JVM 或 Node.js 應用預設 heap size 常常設得離譜。8GB 記憶體的機器上跑 Java 應用給了 -Xmx6g，剩下的 2GB 全部餵給 kernel 跟其他 process，作業系統的 page cache 幾乎沒空間，資料庫查詢的 I/O 就爆掉。合理的做法是 heap 抓總記憶體的 50%~65%，剩下留給 page cache 跟其他 process。
資料庫的記憶體參數也一樣。PostgreSQL 的 shared_buffers 建議值是總記憶體的 25%，MySQL 的 innodb_buffer_pool_size 是 60%~80%。這些數字是在記憶體便宜的年代訂出來的，2026 年可以稍微保守——特別是同一臺機器還跑其他 process 時，硬把 buffer 拉滿反而會逼作業系統開始 swap，得不償失。
zram 是 2026 年最被低估的工具
Linux 早在 kernel 3.14 就把 zram 併入主線，機制是在 RAM 裡開一塊區域當作壓縮的 block device，寫進去的頁面會用 lz4/zstd 壓縮，需要讀回來時解壓縮。壓縮比一般能做到 2 到 4 倍，也就是 4GB 的 zram 大概能塞 8 到 16GB 的實際資料。
在 2026 年記憶體單價這麼貴的背景下，這等於免費多出來的容量。實務設定不複雜：
1 | # Ubuntu/Debian 系 |
PERCENT=50 是把 zram 大小設成總記憶體的 50%，這個值在多數工作負載下都合理——太小起不到效果，太大會反過來壓縮到 anonymous page 讓 CPU 忙不完。演算法選 zstd 是壓縮率跟速度的較佳平衡，lz4 更快但壓縮率差一截。
搭配 kernel 參數調整效果更好：
1 | # /etc/sysctl.d/99-zram.conf |
swappiness=180（在有 zram 的情境下可以拉到超過 100，最高 200）告訴 kernel 遇到記憶體壓力時優先把 anonymous page swap 到 zram，而不是丟掉 page cache——因為 zram 在 RAM 裡，沒有 seek 成本，比磁碟 swap 快好幾個數量級。page-cluster=0 是因為 zram 沒有預讀好處，一次抓一個 page 就好。
實測資料是 4GB VPS 上跑一組典型 web + 資料庫組合，開啟 zram 加上調整 swappiness 後，OOM killer 觸發頻率從一週兩三次降到接近零，多個小型 process 的實際併發承載量提升約 30%。這個數字看起來不驚人，但換算成同樣負載可以少一階規格的 VPS，年度成本差距很可觀。
PSI 才是判斷記憶體到底夠不夠的正確訊號
free -m 只告訴你當下有多少可用記憶體，看不出來系統為了維持這個「可用」數字付出了什麼代價。Linux 4.20 之後引入的 PSI（Pressure Stall Information）才是生產環境該看的訊號，它會統計 process 因為等待記憶體而 stall 的比例，直接反映真實壓力。
1 | cat /proc/pressure/memory |
some 是至少有一個 process 因記憶體 stall 的時間比例，full 是所有 process 都在 stall 的時間比例。實務上 full avg60 > 10 就代表系統在 thrashing，some avg60 > 30 代表接近極限，該考慮加規格或優化應用了。
PSI 的價值在於它捕捉的是「持續壓力」，比 free -m 的瞬時值可靠得多。有些系統看起來記憶體用了 95%（因為 kernel 積極 cache），但 PSI 一直是 0——那是健康狀態。有些系統看起來 available 有 2GB，但 PSI full 常常飆到 20%——那是應用一直在等 page fault 回來，等於明顯的效能瓶頸。
Cgroup v2 也有對應的 memory.pressure，可以精準看到每個 container 或 systemd unit 的記憶體壓力。這個訊號比容器內看到的 free -m 準確得多，因為後者其實反映的是整臺機器的狀態，跟 cgroup 限額無關。
應用架構層面的取捨也得跟著調
記憶體變貴之後，過去某些預設「用 RAM 換效能」的架構決策就得重新評估。
Redis 或 Memcached 這類 in-memory cache 在記憶體便宜時是無腦解，2026 年得認真問這份快取有沒有必要。命中率低於 80% 的 cache 通常拿掉直接讓資料庫扛都比較划算——DRAM 貴、NVMe SSD 相對穩定，這個 trade-off 反過來了。有些場景改成 SQLite 用檔案系統的 page cache 反而比架一臺獨立 Redis 更省。
搜尋跟向量索引也一樣。過去很多人用 Elasticsearch 把整份資料的 inverted index 塞進記憶體，2026 年更值得評估的方向是 Meilisearch、Tantivy 這類設計上依賴 mmap 的方案——依賴 OS page cache 的 LRU 自然處理熱資料，不需要應用層強制 pin 到記憶體。
Kubernetes 部署上，memory.limit 設得過鬆是很常見的成本漏洞。VPA（Vertical Pod Autoscaler）跑一段時間搭配 PSI 觀察，把 limit 收到接近實際 P99 用量，往往可以省下三到四成的節點記憶體配置。
什麼時候該接受多花錢加規格
上面說的優化路線都是壓榨現有記憶體的作法，但有幾種情境優化不是答案。
寫入密集的資料庫工作負載——特別是 append-heavy 或 OLTP——需要足夠的 shared_buffers 才能維持 checkpoint 效率，硬壓到 zram 反而讓 fsync 排隊。JVM 應用在 heap 開始 GC thrashing 之後，怎麼調 swappiness 都沒救，該加就得加。ML inference 服務把模型權重載進 GPU 前得先過 CPU RAM，這條路徑上省不了。
一個實用的判斷法：跑三天觀察 PSI，如果 full avg300 > 5 而且 zram 壓縮率已經超過 3 倍還壓不下來，那就是真的不夠用了，該升級規格或分拆服務。
從供應鏈到應用層的一整條調整
DRAM 價格結構在未來兩三年不會回頭。這對整條運算基礎設施的成本模型是個結構性影響，不是短期波動可以躲過去的。VPS 選型、容器規格、應用參數、監控指標——這幾層過去憑感覺就能決定的東西，2026 年都得重新用「記憶體是最貴資源」的視角算一次帳。
臺灣本地的 VPS 供應商在這波記憶體荒下反而有相對優勢：不需要跟大 hyperscaler 搶美國本地供應鏈，機房採購彈性高，可以針對本地開發者跟企業客戶維持合理的規格對應。NCSE Network 位於臺灣是方電訊機房的 VPS 主機採用 Intel Xeon Gold CPU 與 NVMe SSD，記憶體規格對應臺灣本地用量需求，適合跑對記憶體使用效率敏感的服務。有需要規劃 VPS 部署或評估容量升級的，可以到 ncse.tw 看規格跟方案細節。
