이 기사는 원래 저희 엔지니어링 블로그인 **WithNext.NET**에 게시되었습니다. 여기에는 원문으로 연결되는 정식 링크(canonical link)와 함께 재게시되었습니다.

로컬 LLM 커뮤니티인 r/LocalLLaMA에서, TensorSharp라는 .NET 추론 엔진이 llama.cpp를 대상으로 한 벤치마크를 발표하며 주목을 받았습니다. 대부분의 추론 엔진은 C/C++ 또는 Python을 기반으로 구축되므로, LLM 추론의 핵심을 순수 C# / .NET으로 구현한 프로젝트는 자세히 살펴볼 가치가 있습니다. 특히 .NET이 주력 분야이고 AI 추론을 해당 스택으로 가져오고 싶다면 더욱 그렇습니다.

이 포스트는 저자의 Reddit 게시물과 GitHub 저장소를 바탕으로 TensorSharp가 실제로 무엇을 하는지, 그리고 llama.cpp와 어떻게 비교되는지를 요약합니다. 아래의 수치들은 저자가 직접 측정한 결과이며, 저는 그 위에 .NET 개발자의 관점을 추가했습니다.

TensorSharp란 무엇인가?

TensorSharp는 GGUF 형식의 모델을 위한 **네이티브 .NET 추론 엔진 (inference engine)**입니다. zhongkaifu에 의해 개발되었으며 BSD-3-Clause 라이선스 하에 공개되었습니다. 콘솔 앱, 웹 기반 챗봇 UI, 그리고 사용자의 프로그램에서 호출할 수 있는 Ollama / OpenAI 호환 HTTP API를 함께 제공합니다. Windows, macOS, Linux에서 실행되며 GPU를 사용할 수 있습니다.

중요한 점은, 이것이 단순히 llama.cpp를 C#으로 감싼 래퍼(wrapper)가 아니라는 것입니다. 저자는 이 엔진이 바닥부터(bottom-up) 구현되었으며, CPU 백엔드에서 실행될 때는 100% 순수 C#이라고 밝히고 있습니다. 그뿐만 아니라 CUDA, MLX, GGML 백엔드를 구현하고 있습니다. GGML 백엔드는 외부 프로젝트로 참조되며, 그 위에 여러 개의 융합 연산(fused operations)이 계층화되어 있습니다. 지원되는 백엔드는 Metal (macOS), CUDA (NVIDIA), Vulkan (범용 GPU) 및 CPU를 아우르며, 모두 CPU 폴백(fallback) 기능을 갖추고 있습니다.

모델 지원 범위 또한 광범위합니다: Gemma 3 / 4, Qwen 3 / 3.5 / 3.6, GPT-OSS, Nemotron-H, Mistral 3와 같은 모델은 물론 DiffusionGemma 및 Qwen-Image-Edit과 같은 멀티모달 모델도 지원합니다. 이미지, 비디오, 오디오 입력, PDF 문서 처리, 도구 호출(tool calling), 사고 모드(thinking mode), 구조화된 출력까지 처리할 수 있습니다. 특히 Q4_K_M, Q8_0, MXFP4, IQ2_XXS와 같은 양자화(quantizations)는 디퀀타이제이션 단계 없이 직접 계산됩니다.

llama.cpp 대비 벤치마크

저자가 제시한 벤치마크는 동일한 백엔드에서 TensorSharp와 llama.cpp를 비교하며, 시나리오별 속도 비율의 기하 평균(geometric mean)을 보고합니다. 1.00× 이상은 TensorSharp가 더 빠르다는 의미입니다. _decode_와 _prefill_은 처리량(throughput)이며, _TTFT_는 첫 토큰까지의 지연 시간(latency)입니다. 측정은 여러 모델에 걸쳐 CUDA와 Vulkan 모두를 아우릅니다.

TensorSharp vs. llama.cpp benchmark table comparing decode, prefill, and TTFT speed ratios across Gemma 4 and Qwen 3.6 models on CUDA and Vulkan
TensorSharp vs. llama.cpp benchmarks (출처: Reddit r/LocalLLaMA / 프로젝트 작성자)

결과는 모델과 백엔드에 따라 다릅니다. Prefill과 TTFT는 여러 경우에서 TensorSharp가 유리합니다. 예를 들어, CUDA 환경의 Gemma 4 E4B는 prefill에서 **1.28×**를, TTFT에서 1.27×를 보여줍니다. 반면 Decode는 1.0 근처에 머무르며, Qwen 3.6 35B-A3B (Vulkan)의 경우 llama.cpp보다 낮은 0.87×로 떨어집니다. Qwen 3.6 27B dense 모델에서는 prefill/TTFT가 1.0 미만입니다. 즉, 균일하게 빠르지는 않습니다. 저자는 전반적인 결과를

TensorSharp는 최근의 추론 최적화 기술들을 적극적으로 차용하고 있습니다. 저자에 따르면, vLLM으로부터 **페이지드 KV 캐시 (paged KV cache)**와 연속 배치 (continuous batching) 기술을, oMLX로부터 MoE 모델을 위한 SSD 기반 캐시 기술을, 그리고 llama.cpp로부터 GGUF 양자화 (quantization) 기술을 가져와 적용했다고 합니다. KV 캐시는 블록 해싱 (block hashing)과 반복 수준 스케줄러 (iteration-level scheduler)를 통해 접두사 공유 (prefix sharing)를 지원하며, 연속 배치는 기본적으로 활성화되어 있습니다.

Qwen 3.6 및 Gemma 4의 경우, **MTP / NextN을 통한 투기적 디코딩 (speculative decoding)**을 지원하며, 텐서 병렬화 (tensor parallelism)는 Megatron-LM의 컬럼/로우 병렬 (column/row parallel) 패턴을 따르며 여러 GPU 및 멀티 노드 TCP 클러스터링으로 확장됩니다. 멀티 GPU 지원에 대해서는 Reddit 댓글에서 언급되었으며, 저자는 단일 노드 멀티 GPU 및 멀티 노드 모두를 위한 PR (Pull Request)이 진행 중이며 활발히 개발되고 있다고 답변했습니다. 이 분야는 여전히 진화 중인 단계라고 보는 것이 타당합니다.

.NET 팀에게 주는 의미

팀이 로컬 LLM을 프로덕션 환경에 도입할 때, 일반적인 형태는 애플리케이션이 HTTP를 통해 호출하는 Python 기반의 모델 서버를 두는 방식입니다. 이 방식도 작동은 하지만, 런타임이 두 배로 늘어나고 배포 및 운영의 접점이 추가됩니다. 추론 엔진 자체가 .NET에서 실행되는 신뢰할 수 있는 옵션은 이러한 아키텍처를 재검토하도록 유도합니다. TensorSharp는 Ollama 및 OpenAI와 호환되는 API를 노출하므로, 기존 클라이언트 코드의 상당 부분을 다시 작성하지 않고도 교체할 수 있는 경우가 많습니다.

그렇긴 하지만, 프로덕션 도입에는 냉철한 판단이 필요합니다. 벤치마크 결과는 모델과 백엔드에 따라 흩어져 있으며, 멀티 GPU 지원은 여전히 개발 중입니다. 가장 현명한 접근 방식은 타겟 모델과 하드웨어로 직접 측정하고, llama.cpp 또는 현재 설정과 비교한 후 결정하는 것입니다.

요약

TensorSharp는 순수 .NET으로 GGUF 추론 (inference)을 구현하며, 저자의 벤치마크(benchmarks) 결과에 따르면 llama.cpp와 동일한 수준의 성능 범위에 도달합니다. 많은 경우 Prefill(프리필)과 TTFT(첫 토큰 생성 시간) 측면에서는 앞서지만, Decode(디코드) 단계에서는 비슷하거나 뒤처지기도 하여 무조건적인 승리라고 할 수는 없습니다. 그럼에도 불구하고, C#만으로 LLM 추론을 완료하는 것이 이제 실용적인 범위 내에 들어왔다는 사실은 매우 중요하며, AI를 .NET 스택에 통합하고자 하는 팀이라면 주목할 만한 가치가 있습니다.

추가적인 맥락이 포함된 더 자세한 일본어 글을 보고 싶으시다면, 원문 포스트에서 확인하실 수 있습니다: TensorSharp — llama.cpp에 도전하는 순수 C# GGUF 추론 엔진 | WithNext.NET.

출처 (Sources)

• Benchmarks: TensorSharp vs. llama.cpp (Reddit r/LocalLLaMA)
• zhongkaifu/TensorSharp (GitHub)

저희는 WithNext.NET에서 .NET / C# 현대화, 성능, 그리고 응용 AI에 대해 다룹니다.