APEX 소개
대화가 길어질수록 LLM 추론(Inference)에서 비싸지는 것은 연산이 아니라 기억입니다. 지금까지 읽은 모든 토큰의 키와 값을 KV 캐시(KV Cache)에 저장해 두고 새 토큰마다 전부 다시 읽어야 하므로, 컨텍스트가 늘어나면 추론 엔진은 점점 계산기가 아니라 메모리 전송 장치에 가까워집니다. 대부분의 가속기는 이 문제를 소프트웨어 쪽으로 넘깁니다. CPU나 GPU에서 캐시를 양자화(Quantization)해 저장하고, 읽을 때 다시 풀어 쓰는 방식입니다. 문제는 압축과 해제가 연산 장치 바깥에서 일어나는 동안에도 원본 크기의 데이터가 한 번은 메모리를 오간다는 점입니다.
이번에 소개할 APEX는 그 압축기를 아예 하드웨어 연산 경로 안에 집어넣은 프로젝트입니다. 키와 값은 만들어지는 순간 압축되어 온칩 SRAM에 들어가고, 어텐션(Attention) 곱셈을 위해 읽히는 순간 해제됩니다. 프로젝트는 이 설계를 두고 "It's not a sidecar", 즉 압축이 부가 모듈이 아니라 데이터가 지나가는 길 자체에 놓여 있어 어디에도 16비트 부동소수점 사본이 남지 않는다고 설명합니다. 여기에 토큰 중요도(Token Importance)를 추적하는 유닛이 붙어서, 계속 참조되는 구간에는 비트를 더 쓰고 그렇지 않은 구간은 더 강하게 압축합니다.
APEX가 다루는 범위는 트랜스포머 디코더 계층 하나이며, 프로젝트는 이를 타일(Tile)이라고 부릅니다. DRAM 컨트롤러도 PCIe도 온칩 네트워크도 들어 있지 않고, 그것들이 범위 밖이라는 사실을 프로젝트가 먼저 밝혀 둡니다. 대신 그 한 계층 안의 정규화, 회전 위치 인코딩, 행렬 곱, 소프트맥스, SwiGLU, 잔차 연결이 모두 실제 RTL(Register Transfer Level)로 작성되어 있고, 각 블록이 실행 가능한 NumPy 기준 모델과 비트 단위로 일치하는지 검증되어 있습니다. 실리콘은 아직 없으며 FPGA에서 Qwen2.5-0.5B를 실제로 실행한 단계인데, 프로젝트가 특히 강조하는 규칙은 모든 숫자에 측정값인지 예측값인지를 함께 표시한다는 것입니다. 이 글도 그 구분을 그대로 따라갑니다.
APEX의 KV 압축 코덱이 다른 점
APEX의 코덱은 키를 채널 단위 INT4로, 값을 토큰 단위 INT4로 양자화하고, 양자화가 잘 되지 않는 채널만 16비트 부동소수점 레인으로 따로 뺍니다. 여기까지는 KIVI와 KVQuant로 이어지는 온디바이스 KV 양자화 계열의 방법과 같고, 프로젝트도 방법 자체의 새로움을 주장하지 않는다고 명시하고 있습니다. 하드웨어 차원의 KV 압축에도 Titanus(GLSVLSI 2025)와 Kelle(MICRO 2025)이라는 선행 연구가 있다는 점까지 함께 적어 두었습니다. 같은 방법을 소프트웨어로 구현한 사례로는 커뮤니티에 소개된 turboquant-pytorch가 있습니다.
APEX가 자기 기여로 내세우는 것은 그 방법을 검증된 하드웨어로 만들어 낸 통합 구현입니다. 세 가지가 함께 있어야 성립하는 주장이므로 하나씩 정리합니다:
- 압축률을 부대 비용까지 포함해서 계산합니다: 태그, 이상치 레인, 패딩, 스케일 뱅크를 모두 더한 뒤의 비율만 기준 모델에서 단언합니다. 압축 알고리즘 논문이 흔히 빼고 세는 항목들이라, 여기서 나온 숫자는 실제로 SRAM이 보는 숫자와 같습니다.
- 압축이 별도 단계가 아닙니다: 회전 위치 인코딩과 캐시 쓰기 사이에서 압축하고, 어텐션 읽기 경로 안에서 해제합니다.
- 정확도를 검증된 코덱을 통과시켜 측정합니다: RTL이 비트 단위로 맞춰져 있는 바로 그 기준 모델로 HellaSwag 검증 세트 전체 10,042개 문서를 0.5B, 1.5B, 7B 규모에서 채점했습니다. 0.5B와 1.5B에서는 손실이 거의 없었고, 7B에서는 KVQ8 계층이 전체 데이터셋 규모에서 감지되는 영향을 남기지 않은 반면 KVQ4 계층은 작지만 실재하는 비용을 냈다고 보고합니다. 이상치 계층이 존재하는 이유가 바로 이것이라고 프로젝트가 설명합니다.
정밀도 계층은 KVQ8, KVQ4, KVQ4+이상치 세 단계이고, 어느 구간에 어느 계층을 쓸지는 토큰 중요도 유닛(TIP)이 측정한 값이 결정합니다. 압축률을 고정해 두고 모델 품질을 감수하는 대신, 문맥 안에서 실제로 계속 쓰이는 부분에만 비트를 몰아주는 구조입니다.
APEX 타일을 지나가는 한 번의 디코드
새 토큰 하나가 활성값 벡터로 들어와 계층 출력이 되어 나오기까지, 그 사이가 전부 하드웨어입니다. 프로젝트가 README에 그려 둔 경로를 옮기면 다음과 같습니다:
x ─► seam ─► RMSNorm ──► MXE: W_Q·x W_K·x W_V·x ──► RoPE ──► KVQ 압축
(ASU) (시스톨릭 GEMM) (Q,K) │
▼
KV 캐시 = INT4 + 이상치 레인
(온타일 SRAM)
│
MXE: Q·K̂ᵀ ──► 온라인 소프트맥스 ──► MXE: P·V̂ │
(ASU) │ │
▲ │ │
└────── TIP 중요도 ◄───────────┤ │
(적응형 정밀도) ▼ │
MXE: W_O·attn ──► + 잔차 ────┼──► y
│
FFN: RMSNorm ─► MXE: W_gate/W_up ─► SwiGLU ─► MXE: W_down
──► + 잔차
이 경로에서 행렬 곱 엔진은 하나뿐입니다. MXE는 INT8 시스톨릭 배열 하나로 디코더 계층의 일곱 가지 행렬 작업, 즉 QKV 투영 셋과 어텐션 곱 둘, 출력 투영, 그리고 FFN(Feed-Forward Network) 행렬들을 시분할로 돌아가며 처리합니다. 소프트맥스는 점수 행렬을 통째로 메모리에 만들지 않는 온라인 방식이라 컨텍스트 길이만큼의 버퍼가 필요 없고, 모든 하드웨어 동작은 행렬 모양과 경로, 양자화 계약을 담은 자기 기술형 디스크립터(Descriptor) 하나로 표현됩니다. 그래서 호스트가 작업을 하나씩 던지는 실행과 타일이 스스로 계층을 도는 실행이 같은 방식으로 동작하고, 실제로 흘러간 모든 작업을 시뮬레이션에서 비트 단위로 재생할 수 있습니다.
실행 방식은 호스트 모드와 워커 모드 두 가지입니다. 호스트 모드에서는 작업 하나마다 호스트를 왕복하므로 정확하지만 느리고, 프로젝트는 그 왕복 비용을 약 100배의 세금이라고 표현합니다. 계층 워커(Layer Walker)는 계층 실행에서 그 호스트를 제거하는 장치로, 디스크립터를 스스로 가져와 엔진들을 순서대로 실행하고 중간 텐서를 온타일 패브릭으로 넘겨 한 번의 신호로 계층 전체를 실행합니다. 시뮬레이션에서는 워커 모드로 실행한 계층이 비트 단위로 일치하고, FPGA 실리콘에서는 호스트 모드가 증명된 상태이며, FPGA 위에서 워커가 실행하는 어텐션은 아직 브링업 중입니다.
APEX가 정확성을 주장하는 방식
이 저장소에서 방법론은 RTL만큼이나 결과물의 일부입니다. 명세에서 실행 가능한 기준 모델을 만들고, 그 모델이 얼어붙은 벡터와 RTL 양쪽의 심판이 되며, 블록 단위에서 파이프라인 단위, 계층 전체 단위로 합성 수준을 올려 가며 대조하고, 마지막에는 같은 작업을 FPGA 실리콘에서 다시 재생해 비트 단위로 비교합니다. 여기에 세 가지 규칙이 더 있습니다:
- 근사가 아니라 비트 일치: 허용 오차를 두지 않고 완전히 같은 값을 요구합니다. 예를 들어 SiLU 함수는 16비트 입력 전체 영역 65,536개 패턴을 남김없이 대조했고, 회전 위치 인코딩은 12,288개 채널 쌍 벡터를, KVQ의 고정소수점 연산 경로는 8,748,634건의 검사를 오차 없이 통과했습니다.
- 변이 시험을 통과한 테스트벤치: 테스트가 녹색인 것만으로는 인정하지 않고, RTL을 일부러 망가뜨렸을 때 그 테스트가 붉게 바뀌는지까지 확인합니다. 살아남은 변이체는 설계 문제가 아니라 검증 문제로 처리합니다.
- 날조 금지 규칙: 공개하는 숫자는 사람이 옮겨 적지 않고 스위트 로그에서 기계가 추출합니다. 2026년 7월 26일에 생성된 STATUS.md를 열어 보면 통과한 스위트뿐 아니라 아직 돌리지 않은 스위트가
NO-RUN으로, 서드파티 체크아웃을 걷어내며 은퇴시킨 스위트가RETIRED로 그대로 남아 있습니다. 알려진 공백은 TRACEABILITY.md의 한계 등록부에 따로 기록됩니다.
시뮬레이션과 실리콘을 차분으로 비교하는 규율도 같은 계열입니다. FPGA에서 수행하는 모든 실행 회차는 레지스터 조작 프로그램이라 Verilator로 만든 동일 모델에서도 그대로 동작하고, 하드웨어에서 캡처한 값과 시뮬레이션 값을 비트 단위로 맞춰 봅니다. 합성 단계에서 생긴 하드웨어 결함 하나를 이 차분 증거만으로 추적해 낸 사례가 저장소에 기록되어 있는데, 그때 틀린 쪽은 RTL이 아니라 도구 체인이었습니다.
APEX가 실제 하드웨어에서 낸 숫자
서로 다른 부품과 서로 다른 도구 체인을 쓴 하드웨어 실증이 둘 있습니다. 하나는 오픈 툴체인으로 진행한 Lattice ECP5-85F로, KV 압축 엔진을 실제 배포 구성 그대로 배치와 배선까지 마치고 비트스트림과 리포트를 저장소에 커밋해 두었습니다. 여기서 공개한 라우팅 후 최대 동작 주파수에는 이전에 파라미터를 줄여 얻었던 수치를 철회한다는 설명이 함께 적혀 있습니다. 다른 하나는 AWS F2의 VU47P로, 타일 전체가 오류 없이 빌드되어 클라우드 FPGA에서 동작하며 250MHz 셸 클럭에서 타이밍을 만족했습니다.
토큰 생성 속도는 하네스가 실리콘에서 직접 출력한 값으로 공개되어 있습니다:
| 이미지 | 타일 클럭 | 측정 속도 | 비고 |
|---|---|---|---|
| A0 | 62.5MHz | 0.56 tok/s | 토큰당 1.78초, 서로 다른 두 빌드에서 확인 |
| A2 | 15.625MHz | 0.25 tok/s | 문서에 기준 이미지로 등록된 구성 |
| 호스트 구동 기준선 | 해당 없음 | 0.004 tok/s | 계층 워커 이전의 출발점 |
기준선에서 A0까지가 140배의 측정된 상승폭이고, 단계별 최적화 사다리는 FIRST_WALKED_TOKENS.md에 정리되어 있습니다. 절대값만 보면 느립니다. 아직 실리콘이 아니라 FPGA이고 타일 클럭도 62.5MHz에 머물러 있기 때문입니다. 대신 검증된 RTL이 실제 FPGA 카드 위에서 실제 모델의 토큰을 끝까지 만들어 냈고, 그 과정의 모든 값이 비트 단위로 채점됐습니다.
기준 이미지 agfi-030a812cd224b409d에서는 193개 검사가 모두 통과했고 이어서 실제 프롬프트에 응답했습니다. 직접 확인해 보려면 두 스크립트를 그대로 실행하면 됩니다:
# f2.6xlarge 인스턴스를 띄우고 이미지를 올린 뒤 검사 배터리와 워커 실행 체인을 수행한 뒤 스스로 종료합니다
bash scripts/fpga/f2/run_walked_demo.sh agfi-030a812cd224b409d
# 워커 모드 파이프라인에 직접 프롬프트를 넣어 보는 대화형 CLI입니다
bash scripts/fpga/f2/run_chat_demo.sh
다만 실행에는 us-west-2 리전의 f2.6xlarge 인스턴스에 접근할 수 있는 AWS 자격 증명과 모델 가중치 이미지가 필요합니다. 가중치는 mlx-community/Qwen2.5-0.5B-Instruct-4bit에서 유도되며, 외부 사용자는 scripts/fpga/f2/make_weight_image.py로 자기 버킷에 이미지를 다시 만들어야 합니다. 한 번 완주하는 데 드는 비용은 약 2달러, 시간은 30분 정도입니다.
APEX-7B 종이 설계와 예측 수치
지금까지의 숫자가 측정값이라면, 7B급 모델을 담는 전체 칩의 그림은 예측값입니다. 위 다이어그램은 그 경계를 색으로 구분해 두었습니다. 초록 실선 상자는 오늘 비트 단위로 검증된 RTL이고, 노란 점선 상자는 아직 만들지 않은 제안이며, 회색 점선 상자는 서드파티 IP라 이 프로젝트의 범위 밖입니다. 다이어그램 맨 위에 "EVERY PERFORMANCE NUMBER PROJECTED"라고 적혀 있는 것도 같은 이유입니다.
프로젝트가 스스로 정한 통과 기준은 32k 이상 컨텍스트에서 초당 10토큰 이상, 1k 토큰 프롬프트의 첫 토큰까지 5초 이하, 소비 전력 5W 이하입니다. 다이어그램에 그려진 구성, 즉 0.65GHz 이상의 64×64 MXE와 ×64 폭 LPDDR5X, W4 가중치 스트리밍, 계층 워커, KVQ를 모두 갖췄을 때 해석 모델이 내놓는 값은 32k 컨텍스트에서 11.4 tok/s, 첫 토큰까지 3.4초, 2.9W입니다. 전부 예측값입니다. 이 예측이 기대고 있는 아직 만들어지지 않은 세 가지는 네이티브 W4 가중치 경로와 하드웨어 계층 워커, 넓은 LPDDR이며, 셋 모두 지금 프로젝트가 작업 중인 항목입니다.
한편 목표를 어디에 두고 있는지도 분명합니다. 프로젝트가 말하는 최종 상태는 약 3W에서 7B 모델을 사람이 읽는 속도로 실행하면서 32k에서 64k 컨텍스트를 KV 압축으로 평평하게 유지하는 것이고, 같은 단일 스트림 작업에서 데스크톱 GPU 대비 토큰당 에너지를 5분의 1에서 10분의 1로 줄이는 것입니다. 그러면서 GPU보다 빠른 것은 결코 목표가 아니라고 프로젝트가 명시해 두었습니다. 비교 기준을 속도가 아닌 토큰당 에너지와 긴 컨텍스트에서의 일관된 응답 속도에 두고 있습니다.
APEX는 누구에게 맞는가
KV 캐시 압축을 하드웨어 수준에서 공부하거나 자기 설계에 참고하려는 연구자와 하드웨어 엔지니어에게 APEX가 가장 큰 값어치가 있습니다. 방법 자체는 이미 논문으로 공개된 계열이지만, 그 방법을 비트 단위로 검증된 RTL과 실제 FPGA 비트스트림, 패딩까지 포함한 압축률 회계로 함께 공개한 저장소는 흔하지 않습니다. 검증 방법론을 배우려는 사람에게도 참고할 자료가 많습니다. 기준 모델과 변이 시험, 시뮬레이션 대 실리콘 차분 비교가 실제 로그와 함께 통째로 들어 있기 때문입니다.
반대로 지금 당장 추론을 빠르게 돌릴 하드웨어를 찾는 팀에게는 APEX가 선택지가 아닙니다. 실리콘이 없고 측정된 속도는 초당 1토큰에도 못 미치며, 범위 자체가 디코더 계층 하나로 한정되어 DRAM 컨트롤러와 인터커넥트가 들어 있지 않습니다. 같은 영역에서 완성된 제품을 찾는다면 OpenAI와 Broadcom의 Jalapeño 같은 상용 추론 칩 쪽이 비교 대상이고, APEX는 그 옆에서 설계와 검증 과정을 통째로 열어 둔 참고 구현에 가깝습니다.
APEX 직접 재현하기
FPGA 없이 시뮬레이션만으로 재현하려면 Verilator 5.x와 Python 3.11, NumPy가 필요합니다. Icarus Verilog는 교차 확인용으로 선택 사항입니다:
make -C golden test # 기준 모델과 얼어붙은 벡터 대조, 압축률 회계 게이트 포함
make -C verif/top/smoke smoke # 어텐션 타일 전체 종단 검사
make -C verif/top l3 # Layer-3, 실제 타일과 기준 모델 대조
make -C verif/seq_walker # 계층 워커 스위트와 변이 게이트
python3 perf/apex_perf_model.py --check # 성능 모델의 보정 기준점 확인
또한 모델 정확도 행렬도 복제본에서 다시 실행할 수 있습니다. 0.5B와 1.5B는 bash eval/kv_eval/run_matrix.sh, 7B는 bash eval/kv_eval/run_matrix_7b.sh입니다. 저장소 구조는 ARCHITECTURE.md에 설계 결정 등록부와 모듈 출처 이력까지 함께 정리되어 있고, 검증 결과는 캠페인마다 디렉토리 하나씩 docs/results에 커밋되어 있습니다.
APEX의 검증 도구는 SigmanticAI가 만든 것으로, 이 회사는 자연어 명세에서 검증된 RTL까지 가는 자율 검증 에이전트를 만드는 칩 설계 도구 기업입니다. 프로젝트가 밝힌 개발 배경이므로 함께 적어 둡니다.
APEX의 라이선스
APEX는 Apache License 2.0으로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다. 저장소 트리의 RTL은 모두 APEX가 직접 작성한 것이며, 브링업 초기에 외부 코드로 시작했던 두 블록은 문서화된 클린룸 재작성으로 교체되어 각 모듈 헤더와 설계 결정 등록부에 그 이력이 남아 있습니다.
APEX 프로젝트 GitHub 저장소
SigmanticAI 홈페이지 (APEX 검증 도구를 만든 회사)
KIVI 논문, APEX 코덱이 따르는 KV 양자화 계열
KVQuant 논문, 같은 계열의 이상치 처리 접근
더 읽어보기
-
turboquant-pytorch: Google의 TurboQuant를 PyTorch로 처음부터 직접 구현한 LLM KV 캐시 양자화 라이브러리
-
OpenAI와 Broadcom이 공개한 첫 자체 LLM 추론 전용 칩 Jalapeño (feat. Celestica)
-
Cerebras, 웨이퍼 3장을 한 랙에 담은 Nexus 아키텍처로 GPU 대비 최대 30배 빠른 추론이 가능한 CS-4 출시
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 도구를 직접 설치해 사용해보셨다면, 
파이토치 한국 사용자 모임
회원들을 위해 경험이나 팁을 댓글로 남겨주세요! 