Typed Memory 架構：簡介 MTLHeap / IOSurface
．作者：Jollen
．日期：August 25, 2026 at 8:00 AM
AI 推論引擎的記憶體管理，現在看起來是一門「硬功夫」；也是 AI ASIC 晶片的核心技術之一。
把記憶體裝好裝滿，或許能滿足大部分 LLM 的 Runtime 需求。不過，記憶體不夠就加，這種「一點也不手軟」的解決方案，或許適合 GPU 工作站，但對手機硬體來說，實在太奢侈。
面對「非皇家頂規」的硬體，比起泛化的「記憶體越大越好」觀念，做好記憶體管理，反倒比較實際一點。
Typed Memory 架構：簡介 MTLHeap / IOSurface
延續 Qwen3.5 的研究；討論記憶體管理時，最直覺的想法通常是「還剩多少 RAM」。但面對圖形運算、影像處理與 AI 推論來說，真正的問題是：
- 如何配置有效記憶體
- 這塊記憶體拿來做什麼
- 多久後要回收此記憶體（記憶體空間可以存活多久）
這個技術議題，統稱為 Typed Memory。
認識 Typed Memory
用白話的方式來講，Typed Memory 就是讓記憶體依照用途、硬體特性與生命週期，分成不同類型。
例如，QNX OS 的 POSIX Typed Memory，就是很經典的 Typed Memory 實作。QNX 能在系統啟動時，事先規劃並預留 memory pool，例如 reserved video memory，讓這些特定用途的記憶體與一般 SYSRAM 分開；應用程式再透過具名（typed）的 memory object 使用這些 memory region。
Typed Memory 也能指定 contiguous allocation，適合有實體位址或 DMA 條件的硬體。於是記憶體開始有了「用途」：
System RAM
├── General Memory
├── Graphics Memory
├── DMA Memory
└── Special-purpose Memory
iOS App 透過 Metal 技術，也能實作 typed memory 技術；而其中最值得研究的是 MTLHeap 與 IOSurface。
MTLHeap：建立 Memory Resources
Apple Metal 將 MTLHeap 定義為可進一步配置 resources 的 memory pool。開發者可先配置一大塊 GPU 專用的記憶體，再經由 Heap 建立 MTLBuffer、MTLTexture 等存取資源。
一個簡單的 Swift 實作範例如下：
let length = 16 * 1024 * 1024
let layout = device.heapBufferSizeAndAlign(
length: length,
options: .storageModePrivate
)
let descriptor = MTLHeapDescriptor()
descriptor.storageMode = .private
descriptor.size = layout.size
let heap = device.makeHeap(descriptor: descriptor)
let buffer = heap?.makeBuffer(
length: length,
options: .storageModePrivate
)
heapBufferSizeAndAlign() 會先計算 Heap resource 所需要的大小與 alignment，再建立 Heap。
更重要的能力是 aliasing：
- 假設運算流程有 A、B、C 三個大型暫存 buffer
- A 用完後才會使用 B
- B 用完才使用 C
- 當以上 A/B/C 三者沒有同時存在的必要時，就有機會重複利用同一段 Heap backing memory
Apple Silicon 也把這種 transient resource sharing 列為重要記憶體管理技術；這也是降低 Metal App memory footprint 的方法。
因此，MTLHeap 真正管理的問題是：
需要多少記憶體
+
什麼時候需要
+
什麼時候可以重用
這已經非常接近 Typed Memory Architecture 的設計哲學。
IOSurface：共享記憶體
IOSurface 處理的是另一個常見問題：共享 image buffer。 影像處理的 Pipeline 流程如下：
Image
→ Pixel Buffer
→ RGB Buffer
→ Metal Texture
→ Tensor
若每一流程，都產生一份 image copy，Memory Peak 很快快速上升（記憶體使用量突增）。因此，成熟的 App 架構會思考：哪些工作能共用 backing memory。
IOSurface 就是為了這類問題，所提供的記憶體管理基礎設施。
Apple 將 IOSurface 定義為可分享 hardware-accelerated framebuffer 與 texture data 的機制，目的之一就是更有效率地管理 image memory。
例如，可以建立一個簡單的影像 surface：
import IOSurface
let width = 1920
let height = 1080
let bytesPerRow = width * 4
let surface = IOSurface(properties: [
.width: width,
.height: height,
.bytesPerElement: 4,
.bytesPerRow: bytesPerRow,
.allocSize: bytesPerRow * height
])
這塊 backing memory 可以成為不同影像處理元件之間交換資料的基礎。Apple 的官方文件也指出，IOSurface-backed pixel buffer 可以在 CPU、GPU，甚至跨 process 分享。
MTLHeap 與 IOSurface 解決不同問題
MTLHeap 著重 Metal resources 的 allocation、lifetime 與 memory reuse；IOSurface 則著重 image buffer 的共享與跨元件交換。
兩者以 Typed Memory 架構的角度來看，可以得到以下結論：
Memory
├── Persistent
│ └── 長時間存在
├── Transient
│ └── 運算完成即可重用
└── Shared Image
└── 多個處理階段共用
使用 Typed Memory 觀念，iOS App 的記憶體管理就會具有「角色」與「生命週期」。
為什麼 AI 推論引擎需要這種架構
AI 推論引擎（inference runtime），對 Typed Memory 有迫切需求。
一個完整的 inference runtime，包含以下處理單元：
- Model Weights
- KV Cache
- Recurrent State
- Activations
- Compute Scratch
- Image Buffer
- Vision Encoder intermediate tensors
- Output tokens
每一個處理單元都會「用到記憶體」。如果老是用「暴力法」來管理記憶體，就會造成 Memory Peak 問題。所謂的暴力法，就是不顧一切地配置記憶體（memory malloc），需要更大量的記憶體時，就升級硬體以滿足需求。
Memory Peak 經常出現在多組大型 buffer 同時存活 的情況。
在 iPhone 作業系統環境下，iOS 會監控 App 的總記憶體使用量，當其使用量超過限制時，系統會直接終止 App，造成「閃退」現象。
解決「閃退」問題的方法，就是使用 Metal Heap 來實作 Typed Memory 記憶體管理架構。
未來的 on-device AI Runtime（Local LLM），需要管理的不只是模型，也包含整個 inference pipeline 的記憶體生命週期。MTLHeap 與 IOSurface 提供了兩個很好的切入點：前者管理 GPU resource 的配置與重用，後者降低影像資料在不同處理階段反覆複製的需求。