Built to Deliver the Answer, Not to Train the Model

Source: https://semiwiki.com/semiconductor-manufacturers/vsora/374232-built-to-deliver-the-answer-not-to-train-the-model/

For more than a decade, the AI hardware industry focused mainly on model training, while inference represented a smaller share of overall demand. That balance is changing as trained models are deployed widely in recommendation engines, content-generation systems, transcription and translation services, and autonomous devices. Industry estimates now place inference at most data-center AI workloads.

1세대 넘게 AI 하드웨어 산업은 주로 모델 학습(Training)에 초점을 맞춰왔으며, 전체 수요에서 추론(Inference)이 차지하는 비중은 상대적으로 작았습니다. 하지만 학습된 모델들이 추천 엔진, 콘텐츠 생성 시스템, 음성 변환 및 번역 서비스, 자율주행 기기 등에 널리 배치되면서 이러한 균형이 변화하고 있습니다. 현재 업계 추정에 따르면 데이터 센터 AI 워크로드의 대부분을 추론이 차지하고 있습니다.

The growth of inference is changing how processor performance should be measured. Peak FLOPS alone no longer provide an adequate measure. What matters is the useful throughput a system can deliver within limits on latency, power, memory, and cost. These factors determine system capacity, operating economics, and the user’s experience.

추론의 성장은 프로세서 성능이 측정되는 방식을 바꾸고 있습니다. 최고 플롭스(Peak FLOPS) 수치만으로는 더 이상 적절한 측정 기준이 되지 못합니다. 중요한 것은 지연 시간(Latency), 전력, 메모리, 비용의 한계 내에서 시스템이 제공할 수 있는 유효 처리량(Useful throughput)입니다. 이러한 요인들이 시스템 용량, 운영 경제성, 그리고 사용자 경험을 결정합니다.

This change exposes a mismatch between established AI processors and the requirements of inference. Most existing platforms were developed to accelerate the dense, highly parallel floating-point operations used in model training. Inference places greater demands on data movement, must handle workloads that change quickly, and often operates under strict latency limits. It must also run efficiently in both data centers and edge devices. Hardware designed mainly for training may therefore be poorly suited to delivering answers.

이러한 변화는 기존의 AI 프로세서와 추론 요구 사항 사이에 불일치가 존재함을 드러냅니다. 기존 플랫폼 대부분은 모델 학습에 사용되는 밀집된(Dense) 고병렬 부동소수점 연산을 가속하기 위해 개발되었습니다. 반면 추론은 데이터 이동에 대한 요구가 더 크고, 빠르게 변화하는 워크로드를 처리해야 하며, 엄격한 지연 시간 제한 하에서 작동하는 경우가 많습니다. 또한 데이터 센터와 엣지 디바이스 모두에서 효율적으로 구동되어야 합니다. 따라서 주로 학습용으로 설계된 하드웨어는 답변을 도출하는 데 부적합할 수 있습니다.

The Changing Computation Profile of AI Inference

Training and inference place different demands on a processor. Both involve substantial computation and data movement, but they are measured differently. Training emphasizes aggregate throughput and the time required to complete a large job, usually with large, regular batches. Inference places more emphasis on useful throughput, predictable latency, efficient use of memory, and operating cost under workloads that can vary from one request to the next.

학습과 추론은 프로세서에 서로 다른 요구 사항을 부과합니다. 둘 다 상당한 연산과 데이터 이동을 수반하지만, 측정 방식은 다릅니다. 학습은 보통 크고 규칙적인 배치(Batch)를 통해 대규모 작업을 완료하는 데 필요한 총 처리량과 시간을 강조합니다. 반면 추론은 요청마다 달라질 수 있는 워크로드 환경에서 유효 처리량, 예측 가능한 지연 시간, 효율적인 메모리 사용, 그리고 운영 비용을 더 강조합니다.

The main differences concern latency, timing predictability, numerical precision, power and cost, and memory access.

주요 차이점은 지연 시간 민감도, 타이밍 예측 가능성, 수치 정밀도, 전력 및 비용, 그리고 메모리 접근 방식과 관련이 있습니다.

Latency Sensitivity

Training can generally tolerate high latency for an individual operation because the objective is to process as much data as possible over the full training run. Inference, especially in interactive applications, must respond within a predictable time. Conversational systems need a short time to first token and a low delay between successive tokens. Perception and control systems may have firm deadlines. Average latency is therefore not enough; consistency and tail latency also matter.

학습은 전체 학습 과정 동안 가능한 한 많은 데이터를 처리하는 것이 목적이므로 일반적으로 개별 연산의 높은 지연 시간을 용인할 수 있습니다. 그러나 추론은 특히 대화형 애플리케이션에서 예측 가능한 시간 안에 응답해야 합니다. 대화형 시스템은 첫 토큰 생성 시간(Time to first token)이 짧아야 하고 연속된 토큰 간의 지연이 적어야 합니다. 인지 및 제어 시스템은 엄격한 마감 기한을 가질 수도 있습니다. 따라서 평균 지연 시간만으로는 부족하며, 일관성과 테일 지연(Tail latency) 역시 중요합니다.

Timing Predictability

Timing predictability is related to latency, but it is not the same measure. Two systems may have the same average latency while differing greatly in the range of response times. That range determines whether a service meets its latency target or a control loop meets its deadline. Predictable timing is therefore an architectural goal. It depends on how consistently the processor moves data and schedules work.

타이밍 예측 가능성은 지연 시간과 관련이 있지만 동일한 측정 기준은 아닙니다. 두 시스템의 평균 지연 시간이 같더라도 응답 시간의 범위는 크게 다를 수 있습니다. 이 범위는 서비스가 지연 시간 목표를 충족하는지 또는 제어 루프가 마감 기한을 준수하는지를 결정합니다. 따라서 예측 가능한 타이밍은 아키텍처적 목표가 됩니다. 이는 프로세서가 얼마나 일관되게 데이터를 이동하고 작업을 스케줄링하는지에 달려 있습니다.

Numerical Precision

Precision requirements also differ. Training commonly uses mixed-precision arithmetic—for example, FP32 for selected operations and BF16, FP16, or TF32 for much of the remaining computation—to maintain numerical stability while the model learns. Inference does not update the model parameters and can often use lower precision. INT8, FP8, INT4, or FP4 can reduce model size, memory traffic, and energy use, provided that model accuracy remains acceptable.

정밀도 요구 사항도 다릅니다. 학습은 모델이 학습하는 동안 수치적 안정성을 유지하기 위해 일반적으로 혼합 정밀도 연산(예: 특정 연산에는 FP32, 나머지 대다수 연산에는 BF16, FP16, 또는 TF32)을 사용합니다. 반면 추론은 모델 파라미터를 업데이트하지 않으므로 더 낮은 정밀도를 사용하는 경우가 많습니다. 모델의 정확도가 허용 가능한 수준으로 유지된다면, INT8, FP8, INT4, 또는 FP4는 모델 크기, 메모리 트래픽, 그리고 에너지 소모를 줄일 수 있습니다.

Power and Cost

Power and cost become especially important in inference. Training concentrates a large amount of computation into a finite run, even if that run takes weeks or months. Inference operates continuously and may serve millions of requests over a model’s deployed life. Small inefficiencies are repeated on every request. Hardware utilization, energy efficiency, and cost per useful output therefore have a direct effect on operating expense.

전력과 비용은 추론에서 특히 중요해집니다. 학습은 수주 또는 수개월이 걸릴지라도 막대한 양의 연산을 유한한 실행 기간 동안 집중시킵니다. 하지만 추론은 지속적으로 작동하며 모델의 배포 수명 동안 수백만 건의 요청을 처리할 수 있습니다. 작은 비효율성이라도 모든 요청마다 반복됩니다. 따라서 하드웨어 활용도, 에너지 효율성, 그리고 유효 출력당 비용은 운영 비용에 직접적인 영향을 미칩니다.

Memory-access Behavior

Memory behavior is often the most important difference. During transformer inference, the processor must repeatedly access the model weights and key-value cache. Autoregressive decode may perform relatively little computation for each byte moved, particularly at low batch sizes. Under these conditions, performance depends more on memory bandwidth, capacity, and efficient data movement than on peak arithmetic throughput.

메모리 행동은 종종 가장 중요한 차이점입니다. 트랜스포머(Transformer) 추론 동안 프로세서는 모델 가중치와 키-값(KV) 캐시에 반복적으로 접근해야 합니다. 자기회귀적 디코딩(Autoregressive decode)은 특히 낮은 배치 크기에서 이동하는 바이트당 상대적으로 적은 연산을 수행할 수 있습니다. 이러한 조건에서는 최고 산술 처리량보다 메모리 대역폭, 용량, 그리고 효율적인 데이터 이동이 성능을 좌우합니다.

Most current models are too large to fit entirely in on-chip SRAM or cache, so their parameters must be fetched from high-bandwidth memory and sometimes moved across several devices. Every step through the memory hierarchy consumes time and energy. When data cannot reach the arithmetic units quickly enough, those units sit idle and delivered throughput falls.

대부분의 최신 모델은 온칩 SRAM이나 캐시에 통째로 담기에는 너무 크기 때문에, 파라미터들을 고대역폭 메모리(HBM)에서 가져와야 하며 때로는 여러 기기 간에 이동시켜야 합니다. 메모리 계층 구조를 거치는 모든 단계에는 시간과 에너지가 소모됩니다. 데이터가 연산 유닛에 충분히 빠르게 도달하지 못하면 해당 유닛들은 유휴 상태로 대기하게 되고, 최종 처리량은 떨어지게 됩니다.

Not all inference is memory-bound. Prompt processing, or prefill, can be compute-intensive, especially with long inputs and large batches. Token-by-token decode, however, is often limited by memory bandwidth. The balance depends on batch size, sequence length, model architecture, quantization, caching strategy, and serving software.

모든 추론이 메모리 병목(Memory-bound) 현상을 겪는 것은 아닙니다. 프롬프트 처리 과정인 프리필(Prefill)은 특히 긴 입력과 큰 배치 조건에서 연산 집약적(Compute-intensive)일 수 있습니다. 그러나 토큰 단위의 디코딩은 종종 메모리 대역폭에 의해 제한됩니다. 이러한 균형은 배치 크기, 시퀀스 길이, 모델 아키텍처, 양자화, 캐싱 전략, 그리고 서빙 소프트웨어에 따라 달라집니다.

Peak throughput therefore tells only part of the inference-performance story. The more useful measure is the work completed within stated limits on latency, power, memory, and cost. Processor design must focus on keeping the arithmetic units supplied with data, not simply on increasing their theoretical capacity.

따라서 최고 처리량은 추론 성능 이야기의 일부분만을 말해줄 뿐입니다. 더 유용한 지표는 지연 시간, 전력, 메모리, 비용에 대한 명시된 한계 내에서 완료된 작업량입니다. 프로세서 설계는 이론적 용량을 단순히 늘리는 것이 아니라, 연산 유닛에 데이터가 끊김 없이 공급되도록 유지하는 데 초점을 맞춰야 합니다.

Table I captures the main differences between training and inference.

표 I는 학습과 추론 사이의 주요 차이점을 요약합니다.

Table I: Main differences between training and Inference based on a set of criteria

VSORA’s Architectural Innovations

VSORA starts from a different architectural background. Drawing on digital signal-processing techniques, the company designed its architecture for inference rather than adapting a platform originally built for general-purpose parallel computing. Its main target is the memory wall: the widening gap between the rate at which arithmetic units can perform calculations and the rate at which memory can supply data. VSORA coordinates computation, memory access, and data movement in an effort to keep its arithmetic resources working for more of each execution cycle.

VSORA는 완전히 다른 아키텍처적 배경에서 출발합니다. 디지털 신호 처리(DSP) 기법을 활용하여, 범용 병렬 컴퓨팅을 위해 원래 제작된 플랫폼을 개조하는 대신 처음부터 추론(Inference)에 최적화된 아키텍처를 설계했습니다. 이들의 주된 타깃은 바로 메모리 벽(Memory wall), 즉 산술 연산 장치가 계산을 수행하는 속도와 메모리가 데이터를 공급하는 속도 사이에서 벌어지고 있는 격차입니다. VSORA는 연산, 메모리 접근, 그리고 데이터 이동을 조율함으로써 각 실행 주기의 더 많은 시간 동안 산술 자원이 멈추지 않고 가동되도록 만듭니다.

The following sections describe its on-chip memory, support for work beyond neural-network operations, software stack, and chiplet-based scaling.

다음 절에서는 온칩 메모리, 신경망 연산 이외의 작업 지원, 소프트웨어 스택, 그리고 칩렛 기반의 확장성에 대해 설명합니다.

VSORA’s Architecture Targets the Memory Wall

One of VSORA’s main departures from conventional designs is its treatment of on-chip memory. GPUs distribute data among registers, shared memory, caches, and external high-bandwidth memory, each with different capacity, bandwidth, and latency. VSORA instead exposes its on-chip working memory through what the company calls a single, large register file.

기존 설계와 구별되는 VSORA의 가장 큰 특징 중 하나는 온칩 메모리를 다루는 방식입니다. GPU는 데이터가 각각 다른 용량, 대역폭, 그리고 지연 시간을 가진 레지스터, 공유 메모리, 캐시, 그리고 외부 고대역폭 메모리(HBM) 사이에 분산되어 있습니다. 반면 VSORA는 회사가 '단일 대형 레지스터 파일(Single, large register file)'이라고 부르는 방식을 통해 온칩 작업 메모리를 노출합니다.

This is not a conventional register file made entirely from flip-flops. It is a programming abstraction implemented with a large on-chip SRAM structure. VSORA says that the compute resources can directly address every location with single-cycle throughput. Data already in the on-chip working set can therefore be retrieved without passing through a conventional cache hierarchy.

이것은 전부 플립플롭(Flip-flop)으로 만들어진 전통적인 레지스터 파일이 아닙니다. 대규모 온칩 SRAM 구조로 구현된 프로그래밍 추상화 계층입니다. VSORA에 따르면 연산 자원은 단일 주기 처리량으로 모든 위치에 직접 접근할 수 있습니다. 따라서 이미 온칩 작업 세트에 들어 있는 데이터는 기존의 캐시 계층 구조를 거치지 않고 곧바로 가져올 수 있습니다.

The design has features of both scratchpad memory and compute-near-memory systems. A GPU relies on hardware-managed caches to retain and replace data in response to observed access patterns. VSORA instead uses the compiler to schedule data placement, movement, and computation explicitly. This reduces the timing variation caused by cache hits, misses, and replacement decisions. Once the compiler sets the movement and placement of data, execution time becomes more predictable. That predictability helps an inference system control tail latency rather than merely improve its average response time.

이 설계는 스크래치패드 메모리(Scratchpad memory)와 메모리 근접 연산(Compute-near-memory) 시스템의 특징을 모두 가지고 있습니다. GPU는 관찰된 접근 패턴에 반응하여 데이터를 유지하고 교체하기 위해 하드웨어가 관리하는 캐시에 의존합니다. 하지만 VSORA는 컴파일러를 사용해 데이터의 배치, 이동, 그리고 연산을 명시적으로 스케줄링합니다. 이를 통해 캐시 적중, 미스, 교체 결정 등으로 인해 발생하는 타이밍 변동성을 줄입니다. 컴파일러가 데이터의 이동과 배치를 설정하고 나면, 실행 시간은 훨씬 더 예측 가능해집니다. 이러한 예측 가능성은 단순히 평균 응답 시간을 개선하는 것을 넘어 추론 시스템이 테일 지연(Tail latency)을 제어하는 데 도움을 줍니다.

The expected benefit is a more reliable supply of operands to the arithmetic units. By coordinating data movement with execution, the architecture aims to reduce pipeline stalls and increase sustained compute utilization. This is especially relevant during autoregressive decode, when low arithmetic intensity often leaves GPU resources waiting for model weights and other data. VSORA reports sustained utilization above 50% for large-language-model inference.

기대되는 이점은 산술 연산 장치에 오퍼랜드(Operand)를 더욱 안정적으로 공급할 수 있다는 점입니다. 데이터 이동을 실행 과정과 조율함으로써, 이 아키텍처는 파이프라인 정체(Stall)를 줄이고 지속적인 연산 활용도를 높이는 것을 목표로 삼습니다. 이는 산술 집약도가 낮아 GPU 자원이 모델 가중치나 기타 데이터를 기다리며 대기하게 만들기 쉬운 자기회귀적 디코딩(Autoregressive decode) 단계에서 특히 중요합니다. VSORA는 대형 언어 모델 추론 시 50%를 상회하는 지속적 활용도를 보고합니다.

That figure depends on the model, precision, batch size, sequence length, inference phase, software stack, and the way utilization is defined. Independent tests using matched workloads would be needed to verify the comparison with conventional GPUs.

물론 이 수치는 모델, 정밀도, 배치 크기, 시퀀스 길이, 추론 단계, 소프트웨어 스택, 그리고 활용도가 정의되는 방식에 따라 달라집니다. 기존 GPU와의 비교를 검증하려면 일치된 워크로드를 사용한 독립적인 테스트가 필요합니다.

Extending the Architecture Beyond AI

VSORA’s compute engine is its Matrix Processing Unit, or MPU. Its 16,384-bit-wide output datapath lets an instruction operate on a large amount of data in parallel pipelines. Programmable tensor operations are built into the MPU’s processing pipelines, and execute AI, digital signal processing (DSP), and general-purpose code. An instruction can use those pipelines in vector mode, where individual lanes work on separate data elements, or in matrix/tensor mode, where they perform operations on multidimensional data. The two modes can be interleaved in the instruction stream. That matters for workloads that mix steps such as neural-network inference and signal processing: the work can move between vector and tensor operations within the same engine, rather than being divided between a general-purpose core and a separate matrix accelerator.

VSORA의 연산 엔진은 바로 매트릭스 처리 장치(Matrix Processing Unit, MPU)입니다. 16,384비트 너비의 출력 데이터패스 덕분에 하나의 명령어가 병렬 파이프라인을 통해 방대한 양의 데이터를 동시에 처리할 수 있습니다. MPU의 처리 파이프라인에는 프로그래밍 가능한 텐서 연산이 내장되어 있어 AI, 디지털 신호 처리(DSP), 그리고 범용 코드를 모두 실행할 수 있습니다. 명령어는 개별 레인이 각각의 데이터 요소를 처리하는 '벡터 모드'나 다차원 데이터를 대상으로 연산하는 '매트릭스/텐서 모드'로 파이프라인을 사용할 수 있으며, 두 모드는 명령어 스트림 안에서 상호 인터리빙(Interleaving)될 수 있습니다. 이는 신경망 추론과 신호 처리가 섞여 있는 워크로드에서 매우 중요합니다. 범용 코어와 별도의 매트릭스 가속기 사이로 작업을 쪼갤 필요 없이, 동일한 엔진 안에서 벡터 연산과 텐서 연산 사이를 오갈 수 있기 때문입니다.

This design delivers two main advantages.

이 설계는 두 가지 주요 이점을 제공합니다.

The first is its suitability for edge systems, where a complete application rarely consists of AI inference alone. An autonomous-driving platform, for example, may run neural networks together with radar and lidar processing, sensor fusion, filtering, localization, image transformation, and vehicle-control algorithms. Handling these functions on one device can reduce the need for separate processors, limit chip-to-chip data transfers, and simplify the system.

첫째, 엣지 시스템에 매우 적합합니다. 완전한 애플리케이션이 AI 추론 하나만으로 이루어지는 경우는 드뭅니다. 예를 들어 자율주행 플랫폼은 신경망 구동과 함께 레이더 및 라이다 처리, 센서 융합, 필터링, 위치 추정(Localization), 이미지 변환, 그리고 차량 제어 알고리즘을 동시에 실행해야 합니다. 이러한 기능들을 단일 기기에서 처리하면 별도의 프로세서 필요성을 줄이고, 칩 간 데이터 전송을 제한하며, 시스템을 단순화할 수 있습니다.

The second advantage applies to neural-network inference itself. Operations used for next-token selection, such as randomized top-k sampling, can run inside the MPU. This avoids the transfers to a host processor that some competing architectures require.

둘째, 신경망 추론 그 자체에도 이점을 줍니다. 무작위 탑케이(Top-k) 샘플링과 같은 다음 토큰 선택에 사용되는 연산들이 MPU 내부에서 직접 실행될 수 있습니다. 이를 통해 일부 경쟁 아키텍처가 요구하는 호스트 프로세서로의 데이터 전송 과정을 피할 수 있습니다.

The MPUs connect to the shared memory / register file through a high-bandwidth network-on-chip. VSORA describes this interconnect as intelligent because it coordinates data movement between memory and the compute resources. Its purpose is to deliver operands to the appropriate execution units while reducing stalls, redundant transfers, and congestion.

MPU들은 고대역폭 온칩 네트워크(NoC)를 통해 공유 메모리/레지스터 파일에 연결됩니다. VSORA는 메모리와 연산 자원 간의 데이터 이동을 조율하기 때문에 이 상호 연결망을 '지능형'이라고 표현합니다. 그 목적은 정체, 중복 전송, 그리고 지연을 줄이면서 적절한 실행 유닛에 오퍼랜드를 전달하는 것입니다.

The architecture supports numerical formats from FP32 to FP4, allowing precision to be selected for each layer. This matters because neural-network layers differ in their tolerance for quantization. Less-sensitive layers can use lower precision to increase arithmetic density and reduce memory requirements, while sensitive layers retain higher precision to protect accuracy.

이 아키텍처는 FP32부터 FP4까지의 수치 포맷을 지원하여 각 레이어에 맞는 정밀도를 선택할 수 있게 합니다. 신경망 레이어마다 양자화에 대한 허용도가 다르기 때문에 이는 매우 중요합니다. 덜 민감한 레이어는 낮은 정밀도를 사용하여 연산 밀도를 높이고 메모리 요구량을 줄일 수 있으며, 민감한 레이어는 더 높은 정밀도를 유지하여 정확도를 보호할 수 있습니다.

VSORA’s Compilation Flow and Software Stack

VSORA uses a two-stage compilation flow that combines standard model formats with optimizations for its architecture. First, a model developed in PyTorch is exported to ONNX and passed to VSORA’s graph compiler. This front end analyzes the graph and performs operator fusion, constant folding, graph simplification, and other transformations. It then generates high-level C++ code that uses VSORA’s array-processing and neural-network component libraries.

VSORA는 표준 모델 형식과 아키텍처 최적화를 결합한 2단계 컴파일레이션 플로우를 사용합니다. 먼저, PyTorch로 개발된 모델을 ONNX로 내보낸(Export) 뒤 VSORA의 그래프 컴파일러에 전달합니다. 프런트엔드는 그래프를 분석하여 연산자 융합(Operator fusion), 상수로 고정(Constant folding), 그래프 단순화 등의 변환을 수행합니다. 그 후 VSORA의 배열 처리 및 신경망 컴포넌트 라이브러리를 사용하는 고수준 C++ 코드를 생성합니다.

In the second stage, a modified LLVM backend converts the C++ code into a RISC-V application and generates instructions for the MPU. The compiler selects and sequences MPU instructions, allocates stack memory, preloads weights, and manages the MPU inputs and outputs.

2단계에서는 수정된 LLVM 백엔드가 C++ 코드를 RISC-V 애플리케이션으로 변환하고 MPU용 명령어를 생성합니다. 컴파일러는 MPU 명령어를 선택 및 시퀀싱하고, 스택 메모리를 할당하며, 가중치를 미리 로드(Preload)하고, MPU의 입력과 출력을 관리합니다.

Because the architecture does not use a conventional hardware-managed cache hierarchy, the compiler has more responsibility for deciding where data resides and when it moves. It schedules transfers and computation directly instead of relying on the hardware to improve cache-hit rates. The goal is to make execution more predictable and keep operands available when the processing units need them. Actual hardware utilization will therefore depend heavily on the quality of the generated code.

아키텍처가 기존의 하드웨어가 관리하는 캐시 계층 구조를 사용하지 않기 때문에, 데이터가 어디에 위치하고 언제 이동해야 하는지를 결정할 책임이 컴파일러에게 더 많이 부여됩니다. 하드웨어가 캐시 적중률을 높이도록 내버려 두는 대신, 전송과 연산을 직접 스케줄링합니다. 그 목적은 실행을 더욱 예측 가능하게 만들고 처리 유닛이 필요로 할 때 오퍼랜드가 상시 대기하도록 하는 것입니다. 따라서 실제 하드웨어 활용도는 생성된 코드의 품질에 크게 좌우됩니다.

Application developers do not have to manage most of these details. They can start with familiar frameworks and model-exchange formats instead of writing kernels in a low-level language similar to CUDA. In practice, portability will depend on ONNX operator coverage, support for dynamic model behavior, and integration with commonly used inference frameworks.

애플리케이션 개발자가 이 모든 세부 사항을 직접 관리할 필요는 없습니다. CUDA와 유사한 저수준 언어로 커널을 직접 작성하는 대신, 익숙한 프레임워크와 모델 교환 형식에서 시작할 수 있습니다. 다만 실제 이식성은 ONNX 연산자 커버리지, 동적 모델 동작 지원, 그리고 널리 쓰이는 추론 프레임워크와의 통합 수준에 따라 달라질 것입니다.

VSORA’s Chiplet Architecture and System Integration

VSORA uses a chiplet architecture with each chiplet encompassing two MPUs, arranged as two clusters. Each cluster has its own DMA and control logic to manage data movement and execution. The architecture brings varied compute operations together while giving each MPU cluster local control over its work.

VSORA는 칩렛(Chiplet) 아키텍처를 채택하고 있으며, 각 칩렛은 2개의 클러스터로 배치된 2개의 MPU를 포함합니다. 각 클러스터는 데이터 이동과 실행을 관리하기 위한 자체 DMA 및 제어 로직을 가지고 있습니다. 이 아키텍처는 다양한 연산 작업을 하나로 모으면서도 각 MPU 클러스터가 자신의 작업을 로컬에서 제어할 수 있게 합니다.

Flexible scaling is achieved by varying the number of compute chiplets and HBM3E memory stacks in a package. According to the company, each MPU achieves a nominal 200 TFLOPS of dense FP8 performance, and the total per chiplet therefore amounts to 400 TFLOPS.

패키지 내의 연산 칩렛과 HBM3E 메모리 스택의 개수를 달리하여 유연한 확장을 달성합니다. 회사의 발표에 따르면 각 MPU는 공칭 기준 200 TFLOPS의 밀집 FP8 성능을 달성하며, 따라서 칩렛 당 총 성능은 400 TFLOPS에 달합니다.

The ratio of compute chiplets to HBM3E stacks can be adjusted for different workloads. Compute-intensive configurations can use more processing capacity per memory stack, while memory-intensive models can use more bandwidth and capacity relative to compute. This modular design allows VSORA to address applications ranging from data-center inference to automotive processing.

연산 칩렛과 HBM3E 스택의 비율은 워크로드에 따라 조절할 수 있습니다. 연산 집약적인 구성은 메모리 스택당 더 많은 처리 능력을 사용할 수 있고, 메모리 집약적인 모델은 연산 대비 더 많은 대역폭과 용량을 활용할 수 있습니다. 이러한 모듈식 설계를 통해 VSORA는 데이터 센터 추론부터 자동차용 프로세서에 이르는 다양한 애플리케이션을 소화할 수 있습니다.

At the high end of the product family, Jotunn8 combines eight compute chiplets with eight HBM3E stacks. VSORA specifies 288 GB of high-bandwidth memory and 3.2 PFLOPS of peak dense FP8 performance. These are rated peaks. Delivered performance depends on how much of that capacity the system can sustain on a given workload, which is why the company’s utilization claim requires the same attention as its peak-performance figure.

제품군의 최상위 모델인 Jotunn8은 8개의 연산 칩렛과 8개의 HBM3E 스택을 결합했습니다. VSORA는 288GB의 고대역폭 메모리와 3.2 PFLOPS의 최고 밀집 FP8 성능을 제시합니다. 물론 이는 정격 최고 성능이며, 실제 성능은 주어진 워크로드에서 시스템이 그 용량을 얼마나 지속해서 유지할 수 있느냐에 달려 있습니다. 따라서 회사의 활용도 수치 역시 최고 성능 수치와 마찬가지로 면밀히 따져봐야 합니다.

The Tyr family is intended for edge applications and is available with either two or four compute chiplets paired with one HBM3E stack. System designers can therefore choose a different balance of compute performance, memory bandwidth, power, and cost for each vehicle platform. VSORA states that Tyr is designed to meet ISO 26262 and ASIL functional-safety requirements while providing predictable, low-latency inference within automotive power and thermal limits.

차량용 애플리케이션을 겨냥한 Tyr(티르) 가족군은 1개의 HBM3E 스택과 결합된 2개 또는 4개의 연산 칩렛 구성으로 제공됩니다. 이를 통해 시스템 설계자는 각 차량 플랫폼의 전력, 열 한계, 메모리 대역폭, 그리고 연산 성능 간의 최적의 균형을 선택할 수 있습니다. VSORA는 Tyr이 자동차 전력 및 발열 한계 내에서 예측 가능하고 지연 시간이 짧은 추론을 제공하는 동시에, ISO 26262 및 ASIL 기능 안전 요구 사항을 충족하도록 설계되었다고 밝히고 있습니다.

Conclusion

As inference accounts for more AI computation, processor-design priorities are changing. Peak arithmetic throughput still matters, but it is not enough. An inference platform must deliver useful throughput within limits on latency, memory bandwidth and capacity, power, and cost.

추론이 AI 연산의 더 큰 비중을 차지함에 따라, 프로세서 설계의 우선순위도 변화하고 있습니다. 최고 산술 처리량은 여전히 중요하지만, 그것만으로는 충분하지 않습니다. 추론 플랫폼은 지연 시간, 메모리 대역폭 및 용량, 전력, 그리고 비용의 한계 내에서 유효 처리량을 제공해야 합니다.

VSORA approaches the problem differently from a conventional GPU. Its design uses compiler-directed data movement, a unified register-file abstraction, a DSP-derived execution engine with tensor capability, several numerical formats, and scalable HBM3E capacity. The architecture makes operand movement explicit and predictable instead of relying mainly on hardware-managed caches.

VSORA는 기존 GPU와는 다른 방식으로 이 문제에 접근합니다. 이 디자인은 컴파일러가 유도하는 데이터 이동, 단일 레지스터 파일 추상화, 텐서 기능을 갖춘 DSP 파생 실행 엔진, 여러 수치 포맷, 그리고 확장 가능한 HBM3E 용량을 활용합니다. 이 아키텍처는 하드웨어가 관리하는 캐시에 주로 의존하는 대신, 오퍼랜드의 이동을 명시적이고 예측 가능하게 만듭니다.

This combination distinguishes VSORA from other inference accelerators. The company combines the predictable execution of SRAM-centered architectures with enough external memory for large models, while using chiplets to address both data-center and automotive systems.

이러한 조합은 VSORA를 다른 추론 가속기들과 차별화합니다. 이 회사는 SRAM 중심 아키텍처의 예측 가능한 실행 능력과 대형 모델을 위한 충분한 외부 메모리를 결합하는 동시에, 칩렛을 사용하여 데이터 센터 시스템과 자동차용 시스템을 모두 아우릅니다.

VSORA’s design reflects a broader change in AI processors. Architects are looking beyond arithmetic capacity and paying more attention to the complete path that carries data to the compute engines.

VSORA의 설계는 AI 프로세서 전반에 걸쳐 일어나는 광범위한 변화를 반영합니다. 아키텍트들은 단순히 산술 연산 능력을 넘어, 데이터가 연산 엔진으로 전달되는 전체 경로에 더 많은 주의를 기울이고 있습니다.

For inference, theoretical throughput is only a starting point. A more useful measure is how much work a processor completes while meeting real limits on latency, power, memory, and cost.

추론에 있어 이론적 처리량은 단지 출발점에 불과합니다. 더 유용한 척도는 지연 시간, 전력, 메모리, 그리고 비용의 현실적인 한계를 충족하면서 프로세서가 얼마나 많은 작업을 완수해 내느냐입니다.