GPU 세금 7배를 겨눈다, 에이전트 추론 클라우드의 조건

AI 요약

• 무슨 일: General Compute가 2026년 5월 15일 에이전트용 ASIC-first 추론 클라우드 일반 제공에 들어갑니다.
  • 공식 발표는 목적 특화 AI 가속기, OpenAI 호환 API, prefill/decode 분리 로드맵을 전면에 세웁니다.
• 핵심 주장: 에이전트는 챗봇보다 긴 입력, 짧은 구조화 출력, 작은 배치, 반복 도구 호출에 묶입니다.
• 개발자 영향: 모델 품질 경쟁 뒤에서 지연시간, 전력, provider 라우팅이 에이전트 제품의 실제 비용을 가릅니다.
• 주의점: 7배, 950 tok/s 같은 수치 일부는 공식 claim 또는 projection이며 독립 벤치마크와 구분해야 합니다.

General Compute가 2026년 5월 15일 에이전트 워크로드를 겨냥한 추론 클라우드의 일반 제공을 시작합니다. 회사는 4월 18일 공식 보도자료에서 이 플랫폼을 "자율 AI 에이전트를 위한 ASIC-first inference cloud"라고 소개했습니다. 겉으로 보면 또 하나의 OpenAI 호환 API입니다. 하지만 이 발표가 흥미로운 이유는 모델 카탈로그가 아니라, 에이전트 시대의 병목을 "모델이 아니라 추론 하드웨어와 serving 구조"로 다시 정의한다는 데 있습니다.

General Compute의 슬로건은 노골적입니다. 공식 사이트 첫 화면은 "GPU는 그래픽을 위해 만들어졌고, 우리는 추론을 위해 만들어졌다"는 메시지와 함께 목적 특화 ASIC, 1,000 tokens per second, 7x faster inference를 내세웁니다. 개발자가 실제로 접하는 표면은 익숙합니다. Python이나 Node.js에서 OpenAI SDK를 쓰고 base_url과 API key만 바꾸면 됩니다. 그러나 내부 논리는 GPU 클라우드가 챗봇 시대의 평균 부하에 최적화됐고, 에이전트 시대의 작은 배치·긴 컨텍스트·반복 도구 호출에는 맞지 않는다는 주장입니다.

이 주장은 지금 AI 인프라 시장의 방향과도 맞물립니다. 2023년과 2024년의 질문은 "누가 GPU를 얼마나 확보했는가"였습니다. 2025년을 지나 2026년으로 오면서 질문은 더 잘게 쪼개졌습니다. 훈련은 여전히 범용 GPU가 지배하지만, 추론은 음성, 검색, 온디바이스, 장문 컨텍스트, 에이전트, 배치 처리처럼 서로 다른 workload class로 갈라지고 있습니다. General Compute가 노린 곳은 이 중에서도 에이전트 추론입니다. 한 번 답하고 끝나는 챗봇이 아니라, 계획을 세우고, 도구를 호출하고, 실패를 관찰하고, 다시 호출하는 긴 trajectory를 돌리는 시스템입니다.

에이전트는 왜 챗봇과 다른 부하인가

General Compute의 2026년 5월 백서는 글의 핵심 논리를 가장 선명하게 설명합니다. 챗봇은 사용자가 질문을 입력하고, 모델이 긴 답변을 생성하고, 사용자가 읽는 동안 자연스러운 대기 시간이 생깁니다. 이때 provider는 여러 사용자의 요청을 묶어 batch throughput을 높일 수 있습니다. 사용자가 초당 50토큰 이상으로 스트리밍되는 답변을 읽고 있다면, 그 이상은 체감 차이가 줄어듭니다.

에이전트는 다릅니다. 입력은 시스템 프롬프트, 도구 목록, 메모리, 검색 결과, 이전 단계 로그를 모두 포함합니다. 백서는 "수만 토큰은 보통이고, 수십만 토큰도 드물지 않다"고 설명합니다. 반대로 출력은 대개 짧습니다. 에이전트는 에세이를 쓰기보다 JSON, tool call, 중간 계획, structured output을 내보냅니다. 더 중요한 차이는 순차성입니다. 한 tool call이 끝나야 다음 단계가 시작됩니다. 사람이 읽는 시간이 완충재가 되지 않습니다. 한 단계에서 500ms가 늦어지면 20단계 trajectory에서는 10초가 됩니다.

그래서 에이전트 추론은 일반적인 "tokens per second" 경쟁과 조금 다르게 움직입니다. 긴 입력을 빠르게 읽는 prefill, 짧은 출력을 낮은 지연시간으로 반복 생성하는 decode, 그리고 각 단계의 tail latency가 모두 중요합니다. 백서는 이 문제를 "추론은 하나의 workload가 아니라 두 workload"라고 표현합니다. prefill은 긴 prompt를 병렬로 처리하는 compute-bound 작업입니다. decode는 한 토큰씩 autoregressive하게 생성하면서 모델 weight와 KV cache를 계속 읽는 memory-bound 작업입니다.

GPU는 prefill에 강합니다. 넓은 SIMD, 높은 FLOPs, HBM bandwidth를 활용해 긴 입력을 병렬로 밀어붙일 수 있습니다. 하지만 batch size one에 가까운 decode에서는 상황이 달라집니다. 백서는 GPU가 batch size one decode에서 비싼 silicon을 충분히 활용하지 못한다고 주장합니다. 이 주장이 완전히 새로운 것은 아닙니다. Groq, Cerebras, SambaNova, Google TPU, hyperscaler의 자체 silicon 모두 비슷한 문제의식을 공유합니다. 다만 General Compute는 이 문제를 "에이전트용 클라우드"라는 제품 표면으로 묶었습니다.

공식 수치가 말하는 것과 말하지 않는 것

General Compute는 성능 수치를 공격적으로 공개합니다. 공식 사이트는 MiniMax M2.5 비교에서 GC 950 tok/s, NVIDIA Cloud 약 100 tok/s를 제시합니다. 전력은 17kW rack 대 120kW GPU equivalents, 전력 단가는 $0.035/kWh 대 미국 상업 평균 $0.13/kWh로 표시합니다. 동시에 작은 별표가 중요합니다. 사이트의 해당 비교에는 next-generation racks에 대한 projection과 Together AI benchmark를 통한 NVIDIA throughput이라는 주석이 붙어 있습니다. 즉, 이 수치는 그대로 "현재 모든 workload에서 9.5배 빠르다"로 읽으면 안 됩니다.

백서의 현재 실측 claim은 더 구체적입니다. General Compute는 현재 SambaNova SN40L 위에서 GPT-OSS-120B를 실행하며, 같은 prompt를 동시에 보낸 비교에서 Together AI 대비 time-to-first-token 738ms 대 1,899ms, end-to-end latency 1.76초 대 8.05초를 기록했다고 주장합니다. 회사 표현으로는 첫 토큰 2.6배, 전체 지연시간 4.6배입니다. 이 수치도 공식 백서 claim입니다. 독립 벤치마크가 아니며, 모델, prompt, region, queue 상태, streaming 방식에 따라 결과는 달라질 수 있습니다.

그래도 이 수치가 던지는 질문은 의미가 있습니다. 지금까지 많은 AI 팀은 모델 API를 고를 때 품질, 가격, context window, rate limit을 봤습니다. 에이전트 제품에서는 여기에 per-step latency와 trajectory economics가 추가됩니다. 5단계 tool loop는 조금 느려도 참을 수 있습니다. 30단계 tool loop는 다릅니다. 코딩 에이전트가 테스트를 실행하고 실패 로그를 읽고 패치를 반복하는 동안, 각 단계의 지연시간은 곧 제품의 한계가 됩니다.

prefill은 AMD, decode는 SN50이라는 로드맵

General Compute의 로드맵에서 가장 흥미로운 부분은 "한 칩으로 모든 것을 하지 않겠다"는 대목입니다. 백서는 2026년 4분기에 SambaNova SN50과 AMD MI300X를 조합한 disaggregated stack으로 이동한다고 설명합니다. 긴 prompt를 처리하는 prefill은 AMD MI300X가 맡고, 순차적인 decode는 SN50이 맡는 구조입니다. 사용자는 하나의 API만 보지만, 내부에서는 서로 다른 silicon이 서로 다른 phase를 처리합니다.

이 접근은 추론 provider가 앞으로 더 라우터에 가까워질 수 있음을 보여줍니다. 지금도 OpenRouter 같은 계층은 모델과 provider를 라우팅합니다. 앞으로는 같은 모델 안에서도 prefill과 decode, 긴 컨텍스트와 짧은 tool call, batch와 interactive request가 서로 다른 backend로 갈라질 수 있습니다. 개발자는 여전히 chat.completions.create() 또는 Responses API 형태의 추상화만 볼 수 있지만, 비용 구조는 점점 세분화됩니다.

SambaNova의 SN40L 관련 자료도 이 방향을 뒷받침하는 배경입니다. SambaNova는 SN40L RDU를 reconfigurable dataflow architecture로 설명하고, memory wall과 model switching 문제를 줄이는 데 초점을 맞춰 왔습니다. General Compute는 이 하드웨어를 "에이전트 decode" 문제에 맞춰 포장합니다. 백서는 SN40L, 향후 SN50, air-cooled MI300X가 기존 colocation 시설의 표준 전력 밀도에 들어갈 수 있다는 점도 강조합니다. AI 인프라 병목이 GPU allocation만이 아니라 전력, 냉각, 데이터센터 공사 일정으로 이동했다는 뜻입니다.

OpenAI 호환 API와 "에이전트가 직접 가입하는" 흐름

개발자에게 중요한 것은 하드웨어보다 통합 비용입니다. General Compute의 문서 Introduction은 OpenAI 호환 SDK, 같은 endpoint와 parameter, streaming semantics, tool calling, JSON mode, vision/audio 입력을 핵심 기능으로 소개합니다. 즉, 하드웨어 차별화는 내부에 숨기고, API 표면은 최대한 익숙하게 유지합니다.

Models & Pricing 문서는 MiniMax M2.7, DeepSeek V3.2, DeepSeek V3.1, Llama 3.3 70B, Llama 4 Maverick, GPT-OSS 120B, Gemma 3 12B 등을 열거합니다. GPT-OSS 120B는 128k context, input $0.21/M, output $0.79/M으로 표시됩니다. OpenAI의 gpt-oss 도움말이 이 모델군을 agentic, general-purpose production use case에 적합한 open-weight reasoning model로 설명한다는 점을 감안하면, General Compute가 open-weight 모델을 빠른 추론 substrate 위에 얹어 provider 시장을 노리는 그림이 보입니다.

더 흥미로운 문서는 OpenClaw Integration입니다. 이 문서는 인간이 OpenClaw 설정을 바꾸는 방법뿐 아니라, "For agents" 섹션에서 OpenClaw 에이전트가 직접 API key를 발급받고 provider block을 설정하는 절차를 안내합니다. 사용자의 이메일을 묻고, signup API를 호출하고, verification code를 받고, openclaw.json에 provider block을 붙여넣는 흐름입니다. 아직은 verification code를 사용자가 읽어줘야 하는 등 인간 의존이 남아 있지만, 제품 메시지는 분명합니다. 추론 클라우드의 고객이 사람만이 아니라 에이전트 자체가 될 수 있다는 것입니다.

이 대목은 Circle Agent Stack 같은 agentic payment 인프라, Cloudflare Agent Cloud 같은 runtime 인프라, OpenAI/Anthropic/GitHub의 코딩 에이전트 생태계와 연결됩니다. 에이전트가 도구를 고르고, 유료 API를 호출하고, compute provider를 바꿀 수 있다면, 인프라는 더 이상 개발자가 한 번 설정해두는 배경이 아닙니다. 에이전트의 task planner가 비용, latency, capability를 보고 실행 중 선택하는 대상이 됩니다.

이 뉴스의 실무적 의미

첫째, 에이전트 제품의 병목을 모델 품질 하나로 설명하기 어려워졌습니다. 같은 모델이라도 provider의 prefill latency, decode latency, queueing, region, tool calling 구현, JSON mode 안정성에 따라 전체 경험이 달라집니다. 특히 코딩 에이전트, 리서치 에이전트, 보안 분석 에이전트처럼 tool loop가 긴 제품은 한 번의 응답 품질보다 전체 trajectory의 속도와 실패 복구 비용이 중요합니다.

둘째, "OpenAI-compatible"은 이제 commodity 표면이 됐습니다. 새로운 provider가 개발자에게 요구하는 것은 SDK 교체가 아니라 base URL 교체입니다. 이 말은 전환 비용이 낮아졌다는 뜻이기도 하지만, provider가 품질과 가격을 주장할 때 독립 검증이 더 중요해졌다는 뜻이기도 합니다. API 표면이 같으면 벤치마크는 쉬워집니다. 동시에 마케팅 claim도 쉬워집니다.

셋째, 전력과 냉각이 AI 제품의 사용자 경험으로 내려오고 있습니다. General Compute가 17kW rack, air-cooled silicon, hydroelectric power를 강조하는 이유는 비용 이야기이기도 하지만 capacity 이야기이기도 합니다. liquid-cooled GPU cluster가 공사 일정에 묶인다면, air-cooled inference rack은 더 빨리 들어갈 수 있다는 주장입니다. 이 부분은 회사의 capacity, 계약, 실제 수요가 검증되어야 하지만, AI 인프라 경쟁이 "칩을 샀다"에서 "어디에 얼마나 빨리 꽂을 수 있나"로 이동하는 흐름은 분명합니다.

넷째, 소형 팀에게는 모델 라우팅 전략이 더 현실적인 문제가 됩니다. 모든 요청을 최고 성능 frontier model로 보내는 방식은 긴 tool loop에서 비용이 빨리 커집니다. 반대로 모든 요청을 가장 싼 모델로 보내면 실패한 tool call이 누적돼 전체 비용이 더 커질 수 있습니다. General Compute 같은 provider가 약속하는 것은 "싼 모델"이라기보다 "에이전트 단계당 지연시간과 비용을 낮추는 substrate"입니다. 그 약속이 맞는지는 팀별 workload로 검증해야 합니다.

회의적으로 봐야 할 지점

이 발표를 읽을 때 가장 조심해야 할 부분은 수치의 성격입니다. 공식 사이트의 7x faster, 950 tok/s, 17kW 대 120kW 같은 문구는 강력하지만, 일부는 next-generation rack projection입니다. 백서의 4.6배 end-to-end latency도 회사가 제시한 측정입니다. 독립 벤치마크, 다양한 모델, 긴 실제 agent trajectory, peak traffic 조건, 실패율, JSON/tool call 안정성까지 확인되기 전에는 "GPU 클라우드를 대체했다"고 말하기 어렵습니다.

모델 생태계도 변수입니다. ASIC 또는 dataflow architecture는 특정 workload에 강할 수 있지만, 모델 family가 빠르게 바뀌는 시장에서는 지원 범위와 최적화 속도가 중요합니다. 백서는 Llama, Qwen, DeepSeek, Mixtral, MoE 계열을 언급하지만, 실제 고객은 자신이 쓰는 모델, quantization, LoRA, custom checkpoint, guardrail, observability, region requirement가 맞는지 확인해야 합니다.

또 하나의 질문은 agent workload가 정말 충분히 표준화됐는가입니다. General Compute는 long prompt, short output, sequential trajectory, batch size one을 핵심 패턴으로 잡습니다. 많은 코딩 에이전트와 리서치 에이전트에는 맞는 설명입니다. 그러나 voice agent, browser agent, customer support agent, batch document agent는 서로 다른 profile을 가집니다. 어떤 제품은 prefill이 병목이고, 어떤 제품은 retrieval이나 외부 API latency가 병목이며, 어떤 제품은 모델 자체의 reasoning failure가 병목입니다. 하드웨어 최적화는 필요조건일 수 있지만 충분조건은 아닙니다.

왜 지금 중요한가

General Compute의 등장은 거대한 시장 점유율 뉴스가 아닙니다. 하지만 AI 개발자가 봐야 할 신호는 분명합니다. 에이전트가 늘어날수록 추론은 더 이상 "모델에 prompt를 보내고 답을 받는" 단순 API 호출이 아닙니다. 하나의 작업이 수십 번의 모델 호출, 검색, 파일 읽기, 코드 실행, 테스트, 재시도를 포함하는 실행 그래프가 됩니다. 이 그래프의 비용은 모델 가격표보다 복잡합니다.

그래서 2026년의 AI 인프라 경쟁은 세 층으로 나뉘는 중입니다. 첫 번째는 frontier model과 open-weight model의 품질 경쟁입니다. 두 번째는 에이전트를 배포·관측·통제하는 orchestration 계층입니다. 세 번째는 그 아래에서 호출 하나하나의 latency와 전력 비용을 줄이는 inference substrate입니다. General Compute는 세 번째 층에서 "에이전트는 챗봇과 다른 하드웨어를 요구한다"는 논쟁을 전면화했습니다.

이 주장이 맞다면, 앞으로 AI 팀의 provider 선택은 훨씬 더 workload-aware해집니다. 짧은 챗 응답, 긴 보고서 생성, 코딩 에이전트, 음성 에이전트, 보안 분석 에이전트가 서로 다른 inference backend를 쓸 수 있습니다. 모델 라우터는 단순히 가장 싼 API를 고르는 도구가 아니라, prefill, decode, context length, tool call reliability, region, 전력 비용을 함께 최적화하는 계층이 됩니다.

반대로 이 주장이 과장이라면, General Compute는 빠르게 검증될 것입니다. OpenAI 호환 API라는 표면은 고객이 쉽게 들어오게 하지만, 쉽게 나가게도 합니다. 에이전트 개발자는 실제 repo, 실제 테스트, 실제 tool loop로 provider를 비교할 수 있습니다. 마케팅 문구보다 중요한 것은 한 작업을 끝까지 완료하는 시간, 실패한 tool call 비율, 재시도 비용, peak 시간의 안정성입니다.

결국 이번 뉴스의 핵심은 "새 API가 나왔다"가 아닙니다. 에이전트가 AI 인프라를 다시 쪼개고 있다는 점입니다. 챗봇 시대에는 GPU throughput과 모델 품질이 대부분의 이야기를 차지했습니다. 에이전트 시대에는 작은 배치의 decode, 긴 컨텍스트 prefill, tool loop의 누적 지연, 전력 밀도, provider 전환성이 함께 움직입니다. General Compute가 실제로 GPU 세금을 7배 줄일지는 더 검증되어야 합니다. 그러나 에이전트 제품을 만드는 팀이라면 이제 모델 이름 옆에 "이 trajectory는 어떤 hardware path를 타는가"라는 질문을 붙여야 합니다.