새로 나온 모델 · 2026.10.05
Xing4.0 로컬 실행: 코딩 모델 설치와 GPU·메모리 선택
코딩 요청을 보내기 전에 29B 전체 모델이 들어갈 GPU와 실행기를 정해요.
Xing4.0-29B-A4B는 전체 29B 파라미터 가운데 토큰1마다 약 4B를 활성화하는 MoE2 에이전트 모델이에요. 제작자는 2026-09-17 BF163·FP84·GGUF5 공개를 기록하고, Apache-2.0 라이선스와 코딩·도구 호출6용 경로를 제공해요. 4B 활성 수치가 전체 가중치를 4B만 저장하거나 메모리에 올린다는 뜻은 아니에요. 공식 vLLM 예시는 tensor parallel7 2와 256K 문맥을 사용하지만, 메인 런타임8 지원 PR은 아직 검토 중이라고 저장소에 적혀 있어요.
29B 모델이 토큰마다 약 4B 전문가를 골라 써요
Xing4.0-29B-A4B는 코드를 읽고 수정안을 만들며 도구 호출을 이어 가도록 설계한 오픈웨이트 에이전트 모델이에요. 파일의 전체 크기는 약 29B 파라미터고, MoE 구조가 토큰을 계산할 때 활성화하는 양은 약 4B예요. 에이전트 프레임워크에서 코드와 오류 기록을 보내면 모델이 다음 행동이나 코드 응답을 생성하고, 별도의 실행기가 그 도구를 실제로 호출해요. 제작자 공식 모델 카드
이 글에서는 오류를 고치기 위해 저장소의 세 파일을 읽고, 테스트를 실행한 뒤 바뀐 내용을 설명하는 작업을 이어서 살펴볼게요. 모델은 tool calling과 256K context를 지원한다고 소개되지만, 실제 작업에는 코드 실행기, 저장소 권한, 지원 runtime이 별도로 필요해요. 모델의 점수만으로 파일 편집·테스트·되돌리기까지 잘 수행한다고 판단할 수는 없어요.

4B 활성 수치에서 VRAM을 계산하지 마세요
활성 파라미터는 각 토큰 계산에서 선택되는 전문가의 규모를 설명해요. 나머지 전문가를 메모리에서 없애 주지는 않아요. 가중치 전체를 BF16으로 단순 환산하면 29B×2 byte≈58GB예요. 이 계산은 파일을 구성하는 가중치의 대략적인 데이터 양일 뿐, 실제 체크포인트9 크기나 실행 메모리를 재는 실측값은 아니에요. KV cache10, runtime, 작업 여유도 추가로 들어가요.
그래서 메모리 검토는 정밀도와 배포 파일부터 시작해요. 공식 저장소에는 BF16 원본뿐 아니라 FP8과 GGUF 배포본이 2026년 9월 17일 공개됐다고 기록되어 있어요. 형식별 파일 크기는 서로 다르지만, GGUF가 있다는 사실만으로 특정 GPU11에서 실행 가능하다는 결론을 낼 수는 없어요. 선택한 런타임이 해당 architecture와 파일 양자화12를 지원하는지도 확인해야 해요. 공식 공개 기록
| 수치 | 의미 | 장비 판단에서 쓸 때 |
|---|---|---|
| 29B 전체 | 체크포인트 전체 전문가·가중치 규모 | 파일·메모리 조건 확인 |
| 약 4B 활성 | 토큰 계산에서 선택되는 전문가 규모 | 생성 연산량 이해에 사용 |
| 약 58GB BF16 산술값 | 29B×2 byte로 계산한 가중치 데이터 추정 | 실행 최소 메모리로 보지 않음 |
모델 메모리를 따질 때 전체 가중치와 토큰당 계산량을 나눠요.
29B 전체
- 의미
- 체크포인트 전체 전문가·가중치 규모
- 장비 판단에서 쓸 때
- 파일·메모리 조건 확인
약 4B 활성
- 의미
- 토큰 계산에서 선택되는 전문가 규모
- 장비 판단에서 쓸 때
- 생성 연산량 이해에 사용
약 58GB BF16 산술값
- 의미
- 29B×2 byte로 계산한 가중치 데이터 추정
- 장비 판단에서 쓸 때
- 실행 최소 메모리로 보지 않음

코딩 에이전트 점수에는 도구와 실행 조건이 들어가요
모델 카드에서 SWE-bench Verified는 75.0으로 제시돼요. 제작자는 `SWE-agent`, temperature 1.0, top_p 0.95, repetition penalty 1.05, 210K context로 평가했다고 적었어요. 이 점수는 모델이 저장소 안에서 문제를 해결하는 에이전트 평가 결과이므로, 단일 코드 생성 응답이나 로컬 tok/s와는 다른 지표예요. Xing4.0 공식 평가 설명
Terminal-Bench 2.1 점수는 57.5예요. 이 평가는 `terminus-2`, temperature 0.8, top_p 0.95, repetition penalty 1.05, 최대 64K output token, 과제별 24시간 제한으로 실행해 세 번 평균을 보고했어요. 긴 제한 시간과 에이전트 도구가 포함된 결과라서, 모델이 한 줄을 얼마나 빨리 쓰는지 보여 주지는 않아요. 내 저장소에서 사용할 때는 수정 성공률, 테스트 통과 여부, 허용한 도구 범위를 따로 기록해요.
| 평가 | 공식 평가 점수 | 핵심 조건 |
|---|---|---|
| SWE-bench Verified | 75.0 | SWE-agent, 문맥 210K, temp 1.0; 나머지 설정은 공식 카드 참조 |
| Terminal-Bench 2.1 | 57.5 | terminus-2, 최대 출력 64K, 과제당 24시간, 3회 평균 |
공식 점수는 서로 다른 코딩 에이전트 시험의 결과예요.
SWE-bench Verified
- 공식 평가 점수
- 75.0
- 핵심 조건
- SWE-agent, 문맥 210K, temp 1.0; 나머지 설정은 공식 카드 참조
Terminal-Bench 2.1
- 공식 평가 점수
- 57.5
- 핵심 조건
- terminus-2, 최대 출력 64K, 과제당 24시간, 3회 평균
메인 runtime 지원은 아직 병합 전 경로를 확인해야 해요
Xing 제작자 저장소는 Transformers 경로와 vLLM·SGLang·KTransformers 구성을 안내해요. 동시에 2026-10-05 확인 당시 vLLM, SGLang, llama.cpp 등의 upstream support pull request가 아직 병합 전이라고 적혀 있어요. 따라서 패키지의 기본 최신판에 Xing 지원이 이미 들어 있다고 가정하지 말고, 공식 저장소가 가리키는 PR 브랜치나 사전 빌드 컨테이너를 선택해요. 공식 실행 경로와 PR 상태
코드 실행 권한도 모델과 분리해요. 읽기 전용으로 시작한 뒤, 테스트 실행만 추가하고, 실제 파일을 고치는 권한은 diff를 확인할 수 있을 때 부여해요. agent framework가 저장소와 터미널을 연결하더라도 모델 출력만으로 명령이 자동 실행되는지, 중간 승인 절차가 있는지 먼저 확인해야 해요. 에이전트 점수는 내 도구 권한 설정의 안전성이나 실제 저장소에서의 수정 성공을 대신 측정하지 않아요.
python -m venv .venv
source .venv/bin/activate
pip install -U torch transformers accelerate huggingface_hub
hf download XingChen-AGI/Xing4.0-29B-A4B공식 Transformers 예시로 짧은 코드 질문을 보내요
공식 저장소는 `trust_remote_code=True`를 넣은 Transformers 로드 예시를 제공합니다. 이 설정은 저장소가 제공하는 모델 코드를 사용하므로 공식 모델 파일을 검토한 환경에서 실행해요. 아래 예시는 질문을 고정하고 최대 1024 token을 생성해 로드와 응답 형식을 확인하는 짧은 시작점이에요. 실제 저장소 작업에서는 필요한 설명과 코드 변경 범위에 맞춰 출력 제한을 조정해요. Xing 공식 Transformers quickstart
정상 실행되면 짧은 Python 오류 설명이 터미널에 표시돼요. 모델 구조를 지원하지 않는다는 오류는 설치한 Transformers의 호환성을 확인하고, 일반 OOM은 BF16 가중치만 단순 환산해도 약 58GB라는 점과 입력 문맥·실행기 메모리를 함께 살펴요. `max_new_tokens`를 줄이는 것은 생성 길이를 낮출 뿐, 이미 가중치 로드 단계에서 난 메모리 부족을 해결하지 못할 수 있어요. 공식 모델 구조와 실행 예시
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "XingChen-AGI/Xing4.0-29B-A4B"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
model_id, trust_remote_code=True, device_map="auto", dtype=torch.bfloat16
)
messages = [{"role": "user", "content": "Explain this Python error and suggest a minimal fix: KeyError: 'id'"}]
prompt = tokenizer.apply_chat_template(
messages, tokenize=False, add_generation_prompt=True
)
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
with torch.inference_mode():
output = model.generate(
**inputs, do_sample=True, top_p=0.95, temperature=0.8,
repetition_penalty=1.05, max_new_tokens=1024
)
print(tokenizer.decode(
output[0][inputs.input_ids.shape[-1]:],
skip_special_tokens=False, spaces_between_special_tokens=False
))vLLM 레시피는 2개 GPU와 제한된 동시 요청을 사용해요
제작자의 vLLM 시작 예시는 `--tensor-parallel-size 2`, `--gpu-memory-utilization 0.90`, `--max-model-len 262144`, `--max-num-seqs 4`를 지정해요. 이는 두 GPU에 분할하는 serving 경로와 최대 네 sequence 설정이에요. 모든 prompt를 256K까지 넣으라는 의미는 아니고, 긴 context는 KV cache 메모리도 늘려요. 먼저 사용할 prompt 길이와 동시 사용자를 정하고, 그 설정이 메모리에 들어가는지 검사해야 해요. 공식 vLLM 명령과 기본 설정
제작자가 제시한 KTransformers 예시는 CPU13와 GPU를 함께 쓰는 이기종 실행 경로예요. GPU에 둘 expert 수와 CPU 추론 thread 설정도 들어 있어요. 따라서 ‘한 GPU에서 실행 가능’은 GPU 메모리만으로 전체 가중치를 올린다는 뜻이 아니라, 선택한 실행기가 일부 처리를 CPU에 배분할 수 있다는 뜻일 수 있어요. 정확한 RAM14 최소치와 추론 속도는 공식 자료에서 확인하지 못했으므로 실행 환경에서 별도로 측정해야 해요.
서버가 준비되면 vLLM API15가 `http://localhost:8000/v1`에서 응답해요. 시작 단계에서 모델 구조나 parser 오류가 나면 일반 vLLM 대신 제작자 prebuilt image 또는 저장소가 연결한 PR branch를 쓰는지 확인해요. OOM이면 요청 문맥·동시 sequence 수부터 줄이고, 두 GPU가 모두 보이는지 점검해요. 이 조정 후의 처리 속도는 직접 측정하기 전까지 미확인으로 남겨요. 공식 vLLM 설정과 지원 경로
| 경로 | 확인된 설정 | 아직 확인할 점 |
|---|---|---|
| Transformers | device_map=auto, BF16 예시 | 실제 메모리 배치와 지원 하드웨어 |
| vLLM | TP=2, 최대 문맥 256K, sequence 최대 4개 | upstream PR 미병합, 공식 PR branch/image |
| KTransformers | CPU/GPU 혼합 설정 예시 | 시스템 RAM과 처리 시간은 미공개 |
공식 serving 경로가 전제하는 실행 구성을 비교해요.
Transformers
- 확인된 설정
- device_map=auto, BF16 예시
- 아직 확인할 점
- 실제 메모리 배치와 지원 하드웨어
vLLM
- 확인된 설정
- TP=2, 최대 문맥 256K, sequence 최대 4개
- 아직 확인할 점
- upstream PR 미병합, 공식 PR branch/image
KTransformers
- 확인된 설정
- CPU/GPU 혼합 설정 예시
- 아직 확인할 점
- 시스템 RAM과 처리 시간은 미공개

코드 작업에 맞는지 작은 저장소 작업으로 판단해요
처음 예시의 Python `KeyError: 'id'` 설명이 출력되면, 다음에는 저장소의 작은 오류 하나를 읽기 전용으로 조사해요. 재현 명령과 관련 파일을 모델에 보내고, 어떤 테스트를 실행할지 제안하도록 요청해요. 에이전트가 직접 파일을 바꾸기 전에 답에서 파일 경로·원인·검증 절차가 서로 연결되는지 확인해요. 이후에만 제한된 폴더에서 편집 권한을 켜고 변경 diff와 테스트 결과를 사람이 읽어요.
장비 선택에서는 모델 파일을 내려받을 공간, 가중치와 입력을 메모리에 올릴 공간, 평소 쓸 앱이 남을 공간을 함께 계산해요. 공식 TP=2 경로를 쓰려면 GPU 두 장과 런타임 환경이 필요하고, KTransformers의 CPU/GPU 혼합 구성은 GPU 메모리가 부족할 때 다른 메모리 자원을 사용하지만 그 대가로 완료 시간이 달라질 수 있어요. 이 모델을 반드시 써야 하는 작업이 아니라면, 현재 GPU에 맞는 더 작은 코딩 모델과 같은 저장소 이슈를 비교하는 편이 비용 판단에 도움이 돼요.
용어 각주
토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.
본문으로 돌아가기MoE — 여러 전문가 하위망 중 일부를 입력에 따라 선택해 사용하는 모델 구조입니다. 총 파라미터 수와 한 토큰 처리에 활성화되는 파라미터 수는 다를 수 있습니다.
본문으로 돌아가기BF16 — 모델의 수를 저장하고 계산하는 16비트 부동소수점 형식입니다. 사용 가능 여부는 하드웨어와 실행 프로그램에 달려 있습니다.
본문으로 돌아가기FP8 — 8비트 부동소수점 수치 형식 계열입니다. 세부 형식과 지원 범위는 하드웨어 및 소프트웨어에 따라 다릅니다.
본문으로 돌아가기GGUF — 모델 정보를 담는 파일 형식으로 llama.cpp 계열 도구에서 널리 사용됩니다.
본문으로 돌아가기도구 호출 — 모델이 파일 읽기·검색·명령 실행 같은 외부 기능의 이름과 인자를 요청하는 형식입니다. 요청을 실제로 실행할지는 에이전트 런타임과 권한 설정이 결정합니다.
본문으로 돌아가기텐서 병렬 — 모델 층 안의 연산과 가중치를 여러 장치에 나누는 방식입니다. 계산을 나누는 만큼 장치 간 통신도 필요하므로 속도 향상은 연결과 구현에 영향을 받습니다.
본문으로 돌아가기런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.
본문으로 돌아가기체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.
본문으로 돌아가기KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.
본문으로 돌아가기GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.
본문으로 돌아가기양자화 — 모델의 수치를 더 적은 비트로 표현하는 방법입니다. 메모리 사용량과 함께 정확도나 실행 속도도 달라질 수 있으며, 영향은 형식과 구현에 따릅니다.
본문으로 돌아가기CPU — 컴퓨터에서 일반적인 프로그램 명령을 실행하는 중앙 처리 장치입니다. AI 작업에서는 GPU 등 다른 프로세서와 역할을 나누기도 합니다.
본문으로 돌아가기시스템 RAM — 프로그램이 실행되는 동안 데이터를 임시로 보관하는 시스템 메모리입니다.
본문으로 돌아가기API — 프로그램의 기능을 다른 코드에서 호출하기 위한 약속된 인터페이스입니다.
본문으로 돌아가기
