다만, Llama 3.3 70B 모델의 경우 4장을 기준으로 동작을 하는 것을 가정하고 있으며, TP=8, PP=4 로 빌드를 하시거나, TP=32 로 빌드가 가능하며 이때, TP=32가 성능이 보장되어 있기 때문에 이를 제공하고 있고, 추천을 드리고 있습니다.
2의 경우 특정 환경/설정에서 발생하는 문제로 보이며 아티팩트를 빌드 하는 경우 CPU와 메모리 자원이 많이 사용 되고, Disk 용량도 많이 필요하여 Build를 평가환경에서 하기 보다 로컬에서 furiosa-llm python 패키지와, furiosa-compiler apt 패키지만 설치하신 다음 아티팩트를 빌드하시는 것을 추천드립니다.
현재 2025.3.1 release에서 TP가 4와 8만 지원되는 것으로 확인했는데, 이를 더 큰 값으로 확장할 수 있는 방법이 있는지 궁금합니다.
Furiosa에서 제공하는 모델로 빌드를 시도할 때 아래와 같은 에러가 발생하고 있습니다.
>>> Building with tp=4 -> ./build_models/Llama-3.1-8B-Instruct_tp4
IOSA_GENERATOR_WARMUP_ENABLE=1 furiosa-llm build furiosa-ai/Llama-3.1-8B-Instruct --num-compile-workers 60 -tp 4 ./build_models/Llama-3.1-8B-Instruct_tp4
Fetching 134 files: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 134/134 [00:00<00:00, 5452.12it/s]
INFO:2025-09-03 06:56:44+0000 Failed to get parameter file from cache for model Llama-3.1-8B-Instruct_32L_furiosa_llm_models.llama3.symbolic.mlperf_submission_W16A16KV16.
...
OSError: furiosa-ai/Llama-3.1-8B-Instruct does not appear to have a file named pytorch_model.bin, model.safetensors, tf_model.h5, model.ckpt or flax_model.msgpack.
이 문제를 해결할 수 있는 방법이 있을까요? Furiosa가 제공하는 최적화(예: page attention 등) 가 적용된 상태로 모델을 컴파일하는 것을 목표로 하고 있습니다. 이러한 최적화를 적용한 빌드가 가능한지도 확인 부탁드립니다.
1.의 경우 모델별로 TP가 다르게 설정이 되어야합니다. 예를들어 8B의 경우 TP=8로 지정을 해주셔야하며, 70B는 TP=32가 지원이 되고 있습니다. 이외에 다른 값을 넣게 되면 에러가 발생할 수도 있습니다.
2.의 경우, meta-llama/Llama-3.1-8B-Instruct를 컴파일하시는 것을 기대하고 계실까요? 아니면, 실행을 하려고 furiosa-ai/Llama-3.1-8B-Instruct를 넣으신 것일지 궁금합니다. 우선 에러의 경우 이미 아티팩트(빌드가 완료되어 RNGD에서 돌아갈 수 있는 파일)을 build 하셔서 발생하신 문제입니다.
또한 빌드 과정에서 Furiosa 가 제공하는 최적화는 모델별로 적용된 상태로 컴파일이 되게 됩니다.
furiosa-ai/Llama-3.1-8B-Instruct 대신에 meta-llama/Llama-3.1-8B-Instruct 를 사용하셔야 합니다. 이유는 furiosa-ai/Llama-3.1-8B-Instruct 와 같이 furiosa-ai organization 아래 있는 모델들은 모두 컴파일이 완료된 아티팩트들입니다. 따라서 컴파일 결과물이 아닌 원본 베이스 모델을 선택하셔야 합니다. 그런 이유로 OSError: furiosa-ai/Llama-3.1-8B-Instruct does not appear.. 에러를 보고 계시는 거라고 이해하시면 됩니다. 추가로 이 인자에 Huggingface Hub의 다른 fine-tune 된 모델을 지정하시면 그 모델로 컴파일이 됩니다; e.g., fdtn-ai/Foundation-Sec-8B-Instruct.
--num-compile-workers 60 에서 60 이면 많은 메모리를 요구하게 되어 Linux 환경에서 OOM killer 가 동작하게 됩니다. 현상은 이유 없이 프로세스가 죽는 현상입니다. 최초 올려주셨던 프로세스가 죽는 원인은 이것이었을 것으로 추정됩니다. 적절한 사이즈는 가용한 메모리양에 따라 달라지며 1~4 정도를 우선 설정해서 써보시면서 증가 시켜보시는 것을 제안 드려봅니다.
현재 2025.3.1 release에서 TP가 4와 8 지원되는 것으로 확인했는데, 이를 더 큰 값으로 확장할 수 있는 방법이 있는지 궁금합니다.
전체적으로 보면 현재 지원되는 TP는 4,8,32 입니다. 다만, 내부 모델링과 계산 결과에 따라 모델과 parameter size 마다 최적인 TP가 어느 정도 알려져 있는데요. 예를 들면, meta-llama/Llama-3.1-8B-Instruct 은 TP=8, meta-llama/Llama-3.1-70B-Instruct 는 TP=32 입니다. 관련해서는 제가 가이드에 권장 병렬화 설정을 올려 두도록 하겠습니다.
저희가 내부적으로 많은 벤치마크를 해오고 있는데요. 여러 장치를 사용 중이시라면, 권장되는 설정은 meta-llama/Llama-3.1-8B-Instruct 은 장치당 TP=8 로 컴파일 하셔서 PE 8개를 모두 사용하시고 장치가 늘어나게 되면 DP 를 증가시키는 형태로 하시면 될 것 같습니다. Llama 8B는 weight가 상대적으로 작기 때문에 latency 를 낮춰서 throughput 을 높이는데는 한계가 있고 DP 를 높여서 throughput 을 높이는 것이 더 효과적입니다.
가이드에 소개해 두지는 않았지만 프로파일러가 있습니다. 프로파일러 데이터를 분석하면 레이어 단위 실행은 가능 하기는 합니다. 사용법과 데이터 분석법을 공유 드릴 수 있을 것 같습니다.
모델 내부에 로깅 코드를 삽입했을 때 해당 로그가 정상적으로 출력되는지도 궁금합니다.
모델의 동작 매커니즘은 vLLM 이나 TensorRT-LLM 과 유사하다고 보시면 됩니다. Furiosa-LLM은 모델 weights 만 외부로 부터 받아드립니다. 모델은 transformers 나 vLLM 에 구현된 LLamaForCausalLM 과 같은 레퍼런스 구현을 바탕으로 최적화된 구현이 Furiosa-LLM 내부에 포함되어 있고 해당 구현을 사용합니다. 따라서 변경하신 내용에 영향 받지 않습니다.
또한, 현재 서빙 중인 모델이 수행하는 TFLOP을 직접 측정할 수 있는 방법이 있는지 문의드립니다.
직접 TFLOP 을 측정하는 방법은 제공해드리고 있지 않습니다. 다만 모델에 필요한 계산량과 실제 실행 throughput을 바탕으로 역산 가능할 것으로 예상됩니다.
답변이 늦었습니다. 성능 차이는 세부적인 tensor parallelism(TP) 전략에 따라 발생할 수 있으며, Nvidia GPU가 실제로 어떤 전략을 사용하는지는 추가적인 분석이 필요할 것 같습니다.
추정 가능한 설명은 다음과 같습니다. NPU와 GPU는 각각 최적화 대상이 상이하기 때문에 동일한 TP 전략을 적용하더라도 결과가 달라질 수 있습니다. 하드웨어 및 시스템 구성이 제각각인 상황에서, 소프트웨어 레벨(예: NPU/GPU 커널 구현)에서는 특정 타겟 환경을 기준으로 최적화할 수밖에 없습니다. 따라서 동일한 전략이라 하더라도 환경 차이에 따라 성능 편차가 발생합니다.
RNGD 컴파일러의 경우 interconnect로 PCIe를 사용하므로, PCIe 대역폭 제약에 맞춘 TP 병렬화 전략을 채택하고 있습니다. PCIe는 비교적 표준화된 인터페이스라 시스템 구성에 따른 변동 폭이 크지 않으며, 그 결과 다양한 환경에서도 의도한 성능이 안정적으로 재현되는 경향이 있습니다.
반면 Nvidia GPU는 NVLink, NVSwitch 등 interconnect 구성에 따라 대역폭 및 지연 특성이 크게 달라집니다. 이 경우 최적 구성을 기준으로 최적화된 전략은, NVLink나 NVSwitch 구성에 따라 네트워크 성능이 차이가 나는 환경에서 상대적으로 성능 저하가 더욱 두드러질 수 있습니다.
반대로, 만약에 NPU가 다양한 환경에서 노출되는 경우는 어떻게 동작하는지에 대해서 의견 (자랑을) 드려보면, Nvidia GPU의 경우 최적화된 주요 커널들은 특정 시스템과 특정 병렬화 전략을 타겟으로 사람이 직접 작성합니다. Furiosa Compiler는 비용 모델과 주어진 장치 구성 설정에 맞게 최적화된 전체 NPU 프로그램을 생성합니다. 따라서 RNGD가 장기적으로 다양한 구성에서 유연하게 대응할 수 있는 체계를 가지고 있다고 볼 수 있을 것 같습니다.
