DEVOCEAN

총 5,520억 개 파라미터를 가진 거대 모델이 텍스트와 이미지를 읽는 데 단 80억 개, 답을 적는 데 160억 개의 파라미터만 깨웁니다. 전체 가중치 중 입력 단계에서는 약 1.4%, 출력 단계에서는 약 2.9%만 활성화하는 셈입니다.

거대 언어 모델과 영상 데이터를 실무 파이프라인에 결합할 때 마주치는 장벽은 모델의 이해 능력 부족이 아니라 비용과 추론 지연 시간(Latency)입니다. 고해상도 이미지와 긴 영상 프레임을 그대로 모델 컨텍스트에 쏟아붓다 보면 GPU 메모리가 고갈되거나 토큰 비용이 급증합니다. DeepSeek V4.1 Flash와 AWS MediaConvert 기반 VOD 챕터 생성 파이프라인은 이 문제를 서로 다른 계층에서 해결합니다. DeepSeek은 모델 아키텍처 내부에서 활성화 파라미터를 비대칭으로 쪼개 계산 비용을 덜어내고, AWS 파이프라인은 모델 바깥의 인코딩 계층에서 영상을 구간별 메타데이터로 먼저 정제하여 모델이 삼켜야 할 데이터 양 자체를 통제합니다. 멀티모달 인프라를 설계할 때 계산 비용을 어떻게 통제해야 하는지 두 사례를 통해 살펴봅니다.

DeepSeek V4.1 Flash가 비대칭 MoE를 택한 이유

DeepSeek이 공개한 DeepSeek V4.1 Flash는 회사 최초로 Causal Encoder-Decoder(인과적 인코더-디코더, 이하 CED) 아키텍처를 도입한 희소 MoE(Mixture of Experts, 입력 데이터에 따라 필요한 전문 신경망 모듈만 골라 활성화하는 구조) 모델입니다. 이 모델의 핵심 특징은 사전 학습 초기 단계부터 시각 및 텍스트 임베딩을 분리하지 않고 함께 학습했다는 점과, 극단적인 비대칭 희소 구조를 취했다는 점입니다.

원문 수치에 따르면 DeepSeek V4.1 Flash의 총 파라미터는 5,520억 개(552B)에 달합니다. 그러나 추론 시점의 활성화 파라미터(Active Parameters)는 입력 처리(프롬프트 인코딩) 시 단 80억 개(8B), 출력 생성(토큰 디코딩) 시 160억 개(16B)로 제한됩니다.

[입력 데이터 (텍스트 + 네이티브 이미지)]
       │
       ▼
┌────────────────────────────────────────────────────────┐
│  인코더 단계 (CED 아키텍처)                            │
│  총 5,520억 개 파라미터 중 80억 개(8B)만 활성화        │
└────────────────────────────────────────────────────────┘
       │
       ▼
┌────────────────────────────────────────────────────────┐
│  디코더 생성 단계                                      │
│  총 5,520억 개 파라미터 중 160억 개(16B)만 활성화      │
└────────────────────────────────────────────────────────┘
       │
       ▼
[최종 응답 텍스트 / 메타데이터]

기존의 밀집(Dense) 모델이나 일반적인 대칭형 MoE 모델은 긴 멀티모달 입력이 들어올 때 인코더와 디코더 모두에서 막대한 연산량을 소모합니다. 특히 고해상도 이미지가 패치 단위의 비전 토큰으로 쪼개져 수천 개 단위로 유입되면 프롬프트 처리 단계(Time to First Token, TTFT)에서 극심한 연산 병목이 발생합니다.

여기부터는 DEVOTEE의 해석입니다. DeepSeek이 입력 단계 활성화 파라미터를 80억 개 수준으로 억제한 것은 이미지 패치 토큰의 대량 유입으로 인한 1차 연산 병목을 차단하기 위한 결정입니다. 텍스트와 이미지를 네이티브로 결합해 학습했기 때문에 외부 비전 인코더(예: CLIP 계열)를 거쳐 프로젝션 레이어로 전달하는 오버헤드가 없으며, CED 구조를 통해 인코더는 입력 표현을 빠르게 요약하고 디코더는 상대적으로 넉넉한 160억 개 용량으로 논리적 완결성을 가진 텍스트를 생성하도록 역할을 명확히 갈랐습니다.

이 구조에 대한 판단은 조건부로 유효하다입니다. 서비스 호출 관점에서는 초당 처리량(Throughput)이 크게 향상되고 API 비용이 줄어드는 장점이 명확합니다. 하지만 자체 사내 인프라(On-Premise)나 프라이빗 클라우드에 직접 올려 서빙하려는 팀에는 제약이 따릅니다. 활성화 파라미터가 8B/16B 수준이라 해도, 라우팅을 위해 5,520억 개 가중치 전체를 VRAM(GPU 메모리)에 올려두어야 합니다. 모델 가중치를 FP8이나 INT4로 양자화하더라도 최소 수백 기가바이트의 고대역폭 메모리가 필요하므로, 자체 인프라 호스팅 팀보다는 매니지드 API나 서빙 플랫폼을 사용하는 환경에서 유효합니다.

영상을 모델에 쏟아붓지 않고 챕터로 바꾸는 미디어 선별 계층

모델 내부의 활성화 가중치를 줄이는 것만으로는 긴 미디어 데이터를 다룰 때의 비용 문제를 완전히 해결할 수 없습니다. 10분이 넘는 긴 VOD(주문형 비디오) 영상을 처리할 때 가장 비효율적인 접근은 수 기가바이트에 달하는 영상 파일 원본을 그대로 멀티모달 모델에 넘기는 방식입니다.

AWS Elemental MediaConvert와 Amazon Bedrock을 활용한 VOD 자동 챕터 생성 파이프라인은 모델 앞단에 전용 미디어 처리 계층을 두어 토큰 비용을 구조적으로 통제하는 방식을 보여줍니다. 10분이 넘는 영상에서 사용자가 프로그레스바를 더듬거리며 특정 장면을 찾지 않도록, 영상 속 구간별 제목과 요약을 생성해 구간 단위 검색과 메타데이터 색인을 가능하게 만드는 것이 목적입니다.

원문이 제시하는 처리 흐름은 명확합니다. AWS Elemental MediaConvert(클라우드 기반 미디어 트랜스코딩 서비스)를 사용해 원본 영상에서 시각 프레임과 오디오 트랙을 가공 가능한 최소 단위로 추출합니다. 즉, 전체 비디오 스트림을 토큰화하는 대신, 장면 전환 감지(Scene Detection)를 통해 대표 프레임 썸네일을 이미지로 추출하고 음성 트랙은 텍스트(STT)로 변환하거나 구간별 오디오 청크로 분리합니다.

이후 정제된 메타데이터와 대표 구간 정보만을 Amazon Bedrock을 통해 LLM(대형 언어 모델)에 전달합니다. LLM은 원본 동영상의 무수한 픽셀 데이터를 볼 필요 없이, 시계열로 정렬된 음성 대본과 프레임 요약 정보를 바탕으로 논리적인 챕터 구분점(Timestamp), 제목, 요약문을 생성합니다.

이 접근법에 대한 판단은 지금 써볼 만하다입니다. 대형 멀티모달 모델이 아무리 발전해도 1시간 분량의 고해상도 영상을 프레임 단위로 입력받아 분석하는 것은 토큰 단가와 처리 시간 측면에서 실무 서비스에 적용하기 어렵습니다. 트랜스코딩 전용 엔진으로 데이터를 선별한 뒤 LLM에 질의하는 분리형 아키텍처는 추가적인 R&D 없이도 현재 프로덕션 환경에서 즉시 비용과 안정성을 확보할 수 있는 방법입니다.

실무 파이프라인 구현: 미디어 이벤트 기반 Bedrock 챕터 생성

실무에서 미디어 트랜스코딩과 LLM을 연동할 때는 MediaConvert 작업이 완료되는 이벤트를 받아 Bedrock 모델을 비동기로 호출하도록 구성해야 백엔드 웹 서버가 긴 변환 작업 동안 대기하지 않습니다.

아래 예시는 AWS SDK for Python(boto3)을 사용하여 MediaConvert 작업 완료 후 추출된 오디오 전사 데이터와 타임스탬프 목록을 Bedrock의 Claude 계열 모델에 전달하고, 구조화된 챕터 JSON을 반환받는 AWS Lambda 핸들러의 완결된 형태입니다.

import json
import logging
from typing import Any, Dict, List
import boto3
from botocore.exceptions import BotoCoreError, ClientError

logger = logging.getLogger()
logger.setLevel(logging.INFO)

bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")


def call_bedrock_chaptering(transcript_segments: List[Dict[str, Any]]) -> str:
    """정제된 자막 구간 데이터를 기반으로 Bedrock에 구조화된 챕터 생성을 요청합니다."""
    prompt = f"""
다음은 영상에서 추출한 시간대별 발화 내용입니다:
{json.dumps(transcript_segments, ensure_ascii=False)}

이 내용을 주제의 흐름에 따라 3~7개의 주요 챕터로 나누어 주세요.
반드시 아래 JSON 스키마 형식으로만 응답하고, 마크다운 코드블록이나 불필요한 설명은 붙이지 마세요:
[
  {{"start_time": "00:00", "end_time": "03:15", "title": "도입 및 문제 정의", "summary": "기존 파이프라인의 비용 병목 분석"}}
]
"""
    body = {
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 1500,
        "temperature": 0.1,
        "messages": [{"role": "user", "content": prompt}],
    }

    response = bedrock_runtime.invoke_model(
        modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
        contentType="application/json",
        accept="application/json",
        body=json.dumps(body),
    )
    response_body = json.loads(response["body"].read().decode("utf-8"))
    return response_body["content"][0]["text"]


def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, Any]:
    """EventBridge를 통해 전달된 MediaConvert 완료 이벤트를 처리합니다."""
    logger.info("이벤트 수신: %s", json.dumps(event))

    # MediaConvert가 생성한 자막 전사 결과(예시 세그먼트 데이터)
    # 실제 환경에서는 S3에 저장된 전사 JSON을 읽어옵니다.
    transcript_segments = [
        {"start": "00:00", "end": "02:40", "text": "HPC 시뮬레이션 환경 구축 개요를 설명합니다."},
        {"start": "02:41", "end": "05:10", "text": "스팟 인스턴스와 온디맨드 인스턴스 간 비용 차이를 분석합니다."},
        {"start": "05:11", "end": "09:30", "text": "최종 벤치마크 결과 및 결론을 공유합니다."},
    ]

    try:
        chapter_result_str = call_bedrock_chaptering(transcript_segments)
        chapters = json.loads(chapter_result_str)
        logger.info("생성된 챕터 수: %d", len(chapters))

        return {
            "statusCode": 200,
            "body": json.dumps({"status": "SUCCESS", "chapters": chapters}, ensure_ascii=False),
        }
    except (BotoCoreError, ClientError) as aws_err:
        logger.error("Bedrock API 호출 실패: %s", str(aws_err))
        return {"statusCode": 500, "body": json.dumps({"error": "LLM 호출 중 오류 발생"})}
    except json.JSONDecodeError as json_err:
        logger.error("LLM 응답 JSON 파싱 실패: %s", str(json_err))
        return {"statusCode": 502, "body": json.dumps({"error": "잘못된 응답 포맷"})}

이 구현에서 핵심은 temperature 값을 0.1로 낮추고 프롬프트에 명확한 JSON 스키마를 지정하여 파싱 실패 확률을 줄이는 것입니다. 영상 전체를 프레임 단위로 Bedrock에 올리지 않고, 이미 텍스트화된 타임스탬프 세그먼트만 전송하기 때문에 호출당 토큰 비용을 최소화할 수 있습니다.

두 방식의 비교와 아키텍처 선택 기준

모델 내부의 효율화(DeepSeek V4.1 Flash)와 모델 외부의 데이터 정제(MediaConvert + Bedrock)는 상호 배타적인 기술이 아닙니다. 파이프라인의 어떤 위치에서 병목을 제어할 것인가에 대한 기준입니다.

• 제어 계층 — DeepSeek V4.1 Flash 방식: 모델 내부 아키텍처 (CED + MoE) / MediaConvert + Bedrock 방식: 모델 외부 인프라 파이프라인 (미디어 전처리)
• 입력 데이터 형태 — DeepSeek V4.1 Flash 방식: 원본 이미지 + 텍스트 혼합 임베딩 / MediaConvert + Bedrock 방식: 사전 추출된 메타데이터 / 타임스탬프 텍스트
• 장점 — DeepSeek V4.1 Flash 방식: 이미지 패치 이해와 다중 모달 추론의 자연스러운 통합 / MediaConvert + Bedrock 방식: 기존 미디어 파이프라인 즉시 적용 가능, 토큰 비용 예측 용이
• 주된 제약 조건 — DeepSeek V4.1 Flash 방식: 5,520억 파라미터 적재를 위한 막대한 VRAM 인프라 필요 / MediaConvert + Bedrock 방식: 오디오 전사 및 썸네일 추출을 위한 전처리 지연 시간 발생
• 실무 판단 — DeepSeek V4.1 Flash 방식: 조건부 유효 (API 활용 시 추천) / MediaConvert + Bedrock 방식: 지금 써볼 만함 (사내 VOD 서비스 즉시 권장)

여기부터는 DEVOTEE의 해석입니다. 향후 영상 및 음성 기반 서비스 아키텍처는 두 방식의 결합으로 수렴할 가능성이 큽니다. 미디어 인프라가 1차적으로 비디오 스트림을 핵심 키프레임과 오디오 세그먼트로 가볍게 다듬고, 이를 처리하는 백엔드 모델은 DeepSeek V4.1 Flash와 같은 비대칭 MoE 모델을 통해 낮은 지연 시간으로 멀티모달 분석을 수행하는 형태입니다. 모델이 커진다고 해서 처리 파이프라인까지 무거워질 필요는 없습니다.

도입 전 확인할 것

비대칭 MoE 모델이나 미디어 자동 챕터 생성 파이프라인을 실무에 도입하기 전에 점검해야 할 기술적 체크리스트입니다.

• VOD 전처리 파이프라인의 이벤트 격리 여부: MediaConvert 작업은 동영상 길이에 따라 수 분 이상 소요될 수 있습니다. API 서버 내부에서 동기식으로 대기하지 않고, SQS 큐나 EventBridge를 통해 비동기 이벤트 기반으로 모델 호출을 분리했는지 확인하세요.
• 초기 적재 VRAM 요구량 산출: DeepSeek V4.1 Flash처럼 활성화 파라미터가 적은 모델을 직접 호스팅하려 할 때, 활성화 크기(8B/16B)만 보고 인스턴스를 발주해서는 안 됩니다. 552B 전체 모델 가중치를 적재할 GPU 클러스터의 최소 VRAM과 노드 간 통신 대역폭을 먼저 계산해야 합니다.
• 챕터 분할 실패 시의 폴백(Fallback) 정책: LLM이 반환하는 JSON 타임스탬프가 영상의 총 재생 길이를 초과하거나, 시작 시간이 이전 구간의 종료 시간보다 앞서는 논리 결함이 발생할 수 있습니다. 파싱 계층에서 타임스탬프의 단조 증가(monotonic increase) 여부를 검증하는 로직을 필수로 두어야 합니다.

그 밖의 소식

• 토스뱅크가 호스트 실행 환경과 원본 소스 코드 확인 문제를 해결하기 위해 패키지 관리의 세 가지 기준과 빌드 도구 설정을 정립했습니다 — 원문
• Google이 복잡한 기술적 난제를 해결하도록 설계된 Gemini 4 Argon 모델을 발표하고 개발자 위클리 업데이트를 공유했습니다 — 원문
• 인코어드가 재생에너지 발전량 예측을 위해 AWS HPC 환경에서 WRF 기상 시뮬레이션을 구동하는 인스턴스 선정 및 비용 최적화 사례를 공개했습니다 — 원문