Deveoler Lee

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 철학: ...

대규모 언어 모델(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 외부 메모리, ...

왜 로컬에서 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와 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 실행 방법 은 단순한 모델 실행을 넘어, 고성능 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...

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

왜 모놀리식 프롬프트는 한계가 있을까요? 대부분의 AI 에이전트는 시스템 프롬프트 하나에 모든 도메인 지식을 몰아넣는 방식으로 동작해요. 컴플라이언스 규칙, 스타일 가이드, API 레퍼런스, 트러블슈팅 절차까지 하나의 거대한 문자열로 연결하는 거죠. 태스크가 두세 개일 땐 문제없지만, 열 개 이상으로 늘어나면 매 LLM 호출마다 수천 토큰을 소비하게 돼요 — 사용자의 쿼리가 그 지식을 전혀 필요로 하지 않더라도요. Google의 ADK(Agent Development Kit) 는 이 문제를 프로그레시브 디스클로저(Progressive Disclosure)라는 아키텍처 패턴으로 풀어요. 필요한 컨텍스트를 필요한 시점에만 로드하는 구조인데, 이 글에서는 ADK의 SkillToolset 을 활용한 4가지 실전 스킬 패턴을 단계별로 살펴볼게요. ADK 스킬 스펙: 3단계 지식 로딩 구조 ADK 에이전트 스킬 의 핵심은 지식을 세 단계로 분리하는 데 있어요. L1 메타데이터 (~100 토큰/스킬) 스킬 이름과 설명만 포함하는 최소 정보예요. 에이전트가 시작될 때 모든 스킬의 L1을 로드해서, 어떤 스킬이 현재 쿼리에 관련 있는지 판단하는 메뉴 역할을 해요. L2 인스트럭션 (<5,000 토큰) 스킬의 전체 본문이에요. 에이전트가 특정 스킬을 명시적으로 활성화할 때만 API를 통해 로드돼요. L3 리소스 (필요 시) 스타일 가이드나 API 스펙 같은 외부 참조 파일이에요. 스킬의 인스트럭션이 요구할 때만 로드되죠. 이 구조 덕분에 10개 스킬을 가진 에이전트가 매 호출 시 약 1,000 토큰의 L1 메타데이터만 사용해요. 모놀리식 프롬프트 대비 약 90%의 컨텍스트 사용량 절감이 가능한 거예요. SkillToolset 클래스가 activate_skill , deactivate_skill , list_skills 세 가지 도구를 자동 생성해서 이 흐름을 관리해 줘요. 4가지 스킬 패턴 구현하기 패턴 1: 인라인 스킬 — 가장 단순한 시작점 파이썬 객체로 직접 정의...

RAG(검색 증강 생성) 기반 AI 어시스턴트는 분명 강력하지만, 문서 탐색에서는 뚜렷한 한계를 보여요. 쿼리와 유사한 텍스트 청크만 반환하는 방식은 답변이 여러 페이지에 걸쳐 있거나 정확한 구문 매칭이 필요한 경우 제대로 작동하지 않아요. Mintlify 팀은 에이전트가 코드베이스를 탐색하듯 문서를 직접 탐색할 수 있는 구조가 필요하다고 판단했어요. 그 결과물이 바로 가상 파일시스템(Virtual Filesystem) — ChromaFs예요. 이 글에서는 ChromaFs의 설계 배경, 핵심 구조, 그리고 성능·비용 트레이드오프를 개발자 시각에서 깊이 있게 살펴볼게요. 실제 샌드박스가 실패하는 이유 에이전트에게 실제 파일시스템을 주는 건 직관적인 해결책이에요. 격리된 샌드박스를 스핀업하고 저장소를 클론하면 되니까요. Mintlify도 비동기 백그라운드 에이전트에는 실제로 이 방식을 사용해요. 그런데 사용자가 로딩 스피너를 바라보는 프론트엔드 어시스턴트 시나리오에서는 이야기가 완전히 달라져요. 레이턴시 문제 GitHub 클론을 포함한 세션 생성의 p90 레이턴시가 약 46초 에 달했어요. 사용자 입장에서 46초는 곧장 이탈로 이어지는 숫자예요. 아무리 답변 품질이 좋아도, 기다림 자체가 UX를 망가뜨려요. 비용 문제 정적 문서 읽기를 위해 전용 마이크로-VM을 띄우는 건 인프라 비용이 상당해요. Daytona의 퍼-세컨드 샌드박스 가격(vCPU당 $0.0504/h, GiB RAM당 $0.0162/h)을 기준으로, 월 850,000건의 대화에 최소 설정(1 vCPU, 2 GiB RAM, 5분 세션)을 적용하면 연간 $70,000 이상 이 나와요. 세션 시간이 늘어나면 이 수치는 두 배로 뛰죠. 항목 실제 샌드박스 ChromaFs 세션 생성 시간 ~46초 ~수백 ms 대화당 추가 비용 ...

모바일에서 AI가 '행동'하기 시작했다 AI가 단순히 텍스트를 생성하는 것을 넘어, 실제로 앱을 열고 시스템 설정을 바꾸고 캘린더에 일정을 추가하는 시대가 왔어요. 이 모든 것이 서버 없이, 내 스마트폰 위에서 실행된다면 어떨까요? 온디바이스 함수 호출(On-Device Function Calling) 은 바로 그 가능성을 현실로 만드는 기술이에요. 네트워크 지연도, 개인정보 유출 위험도 없이 자연어 명령 하나로 OS 기능을 직접 제어할 수 있죠. Google은 최근 AI Edge Gallery를 대폭 업데이트하며 이 기술을 개발자 누구나 체험하고 확장할 수 있도록 공개했어요. 이번 글에서는 FunctionGemma의 구조, 성능 벤치마크, 그리고 실제 커스텀 에이전트를 만드는 방법까지 깊이 있게 살펴볼게요. FunctionGemma 270M — 왜 이 숫자가 중요한가 전통적인 함수 호출(Function Calling) 모델은 수십억 개의 파라미터를 요구해서, 모바일 하드웨어의 메모리와 배터리 한계를 훌쩍 넘겼어요. 이걸 모바일에 구겨 넣으면서도 정확도를 유지하는 것이 핵심 엔지니어링 과제였죠. Google이 내놓은 해답이 바로 FunctionGemma 270M 이에요. 겨우 2억 7천만 개의 파라미터로 자연어를 OS 툴 인텐트(intent)로 변환하는 데 특화된 모델이에요. 성능 수치를 보면 왜 주목받는지 바로 알 수 있어요. Pixel 7 Pro CPU 기준 : 프리필(prefill) 1,916 tokens/sec 디코드(decode) 속도 : 142 tokens/sec 완전 오프라인 동작 — 네트워크 핑(ping) 제로 iOS/Android 크로스플랫폼 지원 (LiteRT 기반) 이 숫자가 의미하는 건 단순한 벤치마크 수치가 아니에요. 사용자가 "내일 오후 2시 30분에 요리 수업 캘린더 등록해줘"라고 말하면, 모델이 네트워크를 거치지 않고 즉시 createCalendarEvent(ti...