Windows 앱에 로컬 AI 모델을 통합하는 방식의 차이점

Windows 앱에 자체 보유한 AI 모델을 통합할 때, 'llama.cpp가 Windows에서 작동한다'는 것과 '해당 모델을 Windows ML을 통해 다룰 수 있다'는 것은 별개의 문제입니다. 이번 발표를 통해 늘어난 것은 후자의 실험적인 경로입니다. 이미 작동하는 로컬 AI를 바로 상용 앱으로 옮길 수 있다는 의미는 아닙니다.

Microsoft의 이전 게시물은 Windows ML에 llama.cpp를 통합하여 GGUF 형식의 모델을 다룰 수 있게 된다고 안내하고 있습니다. 공식 기사에서는 텍스트 생성 API가 GGUF와 ONNX 모델을 수용하며, 기존 OpenAI SDK로부터 연결할 수 있는 로컬 진입점도 소개하고 있습니다. 음성 인식 API와 결합한다면, 예를 들어 장치 내에서 음성을 문자로 변환한 후 그 결과를 로컬 모델에 전달하는 시제품이 구상될 수 있습니다. 다만, 이 생성/실행 API는 실험 단계이며, 상용 환경에서의 사용은 지원되지 않습니다.

확인된 초기 답변 중에는 한 사람이 '모델, 실행 엔진, 장치의 조합을 어디까지 자동으로 선택할 수 있는지'를 질문했고, 다른 사람은 OS 자체와의 메모리 점유 경쟁에 대해 우려했습니다. 또한 'llama.cpp는 이전부터 Windows에서 작동하지 않았냐'는 의견도 있습니다. 이들은 모두 소수의 공개 반응일 뿐이며, 이번 기능을 테스트한 성능 보고서는 아닙니다.

여기서 제공 범위를 세밀하게 살펴볼 필요가 있습니다. Windows ML 전체는 CPU, GPU, NPU를 다루지만, 공식 실행 API 자료에서 이번 GGUF/llama.cpp 경로로 검증되었다고 하는 것은 CPU와 NVIDIA CUDA뿐입니다. 'Windows ML이 NPU를 지원한다'라는 것과 '자신의 GGUF 모델도 NPU에서 작동한다'는 것을 혼동하지 않는 것이 좋겠습니다. 생성 API에는 샘플링이나 구조화된 출력 등 아직 표면화되지 않은 기능들도 있습니다.

테스트하려면, 먼저 대상 Windows 장치와 모델을 하나 정하고, 시작 시 메모리, 첫 문자가 나올 때까지의 시간, 긴 입력 후 대기 시간을 측정해야 합니다. CPU와 대응하는 GPU로 같은 작업을 비교하고, 필요한 생성 기능이 API에 있는지 확인해야 합니다. 상용 배포 여부를 판단하는 것은 실험판의 성공과는 구분해야 합니다. 모델 선택의 자유가 늘어난 지금이야말로 '작동하는 장치'와 '배포할 수 있는 메커니즘'의 경계를 먼저 확인하고 싶습니다.