DeepSeek Engram은 정적 N-gram 메모리를 DRAM 쪽으로 분리할 수 있지만, 모델 가중치와 동적 컨텍스트까지 VRAM에서 없애 주는 기술은 아닙니다.
Engram의 아이디어는 자주 반복되는 정적 패턴을 모든 신경망 층에서 다시 계산하지 말고 결정론적인 주소로 조회하자는 것입니다. Attention, MoE가 문맥과 추론을 처리하는 동안 별도 N-gram 임베딩 테이블이 기억 역할을 맡습니다. 이 분리는 HBM 사용을 줄일 여지가 있지만, 호스트 메모리 조회가 실제 생성 지연에 미치는 영향을 함께 봐야 합니다.
입력 토큰의 N-gram 패턴은 룩업 테이블의 주소로 바뀌고, 해당 임베딩은 CPU DRAM이나 CXL 계층에서 조회됩니다. 모델의 hidden state는 기존처럼 GPU에서 Attention과 MoE 연산을 거칩니다. 두 경로의 표현은 중간 레이어에서 결합됩니다.
룩업 자체를 O(1)로 표현할 수 있어도 전체 토큰 생성이 O(1)이 되는 것은 아닙니다. 주소 계산, 메모리 접근, CPU와 GPU 사이 전송, 나머지 Transformer 연산은 그대로 남습니다. Engram은 “GPU 연산을 없앤다”보다 반복 지식에 쓰던 모델 용량을 별도 메모리 계층으로 옮기는 설계로 보는 편이 정확합니다.
원문은 Engram을 Layer 2 부근의 초기 레이어에 넣었을 때 효율이 높고, 깊이에 따른 효과가 U자형으로 나타난다는 결과를 설명합니다. 앞단에서 정적 패턴을 제공하면 뒤 레이어가 그 정보를 바탕으로 문맥 조합과 추론에 집중할 수 있다는 해석입니다.
이 결과가 모든 모델 깊이와 데이터에서 Layer 2가 정답이라는 뜻은 아닙니다. 토크나이저, N-gram 크기, 백본 구조와 학습 목표에 따라 적절한 위치가 달라질 수 있습니다. 도입 실험에서는 삽입 위치별 정확도뿐 아니라 전송량과 토큰 지연도 함께 기록해야 합니다.
원문은 27B 규모 Engram 모델이 동급 일반 MoE를 상회하고, MMLU 같은 지식 평가에서 최대 3.4포인트, 긴 문맥 검색에서 12.8포인트 개선됐다고 전합니다. 이는 특정 학습, 비교 조건의 결과이며 “저렴한 RAM만 추가하면 모든 70B 모델을 더 작은 GPU에서 돌린다”는 보장은 아닙니다.
비교할 때는 다음 조건이 같아야 합니다.
성능 점수와 시스템 비용을 분리하면, 정확도가 오른 이유와 메모리 계층의 이점을 혼동하지 않을 수 있습니다.
DRAM 용량은 HBM보다 싸고 크게 구성하기 쉽지만 대역폭과 지연 특성이 다릅니다. 순차 생성에서 필요한 임베딩이 제때 도착하지 않으면 PCIe 대기나 cache miss가 토큰 속도에 직접 영향을 줄 수 있습니다. CXL이 선택지를 넓혀도 실제 서버 구성과 소프트웨어 스케줄링이 중요합니다.
사전 테이블에 없는 새로운 용어와 긴 로그 같은 동적 컨텍스트는 기존 신경망 경로가 처리해야 합니다. OOV가 많으면 Engram 경로의 이점이 줄고 예외 처리 비용이 늘 수 있습니다. 지식 업데이트도 테이블만 바꾸면 끝난다고 단정하기 어렵습니다. 학습된 임베딩과 백본의 결합이 유지되는지 다시 평가해야 합니다.
원문에 따르면 공개 저장소의 engram_demo_v1.py는 Attention과 MoE 같은 표준 구성요소를 모킹한 독립 실행형 데모입니다. 현재 코드가 pip install 한 번으로 운영 모델을 서빙하는 완성 프레임워크는 아닙니다. 실제 적용에는 학습 파이프라인, 비동기 호스트 조회, GPU 커널, 테이블 배포와 vLLM, PyTorch 생태계 연동이 남습니다.
같은 이름의 코딩 에이전트용 engram 도구는 SQLite 기반 영구 메모리라는 별개 프로젝트입니다. 두 프로젝트의 “기억”을 혼동하지 않는 것이 좋습니다. DeepSeek Engram의 가치는 VRAM의 저주를 즉시 없앤다는 약속보다, 모델 용량과 하드웨어 메모리 계층을 함께 설계해야 한다는 문제 제기에 있습니다.
자주 반복되고 비교적 정적인 패턴은 테이블 조회의 후보가 될 수 있습니다. 반대로 새로 생긴 용어, 임시 코드 식별자, 긴 문맥에서만 의미가 정해지는 표현은 고정 N-gram 주소만으로 다루기 어렵습니다. 실제 데이터에서 조회 빈도와 미등록 비율을 측정해야 메모리 테이블이 얼마나 자주 유효한 신호를 주는지 알 수 있습니다.
N의 크기도 교환 관계를 만듭니다. 짧은 패턴은 재사용이 많지만 서로 다른 문맥을 구분하지 못할 수 있고, 긴 패턴은 더 구체적이지만 테이블이 커지고 미등록 비율이 높아질 수 있습니다. 토크나이저가 바뀌면 같은 문자열의 N-gram 구성도 달라지므로 테이블과 백본의 버전을 묶어 관리해야 합니다.
GPU에서 줄어든 HBM만 보고 시스템 메모리가 절감됐다고 말하면 안 됩니다. N-gram 테이블의 DRAM 용량, 호스트 캐시, 전송 버퍼, 모델 가중치, KV 캐시를 모두 합쳐야 합니다. 같은 품질의 일반 모델과 비교할 때는 Engram 경로까지 포함한 총 파라미터와 저장 공간을 표시해야 합니다.
동시 요청이 늘면 각 요청의 동적 KV 캐시와 전송 큐가 별도로 커질 수 있습니다. 정적 테이블을 공유할 수 있다는 장점과 요청별 상태 비용을 분리해 재야 합니다. 서버 한 대에서 맞더라도 여러 장비로 확장할 때 테이블 복제와 배포 시간이 운영 비용이 될 수 있습니다.
테이블이 캐시에 잘 맞는 인기 패턴과 캐시 미스가 잦은 드문 패턴을 나눠 지연을 측정합니다. 평균 토큰 속도뿐 아니라 첫 토큰, 토큰별 꼬리 지연, 호스트 대역폭 사용률을 기록합니다. 여러 요청이 동시에 다른 주소를 조회할 때 전송이 직렬화되는지도 확인해야 합니다.
룩업을 미리 가져오는 비동기 방식이 있다면 정확히 필요한 주소를 예측하지 못했을 때의 낭비를 포함합니다. 계산과 전송이 겹쳐졌는지 타임라인으로 보고, 캐시 크기와 배치가 달라질 때 결과를 반복합니다. DRAM 용량이 충분하다는 사실은 대역폭과 지연이 충분하다는 뜻이 아닙니다.
테이블의 한 항목을 바꿔도 백본이 그 임베딩을 어떤 의미로 사용하도록 학습됐는지는 그대로입니다. 새 지식을 임의 벡터로 넣거나 다른 시점의 테이블을 결합하면 표현 공간이 어긋날 수 있습니다. 업데이트 전후에 지식 질문뿐 아니라 일반 언어 품질과 관련 없는 문맥의 퇴행을 함께 평가해야 합니다.
삭제와 버전 되돌리기도 필요합니다. 특정 테이블을 사용하는 모델 버전, 토크나이저, 삽입 레이어를 하나의 배포 단위로 기록합니다. 여러 서버가 서로 다른 테이블을 읽는 동안 같은 요청에 다른 결과가 나올 수 있으므로 원자적인 배포나 명시적인 버전 라우팅이 필요합니다.
먼저 공개 데모가 보여 주는 텐서 형태와 결합 위치를 확인하고 운영 서빙과 구분합니다. 다음으로 작은 백본과 제한된 데이터에서 Engram을 넣지 않은 기준선, 테이블만 추가한 구성, 삽입 위치를 바꾼 구성을 같은 학습량으로 비교합니다. 정확도와 총 메모리, 처리량, 미등록 비율을 함께 기록합니다.
후보가 남으면 실제 목표 하드웨어에서 DRAM과 GPU 사이 전송을 포함한 서빙 시험을 합니다. 짧은 문장과 긴 문맥, 인기 패턴과 새 용어, 단일 요청과 동시 요청을 나눕니다. 품질 점수 상승이 시스템 복잡성과 꼬리 지연을 정당화할 때에만 더 큰 모델로 확대하는 것이 합리적입니다.
아닙니다. 정적 N-gram 임베딩을 별도 메모리 계층에서 조회하는 구조이며 모델 가중치, 동적 컨텍스트와 Transformer 연산은 여전히 GPU 자원을 사용합니다.
그렇지 않습니다. 룩업 주소 계산과 DRAM 접근 외에도 PCIe 전송, 캐시 미스, Attention, MoE 연산이 남으므로 전체 지연은 별도로 측정해야 합니다.
현재 글에서 다룬 공개 코드는 아키텍처 데모 단계입니다. 실제 학습, 비동기 조회, GPU 연동, 테이블 배포와 장애 복구를 추가로 구현하고 검증해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.