CELL AI DEVLOG

기존 글에서 SDK 기초는 다뤘습니다. 이번엔 그 다음 단계입니다. Managed Agents API로 코드 한 줄로 격리 샌드박스를 띄우고, GCP와 연결하고, GitHub Actions에 박아 넣는 것까지.📌 핵심 요약→ Antigravity SDK = 에이전트 하네스를 내 코드에 임베딩하는 Python/JS 라이브러리→ Managed Agents API: 목표만 선언 → Google이 샌드박스·루프·재시도 전부 관리→ 과금 구조: 토큰 단위가 아닌 실행(run) 단위 — 장기 작업에 훨씬 유리→ Agent 클래스: 바이너리 탐색·툴 와이어링·훅 등록·정책 기본값 전부 자동 관리→ GCP Enterprise: SLA 보장·VPC 프라이빗 실행·IAM·감사 로그 — 엔터프라이즈 필수→ GitHub A..

배포는 끝이 아닙니다. TTFT가 언제 터질지 모르는 채로 운영하거나, 모델 버전 바꿀 때마다 트래픽 다 끊거나, GPU 노드가 밤새 idle로 켜져 있거나. 4편은 배포 이후 진짜 운영의 이야기입니다.📌 핵심 요약→ LLM 모니터링 핵심 4종: TTFT / TPOT / 큐 깊이 / KV캐시 — RPS만 보면 아무것도 모름→ DCGM Exporter: GPU 하드웨어 메트릭(온도·전력·SM 가동률) Prometheus로 수집→ terminationGracePeriodSeconds 기본 30초는 LLM에 사형선고 — 최소 300초로→ 카나리 배포: 새 모델 10% 트래픽 → TTFT 비교 → 점진 전환, 문제 시 즉시 롤백→ Spot + On-Demand 혼합: 학습은 Spot(60~70% 절감), 추론..

CPU 40%에 스케일 아웃 트리거 맞춰놨는데 추론 큐가 쌓이고 있습니다. LLM은 CPU를 안 씁니다. GPU를 씁니다. 그리고 GPU는 뜨는 순간 VRAM을 다 먹습니다. 기본 HPA로 LLM 스케일링 하려는 건 처음부터 틀렸습니다.📌 핵심 요약→ HPA CPU/메모리 기반 스케일링은 LLM에 무의미 — GPU bound 워크로드→ KEDA: Prometheus 쿼리로 추론 큐 깊이·TTFT·KV 캐시로 스케일링 트리거→ vLLM 핵심 메트릭 3종: num_requests_waiting / gpu_cache_usage_perc / time_to_first_token→ 배치 추론: Job + parallelism으로 병렬 처리, CronJob으로 야간 스케줄→ Kueue: 팀 간 GPU 공정 배분 표..

GPU 노드 세팅이 끝났으면 이제 LLM을 올릴 차례입니다. 근데 일반 웹 컨테이너 올리듯 하면 90초 만에 OOMKilled 납니다. 모델이 뜨는 데만 20분인데 readinessProbe가 30초 만에 죽입니다. AI 추론 서버는 시작부터 다르게 접근해야 합니다.📌 핵심 요약→ 2026 기준 vLLM = 프로덕션 표준 (Meta·Mistral·Cohere·IBM 모두 사용)→ TGI는 2025년 12월 유지보수 모드 전환 — 신규 배포 권장 안 함→ Triton = LLM 엔진 아님, TensorRT-LLM 백엔드 필요한 플랫폼→ 모델 가중치 PVC 캐싱 필수 — 없으면 재시작마다 140GB 다운로드→ startupProbe → readinessProbe → livenessProbe 3단계 분리 —..

AI 서비스 Kubernetes에 올렸더니 GPU 노드에 일반 Pod가 들어가고, GPU Pod는 Pending에서 안 떠나는 경험, 한 번쯤 합니다. 일반 웹앱 운영이랑 GPU 워크로드는 출발점부터 다릅니다.📌 핵심 요약→ GPU 노드는 반드시 Taint — 안 하면 CPU Pod가 $30K짜리 노드에 들어옴→ Device Plugin vs GPU Operator: 소규모는 Plugin, 프로덕션은 Operator→ K8s 1.34 DRA GA — Device Plugin 정수 단위 할당의 한계를 구조화 파라미터로 해결→ GPU 공유 3가지: MIG(하드웨어 격리) / Time-slicing(소프트 공유) / MPS(동시 실행)→ requests = limits 필수 — GPU는 오버커밋 불가, 불일..