온프레미스 B2B AI 제공

온프레미스의 의미

온프레미스: 모델/서비스가 **고객사 인프라(고객 서버)**에서 실행되고 데이터가 외부로 나가지 않음
벤더 인프라(벤더 클라우드, e.g. OpenAI, Gemini ..): 모델이 벤더가 운영하는 서버에서 실행됨
- 스타트업이 OpenAI API를 쓰는 경우, 모델은 OpenAI(또는 Azure OpenAI 등 벤더)의 서버에서 실행
- 이 경우 고객사 서버에서 실행되는 것이 아님 → 온프레미스 아님
Private Endpoint/VPN: 전송 경로가 사설이어도 호스팅 주체가 벤더면 클라우드

스타트업이 온프레미스를 제공하는 현실적 방법

모델 선택

오픈웨이트 모델: Llama / Mistral / Qwen / Gemma 등
상용 모델 온프레미스 라이선스: 드물지만 존재 (대형 계약/규제 산업)
GPT/Gemini/Anthropic: 가중치 비공개 → 온프레미스 불가, 클라우드 API만 가능

배포 방식

고객사 데이터센터/프라이빗 클라우드에 설치
서빙: vLLM / TGI / llama.cpp 등
보안: Air-gapped, 내부망 인증, 로그 외부 반출 금지

”OpenAI급 성능을 쓰고 싶다” vs 온프레미스

OpenAI/Gemini/Anthropic API는 클라우드형 B2B (온프레미스 아님)
데이터는 외부 벤더 서버로 전송됨 (no-training 옵션은 가능)
온프레미스는 **로컬 추론 가능한 모델(오픈웨이트)**을 써야 함

벤더 의존성과 AI 하네스

벤더 파인튜닝 = 벤더 종속 → 스타트업은 최소화
대신 AI 하네스로 가치 제공:
- RAG(도메인 지식), 툴, 정책, 가드레일, 워크플로우
- LLM은 교체 가능한 모듈로 설계 (어댑터 패턴)

스타트업의 B2B 가치 제공 (Phase 분리)

Phase 1: AI Harness (초기, 벤더 LLM 기반)

RAG + 하네스로 “일반 AI보다 더 나은 가치” 제공
벤더 LLM API 사용, 도메인 특화 답변, 업무 자동화

Phase 2: Open-weight Training (추후, 온프레미스 전환)

축적한 데이터로 오픈웨이트 모델 학습
온프레미스 배포로 벤더 의존성 탈피

수집 데이터의 용도

1) RAG 품질 개선 → Phase 1 (하네스)
2) 평가/회귀 테스트 → Phase 1 (하네스)
3) 모델 교체 시 재학습 → Phase 2 (오픈웨이트)

데이터 파이프라인 시퀀스

sequenceDiagram
  autonumber
  participant User as 👤 User
  participant Product as 🧩 Product
  box rgb(220, 240, 255) Startup Platform
    participant VectorDB as 📚 Vector DB
    participant Gateway as 🔐 API Gateway
    participant DataPipe as 🛠️ Data Pipeline
    participant Store as 🗂️ Data Store
    participant Labeling as ✍️ Labeling QA
    participant Train as 🧠 Training
    participant Deploy as 🚀 Deployment
  end
  box rgb(255, 240, 220) External LLM Vendors
    participant LLM as 🤖 LLM API
  end
  box rgb(220, 255, 220) Customer On-Prem
    participant OnPrem as 🏢 On-Prem Runtime
  end
  Note over User,Store: Phase 1 (AI Harness)
  User->>Product: 질의 입력
  Product->>VectorDB: RAG 검색
  VectorDB-->>Product: 관련 문서 컨텍스트
  Product->>Gateway: 질의 + 컨텍스트 전달
  Gateway->>LLM: 프롬프트 전송
  LLM-->>Gateway: 응답 반환
  Gateway-->>Product: 응답 전달
  Product-->>User: 답변 표시
  Product->>DataPipe: 로그 수집 (opt-in)
  DataPipe->>DataPipe: PII 마스킹/정제
  DataPipe->>Store: 모델-중립 포맷 저장
  Store->>VectorDB: RAG 재인덱싱 (주기적)
  Note over Store,OnPrem: Phase 2 (Open-weight Training)
  Store->>Labeling: 라벨링 큐 생성
  Labeling-->>Train: 학습용 데이터셋
  Train-->>Deploy: 오픈웨이트 모델 패키지
  Deploy->>OnPrem: 온프레미스 배포

단계별 요약

Phase 1 (AI Harness)

사용자 질의: 사용자가 제품에 질의 입력
RAG 검색: VectorDB에서 도메인 문서 컨텍스트 검색
벤더 LLM 호출: 질의 + 컨텍스트를 벤더 LLM API로 전송
응답 전달: 벤더 LLM 응답을 사용자에게 반환
로그 수집: opt-in 기준으로 로그/피드백 수집
데이터 정제: PII 마스킹 후 모델-중립 포맷으로 저장
RAG 재인덱싱: 축적된 데이터로 VectorDB 주기적 업데이트
- 실시간 반영 아님: 누적 후 주기적으로 반영

Phase 2 (Open-weight Training)

라벨링: 축적 데이터를 오픈웨이트 학습용 데이터셋으로 준비
학습: 오픈웨이트 모델(Llama/Mistral 등)에 파인튜닝
온프레미스 배포: 학습된 모델을 고객사 내부에 배포

평가 체계 자동화 (선택사항)

스타트업이 성장하면서 품질 관리/모델 교체 대비로 도입할 수 있음. 대표적인 자동 평가 프레임워크

OpenAI Evals: https://platform.openai.com/docs/guides/evals
LM Evaluation Harness: https://github.com/EleutherAI/lm-evaluation-harness
Ragas (RAG 평가): https://docs.ragas.io/en/stable/
DeepEval: https://deepeval.com/

요약

온프레미스 = 고객 인프라 내부 실행
GPT/Gemini/Anthropic은 클라우드 API만 가능 (온프레미스 불가)
Phase 1: 벤더 LLM + RAG + 하네스로 B2B 가치 제공 (초기)
Phase 2: 오픈웨이트 모델 학습 + 온프레미스 전환 (추후)
데이터는 모델-중립 포맷으로 축적 → Phase 1에서도, Phase 2에서도 재사용

2026-03-30 심화: 온프레미스 AI 실전 구축 방법

기존 정리(2026-02-10) 보완 — 기업 특화 모델 구축의 실제 방법론과 2025년 변경사항 반영

업데이트: GPT-OSS 출시로 기존 정리 일부 수정 필요

기존 정리에서 “GPT/Gemini/Anthropic: 온프레미스 불가”라고 명시했으나, 2025년 8월 OpenAI가 GPT-OSS를 출시하며 부분적으로 변경됨.

모델	온프레미스 가능 여부	변경 시점
GPT-4, o1, o3 등	❌ 여전히 불가 (가중치 비공개)	-
GPT-OSS 120b / 20b	✅ 가능 (Apache 2.0)	2025.08 신규 출시
Gemini, Anthropic	❌ 불가	-

기업이 특화 모델을 만드는 2가지 실전 경로

온프레미스 특화 모델 구축은 오픈웨이트 모델의 가중치를 자체 GPU 서버에서 파인튜닝하고, 동일 인프라에서 서빙까지 완결하는 데이터 주권 확보형 AI 운영 방식

AS-IS (기존 인식)

sequenceDiagram
    autonumber
    participant Dev as 기업
    participant Ollama as Ollama
    participant LLM as 특화 모델

    Dev->>Ollama: 올라마에서 모델 받아서 파인튜닝?
    Note over Ollama,LLM: Ollama가 파인튜닝도 하는 건지<br/>출처가 어딘지 불명확

TO-BE (실제 흐름)

sequenceDiagram
    autonumber
    participant HF as HuggingFace
    participant GPU as 자체 GPU 서버
    participant Serving as Ollama / vLLM

    HF->>GPU: 오픈웨이트 가중치 다운로드
    Note over GPU: LoRA / QLoRA 파인튜닝<br/>(도메인 특화 데이터)
    GPU->>Serving: 학습된 모델 로드
    Serving-->>GPU: 내부 API 서빙 (외부 통신 없음)

경로 A: Meta Llama / Mistral / Qwen 기반

오픈웨이트 생태계의 사실상 표준 경로. Llama 3.1이 기업 오픈소스 표준으로 자리잡았으며, AWS Bedrock, HuggingFace, Ollama 모두 통합 지원.

# 1. HuggingFace에서 가중치 다운로드
huggingface-cli download meta-llama/Llama-3.1-8B-Instruct \
  --local-dir ~/.llama/Llama-3.1-8B-Instruct
 
# 2. LoRA 파인튜닝 (싱글 GPU 가능)
python -m llama_cookbook.finetuning \
  --use_peft \
  --peft_method lora \
  --quantization 4bit \
  --model_name meta-llama/Llama-3.1-8B-Instruct \
  --custom_dataset.file "data/training.jsonl" \
  --output_dir ./finetuned_model
 
# 3. Ollama로 서빙
ollama serve  # localhost:11434, 외부 통신 없음

파인튜닝 도구 선택지:

도구	특징	추천 대상
Hugging Face TRL	RLHF, DPO 지원, 생태계 표준	ML 엔지니어 있는 팀
Unsloth	메모리 60% 절감, 2배 빠름	소형 GPU 환경
Axolotl	YAML 설정 기반, 최대 유연성	정밀 제어 필요 시
LLaMA-Factory	Web UI 제공, 코드 불필요	ML 엔지니어 없는 팀

라이선스 주의: Llama는 MAU 7억 초과 서비스 또는 타 LLM 학습 목적 사용 금지 조항 있음. 대부분의 기업에는 해당 없으나, 대형 서비스나 AI 회사는 확인 필요.

경로 B: OpenAI GPT-OSS 기반 (2025.08 신규)

OpenAI가 GPT-2 이후 처음 공개한 오픈웨이트 LLM. Apache 2.0 라이선스로 다운로드, 파인튜닝, 상업적 배포 모두 제약 없음.

# HuggingFace에서 다운로드
huggingface-cli download openai/gpt-oss-120b \
  --include "original/*" --local-dir gpt-oss-120b/
 
# Ollama로 서빙
ollama pull gpt-oss:120b
ollama run gpt-oss:120b  # 외부 통신 없음, API 비용 0원

GPT-OSS 성능 요약:

항목	gpt-oss-120b	gpt-oss-20b
비교 대상	OpenAI o4-mini 수준	OpenAI o3-mini 수준
MMLU	90%	85.3%
필요 VRAM	80GB (H100 1장)	16GB (RTX 4090급)
아키텍처	MoE (활성 5.1B/token)	MoE (활성 3.6B/token)
컨텍스트	128k	128k
라이선스	Apache 2.0	Apache 2.0

주의: 다국어 성능 취약 (중국어 기준 45% 미만). 한국어 집약적 서비스는 Qwen3 등 아시아 언어 특화 모델과 비교 필요.

비용 구조: 자체 서빙 시

모델 가중치 = 무료 (Apache 2.0 / Llama Community License) API 비용 = 0원 (외부 호출 없음) 실제 발생 비용 = 하드웨어

모델	필요 GPU	구매 비용 (참고)	클라우드 임대
gpt-oss-120b / Llama 70B	H100 80GB × 1	~4천만원	$23/시간
gpt-oss-20b / Llama 8B	RTX 4090 16GB × 1	~250만원	~$0.3/시간

월 2~3천만 토큰 이상 처리하는 경우, 자체 서빙이 API 대비 최대 93% 저렴해진다는 분석도 있음.

”Ollama에서 파인튜닝한다”는 표현의 정확한 이해

Ollama는 완성된 모델을 실행하는 런타임이지 파인튜닝 도구가 아님.

[잘못된 인식]
Ollama → 파인튜닝 → 서빙

[실제 흐름]
HuggingFace (가중치 원본)
    ↓ llama-cookbook / Unsloth / Axolotl로 파인튜닝
완성된 모델
    ↓ Ollama / vLLM에 로드
서빙 (localhost, 외부 통신 없음)

기업들이 “Llama를 올라마로 쓴다”고 할 때의 의미는, 파인튜닝 후 최종 서빙 단계에서 Ollama를 런타임으로 쓴다는 뜻.

실제 기업 도입 사례 (2025~2026)

글로벌 사례

Orange (프랑스 최대 통신사)

모델: GPT-OSS (OpenAI 공식 발표 파트너)
방식: 온프레미스 배포 — 민감 고객 데이터를 외부 전송 없이 내부망에서 처리
출처: OpenAI 공식 발표에서 파트너로 명시

AI Sweden (스웨덴 국가 AI 기관)

모델: GPT-OSS 기반 스웨덴어 파인튜닝
방식: 자국 언어·문화 특화 모델로 파인튜닝 후 국가 인프라에 자체 서빙
출처: OpenAI 공식 발표 (“localized fine-tuning on the country’s language”)

HSBC / BNP Paribas (글로벌 금융)

모델: Mistral
방식: EU GDPR·금융 규제 환경에서 데이터 주권 확보를 위한 온프레미스 배포
배경: 외부 API 사용 불가 규제 산업 — Mistral Apache 2.0 라이선스 채택

Oxide AI (기술 스타트업)

모델: Meta Llama + LoRA 파인튜닝
방식: 도메인 특화 데이터로 LoRA 학습, 1개월 후 95% 정확도 달성
성과: GPT-4 대비 37% 빠른 응답속도, 컴퓨팅 비용 대폭 절감
출처: Meta Llama 공식 케이스 스터디

Snowflake (데이터 플랫폼)

모델: GPT-OSS
방식: Arctic Inference + Speculative Decoding으로 추론 속도 1.7~1.8배 향상
출처: Snowflake Engineering Blog 공식 발표

국내 사례

SK텔레콤 — A.X 시리즈

모델: Qwen 2.5 기반 파인튜닝 + 자체 확장 학습
방식: 중국 오픈웨이트 모델을 베이스로 한국어·문화 특화 학습
성과: KMMLU 78점, CLIcK 83점 — 한국어 벤치마크에서 GPT-4o 이상
공개: HuggingFace 오픈소스 공개 (AX 3.1 Lite)

Upstage — Solar

모델: Meta Llama 기반 Continual Training
방식: 기존 Llama 가중치에서 시작, 한국어 성능 강화를 위한 추가 학습
배경: 처음부터 학습하는 것보다 비용·시간 효율적인 방법론 채택

LG AI Research — Exaone

모델: 자체 학습 (처음부터 구축)
방식: 금융·제약·제조 엔터프라이즈 워크플로우 자동화 목적
공개: HuggingFace에 가중치 일부 공개

Kakao — Kanana

모델: 자체 학습 (공개 데이터 기반)
방식: Nano(2.1B) / Essence(9.8B) / Flag(32.5B) 라인업, 멀티모달 지원
공개: Kanana 1.5 오픈소스 공개

공통 패턴 요약

패턴	설명	해당 사례
오픈웨이트 베이스 + 파인튜닝	Llama/Qwen 등을 받아 도메인 특화 학습	SK텔레콤, Upstage, Oxide AI
GPT-OSS 온프레미스	OpenAI 공개 모델을 자체 서버에서 서빙	Orange, AI Sweden, Snowflake
처음부터 자체 학습	대기업이 독자 모델 개발	LG, Naver, Kakao
금융/통신 규제 대응	GDPR·금융 규제로 온프레미스 필수	HSBC, BNP Paribas, Orange

참고 문서

2026-04-18 심화: B2B AI 서비스 온프레미스 배포 구조

기존 정리(Phase 1/2)가 “모델 온프레미스”에 집중했다면, 이 섹션은 AI 서비스 전체를 고객사에 배포하는 인프라 구조를 다룬다.

컴포넌트별 위치 원칙

핵심 원칙: 고객 기밀 데이터는 고객 네트워크 밖으로 나가면 안 된다.

컴포넌트	위치	이유
Local LLM	고객사 서버	프롬프트/응답에 기밀 포함
RAG (Vector DB)	고객사 서버	기밀 문서 인덱싱
Internal Tools	고객사 네트워크	사내 시스템 직접 접근
LangGraph Agent	고객사 서버	LLM/RAG/Tool 오케스트레이션
FastAPI AG-UI 서버	고객사 서버	데이터가 외부로 나가지 않음
CopilotKit UI	고객사 내부망 또는 우리 CDN	이벤트만 전달, 원본 데이터 없음
라이선스 서버	우리 클라우드	인증만, 데이터 없음

인프라 구조 다이어그램

graph TD
    subgraph Customer["🏢 고객사 네트워크 (방화벽 내부)"]
        LLM["🤖 Local LLM (Ollama/vLLM)"]
        RAG["📚 RAG (Vector DB)"]
        Tools["🔧 Internal Tools (사내 DB, API)"]
        LG["⚙️ LangGraph Agent + FastAPI AG-UI 서버"]
        UI["🖥️ CopilotKit UI (브라우저)"]

        LLM --> LG
        RAG --> LG
        Tools --> LG
        LG -->|AG-UI 이벤트 스트림| UI
    end

    subgraph Ours["☁️ 우리 클라우드"]
        Registry["📦 Private Registry (Docker Image)"]
        License["🔐 라이선스 서버"]
    end

    Customer -->|Outbound만 허용 / 이미지 Pull| Registry
    Customer -->|라이선스 검증| License

기술 스택 레이어

CopilotKit React UI         ← 사용자 인터페이스
      ↕ AG-UI 프로토콜 (SSE)
FastAPI + LangGraphAgent    ← AG-UI 이벤트 변환 서버
      ↕ Python 객체 참조
LangGraph CompiledGraph     ← 에이전트 오케스트레이션
      ↕
Local LLM (Ollama/vLLM)    ← 추론 엔진
+ RAG (Vector DB)
+ Internal Tools

LangGraph workflow.compile() 은 파일이 아닌 Python 객체를 반환한다. 이 객체를 LangGraphAgent에 전달하고 FastAPI에 엔드포인트로 등록하면 AG-UI 프로토콜 서버가 된다. 모두 같은 Python 프로세스(uvicorn) 안에서 동작한다.

고객사 배포 형태 (우리가 제공하는 것)

우리가 패키징해서 제공:
├── Docker Image / Helm Chart
│     ├── LangGraph Agent 코드
│     ├── FastAPI AG-UI 서버
│     └── CopilotKit UI 빌드 산출물
│
└── 라이선스 키 (우리 클라우드에서 검증)

고객사 담당자는 Helm Chart 또는 docker-compose 파일로 자사 서버에 설치한다.

원격 업데이트 방식 (방문 없이)

Pull 방식이 표준이다. 우리가 고객사 내부에 접근하는 것이 아니라, 고객사 서버가 우리 Registry에서 새 이미지를 당겨온다.

1. 우리: 코드 수정 → Docker Image 빌드 → Private Registry push (v1.1.0)
2. 고객사 K8s (ArgoCD/FluxCD): 새 버전 감지 → 담당자 승인 → 자동 배포
3. 방화벽: Outbound만 허용, Inbound 전체 차단

업데이트 방식	고객 개입	보안	적합 상황
자동 Pull (ArgoCD)	없음	중간	빠른 업데이트 필요
승인 후 Pull	승인만	높음	일반 B2B 권장
완전 수동	직접 설치	최고	군/금융/완전 폐쇄망

보안 방화벽 설계 원칙

절대 고객사 밖으로 나가면 안 되는 것:
  - RAG 문서 원본 및 인덱스
  - LLM 프롬프트 / 응답
  - Internal Tool 실행 결과
  - 사내 API 키 / 자격증명

나가도 되는 것:
  - 이미지 Pull 요청 (our-registry.io)
  - 라이선스 검증 요청 (데이터 없음)
  - CopilotKit UI 정적 파일 (CDN, 코드만)

우리 서비스 발전을 위한 학습 데이터 확보 전략

온프레미스 B2B에서 고객 기밀을 지키면서도 서비스를 발전시키기 위한 핵심 원칙: 데이터 자체가 아닌, 데이터에서 파생된 것을 가져온다.

방법 1: 암묵적 신호 기반 수집 (액션 불필요)

thumbs up/down 같은 명시적 피드백은 수집률이 5~15%에 불과하다. 대신 대화 패턴에서 자동으로 신호를 읽는다.

실패 신호 (자동 감지)
  - 같은 질문을 다시 함 (재시도)
  - "그게 아니라", "틀렸어" 등 부정어로 시작하는 다음 메시지
  - 답변 직후 세션 이탈
  - 도구 호출 오류 발생

성공 신호 (자동 감지)
  - 답변 후 다음 단계 질문으로 자연스럽게 이어짐
  - 세션이 길게 지속됨
  - 같은 유형 질문 반복 사용

구체적 예시 — 고객사: 로펌

변호사가 AI 에이전트에게 판례 분석을 요청한다.

실제 대화 (고객사 내부, 외부 전송 안 됨)
  사용자: "삼성전자 vs 애플 2024 특허소송 판례 분석해줘"
  에이전트: "해당 판례에서 삼성은... (3페이지 분량)"
  사용자: "그게 아니라..." (부정어로 시작 → 실패 신호 자동 감지)

우리에게 전송되는 것 (익명화 후):

{
  "query_type": "판례 분석",
  "domain": "특허/IP법",
  "tools_used": ["RAG", "search"],
  "result": "retry",
  "retry_count": 2,
  "session_duration_sec": 45
}

기업명, 실제 질문 내용, 응답 원문은 전송하지 않는다. 우리가 배우는 것: “특허 판례 분석” 유형에서 실패율이 높다 → RAG 개선 또는 프롬프트 수정 필요.

방법 2: 합성 데이터 생성 (thumbs 무관, 모든 대화에 자동 적용)

온프레미스의 Local LLM이 실제 대화를 기반으로 합성 Q&A를 자동 생성한다. 원본은 삭제하고 합성본만 전송한다.

모든 대화 종료 시 자동 실행:
실제 대화 → Local LLM이 합성본 생성 → 원본 삭제 → 합성본만 전송

구체적 예시 — 고객사: 병원

의사가 진단 보조 AI를 사용한다.

실제 대화 (절대 외부 전송 안 됨)
  사용자: "박○○ 환자, 52세 남성, 당뇨 병력, 혈당 350, 케톤 양성. 처치는?"
  에이전트: "DKA 의심, 즉시 IV 인슐린 투여 후..."

온프레미스 Local LLM이 합성본 자동 생성:
  Q: "60대 여성, 고혈압 병력, 혈당 320, 케톤 양성. 처치는?"
  A: "DKA 가능성 높음. 수액 보충 후 인슐린..."

원본 삭제 → 합성본만 우리에게 전송

원본과 유사한 패턴을 담지만 실제 데이터가 아니므로 법적 리스크가 낮다. 우리가 배우는 것: DKA 증상 패턴에서 에이전트가 어떤 응답을 해야 좋은지 → 모델/프롬프트 개선.

방법 3: 연합학습 Federated Learning (규모 커진 후)

각 고객사에서 로컬 학습 후 Gradient(기울기 숫자 배열)만 전송한다. 원본 데이터는 절대 외부로 나가지 않는다.

구체적 예시 — 고객사: 은행 A, 은행 B, 보험사 C

은행 A 온프레미스:
  대출 심사 Q&A 1만 건으로 로컬 학습
  → Gradient(숫자 배열)만 추출해서 전송
  예) weight[0]: +0.003, weight[1]: -0.007, ...

은행 B, 보험사 C도 동일하게 각자 로컬 학습 후 Gradient만 전송

우리 서버:
  3곳의 Gradient 집계 (Federated Averaging)
  → 개선된 모델 가중치 생성
  → 각 고객사에 업데이트된 모델 배포 (데이터는 이동 없음)

Gradient는 “모델이 어느 방향으로 얼마나 조정해야 하는지”의 숫자로, 원본 데이터를 역산하기 매우 어렵다. Google(Gboard), Apple이 사용하는 방식. 구현 난이도가 높아 스타트업에는 나중 단계에 해당한다.

현실적 도입 로드맵

Phase 1: 암묵적 신호 + Opt-in 익명화 수집 (계약서 명시, 구현 2주)
              ↓
Phase 2: 합성 데이터 파이프라인 추가 (구현 1~2개월)
              ↓
Phase 3: 연합학습 도입 (고객사 10곳+ 이후)

Explorer

날짜별 보기

2026년 (114)

2025년 (8)

온프레미스 B2B AI 제공

온프레미스의 의미

스타트업이 온프레미스를 제공하는 현실적 방법

모델 선택

배포 방식

”OpenAI급 성능을 쓰고 싶다” vs 온프레미스

벤더 의존성과 AI 하네스

스타트업의 B2B 가치 제공 (Phase 분리)

Phase 1: AI Harness (초기, 벤더 LLM 기반)

Phase 2: Open-weight Training (추후, 온프레미스 전환)

수집 데이터의 용도

데이터 파이프라인 시퀀스

단계별 요약

Phase 1 (AI Harness)

Phase 2 (Open-weight Training)

평가 체계 자동화 (선택사항)

2026-03-30 심화: 온프레미스 AI 실전 구축 방법

업데이트: GPT-OSS 출시로 기존 정리 일부 수정 필요

기업이 특화 모델을 만드는 2가지 실전 경로

AS-IS (기존 인식)

TO-BE (실제 흐름)

경로 A: Meta Llama / Mistral / Qwen 기반

경로 B: OpenAI GPT-OSS 기반 (2025.08 신규)

비용 구조: 자체 서빙 시

”Ollama에서 파인튜닝한다”는 표현의 정확한 이해

실제 기업 도입 사례 (2025~2026)

글로벌 사례

Orange (프랑스 최대 통신사)

AI Sweden (스웨덴 국가 AI 기관)

HSBC / BNP Paribas (글로벌 금융)

Oxide AI (기술 스타트업)

Snowflake (데이터 플랫폼)

국내 사례

SK텔레콤 — A.X 시리즈

Upstage — Solar

LG AI Research — Exaone

Kakao — Kanana

공통 패턴 요약

참고 문서

2026-04-18 심화: B2B AI 서비스 온프레미스 배포 구조

컴포넌트별 위치 원칙

인프라 구조 다이어그램

기술 스택 레이어

고객사 배포 형태 (우리가 제공하는 것)

원격 업데이트 방식 (방문 없이)

보안 방화벽 설계 원칙

우리 서비스 발전을 위한 학습 데이터 확보 전략

방법 1: 암묵적 신호 기반 수집 (액션 불필요)

방법 2: 합성 데이터 생성 (thumbs 무관, 모든 대화에 자동 적용)

방법 3: 연합학습 Federated Learning (규모 커진 후)

현실적 도입 로드맵

참고 문서

Graph View

Table of Contents

Backlinks