12 분 소요

0. Introduction

Paper link

한 줄 요약: Jamba-1.5는 “Transformer vs Mamba”의 승부를 내는 논문이 아니라, Attention·Mamba·MoE·Quantization·Post-training을 함께 묶어 256K long-context serving을 현실적인 비용 안으로 가져오려는 시스템 아키텍처 리포트에 가깝다.

0-1. 왜 지금 읽을 가치가 있는가

  • 하이브리드 SSM-Attention 계열이 아이디어 수준이 아니라, 94B active / 398B total, 256K context, 8×80GB serving 같은 실제 제약 아래 어떻게 설계되는지 보여준다.
  • 이 논문의 핵심은 “Mamba를 섞었다”가 아니라, MoE-targeted quantization, activation control, long-context-aware post-training까지 포함한 serving-aware architecture라는 점에 있다.
  • 무엇보다도, 더 최신 계열인 Mamba-2를 그대로 채택하지 않고, hybrid setting에서는 오히려 Mamba-1-Attention이 더 낫다고 보고한 점이 흥미롭다. 이건 단순한 버전 업 논리가 아니라, 하이브리드 구조에서 무엇이 실제로 중요한가를 다시 생각하게 만든다.

0-2. 먼저 말하고 싶은 핵심 결론

  1. Jamba-1.5의 진짜 메시지는 pure architecture debate보다 hybrid operating point가 더 실전적이라는 것이다.
  2. long-context 품질은 token mixer 하나로 나오지 않는다. KV cache, sparse FFN, quantization path, post-training data mix가 같이 맞물려야 한다.
  3. 그래서 이 논문은 모델 리뷰이면서 동시에 서빙 설계 보고서로 읽는 편이 훨씬 낫다.

0-3. 이 글의 관점

이 글은 Jamba-1.5 원문을 1차 기준으로 읽되, 하이브리드 구조의 배경 설명이 필요한 부분은 원저 Jamba: A Hybrid Transformer-Mamba Language Model도 함께 참고한 관점에서 정리했다. 따라서 아래 내용에는 두 층위가 섞여 있다.

  • 원문에서 직접 확인되는 사실: 모델 크기, block 구성, quantization 방식, training/eval 설정
  • 배경 설명을 위한 보조 해석: 왜 attention을 완전히 없애지 않았는가, 왜 hybrid에서 Mamba-2보다 Mamba-1이 나을 수 있는가
  • 내 해석: 이 구조가 연구보다 실서비스 관점에서 더 의미 있는 이유

1. Problem Setting

1-1. Problem definition

Jamba-1.5가 겨냥하는 문제는 분명하다. 요약하면 아래 두 가지다.

  • 긴 컨텍스트를 다루는 open model을 실제 하드웨어 예산 안에서 서빙하고 싶다.
  • 그렇다고 pure SSM 계열로 가서 assistant quality, retrieval, tool-use capability를 잃고 싶지는 않다.

Transformer 계열은 품질과 일반성 면에서 여전히 강하지만, 긴 컨텍스트에서는 attention 계산량과 KV cache가 꽤 부담이 된다. 반대로 Mamba류 SSM은 recurrent state 기반이라 KV cache 부담을 크게 줄일 수 있고, 긴 시퀀스에서 latency/throughput 측면 이점이 있다. 하지만 실제 assistant 모델에서 필요한 것은 단순한 sequence modeling이 아니라, instruction following, format adherence, retrieval-like behavior, long-context QA, tool use까지 포함한 종합 역량이다.

즉 문제는 “Attention이냐 SSM이냐”의 이분법이 아니다. 어느 정도의 attention을 남기고, 어느 정도의 recurrent mixer를 섞고, sparse capacity는 어떻게 얹고, 그 결과를 실제로 어떻게 서빙할 것인가가 문제다.

1-2. Why previous approaches are insufficient

기존 접근의 한계는 세 갈래로 볼 수 있다.

1) Attention-only 모델의 long-context 비용

attention-only 모델은 컨텍스트가 길어질수록 KV cache와 end-to-end latency 부담이 커진다. 특히 128K~256K 구간에서는 “성능이 나온다”와 “실제로 돌릴 수 있다” 사이의 차이가 급격히 커진다.

2) Pure SSM의 capability gap 가능성

원저 Jamba의 ablation을 보면, pure Mamba는 일부 few-shot / format-sensitive task에서 pure attention보다 약했고, hybrid는 이를 상당 부분 메웠다. 즉 긴 문맥 효율만 보고 attention을 완전히 제거하는 것이 항상 좋은 선택은 아니라는 시사점이 있었다.

3) 모델 구조만으로는 serving 문제가 풀리지 않음

모델이 MoE-heavy해질수록 parameter 대부분은 expert 쪽에 몰린다. 이런 상황에서는 일반적인 “전체 모델을 그냥 quantize하자”는 접근보다, 어디에 파라미터가 집중되어 있는지에 맞춘 quantization/serving 전략이 훨씬 중요해진다.

2. Core Idea

2-1. Main contribution

Jamba-1.5의 핵심 기여는 크게 네 가지로 정리할 수 있다.

  1. 대규모 hybrid Transformer-Mamba-MoE instruction model을 공개했다.
    • Jamba-1.5-Mini: 52B total / 12B active
    • Jamba-1.5-Large: 398B total / 94B active

  2. Jamba 하이브리드 구조를 대형 스케일과 instruction tuning까지 진행했다.
    Attention과 Mamba를 1:7 비율로 섞고, MoE를 매 2개 layer마다 넣는 구조를 유지한다.

  3. ExpertsInt8와 Activation Loss를 통해 서빙 경로를 따로 다듬었다.
    즉 이 논문은 아키텍처 논문이면서 동시에 inference engineering report다.

  4. post-training에서도 long-context capability를 보존하려는 recipe를 분명히 드러낸다.
    짧은 instruction data만 넣으면 long-context가 쉽게 무너질 수 있기 때문에, conversational / skill-specific / long-context 데이터를 섞는 전략을 취한다.

2-2. Design intuition

이 논문의 설계 직관은 생각보다 단순하다.

  • Attention layer는 비싸지만 여전히 중요하다.
    global retrieval, formatting, instruction following, ICL-like behavior를 완전히 버리기 어렵다.

  • Mamba layer는 대부분의 token mixing을 더 싼 비용으로 처리한다.
    그래서 attention의 개수를 최소화하면서도 긴 문맥 처리 효율을 가져갈 수 있다.

  • MoE는 capacity를 올리되 active compute를 통제한다.
    total params와 active params를 분리해서 보는 이유가 여기 있다.

  • Serving은 expert weight가 대부분인 구조에 맞춰 따로 최적화해야 한다.
    그러니 quantization도 “모델 전체”가 아니라 MoE/MLP 중심으로 바라본다.

이 설계는 “SSM이 Transformer를 대체할 수 있다”는 서사가 아니라 Transformer가 꼭 필요한 부분만 남기고, 나머지는 더 싼 mixer와 sparse FFN으로 바꿔치기한 구조라고 읽는 편이 좋다.

3. Architecture / Method

3-1. Overview

Item Description
Goal 256K long-context를 지원하면서도 일반 assistant task에서 경쟁력을 유지하는 open-weight model
Key module Hybrid decoder: Attention + Mamba + MoE
Difference from prior work 하이브리드 구조를 instruction-tuned 대형 모델로 확장하고, ExpertsInt8 / Activation Loss / long-context-aware post-training까지 같이 묶음

Jamba-1.5-Large의 핵심 구조적 사실만 뽑으면 아래와 같다.

Item Jamba-1.5-Large
Total parameters 398B
Active parameters 94B
Blocks 9
Layers per block 8
Attention : Mamba ratio 1 : 7
MoE frequency every 2 layers
Experts / Top-k 16 experts / top-2
Hidden size 8192
Attention heads 64 Q heads / 8 KV heads
KV cache at 256K context 9GB

비교 관점에서 보면 이 9GB KV cache라는 수치가 매우 중요하다. 같은 256K 기준에서 paper가 제시한 표에서는 LLaMA-3.1 70B가 80GB, Mistral-Large-2가 88GB, LLaMA-3.1 405B가 252GB 수준으로 제시된다. 즉 이 논문의 메시지는 “더 큰 총 파라미터를 가졌는데도 long-context memory footprint는 훨씬 작다”는 데 있다.

3-2. Module breakdown

1) Hybrid token mixer

가장 먼저 봐야 할 것은 Attention과 Mamba를 섞는 방식이다.

Jamba-1.5-Large는 9개 block으로 이루어져 있고, 각 block은 8개 layer를 가진다. 여기서 attention:Mamba 비율은 1:7이다. 즉 attention은 “주기적으로 들어가는 보강 수단”에 가깝고, 대부분의 sequence processing은 Mamba가 담당한다.

이 구조에서 특히 중요한 포인트는 Mamba-2를 채택하지 않았다는 점이다. 논문은 350M과 1.3B scale에서 Mamba-1, Mamba-2, 그리고 각각의 hybrid version을 비교했고, pure setting에서는 Mamba-2가 낫지만 hybrid setting에서는 Mamba-1-Attention이 더 잘 나왔다고 보고한다.

이 결과는 꽤 의미심장하다. 내 해석으로는, hybrid stack에서는 full attention layer가 이미 주기적으로 global pooling site 역할을 한다. 그렇다면 Mamba-2가 pure SSM setting에서 가지는 장점 중 일부는 하이브리드 구조 안에서 상대적으로 덜 중요해질 수 있다. 즉 좋은 mixer가 무엇인가는 단독 모델이 아니라 어떤 조합 안에 놓이는가에 따라 달라진다.

2) Sparse capacity via MoE

Jamba-1.5는 attention과 Mamba만 섞은 것이 아니라, MoE를 매 2개 layer마다 넣는다. expert 수는 16개이고, 토큰마다 top-2 expert를 선택한다.

여기서 중요한 것은 MoE가 단순히 “모델을 크게 만들기 위한 장식”이 아니라는 점이다.

  • total params는 크게 올릴 수 있다.
  • 하지만 active params는 그보다 훨씬 작게 유지할 수 있다.
  • 따라서 quality / capacity / latency / memory 사이의 trade-off를 더 세밀하게 조정할 수 있다.

Jamba-1.5-Large를 398B total / 94B active라고 소개하는 이유도 바로 여기에 있다. 이 구조에서는 “모델 크기”라는 표현 하나로는 아무것도 설명되지 않는다. active compute와 long-context memory footprint를 같이 봐야 한다.

3) ExpertsInt8

이 논문에서 내가 가장 흥미롭게 본 부분은 사실 token mixer보다도 ExpertsInt8다.

논문에 따르면, Jamba-1.5-Large의 경우 85% 이상 가중치가 MoE layer에 있고, 90% 이상이 MoE 또는 MLP에 있다. 그러니 quantization 전략도 그쪽에 집중하는 것이 합리적이다.

ExpertsInt8의 아이디어는 다음과 같다.

  • MoE와 MLP weights를 INT8로 저장한다.
  • 실제 계산 직전에는 BF16으로 dequantize한다.
  • 이 dequantization을 vLLM의 fused_moe kernel 내부에서 처리한다.

핵심은 “INT8으로 계산한다”가 아니다. INT8으로 저장하고, 이동 비용을 줄이고, BF16 kernel 생태계를 그대로 활용한다는 점이다. 이건 굉장히 실무적인 선택이다.

논문은 이 방식이 calibration이 필요 없고, model load 시 몇 초면 준비되며, A100에서도 쓸 수 있고, H100에서는 FP8과 비슷한 latency를 보인다고 설명한다. 즉 여기서의 혁신은 quantization algorithm 자체라기보다 MoE-heavy model serving path에 맞춘 integration에 있다.

4) Activation Loss

또 하나 재미있는 부분은 Activation Loss다.

논문에 따르면 pre-training 중 일부 expert output과 마지막 Mamba layer output의 activation magnitude가 특정 token에서 점점 커져서 최대 4×10^6 수준까지 올라갔다. BF16 pretraining 자체에는 큰 문제가 없었지만, inference toolchain 일부는 FP16 activation만 지원하고 최대 표현 범위가 64K 정도라서 실제 서빙에서는 문제가 될 수 있다.

이를 해결하기 위해 저자들은 activation의 mean-square에 비례하는 auxiliary loss를 추가했고, Jamba-1.5-Large에는 α = 10^-5를 사용했다. 그 결과 activation max를 2K~3K 수준으로 내릴 수 있었고, 심지어 훈련 후반부에 추가해도 speed/quality에 큰 영향을 주지 않았다고 한다.

이건 굉장히 중요한 메시지다. 학습은 잘 되는데 배포 시 수치 범위 때문에 깨지는 문제는 논문에서 자주 전면에 나오지 않는다. 그런데 Jamba-1.5는 이런 문제를 감추지 않고 직접 다룬다. 그래서 더 믿을 만한 시스템 보고서처럼 보인다.

4. Training / Data / Recipe

4-1. Data

논문이 공개하는 training data 정보는 아주 자세하진 않지만, 큰 방향은 꽤 명확하다.

Pre-training

  • in-house dataset 사용
  • 2024년 3월 기준으로 업데이트된 데이터
  • publicly available web documents, code, books, scientific articles의 mixture
  • parsing, quality filtering, deduplication 수행
  • 자체 parser를 만들어 text와 formatting을 함께 추출
  • 영어 외에도 Spanish, French, Portuguese, Italian, Dutch, German, Arabic, Hebrew 등을 포함한 multilingual data 사용

Mid-training

  • long documents 비중이 높은 짧은 mid-training 단계를 별도로 수행
  • 목적은 long-range capability를 강조하는 것

Post-training

  • high-quality conversational data
  • skill-specific data
  • long-context data

즉 Jamba-1.5는 “처음부터 긴 문맥을 잘하도록 pretrain한 뒤, post-training에서 그 능력이 무너지지 않게 관리하는” 흐름으로 읽는 편이 정확하다.

4-2. Training strategy

Jamba-1.5-Large는 NVIDIA H100 GPU에서 AI21의 in-house framework로 학습되었고, 아래 병렬화 전략이 언급된다.

  • FSDP
  • tensor parallelism
  • sequence parallelism
  • expert parallelism
  • expert parallel 쪽은 MegaBlocks를 adapted 해서 사용

중요한 것은 training stage가 세 단계로 분리되어 있다는 점이다.

  1. pre-training
    일반 지식, 코드, 문서 이해, multilingual foundation 형성

  2. mid-training on long documents
    long-context capability를 강화

  3. post-training
    assistant capability를 부여하면서도 long-context를 보존

논문이 직접 강조하는 tension도 있다. 대부분의 post-training 데이터는 짧기 때문에, instruction tuning만 강하게 돌리면 long-context 능력이 쉽게 약해질 수 있다. 그래서 저자들은 post-training 자체를 short-form alignment가 아니라 capability preservation problem으로 다룬다.

4-3. Engineering notes

이 논문에서 training recipe의 핵심은 synthetic data pipeline의 역할이다. 논문은 여러 가지 capability-specific data synthesis pipeline을 소개한다.

1) Table-based QA

표를 생성하고 QA pair를 만든 뒤, 이를 다시 자연어 paragraph로 변환한다. 여기서는 extraction, aggregation, attribution 같은 능력을 함께 학습시킨다.

2) Document QA

문서에서 single-paragraph / multi-paragraph QA를 생성하고, 때로는 비슷한 텍스트를 더 붙여 context를 늘린다. 핵심은 long-context attribution을 직접 학습시키려는 의도다.

3) Tool use

Glaive function-calling dataset을 출발점으로 사용하고, schema validation과 heuristic filtering을 거친다. 여기에 parallel function calling을 지원하기 위해 여러 valid parameter assignment를 만들고, 그걸 만족하는 user request를 다시 생성한다.

4) Steerability

제약이 걸린 문서 작성 task를 합성하고, validation + reward model 기반 rejection sampling으로 결과를 걸러낸다. 그리고 일부는 system message instruction 형태로 재구성한다.

논문 후반 observation도 흥미롭다.

  • post-training에서는 non-English 비중이 작아도 multilingual 성능이 꽤 잘 유지됐다.
  • 효율적인 Jamba 구조 덕분에 long-context fine-tuning 실험을 더 많이 돌릴 수 있었다.
  • PPO/DPO 같은 preference tuning도 중요하지만, 강한 post-trained model을 얻는 데는 careful synthetic data generation + filtering + SFT가 특히 중요했다고 말한다.

이 대목은 꽤 현실적이다. 결국 좋은 assistant는 objective 이름보다 좋은 데이터 엔진과 반복 가능한 recipe에서 나오는 경우가 많다.

5. Evaluation

5-1. Main results

논문의 평가 메시지는 과장 없이 정리하면 아래와 같다.

  • 일반 benchmark에서는 동급 attention-only 모델과 대체로 competitive하다.
  • chatbot benchmark에서도 꽤 강하다.
  • 하지만 이 논문의 가장 큰 강점은 long-context benchmark + latency/throughput + memory footprint에서 드러난다.

핵심 수치 몇 개만 추리면 아래 정도가 중요하다.

Benchmark / Aspect Jamba-1.5-Large Comparator 읽는 포인트
MMLU 80.0 LLaMA-3.1 70B: 83.6 / Mistral-Large-2: 82.5 일반 지식 품질은 competitive하지만 최고점은 아님
GPQA 36.9 LLaMA-3.1 70B: 36.0 / Mistral-Large-2: 40.7 어려운 과학 QA에서는 비슷한 수준
BFCL 85.5 LLaMA-3.1 70B: 84.8 / Mistral-Large-2: 85.1 function calling은 strong
Arena-Hard 65.4 LLaMA-3.1 70B: 55.7 / Mistral-Large-2: 70.4 assistant quality는 강하지만 Mistral-L-2에는 못 미침
RULER Avg. 95.7 LLaMA-3.1 70B: 89.6 / Mistral-Large-2: 80.5 long-context에서 가장 설득력 있는 지표

특히 RULER에서 Jamba-1.5-Large는 claimed length 256K, effective length 256K로 표기되고, 평균 95.7을 기록한다. Mini도 effective length 256K로 보고된다. 논문은 Jamba-1.5 모델들이 confirmed effective length 256K를 가진 유일한 모델들이라고 주장한다.

Infinite-BENCH는 조금 더 nuance가 필요하다. Large 기준으로

  • EN.MC: 80.4
  • EN.QA: 34.9

를 기록한다. EN.MC에서는 LLaMA-3.1 70B와 Mistral-Large-2를 앞서지만, EN.QA에서는 LLaMA-3.1 70B보다 낮다. 그래서 long-context story를 읽을 때는 “모든 자연 문서 task에서 압도”라기보다, RULER에서의 확실한 effective length + 일부 naturalistic long-context task에서의 strong performance로 이해하는 편이 좋다.

5-2. What really matters in the experiments

이 논문을 읽을 때 진짜 중요한 실험 포인트는 세 가지라고 본다.

1) “일반 benchmark 최고점”이 아니라 “비슷한 품질 + 훨씬 나은 효율”

Jamba-1.5-Large는 standard benchmark에서 대체로 competitive하지만, 대부분의 지표에서 무조건 최고는 아니다. 논문도 이를 숨기지 않는다. 오히려 메시지는 일관되게 similar quality with much better throughput and latency다.

즉 이 모델의 가치는 pure quality frontier보다 system efficiency frontier에 더 가깝다.

2) KV cache와 effective length가 핵심 지표

Table 1과 long-context section을 같이 보면, Jamba-1.5의 차별점은 파라미터 수보다 256K 컨텍스트에서의 memory behavior다. 이 구조에서는 “모델이 몇 B인가?”보다 256K에서 KV cache가 얼마인가, 그 길이를 실제로 유지하는가가 훨씬 중요하다.

3) Serving benchmark는 hardware-specific하다는 점

throughput/latency figure는 Mini는 2×A100 80GB, Large는 8×A100 80GB, batch size 1, output length 512 tokens 설정에서 측정되었다. 따라서 이 숫자들은 절대적인 알고리즘 우열표라기보다, 특정 serving point에서의 비교 결과로 읽어야 한다.

그럼에도 메시지는 분명하다. 긴 컨텍스트로 갈수록 Jamba의 advantage가 커지고, LLaMA-3.1-405B는 같은 8×80GB 설정에서 100K 이상 컨텍스트를 제대로 싣기 어렵다고 paper는 적는다. 이건 “이론적 효율”이 아니라 실제로 어떤 모델이 같은 기계에서 돌아가느냐의 문제다.

6. Limitations

  1. architecture gain과 recipe gain을 완전히 분리하기 어렵다.
    데이터 mixture, 총 training token 수, internal metric 기반 recipe selection 등은 자세히 공개되지 않는다. 그래서 이 논문의 성과를 순수하게 hybrid architecture의 힘이라고만 해석하긴 어렵다.

  2. 일반 benchmark quality는 competitive하지만 dominant하지는 않다.
    MMLU, HumanEval, IFEval 등에서 attention-only strong baseline이 더 높은 경우가 적지 않다. 즉 “무조건 최고의 범용 모델”을 찾는 관점에서는 다른 선택지가 여전히 유효하다.

  3. long-context 강점의 해석에는 nuance가 필요하다.
    RULER에서는 아주 강하지만, Infinite-BENCH의 각 task에서 항상 최고는 아니다. 따라서 256K effective length를 “모든 enterprise long-doc workflow에서 자동으로 더 좋다”로 일반화하면 안 된다.

  4. baseline 비교 중 일부는 저자 측 재평가나 외부 리더보드 수치를 포함한다.
    논문 자체도 footnote에서 Mistral-Large-2의 ARC-C 실패, LLaMA-3.1의 GSM8K strict/flexible 차이 등을 따로 언급한다. 이런 부분은 independent replication이 붙어야 더 단단해진다.

  5. safety/alignment section은 비교적 high-level이다.
    OECD principle과 code-of-conduct 중심의 설명은 있지만, 안전성에 대한 세밀한 공개 실험 프레임까지 제공하는 논문은 아니다.

7. My Take

7-1. Why this matters for my work

내 관점에서 Jamba-1.5가 중요한 이유는 하나다. 이 논문은 architecture를 systems engineering으로 읽게 만든다.

보통 efficient model 논문을 읽을 때 attention rule이나 mixer 수식에 시선이 먼저 간다. 그런데 Jamba-1.5는 다른 얘기를 한다.

  • hybrid token mixer를 고른다.
  • sparse FFN으로 capacity를 올린다.
  • MoE weight distribution에 맞춰 quantization path를 바꾼다.
  • activation range를 제어해서 실제 inference toolchain에 맞춘다.
  • post-training에서도 long-context를 보존하는 data mix를 설계한다.

이건 “새로운 블록 하나”의 문제가 아니라, 모델을 실제 서비스 워크로드에 맞게 재구성하는 일이다. 그래서 long-context, document QA, enterprise assistant 같은 use case를 보는 입장에서는 상당히 배울 점이 많다.

7-2. Reuse potential

Jamba-1.5에서 바로 재사용 가능한 아이디어는 아래 몇 가지라고 본다.

1) MoE-heavy model은 expert 중심으로 최적화하라

파라미터의 대부분이 expert에 몰려 있다면, quantization도 routing-aware / expert-aware하게 가는 것이 맞다. 그냥 “모델 전체를 PTQ”보다 훨씬 실용적일 수 있다.

2) long-context assistant는 mid-training + post-training을 같이 설계하라

긴 문맥 capability는 pretraining만으로 끝나지 않는다. post-training에서 짧은 chat data만 잔뜩 넣으면 쉽게 손상될 수 있다. Jamba-1.5는 이 지점을 꽤 정직하게 드러낸다.

3) activation range 문제를 deployment 관점에서 미리 다뤄라

학습은 BF16으로 잘 돌아가는데 inference stack은 FP16 제약 때문에 깨지는 상황은 생각보다 흔하다. Activation loss처럼 단순한 보조 손실이 나중의 디버깅 비용을 크게 줄일 수 있다.

4) pure replacement보다 hybrid operating point를 먼저 보라

최근 efficient sequence model 흐름을 보면, “attention을 완전히 없앤다”보다 attention을 얼마나 남길 것인가가 더 중요한 질문일 때가 많다. Jamba-1.5는 바로 그 실전형 대답 중 하나다.

7-3. Follow-up papers

  • Jamba: A Hybrid Transformer-Mamba Language Model
    Jamba-1.5의 구조적 배경과 hybrid rationale, 특히 attention:Mamba ratio와 ICL 관련 ablation을 보려면 원저를 같이 읽는 것이 좋다.

  • Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality
    Mamba-2와 SSD 관점을 통해, 왜 pure SSM과 hybrid SSM-Attention의 설계 논리가 달라지는지 더 넓은 시야에서 볼 수 있다.

8. Summary

  • Jamba-1.5는 단순한 open model 발표가 아니라, hybrid architecture를 실제 serving 제약 아래 확장한 시스템 리포트다.
  • 구조의 핵심은 주기적인 full attention + 많은 Mamba layer + sparse MoE의 조합이다.
  • 이 논문에서 가장 배울 만한 부분은 ExpertsInt8, Activation Loss, long-context-aware post-training처럼 배포 현실과 맞닿은 엔지니어링이다.
  • 일반 benchmark에서는 대체로 competitive하지만, 가장 큰 차별점은 KV cache, latency/throughput, confirmed 256K effective length에 있다.
  • 결국 이 논문은 “Mamba가 이겼다”가 아니라, 어떤 hybrid 설계가 현재의 long-context assistant workload에 더 맞는가를 보여준다.

댓글남기기

참고