안녕하세요. 이번 리뷰는 최근 연구 및 실험 중인 MLLM (LMM) Token Reduction에 관한 논문입니다. 요즘 “MLLM의 VG/Segmentation에서 Token Reduction 시 성능 및 효율성을 고려하는 방법”에 관해 실험을 하고 있습니다. 본 방법론도 비교군 중 하나로, 우선 원활한 이해를 위해서는 최신 Token Reduction 방법론이 어떠한 측면에서 이루어지고 있는지를 이해해야 합니다. 방법론 측면에서 보면 Token Reduction의 위치가 (LLaVA 기준) CLIP의 ImageEncoder에서 수행되는지 / LLaMa (LLM)에서 수행되는지로 나뉩니다. 효율성 측면에서 전자는 아래 그림의 Decode First token time (LLM이 decoding 시 첫 번째 토큰을 생성할 때까지 걸리는 시간)이 중요 지표이며, 후자는 LLM의 연산 시간/메모리가 중요 지표입니다. 본 방법론은 CLIP의 ImageEncoder에서만 수행되며, LLM에서 수행되진 않습니다. 이 점을 염두에 두면 내용 이해에 훨씬 쉽습니다.
Introduction
MLLM (LLM)의 놀랄만한 성능의 뒷면에는 수 많은 파라미터로부터 오는 많은 양의 메모리 소비와 추론 속도 지연이 따라옵니다. 적어도 이 논문이전까지는, 이를 극복하기 위한 방법 중 하나인 Token Reduction 측면에서 PruMerge라는 논문 (이전 리뷰 글)밖에 소개되지 않았습니다. PruMerge에서는 이미지에 대해 Query/Key 간의 연산으로 이미지 토큰의 중요도를 판단하여, Top-K개 이외의 토큰을 Pruning합니다. 이에 추가로 Pruning된 토큰들을 Merging하여 정보를 보완해줍니다.
하지만 이는 다음과 같은 문제점이 있음을 지적하며, 저자는 Token Reduction using CLIP Metric (이하 TRIM)을 제안합니다. 문제점은 위 그림으로 설명이 가능합니다. 즉, 이미지에 대해 중요한 토큰을 가름짓는 것은 이미지 자체만이 아닌 텍스트라는 것입니다. 이미지에 대해 유저가 “remote control”을 요구하는지, “kitten”을 요구하는지 다를 수 있는데, 그 점을 고려하지 않고 이미지만 보고 중요 토큰을 판별하는 것에는 문제가 있다는 것이죠. 물론, 실험에서 언급하겠지만 이전 PruMerge의 저자가 이를 고려하지 못했을리는 없을 것이라 생각합니다. 우선 요즘의 방법들은 주로 텍스트를 사용함이 정설처럼 되어가는데, 이 논문은 그 시초입니다. 빠르게 방법론으로 넘어가봅시다.
Method
방법론 자체가 한 페이지 분량으로 길지 않습니다. Token Reudction의 핵심은 서로 다른 토큰 (LLaVA 기준 576)에서 어떤 토큰이 중요한지를 판별하는 것입니다. 앞서 말한 바와 같이 저자는 이때 텍스트 프롬프트가 핵심임을 언급하며, LLaVA 기준 CLIP ImageEncoder를 사용하기에 텍스트 프롬프트를 CLIP TextEncoder를 태웁니다 (위 그림의 Language Instruction이 Text Encoder로 통과하는 모습입니다). 텍스트의 [eot] 토큰 (텍스트 전체를 요약하는 정보를 포함)을 활용하여 (그림의 u_{pooled} ) 이미지 토큰과의 유사도 매트릭스를 (similarity matrix)를 활용합니다. 이 유사도는 576개의 이미지 토큰과 [eot] 토큰과의 cosine similarity를 소프트맥스 태워 나온 값입니다. 이 유사도 값을 기반으로 중요 토큰을 선별합니다. 이 때 몇 개의 토큰을 선별할 지는 PruMerge의 IQR 방법을 차용하여, 유사도 점수의 IQR 점수 (outlier를 판별)로 개수를 정합니다. 이는 곧 정해진 수가 아닌 이미지와 텍스트에 따라, 유동적으로 토큰을 제거할 수 있음을 의미합니다. 마지막으로, PruMerge와 마찬가지로 Pruning된 토큰들을 모아 (Merging), 정보를 보완하기 위해 그들을 평균낸 하나의 토큰을 추가하여 활용합니다. 방법론은 이로써 끝입니다. 사실 우리가 CLIP을 이미 잘 알고 있기에, 즉 CLIP의 ImageEncoder와 TextEncoder (CLIP ViT-L/32)와 그 사이의 유사도를 구하는 과정을 잘 알고 있기에 사실은 크게 어렵지 않습니다. 이외 IQR 방법이나 Merging 방식은 이전의 PruMerge에서 영감받았기에 사실 신규성 자체가 크다고 생각되진 않습니다.
Experiments
이전 PruMerge도, 본 논문의 TRIM도 모두 LLaVA에서 시작합니다. 실제로 두 방법의 코드를 보면, 2024/25년도 논문임에도 불구하고 100줄 남짓의 코드만 존재합니다. 그만큼 구현면에선 단순합니다. 위 12개의 LLaVA 벤치마크의 결과를보면, PruMerge에 비해 TRIM은 기존 LLaVA 비교 63.5->61.8 (Vicuna-7B 기준), 66.7->62.8 (Vicuna-13B)의 2-4퍼센트 정도의 성능 차이만 납니다. PruMerge와 비교 시에 Ratio (Token Reduction 이후 남은 토큰의 비율)은 약 21%로, 물론 PruMerge+의 25% 대비 4% 대비 더 많이 남긴 합니다만, 이 정도면 그래도 성능면에서 약 1-3%가 좋다보니 이해되는 수준입니다. 그런데 제가 초반부에 언급했듯, 사실 본 논문의 방법론을 보면 PruMerge와 비교해서 CLIP의 TextEncoder를 사용해야 한단 단점이 있습니다. 즉, 텍스트 프롬프트를 활용한다는 점은 다시 말해 원래의 LLaVA에선 수행되지 않았던 CLIP의 TextEncoder를 사용함에 따르는 연산량 증가가 존재합니다. 본 논문에서 이 점은 쏙 뺴놓았지만, 그래도 알아두면 좋을듯합니다.
효율성 측면에서는 메모리 소비 (GB), First Token / Next Token의 LLM 디코딩 시 첫 토큰 생성까지, 그리고 다음 토큰 생성까지 걸리는 시간 (ms) 비교입니다. TRIM은 기존 LLaVA 대비와 PruMerge에서 메모리와 First Token에서 우수한 모습을 보입니다. 그런데 과연 앞서 말한 바와 같이, 과연 이 계산에서 TextEncoder를 포함시켰는지는 의문입니다. 자세히는 적혀져 있지는 않지만, LLM 연산에 대해서만 계산한 것 같습니다.
마지막으로 Ablation을 하나 가져왔습니다. 여기서 말하고자 하는 바는 두 가지로, 첫 번째는 지난 리뷰에서 언급한 바와 같이 Random이나 Pooling과 같은 방식으로도 충분히 높은 성능을 보인다는 것에서 놀랍다는 (아마도 제 생각에는, 랜덤으로 제거하더라도 LLM이 그 이름 (Large) 답게 잘 수행해내는 것 같습니다)면이며, 두 번째로는 Training으로 약 2-3%의 성능 향상이 있단 점입니다. 이 점은 요즘 추세와는 벗어납니다. 즉, MLLM을 Training 시켜야한다는 것이 LLaVA 기준 A100 80G 8장이 필요한데, 이것을 학습시키기 위해서는… 어마한 돈이 필요합니다. 그래서인지 요즘에는 Training-free가 대세입니다. 그렇기에 2025, 올해 논문임에도 물구하고 이 이후에도 최근까지 지속적으로 연구되고 있는 추세입니다.
이번 리뷰글은 굉장히 짧았네요. 실제로 논문이 5장짜리여서 방법론 자체가 깊지 않아, 읽기에도 충분했으며 다음 번에는 이를 Segmentation (VG)에 활용한 실험 결과도 한 번 들고와보겠습니다. 감사합니다.
