2026년 5월 10일 - 5월 16일 (Iteration 22)

주요 개발 내용 요약

이번 주는 추론 API Key 인증 시스템 구현(#254), 추론 API Rate Limiting 구현(#255), 이미지 워머 OOM 버그 수정(#260, #262)에 중점을 둔 기간이었습니다. 총 10개의 커밋, 5개의 PR 머지, 12개의 이슈 생성이 완료되었으며, 추론 프록시의 인증/인가 및 사용량 제한 체계를 완성하여 상위 이슈 #194(추론 API 키 인증 및 Rate Limiting)를 종료하고, 인증/인가 고도화를 위한 후속 이슈 로드맵(사용자 관리, RBAC, Redis 전환 등)을 수립한 주간이었습니다.

새로운 기능 (New Features)

1. 추론 API Key 인증 시스템 (#254 → PR #256)

구현 완료: JWT 외에 프로그래매틱 접근(curl, OpenAI SDK 등)을 위한 API Key 인증 시스템 추가 — sk-hmas- 접두사 기반 키 발급, 통합 인증 미들웨어(JWT + API Key), 배포 범위 제한, 만료 관리

주요 성과:

• Backend:
  • api_keys 테이블 + 마이그레이션(000025, 000026) — SHA-256 해싱, 소유자/만료/스코프/활성 상태 관리
  • 통합 인증 미들웨어 리팩터링 — Authorization: Bearer sk-hmas-xxx(API Key) / Bearer eyJ...(JWT) 자동 분기
  • API Key CRUD 엔드포인트(POST/GET/DELETE /api/api-keys)
  • 추론 프록시에 배포 범위 제한(allowed_deployments) 적용
  • 추론 로그에 인증 방식(auth_method: api_key/jwt)과 키 ID 기록, lastUsedAt 자동 갱신
• Frontend:
  • /api-keys 페이지: 키 목록(이름, 생성일, 만료, 마지막 사용일), 생성 다이얼로그(만료일/스코프 설정), 키 원문 1회 복사 UI, 폐기 확인
  • 사이드바에 “API 키” 메뉴 추가

의사결정 사항:

검증 완료: API Key 인증으로 추론 프록시 비스트리밍/SSE 스트리밍 요청, OpenAI SDK 호환성, 만료/폐기 키 거부, 추론 로그 기록 확인

관련 커밋: c6b9f96 (PR #256, Closes #254)

2. 추론 API Rate Limiting (#255 → PR #265)

구현 완료: 추론 프록시에 사용자/API 키별 RPM(분당 요청 수)/TPM(분당 토큰 수) 제한 적용 — 429 응답 + 표준 헤더, 환경변수 글로벌 기본값 + API 키별 커스텀 한도 오버라이드

주요 성과:

• Backend:
  • RPM: Token Bucket 알고리즘 기반 실시간 요청 제한
  • TPM: Sliding Window 기반 사후 토큰 사용량 추적
  • 429 Too Many Requests 응답 + 표준 헤더(X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After)
  • 환경변수 글로벌 기본값(HMAS_RATE_LIMIT_RPM=60, TPM=0) + API 키별 커스텀 오버라이드
  • GET /api/rate-limits — 현재 사용량/한도/글로벌 기본값 조회 API
  • hmas_inference_rate_limited_total Prometheus 메트릭
• Frontend:
  • API 키 생성 다이얼로그에 RPM/TPM 입력 필드 + 기본값 placeholder
  • API 키 목록에 Rate Limit 컬럼 — 기본값 수치 + “(기본)” 표시

의사결정 사항:

관련 커밋: 10f03b9 (PR #265, Closes #255)

버그 수정 (Bug Fixes)

1. 이미지 워머 OOM 해결 (#260 → PR #261)

수정 완료: 이미지 워머 DaemonSet Pod이 CrashLoopBackOff(OOM-killed)에 빠지는 문제 해결 — 메모리 limit 4Mi → 32Mi, CPU limit 1m → 10m 상향

수정 내용:

• 서빙 런타임 이미지(vLLM 등)의 base layer(Ubuntu 24.04)가 init 시 4Mi 이상 메모리를 요구하여 OOM 발생
• sleep infinity 실행 상태에서 실사용량은 1~2Mi이므로 노드 리소스 부담 없음

관련 커밋: 870ce1b (PR #261, Closes #260)

2. 이미지 워머 메모리 request/limit 분리 (#262 → PR #263)

수정 완료: #260 수정 시 request도 32Mi로 설정되어 발생한 불필요한 노드 메모리 예약 문제 해결 — request 32Mi → 4Mi로 분리

수정 내용:

• Kubernetes 스케줄러가 request 기준(32Mi)으로 노드 리소스를 예약하여 실사용량 대비 16~32배 과다 예약 발생
• request 4Mi(실사용 + 여유) / limit 32Mi(init OOM 방지)로 분리
• Reconciler 60초 주기 갱신으로 기존 DaemonSet에 자동 반영

관련 커밋: 56580b5 (PR #263, Closes #262)

문서화 (Documentation)

기술 문서 업데이트 (7건)

이전 Iteration 계획 달성도

Iteration 21에서 계획한 4개 항목 1개 완료, 3개 미착수 — 추론 API 키 인증 및 Rate Limiting(#194)을 완성하는 데 집중하고, 나머지 시간은 이미지 워머 OOM 긴급 수정 및 인증/인가 고도화 후속 이슈 로드맵 수립에 활용:

추가 달성: 계획에 없던 이미지 워머 OOM 긴급 수정(#260, #262), Control Plane 정리 가이드(#258), 전체 문서 최신화, 인증/인가 후속 이슈 7건 생성(#264, #266~#270).

미해결 이슈 (Open Issues)

신규 이슈 (7개, 이번 Iteration 생성)

#268 → #269 → #267 순으로 의존: 사용자 관리(멀티 사용자) → RBAC(역할별 권한) → 사용자별 Rate Limit #264(Redis 전환)는 수평 확장 시점에 착수, 현재 단일 인스턴스 환경에서는 In-Memory로 충분 #270(TPM 토큰 사전 추정)은 동시 요청 패턴 분석 후 구현 여부 판단

추론 프록시 이슈 체인

인증/인가 고도화 이슈 체인 (신규)

이번 주 통계

결론

이번 주는 추론 프록시 인증/인가 및 사용량 제한 체계를 완성한 기간이었습니다. API Key 인증 시스템(#254)으로 외부 시스템(OpenAI SDK, curl 등)의 프로그래매틱 접근이 가능해졌고, Rate Limiting(#255)으로 사용자/키별 RPM·TPM 제한을 적용하여 남용 방지 및 공정한 자원 분배 기반을 마련했습니다. 이로써 v0.4부터 이어진 추론 프록시 Phase 3(#194)를 종료하고, 인증/인가 고도화 후속 로드맵(사용자 관리, RBAC, Redis 전환, API Key PATCH, TPM 토큰 추정)을 수립하여 v0.9 이후 방향성을 구체화했습니다.

핵심 성과:

1. 추론 API Key 인증 완성: sk-hmas- 접두사 키 발급, SHA-256 해싱, JWT/API Key 통합 인증 미들웨어, 배포 범위 제한, OpenAI SDK 호환
2. 추론 API Rate Limiting 완성: Token Bucket(RPM) + Sliding Window(TPM), 429 응답 + 표준 헤더, 글로벌 기본값 + 키별 커스텀 오버라이드
3. 상위 이슈 #194 종료: 추론 프록시 Phase 3(API Key + Rate Limiting) 전체 완료
4. 인증/인가 후속 로드맵 수립: 사용자 관리(#268) → RBAC(#269) → 사용자별 Rate Limit(#267) 의존 체인 및 Redis 전환(#264) 계획 구체화

다음 주 계획:

• 추론 프록시 Phase 2: 멀티클러스터 라우팅 (agent 터널 통합) (#192)
• hmas-agent 핵심 컴포넌트 구현 착수 (#190)
• 런타임 자동 튜닝 설계 상세화 (#114)
• API Key 동적 수정 API (#266)

문서 작성일: 2026년 5월 17일

• Teaching ‘Fundamentals of Machine Learning’ - Kyunghyun Cho
  • 코딩 어시스턴트(AI 툴)를 적극 활용하여 ‘Fundamentals of Machine Learning’ 수업 방식을 전면 개편한 교수의 경험담.
  • 기존의 빈칸 채우기 식 실습에서 벗어나, 매주 배운 ML 개념을 바탕으로 밑바닥부터 완전한 웹 앱을 ‘바이브 코딩(vibe-coding)’하는 방식으로 수업을 진행함.
  • 학생들에게 자유도를 주고 스스로 AI 도구를 활용해 프로젝트를 완성하게 함으로써, 학생들의 창의성과 문제 해결 능력이 크게 향상됨을 관찰함.
• How to Make LLM Training Faster with Unsloth and NVIDIA
  • NVIDIA와의 협업을 통해 Unsloth의 LLM 파인튜닝 속도를 정확도 손실 없이 기존 대비 약 25% 추가 향상시킴.
  • 반복되는 Packed Sequence 메타데이터를 매 레이어마다 재생성하지 않고 캐싱하여 재사용함으로써 14.3%의 속도 향상을 얻음.
  • 그래픽 메모리와 시스템 메모리 간의 Activation 복사와 역전파 연산을 중첩(Double Buffered Async Gradient Checkpointing)시켜 8%의 속도 향상을 달성함.
  • MoE 라우팅 시 동적 쿼리(torch.where) 대신 argsort와 bincount를 활용해 연산을 한 번에 묶어서 처리함으로써 GPT-OSS 학습 속도를 15% 단축함.
• TokenSpeed: A Speed-of-Light LLM Inference Engine for Agentic Workloads
  • 에이전틱(Agentic) 워크로드에 최적화된 새로운 초고속 LLM 추론 엔진인 TokenSpeed 발표 (LightSeek Foundation, NVIDIA, AMD 등 공동 개발).
  • Control Plane(상태 머신, 자원 관리)과 Execution Plane을 분리한 고성능 스케줄러 및 자동화된 모델링 병렬화 메커니즘을 도입함.
  • Tensor Core 활용도를 극대화한 자체 최적화 커널(TokenSpeed MLA 등)을 적용해, 에이전트 환경에서 TensorRT-LLM 대비 더 높은 처리량(TPM)과 더 낮은 지연 시간(TPS)을 달성함.
• State of Routing in Model Serving - Netflix TechBlog
  • Netflix에서 초당 100만 건 이상의 요청을 처리하기 위해 구축한 중앙 집중식 ML 모델 서빙 플랫폼의 아키텍처 진화 과정 소개.
  • 초기에는 ‘Switchboard’라는 중앙 프록시를 통해 컨텍스트 기반 라우팅과 A/B 테스트를 처리했으나, 단일 장애점(SPOF) 문제와 네트워크 지연이 발생함.
  • 이를 해결하기 위해 라우팅 정보 리졸브(Lightbulb)와 실제 트래픽 라우팅(Envoy proxy) 계층을 분리하는 구조로 개편하여, 안정성과 성능을 개선함.

AI Daily Picks(20260513)

• How to achieve truly serverless GPUs
  • GPU 인퍼런스 환경의 콜드 스타트를 수십 분에서 수십 초 단위로 단축하여 낭비 없는(Serverless) 리소스 할당을 달성한 엔지니어링 4단계 핵심 요소를 설명함.
  • 클라우드 버퍼 (Cloud buffers): 건강한 유휴 GPU 버퍼를 미리 유지하여 새로운 인스턴스 할당과 헬스 체크에 소요되는 수십 분의 지연 시간을 제거함.
  • 커스텀 파일 시스템 (ImageFS): libfuse를 기반으로 티어 구조의 캐시를 구현하여 전체 이미지 로드 없이 컨테이너 실행에 필요한 파일만 지연 로딩(Lazy Loading)함으로써 컨테이너 시작 시간을 단축함.
  • 호스트 및 디바이스 메모리 스냅샷 (Checkpoint/Restore): gVisor(runsc)를 활용해 프로세스 메모리 상태(Host)를 복원하고, Nvidia 드라이버 기능으로 GPU 메모리(Device)까지 체크포인트 및 복원하여 런타임 초기화와 가중치 로드 시간을 획기적으로 줄임.
• Agentic RAG
  • 단순 정보 검색 후 생성을 수행하는 기존 RAG의 한계를 극복하기 위해, AI Agent가 검색의 전 과정을 주도하는 Agentic RAG 개념과 워크플로우를 소개함.
  • 기존 RAG는 한 번의 검색만 수행하여 복잡한 다중 홉(multi-hop) 질문이나 모호한 쿼리 처리에 취약하지만, Agentic RAG는 Agent, 도구(Tools), 루프(Loop)를 활용해 목표 달성 시까지 검색과 평가를 반복함.
  • 대표적인 패턴으로 ReAct, Self-RAG, Corrective RAG(CRAG)가 있으며, 복잡한 쿼리와 다중 데이터 소스 환경에서 뛰어난 성능을 보이나 지연 시간과 비용 증가를 고려해야 함.

2026년 5월 3일 - 5월 9일 (Iteration 21)

주요 개발 내용 요약

이번 주는 추론 요청 로깅 파이프라인 구현(#193), 추론 로그 뷰어 UI 및 토큰 사용량 파싱(#227), 배포 이벤트 히스토리 DB 저장 및 조회(#250)에 중점을 둔 기간이었습니다. 총 12개의 커밋, 8개의 PR 머지, 8개의 이슈 생성이 완료되었으며, 추론 프록시를 경유하는 모든 요청에 대해 DB 로깅·Prometheus 메트릭·토큰 사용량 추적이 가능해졌고, K8s 이벤트 TTL(~1시간) 이후에도 배포 이벤트 이력을 조회할 수 있는 운영 가시성 기반을 구축한 주간이었습니다.

새로운 기능 (New Features)

1. 추론 요청 로깅 및 메트릭 수집 파이프라인 (#193 → PR #245)

구현 완료: 추론 프록시를 경유하는 모든 요청에 대해 DB 로깅, Prometheus 메트릭 5종 수집, 페이지네이션/필터 지원 조회 API를 구현하여 추론 사용 현황 추적 기반 확보

주요 성과:

• Backend:
  • inference_logs 테이블 + 마이그레이션(000023) — request_id, username, deployment, model, cluster, TTFB/Duration, 상태 코드, 스트리밍 여부, 에러 메시지 기록. 인덱스 4개
  • 비동기 채널 기반 배치 writer (InferenceLogWriter) — 프록시 레이턴시 무영향 (buffer=1000, batch=100, flush=5s). Non-blocking drop + 유실 카운터 메트릭
  • Prometheus 메트릭 5종: requests_total, duration_seconds, ttfb_seconds, active_requests, log_drops_total
  • 로그 조회 API (GET /api/inference-logs) — deployment, username, status_code, 시간 범위 필터 + 페이지네이션
  • 30일 보존 정책 정리 goroutine (LogCleaner) — 1시간 주기, 1000건 배치 삭제

의사결정 사항:

관련 커밋: 70a4d0f (PR #245, Closes #193)

2. 추론 요청 로그 뷰어 UI 및 토큰 사용량 파싱 (#227 → PR #249)

구현 완료: 추론 로그 전용 페이지(/inference-logs) 신규 추가 및 비스트리밍/스트리밍 응답에서 토큰 사용량을 투명하게 추출하는 파싱 체계 구현

주요 성과:

• Frontend:
  • /inference-logs 경로에 독립 페이지 생성, 사이드바에 “추론 로그” 메뉴 추가
  • 테이블 UI (타임스탬프, 요청자, 배포, 모델, 상태, TTFB, 소요시간, 토큰)
  • 필터 바 (배포명, 사용자, 상태코드, 시간범위) + 상세 정보 Sheet + 페이지네이션
  • SWR 30초 자동 갱신
• Backend:
  • 비스트리밍 응답 바디에서 usage JSON 추출
  • 스트리밍 응답은 SSE 이벤트 스캐너(SSEUsageScanner)로 투명 토큰 추출
  • opt-in 런타임 지원: vLLM, TGI, llama.cpp, Ollama에 stream_options.include_usage=true 자동 주입
  • hmas_inference_proxy_tokens_total Prometheus 카운터 (deployment × direction)

검증 완료: vLLM/Ollama 비스트리밍·스트리밍 요청에서 토큰 정상 기록 확인, 추론 로그 페이지 필터링·상세 정보 Sheet 동작 확인

관련 커밋: fad3e19 (PR #249, Closes #227)

3. 배포 이벤트 히스토리 DB 저장 및 조회 (#250 → PR #251)

구현 완료: K8s 이벤트 TTL(~1시간) 만료 후에도 배포 이벤트를 조회할 수 있도록 Reconciler 기반 이벤트 수집 및 DB 저장 파이프라인 구현, 모니터링 페이지에 실시간/히스토리 탭 UI 추가

주요 성과:

• Backend:
  • deployment_events 테이블 + 마이그레이션(000024) — fingerprint unique index 기반 중복 제거
  • Reconciler 확장 (syncDeploymentEvents()) — 60초 주기, (cluster, namespace) 그룹핑으로 API 호출 최적화
  • 히스토리 조회 API (GET /api/deployments/:id/events/history) — 페이지네이션, 타입/시간 필터
  • EventCleaner goroutine — 30일 보존 정리 (1시간 주기, 배치 삭제)
• Frontend:
  • 모니터링 페이지 배포 이벤트 섹션에 실시간/히스토리 탭 전환 UI
  • 히스토리 탭: Warning/Normal 필터, 페이지네이션, 경고 카운트/타이머 표시

의사결정 사항:

관련 커밋: 04892d7 (PR #251, Closes #250)

4. 이벤트 히스토리 시간 필터 및 pageSize 조절 UI (#252 → PR #253)

구현 완료: 배포 이벤트 히스토리 탭에 시간 범위 프리셋(1시간/24시간/7일/30일) 및 사용자 지정 시간 필터, pageSize 조절(25/50/100건) UI 추가

수정 내용:

• 시간 범위 프리셋 버튼 및 datetime-local 사용자 지정 입력
• lib/utils/time.ts 유틸리티 분리 — RFC3339 변환 중앙화 (v0.9 글로벌 타임존 설정 연동 대비)
• pageSize 변경 시 page 1로 리셋

관련 커밋: e5163e9 (PR #253, Closes #252)

5. 감사 로그 API 페이지네이션 및 필터 지원 (#241 → PR #248)

구현 완료: 감사 로그 API에 offset 기반 페이지네이션과 다중 필터(action, actor, from, to) 추가, 프론트엔드에 필터 UI 및 페이지 네비게이션 구현

수정 내용:

• Backend: AuditLogFilter 구조체, ListByFilter()/CountByFilter() 추가, 응답에 limit/offset 필드 추가
• Frontend: 필터 바(액션, 실행자, 날짜) + 결과 총계 표시 + 첫/이전/다음/마지막 네비게이션

관련 커밋: 131f868 (PR #248, Closes #241)

6. 감사 로그를 모니터링에서 설정 페이지로 이동 (#240 → PR #242)

구현 완료: 모니터링 페이지(인스턴스 중심)에서 성격이 맞지 않는 감사 로그를 분리하여 관리 영역인 설정 페이지(/settings/audit-logs)로 이동, 아이콘/라벨/색상 매핑 공통 유틸 추출

수정 내용:

• lib/utils/audit-log.ts 공통 유틸 신규 생성 (대시보드 위젯과 설정 뷰어 공유)
• 모니터링 페이지에서 감사 로그 패널 제거, 설정 페이지에 전용 뷰어 추가
• FEATURE_SPEC.md 업데이트 (감사 로그 위치 변경 반영)

관련 커밋: e434843 (PR #242, Closes #240)

인프라 개선 (Infrastructure)

Graceful Shutdown 적용 (#246 → PR #247)

구현 완료: signal.NotifyContext 기반 공유 rootCtx를 생성하여 모든 장기 실행 goroutine(reconciler 3개, inference log writer/cleaner)에 전달, Echo HTTP 서버 graceful shutdown 적용

종료 흐름: SIGINT/SIGTERM → rootCtx 취소 → reconciler 자연 종료 → HTTP 서버 graceful shutdown (10초 timeout) → inference LogWriter drain → 프로세스 종료

관련 커밋: eedcf17 (PR #247, Closes #246)

기타 작업 (Chores)

• 서빙 런타임 표시 순서를 프로덕션 우선순위로 재배치: vLLM → TGI → TEI → llama.cpp → Ollama (5817d74, PR #239, Closes #238)

문서화 (Documentation)

기술 문서 업데이트 (4건)

이전 Iteration 계획 달성도

Iteration 20에서 계획한 4개 항목 2개 완료, 2개 미착수 — 추론 로깅 파이프라인과 추론 테스트 UI 이슈를 종료하고, 나머지 시간은 배포 이벤트 히스토리·감사 로그 개선 등 운영 가시성 강화에 집중:

추가 달성: 계획에 없던 추론 로그 뷰어 UI(#227), 배포 이벤트 히스토리(#250, #252), 감사 로그 설정 페이지 이동(#240) 및 페이지네이션(#241), Graceful shutdown(#246), 런타임 표시 순서 변경(#238) 완료. 로그 통합 인프라(#243)·파티셔닝(#244) 후속 이슈 생성.

미해결 이슈 (Open Issues)

신규 이슈 (2개, 이번 Iteration 생성)

#243은 v1.0 목표로, 추론/Pod/앱 로그를 Loki로 통합하는 장기 과제 #244는 #243 Loki 전환까지 PostgreSQL 부하 완화를 위한 조건부 중간 경로 (실 운영 데이터 기반 판단)

추론 프록시 이슈 체인

추론 로그 확장 경로

런타임 자동 튜닝 선행 조건 이슈 체인

이번 주 통계

결론

이번 주는 추론 프록시 운영 가시성 확보와 플랫폼 운영 도구 고도화에 집중한 기간이었습니다. 추론 요청 로깅 파이프라인(#193)으로 모든 추론 요청의 사용자·배포·토큰·레이턴시를 DB에 기록하고 Prometheus 메트릭으로 노출하는 기반을 마련했으며, 추론 로그 뷰어 UI(#227)와 SSE 스트리밍 토큰 파싱을 통해 실시간 사용 현황을 추적할 수 있게 되었습니다. 배포 이벤트 히스토리(#250)로 K8s 이벤트 TTL 이후에도 장애 원인 추적이 가능해졌고, 감사 로그 설정 페이지 이동(#240) 및 페이지네이션(#241)으로 관리 기능을 체계화했습니다.

핵심 성과:

1. 추론 로깅 파이프라인 완성: 비동기 채널 배치 writer + Prometheus 메트릭 5종 + 30일 보존 — 프록시 레이턴시 무영향 설계
2. 추론 로그 뷰어 + 토큰 파싱: 비스트리밍/SSE 스트리밍 모두 투명 토큰 추출, vLLM·TGI·llama.cpp·Ollama opt-in 자동 주입
3. 배포 이벤트 히스토리: Reconciler 기반 수집 + fingerprint 중복 제거 + 실시간/히스토리 탭 UI
4. 운영 도구 고도화: 감사 로그 설정 이동 + 페이지네이션/필터, Graceful shutdown 전체 적용

다음 주 계획:

• 추론 프록시 Phase 2: 멀티클러스터 라우팅 (agent 터널 통합) (#192)
• 런타임 자동 튜닝 설계 상세화 (#114)
• hmas-agent 핵심 컴포넌트 구현 착수 (#190)
• 추론 API 키 인증 및 Rate Limiting (#194)

문서 작성일: 2026년 5월 10일

• KV Cache Optimization: Serve 10x More Users on the Same GPU (2026) - Spheron Blog
  • LLM 추론 시 긴 컨텍스트에서 발생하는 가장 큰 GPU 메모리 병목인 KV 캐시를 최적화하는 5가지 핵심 기법을 소개합니다.
  • PagedAttention(가상 메모리처럼 필요시 할당), FP8/NVFP4 양자화(메모리 사용량 절감), CPU 오프로딩(트래픽 스파이크 대응), LMCache 및 프리픽스 캐싱(TTFT 단축), GQA/Flash Attention 같은 아키텍처 수준의 최적화 기법들을 다룹니다.
  • 이러한 기법들을 복합적으로 적용하여 동일한 GPU에서 수용 가능한 동시 사용자를 늘리고, 워크로드에 맞게 최적화된 GPU VRAM 예산을 산정할 수 있습니다.
• LLM Inference Optimization: Quantization, KV Cache, and Serving at Scale - Perivitta Rajendran
  • 프로덕션 환경에서 LLM 추론 시 발생하는 메모리 및 연산 병목을 해결하기 위한 최적화 기법들을 심도 있게 다룹니다.
  • 주요 기법으로 가중치와 KV 캐시의 메모리 사용량을 4~8배 줄이는 양자화(GPTQ, AWQ), 처리량을 10~20배 높이는 연속 배치(Continuous Batching), 지연 시간을 2~3배 단축하는 추측 해독(Speculative Decoding)을 설명합니다.
  • 이러한 최적화 기술들이 내장된 vLLM, TGI와 같은 최신 서빙 프레임워크와 Flash Attention, 텐서 병렬 처리(Tensor Parallelism)를 활용한 효율적인 대규모 인퍼런스 구축 방법을 제공합니다.

2026년 4월 26일 - 5월 2일 (Iteration 20)

주요 개발 내용 요약

이번 주는 추론 프록시 Phase 1 구현(#191), 프론트엔드 디자인 시스템 전면 정비(#229→#230→#234→#236), 모델 등록 UX 개선(#223)에 중점을 둔 기간이었습니다. 총 21개의 커밋, 7개의 PR 머지, 8개의 이슈 생성이 완료되었으며, 추론 프록시로 배포된 모델에 단일 통합 엔드포인트를 통한 접근이 가능해졌고, 브랜드 컬러 도입·등록 폼 UX 일관성 확보·제품명 통일 등 프론트엔드 품질을 체계적으로 개선한 주간이었습니다.

새로운 기능 (New Features)

1. 추론 프록시 Phase 1 — 기본 프록시 구현 (Push 모드) (#191 → PR #228)

구현 완료: 배포된 모델에 각 멤버 클러스터의 NodeIP:NodePort를 직접 알 필요 없이 H-MAS 백엔드가 중계하는 단일 통합 엔드포인트(/api/inference/{name}/*)를 통해 추론 요청을 보낼 수 있는 프록시 구현

주요 성과:

• Backend:
  • /api/inference/:name/* 프록시 핸들러 구현 — 배포명 기반 라우팅, SSE 스트리밍 지원, 구조적 로깅 (START/TTFB/DONE)
  • JWT 인증 확장 — 기존 쿠키(hmas_access) 인증에 Authorization: Bearer <token> 지원 추가로 프로그래매틱 접근(curl, SDK) 지원
  • 에러 핸들링 체계화 — deployment 미존재(404), 미실행(503), 엔드포인트 미구성(502), 연결 실패(502), 타임아웃(504) 구분
  • DB 에러 처리 개선 — GetByName에서 DB 장애와 NotFound 명확 분리
• Frontend:
  • 배포 상세 페이지에 프록시 엔드포인트 URL 및 curl 사용 예시 카드 추가

검증 완료: 실제 배포 환경(research 클러스터, Qwen2.5-1.5B-Instruct/vLLM)에서 쿠키·Bearer 인증, 비스트리밍·SSE 스트리밍, 에러 케이스 등 7개 TC 통과

관련 커밋: d1c98b1, 1273e8f, 4edf446, 6a5fcb7 (PR #228, Closes #191)

2. 모델 등록 시 HuggingFace 자동 채움 확대 (#223 → PR #224)

구현 완료: 모델 등록 시 “HuggingFace에서 가져오기” 기능의 자동 채움 범위를 기존 5개 필드에서 8개 필드로 확대하여, 사용자 입력 부담 감소 및 리소스 자동 추천 파이프라인 정상 작동

주요 성과:

관련 커밋: efd1ecd, 81cc3ce, c6720cb, 3f6b56f (PR #224, Closes #223)

3. 디자인 토큰 체계 정립 — 브랜드 컬러 도입 (#230 → PR #233)

구현 완료: H-MAS 고유 브랜드 컬러(쿨 슬레이트 블루) 도입 및 37개 컴포넌트의 하드코딩 컬러를 CSS 변수 기반 디자인 토큰으로 전환하여 향후 화이트라벨링/파트너 브랜딩 대비

주요 성과:

관련 커밋: 235d138, f6f50ee (PR #233, Closes #230)

4. 등록 폼 UX 일관성 확보 — 모달(Dialog) → 드로어(Sheet) 전환

4-1. 클러스터 등록 UI 드로어 전환 (#234 → PR #235)

구현 완료: 클러스터 등록 4단계 위자드를 중앙 모달에서 우측 슬라이드 드로어로 변경하여, 헤더(스텝 인디케이터)·푸터(네비게이션) 고정 배치 및 콘텐츠 독립 스크롤 지원

수정 내용:

• 네비게이션 버튼을 각 Step에서 SheetFooter로 통합
• 스케줄러 선택 카드를 3열 그리드에서 세로 스택 레이아웃으로 변경
• 연결 정보 변경 시 테스트 결과 초기화, 스케줄러 변경 시 사용자 레이블 유지 버그 수정

관련 커밋: b7e6d36 (PR #235, Closes #234)

4-2. 모델 등록/수정 UI 드로어 전환 (#236 → PR #237)

구현 완료: 모델 등록/수정 폼을 중앙 모달에서 우측 슬라이드 드로어로 변경하여, 앱 내 모든 등록 플로우(클러스터, 배치 전략, 리소스 프로파일, 장애복구 정책, 모델)가 동일한 Sheet 패턴을 사용하도록 UX 통일

관련 커밋: 0e1a28c (PR #237, Closes #236)

5. 제품명 H-MAS 통일 및 사이드바 정리 (#229 → PR #232)

구현 완료: 기존 “Serving Platform” 혼용을 “H-MAS”로 통일하여 브랜드 일관성 확보, 사이드바 하단 유저 섹션 제거로 헤더 드롭다운과의 중복 해소

관련 커밋: eee01db (PR #232, Closes #229)

인프라 (Infrastructure)

xxxxxxxxxx xx 코드 리뷰 설정 (#225 → PR #226)

구현 완료: PR 코드 리뷰 품질 향상을 위한 xxxxxxxxxx xx 코드 리뷰 봇 설정 — 한국어 리뷰 출력, 경로별 리뷰 지침(Go 백엔드 에러 핸들링, Next.js 타입 안전성, Helm 보안 등) 구성

관련 커밋: 765759a (PR #226, Closes #225)

문서화 (Documentation)

기술 문서 업데이트 (5건)

이전 Iteration 계획 달성도

Iteration 19에서 계획한 4개 항목 1개 완료, 3개 미착수 — 추론 프록시 Phase 1을 완료하고, 나머지 시간은 디자인 시스템 전면 정비 및 모델 등록 UX 개선에 집중:

추가 달성: 계획에 없던 디자인 토큰 체계 정립(#230), 브랜딩 통일(#229), 등록 폼 UX 일관성 확보(#234, #236), HuggingFace 자동 채움 확대(#223), CodeRabbit 코드 리뷰 도입(#225) 완료. 모델 벤치마크 PRD 작성 및 문서 최신화.

미해결 이슈 (Open Issues)

신규 이슈 (2개, 이번 Iteration 생성)

#231은 #230(디자인 토큰) 완료에 따른 후속 이슈로, v0.9 Technical Preview 이후 대응 예정 #227은 #193(추론 요청 로깅 파이프라인) 완료 후 착수 예정

추론 프록시 이슈 체인

런타임 자동 튜닝 선행 조건 이슈 체인

이번 주 통계

결론

이번 주는 추론 프록시 Phase 1 완성과 프론트엔드 디자인 시스템 전면 정비를 병행한 기간이었습니다. 추론 프록시(#191)로 배포된 모델에 단일 통합 엔드포인트를 통한 접근이 가능해져 외부 SDK·curl에서의 프로그래매틱 추론 호출 기반이 마련되었습니다. 동시에 브랜드 컬러 도입(#230), 제품명 통일(#229), 등록 폼 UX 통일(#234, #236) 등 프론트엔드 품질을 체계적으로 개선하여, 향후 화이트라벨링과 파트너 브랜딩에 대비한 디자인 토큰 기반 아키텍처를 구축했습니다.

핵심 성과:

1. 추론 프록시 Phase 1 완료: 단일 엔드포인트(/api/inference/{name}/*) + JWT Bearer 인증 + SSE 스트리밍 — 실 환경 7개 TC 검증 완료
2. 디자인 시스템 정비: 브랜드 컬러 도입 + 37개 컴포넌트 토큰화 + 등록 폼 5종 Sheet 패턴 통일
3. 모델 등록 UX 개선: HuggingFace 자동 채움 확대로 리소스 자동 추천 파이프라인 정상 작동
4. 개발 프로세스 개선: xxxxxxxxxx xx 코드 리뷰 도입으로 PR 리뷰 품질 향상

다음 주 계획:

• 추론 테스트 UI (Chat 인터페이스) 구현 (#195)
• 추론 요청 로깅 및 메트릭 수집 파이프라인 구현 (#193)
• 런타임 자동 튜닝 설계 상세화 (#114)
• hmas-agent 설계 상세화 (#190)

문서 작성일: 2026년 5월 3일

• GitHub - gauravfs-14/awesome-jepa
  • Yann LeCun과 Meta AI가 제안한 자가지도 학습(Self-supervised learning) 패러다임인 JEPA(Joint Embedding Predictive Architecture) 관련 자료를 모아둔 큐레이션 저장소입니다.
  • 픽셀이나 토큰을 재구성하지 않고 미래의 추상적 표현을 예측하여 학습하는 JEPA의 핵심 개념을 기반으로 한 도구, 라이브러리, 연구 논문, 튜토리얼 등을 종합적으로 제공합니다.
  • 비전, 언어, 의료, 물리, 시계열 등 다양한 도메인에 적용된 최신 연구와 응용 사례들을 꾸준히 업데이트하여 연구자들에게 유용한 지식 허브 역할을 합니다.
• KAME: Tandem Architecture for Enhancing Knowledge in Real-Time Speech-to-Speech Conversational AI
  • 실시간 Speech-to-Speech(S2S) 모델의 빠른 응답성과 백엔드 LLM의 풍부한 지식을 결합한 KAME 아키텍처를 제안했습니다.
  • S2S 모델이 즉각적으로 응답을 시작하는 동시에 백엔드 LLM이 병렬로 실행되며 지식 신호를 비동기적으로 주입하는 “말하면서 생각하기” 패러다임을 구현했습니다.
  • 작업에 따라 백엔드 LLM(gpt-4.1, claude-opus-4-1 등)을 유연하게 교체할 수 있어, 낮은 지연 시간을 유지하면서도 전문적이고 풍부한 응답을 제공합니다.
• Updating 1T parameters in seconds - P2P weight transfer in Large Scale Distributed RL
  • 대규모 분산 RL(강화학습) 환경에서 SGLang을 위한 RDMA 기반의 P2P(Peer-to-Peer) 가중치 업데이트 메커니즘을 도입하여 기존 NCCL 브로드캐스트의 한계를 극복했습니다.
  • 소스 측 CPU 엔진 복제본과 Mooncake TransferEngine을 활용하여 1T 파라미터(Kimi-K2) 모델의 가중치 전송 시간을 53초에서 7.2초로 7배 단축했습니다.
  • 기존의 중앙 집중식 브로드캐스트에서 벗어나 트레이너와 추론 랭크 간의 독립적이고 병렬적인 P2P 매핑 및 Zero-Copy 전송을 구현하여 네트워크 중복을 줄이고 대역폭 활용도를 크게 높였습니다.

AI Daily Picks(20260428)

• What’s new in Foundry Labs - April 2026 - Microsoft Community Hub
  • MAI-Transcribe-1, Voice-1, Image-2: 마이크로소프트의 자체 개발 AI 스택으로, 높은 정확도의 음성 인식/생성 및 텍스트-이미지 생성 모델 공개.
  • Harrier-oss-v1: 94개 언어를 지원하며 지시어 기반(instruction-tuned) 맞춤 설정이 가능한 오픈소스 다국어 텍스트 임베딩 모델(270M, 0.6B, 27B).
  • Phi-4-Reasoning-Vision-15B: 15B의 컴팩트한 크기에도 차트, 수식, GUI 화면 등을 이해하고 구조화된 추론을 할 수 있는 소형 비전 추론 모델.
  • VibeVoice ASR & GigaTIME: 최대 60분 오디오의 다중 화자 음성 인식과 화자 분리를 한 번에 처리하는 VibeVoice ASR, 그리고 저비용 병리 슬라이드를 고해상도 이미지로 변환해 종양 면역 미세환경 분석을 돕는 GigaTIME 모델 소개.

AI Daily Picks(20260427)

• Microsoft Open-Sources Harrier, A New Embedding Blockbuster Model For The Agentic Web
  • 마이크로소프트가 다국어 MTEB v2 벤치마크에서 최고 성능을 달성한 새로운 임베딩 모델 제품군인 Harrier-OSS-v1을 오픈소스로 공개했습니다.
  • 기존 BERT 방식이 아닌 디코더 전용 트랜스포머 아키텍처를 채택하여 최대 32,768 토큰의 긴 문맥을 청킹 없이 네이티브로 처리할 수 있습니다.
  • 27B 플래그십 모델부터 0.6B, 270M 파라미터의 경량 모델까지 제공되며, RAG 시스템 및 다국어 지원 에이전트 구축에 최적화되어 있습니다.

2026년 4월 19일 - 4월 25일 (Iteration 19)

주요 개발 내용 요약

이번 주는 런타임 자동 튜닝(#114)의 선행 조건 이슈 3건 완주 (#125→#126→#128), 클러스터 장애 시 인스턴스 상태 안정성 확보, xxxxxxxxxxx 스케줄러 통합 기술 조사 완료에 중점을 둔 기간이었습니다. 총 12개의 커밋, 7개의 PR 머지, 12개의 이슈 생성이 완료되었으며, 인플레이스 업데이트 API(#125) → Rolling Restart 파이프라인(#126) → 변경 이력 관리(#128) 순서로 파라미터 변경 라이프사이클 전체를 1주일 만에 구축하여 #114 자동 튜닝의 기반 인프라를 마련한 주간이었습니다.

새로운 기능 (New Features)

1. 서빙 배포 인플레이스 업데이트 API — PATCH (#125 → PR #208)

구현 완료: 배포 삭제/재생성 없이 운영 중인 서빙 배포의 최적화 파라미터, 레플리카, 리소스 프로필을 변경할 수 있는 PATCH /api/deployments/:id 엔드포인트 및 프론트엔드 설정 수정 UI 구현

주요 성과:

• Backend:
  • PATCH /api/deployments/:id 엔드포인트 추가 (replicas, optimization, resourceProfileId 변경 지원)
  • xxxxxxx.UpdateServingDeployment() (Get-Modify-Update + 멤버 클러스터 dual-write) 구현
  • UpdateServingOverridePolicy() — 리소스 프로파일 OverridePolicy 생성/교체/삭제 통합
  • GET /api/deployments/:id 응답에 optimization 필드 추가 (기존 설정 표시용)
  • Swagger 문서 재생성
• Frontend:
  • Sheet(드로어) 기반 설정 수정 UI — 기존 OptimizationCard 재사용으로 프리셋/Tier 1·2/Raw Override 구조화 입력
  • 기존 설정 초기값 로드, 변경 diff 미리보기, 재시작 경고 제공
  • 인스턴스 상세 페이지에 “설정 수정” 버튼 (running/pending 상태에서 표시)

의사결정 사항:

관련 커밋: 059a7da, 5d85a21 (PR #208, Closes #125)

2. 서빙 배포 Rolling Restart 파이프라인 (#126 → PR #221)

구현 완료: 배포 파라미터 변경 시 안전한 롤아웃과 실패 시 자동 롤백을 수행하는 Rolling Restart 파이프라인 구현 — Dry-run 사전 분석, 롤아웃 상태 추적, CrashLoopBackOff/OOMKilled 감지 시 자동 복원

주요 성과:

• Backend:
  • Dry-run API (?dryRun=true): 변경 적용 전 재시작 필요 여부, 전략(RollingUpdate/Recreate), 예상 영향도 사전 분석
  • deployment_rollouts 테이블 (migration #21): 롤아웃 상태 추적 및 이전 설정 스냅샷 저장
  • RolloutReconciler: 10초 간격 활성 롤아웃 모니터링, 런타임별 startup grace period 적용 (Recreate 3분 / RollingUpdate 90초)
  • 자동 롤백: CrashLoopBackOff·OOMKilled·ProgressDeadlineExceeded 감지 시 이전 설정으로 자동 복원
  • 롤아웃 상태 조회, 이력 조회, 수동 롤백 엔드포인트 추가
• Frontend:
  • 설정 수정 다이얼로그에 dry-run 분석 결과 (전략, 영향도) 표시
  • 롤아웃 상태 배너: 실시간 진행률 표시 + 수동 롤백 버튼
  • 롤아웃 이력 목록 (collapsible)

해결된 기술 문제:

관련 커밋: 8c3c584 (PR #221, Closes #126)

3. 서빙 최적화 파라미터 변경 이력 관리 및 감사 로그 (#128 → PR #222)

구현 완료: 배포 최적화 파라미터 변경 시 변경 전/후 config, 변경 원인(manual/preset/auto_tuning/rollback), 적용 결과를 자동 기록하는 이력 관리 시스템 및 프론트엔드 통합 변경 이력 패널 구현

주요 성과:

• Backend:
  • deployment_config_history 테이블 신규 생성 (마이그레이션 #22), rollout_id FK로 롤아웃과 하이브리드 연결
  • config-history 조회(목록/상세), 특정 시점 롤백 API 3개 엔드포인트 추가

  엔드포인트	설명
  GET /api/deployments/:id/config-history	변경 이력 목록 (페이지네이션)
  GET /api/deployments/:id/config-history/:historyId	변경 상세 (전/후 diff)
  POST /api/deployments/:id/config-history/:historyId/rollback	특정 시점으로 롤백

• Frontend:
  • 통합 변경 이력 패널: 롤아웃 상태 인라인 표시, JSON diff 뷰, 롤백 버튼
  • 기존 롤아웃 이력 섹션을 통합 패널로 흡수하여 중복 UI 제거 (활성 롤아웃 배너는 유지)

의사결정 사항:

관련 커밋: e223e85 (PR #222, Closes #128)

4. URL 경로 /logs → /monitoring 변경 (#204 → PR #205)

구현 완료: 사이드바 메뉴명 “모니터링”과 URL 경로(/logs) 불일치를 해소하여 Next.js 라우트 디렉토리를 monitoring으로 이동하고, 사이드바·내부 네비게이션·인스턴스 상세 페이지·데모 시나리오의 경로 참조를 일괄 변경

관련 커밋: e2c9963 (PR #205, Closes #204)

버그 수정 (Bug Fixes)

1. 클러스터 종료 시 인스턴스 상세/모니터링 페이지 무한 로딩 (#209 → PR #211)

수정 완료: 멤버 클러스터 종료 시 인스턴스 상세 페이지와 모니터링 페이지가 무한 로딩에 빠지는 문제를 해결하여, 클러스터 미도달 시에도 DB 기반 정보를 정상 표시하고 사용자 친화적 안내 UI 제공

수정 내용:

• Backend: xxxxxxx/멤버 클러스터 조회를 병렬 실행 + 개별 5초 timeout 적용, 실패 시 DB fallback 응답 반환 (statusSource: "cached")
• Frontend: fetchWithAuth AbortController 타임아웃 추가, statusSource === "cached" 시 amber 배너로 “마지막 저장된 상태” 안내, 모니터링 페이지 클러스터 연결 불가 안내 UI (내부 K8s 에러 미노출)

관련 커밋: 40dc15a (PR #211, Closes #209)

2. 클러스터 종료 후 인스턴스 stale status 해결 (#210 → PR #212)

수정 완료: 클러스터 종료 후에도 인스턴스가 “실행 중”으로 표시되는 stale status 문제를 다층 방어(defense-in-depth)로 해결, 목록 API 응답 시간을 10초 → 0.03초로 대폭 개선

수정 내용:

• Backend — API 핸들러: 클러스터 readiness 사전 확인 → not-ready 클러스터 배포는 즉시 unknown/cached 반환, 순차 → 병렬 enrichment + 목록 전용 타임아웃(2초) 도입
• Backend — Reconciler: 연속 3회 API 실패 시 DB LastKnownStatus를 "unknown"으로 갱신, not-ready 클러스터 인스턴스 일괄 "unknown" 갱신 (60초 주기)
• Backend — Repository: BulkUpdateStatusByCluster, ListActiveByCluster 신규 메서드 추가
• Frontend: statusSource="cached" 시 WifiOff 아이콘 + 툴팁, 대시보드 파이차트에 "unknown" 별도 카테고리(회색) 분리, unhealthy 배너에 unknown 포함

관련 커밋: 8e223a7 (PR #212, Closes #210)

문서화 (Documentation)

1. xxxxxxxxxxx 스케줄러 통합 기술 조사 및 설계 (#179 → PR #220)

작성 완료: xxxxxxxxxxx 스케줄러 도입을 위한 기초 기술 조사 및 H-MAS 통합 설계 문서 4건 작성 — 멀티클러스터 이기종 스케줄러 환경 설계, 기능 계층 분류, GPU 공유/격리 방식 비교, Compute Plane GP Profile 설계를 포괄

조사 범위:

생성된 후속 이슈:

• #216 — xxxxxxxxxxx 실 클러스터 설치 및 환경 검증
• #217 — QoS/오버커밋 동작 검증
• #218 — 멀티 GPU 추론 (Gang Scheduling + 토폴로지) 검증
• #219 — H-MAS xxxxxxxxxxx 통합 구현

2. 기타 문서

기타 작업 (Chores)

• 기술 스택 전체 버전 핀닝 (c716bb5)

이전 Iteration 계획 달성도

Iteration 18에서 계획한 4개 항목 1개 완료, 3개 미착수 — 인플레이스 업데이트(#125)를 기점으로 Rolling Restart(#126)→변경 이력(#128) 선행 조건 체인 완주 및 클러스터 장애 안정성 확보에 집중:

추가 달성: 계획에 없던 Rolling Restart 파이프라인(#126), 변경 이력 관리(#128) 구현으로 #114 자동 튜닝의 선행 조건 3/4 완료. 클러스터 장애 시 stale status(#210) 및 무한 로딩(#209) 버그 수정. xxxxxxxxxxx 기술 조사(#179) 완료 및 후속 검증 이슈 4건 + 리서치 이슈 3건 생성으로 v0.9 GP 클러스터 Phase 준비.

미해결 이슈 (Open Issues)

신규 이슈 (12개, 이번 Iteration 생성)

#216→#217→#218→#219는 #179(xxxxxxxxxxx 리서치)의 후속 검증/구현 이슈 체인으로, 이번 iteration에 기술 조사 문서를 기반으로 분해 #213→#214→#215는 xxxxxxxxxxx 통합 과정에서 파생된 SaaS/GP 관련 리서치 이슈

런타임 자동 튜닝 선행 조건 이슈 체인

추론 프록시 이슈 체인 (4개, 미착수)

기타 미해결 이슈

이번 주 통계

결론

이번 주는 런타임 자동 튜닝(#114)의 선행 조건 이슈 3건(#125→#126→#128)을 순차 완주하여 파라미터 변경 라이프사이클 전체를 구축한 기간이었습니다. 인플레이스 업데이트 API(#125)로 운영 중 배포 파라미터 변경이 가능해졌고, Rolling Restart 파이프라인(#126)으로 CrashLoopBackOff/OOMKilled 감지 시 자동 롤백이 적용되며, 변경 이력 관리(#128)로 모든 설정 변경이 감사 로그로 기록됩니다. 이로써 Iteration 18에서 완료한 메트릭 수집(#127)과 합쳐 #114 자동 튜닝의 선행 조건 4/4가 모두 충족되었습니다.

클러스터 장애 대응에서는 stale status(#210)와 무한 로딩(#209) 문제를 다층 방어로 해결하여, 목록 API 응답 시간을 10초에서 0.03초로 개선하고 클러스터 미도달 시에도 DB 기반 정보를 안정적으로 제공하게 되었습니다.

xxxxxxxxxxx 스케줄러 기술 조사(#179)를 완료하고 후속 검증 이슈 4건(#216~#219)과 SaaS 관련 리서치 3건(#213~#215)을 생성하여, 6월 GP 서빙 엔진 Phase 진입을 위한 로드맵을 구체화했습니다.

핵심 성과:

1. 파라미터 변경 라이프사이클 완주: #125(PATCH API) → #126(Rolling Restart + 자동 롤백) → #128(변경 이력 + 감사 로그) — #114 자동 튜닝 선행 조건 4/4 완료
2. 클러스터 장애 안정성 확보: stale status 다층 방어 + 무한 로딩 해결 — 목록 API 10초 → 0.03초 개선
3. xxxxxxxxxxx 기술 조사 완료: 4건 리서치 문서 + 후속 검증/구현 이슈 4건 생성 — GP 클러스터 Phase 준비
4. SaaS 로드맵 구체화: GPU 공유/격리 비교(#213), 멀티테넌트 거버넌스(#214), 과금/미터링(#215) 리서치 이슈 생성

다음 주 계획:

• 추론 프록시 Phase 1 구현 착수 (#191) — Push 모드 기본 프록시
• 추론 테스트 UI (Chat 인터페이스) 구현 (#195)
• 런타임 자동 튜닝 설계 상세화 (#114) — 선행 조건 완료에 따른 착수
• h-mas-agent 설계 상세화 (#190)

문서 작성일: 2026년 4월 26일

• Production-Grade LLM Inference at Scale with KServe, llm-d, and vLLM
  • 수백 개의 대형 언어 모델(LLM)을 스케일링하고 관리하는 과정에서 기존 vLLM의 단순 배포 방식이 가진 스토리지 지연, 인프라 종속성, 비효율적 로드 밸런싱 문제를 KServe, llm-d, vLLM 조합으로 해결한 사례를 공유합니다.
  • KServe의 LLMInferenceService를 통해 표준 Kubernetes API 수준에서 vLLM 설정을 정밀하게 커스터마이징하여 하드웨어 특성에 맞는 유연한 배포를 가능하게 했습니다.
  • Envoy 및 Gateway API Inference Extension을 활용한 접두어 캐시 인식 라우팅(prefix-cache aware routing)을 적용하여 GPU 효율성을 극대화했으며, 실제 Llama 3.1 70B 모델 배포에서 출력 토큰 생성 속도를 3배, 첫 토큰 응답 시간(TTFT)을 절반으로 단축하는 성과를 얻었습니다.
• Microsoft Open-Sources Embedding Models to Improve AI Data Retrieval
  • 마이크로소프트가 단순한 키워드 매칭을 넘어 의미론적 연관성을 파악해 검색, 추천 및 데이터 검색 시스템의 기반을 이루는 새로운 AI 임베딩 모델 제품군(Harrier)을 오픈소스로 공개했습니다.
  • 엔터프라이즈 AI가 실험 단계에서 실제 운영 환경으로 전환됨에 따라, 생성된 결과물의 정교함보다 검증된 실제 데이터에 기반하여 환각(오류)을 줄이고 신뢰성을 높이는 검색 증강 생성(RAG) 및 에이전트 시스템의 중요성이 커지고 있습니다.
  • 100개 이상의 언어를 지원하고 다양한 환경에서 구동 가능한 이 고성능 임베딩 모델의 오픈소스화는, 개발자들이 폭넓은 애플리케이션에 이를 쉽게 통합할 수 있게 함으로써 기업의 내부 검색 도구 강화 및 AI 어시스턴트 성능 향상에 실질적으로 기여할 것으로 기대됩니다.

AI Daily Picks(20260422)

• From Models to Scientists: Building AI Agents for Scientific Discovery - Kempner Institute
  • 하버드 Kempner Institute에서 개발한 ToolUniverse는 대규모 언어 모델(LLM)이 600개 이상의 과학 도구(머신러닝 모델, DB, 시뮬레이터 등)를 활용해 연구를 기획하고 수행할 수 있게 해주는 AI 과학자 에이전트 구축 프레임워크입니다.
  • 4가지 핵심 컴포넌트(Manager, Composer, Discover, Optimizer)를 제공하여, 단순한 도구 호출(MCP)을 넘어 다단계 과학적 추론과 워크플로우를 실행하고 새로운 도구를 자율적으로 생성 및 최적화할 수 있도록 지원합니다.
  • 실제 사례로 AI 에이전트가 단백질 타겟 탐색부터 화합물 식별, 구조 최적화 및 특허 검증에 이르는 약물 발견의 전 과정을 시뮬레이션하여 인간 연구자의 강력한 협력자(Co-scientist)로 활용될 수 있음을 보여주었습니다.

AI Daily Picks(20260421)

• Microsoft’s Harrier Embeds 32K Tokens at Once - AI Beat
  • 최대 32,768 토큰(기존 대비 30~60배)의 컨텍스트 윈도우를 지원하는 디코더 전용 다국어 임베딩 모델 제품군(Harrier-OSS-v1: 270M, 0.6B, 27B)이 MIT 라이선스로 오픈소스 공개되었습니다.
  • 27B 모델은 다국어 MTEB v2 벤치마크에서 74.3점으로 최고 성능(SOTA)을 달성했으며, 문서를 청킹하지 않고 전체 논문이나 계약서를 한 번에 임베딩할 수 있어 RAG(검색 증강 생성) 시스템의 설계에 변화를 줄 수 있습니다.
  • 디코더 전용 구조(마지막 토큰 풀링 방식)를 채택하여 강력한 성능을 발휘하지만, 양방향 인코더 방식에 비해 추론 비용(Inference cost)이 증가한다는 단점이 있으며 27B 모델은 전용 GPU 인프라를 요구합니다.
• AI agents, tech circularity: What’s ahead for platforms in 2026 - MIT Sloan
  • 플랫폼 시장 환경은 자율적인 AI 에이전트의 등장에 대비해 에이전트 전용 인터페이스와 통제 규칙을 마련하는 방향으로 변화하고 있습니다.
  • 생성형 AI의 활발한 도입은 코딩 생산성을 높였으나 최신 시스템에서는 관리가 어려운 불완전한 코드가 축적되는 “기술 부채 폭증(turbocharged technical debt)” 리스크를 발생시키고 있습니다.
  • AI 스택의 소수 빅테크 의존 심화 문제에 대응하기 위해 신중한 AI 툴 도입이 필요하며, 나아가 디지털 플랫폼 전략이 하드웨어 재활용 및 재판매를 통한 순환 경제(circular economy) 영역까지 확장되고 있습니다.
• TurboQuant KV Cache Compression: What Changes for LLM Inference
  • 별도의 재학습 없이(training-free) LLM의 KV 캐시 메모리 사용량을 최대 6배 줄여주는 구글의 압축 기술 ‘TurboQuant’를 분석한 글로, 장문 컨텍스트 추론의 핵심 병목인 VRAM 한계를 획기적으로 극복할 수 있습니다.
  • 극심한 비대칭성 문제를 지닌 캐시 값 분포를 ‘PolarQuant’ 단계의 직교 회전(Orthogonal rotation)으로 균일화하여 양자화 효율을 극대화하며, 실제 구현 시에는 논문상의 QJL 잔차 교정 대신 보편적인 MSE 전용 양자화(MSE-only quantization)를 사용하는 것이 성능 면에서 우수한 것으로 입증되었습니다.
  • 기존 파라미터 양자화(AWQ 등)와 동시 적용이 가능한 상호보완적 기술로서, 향후 프레임워크 지원이 완료되면 다중 접속 및 장문 입력이 필요한 에이전트/RAG 기반 기업용 AI 환경의 인프라 효율성을 극대화할 것입니다.
• • LLM 텍스트 생성 시 이전 토큰에 대한 중복 연산을 방지해주는 ‘KV Cache(Key-Value Cache)’ 메커니즘의 원리를 설명한 상세 가이드입니다.
  • 계산 속도를 O(1) 수준으로 높이는 대신 GPU의 VRAM 메모리 소모가 컨텍스트 길이에 비례해 선형적으로 증가하며, 결국 메모리 관리(Memory bottleneck)가 실제 운영 및 배포 단계에서 가장 중요한 과제가 됨을 강조합니다.
  • 메모리 한계 부딪힘을 극복하기 위한 대표적 최적화 기술로 PagedAttention(메모리 파편화 방지), GQA(멀티 쿼리 헤드의 KV 헤드 공유), KV Cache Quantization(데이터 정밀도 축소) 등을 소개하고 활용을 권장합니다.
• Microsoft Harrier Disrupts the AI Landscape Dethroning Proprietary Embedding Models — ML Hive
  • 마이크로소프트가 상용 임베딩 모델(OpenAI, Google)의 성능을 능가하는 최대 27B 파라미터 규모의 다국어 오픈소스 임베딩 모델군 ‘Harrier’를 공개하여 기업용 RAG 구조의 혁신을 주도하고 있습니다.
  • 초거대 파라미터를 기반으로 단어 구분의 혼동(Semantic crowding) 문제를 해결함으로써 컨텍스트의 미세한 차이를 예리하게 분별해내며, 번역 과정 없이도 100개 이상의 언어를 동일한 다국어 벡터 공간으로 일관성 있게 맵핑할 수 있습니다.
  • 최상위 성능의 모델을 오픈소스로 무료 공개한 것은 검색 시스템 구축 문턱을 허물고 엔터프라이즈 AI 애플리케이션의 확산시키며, 나아가 이와 맞물린 마이크로소프트 자체 클라우드(Azure) 인프라 수요를 촉진하기 위한 전략적 선택(“commoditizing your complement”)으로 평가됩니다.

2026년 4월 12일 - 4월 18일 (Iteration 18)

주요 개발 내용 요약

이번 주는 서빙 런타임 메트릭 수집 파이프라인 전체 구현, 배포 일시정지/재시작 기능, 브랜치 전략 및 릴리즈 프로세스 문서화에 중점을 둔 기간이었습니다. 총 23개의 커밋, 6개의 PR 머지, 9개의 이슈 생성이 완료되었으며, #127(메트릭 수집 파이프라인)의 3개 서브이슈(인프라→Backend API→Frontend)를 1주일 만에 순차 완주하여 목 데이터 기반 대시보드를 Prometheus 실데이터로 전면 전환한 주간이었습니다.

새로운 기능 (New Features)

1. 서빙 배포 일시정지/재시작 (Pause & Resume) (#185 → PR #189)

구현 완료: 서빙 배포의 일시정지(Pause) 및 재시작(Resume) 기능을 xxxxxxx Dual-Update 패턴으로 구현하여, 멤버 클러스터 Pod를 종료/재생성하면서 xxxxxxx 전파 지연 문제를 해결

주요 성과:

• Backend:
  • POST /api/deployments/:id/pause, POST /api/deployments/:id/resume 엔드포인트 추가
  • xxxxxxx Dual-Update: xxxxxxx API Server + 멤버 클러스터 직접 변경을 동시에 수행하여 전파 지연 문제 해결 (#100 패턴 적용)
  • ScaleServingDeployment(), CheckMemberDeploymentRunning(), IsServingDeploymentPaused() xxxxxxx 클라이언트 함수 추가
  • Resume 후 xxxxxxx가 pending으로 보고할 때 멤버 클러스터를 직접 조회하여 running 상태로 보정
  • Reconciler에 paused 상태 교차 검증 (DB ↔ K8s annotation) 및 외부 변경 감지 로직 추가
• Frontend:
  • 인스턴스 목록 드롭다운 메뉴에 일시정지/재시작 액션 추가
  • 인스턴스 상세 페이지 일시정지/재시작 버튼
  • 대시보드 파이 차트에 paused 카운트 반영
  • deployment-status.ts에 paused 배지 스타일 추가
• Docs:
  • xxxxxxx_STATE_MANAGEMENT.md: xxxxxxx 상태 관리 패턴 아키텍처 문서 (Dual-Update, Direct Status Verification, Cross-Validation)

의사결정 사항:

관련 커밋: 05eaf73 (PR #189, Closes #185)

2. 모니터링 인프라 구축 — Prometheus + DCGM Exporter 배포 (#196 → PR #199)

구현 완료: Control Plane에 Prometheus Server를 Helm subchart로 배포하고, 멤버 클러스터에 Prometheus Agent/DCGM Exporter/Node Exporter를 배포하여 멀티클러스터 메트릭 수집 파이프라인의 기반 인프라를 구축

주요 성과:

• Helm Chart:
  • charts/h-mas/Chart.yaml에 Prometheus subchart dependency 추가 (condition: prometheus.enabled)
  • values.yaml: 프로덕션 기본값 (retention 15d, PV 50Gi, remote-write-receiver, servicePort 9090)
  • values-dev.yaml: 개발환경 오버라이드 (retention 3d, PV 비활성화, NodePort 30090)
• Backend:
  • PROMETHEUS_URL 환경변수 주입 (Backend Deployment 템플릿)
  • CreateServingDeployment()에 Prometheus scrape annotation 자동 추가 (prometheus.io/scrape, /port, /path)
• 멤버 클러스터:
  • charts/prometheus-agent-values.yaml: Prometheus 3.x Agent 모드 (--agent 플래그), Node Exporter 포함
  • Makefile: deploy-prometheus-agent, deploy-dcgm, undeploy-monitoring 타겟 추가
  • deploy-dcgm annotation 타입 버그 수정 (--set → --set-string)
• Docs:
  • MONITORING_ARCHITECTURE.md, MONITORING_SETUP_GUIDE.md 업데이트

검증 결과 (xxxstack + research 클러스터 — RTX 5060 Ti):

관련 커밋: a53e1d6, 2def76c, 15289a1, 6d43c59, 4f1225f, b4558dc (PR #199, Closes #196)

3. Backend 메트릭 조회 API 구현 — PromQL 연동 (#197 → PR #200)

구현 완료: Prometheus HTTP API 클라이언트를 통한 서빙 런타임/GPU 메트릭 조회 REST API를 구현하고, 런타임별(vLLM, TGI, llama.cpp) 메트릭 이름을 통합 메트릭으로 정규화

주요 성과:

• Backend (신규 파일 6개):
  • internal/metrics/client.go: Prometheus HTTP API 래퍼 (InstantQuery, RangeQuery)
  • internal/metrics/queries.go: 런타임별 PromQL 매핑 + 통합 메트릭 정의
  • internal/metrics/service.go: 비즈니스 로직 (DB 조회 → PromQL 구성 → 정규화)
  • internal/metrics/middleware.go: Echo 미들웨어 (HTTP 메트릭 수집) + /metrics 핸들러
  • internal/handler/metrics.go: API 핸들러 + Swagger 주석
  • internal/model/metrics.go: API 응답 구조체

• API 엔드포인트:

  엔드포인트	설명
  GET /api/deployments/:id/metrics	배포별 실시간 메트릭 스냅샷
  GET /api/deployments/:id/metrics/history	시계열 메트릭 이력
  GET /api/clusters/:name/gpu-metrics	클러스터별 GPU 메트릭 요약
  GET /metrics	Backend 자체 Prometheus exposition

• Docs:
  • PROMETHEUS_RECORDING_RULES_DESIGN.md: v1.0 이후 메트릭 쿼리 최적화를 위한 Recording Rules 설계

의사결정 사항:

관련 커밋: a96b2f5, b0bc9ea, 675e060 (PR #200, Closes #197)

4. 프론트엔드 모니터링 실데이터 연동 및 대시보드 개선 (#198 → PR #201)

구현 완료: SWR 기반 실시간 폴링으로 배포별 13개 메트릭 지표를 게이지 및 시계열 차트로 표시하고, 대시보드에 서빙 성능 요약 카드·비정상 인스턴스 경고 배너·클러스터 GPU 상태 도트 히트맵을 추가

주요 성과:

• Frontend (신규 파일 13개):
  • lib/api/metrics.ts: 메트릭 API 클라이언트 + TypeScript 타입
  • lib/hooks/use-deployment-metrics.ts: 배포별 메트릭 SWR 훅
  • lib/hooks/use-cluster-gpu-metrics.ts: 클러스터 GPU 메트릭 SWR 훅
  • lib/hooks/use-dashboard-metrics.ts: 대시보드 GPU 사용률 + 클러스터별 GPU 상세 훅
  • lib/hooks/use-aggregated-metrics.ts: running 배포 메트릭 집계 훅
  • components/metrics/deployment-metrics-panel.tsx: 게이지 + 시계열 차트 통합 패널
  • components/metrics/metric-gauge.tsx: 개별 메트릭 게이지 컴포넌트
  • components/metrics/metrics-time-series-chart.tsx: Recharts 시계열 차트
  • components/metrics/metrics-status-bar.tsx: 인스턴스 상세용 컴팩트 메트릭 바
  • components/metrics/cluster-gpu-metrics-panel.tsx: 클러스터 GPU 패널
  • components/metrics/monitoring-not-configured.tsx: Prometheus 미설정 폴백 UI
  • components/dashboard/serving-performance-summary.tsx: 서빙 성능 요약 카드
  • components/dashboard/unhealthy-instances-banner.tsx: 비정상 인스턴스 배너
• 대시보드 개선:
  • StatsCards: GPU 실사용률 (Prometheus 연결 시) / GPU 할당률 (미연결 시) 자동 전환
  • ServingPerformanceSummary: 총 RPS, 총 TPS, 평균 TTFT, 활성 요청, 최대 KV Cache, 평균 GPU 온도
  • ClusterOverview: 클러스터별 GPU 온도 점 표시
  • 사이드바 메뉴명 “로그” → “모니터링” 변경
• 모니터링 페이지:
  • 풀 메트릭 패널 + Pod 로그/이벤트 사이드바 통합 레이아웃
  • 인스턴스 상세 페이지에 컴팩트 MetricsStatusBar 배치
  • SWR polling: 스냅샷 10초, 히스토리 60초, 대시보드 GPU 30초, 집계 메트릭 15초

관련 커밋: 2589b9b (PR #201, Closes #198)

5. Latency p95/p99 분할 표시 및 Ollama 런타임 미지원 안내 (#133 → PR #202)

구현 완료: TTFT, E2E Latency, ITL에 대해 p95/p99 퍼센타일 분할 표시를 추가하고, Ollama 런타임의 추론 메트릭 미지원 안내 UI를 구현하여 #133 대시보드 메트릭 이슈를 완료

주요 성과:

• Backend:
  • queries.go에 p95/p99 PromQL histogram_quantile 쿼리 추가 (vLLM 전체, TGI는 TTFT만)
  • MetricsSnapshot 모델에 6개 필드 추가 (ttftP95, ttftP99, e2eLatencyP95, e2eLatencyP99, itlP95, itlP99)
  • runtimeQueries에 "ollama" 엔트리 추가 — GPU 메트릭만 포함
• Frontend:
  • MetricGauge에 percentiles prop 추가 — 게이지 하단에 p95/p99 서브텍스트 + 임계값 초과 시 색상 강조
  • 시계열 차트에 E2E Latency p95(긴 점선), p99(짧은 점선) 라인 추가
  • Ollama 배포 선택 시 추론 메트릭 영역을 안내 메시지로 교체 (GPU 메트릭은 정상 표시)

버그 수정 (실 환경 테스트 중 발견):

관련 커밋: 903106c, 01f1a9d, 6ee1328, 8e45905 (PR #202, Closes #133)

문서화 (Documentation)

1. 브랜치 전략 및 릴리즈/배포 프로세스 정립 (#166 → PR #203)

작성 완료: 노션 정리 내용 + 이슈 검토 항목 + 기존 프로젝트 문서를 종합 분석하여 H-MAS 프로젝트 맞춤 전략 수립

문서 구성 (14개 섹션):

1. 배경 — 현재 전략 vs v0.9 변화 요인, 브랜치 모델 비교 및 채택 근거
2. 브랜치 정책 — 상시 브랜치(dev/stg/prd) + 임시 브랜치, 네이밍 규칙, 보호 규칙
3. 개발-배포 흐름 — 평소 개발 → 릴리즈 준비 → 운영 배포 → 긴급 대응 다이어그램
4. 버전 정책 — SemVer, dev.N / rc.N 표기, VERSION 파일 운영
5. 릴리즈 프로세스 — 체크리스트 템플릿, 릴리즈 노트 규칙
6. 배포 전략 — 파트너별 Helm values, 업그레이드/롤백, DB migration 원칙
7. CI/CD 확장 — 현재(v0.4) → 목표(v0.9) 워크플로, main→dev 전환 계획
8. 버전 지원 정책 — EOL 기준, 구버전 예외 패치 절차
9. 라이센스와 버전 지원 — 연간 라이센스-지원 범위 관계
10. Feature Flag 운영 — 환경별 flag 정책, 관리 규칙
11. 커밋/PR 규칙 — Conventional Commits, PR 컨벤션
12. 장애 대응 체크리스트 — 1차 확인 → 즉시 조치 → 수정/배포 흐름
13. 도입 시점 판단 기준 — 즉시 / 파트너 2곳+ / 팀원 2명+ 단계별 도입
14. 운영 원칙 요약 — 핵심 규칙 한눈에 보기

2. 아키텍처/설계 문서

3. 기존 문서 최신화

리팩토링 (Refactoring)

1. GP 클러스터 타입 표시명 변경

• GP 클러스터 타입 표시명 "General" → "General Performance" 일괄 변경
• 관련 커밋: 16e8d49

이전 Iteration 계획 달성도

Iteration 17에서 계획한 4개 항목 1개 완료, 1개 부분 달성, 2개 미착수 — 모니터링 파이프라인(#127 → #196/#197/#198) 전체 구축 및 Pause/Resume(#185) 구현에 집중:

추가 달성: 계획에 없던 모니터링 파이프라인 전체 구축(#127의 서브이슈 #196→#197→#198 순차 완주), 대시보드 Latency p95/p99 + Ollama 안내(#133 완료), 브랜치/릴리즈 전략 문서(#166 완료), v0.9 구현 계획 문서, 아키텍처 설계 문서 3건, h-mas-agent 이슈(#190) 생성. 목 데이터 기반이던 대시보드를 Prometheus 실데이터 기반으로 전면 전환하여 운영 가시성을 확보.

미해결 이슈 (Open Issues)

신규 이슈 (9개, 이번 Iteration 생성)

#191→#192→#193→#194는 #36(추론 API 프록시)의 단계별 구현 이슈 체인으로, 이번 iteration에 INFERENCE_PROXY_DESIGN.md 설계 문서를 기반으로 분해

런타임 자동 튜닝 관련 선행 조건 이슈 체인 (5개)

프리셋 확장 이슈 (3개)

대시보드 v0.9 이슈 (1개)

#133(대시보드 실시간 GPU 사용률 및 추론 메트릭)은 이번 iteration PR #202로 완료

리서치 이슈 (4개, Iteration 17에서 생성)

기존 미해결 이슈 (이전 Iteration에서 이관)

1. 스케줄러 어노테이션 변환 (xxx/xxxxxxxxxxx → xxxxxxx OverridePolicy) (#66)

• #179 xxxxxxxxxxx 리서치 이슈와 연계하여 검토 예정

2. 모델 프리셋 리스트 최신화 (#62)

• 잔여 작업: 최신 모델 시드 데이터 추가 필요

3. Failover / 재배치 정책 구현 (#39) — v0.95 마일스톤

4. NUMA / 토폴로지 인식 스케줄링 구현 (#38) — v0.95 마일스톤

5. 추론 API 프록시 구현 — 통합 엔드포인트 (#36)

• 설계 문서 완료, Phase 1~4 이슈(#191~#194)로 분해 완료, Phase 1 구현 착수 예정

이번 주 통계

결론

이번 주는 서빙 런타임 메트릭 수집 파이프라인(#127)을 인프라→Backend→Frontend 3단계로 1주일 만에 완주하여 운영 모니터링 가시성을 확보한 기간이었습니다. Prometheus Server/Agent/DCGM Exporter 기반 멀티클러스터 메트릭 인프라(#196)를 구축하고, PromQL 연동 Backend API(#197)로 런타임별 메트릭을 정규화하며, 13개 신규 프론트엔드 컴포넌트(#198)로 목 데이터를 실데이터로 전면 교체했습니다.

배포 일시정지/재시작(#185)에서는 xxxxxxx Dual-Update 패턴을 적용하여 전파 지연 문제를 해결했고, 이를 xxxxxxx_STATE_MANAGEMENT.md 패턴 문서로 정리하여 향후 유사 기능 구현의 참조 아키텍처를 마련했습니다. Latency p95/p99 분할 표시 및 Ollama 런타임 안내(#133)로 대시보드 메트릭 이슈를 마무리하고, 브랜치/릴리즈 전략 문서(#166)로 장기 미해결 운영 이슈를 클로즈했습니다.

추론 API 프록시(#36)는 설계 문서와 4단계 구현 이슈로 분해하여 Phase 1 착수를 준비했고, h-mas-agent(#190) 이슈를 생성하여 Pull 모드 클러스터 지원의 기반을 마련했습니다.

핵심 성과:

1. 메트릭 수집 파이프라인 완주: #127(상위 이슈) + 3개 서브이슈(#196→#197→#198) — Prometheus 인프라, Backend PromQL API, Frontend 13개 컴포넌트
2. 대시보드 Latency p95/p99: 게이지 퍼센타일 분할 + 시계열 점선 + Ollama 안내 — #133 완료
3. 배포 일시정지/재시작: xxxxxxx Dual-Update + Reconciler 교차 검증 — #185 완료
4. 브랜치/릴리즈 전략: 14개 섹션, 3-브랜치 모델 + SemVer + 장애 대응 체크리스트 — #166 완료
5. 추론 프록시 설계: INFERENCE_PROXY_DESIGN.md + Phase 1~4 이슈 분해 — #36 착수 준비 완료
6. v0.9 방향 구체화: 구현 계획 문서, 아키텍처 설계 문서 3건, h-mas-agent 이슈 생성

다음 주 계획:

• 추론 프록시 Phase 1 구현 착수 (#191) — Push 모드 기본 프록시
• 서빙 배포 인플레이스 업데이트 API (PATCH) 구현 (#125)
• 추론 테스트 UI (Chat 인터페이스) 구현 (#195)
• h-mas-agent 설계 상세화 (#190)

문서 작성일: 2026년 4월 19일

• KV-Cache Wins You Can See: From Prefix Caching in vLLM to Distributed Scheduling with llm-d
  • LLM inference 환경에서 KV-Cache hit rate은 성능(지연 시간)과 비용(최대 10배 차이)에 직결되는 핵심 지표이며 대화형 AI나 에이전트 워크플로우같이 접두사(Prefix)가 긴 패턴에서 그 중요성이 더욱 부각됨.
  • 단일 인스턴스의 vLLM 캐싱 효과는 분산 환경 로드밸런싱 과정에서 무력화되기 쉬우나, llm-d는 vLLM 포드들의 KVEvents를 통해 실시간 글로벌 캐시 뷰를 구축하여 문제를 해결함.
  • 구축된 뷰를 바탕으로 한 Precise Prefix-Cache Aware 스케줄링으로 캐시 재사용을 극대화하여, 기존의 근사치 기반/부하 기반 스케줄러 대비 응답 속도(TTFT)를 최대 57배 높이고 시스템 처리량을 2배 이상 향상시킴.
• Accelerate Large-Scale LLM Inference and KV Cache Offload with CPU-GPU Memory Sharing
  • NVIDIA Grace Blackwell 및 Grace Hopper 아키텍처는 NVLink-C2C를 통해 CPU와 GPU 간 통합 메모리 주소 공간을 제공하여 명시적인 데이터 전송 없이 메모리를 공유함.
  • Llama 3 70B와 같은 대규모 LLM은 추론 시 GPU 메모리(예: GH200의 96GB) 한계를 넘어 OOM(Out-of-Memory) 에러를 발생시키기 쉬움.
  • RAPIDS Memory Manager (RMM) 라이브러리를 활용해 관리 메모리(managed memory)를 할당하면 CPU 메모리(최대 480GB)와 GPU 메모리를 함께 사용하여 물리적 GPU 메모리 한계를 극복하고 대규모 모델 추론이 가능함.

AI Daily Picks(20260414)

• Improving Text Embeddings with Large Language Models
  • 복잡한 파이프라인이나 수작업 레이블 데이터에 의존하지 않고, LLM을 활용해 합성 데이터(Synthetic Data)만으로 고품질 텍스트 임베딩 모델을 학습시키는 방법을 제안했습니다.
  • 93개 언어 및 수십만 개의 임베딩 태스크를 아우르는 합성 데이터를 통해 기존 임베딩 모델들의 제약(언어 편중 및 태스크 제한 등)을 효과적으로 극복했습니다.
  • 합성 데이터만을 사용하여 Mistral-7B 모델을 파인튜닝하는 방식으로 기존 모델에 필적하는 경쟁력을 입증했으며, 다른 레이블 데이터와 혼합 시 BEIR 및 MTEB 등 주요 벤치마크에서 SOTA(최고 성능)를 달성했습니다.
• MongoDB combines database and embedding models for simplified AI development - SiliconANGLE
  • MongoDB는 AI 개발자들이 애플리케이션을 프로토타입에서 프로덕션으로 빠르게 전환할 수 있도록 자사의 핵심 데이터베이스와 작년에 인수한 Voyage AI의 임베딩 기술을 긴밀하게 통합했다고 발표했습니다.
  • Voyage 4 계열 모델(voyage-4, voyage-4-large, voyage-4-lite, 모델 가중치가 공개된 로컬 테스트를 위한 voyage-4-nano)을 API를 통해 MongoDB Atlas와 온프레미스 커뮤니티 에디션에서 텍스트 및 여러 형식 간의 검색(voyage-multimodal-3.5)을 위해 지원합니다.
  • 퍼블릭 프리뷰 상태로 출시된 ‘자동 임베딩’ 기능은 데이터 삽입이나 쿼리 시 자동으로 임베딩을 생성 및 저장하여, 개발자가 별도의 임베딩 파이프라인이나 벡터 DB를 관리할 필요성을 줄이고 운영 위험과 지연 시간을 낮출 수 있게 해줍니다.
• Fine-Tuning Embedding Models for Enterprise Retrieval: A Practical Guide with NVIDIA Nemotron Recipe - Retail News & More
  • Cisco는 NVIDIA Nemotron RAG 파인튜닝 레시피를 활용해 수작업 데이터 레이블링 없이 생성된 합성 데이터(SDG)만으로 엔터프라이즈 도메인 특화 임베딩 모델(NV-EmbedQA)을 성공적으로 파인튜닝했습니다.
  • 단일 GPU 인프라(Cisco AI Pods, NVIDIA H200) 환경에서 모델 학습이 진행되어 데이터 보안을 유지하고 외부 API 비용을 없앴으며, 전체 파이프라인을 단 통상 몇 시간부터 며칠 내 완료해 빠른 가치 검증을 도출해냈습니다.
  • 베이스 임베딩 모델과 비교해 주요 검색 지표(NDCG@1, Recall@10 등) 전반에서 눈에 띄는 성능 개선을 달성했으며, 특히 특정 도메인 질의에서의 검색 품질이 상당히 향상되었음을 확인했습니다.
• The state of agentic AI in 2026
  • 에이전틱 AI(Agentic AI)는 단순한 실험 단계를 넘어 프로덕션 도입의 최우선 순위로 자리잡았으며, 조사 대상 기업의 100%가 2026년에 활용 수준을 확대할 계획이고 74%는 이를 전략적 필수 과제로 인식하고 있습니다.
  • 기업 리더들은 플랫폼 평가 시 즉각적인 ROI보다는 보안과 거버넌스(34%), 기존 시스템과의 통합(30%), 안정성 및 평가 지표(24%) 등 신뢰성 및 운영 준비도를 최우선으로 고려합니다.
  • 데이터 부족과 전문 인력 한계 같은 확장성의 장벽이 존재하지만 절반 이상의 조직(57%)이 시스템 종속성이 없는 오픈 소스 기반 도구 확장을 선호하며, 시간 절약 및 운영 비용 절감 등 실질적인 혜택을 전사적으로 경험하고 있습니다.

• [Linux lays down the law on AI-generated code, says yes to Copilot, no to AI slop, and humans take the fall for mistakes - after months of fierce debate, Torvalds and maintainers come to an agreement

  Tom’s Hardware](https://www.tomshardware.com/software/linux/linux-lays-down-the-law-on-ai-generated-code-yes-to-copilot-no-to-ai-slop-and-humans-take-the-fall-for-mistakes-after-months-of-fierce-debate-torvalds-and-maintainers-come-to-an-agreement)

  • 리눅스 커널 커뮤니티가 AI 생성 코드에 대한 공식 정책을 수립하여 AI 도구 활용을 공식적으로 허용하되 엄격한 투명성과 책임 규정을 적용하기로 합의했습니다.
  • 제출자는 의무적으로 “Assisted-by” 태그를 사용하여 AI의 코드 지원 내역을 명시해야 하며, 코드의 최종 품질이나 잠재적인 버그 문제에 대한 모든 책임은 코드를 제출한 인간 개발자에게 있습니다.
  • AI 코드를 전면 금지하는 다른 오픈소스 프로젝트와 달리, “AI는 일종의 도구일 뿐”이라는 기조 하에 도구 통제보다는 제출자의 책임 소재 확립에 집중하는 실용적인 정책을 도입했습니다.

AI Daily Picks(20260413)

• Google’s TurboQuant: 6x Less Memory for LLM Inference (2026) - Nerd Level Tech
  • 구글 연구진이 발표한 TurboQuant 알고리즘은 LLM의 주요 메모리 병목인 KV 캐시를 정확도 손실 없이 3비트로 압축하여 메모리 사용량을 최대 6배 감소시킴.
  • 무작위 직교 회전(Random Orthogonal Rotation)으로 좌표 구성을 균일하게 한 후 Lloyd-Max 최적 양자화를 적용하며, QJL을 통해 에러를 교정하는 과정으로 데이터나 아키텍처 의존성 없이 압축 효율성을 달성.
  • 평가 벤치마크(LongBench 등)에서 기준점과 동등한 점수를 기록하였으며, H100 환경에서 어텐션 로짓 계산 속도를 8배 향상시켜 저렴한 환경에서 긴 컨텍스트 모델 구동을 가능하게 함.
• Microsoft Open-Sources Industry-Leading Embedding Model
  • 마이크로소프트가 검색 품질 향상 및 차세대 AI 에이전트를 위한 강력한 다국어 텍스트 임베딩 모델 ‘Harrier(Harrier-OSS-v1)’ 제품군을 오픈소스로 공개함.
  • 100개 이상의 언어 지원과 32k 토큰의 긴 컨텍스트 윈도우 처리가 가능하며, Multilingual MTEB v2 벤치마크 평가에서 기존 주요 모델(Gemini Embedding 2 등)을 크게 능가하는 SOTA 성능을 기록함.
  • GPT-5를 활용한 합성 데이터 생성과 20억 쌍의 사전 학습을 거쳤으며, 최고 성능의 27B 모델로부터 소형 모델(0.6B, 270M)로 지식 증류(Knowledge Distillation)를 진행해 매개변수 대비 극대화된 효율성을 확보함.