씨샵으로 로컬 대규모 언어 모델을 돌리는 추론 엔진, 텐서샤프 공개

씨샵으로 만든 로컬 대규모 언어 모델 추론 엔진

• 텐서샤프는 GGUF 모델 파일을 로컬에서 실행하는 씨샵 기반 추론 엔진임

  • 콘솔 앱, 웹 챗봇 UI, 올라마 호환 API, 오픈에이아이 Chat Completions 호환 API를 같이 제공함
  • 닷넷 환경에서 로컬 대규모 언어 모델(LLM)을 직접 띄우고 기존 도구와 붙이는 걸 목표로 잡은 프로젝트임

• 지원 범위가 꽤 넓음

  • 모델 계열은 젬마 3·4, 큐웬 3, 큐웬 3.5·3.6 계열, 지피티 오에스에스, 네모트론-H, 미스트랄 3를 언급함
  • 멀티모달은 젬마 4에서 이미지·비디오·오디오를 지원하고, 젬마 3·큐웬 3.5 계열·미스트랄 3·네모트론-H 옴니에서는 이미지 입력을 지원한다고 설명함
  • 추론 모드는 일부 모델에서 생각하기·추론 출력과 도구 호출까지 다룸

• 실행 백엔드도 하나로 고정하지 않음

  • 순수 씨샵 CPU, 직접 CUDA/cuBLAS, MLX Metal, GGML CPU, GGML Metal, GGML CUDA를 선택할 수 있음
  • 맥에서는 Metal과 MLX, 윈도우·리눅스에서는 NVIDIA CUDA 쪽을 노리는 구조임
  • 지원되지 않는 연산은 CPU fallback으로 돌리는 식이라, 백엔드별 완성도 차이를 흡수하려는 설계가 보임

서버 추론에서 신경 쓴 부분

• 서버 쪽 핵심은 vLLM 스타일의 페이지드 KV 캐시와 연속 배칭임

  • KV 캐시를 고정 크기 블록으로 나누고, 블록 해시를 이용해 요청 간 prefix를 공유함
  • 스케줄러는 iteration 단위로 요청을 받아들이거나 선점하면서 여러 시퀀스를 한 번의 forward에 묶으려 함
  • 기본값은 연속 배칭 활성화이고, --no-continuous-batching으로 끌 수 있음

• 관측성도 꽤 노골적으로 넣어놨음

  • 웹 UI, 올라마 응답, 오픈에이아이 응답 모두에서 KV 캐시 재사용 토큰 수와 비율을 노출함
  • 서버 로그에는 사용자 입력, 전체 메시지 배열, 원시 어시스턴트 출력, 첫 토큰 시간, 처리량, 종료 이유까지 남김
  • 운영 환경에서는 민감한 프롬프트가 로그에 남을 수 있으니 로그 레벨 조정이 필요해 보임

• API 호환성을 전면에 세운 것도 실용적임

  • 올라마 스타일 /api/generate, /api/chat/ollama 엔드포인트를 제공함
  • 오픈에이아이 호환 /v1/chat/completions도 제공하고, 구조화 출력 형식까지 파싱함
  • 기존 로컬 LLM 도구를 완전히 새로 짜지 않고 바꿔 꽂는 사용성을 노린 듯함

성능 최적화 포인트

• 양자화 가중치를 풀어서 FP32로 만들지 않고 직접 계산하는 경로를 강조함

  • Q4_K_M, Q8_0, F16, MXFP4 같은 GGUF 양자화 포맷을 읽고 native quantized matmul을 수행한다고 설명함
  • 메모리와 대역폭을 아끼는 게 핵심이고, 큰 모델을 로컬에서 돌릴 때 체감 차이가 큰 영역임

• 맥 쪽에서는 zero-copy 파일 매핑이 큰 포인트로 나옴

  • GGUF 파일을 메모리 매핑하고 Metal 명령 버퍼에 host pointer로 연결해, 모델 파일을 별도 native heap에 복사하던 비용을 줄였다고 함
  • 예시로 약 10GB짜리 큐웬 3.5 35B A3B 모델이 Metal에서 피크 약 7GB 작업 메모리로 돈다고 설명함

• 모델별 fused kernel도 많이 들어가 있음

  • 젬마 4는 디코드에서 모든 transformer layer를 하나의 GGML compute graph dispatch로 실행해 토큰당 CPU-GPU 왕복을 줄였다고 함
  • 큐웬 3.5·3.6 계열은 attention, output projection, FFN, MoE router, vision encoder 쪽 fused path를 따로 설명함
  • 네모트론-H는 Mamba2 SSM layer와 MoE FFN layer를 다루고, batched Mamba2 native kernel까지 언급함

개발자가 바로 볼 만한 사용성

• 패키지 구조는 꽤 명확하게 나뉘어 있음

  • TensorSharp.Core는 텐서와 연산, 메모리, 디바이스 추상화를 담당함
  • TensorSharp.Runtime은 GGUF 파싱, 토크나이저, 프롬프트 렌더링, 샘플링, KV 캐시, 스케줄러를 맡음
  • TensorSharp.Models는 젬마·큐웬·미스트랄·네모트론 같은 모델 구현을 담음
  • TensorSharp.Server와 TensorSharp.Cli는 각각 HTTP 서버와 콘솔 도구 레이어임

• 빌드와 실행은 닷넷 프로젝트답게 구성돼 있음

  • 전체 솔루션은 dotnet build TensorSharp.slnx로 빌드함
  • 서버는 TensorSharp.Server --model ./models/model.gguf --backend ggml_metal 같은 식으로 단일 GGUF를 명시적으로 띄움
  • 콘솔에서는 단발성 추론, 대화형 REPL, 이미지·비디오·오디오 입력, JSONL 배치, 벤치마크를 지원함

• 테스트 범위도 단순 샘플 수준은 아님

  • xUnit 테스트에는 양자화 연산, CUDA·MLX 백엔드, 페이지드 KV 캐시, 연속 배칭 스케줄러, 모델별 batched forward 정합성, 서버 요청 처리 등이 포함돼 있음
  • 서버 통합 테스트는 웹 UI SSE, 올라마, 오픈에이아이 API, 멀티턴 대화, 도구 호출, 구조화 출력, 동시 요청, 중단 처리를 다룸

---

기술 맥락

• 텐서샤프의 큰 기술적 선택은 “닷넷 안에서 로컬 LLM 추론 스택을 끝까지 가져간다”는 거예요. 단순 래퍼가 아니라 GGUF 파싱, 샘플링, 모델 구현, 서버 API, 스케줄링까지 직접 들고 가려는 구조라서 닷넷 서비스와 붙일 때 언어 경계가 줄어들어요.

• GGUF를 고른 이유는 로컬 추론 생태계에서 이미 모델 배포 단위로 널리 쓰이기 때문이에요. 허깅페이스에 올라온 양자화 모델을 바로 가져와 실행할 수 있어야 사용자 진입 장벽이 낮아지거든요.

• 페이지드 KV 캐시와 연속 배칭이 중요한 이유는 서버형 추론에서 단일 요청 속도보다 동시 요청 처리 효율이 더 큰 병목이 되기 때문이에요. 여러 사용자의 대화 prefix를 블록 단위로 재사용하면 메모리와 prefill 비용을 같이 줄일 수 있어요.

• 백엔드를 여러 개 둔 건 현실적인 선택이에요. 개발자 장비가 맥북일 수도 있고, 운영 장비가 NVIDIA 서버일 수도 있고, 네이티브 의존성을 피해야 할 수도 있으니까요. 대신 이 구조에서는 각 백엔드의 fallback 비율과 fused kernel 완성도가 실제 성능을 좌우해요.

• 메모리 최적화 사례가 특히 의미 있는 건 24GB급 애플 실리콘 같은 로컬 머신에서 30B급 모델 실행 가능성을 바꾸기 때문이에요. 모델 파일을 중복 복사하지 않는 것만으로도 메모리 압박이 줄고, 그 결과 디코드 처리량까지 같이 올라갈 수 있어요.