Furiosa-LLM 2026.3.0에서 FXB 빌드 이해하기

TL;DR

공개 FXB가 있으면 빌드 전 fxb download, fxb check로 재사용 가능 여부 확인
직접 빌드 필요시 fxb build --dry-run으로 bucket plan을 확인
빠른 검증은 O0/O1, production 은 O3 기준
--max-model-len은 원본 모델의 context window 안에서 서비스할 최대 context 길이

1. Furiosa SDK 2026.3.0 변경점

2026.2.0까지 Furiosa-LLM에서 LLM 컴파일을 다룰 때는 ArtifactBuilder와 bucket 설정을 직접 만지는 흐름이 중요했다. 사용자가 prefill, decode, append bucket 및 tokenwise sequence length를 직접 설계해야 했고, 이 값들이 성능과 실행 shape에 어떤 영향을 주는지 이해해야 했다.

2026.3.0에서는 FXB가 중심이 되면서 흐름이 더 단순해졌다. 사용자가 bucket list를 직접 넘기기보다, 공개 FXB를 재사용할 수 있는지 먼저 확인하고, 직접 빌드가 필요할 때 fxb build가 모델 preset과 max-model-len, optim-level, parallelism 옵션을 바탕으로 build plan을 만든다.

~2026.2.0: 사용자가 bucket을 직접 설계한다
2026.3.0: fxb build가 모델 preset과 옵션을 바탕으로 bucket plan을 만든다

기존 방식은 자유도가 높지만 진입장벽도 높았다. 2026.3.0의 FXB 흐름은 bucket 튜닝을 완전히 숨기지는 않지만, 사용자가 처음부터 모든 bucket을 설계해야 하는 부담을 크게 줄인다.

2. FXB란?

RNGD에서 Furiosa-LLM으로 LLM을 서빙하려면 모델을 NPU에서 실행할 수 있는 형태로 준비해야 한다. 2026.3.0 기준 기본 산출물은 FXB, 즉 Furiosa Executable Bundle이다.

FXB는 Furiosa-LLM의 compiled-artifact format이다. .fxb 파일 하나에 특정 모델 architecture용으로 컴파일된 binary와 실행 metadata가 함께 들어간다. 공식 문서 기준으로 FXB는 architecture fingerprint가 같은 모델끼리 재사용할 수 있다. 즉 같은 architecture와 kernel 생성에 영향을 주는 config field가 일치하면, fine-tuned model이나 weight만 갱신된 모델도 같은 FXB를 다시 사용할 수 있다.

단, fingerprint matching은 엄격하다. hidden_size, attention head, MoE expert 설정, quantization format처럼 kernel 생성에 영향을 주는 값이 다르면 같은 모델 계열처럼 보여도 FXB를 공유하면 안 된다. 재사용 가능 여부는 fxb check로 확인할 수 있다.

FXB 안의 kernel

여기서 kernel은 Linux kernel이 아니라, NPU에서 실행되는 shape-specialized 실행 단위다. LLM 실행에서는 크게 tokenwise 계산과 attention 계산을 본다.

Tokenwise 계산은 각 token 위치에서 독립적으로 수행되는 계산이다. embedding, layer norm, linear projection, MLP, lm_head가 여기에 들어간다. fxb inspect에서 tw1, tw16, tw1024 같은 이름이 보이면 tokenwise sequence length별 kernel로 이해할 수 있다.

Attention 계산은 현재 token이 이전 token 또는 KV cache를 참조하는 계산이다. decode 단계에서는 새 token 1개가 이전 KV cache 전체를 바라봐야 하므로, attention kernel은 batch size, attention size, KV cache length에 민감하다. fxb inspect에서 b1_a1024_kv512 같은 이름이 보이면 대략 batch 1, attention size 1024, KV cache length 512를 처리하는 attention kernel이라고 보면 된다.

FXB kernel 수가 의미하는 것

kernel 수가 늘어나면 더 다양한 요청 shape를 처리할 실행 경로가 늘어난다. 대신 빌드 시간, FXB 파일 크기, 검증해야 할 shape 수가 늘어난다.

kernel 수 증가가 곧 모델 weight 크기 증가를 의미하지는 않는다. 실제 모델 weight는 GB 단위이고, FXB 실행 번들의 증가는 그에 비하면 작은 편이다. FXB 파일 크기 자체보다 어떤 실행 shape를 포함하는지가 더 중요한 판단 기준이다.

3. FXB 빌드 흐름

check/download

가장 먼저 공개 FXB나 로컬 cache에 있는 compatible FXB를 확인한다. FuriosaAI가 공개한 pre-compiled FXB가 있거나, 같은 architecture fingerprint를 가진 FXB가 cache에 있다면 기존 FXB를 재사용할 수 있다.

fxb download furiosa-ai/Qwen3-8B-FP8
fxb check Qwen/Qwen3-8B-FP8
furiosa-llm serve Qwen/Qwen3-8B-FP8

fxb download는 Hugging Face Hub에 공개된 FXB를 cache로 가져온다. fxb check는 대상 모델의 config.json에서 fingerprint를 만들고, cache에 있는 FXB 중 compatible bundle을 찾는다.

직접 빌드가 필요한 경우는 보통 다음과 같다.

공개 FXB가 없는 모델을 서빙한다.
같은 모델이라도 원하는 -tp, --max-model-len, --optim-level 조합이 다르다.
배포할 RNGD topology에 맞춰 새 FXB를 고정해야 한다.

dry-run

직접 빌드를 진행하기에 앞서 dry-run으로 bucket plan을 확인할 수 있다.

fxb build Qwen/Qwen3-4B-FP8 \
  /data/furiosa/fxb-seq/qwen3-4b-test.fxb \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 1 \
  --max-model-len 8192 \
  --optim-level O1 \
  --dry-run

--dry-run은 실제 컴파일을 수행하지 않고, 어떤 bucket plan으로 빌드될지 보여준다.

예를 들면 다음과 같은 출력이 나온다.

── Buckets (13 total, 19 kernels) ──────
  - kv_cache_blocks      8192
  - tokenwise            [1, 16, 1024]
  - prefill (2):
      - batch=1    attn=384      input_ids=384
      - batch=1    attn=1024     input_ids=1024
  - decode (4):
      - batch=1    attn=2048     input_ids=1
      - batch=1    attn=8192     input_ids=1
      - batch=2    attn=2048     input_ids=1
      - batch=2    attn=8192     input_ids=1
  - append (4):
      - batch=1    attn=512      input_ids=128
      - batch=1    attn=512      input_ids=384
      - batch=1    attn=8192     input_ids=384
      - batch=1    attn=8192     input_ids=1024

Buckets: FXB에 포함될 실행 shape 묶음 수
kernels: 실제 컴파일될 NPU 실행 단위 수
tokenwise: tokenwise 계산을 처리할 sequence length
prefill: prompt를 처음 처리할 때의 batch/attention/input shape
decode: token을 하나씩 생성할 때의 batch/attention shape
append: KV cache에 새 token block을 붙이는 단계의 shape

이 단계에서 unsupported 모델, 잘못된 max-model-len, 예상보다 큰 bucket plan을 빠르게 확인한다. 긴 빌드 전에 --dry-run을 먼저 실행한다.

build

dry-run 결과가 의도와 맞으면 빌드를 진행한다.

fxb build Qwen/Qwen3-4B-FP8 \
  /data/furiosa/fxb-seq/Qwen3-4B-FP8-tp8-o2-ctx1024.fxb \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 1 \
  --max-model-len 1024 \
  --optim-level O2 \
  --build-report

fxb build는 bucket을 직접 넘기는 CLI가 아니다. 모델 preset과 주요 옵션을 바탕으로 build plan을 만든다.

옵션	용도
`model`	Hugging Face model id 또는 로컬 모델 경로. 로컬 경로는 `.` 또는 `/`로 시작해야 한다.
`output_path`	`.fxb` 파일을 쓸 경로. 확장자가 없으면 `.fxb`가 자동으로 붙는다.
`-tp`, `--tensor-parallel-size`	tensor parallel group당 PE 수. 기본값은 모델 preset을 따르며, 빌드된 FXB의 kernel shape에 영향을 준다.
`-pp`, `--pipeline-parallel-size`	pipeline parallel size. 기본값은 `1`이다.
`--max-model-len`	bucket filtering에 사용할 최대 context length. 원본 모델의 최대 context 대신 이 값을 기준으로 bucket을 고른다.
`-O`, `--optim-level`	bucket filtering optimization level. `O0`, `O1`, `O2`, `O3`를 사용할 수 있고 기본값은 `O3`이다.
`--dry-run`	실제 컴파일 없이 config와 bucket plan을 해석해 build summary만 출력한다.
`--build-report`	빌드 후 kernel별 compile time report를 출력한다.
`--concurrency`	동시에 실행할 kernel compilation 수. 런타임 동시 요청 수가 아니라 빌드 머신의 CPU/메모리 사용량에 영향을 준다.
`--convert`	architecture가 애매한 모델의 task override. 일반적인 causal LM 빌드에서는 기본값인 `auto`로 시작한다.

show/inspect

FXB build가 끝났다면 fxb show와 fxb inspect로 결과를 확인한다.

fxb show /path/to/model.fxb
fxb inspect /path/to/model.fxb

명령	확인 항목
`fxb show`	모델 architecture, FuriosaIR/Furiosa-LLM 버전, TP/PP 설정, bucket/kernel summary
`fxb inspect`	`tw` tokenwise kernel, `b_a_kv` attention kernel, dtype, shape/layout/stride

fxb show는 bundle metadata를 빠르게 보는 명령이고, fxb inspect는 kernel과 bucket별 input/output signature를 자세히 보는 명령이다.

4. 컴파일 옵션별 실험

실험 환경

SDK/Furiosa-LLM: 2026.3.0 계열
CPU/MEM: 20 core / 32 Gi
NPU: Furiosa RNGD 1장
모델: Qwen/Qwen3-4B-FP8
주요 build 설정: TP=8, PP=1
dry-run 비교: O0/O1/O2/O3, max-model-len=1024~32768
runtime 비교: 요청 16개, runtime concurrency 8, max tokens 64
측정 방식: OpenAI-compatible streaming API 응답 기준 TTFT/throughput 측정
O3 모델은 컴파일 시간이 오래 걸려 런타임 실험에서 제외

O0, O1, O2, O3는 bucket coverage를 바꾼다

fxb build에서 중요한 옵션은 -O, --optim-level이다.

공식 문서에서는 이 옵션을 bucket-filtering optimization level로 설명한다. 값은 O0, O1, O2, O3를 사용할 수 있고, 기본값은 O3다. O0은 minimal, O3는 full bucket set에 해당한다.

O level은 모델 정확도를 바꾸는 옵션이 아니다. FXB 안에 포함되는 bucket/kernel coverage를 조절한다.

Qwen/Qwen3-4B-FP8, TP=8, PP=1, max_model_len=1024 기준으로 관찰한 bucket 수는 다음과 같다.

같은 조건에서 kernel 수는 다음처럼 증가했다.

O0: 빌드 시간을 줄이기 위한 최소 bucket 구성. 단일 요청이나 smoke test에는 쓸 수 있지만, 다양한 decode batch shape를 처리하기에는 부족할 수 있다. 공식 문서도 O0 bundle을 production에 사용하지 말라고 안내한다.
O1: O0보다 더 많은 decode/append variant를 포함한다. 빠른 검증과 간단한 benchmark 후보로 쓸 수 있다.
O2: 더 넓은 실행 shape를 포함한다. 동시 요청이나 다양한 context length가 섞이는 workload라면 O2를 O3와 함께 비교한다.
O3: full bucket set이며 공식 문서의 production build 권장값이다. 기본값도 O3다. production 후보는 O3를 기준으로 잡고, 빌드 시간과 실제 workload 성능을 보기 위해 O2를 함께 측정한다.

실제 runtime concurrency=8 조건에서는 O level 차이가 더 명확하게 드러났다. Qwen/Qwen3-4B-FP8, TP=8, PP=1, max_model_len=1024, 요청 16개, runtime concurrency=8 기준 결과는 다음과 같았다.

throughput

TTFT

이 결과는 O level이 파일 안의 bucket 수만 바꾸는 옵션이 아니라, 실제 workload에서 사용할 실행 shape를 늘려 런타임 성능 차이로 이어질 수 있음을 보여준다.

max-model-len은 context coverage를 바꾼다

--max-model-len은 bucket filtering에 사용되는 최대 context length를 지정한다.

최대값은 기본적으로 원본 모델이 가진 최대 context window(예. Hugging Face config의 max_position_embeddings)와 연결된다. --max-model-len을 지정하면 원본 모델의 최대 context를 그대로 쓰는 대신, FXB가 실제로 커버할 context 상한을 낮춰 bucket을 고를 수 있다.

즉, --max-model-len은 다음 질문에 답하는 옵션이다.

이 FXB가 원본 모델의 context window 안에서 어느 길이까지 커버하도록 만들 것인가?

Qwen/Qwen3-4B-FP8, TP=8, PP=1, O2 기준으로 max-model-len을 바꿔 dry-run한 결과는 다음과 같다.

같은 조건에서 kernel 수는 다음처럼 변했다.

이 결과에서 볼 수 있는 점은 두 가지다.

첫째, max-model-len을 늘리면 attention 관련 bucket이 늘어난다. 특히 decode bucket에서 더 긴 attention length를 처리하는 shape가 추가된다.

둘째, 증가가 무한히 선형적으로 이어지지는 않는다. 모델 preset과 optimization level에 의해 선택되는 bucket 후보가 있기 때문에, 특정 지점 이후에는 bucket/kernel 수가 포화될 수 있다.

tensor-parallel-size와 pipeline-parallel-size

-tp, --tensor-parallel-size는 tensor parallel group당 사용할 PE 수를 지정한다. 문서에서는 기본값이 모델 preset을 따른다고 설명한다.

TP는 빌드 시점에 고정된다. FXB의 kernel은 해당 tensor parallel degree에 맞춰 sharding되므로, 나중에 서빙할 때 -tp만 바꿔 같은 FXB를 다른 TP 구성으로 쓰면 안 된다. 배포할 RNGD topology에 맞춰 빌드 단계에서 -tp를 정한다.

-pp, --pipeline-parallel-size는 fxb build에도 옵션으로 존재한다. 다만 pipeline parallelism과 data parallelism은 서빙 시점 배치 전략과 함께 검토해야 한다.

옵션	성격
`-tp`	빌드 시점에 FXB에 고정되는 tensor parallel degree
`-pp`	build option에도 있고 serving topology와 함께 보는 pipeline parallelism
`-dp`	`fxb build` 옵션이 아니라 serving 시점 data parallelism

5. 마무리

Furiosa SDK 2026.3.0의 FXB build는 기존 Furiosa SDK에서의 LLM 컴파일 흐름을 크게 바꿨다.

2026.2.0에서는 사용자가 bucket을 직접 설계하는 느낌이 강했다. 강력하지만, 처음 접근하는 입장에서는 prefill/decode/append/tokenwise bucket을 모두 이해해야 해서 진입장벽이 있었다.

2026.3.0에서는 FXB가 중심이 되면서, bucket을 직접 설계하지 않고 주요 옵션으로 build plan을 정한다.

가장 중요한 선택지는 다음 세 가지다.

--max-model-len: 원본 모델의 context window 안에서 어느 길이까지 처리할 것인가
--optim-level: 어느 정도의 bucket/kernel set을 포함할 것인가
--tensor-parallel-size: 어떤 tensor parallel degree로 FXB를 고정할 것인가

Furiosa-LLM 컴파일을 시작한다면 공개 FXB와 cache 재사용 가능성을 먼저 확인한다. 직접 빌드가 필요하면 fxb build --dry-run으로 bucket plan을 확인한다.

빠른 검증은 O0/O1로 시간을 줄이고, production 후보는 O3를 기준으로 둔다.

FXB build는 bucket 튜닝의 부담을 줄여주지만, build plan을 읽는 능력은 여전히 중요하다. 이 점에 익숙해지면 2026.3.0의 새 흐름은 이전보다 훨씬 다루기 쉬운 컴파일 경험을 제공한다.

참고 링크

Furiosa Executable Bundles (FXB): https://developer.furiosa.ai/latest/en/furiosa_llm/fxb.html
Furiosa SDK Release 2026.3.0: https://developer.furiosa.ai/latest/en/whatsnew/release-2026.3.0.html