글

TorchTPU: PyTorch를 TPU에서 네이티브로 실행하는 구글의 전략

이미지
PyTorch + TPU, 왜 지금 중요한가 대규모 AI 모델 학습의 시대가 본격화되면서, 수천~수만 개의 가속기를 효율적으로 활용하는 소프트웨어 스택의 중요성이 급격히 커지고 있어요. Google의 TPU(Tensor Processing Unit)는 Gemini, Veo 같은 자체 AI 플랫폼은 물론 Cloud 고객의 대규모 워크로드를 처리하는 핵심 인프라인데요. 문제는 ML 커뮤니티의 상당수가 PyTorch 생태계에 익숙하다는 점이에요. TorchTPU 는 바로 이 간극을 메우기 위해 설계된 스택으로, 기존 PyTorch 코드를 최소한의 변경만으로 TPU에서 네이티브로 실행할 수 있게 해줘요. 이 글에서는 TorchTPU의 핵심 아키텍처, Eager 모드 전략, 정적 컴파일 파이프라인, 그리고 2026년 로드맵까지 개발자 관점에서 깊이 살펴볼게요. TPU 하드웨어 아키텍처 이해하기 TorchTPU 를 제대로 이해하려면 먼저 TPU의 하드웨어 구조를 알아야 해요. TPU는 단순한 칩이 아니라 통합 네트워크 시스템이에요. ICI와 토러스 토폴로지 각 호스트에는 여러 개의 TPU 칩이 연결되어 있고, 칩들은 Inter-Chip Interconnect(ICI)를 통해 2D 또는 3D 토러스(Torus) 토폴로지로 연결돼요. 이 구조 덕분에 전통적인 네트워크 병목 없이 대규모 스케일업이 가능해요. GPU 클러스터에서 InfiniBand나 NVLink에 의존하는 것과는 근본적으로 다른 접근이에요. TensorCore와 SparseCore 칩 내부 실행은 TensorCore와 SparseCore로 나뉘어요. TensorCore : 단일 스레드 유닛으로 밀집 행렬 연산(dense matrix math)에 특화 SparseCore : 임베딩, gather/scatter 같은 불규칙 메모리 접근 패턴과 collective 오프로딩 처리 이 이중 구조가 TPU의 핵심 강점이고, TorchTPU는 이 두 코어를 모두 활용할 수 있도록 설계되었어요. Eager First 철학: ...
자세한 내용 보기

단일 GPU로 1000억 파라미터 LLM 학습: MegaTrain 논문 분석

이미지
대규모 언어 모델(LLM) 학습에는 보통 수백, 수천 대의 GPU 클러스터가 필요해요. 100B 파라미터 모델 하나를 학습하려면 파라미터, 옵티마이저 상태, 그래디언트, 활성화 값까지 합쳐 테라바이트 단위의 메모리가 필요하기 때문이에요. 그런데 만약 단일 GPU로 1000억 파라미터 LLM 학습 이 가능하다면 어떨까요? Zhengqing Yuan 등이 발표한 MegaTrain 논문은 바로 이 문제를 정면으로 다루고 있어요. 풀 프리시전(Full Precision)을 유지하면서도 단 하나의 GPU에서 100B+ 규모 모델을 학습할 수 있는 시스템 아키텍처를 제안하고 있죠. 왜 단일 GPU 학습이 중요한가 현재 LLM 학습 생태계는 극심한 자원 불균형 상태에 있어요. NVIDIA H100 한 대가 약 6만 달러, 멀티 GPU 서버는 50만 달러 이상이에요. 대부분의 연구자와 중소 규모 조직은 이런 클러스터를 확보하기 어렵죠. 하지만 흥미로운 트렌드가 있어요. LLM 개발 워크플로우가 점차 사전학습 중심에서 사후학습(Post-training) 중심으로 이동하고 있다는 거예요. Instruction tuning, alignment, domain adaptation 같은 작업은 사전학습 대비 연산량이 훨씬 적어요. 원칙적으로는 단일 노드에서 충분히 수행할 수 있는 규모이지만, 기존 학습 시스템의 메모리 구조가 이를 가로막고 있었어요. 단일 GPU로 1000억 파라미터 LLM 학습 이 실현되면, GPU 클러스터 없이도 대형 모델을 커스터마이징할 수 있어요. 이건 LLM 민주화에 있어 결정적인 전환점이 될 수 있어요. GPU 메모리의 구조적 한계 100B 파라미터 모델을 BF16/FP32 혼합 정밀도로 학습한다고 가정해 볼게요. 파라미터 자체가 약 200GB(BF16), AdamW 옵티마이저 상태가 FP32로 파라미터의 3배(약 1.2TB), 그래디언트와 활성화 값까지 더하면 단일 GPU의 VRAM(80~192GB)으로는 어림도 없어요. 결국 핵심은 GPU 외부 메모리, ...
자세한 내용 보기

Gemma 4 로컬 실행: LM Studio Headless CLI와 Claude Code 연동 가이드

왜 로컬에서 LLM을 돌려야 할까? 클라우드 AI API는 편리하지만, 매번 따라오는 문제가 있어요. 요금 폭탄, 속도 제한, 개인정보 유출 우려, 그리고 네트워크 지연까지. 특히 코드 리뷰, 초안 작성, 프롬프트 테스트처럼 빠른 반복이 필요한 작업에서는 매 요청마다 클라우드를 거치는 게 병목이 돼요. Gemma 4 로컬 실행 은 이런 문제를 근본적으로 해결하는 접근법이에요. Google이 공개한 Gemma 4는 mixture-of-experts(MoE) 구조를 채택해서 26B 파라미터 모델이면서도 추론 시 4B 파라미터만 활성화해요. 덕분에 M4 Pro MacBook(48GB) 같은 소비자용 하드웨어에서도 초당 51토큰이라는 실용적인 속도를 낼 수 있어요. 이 글에서는 LM Studio의 새로운 Headless CLI를 활용해 Gemma 4 로컬 실행 환경을 구축하고, Claude Code와 연동해 완전한 오프라인 코드 어시스턴트를 만드는 과정을 다뤄요. Gemma 4 아키텍처: MoE가 개발자에게 의미하는 것 10B급 품질, 4B급 비용의 비밀 Gemma 4 26B-A4B 모델은 128개 전문가(expert) 중 8개만 활성화해서 실제 연산에 사용하는 파라미터는 3.8B에 불과해요. 벤치마크 성능은 MMLU Pro 82.6%, AIME 2026 88.3%로 31B dense 모델에 근접하면서도 훨씬 적은 연산 자원을 소모해요. Per-Layer Embeddings 구조를 사용하며, 도구 호출(tool use) 학습도 완료된 상태라 에이전트 워크플로우에 바로 투입할 수 있어요. MoE의 메모리 특성 — 흔한 오해 바로잡기 한 가지 주의할 점이 있어요. MoE는 연산량(FLOPs)은 줄여주지만, 메모리(VRAM/RAM) 사용량은 dense 모델과 크게 다르지 않아요. 비활성 전문가들도 여전히 메모리에 로드되어 있어야 하거든요. 다만 tok/s(초당 토큰 생성 속도)는 확실히 개선돼요. NVIDIA GPU 사용자라면 비활성 전문가를 CPU RAM으로 오프로드하...
자세한 내용 보기

Claude Code 이슈 #42796: GitHub 검색 기능 완벽 분석

이미지
Claude Code와 GitHub 검색 기능, 왜 주목해야 할까요? Claude Code 는 Anthropic이 개발한 AI 기반 코딩 어시스턴트로, 개발자의 워크플로우에 깊숙이 통합되는 것을 목표로 해요. 그 중에서도 GitHub와의 연동은 실무 개발자에게 특히 중요한 주제예요. 이번 포스트에서는 GitHub 이슈 #42796을 중심으로, Claude Code 가 코드·저장소·사용자·이슈·풀 리퀘스트(Pull Request) 검색을 어떻게 다루는지, 그리고 개발자 입장에서 어떤 실질적인 의미가 있는지 살펴볼게요. GitHub 검색 기능의 범위와 한계 GitHub의 검색(Search) 기능은 단순한 키워드 매칭을 넘어 다양한 범주를 커버해요: 코드(Code) : 특정 함수명, 패턴, 라이브러리 사용 예시를 전체 공개 저장소에서 탐색 저장소(Repositories) : 스타 수, 언어, 토픽 기반으로 프로젝트 필터링 사용자(Users) : 기여자 프로필, 조직 멤버 검색 이슈(Issues) : 레이블, 담당자, 상태별 이슈 추적 풀 리퀘스트(Pull Requests) : 리뷰 상태, 브랜치, 머지 여부 기반 탐색 검색 API의 실제 제약 GitHub Search API는 인증 여부에 따라 분당 10~30회 요청 제한이 걸려요. 특히 코드 검색은 기본 브랜치(default branch)만 인덱싱되며, 포크(fork) 저장소는 기본적으로 제외돼요. Claude Code 가 이런 API를 통해 컨텍스트를 수집할 때 이 제약을 인지하고 있어야 해요. # GitHub CLI를 활용한 이슈 검색 예시 gh search issues "claude code search" --repo anthropics/claude-code --state open # 코드 검색 gh search code "def search_repositories" --language python 이슈 #42796이 다루는 핵심 문제 Claude Code GitHub ...
자세한 내용 보기

gemma4 sglang 실행 방법: 최신 세팅 가이드

gemma4 sglang 실행, 왜 중요한가 gemma4 sglang 실행 방법 은 단순한 모델 실행을 넘어, 고성능 LLM inference 파이프라인을 구축하는 핵심이에요. 최근 Google DeepMind가 공개한 Gemma 4는 멀티모달과 함수 호출을 기본 지원하는 고성능 오픈 모델로, 다양한 추론 엔진에서 활용 가능해요. According to Google AI 및 최신 기술 블로그 자료, Gemma 4는 vLLM, Transformers, SGLang 등 주요 inference 엔진과 호환되며 고성능 환경에서 특히 강점을 보여요. 문제는 단순 실행이 아니라 "효율"이에요. SGLang은 KV cache 재사용과 structured decoding 최적화를 통해 최대 6배 이상의 throughput 개선을 제공해요. 즉, gemma4를 SGLang으로 실행하면 단순 API 호출 대비 훨씬 높은 성능을 확보할 수 있어요. 이 글에서는 개발자 관점에서 실제 실행 방법과 구성 전략을 구체적으로 설명해요. SGLang + Gemma4 아키텍처 이해 SGLang이 필요한 이유 SGLang은 LLM 실행을 위한 프론트엔드 언어 + 런타임 구조로 설계되어 있어요. According to SGLang 논문, 다음과 같은 특징이 핵심이에요: RadixAttention 기반 KV cache 재사용 structured output decoding 최적화 multi-call 프로그램 실행 최적화 cache-aware scheduling Gemma4와의 궁합 Gemma4는 다음 특성 때문에 SGLang과 잘 맞아요: 함수 호출 및 JSON 출력 지원 멀티모달 입력 처리 MoE 구조로 높은 효율성 (26B 모델이 4B 수준 속도) According to 최신 Gemma 4 발표 자료, 일부 모델은 단일 GPU에서도 실행 가능하며, 효율적인 inference 엔진과 결합 시 성능이 크게 향상돼요. gemma4 sglang 실행 방법 (실전) 1. 환경 준비 b...
자세한 내용 보기

gemma4 vllm 실행 방법: 설치·최적화·멀티GPU 완전 가이드

최신 LLM을 직접 서빙하는 환경을 구축하려면 단순 실행을 넘어서 성능, 안정성, 확장성까지 고려해야 해요. 특히 gemma4 vllm 실행 방법 은 최신 모델 특성상 문서와 실제 구현 간 차이가 존재하기 때문에, 제대로 이해하지 않으면 실행은 되더라도 성능이 크게 떨어질 수 있어요. 최근 vLLM이 Gemma 4를 공식 지원하면서 OpenAI-compatible API 형태로 바로 서비스가 가능해졌고, KV cache 최적화와 PagedAttention 덕분에 높은 throughput을 확보할 수 있어요. 이 글에서는 단순 실행을 넘어 실무 환경에서 바로 적용 가능한 수준으로 상세하게 정리해볼게요. gemma4 vllm 실행을 위한 시스템 아키텍처 이해 Gemma 4는 단순 텍스트 모델이 아니라 멀티모달 + reasoning 중심 모델이에요. vLLM은 이를 효율적으로 처리하기 위해 내부적으로 다음 구조를 사용해요. vLLM 핵심 구조 PagedAttention: KV cache를 페이지 단위로 관리해 fragmentation 최소화 Continuous batching: 요청을 실시간으로 합쳐 GPU utilization 극대화 OpenAI API layer: 기존 클라이언트 그대로 사용 가능 이 구조 덕분에 gemma4 vllm 실행 방법 은 단순하지만 내부적으로는 매우 고성능 추론 파이프라인이 동작해요. 권장 하드웨어 구성 7B 이하: RTX 3090 / 4090 (24GB) 27B 이상: A100 80GB 또는 멀티 GPU NVLink 환경이면 tensor parallel 효율 상승 메모리가 부족하면 swap이 아니라 inference 자체가 실패하기 때문에 VRAM 확보가 가장 중요해요. gemma4 vllm 설치 및 빌드 전략 Gemma 4는 최신 모델이기 때문에 stable보다 nightly 사용이 사실상 필수예요. Python 환경 설치 (권장) uv venv source .venv/bin/activate uv pip install -U vll...
자세한 내용 보기

AI 코딩 가이드라인: 에이전트와 사람 모두를 위한 코딩 표준 만들기

이미지
AI 코딩 에이전트 시대, 왜 가이드라인이 달라져야 할까요? 2026년 현재, 소프트웨어 엔지니어들이 직접 코드를 작성하는 비중은 빠르게 줄어들고 있어요. 대신 AI 코딩 에이전트 가 설계 의도에 따라 코드를 생성하고, 엔지니어는 설계·아키텍처·코드 리뷰에 집중하는 구조로 전환되고 있죠. 문제는 이 에이전트들이 기존 엔터프라이즈 코드베이스에 기여하려면 팀의 코딩 표준과 가이드라인을 정확히 따라야 한다는 점이에요. 주니어 개발자에게 문서 몇 개 던져주고 "알아서 배워"라고 할 수 있지만, 에이전트에게는 이 접근이 통하지 않아요. 에이전트는 빠르지만 코드의 맥락(Context)을 스스로 체득하지 못하고, 코드 스멜(Code Smell) 같은 암묵적 지식이 없기 때문이에요. 이 글에서는 AI 코딩 에이전트 와 사람 모두를 위한 효과적인 코딩 가이드라인을 어떻게 설계하는지 구체적으로 살펴볼게요. 에이전트용 코딩 가이드라인이 기존과 다른 이유 사람은 코드베이스를 탐색하면서 패턴, 스타일, 관행을 암묵적으로 학습해요. 특정 함수 네이밍 컨벤션이나 에러 처리 패턴을 반복적으로 보면서 "우리 팀은 이렇게 하는구나"를 자연스럽게 흡수하죠. 하지만 AI 코딩 에이전트 는 이 과정을 거치지 않아요. 프롬프트에 명시되지 않은 규칙은 존재하지 않는 것과 같아요. Heroku의 수석 아키텍트 Vish Abrams는 DRY(Don't Repeat Yourself)나 설정과 코드의 분리 같은 원칙조차 에이전트에게는 명시적으로 알려줘야 한다고 강조했어요. 예를 들어 "스네이크 게임을 만들어줘"라고만 하면 에이전트는 유지보수성을 전혀 고려하지 않은 코드를 생성할 수 있어요. 이런 차이 때문에 에이전트용 가이드라인은 다음 세 가지 특성을 가져야 해요: 명시적(Explicit) : 암묵적 가정을 모두 문서화해야 해요. 예시 중심(Demonstrative) : 올바른 패턴과 잘못된 패턴을 코드 예시로 보여줘야 해요. 명백함(Obvious...
자세한 내용 보기