같은 모델, 두 개의 문 : Bedrock Mantle 엔드포인트와 bedrock-runtime을 도쿄 리전에서 실측 비교
Amazon Bedrock에는 추론 요청을 받는 엔드포인트가 두 개 있습니다. 예전부터 쓰던 bedrock-runtime.{region}.amazonaws.com과, OpenAI 호환 API와 Anthropic Messages API를 제공하는 bedrock-mantle.{region}.api.aws입니다. AWS 공식 문서는 두 엔드포인트가 같은 Mantle 추론 엔진 위에서 동작하며 bedrock-mantle이라는 이름은 엔진이 아니라 엔드포인트 표면을 가리킨다고 설명합니다. 그렇다면 “같은 모델을 같은 리전에서 호출할 때 응답 속도도 같은가”라는 질문이 자연스럽게 생깁니다. 이 글은 그 질문을 문서가 아니라 실측으로 확인합니다.
만들 것은 도쿄 리전(ap-northeast-1)에서 같은 모델을 두 엔드포인트로 번갈아 호출해 지연 시간을 비교하는 벤치마크입니다. Bedrock API 키, 두 엔드포인트의 URL과 모델 ID 표기 차이, IAM 액션 네임스페이스 차이, 쿼터 구조 차이를 거치게 됩니다. 어떤 기능을 어디에 사용했는지는 글 마지막에 표로 정리해두었습니다.
만들 것은 도쿄 리전(ap-northeast-1)에서 같은 모델을 두 엔드포인트로 번갈아 호출해 지연 시간을 비교하는 벤치마크입니다. Bedrock API 키, 두 엔드포인트의 URL과 모델 ID 표기 차이, IAM 액션 네임스페이스 차이, 쿼터 구조 차이를 거치게 됩니다. 어떤 기능을 어디에 사용했는지는 글 마지막에 표로 정리해두었습니다.
실습 환경
| 항목 | 내용 |
|---|---|
| 배포 대상 | AWS ap-northeast-1 (도쿄), IAM 리소스만 생성 |
| 런타임 요건 | Terraform 1.15.8, AWS Provider 6.62.0, openai 3.6.0, anthropic 1.2.0, boto3 1.42 |
| 비교 모델 | gpt-oss-120b (Chat Completions API), Claude Haiku 4.5 (Anthropic Messages API) |
| 측정 시각 | 2026-09-01 (KST 오후) |
목표 아키텍처
이 실험의 핵심은 “조건을 최대한 같게 맞추는 것”입니다. 같은 리전, 같은 모델, 같은 프롬프트, 같은 API 키, 같은 클라이언트 PC에서 엔드포인트 호스트 이름만 바꿔 호출해야 두 엔드포인트의 차이만 남습니다. 그래서 별도 서버를 두지 않고 개발자 PC에서 직접 호출하는 구성을 택했습니다.
배포 모델은 단순합니다. AWS 쪽에 만드는 리소스는 IAM 사용자 하나, 그 사용자에게 붙는 인라인 정책 하나, 그리고 그 사용자에게 발급되는 Bedrock 장기 API 키 하나뿐입니다. Bedrock 장기 API 키는 실체가 IAM 서비스 전용 자격 증명(service-specific credential)이므로 Terraform의 aws_iam_service_specific_credential 리소스로 만들 수 있습니다. 벤치마크 스크립트는 이 키 하나로 두 엔드포인트를 모두 호출합니다. 두 엔드포인트 모두 Bedrock API 키 인증을 지원하기 때문입니다.
호출 대상은 도쿄 리전의 두 엔드포인트입니다. bedrock-runtime은 OpenAI 호환 API를 /openai/v1 경로에, Anthropic Messages API를 /anthropic 경로에 제공합니다. bedrock-mantle은 OpenAI 호환 API를 /v1 경로에, Messages API를 /anthropic/v1/messages에 제공합니다. 두 엔드포인트 뒤에는 같은 Mantle 추론 엔진이 있고, 지표는 각각 AWS/Bedrock과 AWS/BedrockMantle 네임스페이스로 CloudWatch에 발행됩니다.
한 가지 비대칭이 있습니다. gpt-oss-120b는 두 엔드포인트 모두 도쿄 in-region으로 제공되지만, Claude Haiku 4.5는 bedrock-runtime에 도쿄 in-region 모델 ID가 없고 Geographic Inference Profile(도쿄와 오사카 사이 라우팅)로만 호출할 수 있습니다. 반면 bedrock-mantle은 크로스리전 추론이 없고 요청한 리전에서 처리가 끝납니다. 따라서 Claude 비교는 “in-region 대 Geographic Inference Profile” 비교라는 점을 감안해서 읽어야 합니다.
다이어그램의 구성 요소는 다음과 같습니다.
| 구성 요소 | 역할 |
|---|---|
| AWS IAM | 사용자 bedrock-mantle-bench와 API 키 보관 |
| bedrock-runtime 엔드포인트 | bedrock-runtime.ap-northeast-1.amazonaws.com |
| bedrock-mantle 엔드포인트 | bedrock-mantle.ap-northeast-1.api.aws |
| Mantle 추론 엔진 | 두 엔드포인트가 공유하는 추론 엔진, Zero Operator Access 설계 |
| gpt-oss-120b | 비교 모델 1 |
| Claude Haiku 4.5 | 비교 모델 2 |
| ap-northeast-3 (오사카) | jp. 지리적 추론 프로파일의 라우팅 후보 리전 |
| Amazon CloudWatch | 두 엔드포인트의 호출 지표 |
표에서 눈여겨볼 점은 AWS 쪽에 생성되는 리소스가 IAM 세 개뿐이라는 것입니다. 엔드포인트, 엔진, 모델은 모두 AWS가 관리하는 서비스이므로 만들거나 지울 것이 없고, 비용은 호출한 토큰만큼만 발생합니다.
한 회차의 실행 시퀀스를 그려보면 다음과 같습니다.
시퀀스에서 중요한 것은 두 엔드포인트가 같은 엔진으로 들어간다는 점과, 회차마다 호출 순서를 바꿔 특정 엔드포인트가 항상 먼저 호출되는 편향을 줄인다는 점입니다.
Step 1. Terraform으로 실측용 IAM 사용자와 Bedrock API 키 만들기
이 단계에서는 두 엔드포인트를 모두 호출할 수 있는 최소 권한의 IAM 사용자와 Bedrock 장기 API 키를 Terraform으로 만듭니다. 실측이 끝나면 통째로 지울 수 있도록 리소스를 한 곳에 모으는 것이 목적입니다.
먼저 API 키가 왜 필요한지부터 짚겠습니다. OpenAI SDK는 AWS SigV4 서명을 모릅니다. 그래서 OpenAI SDK로 Bedrock을 호출하려면 Bearer 토큰 형태의 Bedrock API 키가 필요합니다. API 키는 두 종류입니다. 단기 키는 최대 12시간 유효하고 생성한 IAM 주체의 권한을 상속하며, 장기 키는 IAM 사용자에 붙는 서비스 전용 자격 증명으로 만료일을 정할 수 있습니다. 공식 문서는 장기 키를 탐색 용도로만 권장합니다. 이 실험은 몇 시간 안에 끝나고 끝나는 즉시 지우므로 장기 키를 만료 1일로 만들었습니다.
Bedrock API 키를 만드는 경로는 세 가지입니다.
| 발급 경로 | 적합한 상황 | 명령 또는 방법 |
|---|---|---|
| 콘솔 | 한 번 써보고 버릴 때 | Bedrock 콘솔 > API keys > Long-term API keys > Generate |
| AWS CLI | 스크립트에서 즉석 발급 | aws iam create-service-specific-credential --user-name <user> --service-name bedrock.amazonaws.com --credential-age-days <days> |
| Terraform (이번 사례) | 사용자, 정책, 키를 한 단위로 만들고 지울 때 | aws_iam_service_specific_credential 리소스, credential_age_days 인자 |
Terraform 구성은 다음과 같습니다. 정책에는 bedrock-runtime용 액션과 bedrock-mantle용 액션을 별도 Statement로 나눠 넣었습니다. 두 엔드포인트의 IAM 액션 네임스페이스가 다르기 때문입니다.
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = ">= 6.0"
}
}
}
provider "aws" {
region = var.region # 기본값 ap-northeast-1
}
resource "aws_iam_user" "bench" {
name = "bedrock-mantle-bench"
path = "/bench/"
}
# runtime과 mantle은 IAM 액션 네임스페이스가 다르다
resource "aws_iam_user_policy" "bench" {
name = "bedrock-both-endpoints-inference"
user = aws_iam_user.bench.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "RuntimeEndpoint"
Effect = "Allow"
Action = [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:CallWithBearerToken",
"bedrock:ListFoundationModels",
"bedrock:ListInferenceProfiles",
"bedrock:GetInferenceProfile"
]
Resource = "*"
},
{
Sid = "MantleEndpoint"
Effect = "Allow"
Action = [
"bedrock-mantle:CreateInference",
"bedrock-mantle:ListModels",
"bedrock-mantle:CallWithBearerToken"
]
Resource = "*"
}
]
})
}
# Bedrock 장기 API 키 = IAM 서비스 전용 자격 증명
resource "aws_iam_service_specific_credential" "bedrock_api_key" {
service_name = "bedrock.amazonaws.com"
user_name = aws_iam_user.bench.name
credential_age_days = 1
depends_on = [aws_iam_user_policy.bench]
}
output "bedrock_api_key" {
value = aws_iam_service_specific_credential.bedrock_api_key.service_credential_secret
sensitive = true
}
적용은 평소와 같습니다.
terraform init
terraform apply -auto-approve
# 벤치마크 스크립트에 키 전달 (PowerShell 예시)
$env:BEDROCK_API_KEY = (terraform output -raw bedrock_api_key)
실제 적용 결과 IAM 사용자, 인라인 정책, API 키 세 리소스가 만들어졌고 출력에는 키 ID와 만료 시각(생성 시각 + 1일)이 표시되었습니다. 키 본문은 sensitive 출력이라 화면에 나오지 않고 terraform output -raw로만 읽습니다.
여기서 막히기 쉬운 지점을 정리하면 다음과 같습니다.
| 증상 | 원인 | 조치 |
|---|---|---|
credential_age_days 인자를 모른다는 오류 | AWS Provider가 오래됨 | 최신 6.x로 올림 (이번 실습은 6.62.0). 이 인자는 Bedrock 키에만 유효 |
mantle 호출 시 403 bedrock-mantle:ListModels ... not authorized | bedrock:* 액션은 mantle 호출을 인가하지 않음 | 정책에 bedrock-mantle:CreateInference, bedrock-mantle:ListModels 추가 |
| Bearer 키로 호출 시 거부 | CallWithBearerToken 액션이 Deny 되어 있음 | bedrock:CallWithBearerToken과 bedrock-mantle:CallWithBearerToken 둘 다 확인 |
| 키를 잃어버림 | service_credential_secret은 생성 시점에만 조회 가능 | terraform state에 남아 있으므로 output -raw로 재조회, 아니면 리소스 재생성 |
이 단계가 끝나면 키 하나로 도쿄 리전의 두 엔드포인트를 모두 호출할 수 있습니다.
Step 2. 두 엔드포인트 연결 확인 — URL, 모델 ID, 권한이 어떻게 다른가
이 단계에서는 본격적인 측정에 앞서 각 엔드포인트에 한 번씩 호출해 URL, 모델 ID, 응답 형식이 어떻게 다른지 확인합니다. 벤치마크 결과를 해석하려면 이 차이를 먼저 알아야 합니다.
같은 모델이라도 두 엔드포인트에서 부르는 이름이 다릅니다. bedrock-runtime은 Bedrock 고유의 모델 ID(버전 접미사 포함) 또는 크로스리전 추론 프로파일 ID를 쓰고, bedrock-mantle은 접두사 없는 파운데이션 모델 ID를 씁니다. 다음 표는 이번 실험에서 실제로 동작한 조합입니다.
| 항목 | bedrock-runtime | bedrock-mantle |
|---|---|---|
| OpenAI 호환 base URL | https://bedrock-runtime.ap-northeast-1.amazonaws.com/openai/v1 | https://bedrock-mantle.ap-northeast-1.api.aws/v1 |
| Anthropic SDK base URL | https://bedrock-runtime.ap-northeast-1.amazonaws.com/anthropic | https://bedrock-mantle.ap-northeast-1.api.aws/anthropic |
| gpt-oss-120b 모델 ID | openai.gpt-oss-120b-1:0 (openai.gpt-oss-120b는 400 오류) | openai.gpt-oss-120b |
| Claude Haiku 4.5 모델 ID | jp.anthropic.claude-haiku-4-5-20251001-v1:0 (지리 프로파일) | anthropic.claude-haiku-4-5 |
| 인증 | Bedrock API 키 또는 SigV4 | Bedrock API 키 또는 SigV4 |
| 인가 액션 | bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream | bedrock-mantle:CreateInference |
GET /models 응답 (도쿄) | UnknownOperationException | 정상 (bedrock-mantle:ListModels 필요) |
| 크로스리전 추론 | 지리, 글로벌 프로파일 지원 | 미지원, 요청 리전에서 처리 |
연결 확인 스크립트의 핵심은 다음과 같습니다. 두 SDK 모두 base URL과 API 키만 바꾸면 그대로 동작합니다.
import os
from openai import OpenAI
from anthropic import Anthropic
REGION = "ap-northeast-1"
KEY = os.environ["BEDROCK_API_KEY"]
# OpenAI 호환 Chat Completions
runtime = OpenAI(base_url=f"<https://bedrock-runtime>.{REGION}.amazonaws.com/openai/v1", api_key=KEY)
mantle = OpenAI(base_url=f"<https://bedrock-mantle>.{REGION}.api.aws/v1", api_key=KEY)
for name, client, model in [("runtime", runtime, "openai.gpt-oss-120b-1:0"),
("mantle", mantle, "openai.gpt-oss-120b")]:
r = client.chat.completions.create(
model=model, max_tokens=64,
messages=[{"role": "user", "content": "Reply with exactly: pong"}],
extra_body={"reasoning_effort": "low"},
)
print(name, repr(r.choices[0].message.content), r.usage)
# Anthropic Messages API
runtime_a = Anthropic(base_url=f"<https://bedrock-runtime>.{REGION}.amazonaws.com/anthropic", api_key=KEY)
mantle_a = Anthropic(base_url=f"<https://bedrock-mantle>.{REGION}.api.aws/anthropic", api_key=KEY)
for name, client, model in [("runtime", runtime_a, "jp.anthropic.claude-haiku-4-5-20251001-v1:0"),
("mantle", mantle_a, "anthropic.claude-haiku-4-5")]:
r = client.messages.create(model=model, max_tokens=32,
messages=[{"role": "user", "content": "Reply with exactly: pong"}])
print(name, repr(r.content[0].text), r.usage)
실행하면 네 호출이 모두 성공하는데, gpt-oss-120b의 응답 본문이 엔드포인트에 따라 다르게 옵니다. bedrock-runtime은 <reasoning>We need to output exactly "pong".</reasoning>pong처럼 추론 과정을 content 안에 태그로 포함해 돌려주고, bedrock-mantle은 pong만 돌려줍니다. 두 응답의 completion_tokens는 19로 같았습니다. 즉 모델이 생성한 토큰은 같고, 그것을 클라이언트에 어떻게 노출하느냐가 엔드포인트마다 다릅니다. 이 차이는 뒤의 지연 시간 해석에도 영향을 줍니다.
Anthropic SDK를 mantle에 붙일 때 한 가지 주의할 점이 있습니다. base URL을 https://bedrock-mantle.{region}.api.aws까지만 주면 SDK가 /v1/messages를 붙여 404가 납니다. mantle의 Messages API 경로는 /anthropic/v1/messages이므로 base URL에 /anthropic까지 포함해야 합니다.
요청이 어느 경로로 인가되고 처리되는지 흐름으로 정리하면 다음과 같습니다.
흐름에서 주목할 점은 인가와 쿼터가 호스트 이름 단계에서 갈라지고, 엔진에서 다시 합쳐진다는 것입니다. 이 단계가 끝나면 두 엔드포인트의 응답 형식과 권한 차이를 알고 벤치마크를 돌릴 수 있습니다.
Step 3. 벤치마크 스크립트 작성 — 무엇을 어떻게 재는가
이 단계에서는 측정 방법을 정합니다. 지연 시간 비교는 측정 방법이 조금만 달라도 결론이 뒤집히므로, 무엇을 재고 무엇을 통제했는지를 먼저 밝힙니다.
측정 지표는 네 가지입니다.
| 지표 | 정의 | 측정 모드 |
|---|---|---|
| E2E 지연 | 요청 전송부터 응답 객체 수신 완료까지 (ms) | 비스트리밍, 스트리밍 |
| TTFT | 요청 전송부터 첫 텍스트 델타 수신까지 (ms). 추론 토큰이 아니라 사용자에게 보이는 첫 글자 기준 | 스트리밍 |
| 출력 토큰 속도 | 출력 토큰 수 / (E2E – TTFT), 토큰/초 | 스트리밍 |
| 토큰 수 | 응답 usage의 입력, 출력 토큰 | 비스트리밍, 스트리밍 (OpenAI는 stream_options.include_usage, Anthropic은 message_delta 이벤트) |
통제한 조건은 다음과 같습니다.
| 조건 | 설정 | 이유 |
|---|---|---|
| 리전 | ap-northeast-1 고정 | 두 엔드포인트 모두 도쿄 in-region 제공 리전 |
| 모델 | gpt-oss-120b, Claude Haiku 4.5 | 두 엔드포인트에서 모두 제공되고 도쿄에서 호출 가능 |
| 프롬프트 | short(질문 한 문장), medium(로그 180줄), long(로그 1,400줄) | 프리필 비중이 다른 세 구간. 입력 토큰은 토크나이저에 따라 gpt-oss 98 / 8,045 / 61,715, Claude 37 / 9,112 / 70,398 |
max_tokens | 200 | 출력 길이 편차를 제한 |
gpt-oss reasoning_effort | low | 추론 토큰이 출력 한도를 다 쓰는 것을 방지 |
| 반복 | 프롬프트별, 모드별 5회, 회차마다 호출 순서 교차 | 순서 편향 완화 |
| 재시도 | max_retries=0, 실패 시 스크립트에서 최대 3회 | SDK 자동 재시도로 지연이 가려지지 않게 |
| 워밍업 | 엔드포인트당 1회, 결과 제외 | DNS와 TLS 핸드셰이크 비용 제거 |
medium과 long 프롬프트는 결정적으로 생성한 합성 운영 로그입니다. 로그 한 줄에 서비스 이름, 상태, p99 지연, CPU 사용률을 넣고, 그중 한 줄에만 INCIDENT-7731 root-cause=expired-tls-certificate를 심어 “몇 번 항목에 INCIDENT-7731이 있고 원인은 무엇인가”를 묻습니다. 모델이 프롬프트 전체를 실제로 읽어야 답할 수 있게 하기 위해서입니다.
def make_log(n_entries: int) -> str:
lines = []
for i in range(1, n_entries + 1):
svc = SERVICES[i % len(SERVICES)]
st = STATUSES[(i * 7) % len(STATUSES)]
lat = 40 + (i * 37) % 900
cpu = 5 + (i * 13) % 90
lines.append(f"[entry {i:05d}] 2026-08-{(i % 28) + 1:02d}T{(i % 24):02d}:{(i * 3) % 60:02d}Z "
f"service={svc} status={st} p99_latency_ms={lat} cpu={cpu}% "
f"note=routine check by operator {chr(65 + i % 26)}{chr(65 + (i * 3) % 26)}")
return "\n".join(lines)
# medium: 180줄에 97번 항목에 needle, long: 1400줄에 1123번 항목에 needle
스트리밍 측정부의 핵심은 다음과 같습니다. TTFT는 delta.content가 비어 있지 않은 첫 청크에서 찍습니다.
def stream(self, prompt):
t0 = time.perf_counter(); ttft = None; out_tok = None
s = self.c.chat.completions.create(
model=self.model, max_tokens=self.max_tokens, stream=True,
messages=[{"role": "system", "content": SYSTEM}, {"role": "user", "content": prompt}],
stream_options={"include_usage": True},
extra_body={"reasoning_effort": "low"},
)
for ch in s:
if getattr(ch, "usage", None):
out_tok = ch.usage.completion_tokens
if ch.choices and ch.choices[0].delta and ch.choices[0].delta.content:
if ttft is None:
ttft = time.perf_counter() - t0
dt = time.perf_counter() - t0
return dict(e2e_ms=dt * 1000, ttft_ms=(ttft or dt) * 1000, out_tok=out_tok)
호출 순서 교차는 다음 한 줄로 처리합니다. 짝수 회차는 runtime을 먼저, 홀수 회차는 mantle을 먼저 호출합니다.
order = ("runtime", "mantle") if i % 2 == 0 else ("mantle", "runtime")
실행 명령은 다음과 같습니다. 두 모델은 서로 간섭하지 않도록 순차로 돌렸습니다.
python bench.py --suite gptoss --runs 5 --out results_gptoss.json
python bench.py --suite haiku --runs 5 --out results_haiku.json
이 단계가 끝나면 엔드포인트별, 프롬프트별, 모드별 원시 데이터와 p50, 평균, 최소, 최대 요약이 JSON으로 남습니다.
Step 4. 실측 결과 — 같은 모델의 지연 비교
이 단계에서는 측정값을 읽습니다. 모든 수치는 2026-09-01 오후(KST)에 서울의 PC에서 도쿄 리전으로 호출한 값이며, 절대값보다 두 엔드포인트의 상대 차이에 주목하시기 바랍니다.
먼저 네트워크 바닥값입니다. 측정에 앞서 curl로 두 호스트의 DNS, TCP 연결, TLS 핸드셰이크 시간을 5회씩 쟀습니다.
| 호스트 | DNS (s) | TCP 연결 (s) | TLS 완료 (s) |
|---|---|---|---|
| bedrock-runtime.ap-northeast-1.amazonaws.com | 0.045 ~ 0.057 | 0.057 ~ 0.082 | 0.32 ~ 0.75 |
| bedrock-mantle.ap-northeast-1.api.aws | 0.044 ~ 0.141 | 0.084 ~ 0.163 | 0.31 ~ 1.57 |
첫 연결의 TLS 비용이 수백 ms로 큰데, 이는 두 엔드포인트 모두 같으므로 벤치마크에서는 워밍업 호출로 제거하고 커넥션을 재사용합니다.
gpt-oss-120b (Chat Completions API, 두 엔드포인트 모두 도쿄 in-region)
측정 구간은 2026-09-01T07:53Z ~ 07:55Z, 모델 ID는 runtime openai.gpt-oss-120b-1:0, mantle openai.gpt-oss-120b, max_tokens=200, reasoning_effort=low, 프롬프트별 모드별 5회입니다. 60회 호출 중 오류와 스로틀은 없었고, medium과 long의 needle 질문은 두 엔드포인트 모두 20회 중 20회 정답이었습니다.
비스트리밍 E2E 지연 (ms, 5회)
| 프롬프트 | 입력 토큰 | runtime p50 | runtime 평균 | runtime 최소~최대 | mantle p50 | mantle 평균 | mantle 최소~최대 | p50 차이 (mantle – runtime) |
|---|---|---|---|---|---|---|---|---|
| short | 98 | 591 | 591 | 471 ~ 668 | 641 | 644 | 604 ~ 707 | +49 (+8%) |
| medium | 8,045 | 1,073 | 1,259 | 650 ~ 2,471 | 851 | 807 | 674 ~ 961 | -222 (-21%) |
| long | 61,715 | 3,905 | 3,858 | 3,564 ~ 3,969 | 2,504 | 2,737 | 1,678 ~ 3,968 | -1,400 (-36%) |
스트리밍 TTFT와 E2E (ms, 5회)
| 프롬프트 | runtime TTFT p50 | runtime E2E p50 | runtime E2E 최소~최대 | mantle TTFT p50 | mantle E2E p50 | mantle E2E 최소~최대 | TTFT p50 차이 (mantle – runtime) |
|---|---|---|---|---|---|---|---|
| short | 992 | 1,049 | 765 ~ 4,309 | 566 | 654 | 539 ~ 880 | -426 (-43%) |
| medium | 905 | 938 | 836 ~ 1,020 | 782 | 783 | 568 ~ 869 | -122 (-14%) |
| long | 2,805 | 2,866 | 1,116 ~ 4,547 | 3,538 | 3,539 | 2,646 ~ 4,103 | +733 (+26%) |
출력 토큰 수와 스트리밍 청크 수 (p50)
| 프롬프트 | runtime 출력 토큰 | mantle 출력 토큰 | runtime 청크 수 | mantle 청크 수 |
|---|---|---|---|---|
| short | 46 | 43 | 2 | 2 |
| medium | 42 | 40 | 3 | 1 |
| long | 72 | 53 | 4 | 1 |
세 표에서 읽을 수 있는 것은 다음과 같습니다.
- 비스트리밍 p50은 short에서 mantle이 49ms 느리고, medium과 long에서는 mantle이 각각 222ms, 1,400ms 빠릅니다. 그런데 스트리밍에서는 long의 방향이 뒤집혀 runtime이 733ms 빠릅니다. 같은 프롬프트에서 모드에 따라 승자가 바뀐다는 것은, 두 엔드포인트의 차이가 회차 간 편차보다 작다는 뜻입니다. runtime long 스트리밍의 최소값 1,116ms와 최대값 4,547ms, mantle long 비스트리밍의 1,678ms와 3,968ms가 그 편차의 크기입니다.
- 가장 반복적으로 관측된 차이는 short 프롬프트의 TTFT입니다. mantle 566ms, runtime 992ms로 mantle이 400ms 남짓 빨랐습니다. 다만 runtime short 스트리밍에는 4,309ms짜리 이상치가 하나 있어 평균이 크게 흔들렸습니다.
- 청크 수가 1~4개입니다. gpt-oss-120b는
reasoning_effort=low에서도 추론을 먼저 끝낸 뒤 40~70 토큰짜리 답을 한두 청크로 한 번에 보내므로, TTFT가 E2E와 거의 같습니다. mantle은 추론 텍스트를 걷어내고 최종 답만 보내기 때문에 청크가 1개인 경우가 대부분입니다. 이 모델에서는 스트리밍을 켜도 사용자가 글자가 흘러나오는 것을 볼 수 없다는 뜻이고, 이는 두 엔드포인트가 같습니다. - long에서 같은 프롬프트를 반복하는 동안 양쪽 모두 간헐적으로 1.1~1.7초대의 빠른 응답이 섞여 나왔습니다. 응답
usage에 캐시 관련 필드가 없어 원인을 단정할 수 없으므로, 긴 프롬프트의 절대값은 참고로만 보시기 바랍니다.
Claude Haiku 4.5 (Anthropic Messages API, runtime은 jp. 지리적 추론 프로파일)
측정 구간은 2026-09-01T07:58Z ~ 08:00Z, 모델 ID는 runtime jp.anthropic.claude-haiku-4-5-20251001-v1:0(도쿄와 오사카 사이 지리적 추론 프로파일), mantle anthropic.claude-haiku-4-5(도쿄 in-region), max_tokens=200, 프롬프트별 모드별 5회입니다. Claude 토크나이저 기준 입력 토큰은 short 37, medium 9,112, long 70,398입니다. 60회 호출 중 오류와 스로틀은 없었고, needle 질문은 두 엔드포인트 모두 20회 중 20회 정답이었습니다.
비스트리밍 E2E 지연 (ms, 5회)
| 프롬프트 | 입력 토큰 | runtime p50 | runtime 평균 | runtime 최소~최대 | mantle p50 | mantle 평균 | mantle 최소~최대 | p50 차이 (mantle – runtime) |
|---|---|---|---|---|---|---|---|---|
| short | 37 | 908 | 926 | 778 ~ 1,119 | 772 | 812 | 763 ~ 914 | -135 (-15%) |
| medium | 9,112 | 1,068 | 1,081 | 943 ~ 1,212 | 1,023 | 989 | 782 ~ 1,098 | -46 (-4%) |
| long | 70,398 | 2,226 | 2,256 | 2,109 ~ 2,509 | 2,289 | 2,538 | 2,008 ~ 3,439 | +63 (+3%) |
스트리밍 TTFT와 E2E (ms, 5회)
| 프롬프트 | runtime TTFT p50 | runtime E2E p50 | runtime E2E 최소~최대 | mantle TTFT p50 | mantle E2E p50 | mantle E2E 최소~최대 | TTFT p50 차이 (mantle – runtime) |
|---|---|---|---|---|---|---|---|
| short | 881 | 938 | 922 ~ 1,546 | 565 | 817 | 648 ~ 828 | -315 (-36%) |
| medium | 829 | 1,159 | 932 ~ 1,416 | 824 | 1,140 | 960 ~ 1,176 | -6 (-1%) |
| long | 1,958 | 2,058 | 1,915 ~ 2,811 | 1,846 | 2,115 | 2,052 ~ 2,349 | -113 (-6%) |
출력 토큰 수, 스트리밍 청크 수, 출력 토큰 속도 (p50)
| 프롬프트 | runtime 출력 토큰 | mantle 출력 토큰 | runtime 청크 수 | mantle 청크 수 | runtime 토큰/초 | mantle 토큰/초 |
|---|---|---|---|---|---|---|
| short | 30 | 30 | 10 | 11 | 151 | 128 |
| medium | 26 | 26 | 11 | 12 | 110 | 119 |
| long | 25 | 26 | 11 | 12 | 113 | 115 |
결과에서 읽을 수 있는 것은 다음과 같습니다.
- medium 이상에서는 두 엔드포인트가 사실상 같은 곡선입니다. 비스트리밍 p50 차이가 -46ms와 +63ms, 스트리밍 TTFT 차이가 -6ms와 -113ms로, 모두 회차 간 편차(수백 ms) 안에 있습니다.
- short에서는 gpt-oss와 같은 경향이 다시 나타났습니다. 스트리밍 TTFT가 mantle 565ms, runtime 881ms로 mantle이 300ms 남짓 빨랐고, 비스트리밍도 135ms 빨랐습니다. 두 모델에서 같은 방향으로 반복된 유일한 차이입니다. 다만 표본이 5회이므로 “짧은 요청은 mantle이 빠르다”고 단정하기보다 “짧은 요청에서 mantle이 느리지는 않다” 정도로 읽는 것이 안전합니다.
- gpt-oss와 달리 청크가 9~16개로 나뉘어 왔고 출력 토큰 속도는 양쪽 모두 110~150 토큰/초로 같은 수준입니다. Claude에서는 스트리밍이 실제로 점진적으로 표시됩니다.
- runtime 쪽은
jp.지리적 추론 프로파일이라 요청이 오사카로 갈 수도 있는 조건이었는데도, 도쿄 in-region인 mantle과의 차이가 100ms 안팎이었습니다. 지리 프로파일의 라우팅 비용이 이 실험에서는 눈에 띄지 않았습니다.
응답 형식 차이
지연 수치와 별개로 응답 형식이 달랐던 점을 정리합니다.
| 항목 | bedrock-runtime | bedrock-mantle |
|---|---|---|
| gpt-oss 추론 과정 노출 | content 안에 <reasoning>...</reasoning> 태그로 포함 | content에 최종 답만 포함 |
gpt-oss 출력 토큰 수 (completion_tokens) | 추론 토큰 포함 | 추론 토큰 포함 (같은 값) |
| gpt-oss 정답률 (needle 찾기) | medium, long 모두 정답 | medium, long 모두 정답 |
| 요청 ID | x-request-id 헤더 | x-request-id 헤더 |
runtime의 <reasoning> 태그는 애플리케이션에서 파싱해 걷어내야 하므로, 사용자에게 보이는 첫 글자 기준 TTFT를 재려면 태그 이후의 텍스트를 기준으로 삼아야 합니다. 이번 측정의 TTFT는 태그를 포함한 첫 청크 기준이므로 runtime 쪽이 조금 유리하게 측정되었을 수 있습니다.
이 단계가 끝나면 “같은 엔진이라는 문서 설명이 실측에서도 성립하는가”에 대한 답을 갖게 됩니다.
Step 5. 긴 프롬프트 테스트 — 6만 토큰에서 무엇이 달라지나
이 단계에서는 long 프롬프트(gpt-oss 기준 61,715 토큰, Claude 기준 70,398 토큰) 결과를 따로 봅니다. 긴 프롬프트는 프리필(입력 토큰 처리) 시간이 지배적이라 엔진 차이가 있다면 가장 크게 드러나는 구간이고, 동시에 쿼터 구조의 차이가 실제로 작동하는 구간입니다.
두 모델의 long 결과만 모아 보면 다음과 같습니다. 입력 토큰은 같은 텍스트를 각 모델의 토크나이저로 센 값입니다.
| 모델 | 입력 토큰 | 모드 | runtime p50 (ms) | mantle p50 (ms) | 차이 (mantle – runtime) | needle 정답 |
|---|---|---|---|---|---|---|
| gpt-oss-120b | 61,715 | 비스트리밍 E2E | 3,905 | 2,504 | -1,400 (-36%) | 10/10, 10/10 |
| gpt-oss-120b | 61,715 | 스트리밍 TTFT | 2,805 | 3,538 | +733 (+26%) | 10/10, 10/10 |
| Claude Haiku 4.5 | 70,398 | 비스트리밍 E2E | 2,226 | 2,289 | +63 (+3%) | 10/10, 10/10 |
| Claude Haiku 4.5 | 70,398 | 스트리밍 TTFT | 1,958 | 1,846 | -113 (-6%) | 10/10, 10/10 |
표에서 주목할 점은 세 가지입니다. 첫째, 6만~7만 토큰을 넣어도 두 엔드포인트 모두 2~4초 안에 첫 글자가 나왔고 정답률은 40회 모두 100%였습니다. 둘째, gpt-oss에서 두 모드의 차이 방향이 서로 반대인데, 이는 엔드포인트 간 차이가 아니라 회차 편차로 읽어야 합니다. 셋째, Claude에서는 in-region(mantle)과 지리적 추론 프로파일(runtime)의 차이가 100ms 안에 들어왔습니다. 긴 프롬프트에서 “어느 엔드포인트가 구조적으로 빠르다”는 신호는 이번 실측에서 나오지 않았습니다.
쿼터 관점에서는, 엔드포인트당 long 프롬프트 10회(gpt-oss 기준 약 62만 입력 토큰, Claude 기준 약 70만 입력 토큰)를 1분 남짓에 보냈는데 429나 503이 한 번도 없었습니다.
긴 프롬프트에서 쿼터가 어떻게 차감되는지는 엔드포인트마다 다릅니다. bedrock-mantle은 요청 시작 시 입력 토큰에 max_tokens를 더한 값을 입력 TPM 쿼터에서 예약하고, 응답이 끝나면 미사용분을 돌려줍니다. bedrock-runtime은 입력과 출력을 합산한 모델별 TPM 쿼터를 씁니다.
이번 사례에서 활용한 Bedrock Mantle 기능 정리
벤치마크 하나를 만들면서 실제로 사용한 기능을 단계별로 정리하면 다음과 같습니다.
| # | 기능 | 이번 사례에서의 활용 |
|---|---|---|
| 1 | Bedrock 장기 API 키 | 한 키로 두 엔드포인트를 모두 호출 |
| 2 | mantle 전용 IAM 액션 | mantle 호출 인가와 모델 목록 조회 |
| 3 | OpenAI 호환 Chat Completions API | gpt-oss-120b를 두 엔드포인트에서 같은 코드로 호출 |
| 4 | Anthropic Messages API | Claude Haiku 4.5를 두 엔드포인트에서 같은 코드로 호출 |
| 5 | Models API | mantle에서 사용 가능한 모델 ID 확인 |
| 6 | 스트리밍 응답 | TTFT와 출력 토큰 속도 측정 |
| 7 | mantle in-region 처리 | 크로스리전 없이 도쿄에서 처리 완결되는 조건으로 비교 |
| 8 | 엔드포인트별 분리 쿼터 | 긴 프롬프트 60회 호출 중 스로틀 없음 확인 |
결론
이번 실측으로 확인한 것은 “같은 엔진”이라는 문서 설명이 도쿄 리전에서 실제 숫자로도 성립하는지였습니다. 두 모델, 세 프롬프트 크기, 두 호출 모드로 총 120회를 호출한 결과, 두 엔드포인트의 p50 차이는 대부분 회차 간 편차 안에 있었고 방향도 일관되지 않았습니다. 6만~7만 토큰의 긴 프롬프트에서도 두 엔드포인트는 같은 속도 구간에 있었고 정답률은 모두 100%였습니다. 가장 반복적으로 보인 차이는 짧은 프롬프트의 TTFT에서 mantle이 300~400ms 빨랐던 것인데, 5회 표본이라 경향 이상으로 단정하기는 어렵습니다. 지금 bedrock-runtime으로 잘 돌아가는 서비스라면 속도 때문에 mantle로 옮길 이유는 이 실측에서 나오지 않았습니다.
따라서 엔드포인트 선택은 속도가 아니라 필요한 기능으로 정하면 됩니다. Guardrails, 지능형 프롬프트 라우팅, 크로스리전 추론, Bedrock 네이티브 API가 필요하면 bedrock-runtime이고, 서버 측 도구, 백그라운드 추론, Projects나 Workspaces 단위의 비용 추적, 또는 mantle에만 올라온 모델이 필요하면 bedrock-mantle입니다. 도입 전에는 두 엔드포인트의 IAM 액션과 쿼터가 완전히 분리되어 있다는 점, 그리고 mantle에는 아직 CloudWatch 지연 지표가 없다는 점을 확인하시기 바랍니다.
- Zero operator access design of Mantle: https://aws.amazon.com/blogs/machine-learning/exploring-the-zero-operator-access-design-of-mantle/
- Responses API (bedrock-mantle 지원 리전): https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-mantle.html
- Chat Completions API on bedrock-mantle: https://docs.aws.amazon.com/bedrock/latest/userguide/inference-chat-completions-mantle.html
- Anthropic Messages API: https://docs.aws.amazon.com/bedrock/latest/userguide/inference-messages-api.html
- Bedrock API keys: https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html
- Quotas for the bedrock-mantle endpoint: https://docs.aws.amazon.com/bedrock/latest/userguide/quotas-mantle.html
- Scaling and throughput best practices: https://docs.aws.amazon.com/bedrock/latest/userguide/scaling-throughput-best-practices.html
- bedrock-mantle CloudWatch metrics: https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-mantle-metrics.html
글 | 메가존클라우드 Commercial Managed Unit 최영훈 매니저
