What do HBM, DRAM, NAND, eMMC, UFS and SSDs do in AI devices?

HBM belongs to DRAM: it is high-bandwidth, volatile working memory located close to a GPU or AI accelerator. NAND is a nonvolatile medium that can retain data without power. eMMC, UFS, SSDs and microSD are not four raw materials alongside NAND; they combine NAND, controllers, firmware and interfaces into different storage products.

This article focuses on NAND-based storage matching within Kalstor's confirmed supply scope. It does not make an HBM or server-DRAM supply commitment. Calling a device an AI product does not remove the need to check its interfaces and workload.

Image disclosure: the cover is an AI-generated representative workbench scene, not a factory photograph, customer board or bill of materials. HBM, exact component identities and compatibility cannot be established from the image.

Why does an AI device need both memory and persistent storage?

During inference, the device needs low-latency access to active weights, intermediate results and program state. After shutdown, it may still need to retain its operating system, model files, configuration, recordings, maps, logs and update packages. DRAM usually supports the first task; NAND-based storage commonly supports the second. The two exchange data but do not replace one another.

This distinction matters when a purchasing request says only “AI memory.” A request for model execution bandwidth is different from a request to retain seven days of video. Before choosing a part, identify which task needs more capacity or performance.

What do HBM and other DRAM types do?

DDR and LPDDR supply working memory to CPUs, systems-on-chip and some accelerators. HBM uses stacked DRAM dies, a wide interface and close integration with the processor to deliver high bandwidth. Micron describes its HBM architecture, while Samsung lists DDR, LPDDR, GDDR and HBM within its DRAM portfolio [1][2].

More HBM capacity does not provide SSD-like persistence. A model is commonly read from persistent storage into working memory before computation. Nor does every AI device use HBM: many edge platforms use DDR or LPDDR. The processor and system architecture determine the memory type. A data-center accelerator's design is not a specification for a camera, AGV or pair of smart glasses.

How are NAND, eMMC, UFS, SSDs and microSD related?

Raw NAND leaves more media-management responsibility to the host or an external controller; the exact division, including ECC, depends on the device. Managed storage integrates a controller and management logic into a package or module. Micron explicitly identifies microSD, eMMC and UFS as fully managed NAND products with internal media management and ECC [3].

A platform may use several media together. NVIDIA's Jetson AGX Orin Developer Kit documentation lists onboard eMMC and optional NVMe, USB storage and microSD support [4]. That is one platform example, not proof that every AI board supports all four paths or that any Kalstor part is qualified on it.

Which storage requirements belong to each task?

• Model loading: sequential reads, random access, startup latency and usable capacity.
• System startup: host boot support, partition layout, repeated starts and update recovery.
• Continuous recording: sustained writes, overwrite cycles, temperature and file integrity.
• Logs and sensor data: small writes, synchronization policy, write amplification and interruption behavior.
• OTA updates: space for downloads, snapshots or A/B partitions and rollback, according to the actual update design.

The same device can run several of these tasks concurrently. A specification based only on a sequential read benchmark can therefore miss the behavior that interrupts recording or delays startup.

Why is capacity alone insufficient?

A “128GB” label identifies a capacity class. It does not specify interface support, sustained write behavior, random latency, NAND, controller, firmware, temperature limits or endurance. An unsupported interface can prevent a device from booting. A high peak read figure does not guarantee reliable recording under the target write load.

For the physical and protocol trade-offs, see our embedded-storage comparison. For supply decisions, keep the architecture distinction separate from HBM and NAND market signals.

What should the project checklist contain?

1. Device, SoC and supported boot media.
2. eMMC/UFS version or SATA, PCIe/NVMe and SD host interfaces.
3. BGA package, SSD dimensions or socket design.
4. Capacity for the system, models, caches, logs, video and updates.
5. Sequential and random I/O, concurrency, latency and near-full behavior.
6. Daily writes, overwrite policy, target service life and retention needs.
7. Operating temperature, cooling, vibration and abnormal power interruption.
8. Controlled BOM, firmware, lot traceability, change notification and lifecycle.

How can Kalstor help?

Send the device, host, interface, package, capacity, workload, environment and project quantity through our project inquiry form. Within the confirmed product range, Kalstor can organize candidate configurations and a sample-validation checklist. A candidate is not a compatibility approval: the result must be tied to the actual host and controlled configuration.

The references below explain technology classes and example platforms. They do not establish Kalstor supply of HBM/DRAM or qualification of Kalstor storage on those platforms.