26O05e
네. 다시 확인해 보니 그 지적은 맞습니다. 특히 Stage3a10의 remote_obj를 MemKV 성능이라고 해석하면 안 됩니다. 현재 문서/테스트 정의를 정정하는 게 좋습니다.
1. MemKV는 S3 endpoint가 아닙니다
현재 MemKV 공식 문서를 확인하면 데이터 plane 기본 endpoint는 host:9900이고, 자체 wire protocol과 HMAC-SHA256 인증을 사용합니다. Admin HTTP endpoint는 기본적으로 data port + 1인 9901입니다. TCP와 RDMA가 같은 MemKV 프로토콜을 운반합니다. MinIO AIStor Documentation
즉 이것은:
http://memkv-node:9000같은 S3-compatible endpoint가 아닙니다.
실제 MemKV client 설정은 이런 개념입니다.
MEMKV_SERVERS=10.x.x.x:9900
MEMKV_AUTH_KEY=...
MEMKV_LICENSE=...그리고 vLLM과 MemKV를 직접 연결할 때 공식 문서에는 memkv-vllm plugin을 설치하여 native KV offloading/tiering에 붙이는 방식이 나옵니다. MinIO AIStor Documentation
따라서 기존 문서가
remote_obj
↓
http://memkv-node:9000
↓
S3-compatible처럼 기술했다면 MemKV 설명으로는 잘못된 것입니다.
2. 현재 Stage3a10의 remote_obj는 사실상 Object Storage 테스트로 보는 게 맞습니다
현재 v12/v13 계보에서 Stage3a10을 제가 만들 때도:
none
local_nvme
remote_obj로 추상화했고 remote_obj는 TieringOffloadingSpec의 object secondary tier를 사용하도록 구성했습니다.
따라서 의미상:
remote_obj
↓
S3/Object Storage
↓
MinIO / AIStor테스트입니다.
즉 결과표에
MemKV remote tier 성능
이라고 쓰면 안 되고,
Remote Object Storage KV tier (MinIO/AIStor)
라고 쓰는 게 정확합니다.
현재 사용자 환경에서 MinIO/AIStor가 Storage Cluster에 있으므로 더 명확하게:
Stage3a10-C
Remote Object KV Tier
AIStor / MinIO
S3 API over TCP/TLS로 이름을 바꾸는 것을 권합니다.
3. 진짜 MemKV 테스트는 별도 케이스가 필요합니다
공식 문서 기준으로 현재 MemKV와 vLLM 연결 방법은 적어도 구분해야 합니다.
가장 직접적인 것은:
vLLM
│
│ native OffloadingConnector
▼
TieringOffloadingSpec
│
│ memkv-vllm plugin
▼
MemKV tier
│
├─ TCP
└─ RDMA입니다.
공식 MemKV 문서도 이 경로를 vLLM native offloading + MemKV라고 별도로 설명하고 있으며, CPU pinned pool 뒤의 secondary tier로 MemKV를 사용합니다. MinIO AIStor Documentation
또 다른 경로는:
vLLM
↓
LMCache
↓
MemKV plugin
↓
MemKV입니다.
그리고 direct offloading 경로도 존재합니다.
vLLM
↓
MemKVOffloadingSpec
↓
MemKV다만 direct 경로는 공식 문서상 RDMA NIC가 필수이고 TCP fallback이 없습니다. MinIO AIStor Documentation
따라서 acceptance test에서 세 가지를 섞으면 안 됩니다.
Stage3a10을 이렇게 다시 정의하는 게 좋겠습니다
현재:
Stage3a10
none
local_nvme
remote_obj에서 앞으로는:
Stage3a10 — KV Tier Qualification
A. none
GPU HBM only
B. local_nvme
GPU
↓
CPU/offload
↓
Local NVMe
C. remote_object
GPU
↓
CPU/offload
↓
AIStor/MinIO
S3/TCP/TLS
D. memkv_tcp
GPU
↓
vLLM native offloading
↓
memkv-vllm
↓
MemKV :9900
TCP
E. memkv_rdma
GPU
↓
vLLM native/direct offloading
↓
memkv-vllm
↓
MemKV :9900
RDMA로 분리하는 것이 가장 명확합니다.
그리고 현재 환경에서는 D까지만 실행 가능합니다.
A none → 실행 가능
B local_nvme → 실행 가능
C remote_object → 실행 가능
D memkv_tcp → MemKV 설치 시 실행 가능
E memkv_rdma → 현재 N/A현재 GPU node에 RDMA가 없기 때문입니다.
4. 97 GB/s 부분도 지적이 맞습니다
MemKV 공식 Quick Start 문서에서 97.4 GB/s가 benchmark된 구성은 distributed full server의 RDMA/NVMe/JBOF performance path입니다. TCP-only single-node/file-mode 구성과 같은 의미의 숫자가 아닙니다. MinIO AIStor Documentation
따라서 현재 환경에서:
GPU node
│
Ethernet TCP/IP
│
MemKV를 측정해서:
97 GB/s expected같은 acceptance threshold를 적용하면 잘못된 비교가 됩니다.
오히려 테스트 결과서에는 다음처럼 명시하는 게 맞습니다.
MemKV TCP result is not compared against vendor RDMA performance figures. It establishes a site-specific TCP baseline only.
이 부분은 상당히 중요합니다.
5. 더 흥미로운 것은 MemKV native tiering은 TCP fallback을 지원합니다
공식 native offloading + MemKV 문서에서는 RDMA fast path가 없으면 TCP로 동작할 수 있다고 명시합니다. MinIO AIStor Documentation
따라서 현재 환경에서도 MemKV 자체를 시험할 수는 있습니다.
B300
│
vLLM 0.30
│
OffloadingConnector
│
TieringOffloadingSpec
│
memkv-vllm
│
TCP
▼
MemKV다만 이것을:
MemKV 성능 qualification이라고 하기보다는:
MemKV TCP baseline qualification으로 분류하는 게 좋습니다.
향후 RDMA가 들어오면 동일 workload를 다시:
MemKV TCP
vs
MemKV RDMA로 비교하면 됩니다.
6. 그리고 vLLM 0.30 compatibility도 다시 검증해야 합니다
이것도 그냥 넘어가면 안 됩니다.
MemKV 공식 native-tiering 문서는 현재 해당 plugin이 여러 vLLM 버전에서 확인됐다고 설명하지만, offloading spec API 자체가 experimental임을 명시하고 있습니다. MinIO AIStor Documentation
우리는:
vLLM 0.30.0을 production standard로 잡았기 때문에 Stage3a10-D를 실행하기 전에:
vLLM 0.30.0
+
memkv-vllm plugin version
+
OffloadingConnector
+
TieringOffloadingSpec
+
memkv tier조합을 별도의 compatibility gate로 확인하는 것이 맞습니다.
즉:
Stage3a10-D0
MemKV Integration Preflight
vLLM == 0.30.0
memkv-vllm installed
plugin registration OK
MemKV :9900 reachable
HMAC auth OK
transport = tcp
tier initialization OK
↓ PASS
Stage3a10-D1
MemKV TCP functional test
↓ PASS
Stage3a10-D2
MemKV TCP performance test순서가 좋습니다.
7. 측정 workload도 동일해야 합니다
그리고 기존 Stage3a10의 또 다른 문제와 연결됩니다.
none
local_nvme
remote_object
memkv_tcp를 비교할 때 서로 다른 random prompt를 사용하면 안 됩니다.
동일한:
fixed dataset
fixed random seed
same model
same TP
same dtype
same max_model_len
same concurrency
same input/output length
same prefix reuse
same CPU pool조건이어야 합니다.
그 상태에서:
| Tier | TTFT | ITL | Req/s | Output TPS | KV Hit | Restore GB/s | Error |
|---|---|---|---|---|---|---|---|
| none | N/A | ||||||
| local NVMe | |||||||
| AIStor/MinIO | |||||||
| MemKV TCP | |||||||
| MemKV RDMA | future | future | future | future | future | future | future |
로 비교해야 의미가 있습니다.
그래서 현재 architecture도 이렇게 정정하는 것이 좋습니다
KV Tier Qualification
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
GPU HBM Local NVMe Remote systems
│
┌─────────────┴─────────────┐
│ │
▼ ▼
Object Storage MemKV
AIStor/MinIO │
│ │
S3/TLS Native protocol
│ │
TCP TCP / RDMA
│
current ─────┤
TCP │
│
future ──────┘
RDMA즉 AIStor/MinIO와 MemKV를 같은 remote_obj 박스 안에 넣으면 안 됩니다.
결론
확인 결과, 말씀하신 두 지적 모두 타당합니다.
첫째, 현재 Stage3a10의 remote_obj가 S3 endpoint를 사용한다면 그것은 MemKV test가 아니라 MinIO/AIStor Object Storage test입니다. MemKV는 기본적으로 :9900의 자체 data protocol과 HMAC 인증을 사용하며, vLLM에서는 MemKV plugin/native offloading 또는 LMCache integration 같은 별도 경로가 필요합니다. MinIO AIStor Documentation
둘째, MemKV의 97.4 GB/s급 수치를 현재 TCP-only 환경의 acceptance 기준으로 사용하면 안 됩니다. 그 수치는 공식 문서상 RDMA 기반 distributed full-server performance path와 연결된 결과입니다. 현재 환경에서는 MemKV TCP baseline을 별도로 측정하고, 향후 RDMA 도입 후 같은 workload로 TCP vs RDMA를 재검증하는 게 맞습니다. MinIO AIStor Documentation
따라서 v13의 Stage3a10 문서·스크립트·Excel·draw.io를 모두 remote_object(MinIO/AIStor)와 memkv_tcp, memkv_rdma(future/N/A)로 분리하는 수정이 필요합니다. 이건 단순 문구 수정이 아니라 테스트 의미가 달라지는 부분이라, v13.1 정도로 올려서 반영하는 게 적절합니다.
MinIO AIStor(S3 Object Storage)와 MinIO MemKV(Context Store)는 동일한 MinIO 생태계에 속해 있지만, 설계 목적, 데이터 경로(Data Path), 프로토콜, 그리고 서빙 엔진(vLLM)과의 결합 방식에서 근본적인 차이가 있습니다.
1. 핵심 아키텍처 및 동작 방식 차이
| 비교 항목 | MinIO AIStor (S3 Object Storage) | MinIO MemKV (Context Store / KV Tier) |
|---|---|---|
| 설계 목적 | 대용량 비정형 데이터(모델 가중치, 체크포인트, 로그, 데이터셋)의 영구 저장 및 관리 | LLM 추론 시 발생하는 KV Cache의 초저지연 오프로딩 및 재사용(Context Store) |
| 통신 프로토콜 | 표준 HTTP/REST (S3 API 호환) | 자체 바이너리/데이터 스트리밍 프로토콜 |
| 기본 포트 | :9000 (API), :9001 (콘솔) |
| :9900 (데이터 전송 전용 포트) |
| 인증 메커니즘 | AWS SigV4 (Access Key / Secret Key 기반 서명)
| 경량화된 고속 HMAC 인증 |
| 전송 계층 | 일반 TCP/IP (소켓, HTTP 파싱, 커널 버퍼 복사)
| RDMA / RoCEv2 (GPU Direct Memory Access 지원) 또는 최적화된 고속 TCP 경로 |
| vLLM 연동 방식 | S3 API 기반의 일반 파일/오브젝트 IO (minio SDK 또는 S3 connector)
| LMCache 플러그인, NVIDIA NIXL(Fast IO), 또는 전용 MemKV native connector |
| 처리 단위 | 일반 오브젝트/블록 단위 (수 MB ~ 수 GB 단위의 단일 객체)
| PagedAttention의 KV Cache 블록/토큰 텐서 단위 |
2. 상세 차이점 분석
① 데이터 경로 및 오버헤드 (Protocol Overhead)
- AIStor (S3 Endpoint, :9000):
- S3 API는 HTTP 1.1/HTTP 2 기반의 REST 통신을 수행합니다.
- 요청마다 HTTP 헤더 파싱, AWS Signature V4 검증, XML/JSON 메타데이터 처리, 커널 네트워크 버퍼 유저 스페이스 GPU 메모리로 이어지는 다단계 메모리 복사(Copy)가 발생합니다.
- 이는 대용량 가중치 파일(예: 70B 모델의 safetensors)을 다운로드할 때는 높은 처리량을 내지만, 밀리초(ms) 단위의 응답 속도가 중요한 실시간 추론 KV 캐시 조회에는 지연시간(Latency) 오버헤드가 지나치게 큽니다.
- MemKV (Data Protocol, :9900):
- HTTP 계층을 완전히 제거하고, KV 블록 전송에 특화된 경량 바이너리 스트리밍 프로토콜을 사용합니다.
- 핸드셰이크와 인증(HMAC)을 단순화하여 연결 오버헤드를 극소화했습니다.
- 지원 환경(RDMA/RoCEv2)에서는 CPU/커널을 거치지 않고 스토리지 노드의 NVMe/메모리에서 GPU HBM으로 데이터를 직접 밀어넣는 구조를 지향합니다.
② vLLM 서빙 엔진과의 통합 레벨
- AIStor 사용 시 (현재 Stage3a10의
remote_obj추정 형태): - vLLM이 GPU 메모리가 부족해지면 KV 텐서를 직렬화(Serialization)하여 일반 파일이나 S3 Object 형태로 변환한 뒤
PutObject를 호출합니다.
- 다시 필요할 때는
GetObject로 가져와 역직렬화(Deserialization) 후 GPU 메모리에 재배치합니다. - 직렬화/역직렬화 비용과 HTTP 지연 때문에, 캐시를 네트워크로 가져오는 시간이 GPU에서 토큰을 다시 계산(Prefill)하는 시간보다 길어져 오히려 성능이 저하되는 현상(Negative Gain)이 발생하기 쉽습니다.
- MemKV 사용 시 (전용 플러그인/LMCache 연동):
- vLLM 내부의 PagedAttention 블록 매니저와 직접 맞물립니다.
- 텐서 레이아웃을 그대로 유지한 채 블록 해시 키를 기반으로 필요한 KV 블록 슬라이스를 분산 노드에서 즉시 당겨옵니다.
- Prefill 단계에서 중복 프롬프트를 인식하면, 직렬화 오버헤드 없이 타깃 GPU 메모리 주소로 직접 데이터를 채워 넣어 TTFT(첫 토큰 생성 시간)를 수십~수백 ms 수준으로 단축시킵니다.
③ 성능 및 처리량의 기대치
- AIStor (S3):
- 본 환경의 네트워크인 100GbE LACP(실효
50Gbps TCP) 환경에서 HTTP S3 프로토콜을 타면 단일 세션 지연시간이 수십수백 ms 단위로 튀며, 처리량도 TCP 스택 한계(약 4~5 GB/s)에 묶입니다.
- 따라서 레이턴시 단축 목적보다는 "GPU 메모리 부족 시 에러(OOM)를 방지하고 동시 처리량(Capacity)을 늘리는 완충 지대" 역할에 그치게 됩니다.
- MemKV:
- 800GbE RoCEv2(RDMA) 등의 환경에서 공식 벤치마크 기준 97.4 GB/s 수준의 대역폭을 목표로 설계되었습니다.
- 로컬 NVMe를 읽어오는 수준 또는 그 이상의 초고속으로 원격 노드의 KV 캐시를 적재할 수 있어, 네트워크를 경유함에도 로컬 캐싱과 대등한 수준의 TTFT 절감 효과를 제공합니다.
결론
현재 구성에서 :9000 포트로 minio Python SDK를 호출하고 있다면, 그것은 "일반 S3 오브젝트 스토리지(AIStor)를 백엔드로 둔 파일 오프로딩 테스트"를 수행하고 있는 것입니다.
진정한 MemKV 테스트가 되려면:
- 스토리지 노드에서 MemKV 전용 데몬(
:9900)이 구동 중이어야 하고, - vLLM 클라이언트/서버 측에
LMCache또는 MinIO MemKV 전용 커넥터(NIXL 등)가 장착되어 바이너리/HMAC 채널로 통신하는지 파이프라인을 교정해야 합니다.
