KREONET Workshop 2일차

EXAONE 기반 ixi-GEN : 도메인 특화 sLLM

  • 최근 저비용 오픈 모델 기반 Continal-Pretraining

특화모델이 필요한 이유

  • LLM에 대규모 도메인 데이터를 추가 학습시켜 성능 향상 도모

DACP

  • 도메인 지식의 학습은 최대화 & 일반 지식의 망각은 최소화
  • AS-IS(Pretraining → Continal-Pretraining → Post Pretraining)
  • 잘 갖추어친 체계 위에서 빠르게 특화 도메인 확장 및 모델 업데이트 적용

EXAONE

  • EXAONE 기반 ixi-GEN(sLLM/sLM)모델 확보
  • EXAONE DeepSeek와 비슷한 추론 모델 공개

ixi-GEN

  • 통신/금융 생성형 AI 모델 확보, ixi-GEN
  • 각 산업 별 데이터를 학습하여 도메인 특화 생성형 AI 모델 제공 가능
  • 통신 특화 데이터
    • 네트워크/통신 관련 지식 데이터
    • 개인정보 비식별화 적용 완료된 상담 데이터
  • 통화 데이터
    • 개인정보 비식별화 적용 완료된 상담 데이터
  • 금융 데이터
    • 제휴를 통해 확보한 금융 데이터
  • 증강 기술을 통해 데이터 고품질화 도모

특화모델 성능

  • 일반 도메인 지식의 망각을 최소화 하며, 통신 도메인 지식 학습 최대화
  • 통신 도메인 성능 50% 상승, 일반 도메인 성능 유지
  • 더 큰 파라미터의 모델보다 더 높은 통신 도메인 성능
  • 작은 모델을 서비스에 적용함으로써 고객 경험 상승
  • 교육특화
  • DACP 및 타겟 도메인, 서비스 적용시 성능 개선 확인
    • 통신 LLM이 기존 대비 9% 성능 개선
    • RAG 성능 11% 상승

Work agent 핵심 기술 RAG

  • Retrieval과 Augmentation 과정을 통해 내부 문서 등 LLM 외부로부터 검색된 지식을 활용하여 정확한 답변을 생성하는 기술
  • RAG가 없다면? LLM이 미리 학습하지 않았다면 질문에 대한 정확한 답변이 불가능
  • 문서인식
    • Parser RAG 시스템의 핵심 기술

Era of Agent AI

  • LLM, RAG, MCP, AZA

Cluster with AI Cloud

HAEIN Cluster

  • 1,000+ NVIDA Blackwell GPUs
  • Petasus AI Coud
  • National Program
  • Partners

SKT AI DC - Tier-III Data Center, 44KW per Rack(air cooled)

SuperMicro Server

8 x 8200 GPUs

GPU Fabric - InfiniBand based

Storage Fabric - NFS over RDMA

Evolution of Virtualization Technology 

  • Performance
  • Multi-tenancy
  • Management
  • Security
  • Maintenance

Virtual Machine

  • Hypervisor
  • openstack
  • Host Kernal

Container

  • Container Runtime
  • Kubernetes
  • Host Kernal

Containerized Virtual Machine

  • Container Runtime
  • Kubernetes
  • KubeVirt
  • Host Kernal

NVLink

  • Fast communication among GPUs

GPUDirect RDMA (GDR)

Virtualization on NVLink

  • Steers the intra-node GPU traffic using Fabric Manager → isolate the GPU traffic per tenancy

Virtualization on GPUDirect RDMA

  • ATS (@HCA/NIC) with Direct Translation (@PCIe Switch) enables GDR and GDS for VM

Virtulized NVLink and GDR

  • VM provisioning with virtualized NVLinks with GPUDirect RDMA

저비용 Deep Learning

LLM Training and Fine-Tuning → Multi-cluster Training → Reducing

Limitations of Commodity GPUs

GPU resource pooling from hybrid multi cluster

TTA(Time to accuracy)

  • Iteration speed
  • Convergence speed

Top Cache line size/k [solution cpu]

Speculative decoding

AIOps 기반 차세대 네트워크

네트워크 운영의 AI 자동화

  • PCA
    • 장애 이전에 탐지-대응하는 Proactive 운영이 시장 표준으로 자리 잡음
    • 예측-자동화 Self-Healing 기능을 핵심 경쟁력으로 인식
  • NMS

기존 운영 방식의 한계 - 기술적 제약

  • 기존 운영 방식은 선제적, 통합적 대응을 보장할 수 없음
    • 멀티 벤더의 멀티 장비 운용
    • 가상화 및 가상 솔루션의 비가시성
    • 장애 발생 사후 조치

기존 운영 방식의 한계 - 운영적 제약

  • 자동 대응 체계의 부재로, 운영 품질의 균질화와 신속한 장애 대응이 어려움
    • 수도권에 기술 인재 집중
    • 라이선스 위배 및 연한이 지난 장비(EOS)
    • 인프라/네트워크 팀 간 단절

AIOps 지능형 자동화 전환 필요성

  • 장애 발생, 사후 대응 → 사전 예측, 대응 및 지능형 자동화가 새로운 운영 표준

솔루션 개요 및 목표

  1. Muliti-Agent 기반 RCA 도출
    1. 이벤트 상관 분석
    2. 인프라 에이전트
    3. 네트워크 에이전트
    4. 소프트웨어 에이전트
    5. RCA 추론
  2. 엔지니어 피드백 기반 학습
    1. RCA 추론
    2. 엔지니어 확인 요청
    3. 핵심원인 파악 요청
  3. Semi-Automation
    1. Runbook 생성
    2. 조치 결과 확인
  4. Full-Automation
    1. 자동 조치 수행
    2. 디지털 트윈 시뮬레이션
    3. 감독 및 보고

기대효과 및 기술 차별성

  • 융합 아키텍처
  • Self-Healing 자동화
  • RLHF기반 학습 고도화
  • 오픈소스 기반 확장성

차세대 네트워크 6G 아키텍처 진화 방향

6G - AI, Sensing, Satelite NTN

5G

  • Network slicing
  • Service based architecture (SBA), and capability exposure (NEF)
  • Common core architecture 
  • Distributed UPFs and edge computing support

Service and Technology Trends Towards 6G

  • Diversification od Data Consumers
  • Digital Replica
  • Digital Twin
  • Expansion of Service Coverage
  • coverage of new verticals

General Views on 6G System Architecture 

  • Expending Network Capabilities for 6G
    • Suporting new capabilities for emerging services and verticals (e.g.. AI-natives capabilities/service, sensing, etc)
  • Building a New Ecosystem with Unified Open Interfaces

6G Timeline (TBD)

  • 유스케이스 논리 → Studt Items (TR) → Work Items (TS) → ITU-R 제출

ITU-R IMT-2030 Framework

  • IMT-2030(6G) Usage scenarios

3GPP Activities on 6G System Architecture Study

  • Study on Architecture for 6G System (TR 23.801-01)
  1. Overall architecture 
  2. Migration and interworking
  3. AI
  4. Sensing
  5. Data Framework
  6. Computing
  7. NTN
  8. 6G Iot

6G System Architecture- New Features/ Functionalities

  • AI and Communication 
  • Network and Computing Convergence
  • Sustainability
  • Ubiquitous Connectivity
  • Integrated Sensing and Communication 
  • Security and Trustworthy Architecture 
  • System Design and Network Operation

AI Traffic Identification and AI - aware Routing (Network for AI Agent)

  • AI Traffic vs Conventional Traffic 
  • AI-aware QoS routing

Common and Unified Data Framework

  • Architectural Motivation
  • Technical Impact

Network-Computing Convergence

  • Architectural Motivation
  • Technical Impact

NTN Evolution

  • NTN-Native Core : NTN not just as an "Add-on"

End-to-end Energy Efficiency / Energy-Native System

Enhanced Security : Quantum Cryptography 

  • More Enhanced Security
  • Quantum Threat
  • Post Quantum Cryptography (PQC)
  • Quantum Key Distribution (QKD)

AI for Mobile Network

Trend of AI4NET

  • AI를 활용한 네트워크의 성능 개선
  • 4G
    • AI는 Network 외부에 존재
  • 5G
    • AI 학습과 추론이 Network 내부로 이동
    • 추론 결과에 따라 조건부 action 실행
  • 6G
    • AI 학습과 추론이 Network 내부로 이동
    • 사용자와 운영자의 Intent 기반으로 Multi-Agent Network orchestration.

Trend of NET4AI

  • 네트워크를 활용한 AI의 성능 개선
  • Phase I Connectivity
    • Issues
      • Synchronization in Multi-modal AI
      • High UL throughput (e.g. eMIMO, CoMP, etc) / Low Iatency (e.g. MEC, etc)
      • Token communication (e.g. different Property, etc)
  • Phase II + Computing Infra
    • Motivation
      • GPU
      • CPU
      • NPU
  • Phase III + Platform

AI4NET

  • 5G Network
    • NWDAF provide AI framework in 5G Network
    • All NF can subscribe AI intelligence
  • 6G Network
    • Intent Driven Agent Management 
    • Multi-Agent Network Orchestration
    • AI Agent for Network Function
    • MCP based Network Control

MCP(Model Context Protocol)? - AI Agent가 외부 데이터 소스와 도구에 연결하여 작업을 수행할 수 있도록 돕는 표준 프로토콜

NET4AI

  • 5G Network
    • Latency
    • Prompt-Response sevice
    • No Personal Customizing
    • Data Privacy 
    • Hyperscaler overhead in infrastructure for learning & inference
  • 6G Network
    • GPU on Demand API
      • AI agent을 위한 Ai mode 학습응 위해 API 기반으로 네트워크의 GPU 자원 동적 활용
    • Split Computing for Physical AI VLC (Vision-Language-Action)

네트워크 기반 원격제어 자율 주행 및 로봇 응용 실증

Edge Application 등장

5G 기술 확산의 한계

  • 유선, 종단간 지연 미고려
  • 융합 서비스 실현 한계

버티컬 산업의 기술적 병목 요인

  • 제어 지연과 네트워크의 불안정
  • 통신,제어,응용 간 단절된 시스템 구조
  • 공장,물류,서비스 등 이기종 도메인 간 연동 마비
  • 기술 필요성
    • 제어에 요구되는 End-to-End 실시간 통신 성능 확보 필요
    • 구성요소(로봇, 클라우드, 네트워킹, 인프라 등)의 데이터 통합/제어 기능 환경 요구
  • 최선의 지연시간 달성을 위해 전용 유무선 통신 기술로 종단간 성능 보장이 가능한 모빌리티 네트워크 구축
    • 모빌리티 서비스를 대상으로 성능이 보장되는 개별 네트워크를 생성하는 기술
    • 이동 중에도 네트워크 슬라이싱 및 측위에 기반한 이동성 기술(Hand-off)을 구현
    • 프로그래밍 가능한 프로그래머블 사설망은 자율주행, 원격의료, 로봇관제
  • 네트워크 슬라이싱 코어 플랫폼
  • 원격 자율주행 저지연 통신망 플랫폼
  • TRENTO Ecosystem 5G

원격 제어 자율주행

  • 자율주행 인지 한계
    • 센서의 인지 한계
      • 센서 특성으로 인한 사물 검지의 제약 발생
    • 상황인지를 위한 전산비용
      • 전산 처리비용 및 에너지 소모량 증가
  • 기술적 배경 및 문제점
    • 자동자 및 로봇등에 적용되는 완전 자율주행 기술의 기술적 난도
    • 자율주행 기술의 사고 증가에 따른 안정성 이슈 최근 부각
    • 모빌리티 위한 초 저지연 기술 필요, 그러나 실용 기술 부재
    • 5G 사설망의 문제점(비용과 구축 운영의 복잡성)
  • 저지연 네트워크 기술 기반 차량 내외부 통신 기술 적용

저지연 네트워크 기반 Cloud 로봇 제품화

  • 클라우드 기반 로봇 서비스를 위한 소프트웨어의 기술
  • 로봇 기능의 메시지 챗 통신 프로토콜이 포함된 API 기술(표준화 추진)
  • H/W에서 S/W 분리하여 중앙집중식 로봇 기능 소프트웨어화
  • 기존 단순한 클라우드 서비스에서 로봇 애플리케이션 서비스까지 로봇은 하드웨어 비용과 소프트웨어 비용을 크게 줄일 수 있는 환경 제공

KAFE T&I

  • 목적 - 글로벌 통합 인증
  • 핵심 기능 - 메타데이터 수집/배포, eduGAIN연동점, 탐색 서비스, Homeless IDP, trustHUB
  • trustHUB 부가 서비스 - 서비스제공자의 부가 인증 기능을 위임 받아 수행

T&I vs trustHUB

  • T&I
  • trustHUB

KeyCloud

국가 대용량 데이터 교환노드 접근제어 시스템 고도화 개발

OTP

  • TOTP
  • HOTP

그룹 관리 시스템

  • 계층 구조 기반 그룹 관리
  • 역할 기반 권한 구조
  • 주요 기능
    • 그룹 속성 관리
    • OIDC/SAML RP 연동 속성 매핑
    • 계층적 권한 상속 구조
    • 그룹 액션 권한 관리

LDAP 연동

  • 안정적인 LDAP 연동 아키텍처
  • 유연한 속성 매핑 및 테이블 관리

OAuth2-proxy & I AM MyKSC

MyKSC 인증

  • Kubernetes에서는 Ingress 규칙만 정의
  • 실제 트래픽 라우팅을 위해서는 Ingress controller이 필요
  • Path-based host routing
    • 단일 도메인 사용 가능
    • 실행 서비스에서 서비스 주소 변경이 가능해야 함 (proxy 모드)
    • Jupyter의 경우 baseurl 설정을 통해 서비스 주고 변경이 가능
  • Hostname-based host routing (MyKSC 적용)
    • 트래픽 저에가 복잡
    • 멀티 도메인 필요
    • 실행 서비스의 설정 변경 없이 활용 가능
  • Path-based host routing을 이용할 경우 Proxy 모드 지원이 필수적이나 많은 Open-source application 미지원
  • 문제점
    • 멀티 도메인 인증서 필요
    • 인증 문제
      • 인증을 받은 request만 통과
  • 해결 방안
    • istio + oauth2-proxy + IAM
      • istio external authorization 
      • oauth2-proxy as authentication middleware 
  • MyKSC ↔  BANDI SSO ↔ OAuth2 Proxy ↔ Istio → 

AI-On

  • For AI application
    • 슈퍼컴퓨터 5호기에 최적화된 응용은 제외
    • AI/ML end-to-end pipeline 지원(예정)
  • Open source
    • BandiSSO를 open-source
  • Fine tunning
  • Zero-code fine tunnung
    • LLaMA-Factory
    • Axolotl

eduroam

freeradius 전환

test point - 주기적 ping