파이썬 9.1GiB vs 바이너리 66MiB: LocalAI가 직접 C++ 추론 엔진을 짜는 이유

오픈소스 AI 엔진 LocalAI는 대부분의 백엔드에서 남이 만든 추론 엔진을 감싸는 방식을 쓴다. llama.cpp, vLLM, whisper.cpp, stable-diffusion, MLX 같은 프로젝트는 해당 모델을 가장 잘 아는 사람들이 유지보수하고 있고, 이를 래핑하는 비용은 Dockerfile 하나와 gRPC 어댑터 정도에 그친다. LocalAI 스스로도 이것이 올바른 기본값이라고 못박는다. 그런데 이들의 백엔드 중 18개는 아무것도 감싸지 않는다. 밑바닥부터 새로 작성한 C 또는 C++ 포트다. 이 글은 그런 포팅이 무엇을 얻고 무엇을 치르는지를 측정치와 함께 정리한 기록이다.

직접 엔진을 짜는 판단 기준은 단순하다. 상용 파이썬 추론 스택을 배포하려면 대상 머신의 CUDA와 glibc 조합에 맞춰 설치 시점에 의존성 트리를 해석해야 한다. 반면 ggml 포트를 배포하는 일은 공유 라이브러리 하나와 GGUF 파일 하나를 복사하는 것으로 끝난다. LocalAI가 자체 엔진을 만드는 경우는 세 가지로 좁혀진다. 모델에 C++ 구현이 아예 없거나, 파이썬 의존성이 모델 자체보다 무겁거나, 필요한 기능이 아직 존재하지 않을 때다. 그 밖의 모든 것은 여전히 남의 것을 설치해서 쓴다.

발자국은 줄이되 처리량은 지킨다

가장 선명한 사례는 vLLM의 V1 서빙 구조를 C++20으로 옮긴 vllm.cpp다. vLLM을 설치하면 9.1GiB짜리 가상환경이 생기지만, vllm.cpp는 66MiB 바이너리 하나로 끝난다. 그러면서 페이지드 KV 캐시, 연속 배칭, 프리픽스 캐싱, 스케줄러, 샘플러까지 원본이 하는 일을 추론 경로에 파이썬도 PyTorch도 ggml도 없이 동일하게 구현한다. 관건은 이 다이어트가 성능을 갉아먹지 않느냐다. NVIDIA GB10에서 Qwen3.6-27B를 NVFP4·그리디·폐루프로 돌려 프로덕션 그래프 구성의 vLLM과 맞붙인 결과, 여섯 지점 모두에서 앞섰고 그중 다섯은 사실상 동률이었다. 실행 간 노이즈가 0.5% 수준이고 동시성 2~32 구간이 0.7~1.7%에 걸쳐 있어, 노이즈 밖으로 확실히 벗어난 것은 단일 스트림(4.5%)뿐이다. 출력은 모든 지점에서 vLLM과 토큰 단위로 동일했고, 최대 호스트 메모리는 28.18GiB 대비 24.88GiB였다. 성숙한 CUDA 스택을 상대로 66MiB 바이너리가 무승부를 낸 것은, 용량 절감을 처리량으로 지불하지 않았다는 뜻이다. 같은 GGUF로 CPU의 llama.cpp와 비교하면 프리필이 1.18배(223.8 대 177.3 tok/s) 빠르고 디코드는 동률, 애플 M4의 MLX-LM 대비로는 첫 토큰까지 1.5% 앞서되 워밍업 후 총처리량은 97.6%로 디코드에서 2.4% 뒤진다.

빠름의 정체는 커널이 아니라 호스트 코드

바이트댄스의 Depth Anything 3를 옮긴 depth-anything.cpp는 사진 한 장에서 미터 단위 절대 심도와 픽셀별 신뢰도, 카메라 내·외부 파라미터, 역투영 포인트 클라우드까지 뽑아낸다. Ryzen 9 9950X3D·504x336·16스레드 환경에서 같은 모델의 PyTorch보다 1.31배 빠르고 메모리는 27%, 로딩은 749ms가 아니라 40ms에 끝난다. q4_k 양자화 빌드는 99MB이며 거의 무손실이고, 37개 패리티 테스트에서 참조 순전파와 성분별로 상관계수 1.0을 기록한다. 흥미로운 점은 이 속도가 PyTorch보다 나은 행렬곱 커널에서 나온 것이 아니라는 사실이다. DPT 헤드의 UV 임베딩과 백본의 바이큐빅 위치 임베딩 두 가지가 입력 기하에만 의존해 매번 동일한데도, 매 순전파마다 단일 스레드 스칼라 sin·cos·바이큐빅 루프로 다시 계산되고 있었다. 이를 캐싱해 순전파당 약 95ms의 호스트 측 오버헤드를 없앤 것이 격차의 대부분이다. PyTorch는 애초에 벡터화 연산으로 이 임베딩을 만들어 그 비용을 치르지 않았다. 즉 무거운 GEMM은 모두 같은 부류의 BLAS 커널을 부르니 사실상 무승부고, 차이는 파이썬 참조 구현이 굳이 최적화하지 않은 호스트 측 작업과 인터프리터·프레임워크를 로딩하지 않는 데서 생긴다. GPU로 가면 그림이 다시 뒤집혀, ggml CUDA 백엔드와 플래시 어텐션을 쓴 GB10에서 순전파당 47.3ms로 튜닝된 cuDNN과 동률이고 이기는 것은 콜드 스타트뿐이다.

속도가 아니라 일치가 목적일 때

face-detect.cpp와 voice-detect.cpp는 CPU 속도 우위를 주장하지 않는데도 출시된 경우다. face-detect.cpp는 SCRFD 검출, 다섯 랜드마크 정렬, ArcFace 임베딩으로 이어지는 insightface buffalo 체인 전체를 파이썬과 onnxruntime 없이 GGUF 하나에서 돌린다. 박스와 랜드마크는 1픽셀 이내로, 인식 임베딩은 코사인 1.000000으로 일치하지만, CPU에서는 onnxruntime보다 느리다. SCRFD 검출이 스레드에 따라 약 0.83~0.69배, ArcFace가 0.61~0.84배 수준이다. onnxruntime의 MLAS 합성곱 커널이 FMA 포트 한계에 붙어 있어, 커스텀 AVX2 위노그래드 경로로도 격차를 좁혔을 뿐 닫지는 못했다. voice-detect.cpp는 WeSpeaker 검증에서 파이썬 경로가 약 334MB를 쓰는 반면 62MB로 약 5.4배 낮은 메모리에, 판정과 임베딩은 코사인 1.000000으로 동일하다. 그럼에도 이들을 내놓은 이유는 생체 인식 파이프라인에서는 빠른 것보다 참조와 정확히 일치하는 것이 더 중요하기 때문이다. 임베딩이 소수점 넷째 자리에서 어긋나면 임계값 근처의 검증 판정이 바뀌고, 배포된 모든 등록 템플릿을 다시 계산해야 한다. 패리티야말로 이 교체를 마이그레이션이 아니라 드롭인으로 만든다.

순서가 핵심인 포팅 절차와 그 대가

모든 포트는 같은 순서를 따르며, 실무자가 눈여겨볼 지점은 그 순서 자체다. 먼저 가중치를 토크나이저·어휘·보조 모델까지 묻은 GGUF 하나로 변환해 배포를 파일 복사로 만든다. 다음으로 그래프를 옮기되 원본에서 덤프한 참조 텐서에 대해 성분 단위로 게이트를 건다. depth-anything.cpp는 전처리부터 익스포터까지 37개 ctest, parakeet.cpp는 NeMo와 전사 일치를 WER 0으로 검증한다. 빠르지만 조금 틀린 포트는 무가치하고, 성분별 게이트가 없으면 그 오류를 몇 달 뒤에야 발견하게 된다. 최적화는 패리티가 성립한 뒤 프로파일러로 세 번째에 한다. parakeet.cpp의 결정적 개선은 트랜스듀서 디코드 시간의 97%를 차지하던 예측 네트워크 LSTM 순전파 캐싱이었는데, 이는 동작하는 기준선 없이는 찾을 수 없는 종류다. 마지막으로 평평한 C ABI를 노출해 LocalAI가 purego로 공유 라이브러리를 직접 dlopen한다. 서빙 경로에 서브프로세스도, 파이썬 서버로 가는 gRPC 홉도, 인터프리터도 없다.

비용은 대체로 유지보수다. 엔진마다 별도 CI와 벤치마크, GGUF 변환 스크립트, 패리티 기준선을 갖는 하나의 저장소이며, 상류가 새 체크포인트를 낼 때마다 변환기 작업이 따라붙는다. 약점은 GPU 커널이다. ggml의 범용 CUDA 합성곱·어텐션 커널이 합성곱 위주 모델에서 cuDNN에 뒤지는 탓에, face-detect.cpp는 패리티를 맞추려 별도 cuDNN 경로가 필요하고 parakeet.cpp의 GPU 우위는 중앙값 1.25배로 CPU만큼 벌어지지 않는다. 결국 이 접근은 만능이 아니다. llama.cpp, vLLM, whisper.cpp, MLX, diffusers처럼 크고 빠르게 움직이며 이미 뛰어난 프로젝트는 계속 래핑한 채로 둔다. C++ 구현이 없거나, 의존성이 모델보다 무겁거나, 필요한 것이 아직 없을 때만 직접 짠다는 원칙은 한국의 온프렘·엣지 배포 환경에서 무엇을 자체 구현하고 무엇을 그대로 가져다 쓸지 가르는 실무 기준으로도 그대로 읽힌다.