Workers AI는 edge에서 inference를 수행할 수 있으며, 많은 팀에게는 이 사실 하나만으로도 새로운 Worker를 배포하기에 충분합니다. 하지만 지원 여부만으로는 부족합니다. 동일한 모델이라도 Worker가 전혀 필요 없는 경로가 존재하기 때문입니다. 바로 기존 backend에서 일반적인 Cloudflare API 토큰을 사용하여 POST /accounts/{account_id}/ai/run/{model} REST 호출을 직접 수행하는 방식입니다. 사용자에게 가깝다는 사실 그 자체는 아무것도 증명하지 않습니다. 유용성은 단순히 가깝다는 사실이 아니라, 그 근접성이 특정 경로에서의 구체적인 지연 시간 (latency)을 단축하느냐에 달려 있습니다. 만약 edge에 코드를 배치하는 것이 지연 시간을 단축하지 못한다면, 일반적인 backend가 정답이며 새로운 Worker는 운영상의 불필요한 구성 요소가 됩니다.

다음으로, 저는 토론에서 거의 항상 하나로 묶여 다뤄지는 두 가지 질문, 즉 '어떤 모델을 호출할 것인가'와 '코드가 물리적으로 어디에서 실행되는가'를 분리하여 다루고자 합니다. 모델은 호출 방식과 관계없이 카탈로그의 동일한 @cf/ 식별자에 의해 결정됩니다. 배치는 별개의 문제이며, 그 자체로 고유한 운영 비용이 따릅니다. 따라서 이는 지원되는 모델 목록이 아니라, 특정 요청의 경로(map)를 바탕으로 결정해야 합니다.

아래는 이 경로를 측정하기 위한 작은 카나리 (canary) 계획입니다: 클라이언트, Worker, 모델, 응답. 이것은 계획이지 완료된 측정 보고서가 아닙니다. 본문에 포함된 어떤 지연 시간 수치도 Cloudflare 문서에서 가져온 것이 아닙니다. 문서에는 그런 수치가 없으며, 모든 밀리초 (millisecond) 단위의 수치는 직접 실행한 결과에서 나와야 합니다.

당신이 실제로 선택하는 것: 모델인가, 배치인가?

팀 내에서의 첫 번째 논의는 보통 다음과 같이 시작됩니다: "Workers AI가 edge에서의 inference를 지원하니, 생성 작업을 그쪽으로 옮깁시다." 여기서의 오류는 전제 자체에 숨어 있습니다. edge에서의 inference 지원이 edge의 유용성을 증명하는 것은 아닙니다. 이 둘은 서로 다른 두 가지 주장이며, 두 번째를 증명할 수 있는 것은 오직 측정뿐입니다.

Workers AI의 모델은 당신이 어떻게 호출하든 동일한 @cf/ 식별자로 참조됩니다. Cloudflare 문서에 따르면 카탈로그에는 텍스트 생성, 임베딩 (embeddings), 이미지, 오디오를 포함하여 50개 이상의 오픈 웨이트 (open-weight) 모델이 있습니다. 여기에는 Llama 3.1/4, Qwen3 제품군, GLM-4.7-Flash, BGE 및 Qwen3 임베딩 등이 포함됩니다. 동일한 ID가 Worker 내부와 외부 백엔드 (backend) 모두에서 작동합니다. 즉, 모델 선택은 코드가 어디에서 실행되는지와 전혀 무관합니다.

배치 (placement) 문제는 다릅니다. 기본적으로 Worker는 호출하는 백엔드 (backend)가 아니라, 들어오는 요청에 가장 가까운 Cloudflare 데이터 센터에서 실행됩니다. 클라이언트와의 근접성과 해당 백엔드 (backend)에 필요한 데이터와의 근접성은 서로 다른 것이며, 하나를 최적화하면 다른 하나가 악화될 수 있습니다. 따라서 "Worker가 필요한가"라는 질문은 지원되는 모델 목록만 보고는 결정할 수 없습니다.

두 가지 호출 경로, 그리고 두 번째 경로가 Worker의 논거를 깨뜨리는 이유

Workers AI에는 두 가지 진입로가 있으며, 이는 인프라에 대한 논의를 근본적으로 변화시킵니다.

첫 번째 경로: Worker 내부에서의 바인딩 (binding). Wrangler 설정에서 [ai]-바인딩 (binding)을 선언하면 코드 내에 env.AI.run(model, options)가 나타납니다. 여기서 인증은 암시적입니다. 요청은 Worker 자체의 플랫폼 정체성으로 수행되므로, 별도의 API 토큰을 수동으로 발급할 필요가 없습니다. 이는 다른 이유로 이미 Worker를 사용 중일 때 매우 편리합니다.

두 번째 경로는 공정한 결정을 내리는 데 더 중요합니다. Workers AI는 배포된 Worker가 전혀 없어도 REST를 통해 사용할 수 있습니다. 어떤 외부 백엔드 (backend)든 POST https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}로 요청을 보내며, 헤더에 계정 ID와 함께 Workers AI Read/Edit 권한을 가진 Cloudflare API 토큰으로 인증합니다. AI Gateway를 통하면 Worker 내부의 env.AI.gateway(id) 바인딩 (binding)과 에지 (edge) 외부에서의 순수 REST 방식 모두를 사용할 수 있습니다.

여기서 도출할 수 있는 결론은 하나이며 매우 단호합니다. Workers AI의 존재 자체가 호출하는 코드가 반드시 Worker에서 실행될 필요는 없다는 것입니다. 만약 cloudflare workers ai api를 찾고 있고 통합을 고려 중이라면, 새로운 Worker를 만들기보다 기존 서비스에서 REST 방식으로 시작하십시오. Worker는 코드를 에지 (edge)에 배치함으로써 특정 경로의 관련 지연 시간 (latency)을 줄일 수 있다는 가설이 있을 때만 추가하십시오.

"클라이언트—Worker—모델—응답" 요청 맵은 어떻게 생겼는가

해결을 위한 주요 도구는 벤치마크 (benchmark)가 아니라, 단일 요청의 경로 맵입니다. 코드를 작성하기 전에 이 맵을 그려보아야 합니다. 왜냐하면 이 맵을 통해서만 당신이 어떤 홉 (hop)을 단축하려 하는지 알 수 있기 때문입니다.

에지 (edge) 방식에서의 경로는 다음과 같습니다: 클라이언트가 자신과 가장 가까운 Cloudflare 데이터 센터로 요청을 보내면, 그곳에서 Worker가 실행되고, Worker가 모델을 호출하며, 응답이 클라이언트에게 다시 전달됩니다. 백엔드 (backend) 방식에서는 클라이언트가 당신의 일반적인 서비스로 요청을 보내고, 그 서비스가 REST를 통해 Workers AI를 호출합니다. 이 두 가지 맵 사이의 차이가 바로 카나리 (canary) 테스트가 측정해야 할 대상입니다.

여기서 놓치기 쉬운 Cloudflare 문서의 주의 사항이 하나 있습니다. Workers AI는 인퍼런스 (inference)를 "Cloudflare 네트워크 내의 서버리스 GPU (serverless GPU)" 작업으로 설명하지만, 모든 호출이 클라이언트와 가장 가까운 데이터 센터에서 실행된다고 어디에서도 보장하지 않습니다. GPU 위치는 스케줄러 (scheduler)에 의해 관리되는 네트워크의 하위 집합이지, 보편적인 근접성을 보장하는 것이 아닙니다. 즉, 당신의 맵에는 두 가지 서로 다른 배치 (placement) 결정이 존재합니다: 당신의 JavaScript가 실행되는 위치와 Cloudflare가 GPU 호출 자체를 계획하는 위치입니다. 이 둘은 동일하지 않으며, Worker의 배치를 측정하는 카나리 테스트가 인퍼런스의 배치를 자동으로 측정하는 것은 아닙니다. 이들은 별개의 홉 (hop)으로 추적(trace)되어야 합니다.

비용은 얼마나 들며, 한계치는 생각보다 어디서 먼저 오는가

Worker를 실행하기 전에 두 가지 상한선, 즉 과금 (billing)과 속도 제한 (rate limits)을 살펴보아야 합니다. 두 가지 모두 직관적인 예상과는 다르게 설정되어 있습니다.

Cloudflare의 과금은 뉴런 (Neurons) 단위로 계산됩니다. Free 및 Paid Workers 플랜 모두에 공통으로 적용되는 10,000 뉴런이 매일 UTC 00:00에 초기화되어 무료로 제공됩니다. 이를 초과할 경우 Paid 플랜에서의 가격은 1,000 뉴런당 $0.011입니다. 한편, Cloudflare의 가격 페이지에는 모델별 개별 과금 방식(토큰, 단계, 문자 수)으로 전환 중이라고 솔직하게 명시되어 있지만, 백엔드 계산은 여전히 뉴런 단위로 환산됩니다. 실질적인 결론은 다음과 같습니다: 카나리 (canary) 모델의 특정 모델에 대한 정확한 요율은 안정적인 것으로 간주하지 말고, 빌드 시점에 다시 확인해야 합니다.

속도 제한 (Rate limits)은 하나의 글로벌 제한이 아니라 작업(task)과 모델별로 설정되어 있습니다. 텍스트 생성 (Text generation)은 기본적으로 분당 300회 요청 (rpm)이며, 모델에 따라 범위는 약 1501500 rpm입니다. 텍스트 임베딩 (Text embeddings)은 15003000 rpm입니다. 이미지 분류 (Image classification) 및 객체 탐지 (Object detection)는 최대 3000 rpm까지 가능합니다. 그리고 카나리 배포를 위한 별도의 함정이 하나 있는데, Wrangler의 dev 모드에서 수행되는 로컬 추론 (inference)도 동일한 제한 사항에 합산된다는 점입니다. 제한 사항에 관한 문서에는 Free 플랜과 Paid 플랜 간의 제한 차이가 있는지 명시되어 있지 않으며, 동시성 (concurrency) 및 배치 (batch)에 대한 상한선도 설명되어 있지 않습니다. 따라서 이는 RPM 수치로부터 유도하는 것이 아니라 경험적으로 확인해야 합니다.

여기서 모델 선택과 모델 액세스 제공자 (provider) 선택이라는 두 가지 개념을 구분할 필요가 있습니다. provod.ai (OpenRouter의 러시아판 유사 서비스)는 정확히 두 번째 질문에 답하며 Workers AI와는 다른 축에서 작동합니다. 이는 추론 (inference) 위치를 사용자에게 가깝게 배치하는 것이 아니라, 하나의 호환 가능한 API를 통해 Claude, GPT, Gemini, DeepSeek, Qwen을 포함한 다양한 제공자의 모델을 하나의 키로 사용할 수 있게 해주는 것입니다. 이것이 실무에서 어떤 의미를 갖는지는 provod.ai에서 확인할 수 있습니다.

연결 방식은 Workers AI의 REST 경로를 미러링하며, 변경 방식 또한 동일합니다. Cloudflare 계정 주소가 아니라, OpenAI 또는 Anthropic SDK를 사용하는 base_url과 키를 통해 변경됩니다.

export OPENAI_API_KEY="provod-key"
export OPENAI_BASE_URL="https://api.provod.ai/v1"

이러한 연결 형식은 provod.ai 페이지에서 확인할 수 있습니다. 경계에 대한 별도의 주의 사항을 말씀드리자면, provod.ai를 통한 모델 접근은 여러 제공업체(provider) 상단에 위치한 중앙 집중식 호환 계층(central compatible layer)으로 유지되며, 고객의 프라이빗(private) 또는 온프레미스(on-prem) 인프라가 아닙니다. 따라서 이를 모델의 로컬(local) 또는 에지(edge) 배치와 혼동해서는 안 됩니다. 여기서의 탄력성(resilience) 또한 지리적 위치가 아닌 라우팅(routing)을 기반으로 구축됩니다. 즉, 하나의 상위 제공업체 채널이 일시적으로 사용할 수 없는 경우에도 멀티 채널(multi-channel) 체계가 요청을 계속해서 전달합니다.

작은 카나리아가 배치의 이점을 측정하는 방법

좋은 소식은 Cloudflare에 배치를 둘러싼 논쟁을 측정 가능한 수치로 바꿔주는 내장 메커니즘이 있다는 것입니다. 나쁜 소식은 그것이 지도의 두 홉(hop) 중 하나만 측정한다는 점입니다.

바로 스마트 플레이스먼트(Smart Placement)에 관한 이야기입니다. 기본적으로 Worker는 클라이언트 근처에서 실행됩니다. 스마트 플레이스먼트는 Worker의 실행을 백엔드(backend)에 더 가깝게 이동시키되, 그것이 측정 가능할 정도로 더 빠를 때만 이동시킵니다. 또한 각 응답에 cf-placement 헤더(local- 대 remote-)를 표시하며, 기준점(baseline)으로서 1%의 트래픽은 의도적으로 이동시키지 않고 남겨둡니다. 이는 Cloudflare가 배치의 선택이 특정 요청 경로에 도움이 되는지를 경험적으로 확인하는 공식적인 방법입니다. 저는 바로 이러한 로직, 즉 가용성(availability)이 아닌 측정(measurement)에 기반한 해결책을 에지(edge)에 관한 전체 문제로 확장하여 적용하고자 합니다.

카나리(Canary) 테스트는 소박해 보입니다. [ai] 바인딩(binding)이 포함된 최소한의 Worker를 배포하여, 맹신할 수 없는 세 가지 사항을 확인합니다: 바인딩과 REST가 선택한 모델에서 실제로 작동하는지, 인증이 두 경로 모두에서 통과되는지, 그리고 실제 제한 사항(limits)이 문서화된 내용과 일치하는지입니다. 이와 동시에 REST를 통한 백엔드(backend) 옵션을 병행합니다. 동일한 경로에서 지연 시간(latency) 분포를 수집하고, cf-placement 헤더를 대조하여 실제로 무엇이 이동했는지 파악합니다.

// 카나리 Worker: 바인딩 확인 및 cf-placement 읽기
export default {
  async fetch(request, env) {
...

# 백엔드 경로: Worker 없이 REST를 통한 동일한 @cf/-식별자 사용
curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run/@cf/meta/llama-3.1-8b-instruct" \
...

카나리 테스트의 핵심적인 정직함은 그 제한 사항에 있습니다. Smart Placement는 JavaScript가 실행되는 위치를 관리하며, 이는 Cloudflare가 인퍼런스(inference) GPU 호출 자체를 계획하는 위치와는 별개의 메커니즘입니다. 두 배치(placement) 기록은 동일하지 않습니다. 만약 Worker 이동을 통해 이득을 보았더라도, 인퍼런스 배치의 이득을 증명한 것은 아닙니다. 지도상에서 이들은 서로 다른 홉(hop)이며, 각각 별도로 측정해야 합니다.

결정적인 표: 에지(edge)인가 일반 백엔드인가

이 모든 것을 한눈에 파악하는 데는 표가 도움이 됩니다. 이 표는 "에지가 유행인가"를 다루는 것이 아니라, 해당 시나리오에 측정 가능한 근거가 있는지를 다룹니다.

표의 로직은 계획의 결정 추적(decision trace)을 반영합니다. 채택된 비용은 소규모 카나리(canary)를 실행하는 것입니다. 대안은 일반적인 백엔드(backend)를 사용하거나, 측정 가능한 효과가 있을 때 edge를 사용하는 것입니다. edge를 포기하는 기준은 명확하게 명시되었습니다: 측정 가능한 이점이 없거나, 플랫폼 제한 사항이 시나리오를 망가뜨리는 경우입니다. 반증 가능한(Falsifiable) 테제는 다음과 같습니다: 만약 카나리가 배치의 측정 가능한 이점을 보여주지 못한다면, Workers AI는 새로운 Worker를 사용할 가치가 없습니다.