SemiAnalysis: AI의 진짜 100배는 co-design에서 온다 (Sequoia) (youtube.com) ↗

• Dylan Patel은 inference가 AI 경제의 핵심 시장이 될 것으로 봄. 사용자가 실제로 돈을 내는 지점은 모델 학습이 아니라 토큰 사용이기 때문
• SemiAnalysis가 만든 InferenceX의 핵심은 한 번 찍고 끝나는 benchmark가 아니라, 매일 최신 모델과 최신 하드웨어에서 계속 도는 benchmark
• 같은 품질의 모델 비용은 최근 연 단위로 약 60배 내려갔고, intelligence per watt도 크게 개선됐다는 주장
• 진짜 큰 효율 향상은 하드웨어, 시스템 소프트웨어, 모델 구조를 따로 최적화할 때가 아니라 세 층을 같이 맞출 때 나온다는 설명
• Sequoia Capital의 Training Data 인터뷰. SemiAnalysis 창업자 Dylan Patel이 inference benchmark, GPU/TPU, 데이터센터 buildout, Nvidia 전략을 설명한 대담

Inference가 왜 AI 경제의 중심이 되나?

• Dylan은 “token 사용”이 AI에서 가장 중요한 경제 단위가 된다고 봄. 모델이 만들어내는 가치가 결국 inference 사용량으로 나타나기 때문
• open model이든 closed model이든, 사용자가 매일 쓰는 AI 제품은 모두 inference 비용과 속도에 묶임
• 그래서 “모델이 얼마나 똑똑한가”만 보면 부족함. 같은 품질을 더 싸게, 더 빠르게, 더 적은 전력으로 내는지가 실제 시장을 가름
• SemiAnalysis는 같은 benchmark 수준에서 모델 비용이 약 60배 내려갔다고 말함. 전력 기준 효율도 약 40배 가까이 좋아졌다는 설명
• 이 하락은 GPU 세대 교체만으로 생긴 게 아님. 모델 구조, kernel, serving framework, driver, memory 사용 방식이 같이 바뀐 결과에 가까움

Inference benchmark는 왜 계속 살아 있어야 하나?

• 예전 benchmark는 특정 시점의 사진에 가까웠음. 하지만 지금은 모델, PyTorch, vLLM, SGLang, driver, inference optimization이 계속 바뀜
• Dylan은 어떤 라이브러리는 주 2회 수준으로 업데이트된다고 말함. 그러면 한 달 전 benchmark도 이미 낡은 숫자가 될 수 있음
• InferenceX는 Nvidia, AMD, Google, Amazon, CoreWeave, Crusoe, Microsoft, OpenAI 등 생태계의 compute를 받아 여러 chip type에서 매일 benchmark를 돌리는 프로젝트
• 핵심 지표는 throughput-interactivity curve임. 쉽게 말하면 “한 장비가 총 몇 token을 뽑는가”와 “사용자 한 명에게 얼마나 빠르게 답하는가”의 균형
• 문서 수천 개를 밤새 처리하는 batch 작업은 느려도 싸면 됨. 반대로 coding agent나 chat 제품은 응답이 느리면 workflow가 끊기므로 더 비싼 fast mode를 쓸 수 있음

선택	적합한 작업	tradeoff
낮은 latency	coding agent, 실시간 chat, 반복 feedback	비용이 올라갈 수 있음
높은 batch size	문서 처리, offline 분석, 대량 요약	사용자별 응답은 느릴 수 있음
중간 지점	일반 SaaS 기능, 내부 자동화	비용과 체감 속도의 균형

hardware-software co-design이 왜 100배를 만들까?

• Sean이 “효율 향상이 주로 hardware에서 온 것 아니냐”고 묻자 Dylan은 반대함. hardware, system software, model layer가 모두 중요하다는 답
• 예를 들어 Hopper에서 Blackwell로 넘어가며 DeepSeek 최적 deployment에서 큰 개선이 있었지만, 그것만으로 전체 효율 변화를 설명하기는 어렵다는 관점
• DeepSeek V3는 Hopper에, 이후 구조는 Blackwell과 Huawei chip에 더 맞춰졌다는 식의 예시가 나옴. 모델의 expert shape, attention 구조, memory access, network I/O가 특정 하드웨어와 맞물림
• Gemini도 TPU 세대에 맞춰 최적화되고, Anthropic은 training과 inference에서 서로 다른 하드웨어 조합을 쓰는 식으로 최적점을 찾는다는 설명
• 그래서 2배, 2배, 2배 개선을 따로 더하면 8배처럼 보이지만, 세 층을 같이 설계하면 100배 개선이 나올 수 있다는 게 Dylan의 핵심 주장

층	쉬운 설명	예시
Hardware	실제 chip, memory, network	GPU, TPU, HBM, NVLink, ICI
System software	모델을 chip 위에서 돌리는 실행층	kernel, compiler, serving framework
Model architecture	모델이 계산을 요구하는 모양	sparse expert, attention, matrix shape

GPU와 TPU는 무엇이 다르게 맞춰지나?

• Dylan은 GPU가 무조건 낫다거나 TPU가 무조건 낫다고 말하기 어렵다고 봄. 어떤 모델 구조를 어떤 하드웨어에 맞췄는지가 더 중요함
• Nvidia는 범용성과 switch 기반 NVLink 생태계가 강함. Google TPU는 특정 network architecture와 에너지 효율에서 장점이 있음
• Google ICI는 많은 chip을 높은 bandwidth로 묶을 수 있지만, switch가 없는 구조라 chip을 거쳐 가는 tradeoff가 있음
• OpenAI처럼 더 sparse한 모델 구조와 Anthropic처럼 상대적으로 dense한 구조는 하드웨어 선택이 달라질 수 있음
• CUDA moat도 단순히 CUDA 문법의 문제가 아니라, open model 생태계가 Nvidia GPU에 맞춰져 있다는 점이 더 중요해지는 중

데이터센터 경쟁은 왜 단순한 전기 문제가 아닌가?

• Dylan은 compute crunch가 단기적으로 계속될 수 있다고 봄. 모델이 할 수 있는 일이 늘어나는 속도가 compute 공급 증가보다 빠르면 가격은 쉽게 내려가지 않음
• 대담에서는 단기적으로 20GW, 그 다음 해 30GW 규모의 데이터센터 buildout이 언급됨. 그래도 long agent 수요가 더 빨리 늘면 부족할 수 있음
• AI cloud는 전통 cloud와 다름. CPU cloud에서는 tenant isolation, custom SSD, 범용 network가 중요했지만, AI workload에서는 전체 rack을 장기 계약으로 빌리는 경우가 많음
• 그래서 hyperscaler의 기존 장점 일부가 오히려 GPU AI 성능에는 방해가 될 수 있고, CoreWeave나 Crusoe 같은 NeoCloud가 빠르게 기회를 잡았다는 설명
• Nvidia가 NeoCloud와 여러 AI lab을 밀어주는 것도 같은 맥락임. hyperscaler 몇 곳만 compute를 장악하면 장기적으로 Nvidia의 협상력이 약해지기 때문

AI hardware-software co-design이란 무엇인가요?

하드웨어를 먼저 만들고 그 위에 모델을 얹는 방식이 아님. 모델 구조, kernel, memory 사용, network topology, chip 설계를 서로 맞춰 전체 효율을 끌어올리는 방식임. 같은 chip이라도 어떤 모델에 맞췄는지에 따라 성능과 비용이 크게 달라질 수 있음.

InferenceX는 무엇을 측정하나요?

InferenceX는 모델을 실제 serving 환경에서 돌렸을 때의 속도, 비용, 전력, batch size, 사용자 응답성을 비교하는 benchmark임. 단일 점수가 아니라 throughput과 interactivity의 곡선을 보여줘서, 빠른 응답이 필요한 제품과 대량 batch 작업을 구분할 수 있게 함.

GPU와 TPU 중 어느 쪽이 AI에 더 유리한가요?

정답은 workload와 모델 구조에 따라 다름. GPU는 범용성과 생태계가 강하고, TPU는 특정 구조와 대규모 내부 workload에 맞추면 매우 효율적일 수 있음. 큰 lab일수록 “좋은 chip 하나”보다 “내 모델에 맞는 chip과 software stack”을 고르는 쪽으로 감.

1인기업 관점

결국 model은 계속 발전하고, model이 발전하면 그 위에 얹은 harness도 같이 낡는 것 같음. 그래서 agent 제품을 만들 때도 한 번 짠 workflow를 믿고 두는 게 아니라, 계속 테스트하면서 작은 benchmark를 만들어야 할 듯. 이걸 안 하면 예전에는 성능을 올려주던 harness가 어느 순간 오히려 model의 blocker가 될 수 있지 않나 싶음.

---

관련: Prime Intellect: RL 환경의 GitHub를 만들다와 Cursor가 Composer 2를 직접 훈련한 이유도 같이 보면 좋습니다.