When Running Your Own AI Models Beats Paying for APIs - Steven Latré, imec

한 줄 핵심

API만 쓰는 것보다 자체 인프라와 open weight 모델을 운영할 때 총소유비용과 성능을 동시에 개선할 수 있으며, 특히 장기 코딩 작업에서는 정확도보다 하드웨어·동시성·하네스 선택이 비용을 더 크게 좌우한다.

시간별 요약

1. 0:00
   소개 IMEC는 반도체 분야에서 강한 연구 역량을 가진 조직이며, AI를 시스템과 워크로드까지 확장해 바라보는 관점에서 이 발표의 출발점을 만든다.
2. 0:59
   칩 연구소가 AI 워크로드를 연구하는 이유 반도체 연구는 트랜지스터를 넘어서 시스템과 워크로드까지 다뤄야 하므로, AI 워크로드가 인프라에 어떤 요구를 만드는지 연결하는 일이 핵심 과제가 된다.
3. 1:32
   AI 성숙도의 단계 초기에는 최신 frontier model을 무조건 쓰는 흐름이 강했지만, 이제는 가격이 구독형에서 token 기반으로 바뀌고 model routing을 거쳐 자체 스택을 통제하는 단계로 이동하고 있다.
4. 3:28
   스택을 소유하면 설계 공간이 폭발적으로 넓어진다 API만 쓸 때는 모델 선택이 중심이지만, 자체 인프라를 운영하면 모델 신뢰성, harness, CPU-GPU 비율, KV cache 최적화 같은 하드웨어·시스템 변수가 한꺼번에 중요해진다.
5. 4:38
   벤치마킹 연구 Agentic AI 과제를 기준으로 API 사용과 자체 인프라 운영을 비교하는 수천 회 규모의 벤치마크를 수행해, 성능뿐 아니라 총소유비용과 적절한 인프라 구성을 함께 측정했다.
6. 5:28
   테스트 구성 방법 장기 과제에 적합한 SWE-bench pro를 사용하고, Codex와 Claude Code 같은 coding harness와 다양한 open weight model, 그리고 여러 하드웨어 구성을 조합해 처리량·지연시간·해결률·비용을 비교했다.
7. 7:28
   모델별 정확도 모델 규모에 따라 정확도는 뚜렷하게 갈렸으며, 작은 계열은 32.5~40% 수준, GLM은 Opus급, Kimi K3는 86% 수준의 해결률을 보였다.
8. 8:40
   하드웨어 비용을 더했을 때 정확도가 비슷해 보여도 필요한 하드웨어와 GPU 임대 비용은 크게 달랐고, Qwen과 DeepSeek처럼 비슷한 성능의 모델도 하드웨어 요구량은 4배까지 차이날 수 있었다.
9. 10:08
   동시성: 몇 명의 사용자를 수용할 수 있는가 자체 인프라에서는 모델이 메모리에 맞는지뿐 아니라 KV cache까지 포함한 동시 사용자 수와 latency가 중요하며, 큰 모델일수록 안정적으로 수용 가능한 사용자 수가 크게 줄었다.
10. 12:37
    API, 임대, 직접 구매 비교 총소유비용 기준으로는 낮은 하드웨어 계층일수록 자체 인프라 전환이 불리하고, 현실적인 GPU utilization과 비용 절감 폭을 고려할 때 GLM급 작업에서 전환 임계점이 형성되며 약 24.5%의 비용 절감이 관찰됐다.
11. 14:35
    Harness와 token 사용량 하네스 자체가 정확도를 크게 바꾸지는 않았지만, GPU를 직접 비용으로 부담하는 환경에서는 token 사용량과 wall time을 크게 바꿔 총비용에 결정적인 영향을 주었고, Codex는 특정 조합에서 token과 GPU 시간이 절반 수준으로 줄었다.
12. 16:20
    다음 단계 API에서 인프라로의 이동은 단순한 선택이 아니며, 여러 애플리케이션 조합과 quantization, speculative decoding, 새로운 모델·하드웨어의 등장까지 반영하는 공개 벤치마킹 데이터셋과 생태계 협력이 다음 과제가 된다.

실무 인사이트

• 자체 모델 운영의 판단 기준은 정확도보다 총소유비용, 동시성, GPU utilization을 함께 봐야 하며, 특히 장기 작업일수록 이 차이가 커진다.
• 모델 성능이 비슷해 보여도 하드웨어 요구량과 하네스에 따른 token 소비가 크게 달라지므로, 모델 선택 전에 인프라 제약을 먼저 계산하는 것이 유리하다.
• 기업 환경에서는 단일 모델 최적화보다 여러 워크로드를 묶어 보는 벤치마킹 체계를 만들어야 API 유지와 자체 인프라 전환의 경계점을 정확히 찾을 수 있다.