Tensorfuse

Tensorfuse

Tensorfuse (Y Combinator W24, San Francisco) · 코딩 · 기타

Tensorfuse는 자사 AWS·Azure·GCP 계정 안에서 AI 모델을 배포하고 파인튜닝하며 자동 확장하는 서버리스 GPU 플랫폼이다. 모델 가중치와 데이터는 VPC 밖으로 나가지 않는다.

Tensorfuse 미리보기

Tensorfuse 소개

What Is Tensorfuse

Tensorfuse는 모델은 이미 있는데 서빙하려고 쿠버네티스를 직접 돌보고 싶지 않은 팀을 위한 인프라다. 자사 클라우드 계정을 지정하면 EC2 인스턴스 위에 쿠버네티스 클러스터와 로드 밸런서, 오토스케일러를 세우고 마지막에 배포 명령 하나를 건넨다.

파는 것은 GPU 자체가 아니라 운영 부담의 감소다. GPU 시간은 여전히 클라우드 사업자에게 지불하고, Tensorfuse는 그 관리 비용을 받는다. 연산 자원과 모델 가중치, 데이터셋이 VPC 안에 머물기 때문에 프롬프트도 체크포인트도 제3자 계정을 거치지 않는다. 기업 보안 심사에서 결론을 가르는 지점이 바로 여기다.

한계는 호스팅된 엔드포인트가 아니라는 점이다. GPU 할당량이 있는 클라우드 계정과 리소스를 만들 권한, 앱이나 모델을 담은 Dockerfile이 필요하다. 클라우드 계정 없이 5분 만에 돌아가는 엔드포인트를 원한다면 호스팅형 서비스가 더 빠르다. 가격표도 공개하지 않으므로 비교 전에 영업과 통화를 해야 한다.

Getting Started

  1. 클러스터를 만든다. 로그인하고 클라우드 사업자를 고른 뒤 안내된 IAM 권한을 부여하고 기다린다. 이 단계에 25~30분이 걸린다.
  2. Tensorkube CLI를 설치하고 5~10분 더 쓴 뒤 로컬 환경을 클러스터와 동기화한다.
  3. 돌릴 것을 묶는다. FastAPI 앱이든 추론 서버든 Dockerfile에 넣고, 시크릿과 모델 설정은 env 파일로 분리한다.
  4. CLI로 배포하고 최소·최대 레플리카 수를 정한 뒤 엔드포인트가 정상이 될 때까지 상태를 확인한다.

제품 정보

Tensorfuse의 요금, 지원 플랫폼, 성능을 한눈에 확인해 보세요.

무료 플랜예
유료 플랜Custom quote, billed per managed GPU hour plus your cloud GPU bill
플랫폼Web dashboard, Tensorkube CLI, AWS (Azure and GCP supported)
개발사Tensorfuse (Y Combinator W24, San Francisco)
카테고리코딩 · 기타
출시일Jun 2024
최근 업데이트Oct 2026
웹사이트 방문 수4.5K
웹사이트 글로벌 순위4M
API 제공 여부예

추천 대상

이 도구가 가장 잘 맞는 사용자, 작업, 상황입니다.

사용자

  • 시드에서 시리즈 A 단계의 ML 엔지니어
  • 규제 산업의 플랫폼 팀
  • 이미 AWS를 쓰는 개인 개발자

작업

  • 오픈 가중치 LLM 서빙
  • 자체 데이터로 파인튜닝
  • 임베딩, 평가, 라벨링 같은 배치 작업
  • 고객별 어댑터 대량 서빙

활용 상황

  • 트래픽이 늘면 느려지는 SageMaker 엔드포인트 교체
  • 약정한 AWS 사용액 소진
  • 기업 보안 질의서 통과

주요 기능

자사 VPC 안에서 도는 서버리스 추론

배포는 들어오는 트래픽에 맞춰 늘고 요청이 끊기면 줄어든다. 컨테이너는 직접 준비한다. vLLM, SGLang, TensorRT-LLM, NVIDIA Dynamo 어느 쪽이든 되고 클러스터와 로드 밸런서, 확장 규칙은 Tensorfuse가 맡는다. 엔드포인트 동작이 기존 호스팅 API와 같아서 이전에 코드를 고칠 필요가 없다.

무거운 컨테이너의 빠른 콜드 스타트

서버리스 GPU의 약점은 콜드 스타트에서 드러난다. Tensorfuse는 수 GB짜리 GPU 이미지를 염두에 둔 컨테이너 런타임을 넣었고 회사는 초 단위 기동을 내세운다. 사용자 입장에서는 유휴 시 0으로 줄여도 첫 요청이 타임아웃으로 끝나지 않는다는 뜻이다.

GPU 한 장에 여러 LoRA

수천 개 LoRA 어댑터를 GPU 한 장에서 학습하고 실시간으로 교체하며 서빙할 수 있다. 고객마다, 작업마다 엔드포인트를 따로 두는 대신 베이스 모델 하나를 띄우고 요청에 맞는 어댑터를 얹는다. 고객별 커스터마이징이 많은 팀에 특히 유리하다. 어댑터 수가 GPU 수를 좌우하지 않게 되기 때문이다.

익숙한 프레임워크로 하는 파인튜닝

학습은 자사 클라우드 GPU에서 돌고 Axolotl, Unsloth, Hugging Face 라이브러리, 직접 짠 루프를 모두 쓸 수 있다. 데이터셋과 결과 가중치는 사설 S3 버킷에 남는다. 전용 학습 형식을 강요하지 않아서 노트북에서 실험한 스크립트를 그대로 옮길 수 있다.

배치 작업을 위한 잡 큐

평가, 데이터 재생성, 라벨링처럼 긴 작업에 상시 켜둔 엔드포인트는 필요 없다. 코드로 큐에 넣고 비용 관리를 위해 최소·최대 확장 폭을 정하며 상태는 명령 하나로 확인한다. GPU는 실행할 때만 나타났다 사라진다. 시간당 과금의 의미가 거기에 있다.

IDE와 동기화되는 개발 컨테이너

SSH 없이 로컬 코드를 클라우드 GPU에 연결한다. 에디터에서 계속 작업하면 변경 사항이 실행 중인 컨테이너에 바로 반영된다. 전체 배포 전에 모델 변경을 실제 하드웨어에서 확인하는 가장 짧은 경로다.

장단점

장점

  • 모델 가중치와 데이터셋, 프롬프트가 자사 클라우드 계정에 남는다. 보안 심사를 통과하기에 가장 유리한 구조다.
  • GPU 시간이 기존 AWS 청구서에 잡혀 약정 사용액과 크레딧, 기업 할인이 그대로 적용된다.
  • 컨테이너라면 무엇이든 된다. vLLM, SGLang, TensorRT-LLM, 자체 FastAPI 서비스가 같은 배포 절차를 탄다.
  • 클러스터 구축이 1시간 안쪽이고 확장 규칙도 미리 설정돼 있어 직접 짤 필요가 없다.
  • 멀티 LoRA 덕에 고객별 어댑터 비용이 낮다. 수천 개가 GPU 한 장을 공유한다.

단점

  • 첫 배포 전에 클라우드 관리자 권한과 GPU 할당량이 필요하다. 인프라 경험이 없는 팀은 여기서 막힌다.
  • GPU 청구서는 클라우드 사업자가 따로 보낸다. 최소 레플리카를 놀리면 비용이 조용히 쌓이므로 직접 조정해야 한다.
  • 공개 가격표가 없다. 호스팅 GPU 사업자와 비교하려면 영업과 대화가 먼저다.
  • Azure와 GCP 문서는 AWS보다 훨씬 얇다. 멀티 클라우드 팀은 첫 배포에서 시행착오가 늘어난다.

자주 묻는 질문

자사 클라우드 계정 안에 서버리스 GPU 스택을 설치하고 운영한다. 컨테이너를 넘기면 클러스터와 로드 밸런서, 오토스케일러를 만들고 모델은 트래픽을 따라 확장되는 HTTP 엔드포인트 뒤에서 돌아간다.