얼떨결에

이전 논문리뷰에서 다뤘던 Omni-Emotion 후속연구로 진행한 논문입니다. 스트리밍 환경에서 실시간 상호작용개념을 소개하면서 기존 오프라인 비디오에 집중했던 연구보다 더욱 실제 환경에 적합해 보입니다.

1. Introduce

기존 LMM은 오프라인 비디오 기반이기 때문에, 전체 비디오를 한 번에 보고 처리하는 데에 초점이 맞춰져 있기 때문에 공간적, 시간적, 비디오 전반의 종합적인 이해도가 높은 편입니다. 하지만 스트리밍 비디오는 전체 비디오의 맥락을 미리 알 수 없고, 이후 데이터도 계속 들어오기 때문에 지속적인 업데이트가 필요합니다.

스트리밍과 오프라인 비디오 이해의 3가지 차이점은 다음과 같습니다.

- 시간 민감성 (Time-sensitivity)

• 지금 무슨 일이 벌어지는 지는 시간에 따라 다른 답변을 요구할 수 있으며 모델은 적절한 타이밍에 정확한 응답이 필요합니다.

- 옴니 모달리티 (Omni-modality)

• 스트리밍 비디오는 항상 오디오와 함께 들어옵니다.

- 상호작용성 (Interactivity)

• Non-awakening interaction : 사용자는 언제든 에이전트와 상호작용이 가능합니다.
• Interruption : 사용자가 대화를 멈추거나 주제를 바꿀 수 있습니다.
• Proactive output : 에이전트도 판단 가능해야합니다.

본 연구에서는 상호작용 및 시각적 지시를 이해하고 이에 대해 즉각적 피드백을 수행시키기 위해 Visual Instruction Feedback을 이용하였고 이는 사전 정의된 일곱가지의 서브태스크를 지정해놓았습니다.

ViSpeak 모델은 Omni-modal을 기반으로 3단계 파인튜닝을 진행했습니다. 

1. Template Alignment

   기존 오프라인 모델 --> 스트리밍 템플릿에 맞춤

   입력과 응답이 동시에 시간 정렬

   중간에 끊는 Interruption 기능

2. Streaming Finetuning

   실시간 QA 능력 + Proactive output

3. ViSpeak-Instruct Finetuning

   Visual Instruction Feedback 태스크를 위한 tuning

결과적으로 StreamingBench ( 62.00) 및 OVO-Bench (61.08) 에서 SOTA 성능을 달성해 GPT-4o에 필적한 연구입니다.

2. Method

2.1. Visual Instruction Feedback Task

2.1.1. Task Definition

- Task = 시각적인 단서 (행동, 제스처, 이벤트 등) 만으로 사용자와 상호작용

- 정해진 시간 안에 인식하고 피드백을 제공해야

- 모든 피드백은 2인칭 관점 (너)로 이뤄지고 대화형 시나리오에 국한

2.1.2. Dataset Construction

- 공개 데이터셋

   - Anomaly Warning : OOPS, Holmes-VAU

   - Gesture : Jester

   - Humor : FunQA

   - Social Cue : Social-IQ, IntentQA, SMILE

- 자체 데이터셋

   - 약 1.2만개 영상

- 평가 방법

1. Time Accuracy 

   - 모델이 응답한 시점 T가 정답 시간 범위[t1, t2 + T]에 포함되어야함

2. Text Score

   - 대답의 내용이 시각적 행동이나 이벤트를 반영해야함

   - 상황에 맞고 긍정적이며, 사용자를 도와주는 피드백이어야 함

   - GPT-4o가 채점 (0 - 5점)

3. Overall Score

   - 각 서브태스크에 대해 O = 평균(T_acc × S)

   - 정확한 타이밍 + 적절한 답변 모두가 중요

2.2. The ViSpeak Model

2.2.1. Model Architecture

기존 LLM은 Turn-taking 방식으로 말 중간에 Interrupt가 어렵습니다. 따라서 ViSpeak은 사용자 입력과 에이전트 응답을 별도의 Stream으로 분리합니다.

<Stream 구조>

Stream 1 : User Input (비디오, 오디오, 텍스트 등) 

Stream 2 : Agent Input (History)

두 Stream은 LLM에 넣기 전 Weighted Sum으로 통합합니다. (선형 레이어로 학습)

<Segmentation>

LLM에 넣기 전 스트리밍 입력을 처리하기 위해 시간 단위로 분할합니다.

비디오 : 1 fps

오디오 : 1 sec

각 세그먼트는 <seg> 토큰으로 구분되고, LLM은 반드시 <seg>토큰에서만 응답을 시작할 수 있습니다.

<응답 포맷 / 모달리티 구분>

VITA 방식을 차용해 답변의 시작은 다음과 같이 다르게 표시합니다.

예를 들어, 사용자가 손을 흔들면, 모델은 ⇓ Nice to meet you

<언제 말할지 결정>

텍스트 응답은 기존 LLM의 Next Token Prediction으로 충분하기 때문에 다음 토큰이 예상되면 ⇐ 을 출력하고 계속 말합니다.

비주얼 응답은 단순한 토큰 예측 방식으로는 언제 말할지 판단이 불가능합니다. 따라서 별도의 binary classification head ("informative head")를 도입합니다. (MMDuet에서 착안)

   - binary classification head ("informative head") 는 "지금 말해야 하나?" 여부를 판단합니다.

   - 예를 들면 예측 점수가 임계값을 넘으면 말을 시작

오디오 응답의 Turn-taking 문제는 단순화 목적으로 고려하지 않았습니다.

<전체 흐름>

스트리밍 입력 → 이미지/오디오 인코딩 → 시간 단위 세분화 → <seg> 토큰 추가 → [사용자 입력 스트림 + 에이전트 응답 스트림] → 결합 → LLM 처리 → ⇐ / ⇒ / ⇓ 로 시작하는 응답 생성 + informative head가 응답 타이밍 조절

2.2.2. A Three-Stage Finetuning Recipe

스트리밍 대응 LLM을 처음부터 훈련하는 것은 너무 많은 리소스를 요구하기 때문에 기존 멀티모달 모델 (VITA 1.5)를 기반으로 파인튜닝을 했습니다.

2.2.2.1. Stage 1. Template Alignment

기존 오프라인 모델을 스트리밍 구조에 적응시키는 단계입니다.

VITA 1.5에서 270만개의 샘플을 200만개의 샘플로 압축해 빠른 학습을 했습니다. 

2.2.2.2. Stage 2. Streaming Finetuning

스트리밍 기반 QA 능력과 Proactive output 능력을 향상시키는 단계입니다. 

timestamp가 포함된 데이터로 실시간 반응성을 학습하고 이 단계에서 Informatve head 훈련을 진행합니다. 

MMduet을 포함해 총 65.7만개의 샘플로 학습했습니다.

2.2.2.3. Stage 3. Vispeak-Insturct Finetuning

최종적으로 논문에서 직접 수집한 Visual Instruction Feedback 태스크 데이터셋으로 튜닝합니다.

ViSpeak은 오픈소스 중 최고 성능을 기록했습니다. 

자체제작한 ViSpeak-Bench 입니다. 7가지의 서브태스크를 포함해 인간 평가과 비교한 결과입니다.

3. Experiment

2.1. Implementaton Detail

- 기반 모델 : VITA 1.5

   - LLM : Qwen2.5 7B

   - 이미지 인코더 : InternViT300M (448px)

   - 오디오 인코더 : VITA 자체 (341M 파라미터)

- 프레임 샘플링 : 1fps

- H/W : L20 GPU 32장

- Informative Head 임계값 : 0.35

2.2. Ablation Study

2 Stream 구조에서 Weighted Sum을 사용했을 때 (Adaptive Sum), 단순히 Feature 차원으로 ADD, 두 Stream을 붙이고 선형 통과(Linear) 방식을 비교했는데 성능 차이는 비슷했으나 이론적으로 가장 유연한 Adaptive Sum을 기본값으로 사용했습니다.

모델이 스스로 시각적 단서에 반응할 수 있는지 확인하는 실험에서 Inform Head를 사용하고 LLM과 공동으로 학습했을 때, 그리고 <seg> 보다 마지막 visual 토큰이 행동 경계 인식에 더 효과적이었습니다.

ViSpeak-Instruct 학습 시, 오프라인 데이터 포함 여부가 성능에 영향을 미치는지 분석을 했습니다. (HR(Humor Reaction), GU (Gesture Reaction)) 오프라인 데이터 포함 시, 제스처와 유머 인식 성능이 올라갔습니다.

파인튜닝이 진행될 수록 기존 성능은 유지하면서 스트리밍+시각 지시 반응 성능이 강화되는 것을 확인할 수 있었습니다. 

4. Conclusion

스트리밍 영상 이해에서 사람과의 자연스러운 상호작용을 위한 새로운 태스크를 제안했고, 추가적인 데이터 구축, 3단계 파인튜닝으로 학습된 ViSpeak 모델로 GPT-4o급의 SOTA 성능을 확보했습니다.

아직 유머와 이상 상황 감지(추론 능력)는 아직 부족한 것으로 파악됩니다.

이전 논문리뷰에서 다뤘던 VideoLLM-Online의 연구팀이 후속연구로 진행한 논문입니다. Fast & Slow 라는 개념을 소개하면서 이전 VideoLLM-Online을 다듬은 내용 같습니다.

1. Introduce

AR글래스나 HMD가 발전하면서 실시간 비디오 기반 AI 어시스턴트 활용이 증가했습니다. 본 연구에서는 1인칭 시점에서 주변 환경을 분석해 사전 대응하는 시스템을 연구했습니다. 기존 Online Video 어시스턴트의 한계는 다음과 같습니다. 

- 낮은 응답 결정 정확도

• 기존 시스템은 2FPS의 낮은 프레임 속도로 비디오를 처리하기 때문에 시간적 관계를 학습하는 데 한계가 있어 응답이 필요한 순간을 제대로 인식하지 못했습니다.

- 부정확한 응답 생성

• 모든 프레임을 같은 방식으로 처리해 중요한 공간 정보를 충분히 반영하지 못했습니다.

- 비효율적인 학습 및 추론

• 모든 프레임에서 동일한 수의 토큰을 유지해 불필요한 연산이 증가했습니다. 
• 응답 결정 단계에서는 많은 정보가 필요하진 않지만, 응답 생성 시에는 더 많은 정보를 활용해야합니다.

즉, 응답이 필요할 때만 연산을 집중하고, 중요 순간을 더 정밀하게 분석하는 방법을 도입했습니다.

따라서 본 연구에서는 다음과 같은  LION-FS : Fast & Slow Video-Language Thinker 프레임워크를 제안했습니다. 사람 사고 방식을 모방해, 빠른(FAST) 판단 + 정밀(SLOW) 분석을 결합했습니다. 

- Fast Path : 빠른 응답 결정

• Token Aggregation Routing 
  • 1인칭 비디오의 장점 + 3인칭 비디오의 장점
  • 고프레임 특징을 유지하면서 연산량을 증가하지 않도록 최적화
• Token Dropping Routing
  • 응답이 필요하지 않는 프레임에서는 불필요한 정보 삭제해 연산량 감소
  • 중복되는 배경, 변화가 없는 프레임 자동 감지, 토큰 감소

- Slow Path : 정밀한 응답 생성

• Global Uniform Augmentation for Grid Tokens
  
  • 키 프레임을 여러 개의 그리드로 나눠, 개별 객체와 환경 요소를 더 정밀하게 분석
  • 더 많은 공간정보를 활용해 응답의 정확도를 높임
• Local Adaptive Augmentation for Box Token
  • 손 동작 및 상호동작 중인 객체를 감지해 추가적인 정보 추출
  • Bounding Box를 사용해 중요한 객체만 선택적으로 분석

2. Method

LION-FS의 목표는 실시간 비디오 스트리밍을 처리하면서 적절한 응답 시점을 판단하고 필요할 경우 정밀한 응답을 생성하는 것입니다. Figure 2를 참고하면, 각 프레임이 들어올 때마다 Fast Path에서 응답이 필요한지 판단하고, 응답이 필요하지 않다면 다음 프레임을 분석합니다. 하지만 응답이 필요하다면 Slow Path에서 과거 문맥을 활용해 정밀한 응답을 생성하고 생성된 응답은 Autoregressive 방식으로 생성합니다.

본 연구에서는 Fast Path에서 응답 필요 여부를 학습하고(Streaming Loss), Slow Path에서는  응답을 생성하는 방식을 학습합니다(LM Loss). Loss Function은 다음과 같습니다.

2.1. Fast Path : Routing-Bassed Response Determination

Fast Path의 핵심 목표는 다음과 같습니다. 

- 고프레임 비디오에서도 실시간 응답을 제공한다. (2.1.1)

- 1인칭 시점과 3인칭 시점의 특징을 효과적으로 결합한다. (2.1.1)

- 중복된 정보를 자동으로 제거해 연산량을 최적화한다 (2.1.2)

- 응답이 필요한 순간을 정확하게 판단해 불필요한 대화 생성을 방지한다. (2.1.2)

2.1.1. Dual Encoding with Token Aggregation Router

기존 VideoLLM은 단일 이미지 인코더를 사용해 프레임을 독립적으로 처리해 시간 정보가 부족했습니다. 그리고 LLM에서 모든 프레임을 개별적으로 해석해 고프레임 비디오를 효과적으로 처리하지 못했으며 특히 3인칭 이미지 데이터로 훈련된 인코더는 1인칭 시점 비디오를 제대로 해석하지 못했습니다.

- Dual Encoding (1인칭 + 3인칭 결합)

1. E_gen (SigLIP) : 2FPS : 3인칭 시점의 일반적인 공간 정보 추출

2. E_ego (EgoVLPv2) : 8FPS : 1인칭 시점의 연속적인 시간 정보 추출

E_ego가 처리한 1인칭 시간 정보는 4개의 프레임 그룹으로 처리합니다.

CLS 토큰을 Visual Guidance(VG)로 가중치를 계산하고 SoftMax 기반의 적응형 가중치를 생성해 두 가지 특징을 가중치 기반으로 융합합니다.  결과적으로 [Frm]_i 는 두 정보가 최적의 비율로 결합된 결과입니다.

2.1.2. Sparse Decoding with Token Dropping Router

8FPS의 고프레임 비디오에서는 연속된 프레임이 거의 동일한 정보를 포함할 가능성이 큽니다. 이 중복된 프레임을 LLM에 모두 개별적으로 처리하면 연산량이 엄청나게 증가하기 때문에 중복을 제거해야합니다.

- Token Dropping Router 

반복된 프레임을 감지해 불필요한 정보를 제거하고, 객체의 움직임, 손-객체 상호작용 등의 변화가 있는 프레임만 유지합니다. 

1. 객체 움직임 : 연속된 프레임에서 변화가 있는 객체인가

2. 손-객체 상호작용 : 사용자의 손과 상호작용 중인 객체인가

3. Self-Attention 기반 중요도 평가 : 과거의 맥락에서 중요한 프레임인가

r^l : 특정 프레임의 토큰의 중요도

P^l : 특정 중요도 임계값

2.2. Slow Path : Multi-granularity Keyfame Augmetation

Fast Path에서 처리하는 프레임은 10개 토큰 (1 CLS + 3 x 3 pooled tokens) 만 사용됨 --> 세부적인 정보 손실

하지만 모든 프레임에서 Fine-grained 정보를 유지하면 연산량이 많아짐

따라서 Slow Path의 핵심 목표는 다음과 같습니다. 

- Fast Path에서 응답해야한다고 판단된 Keyframe에서만 추가적인 Augmentation을 적용해 세부 정보 보강

2.2.1. Global uniform augmentation for Grid Tokens

Keyframe(1 x 6 x 6)을 4개의 그리드로 균등하게 나누고

각 Grid마다 3 x 3 pooling을 수행해 4 x 3 x 3 토큰을 생성합니다. 

즉 Keyframe을 4개의 작은 서브 프레임으로 나누어 더 높은 해상도 정보를 보강합니다.

2.2.2. Local adaptive augmentation for Box Tokens

Faster R-CNN을 이용해 손의 위치를 탐지하고 손과 상호작용하는 객체도 추가적으로 탐지합니다. 

Bounding Box 영역에서 Average Pooling을 수행해 단일 Box Token을 생성합니다.

NMS (Non-Maximum Suppression) 최적화를 수행해 중복된 Bounding Box를 제거합니다.

손과 객체 각각의 하나의 Box Token으로 변환합니다.

생성된 Grid Token과 Box Token을 활용해 다음과 같이 Multimodel Thinking Template 포맷을 활용합니다.

Stream: [Frame Tokens] [Grid Tokens]

User: Please focus on [Box Tokens].

Assistant: [Response]

3. Experience

• 사용한 장비 : Nvidia A800 (80GB VRAM)
• 데이터셋 
  • Ego4D Narration Stream Benchmark
    • Ego4D 데이터셋 사용
    • TimeStamp가 있는 나레이션 데이터셋 활용
  • Ego-Exo4D Benchmark
    • Ego-Exo4D 데이터셋 사용
    • 1인칭 + 3인칭 멀티뷰 영상 포함
• 평가 지표 
  • Language Model Perplexity (LL-PPL)
    • 값이 낮을수록 모델이 더 자연스럽고 정확한 문장 생성
  • Time Difference (TimeDiff)
    • 낮을수록 실제 상황과 모델 응답 간의 시간 차이가 적음
  • Fluency
    • 높을수록 스트리밍 상황에서 모델이 부드럽고 자연스러운 응답 생성
  • LM-Correctness
    • 문맥을 잘 반영하여 정답을 생성하는가
    • 높을수록 정확한 정보를 제공하는 능력이 뛰어남

LION-FS가 기존 모델 대비 향상된 성능을 보였습니다. Ego4D 에서는 TimeDiff가 다소 증가했지만 이는 응답 길이 차이 때문입니다.

3.1. Ablation Study

- Token Aggregation Router

SigLIP (일반적 인코더) 과 EgoVLPv2 (1인칭 인코더)를 비교해 어떤 융합방식이 더 효과적인지 실험했습니다. 

SigLIP 은 LL-PPL과 TimeDiff에서 우수했고 EgoVLPv2는 Fluency와 LM-Correctness에서 우수했습니다. 결국 하나의 인코더만 사용하면 특정 측면에서 성능이 떨어지기 때문에 두 개의 특징을 효과적으로 융합해야합니다.

- Token Dropping Router

Droppiing 전략이 모델 성능에 어떤 영향을 미치는지 실험한 결과입니다. Random Dropping은 성능이 크게 감소했고 Token Dropping을 Interleaved 교차 레이어로 적용했을 때 가장 효과적이었습니다. 

- Multi-granularity Augmentation

Grid & Box Token이 모델의 성능에 어떻게 영향을 끼치는지, KeyFrame에 추가적인 정보를 반영하면 응답 품질이 얼마나 개선되는지 실험했습니다. 

- Qualitative Analysis

(VideoLLM-Online)LIVE (Baseline) : "You repaired the bicycle by removing the screw and rotating the pedal."

LION-FS (Fast-Path) : "You repaired the bicycle by adjusting the screw on the bicycle"

LION-FS (Fast + Slow) : "You repaired the bicycle by tightening the screw with a screwdriver."

이전 방식은 잘못된 추론을 했고 Fast-Path는 정답은 맞췄지만 세부적은 설명 부족, 모두 적용 시 더 정밀한 응답 생성을 했습니다.

4. Conclusion & Limitations

LION-FS는 실시간 비디오 분석 속도를 개선했고 응답 정확도도 향상시켰습니다. 1인칭 시점에 최적화된 모델이기 때문에 응용 가능성이 높습니다. 

실시간 비디오 대화 모델은 EOS 토큰이 훨씬 더 자주 등장하기 때문에 모델이 응답하기 보단 침묵하는 경향이 강해져 결과적으로 모델이 너무 조용해질 수 있습니다. 즉, 모델이 EOS로 예측하는게 안전하다고 판단할 수 있습니다.

따라서 EOS를 단순히 예측하는 게 아니라, 다양한 응답 확률을 가진 Special Token을 추가해 응답 확률을 회귀로 학습하는 방법이 필요합니다. 즉, 단순한 EOS/응답 예측이 아닌 응답을 할 확률을 연속적인 값으로 예측하도록 설계해야합니다. 예를 들어, EOS / 간단한 응답 / 자세한 응답 / 긴급 응답  등 다중 클래스를 추가하거나, 이 프레임에서 응답할 확률이 몇 퍼센트인지 예측해 확률이 높으면 즉시 응답하고 낮으면 다음 프레임까지 대기, 더 낮으면 침묵하는 것으로 수준을 조절할 수 있습니다.

LION-FS 또한 KV Cache를 통해 Context를 저장합니다. 하지만 무한한 길이의 비디오를 처리하기엔 한계가 있어 Fixed-Length Memory Mechanism을 도입해 최근 정보를 우선 유지하면서 핵심적인 과거 정보도 함께 저장하는 방식으로 변경해야합니다. 

실시간 비디오 스트리밍에서 자연스러운 이해와 사용자와의 대화를 유지할 수 있는 온라인 Video LLM 논문입니다. 

1. Introduce

기존 Video LLM들은 사전 정의된 짧은 비디오 클립을 입력으로 학습되기 때문에 AR 글래스나 스마트 카메라에서는 즉각적인 반응이 필요하지만 기존 방식들은 이를 제대로 지원하지 못했습니다. 기존 Video LLMs의 한계는 다음과 같습니다.

- 이벤트 감지 부족

• 기존 Video LLMs는 정해진 비디오 클립을 분석하고 요약하는 방식
• 언제 이벤트가 발생하는지 같은 감지 기능이 없어 실시간 대응이 어려움

- 장기 컨텍스트 유지 어려움

• 실시간 비디오 스트리밍에서는 이전 대화 및 장면을 어느정도 기억해야함
• 하지만 LLM의 컨텍스트 윈도우 제한으로 장기적인 정보를 유지하는 것이 어려움

- 실시간 응답 지연 (Inference 속도)

• 기존 모델들은 한 프레임당 텍스트 응답을 너무 길게 생성
• 프레임마다 긴 내용을 생성하면 지연이 발생해 실시간 대응이 어려움

따라서 본 논문에서는 다음과 같이 LIVE (Learning-In-Video-strEam) 프레임워크를 제안했습니다.

- Streaming EOS (End-Of-Sequence) Predictin : 언제 말할까?

• 매 프레임마다 응답을 생성하려고 하는 기존 LLM은 비효율적
• 모델이 응답할지 말지 학습해, 필요할 때만 응답하도록 학습

- Streaming Dialogue Data Generation : 실시간 데이터로 변환

• 기존 비디오 데이터셋은 사전 녹화된 비디오에 대한 annotation이 포함됨
• 이를 실시간 대화형태로 변환해 스트리밍 비디오에서 자연스럽게 응답하도록 변환

- Optimized Inference Pipeline : 고속 추론

• Key-Value Caching 활용하여 이전 정보를 빠르게 검색
• Vision encoding과 Text encoding을 병렬화해 속도 최적화

본 논문은 결과적으로 5분짜리 비디오를 10FPS 이상 속도로 실시간 분석이 가능했으며 (A100 기준) Memory Cost 20GB 이하로 유지하여 장시간 비디오 스트리밍이 가능했습니다.

2. Method

2.1. Video Streaming Dialogue

기존 비디오 LLM은 정적인 비디오 클립을 대상으로 작동하며 실시간 비디오 스트리밍 환경에서의 상호작용이 부족합니다. 기존 비디오LLM 및 GPT-4V를 실시간 비디오 스트리밍 대화에 적용하려고 하면 다음과 같은 문제가 발생합니다.

- Interleaved Vision-Language Chatting

 일정한 시간 간격마다 프레임을 받아서 텍스트 생성

  - 불필요한 중복 발생 : 프레임 간 큰 변화가 없는 경우에도 같은 내용 반복 생성

  - 지속적인 프레임 처리로 연산 증가

  - 수동으로 타임스탬프 설정 필요

- Per-Frame Chatting

 각 프레임 마다 개별적인 언어 모델 수행

  - 매 프레임마다 생성으로 속도 지연

  - 프레임 스키핑 문제 발생

  - GPU 메모리 부담 증가

2.1.1. Streaming EOS Prediction 

기존 방식처럼 매 프레임마다 긴 텍스트를 생성하지 않으면서 언제 응답해야 하는지 (EOS : End Of Sequence)를 예측하는 방식으로 최적화하여 필요할 때만 응답하고, 불필요한 응답을 줄이는 방법을 소개합니다.

- 기존 방식처럼 모든 프레임에서 언어 모델링을 수행하는 대신, 특정 타임스탬프 t_2에 도달했을 때 텍스트 응답을 생성할지 여부를 판단하고, (t_1 <= t < t_2 동안 불필요한 turn 추가 X) 만약 응답할 필요가 없다면 EOS 토큰을 출력하고 다음 프레임으로 이동하는 방법입니다.

이전 context와 현재 프레임을 고려해 t_2 시점에서 적절한 텍스트를 생성하는 확률을 최적화하는 것이 목표입니다.

즉, 지금 텍스트를 생성할 타이밍이 맞다고 판단되면 텍스트를 생성합니다.

다음 수식은 해당 프레임에서 응답이 필요하지 않다면 EOS를 출력하고 다음 프레임으로 이동하는 수식입니다. 

2.2. Data

기존 오프라인 데이터셋을 실시간 스트리밍 대화 형식으로 변환하는 방법을 설명합니다. 즉, 기존의 offline annotation이 달린 비디오 데이터를 활용해 online 대화 데이터셋을 구축하는 과정입니다.

일부 비디오 데이터셋 (Ego4D Narrations)은 원래부터 스트리밍 방식으로 수집되어 (인간 주석자가 5분짜리 비디오를 보면서 실시간으로 설명을 추가하는 방식) 이러한 데이터를 활용해 모델을 학습시키는 건 가능합니다.

하지만 대부분의 비디오 데이터셋은 offline 방식으로 수집되어 30~60초짜리 짧은 클립을 대상으로 annotation을 달아 학습하는 방식이기 때문에 실시간 스트리밍 문맥에서 활용하려면 변환 과정이 필요했습니다.

따라서 비디오에서 과거, 현재, 미래에 대해 질문할 수 있도록 템플릿을 생성하고 각 50개씩 총 150개의 Query를 준비합니다. 

기존 offline 데이터셋에는 타임스탬프별 비디오 annotation 이 존재하는데 이는 다음과 같습니다.

- t1-t2 : 물을 끓이고 있다.

- t3-t4 : 야채를 썰고 있다.

이러한 상태 변화가 일어나는 시간 t1-t4를 응답을 생성한 이상적인 타이밍으로 설정하고 

각 타임스탬프 t1-t4 에서 LLM에 질문을 던지고 그에 대한 답변을 저장하는 것을 반복해 질문과 답변을 포함하는 학습 데이터를 구축합니다. 

또한 더욱 자연스러운 학습데이터를 구축하기 위해, 랜덤 타임스탬프에 질문을 삽입해, 새로운 질문이 추가되면 이전 질문 이후의 응답을 무효화해 자연스러운 대화 흐름을 유지시킵니다.

본 연구에는 Ego4D Narrations, COIN, Ego4D GoalStep 데이터셋을 사용했습니다.  

3. Model Training

3.1 Model Architecture

모델 아키텍처는 Image Encoder, MLP Projector, Language Model 로 총 세 가지 요소로 구성되어있습니다.

3.1.1. Image Encoder

CLIP ViT-L(DataComp1B로 사전학습)을 사용합니다. 

비디오 프레임을 2FPS로 샘플링하여 임베딩을 생성하고 각 프레임의 임베딩 크기는 다음과 같습니다.

(1+h_p * w_p) : CLS 토큰 + 공간 토큰

c : 차원 수 (임베딩 차원)

실험에서는 h_p = w_p = 0으로 설정해 긴 비디오를 처리하도록 최적화하였으나 데모 모델은 3(10개 토큰)으로 사용해 더 정밀하지만 짧은 비디오만 지원됩니다.

따라서 비디오 프레임을 CLIP ViT-L을 통해 벡터화하고 이 정보를 활용해 LLM이 대화를 생성합니다.

3.1.2. MLP Projector

이미지 인코더에서 생성된 프레임 임베딩을 MLP Projector 에서 프레임 토큰으로 변환합니다. 본 연구에선 LLaVA-1.5와 동일한 방식을 적용했습니다. 

CLIP의 출력값을 LLM이 이해할 수 있게 프레임 토큰과 언어 토큰을 결합해 형식을 변환합니다.

3.1.3. Language Model

LLaMA-2-7B-Chat / LLaMA-3-8B-Instruct 를 사용합니다. LoRA를적용해 파라미터를 효율적으로 튜닝을 했습니다. 이전에서 프레임 토큰 + 언어 토큰을 입력으로 받아 대화를 생성합니다.

3.2 Training Loss

LIVE 프레임워크는 두 가지 손실 함수를 사용하여 학습됩니다.

3.2.1. LM Loss

LLM이 입력된 텍스트 시퀀스를 기반으로 적절한 다음 단어를 생성하도록 학습합니다.

LLM이 j번째 토큰을 보고 다음 텍스트 토큰 Txt_j+1을 예측하는 확률

3.2.2. Streaming EOS Prediction Loss

모델이 불필요한 순간에는 침묵하고 적절한 순간에만 응답하도록 학습합니다.

j번째 토큰에서 EOS 토큰을 예측할 확률, 이 확률이 높아질 수록 모델은 지금 말할 타이밍이 아니다 라고 판단하고 침묵

4. Inference

Inference 과정에서는 실시간 속도를 최적화하기 위해 Key-Value Caching, EOS 확률 보정, 병렬 처리 등의 기법이 적용됩니다.

4.1. EOS Probability Correction

LIVE 프레임워크에서는 모델이 불필요할 경우엔 침묵하도록 학습됩니다. 하지만 학습 중에 EOS 토큰이 너무 자주 등장하면 모델이 과도하게 침묵하게 될 수 있어, 이를 방지하기 위해 EOS 예측 확률이 특정 임계값 이하일 경우 EOS를 무시하도록 설정합니다.

특정 프레임 j에 대해서 EOS 토큰의 확률이 상기 확률일 때, EOS를 무시합니다. 본 연구에서는 theta값이 0.5-0.8일 때 최적 성능을 나타냈습니다.

4.2. Continuous Key-Value Cache

LLM은 토큰을 생성할 때 이전 Context를 계속 유지해야합니다. 일반적으로 LLM은 입력된 문장을 처음부터 다시 계산해야하지만 Key-Value Cache를 사용하면 이미 계산된 부분을 저장해둬서 속도를 높일 수 있습니다. 즉, 과거 정보를 저장해두고, 새로운 입력이 들어오면 그 부분만 추가로 처리해서 계산량을 줄이는 방식입니다. (본 연구에서는 2FPS로 들어오는 비디오 프레임을 입력받고 바로 토큰을 생성합니다.)

4.3. Parallelization of encoding and decoding (비디오 인코딩과 언어모델 디코딩 병렬 처리)

영상 인코더 CLIP ViT-L (307M)은 상대적으로 빠르고 언어 디코더 LLaMA는 상대적으로 느리기 때문에 만약 LLM이 긴 문장을 생성하면 비디오 프레임이 들어오는 속도보다 디코딩 속도가 느려질 수 있어 프레임이 스킵될 수 있습니다.

따라서 FIFO 큐를 활용해 프레임을 먼저 인코딩하고 언어 모델이 여유가 있을 때 가져가도록 처리하는데, 즉 비디오 프레임 인코더는 항상 동작하며 프레임을 인코딩하고 저장한 뒤, 언어모델은 이전 프레임 처리를 마치는 즉시 저장된 프레임을 가져가서 처리합니다.

5. Experiments

5.1. Implementation Details

본 연구에서는 두 가지 버전의 VideoLLM-online을 구현했습니다. 각 버전은 효율성, 성능에 따라 구현 방법이 다릅니다.

5.1.1. VideoLLM-online-7B-v1 (효율성)

• 비디오 프레임 인코더 : OpenCLIP-ViT-L-224
• MLP : 2-layer MLP
• LLM : LLaMA-2-7B-Chat
• 토큰 사용량 : 각 비디오 프레임당 CLS 토큰 한개만 사용 (최소한의 메모리)

5.1.2. VideoLLM-online-8B-v1+ (성능)

• 비디오 프레임 인코더 : SigLIP-ViT-L-384
• MLP : 2-layer MLP
• LLM : LLaMA-3-8B-Instruct
• 토큰 사용량 : CLS 토큰 1개 + 추가적인 공간 토큰 (3 x 3 average pooling) , 총 10개 토큰/프레임 사용

기본 실험 환경은 다음과 같습니다.

• VideoLLM-online-7B-v1을 기본 모델로 사용
• 2 FPS로 샘플링된 비디오를 학습 데이터로 사용
• 학습 시 모든 Linear Layers에 LoRA 적용 (rank=128, scaling factor=256)
• Vision-Language 정렬 없이 바로 학습
• MLP는 LLaVA-1.5를 사용하지 않고 랜덤 초기화

학습 Epoch 설정은 다음과 같습니다.

• 비디오 스트리밍 대화모델 (Online) : 2 Epochs 학습
• 비디오 이해 관련 오프라인 실험(Offline) : 5~6 Epochs 학습
• 스트리밍 학습 시 EOS Loss 가중치 w = 1.0으로 설정

5.2. Evaluation Setting

VideoLLM-online 모델이 어떻게 평가되었는지 사용된 데이터셋과 평가지표를 설명합니다.

5.2.1. Dataset 및 평가 설정 (COIN, Ego4D Dataset)

• Ego4D Narration Stream
  
  • Ego4D 데이터셋에서 주어진 timestamp-narration 데이터 활용해 실시간 나레이션 생성 능력 평가
  • 모델이 Ego4D의 인간 어노테이터처럼 적절한 시점에 행동을 평가할 수 있는지 평가
• COIN + Ego4D Narration Stream
  • COIN 데이터셋의 행동 단계를 Ego4D 스타일 나레이션으로 변환하여 추가 학습
  • 모델이 행동이 시작할 때 알려주고, 끝날 때 요약하며, 다음 행동을 예측하는 능력 평가
• Ego4D GoalStep + Narration Stream
  • 목표 지향적 작업을 수행할 때, 모델이 얼마나 잘 대응하는지 평가
• COIN Benchmarks
  • Step Recognition (행동 단계 인식)
  • Step Forecasting (다음 행동 예측)
  • Task Summarization (작업 요약)
  • Procedure Forecasting (절차 예측)
  • Goal-based Procedure Forecasting (목표 기반 절차 예측)
• Ego4D Long-Term Action Anticipation (LTA) Benchmarks
  • 주어진 과거 8단계의 행동을 바탕으로, 향후 20개의 행동(동사+명사 조합)을 예측하는 능력 평가
  • 비디오 기반 AI 어시스턴트가 미래 행동을 예측할 수 있는지 테스트

5.2.2. Evaluation Metrics (평가 지표)

본 연구는 비디오를 보면서 실시간으로 나레이션을 생성하는 AI 어시스턴트 역할을 수행해야 합니다.

• 언어 모델 성능 평가
  • LM-PPL (Language Model Perplexity)
    • 언어 모델이 특정 시점에서 얼마나 정확하게 답변을 생성했는지 평가
    • LM-PPL 값이 낮을수록 모델이 더 정확한 답변을 생성
    • 서로 다른 LLM 비교 시에는 토큰화 방식 차이로 직접 비교 X
  • LG-Match (Language Generation Matching Ratio)
    • 7B 모델과 8B 모델을 비교
    • 정답과 비교해, 처음으로 틀린 토큰이 나오기 전까지의 일치율을 측정
    • 얼마나 모델이 정확하게 나레이션을 수행했는지 평가
• 시간 정렬 평가
  • TimeDiff
    • 모델의 응답 시점과 실제 행동이 발생한 시점간의 차이
    • 적을 수록 더 실시간 나레이션 수행
  • Fluency
    • 한 대화(turn)에서 연속적으로 성공한 토큰의 비율을 측정
    • 언어 모델의 정확성과 시간 정렬 성능을 종합적으로 평가

5.2.3. Baseline 모델 

본 논문 발표 전까지 실시간 비디오 스트리밍에 맞춰 자유로운 자연어 응답을 생성하는 모델이 없어 저자는 자체적으로 Baseline 모델을 구축해 비교 실험을 수행했습니다.

• Video-Text Interleaved Dialogue (비디오 텍스트 대화 모델)
  • 기존 LLM과 비디오를 조합해 한 프레임씩 대화하는 방식
• Per-Frame Dialogue (프레임 별 대화 모델)
  • 매 프레임마다 개별적으로 응답하는 방식

5.3. Ablation Study

본 연구의 Streaming Dialogue 는 언어 모델의 loss 증가 없이도 학습이 가능했으며, Per-Frame 방식은 너무 많은 EOS 토큰을 예측하기 때문에 LM-PPL 값이 증가되었습니다. 또한 TimeDiff, Fluency 에서도 좋은 성능을 보였습니다. 

어떤 손실 함수가 스트리밍 학습에서 가장 적합한지 테스트를 했습니다. 기본설정인 Cross Entropy(CE) Loss, τ = 1.0 에서 가장 안정적인 성능을 보였습니다. 복잡한 손실 함수 추가없이 기본 CE Loss만으로도 충분히 학습 가능했습니다.

어떤 방식이 실시간 스트리밍에서 가장 빠르고 메모리 효율적인지 비교합니다. Ego4D 나레이션 스트림 테스트 (5분짜리 비디오)를 진행했고 A100에서 평가를 진행했습니다.

5.4. Results

COIN 데이터셋에서 작업 요약 및 다음 단계 예측에서 SOTA를 달성했습니다. 즉 비디오의 내용을 이해하고 절차적인 흐름을 예측하는 성능이 높았습니다.

Ego4D LTA 벤치마크에서도 높은 성능을 보였습니다. 

실시간 나레이션 성능 비교에서는 본 연구의 세 가지 모델을 비교하였습니다. 8B 모델을 사용하면 실시간 성능이 향상됩니다. 

6. Conclusion

본 연구는 특정 벤치마크 (COIN, Ego4D 등)에 최적화되어, 일반화 모델을 개발할 계획입니다. 특히 Zero-Shot 성능 향상을 목표로 하고있습니다. 추가적으로 현재는 속도를 유지하기 위해 프레임당 적은 토큰을 사용했으나 향후에는 더 많은 공간 토큰을 활용해 성능 및 속도 최적화를 진행할 예정입니다.

Emotion LLaMA 이후로 2025년에 나온 MLLM 감정 탐지 논문입니다. 기존 비디오 기반 MLLM의 한계인 오디오 통합과 Micro expressions recog 를 해결했고 새로운 감정 데이터셋을 구축한 논문입니다.

1. Introduce

- 멀티모달 감정 분석

기존 멀티모달 감정 분석 연구들은 주로 feature 융합 또는 모달리티 보완에만 집중해 왔습니다. 이 방법들은 감정을 논리적으로 reasoning하는 능력이 부족합니다. 또한 기존 Emotion LLaMA, AffectGPT, EmoLLM 등의 모델들은 범용적인 Vision 인코더와 Audio 인코더를 LLM에 결합하는 방법을 사용했고, Facial Expression 분석 모델이 포함되지 않아 미세한 감정 표현을 인식하기 어렵습니다. 그리고 감정을 표현하는 문화적 차이 등의 라벨링 기준이 모호해 MLLM이 제대로 감정을 학습하기 어려웠기 때문에 본 논문에서는 감정 데이터셋을 새로이 제작했습니다.

- 새로운 감정 데이터셋 구축

Self-Reviewed Emotion (SRE) Dataset : 24,137개의 데이터셋 (GPT로 검증)

Human-Reviewed Emotion (HRE) Dataset : 3,500개의 수작업 데이터셋

데이터 생성 과정

1. 기존 감정 데이터셋에서 비디오 클립을 수집합니다.

2. 일반적인 비디오 MLLM(Qwen-VL)을 사용해 비디오 내 시각적 정보(사람, 배경)를 자동 설명합니다.

3. 얼굴 감정 분석을 위해 Face Tracklet을 추출합니다.

4. 나이, 성별 예측 모델을 사용해 얼굴 정보를 보강합니다.

5. 오디오 모델(Whisper-large-v3)로 음성 데이터를 분석해 감정적 단서를 추출합니다.

6. GPT-3.5를 사용해 설명의 일관성을 체크하고 부정확한 설명을 제거합니다.

7. 최종적으로 감정 reasoning 및 감정 annotation을 생성합니다.

- 모델 아키텍처

기존 Video MLLM에 Face + Audio 모델을 추가해 감정 분석 성능을 향상시켰습니다.

기존 Video MLLM으로 Scene 및 Context를 분석하고 Audio Encoder로 음성 데이터에서 감정적 단서를 추출합니다. 그 이후 Face Encoder로 얼굴에서 미세한 감정 변화를 감지한 뒤, Audio + Face + Video 세가지 인코더를 MLLM 임베딩 공간에 정렬해 감정 분석을 수행합니다.

2. Method

- Whisper 기반 Audio Modality

기존 모델의 문제점인 음성 억양, 강도, 리듬을 무시하는 경우를 해결하기 위해 본 논문에서는 Whisper-large-v3를 사용해 감정정보를 디테일하게 학습합니다.

1. Whisper-large-v3을 사용해 오디오를 텍스트로 변환(ASR) + 감정적 특징을 추출

2. 오디오 데이터를 16kHz로 리샘플링 : 원본 오디오 데이터를 16kHz 샘플링 속도로 변환

3. 128 채널 Mel-Spectrogram 변환 : 오디오를 128 채널의 Mel-Spectrogram으로 변환 (윈도우 크기: 25ms, hop size: 10ms)

4. Pooling Layer 적용 : 3-Stride 풀링을 사용하여 토큰 길이를 줄이고, 최종적으로 60ms 단위의 오디오 토큰 생성

5. Audio Projector 적용 : 두 개의 선형(Linear) 레이어를 사용하여 오디오 특징을 LLM의 임베딩 크기와 맞춤

- FaceXFormer 기반 Facil Modeling

기존 Video MLLM들은 일반적인 비전 인코더(CLIP, SigLip 등)을 사용하는데 이는 배경, 사물의 정보도 함께 학습하여 감정 분석에 최적화되지 않았습니다.

1. 얼굴 감정을 학습하는 전용 Transformer 기반 인코더인 FaceXFormer를 사용

2. Face Detector & Tracking : 얼굴을 검출하고, 영상 내에서 지속적으로 추적

3. Multi-Scale Feature Extraction : 얼굴 특징을 다양한 스케일에서 추출

4. MLP-Fusion Module : 다중 스케일에서 추출된 얼굴 특징을 융합

5. Facial Projector : 두 개의 선형(Linear) 레이어를 사용하여 얼굴 특징을 LLM 임베딩 크기와 맞춤

- 멀티모달 융합

기존 감정 분석 모델들은 face, video, audio 정보를 개별적으로 처리했으나 본 논문에서는 Visual Feature Fusion Module을 사용해 얼굴과 일반적인 시각 정보(배경, 장면 등)을 융합했습니다.

얼굴 특징을 Query로, 비주얼 특징을 Key, Value로 설정해 attention 메커니즘을 적용했습니다.

결과적으로 최종 LLM에 입력되는 데이터는 다음과 같습니다.

- Whisper 통해서 추출한 음성 특징인 Audio Token

- CLIP 기반 비주얼 특징 + FaceXFormer의 융합인 Visual Token

- GPT-3.5가 생성한 감정 설명인 Text Token 

3. Experiments

4. Limitations

real-world에서 발생하는 데이터셋이 부족하며, 사용자들이 전면 카메라를 사용해 데이터를 촬영해 real-world의 성능이 부족할 수 있습니다.

또한, Mixed Emotions 분석 정확도가 낮습니다. 인간의 감정은 한가지 감정만 존재하는 것이 아니라, 여러 감정이 동시에 섞여 있어 Mixed Emotions의 정확도가 부족합니다. 

다양한 인코더들을 포함했기 때문에 모델의 크기가 너무 커져, 계산량이 증가하여 실제 배포가 어려울 수 있으며, Token Length Limit도 존재해 긴 비디오를 처리하는 데 어려움이 있습니다.

VLM 관련 논문을 보다가, LLaMA를 통해 감정을 캡셔닝하는 논문이 있어 리뷰합니다. 2024년 NeurIPS에 올라온 논문입니다. Emotion LLaMA는 MLLM을 대체할 MERR 데이터셋을 구축하고 instruction tuning을 통해 감정 추론을 강화한 논문입니다.

1. Introduce

- 멀티 모달리티

단일 모달리티에서 (얼굴 표정, 텍스트 기반, 오디오 감정 등)은 효과적이지만, 현실 세계의 복잡한 감정을 포착하기엔 한계가 있습니다. (실제 감정은 텍스트, 오디오, 이미지 등등 여러 멀티 모달리티가 결합되기 때문에)

- MERR 데이터셋

MLLM(멀티 모달 대형 언어 모델)은 오디오 처리가 어렵고, 미세한 표정 인식이 어려워 감정 인식에 어려움이 있습니다. 이를 해결하기 위해서 본 논문에선 MERR 데이터셋을 구축하여 해결했습니다. 다양한 시나리오에서 학습할 수 있도록 28,618개의 coarse grain과 4,487개의 fine grain으로 구성되어 있습니다.

- Emotion-LLaMA 모델

HuBERT를 사용해 오디오 신호를 처리하고, MAE, VideoMAE, EVA 로 얼굴의 세부 정보, 역동성, 맥락을 캡처합니다. 이 모든 정보를 튜닝된 LLaMA에 정렬해 감정을 인식합니다.

2. Method

Emotion-LLaMA는 세가지 주요 구성 요소로 이뤄져 있습니다.

1. MERR 데이터셋 구축

2. Emotion-LLaMA 멀티 모달 모델 구조

3. 훈련 과정

2.1. MERR 데이터셋 구축

MERR 데이터셋은 감정 annotation을 비디오 데이터에 추가하는 과정을 통해 구축됩니다. 

2.1.1 얼굴 추출 및 Action Units(AU) 감지

각 비디오 프레임에서 OpenFace로 얼굴을 추출하고 AU 강도를 감지하는데, 특정 프레임에서 AU 강도가 가장 높은 순간을 찾기 위해 다음과 같은 공식을 사용합니다. AU는 얼굴 움직임을 표현하는 Cved(표정 설명)으로 매핑됩니다.

2.1.2 컨텍스트 정보 추출

MiniGPT-v2를 통해 최대 강도의 Peak 프레임을 분석하여 활동, 주변환경 등과 같은 Cvod(시각적 맥락 정보)를 추출합니다. 이러한 시각적 맥락 정보는 배경에서 나타나는 감정 요소 식별에 도움을 줍니다.

2.1.3. 오디오 정보 추출

Qwen-Audio 모델을 사용해 음성 세그먼트를 처리하고 음성 톤 및 억양에서 감정과 관련된 정보를 Catd로 생성합니다.

2.1.4. 멀티 모달 설명 통합

시각 정보 (Cved, Cvod), 오디오 정보(Catd), 자막 정보 (Cls)를 하나로 결합하여 Raw Multimodal Description을 생성합니다. 이를 통해 더욱 풍부한 맥락을 제공할 수 있습니다.

2.1.5. 멀티 모달 Description (Cmd)생성

단일 모달 Description인 Cved, Cvod, Catd, Cls를 종합해 Cmd를 생성하고 최대 강도 프레임에 대해 상세한 감정 Description을 생성합니다.

2.2. Emotion-LLaMA 멀티 모달 모델 구조

Emotion-LLaMA의 입력 튜플은 다음과 같습니다. 

그리고, Emotion-LLaMA의 수식은 다음과 같습니다.

ϕ : LLaMA 언어 모델

Ω : Vision Preprocessor

E : 멀티 모달 인코더

2.2.1. 멀티 모달 프롬프트 템플릿

Emotion-LLaMA는 비디오 특징, 오디오 특징, 작업 식별자, 텍스트 프롬프트를 포함하는 프롬프트 템플릿을 사용합니다.

<VideoFeature><AudioFeature>[Task Identifier]Prompt

2.2.2. 멀티뷰 멀티모달 인코더

2.2.2.1. 오디오 인코더 Eaud

HuBERT 모델을 사용해 입력 오디오 신호로부터 포괄적인 오디오 표현 uaud를 추출하고 이는 억양 및 톤에서 감정 단서를 감지할 수 있습니다.

2.2.2.2. 비주얼 인코더 Evis

비주얼 인코더를 세가지로 구성되며, 서로 다른 시각적 감정 특징을 보완적으로 추출합니다.

로컬 인코더 : ViT 기반 모델 (MAE 사전 학습) 으로 정적 얼굴 표정 특징을 추출합니다. 

얼굴 시퀀스를 입력으로 받아 각 프레임의 특징을 평균 풀링하여 로컬 시각적 특징을 생성합니다.

Temporal 인코더 : VideoMAE 모델로 얼굴 시퀀스의 시간적 특징을 학습해 감정 상태를 나타내는 동적 정보를 제공합니다.

글로벌 인코더 : EVA 모델을 사용해 얼굴 표정뿐만 아니라 배경 콘텍스트까지 포함하는 시각적 특징을 추출합니다.

2.2.3. 멀티 모달 통합 및 Tokenization

Emotion-LLaMA는 LLaMA의 BPE(Byte-Pair Encoding) Tokenizer를 사용해 텍스트 입력을 효율적으로 처리합니다. 오디오 및 시각적 특징을 텍스트 Token과 통합하기 위해 선형 투영 메커니즘(Linear Projection Layer)을 사용합니다.

2.3. 훈련 과정

2.3.1. Pretraining

MERR 데이터셋의 coarse-grained 샘플 (28,618개)을 사용해 모델을 사전 학습합니다. 다양한 작업을 통해 멀티 모달 특징 토큰이 언어 임베딩 공간에 빠르게 정렬되도록 돕습니다.

2.3.2. 멀티모달 Instruction Tuning

Pretrained Emotion-LLaMA를 기반으로 MERR 데이터셋의 4,487개의 fine-grained 샘플을 사용해 모델을 튜닝합니다. 이 단계에서는 복잡한 감정 상태에 대한 정밀한 묘사 및 레이블링을 학습하는데, MER2023, DFEW 등 추가적인 데이터셋도 포함해 확장합니다.

1. apt 업데이트 

sudo apt update

2. curl 패키지 설치

sudo apt install curl -y

3.  Anconda 설치

버전 참고 사이트 : https://repo.anaconda.com/archive/

curl --output anaconda.sh https://repo.anaconda.com/archive/Anaconda3-2024.10-1-Linux-x86_64.sh

sha256sum anaconda.sh

bash anaconda.sh

4. conda  환경변수 추가

sudo vi ~/.bashrc

 * vi 가 없다면?

sudo apt install vim

마지막 줄에 입력 후 :wq 로 저장

export PATH=~/anaconda3/bin:~/anaconda3/condabin:$PATH

환경변수 업데이트

source ~/.bashrc 

5. conda 버전 확인

conda -V 

6. conda 가상환경 설정 (가상 환경 이름 : py_312 / python 버전 : 3.12)

conda create -n py_312 python=3.12

7. 생성한 conda 가상 환경 실행

conda activate python_3

*** 'conda init'. 과 같은 에러가 난다면 profile 변경 값을 conda shell script 파일에 적용

source ~/anaconda3/etc/profile.d/conda.sh

딥러닝 학습은 시간을 많이 소요하기 때문에 로컬 PC가 꺼져도 세션은 계속 작동되어야 함.

1. Tmux 설치

apt-get install tmux

2. Tmux 실행

tmux

3. 새로운 세션 실행

tmux new -s [SESSION NAME]

4. 세션 중 나가기(종료 아님) / 종료는 세션 내에서 exit

Ctrl + b 누른 뒤, d 누르기

5. 실행 중인 세션 확인하기

tmux ls

6. 세션 다시 연결하기

tmux attach-session -t [SESSION NAME]

Container는 무제한으로 HOST의 리소스를 사용하기 때문에, 각 컨테이너마다 리소스 제한이 필요할 때가 있음

1. Container CPU 사용 수 제한 (host에 CPU가 여러 개 있는 경우)

docker run -itd --name [컨테이너이름] --hostname [생성할 호스트이름] --gpus '"device=0,1,2"' --cpuset-cpus=”0,1” nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04

2. Container CPU 사용량 제한 (기준 사용량 1(1024)을 기준으로 2024는 기본값보다 2배 사용한다)

docker run -itd --name [컨테이너이름] --hostname [생성할 호스트이름] --gpus '"device=0,1,2"' --cpu-shares 512 nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04

3. Container CPU 사용량 제한 (전체 사용량 1을 기준으로)

$ docker run -itd --name [컨테이너이름] --hostname [생성할 호스트이름] --gpus '"device=0,1,2"' --cpus=0.2  nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04

4. Container 최대 메모리 제한

docker run -itd --name [컨테이너이름] --hostname [생성할 호스트이름] --gpus '"device=0,1,2"' -m 16g  nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04

5. Containers 리소스 사용량 확인

docker stats

도커에서 컨테이너를 구축하기 전에 먼저 Image를 생성해야합니다. 삭제 방법도 아래에 적어드리겠습니다.

1. 도커 Image

1. Image 생성

(Repository 참고자료: https://gitlab.com/nvidia/container-images/cuda/blob/master/doc/supported-tags.md)

예시 : CUDA 12.1.1 / CUDNN8.9.4 (cudnn8 = 8 내에서의 lastest로 맞춰주는 듯) / UBUNTU 22.04

docker pull nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04

2. 설치된 Docker images 확인

docker images

3. 설치된 image 삭제 (호스트의 용량 관리를 위해)

docker rmi [image id]

2. 도커 Container 

1. Container 생성 / 실행 (아직 접근 X)

*--gpus ‘“device=0,1,2”’ : 0,1,2 번의 gpu를 사용하겠다.

*nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04 : 이미지 태그명

*-i : 표준입력 활성화 / -t : bash 사용을 위해

*-d : Container 백그라운드로 실행 (제외하면, 해당 Container에서 나가면 Container가 꺼짐)

docker run -itd --name [컨테이너이름] --hostname [생성할 호스트이름] --gpus '"device=0,1,2"' nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04

2. 실행된 Container 확인

docker ps

3. 모든 Container 확인

docker ps -a

4. Container 접근

docker exec -it [컨테이너이름] bash

5. Container 삭제 (Container 중지가 우선 / $ docker stop [컨테이너ID or 이름])

docker rm [컨테이너ID or 이름]

Container에서 GPU를 사용하기 위해서는 NVIDIA Docker를 설치해야 합니다.

1. NVIDIA-Docker GPG 및 저장소 추가

distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
  && curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - \
   && curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list

2. NVIDIA-Docker 설치

sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit

3. Docker 재실행

sudo systemctl restart docker