SK하이닉스, SSD 컨트롤러에 맞춤형 소형 CPU 코어 탑재…아머 부하 경감 및 드라이브 속도 향상
🇰🇷 한글 번역
SK하이닉스, SSD 컨트롤러에 맞춤형 초소형 CPU 코어 탑재로 Arm 부하 경감 — 각 H-TPU는 CPU 코어 전력의 약 2.5%만 소모하는 것으로 알려짐
각 H-TPU는 반복적인 작업에 적합한 4단계 순차 파이프라인을 실행한다.
SK하이닉스는 전력 소모가 큰 CPU 코어에 대한 의존도를 줄이기 위해 자체 설계 코어인 ‘하이닉스 트랜잭션 처리 유닛(H-TPU)’을 도입할 계획을 상세히 밝혔다. AI 가속기와 혼동해서는 안 되는 H-TPU는 일반적으로 드라이브 속도가 빨라질수록 컨트롤러에 더 많은 코어를 요구하는 SSD가 처리하는 반복적인 작업을 보조하기 위해 설계되었다. 이 새로운 코어들은 클러스터 형태로 배치되며, 4단계 순차 파이프라인을 통해 일반적인 입출력(I/O) 작업을 처리하고, 관리 작업은 기존 Arm CPU에 맡긴다. 이 새로운 초소형 코어는 범용 CPU 코어 전력의 약 2.5%만 소모하며, 면적도 약 4%에 불과한 것으로 알려졌다. 이제 회사는 H-TPU를 제품군 전반에 적용할 계획이며, 이는 더이코일(TheElec)의 보도를 통해 알려졌다.
시스템온칩(SoC) 설계 담당 부사장 구인재는 이번 주 초 열린 국제 SoC 설계 컨퍼런스인 ISOCC 2026에서 “SSD 컨트롤러 CPU는 전력 및 면적 측면에서 한계에 도달했다”고 말했다. ‘SSD 컨트롤러에서 AI 메모리 SoC로’라는 제목의 발표에서 그는 PCIe 대역폭이 세대마다 두 배씩 증가하고 있으며, 컨트롤러 CPU의 클럭 속도와 제어 능력이 이를 따라잡지 못하고 있다고 밝혔다. SK하이닉스는 차세대 엔터프라이즈 SSD 컨트롤러를 포함한 NAND 제품 전반에 H-TPU를 적용할 계획인 것으로 알려졌다. 이는 IOPS(초당 입출력 연산 수)를 끊임없이 추구하는 과정에서 문제가 가장 명확하게 드러나는 부분이다.
구의 발언은 경쟁사 제품에서 발견되는 ‘코어 수 증가’ 해결책에서 명확히 드러나는 확장성의 문제를 강조한다. 마벨의 PCIe 6.0 브라베라 SC6는 6코어 클러스터 2개에 코텍스-R82 코어 12개와 코텍스-M7 코어 3개, 그리고 보안용 코텍스-M3를 사용한다. 이를 보안용 코텍스-M3를 제외한 코텍스-R8 및 코텍스-M7 코어 10개를 탑재한 PCIe 5.0 전작인 브라베라 SC5와 비교해보면, PCIe 속도 증가에 따라 코어 수가 필수적으로 증가했음을 알 수 있다.
SK하이닉스의 대안은 자체 설계 코어인 H-TPU로, 작고 프로그래밍 가능한 구조를 유지한다. 이 코어는 전용 컴파일러 및 특수 코드용 기타 개발 도구를 제공한다. H-TPU는 순차적 실행을 지원하는 4단계 파이프라인을 사용하며, 슈퍼스칼라 아키텍처가 아니며 순차 실행 외의 단위(out-of-order units)를 사용하지 않는다. 또한 AI용 텐서 프로세서와 혼동해서는 안 된다. 이 코어는 읽기 및 쓰기 명령어 처리, 메타데이터 관리, 버퍼 제어 등 반복적인 작업을 처리하도록 설계되었다.
스토리지 제어에는 100개 이상의 상세한 기능이 필요하며, 이는 단일(monolithic) CPU에는 이상적이지 않다. 대신 SK하이닉스는 이러한 기능들을 분할하여 ‘수십 개의 작은 TPU 클러스터’에 분산시켰다고 ZD넷 코리아(번역본)가 전했다. 따라서 각 H-TPU는 특화된 작업을 담당한다. H-TPU의 총 개수는 100개 이상이지만, 앞서 언급한 기능 수는 별개의 수치이다. 현재 각 클러스터에 몇 개의 코어가 포함되어 있는지에 대한 상세 정보는 아직 없다.
주요 CPU는 여전히 오류 복구 및 예외 처리, 그리고 스토리지 정책 관리를 담당하므로, H-TPU는 CPU를 대체하기보다 보완하는 역할을 한다. 이 설계는 특정 I/O에 필요하지 않은 코어들을 유휴 상태로 만들어 최소 전력 모드로 전환하는 것으로 알려졌다. 두 보도 모두 SK하이닉스의 2.5% 전력 및 4% 면적 수치를 뒷받침하는 구체적인 CPU 코어명을 명시하지 않았다.
이렇게 작업 부하를 분할하는 아이디어는 새로운 것이 아니다. Cortex-R5 코어를 경화된 매크로와 결합하여 반복적인 펌웨어 작업을 와이어 속도로 오프로드하는 파이션(Phison)의 CoXProcessor는 이미 일부 제품에 적용되어 왔다. 동사의 E18 SSD 컨트롤러는 세 개의 메인 코어를 보완하기 위해 두 개의 낮은 클럭 속도의 Cortex-R5 코어를 사용한다. 엔터프라이즈 부문에서는 파이션의 X1이 두 개의 Cortex-R5 코어와 각각 하나 또는 두 가지 작업에 전념하는 최대 32개의 ‘마이크로 코어’를 사용했다. H-TPU는 이러한 접근 방식을 더 큰 규모로 확장한다.
발표 자체는 세부 사항이 많지 않지만, 우리는 작은 코어와 CPU 간의 유사한 분할을 설명하는 여러 개의 SK하이닉스 특허를 발견했다. 2020년 11월 한국에서 처음 출원된 미국 특허 11,675,537호는 CPU가 실행하는 제어 플레인(control plane)과 작업에 따라 네 그룹으로 분류된 많은 소형 프로세서들로 구성된 I/O 플레인을 상세히 기술한다. 명령은 순서대로 네 단계를 통과한다: 호스트에서 ingestion(수집), 캐시, 맵(map), 그리고 NAND로 가는 NVM(비휘발성 메모리). 프로세서들은 이렇게 “데이터 I/O 작업을 위한 파이프라인을 구성”하여 CPU가 예외 상황을 처리할 수 있게 한다. 이 파이프라인은 많은 코어에 걸쳐 실행되며, 각 H-TPU 내부의 4단계 파이프라인과는 무관하다.
특허의 예시에서 각 소형 코어는 CPU의 “700만 개의 로직 게이트”에 비해 약 “20만 개의 로직 게이트” 정도이며, 이는 CPU 게이트 수의 약 2.9%에 해당한다. 이들은 고정된 요소가 아니다. “TPU 각각에서 펌웨어가 구동될 수 있기” 때문에, 특허가 ‘수정하기 어렵다’고 지칭하는 하드웨어 회로보다 더 유연하다. 특허는 TPU를 ‘텐서 처리 유닛(Tensor Processing Units)’으로 명시하고 있지만, 다시 한번 말하지만 이는 AI 가속기와 혼동해서는 안 된다. H-TPU는 그러한 프로그래머블 접근 방식을 공유하지만, SK하이닉스가 설명한 다음 단계는 일부 일상적인 작업을 고정 하드웨어로 이동시킨다.
이 다음 단계는 하드웨어 자동화(HWA)이며, 명령 처리, 주소 조회 및 버퍼 복사가 전용 회로로 이동한다. CPU와 H-TPU는 여전히 예외 상황과 주요 정책 결정을 처리한다. 이러한 프레임워크로 전환하는 것은 완료 시간을 예측 가능하게 유지하려는 것으로, 이는 특히 오늘날의 높은 IOPS를 갖춘 엔터프라이즈 SSD와 같은 I/O에 필수적이다.
SK하이닉스는 이미 고정 하드웨어 경로에 대해 출원한 바 있다. 산호세에 위치한 자회사가 2014년에 출원한 사례와, 2022년 한국에서 처음 출원된 미국 특허 12,216,914호가 있다. 후자는 ‘쓰기 자동화 회로’를 설명하며 “지능형 제어가 필요 없는 작업은 하드웨어 레이어를 통해 처리되거나 처리될 수 있다”고 명시하는 반면, 펌웨어는 가비지 컬렉션과 같은 작업을 유지한다. 전자는 더 나아가 기본 I/O 명령을 “하드웨어로 완전히 구현된 경로”로 보내며, 처리할 수 없는 것은 상위로 전달한다.
보고에 따르면 H-TPU는 SK하이닉스와 나비디아(Nvidia)의 공동 프로젝트인 AIN P의 명칭인 ‘Storage Next’에서 사용되고 있다. Storage Next는 전통적으로 더 큰 운영 크기를 목표로 하는 NAND를 사용하여 512바이트 또는 그 이상의 제한된 접근을 목표로 한다. SK하이닉스는 또한 이를 내년 출시 예정인 고대역폭 플래시(HBF)에 적용할 계획이다. HBF는 AI 추론을 위해 NAND 다이(die)를 스택하며, HBM4의 64GB 대비 최대 512GB까지 훨씬 더 많은 용량을 가지면서 고대역폭 메모리(HBM) 수준의 대역폭을 목표로 한다.
HBF의 경우, AI 추론에서 읽기 작업은 쓰기 작업보다 약 300,000 대 1의 비율로 많으며, AI 컴파일러와 런타임은 미리 분석된 데이터플로우를 HBF SoC로 전달한다. 이러한 데이터플로우를 기반으로 한 적절한 버퍼 관리와 프리페칭(prefetching)은 계산 처리 뒤에 느린 NAND 지연 시간을 숨기는 것을 목표로 한다. HBF 스택에서 크기는 중요하므로, 전통적인 멀티코어 Arm 설계는 덜 실용적일 가능성이 높다.
H-TPU는 아직 실제 엔터프라이즈 SSD 컨트롤러 제품에서 입증되지 않았으며, 출시 일정도 발표되지 않았다. 범용 CPU 코어에서 단일 작업 전용 코어 및 회로로의 전환은 SSD가 처리하는 워크로드 유형과 일치하며, AI 서버가 메모리 제약에 직면함에 따라 스토리지에 대한 요구사항은 더욱 증가하고 있다.
SK하이닉스의 성명서와 특허들은 H-TPU를 거쳐 HWA로 나아가는 진화 방향을 지지하며, H-TPU 자체는 기존 NAND와 내년 출시 예정인 HBF(하이브리드 브릿지 파이버)를 향해 나아가고 있다. 단순한 스케일링은 현재 PCIe 수준에서도 최적의 해결책이 아니며, PCIe 7.0과 8.0에서 약속된 속도에 이르러서는 더욱 그러하다. 특히 PCIe 8.0은 2028년 최종 표준화될 예정이다.
Shane Downing은 Tom’s Hardware의 기고 작가로, 소비자용 스토리지, PC 하드웨어 및 AI 분야를 담당하고 있다.
📄 원문 (English)
SK hynix to place custom tiny CPU cores in its SSD controllers to ease Arm load as drive speeds rocket — each H-TPU reportedly draws 2.5% of a CPU core’s power
Each H-TPU runs a four-stage, in-order pipeline suited to repetitive work.
SK hynix has detailed plans to reduce reliance on power-hungry CPU cores with an in-house core named a Hynix Transaction Processing Unit (H-TPU). Not to be confused with an AI accelerator, an H-TPU would assist with repetitive work handled by an SSD, which usually demands more cores on a controller as drives get faster. These new cores are placed in clusters and would handle routine I/O with a four-stage, in-order pipeline, while management is left to the traditional Arm CPU. The new, tiny cores are claimed to draw only about 2.5% of a general-purpose CPU core’s power, with just around 4% of its area. Now, the company plans to apply H-TPU across its portfolio of products, TheElec reports.
The company’s VP of system-on-chip (SoC) design, Koo In-jae, spoke at ISOCC 2026, the International SoC Design Conference, earlier this week, saying that SSD controller CPUs are at their limit on power and area. In the talk, titled “From SSD Controllers to AI Memory SoCs,” he said that PCIe bandwidth doubles every generation, and controller CPU clocks and control capability reportedly can’t keep up. SK hynix reportedly plans to apply H-TPU across its NAND products, including next-gen enterprise SSD controllers. That’s where the unending chase for IOPS makes the problem most evident.
Koo’s comments underline the issue of scaling, which is evident in the “more cores” solutions found in competitor products. Marvell’s PCIe 6.0 Bravera SC6 uses 12 Cortex-R82 cores in two six-core clusters with three Cortex-M7 cores and a secure Cortex-M3. Compare this to its PCIe 5.0 predecessor, the Bravera SC5, which lists 10 Cortex-R8 and Cortex-M7 cores plus a Cortex-M3 for security. Core counts have climbed with PCIe speeds out of necessity.
SK hynix’s answer is a core of its own design: the H-TPU, kept small and programmable. It comes with a dedicated compiler and other development tools for specialized code. It’s stated to use a four-stage pipeline with in-order, or sequential, execution. It is not superscalar, does not use out-of-order units, and should not be confused with a tensor processor for AI. It is designed to handle read and write command processing, manage metadata, and handle buffer control, all repetitive tasks.
Storage control requires more than 100 detailed functions, which is not ideal for a monolithic CPU. Instead, SK hynix broke those functions up and spread them across “dozens of small TPU clusters,” according to ZDNet Korea (translated). Each H-TPU therefore has a specialized job. The total number of H-TPUs is more than 100; the function count above is a separate figure. However we currently have no details on how many cores each cluster holds.
The main CPU still handles error recovery and exception handling, plus storage-policy management, so the H-TPU complements the CPU: offloading, not replacement. The design idles the cores a given I/O doesn’t need, which reportedly drop into a minimum-power mode. Neither report names the CPU core behind SK hynix’s 2.5% power and 4% area figures.
Splitting the workload this way is not a new idea. Phison’s CoXProcessor, which pairs Cortex-R5 cores with hardened macros to offload repetitive firmware at wire speed, has been in products for some time. The company’s E18 SSD controller uses two lower-clocked Cortex-R5 cores to supplement the three main ones. On the enterprise side, Phison’s X1 used two Cortex-R5 cores plus up to 32 “micro cores,” each dedicated to one or two tasks. H-TPU takes this approach to a larger scale.
While the talk itself is light on detail, we discovered multiple SK hynix patents that describe a similar split between small cores and a CPU. U.S. patent 11,675,537, first filed in Korea in November 2020, details a CPU-run control plane and an I/O plane of many small processors, sorted into four groups by job. A command passes through all four in order: host for ingestion, cache, map, and NVM to the NAND. The processors “configure a pipeline for the data I/O operation” this way, letting the CPU handle any exceptions. That pipeline runs across many cores and is unrelated to the four-stage pipeline inside each H-TPU.
In the patent’s example, each small core is around “200,000 logic gates” rather than the “seven million logic gates” of the CPU, or about 2.9% of the CPU’s gate count. These are not fixed elements, as “firmware may be driven in each of the TPUs,” making them more adaptable than the hardware circuits the patent calls “difficult to modify.” The patent spells out TPU as “Tensor Processing Units,” but, again, this should not be confused with AI accelerators. H-TPU shares that programmable approach, but the next step SK hynix described moves some routine jobs into fixed hardware.
This next step is hardware automation (HWA), with command processing, address lookup, and buffer copies moved to dedicated circuits. The CPU and H-TPUs still handle exceptions and key policy decisions. Moving to this framework is meant to keep completion times predictable, which is necessary with I/O, especially for today’s high-IOPS enterprise SSDs.
SK hynix has filed on fixed-hardware paths before, with a 2014 filing by its San Jose-based unit and, later, with U.S. patent 12,216,914, first filed in Korea in 2022. The latter describes a “write automation circuit” and says “a task without intelligent control can be handled or processed through the hardware layer,” while firmware keeps jobs such as garbage collection. The former went further, sending basic I/O commands down a path “completely implemented in hardware,” with anything it couldn’t handle being sent upstream.
The H-TPU itself is reportedly being used in “Storage Next,” Nvidia’s name for the joint AIN P project with SK hynix. Storage Next targets 512-byte or more limited access with NAND, which traditionally aims at higher operating sizes. SK hynix also plans to apply it to high-bandwidth flash (HBF), which the outlet said is due next year. HBF stacks NAND dies for AI inference, targeting high-bandwidth memory (HBM) levels of bandwidth but with far more capacity, with up to 512GB per stack versus 64GB for HBM4.
For HBF, AI inference reads outnumber writes around 300,000 to 1, with the AI compiler and runtime passing pre-analyzed dataflow to the HBF SoC. Proper buffer management and prefetching based on that dataflow are meant to hide the slow NAND latency behind compute. Size is important in HBF stacks, so a traditional multi-core Arm design is likely less practical.
H-TPU has yet to be proven in an actual enterprise SSD controller product, and no date has been given. The move from general-purpose CPU cores to specialized single-job cores and circuits matches the type of workload SSDs handle, and the demands on storage are only increasing as AI servers become memory-constrained.
SK hynix’s statements and patents support an evolution to H-TPU and beyond to HWA, with H-TPU itself headed for traditional NAND and next year’s HBF. SSD controller manufacturers must be willing to adapt, as simple scaling is suboptimal even at current PCIe levels, let alone the speeds promised for PCIe 7.0 and 8.0, the latter headed for final ratification in 2028.
Shane Downing is a Contributing Writer for Tom’s Hardware, covering consumer storage, PC hardware, and AI.
▶ 칩 라이브 24 홈으로 — chiplive24.com