트러블슈팅¶

배포와 호출 중 확인한 오류를 증상, 원인, 해결 방법 순서로 정리했습니다.

에러 메시지를 알면 검색이 가장 빠릅니다

Ctrl+F(또는 상단 검색창)에 에러 메시지를 그대로 붙여넣으세요. 오른쪽 사이드바에 전체 항목 목록이 있습니다.

증상별 찾기¶

오류 메시지가 없으면 증상에 가까운 항목부터 확인하세요.

언제	어디
배포는 됐는데 호출하면 500	호출 실패
Endpoint가 `Failed`로 끝남	Endpoint 생성 실패
컴포넌트가 안 뜨거나 사본이 부족함	Inference component 실패
0 으로 안 줄거나 0 에서 안 올라옴	Scale to zero
서버리스가 응답하지 않거나 콜드 스타트가 길다	Serverless Inference
`config.pbtxt` 파싱 실패, CUDA error 803	Triton
모델 로드 실패, 첫 호출이 느림	LMI / DJL Serving
architecture 미지원, 요청하지 않은 model이 로드됨	vLLM
양자화 후 예측이 무너짐, 변환 실패	ONNX 변환
배칭했는데 안 빨라짐, p99가 튐	벤치마크
지표를 어디서 보나	모니터링
최적화 도구를 붙였는데 안 됨	Microsoft Olive

배포는 성공했는데 호출하면 500¶

`No module named 'onnxruntime'`¶

ModelError: Received client error (400) from mdeberta with message
"{"code": 400, "type": "InternalServerException",
  "message": "No module named 'onnxruntime'"}"

HF DLC에는 onnxruntime이 들어 있지 않습니다. endpoint 생성과 health check는 통과하고 호출 시점에 실패합니다. 배포 단계에서는 드러나지 않습니다.

해결: model artifact의 code/requirements.txt에 추가합니다.

onnxruntime>=1.28.0

optimum은 넣지 마세요. transformers<4.58을 요구해서 컨테이너의 5.5.3과 충돌하고, 서빙에는 필요하지 않습니다(변환 단계에서만 씁니다).

`Worker died`: 큰 모델만 실패¶

mdeberta: `model_fn` implementation found → Worker died
minilm  : ONNX 로드: model.onnx → Model loaded    ← 작은 모델은 정상

원인은 메모리입니다. SAGEMAKER_MODEL_SERVER_WORKERS를 지정하지 않으면 vCPU 수만큼 워커가 뜨는데, ONNX 세션은 워커마다 모델을 따로 로드합니다. mdeberta ONNX가 1137MB라 ml.c6i.2xlarge(16GB)에 컨테이너 2개 × 워커 8개면 메모리가 부족해집니다.

다음 조건 때문에 memory 문제를 바로 확인하기 어렵습니다.

CloudWatch에 OOM이나 Killed 메시지가 없습니다. model_fn 직후 종료됩니다.
Endpoint는 InService이고 health check도 통과합니다.
첫 호출은 성공할 수도 있고, 이후 Worker died(500)가 납니다.
작은 model process만 남아 일부 model만 응답할 수 있습니다.

해결: worker를 1개로 두고 ORT thread를 사용합니다. model copy가 하나만 load되므로 Memory 사용량을 줄일 수 있습니다.

"SAGEMAKER_MODEL_SERVER_WORKERS": "1",
"ORT_INTRA_OP_THREADS": "0",   # 0 = os.cpu_count()

`Invalid input name: token_type_ids`¶

InvalidArgument: Invalid input name: token_type_ids

Tokenizer는 token_type_ids를 만들지만 이 모델의 ONNX 그래프는 input_ids, attention_mask만 받습니다.

해결: 세션의 실제 입력 이름으로 필터링합니다.

input_names = {i.name for i in session.get_inputs()}
feed = {k: v for k, v in enc.items() if k in input_names}

Endpoint 생성 실패¶

`Instance type ml.g5.xlarge is not supported for a Model using Direct InferenceExecutionMode`¶

멀티컨테이너 Direct mode는 GPU 인스턴스를 지원하지 않습니다. 확인한 AWS 문서 네 페이지 (multi-container-endpoints, -create, -direct, -troubleshooting)에는 이 제약이 명시되어 있지 않았습니다.

인스턴스	결과
ml.g5.xlarge, ml.g5.2xlarge, ml.g4dn.xlarge	거부
ml.c6i.2xlarge	통과

원인은 멀티컨테이너가 아니라 Direct 모드입니다. 같은 GPU image로 Serial 모드를 만들면 g5.xlarge가 통과합니다. 다만 Serial은 inference pipeline이라 컨테이너를 골라 부를 수 없어 co-host 용도가 아닙니다.

해결: CPU를 쓰거나, GPU co-host가 필요하면 LMI(04)를 씁니다.

재현: uv run python 02_cpu_cohost_multicontainer/deploy.py --prove-gpu-fails (endpoint 인스턴스 생성 안 함)

`does not contain required accept-bind-to-port=true Docker label`¶

멀티컨테이너에서는 SageMaker가 컨테이너마다 SAGEMAKER_BIND_TO_PORT를 다르게 주입하고, 컨테이너가 그 포트에 바인딩해야 합니다. 이미지에 라벨이 없으면 endpoint 생성이 거부됩니다.

이미지	accept-bind-to-port	multi-models
`huggingface-pytorch-inference` (cpu/gpu)	✅	✅
`djl-inference` (cpu-full / lmi)	✅	✅
`vllm:0.26.0-...-sagemaker`	❌	❌

해결: vLLM은 단독 endpoint로만 씁니다.

확인 방법:

aws ecr batch-get-image --registry-id 763104351884 --repository-name <repo> \
  --image-ids imageTag=<tag> --region us-east-1 --query 'images[0].imageManifest'
# → config digest → get-download-url-for-layer → Labels 확인

50분 동안 `Creating` 후 `Failed` (FailureReason 없음)¶

Capacity 부족입니다. ml.g5.12xlarge로 시도했을 때 겪었습니다.

진단 단서:

쿼터는 충족(ml.g5.12xlarge for endpoint usage = 1.0, 요청 1대)
FailureReason이 비어 있음
LastModifiedTime이 생성 1초 뒤에 멈춘 채 Creating 유지
ProductionVariants 필드 자체가 응답에 없음 → 인스턴스 배정 전 단계

이 실험에서는 ml.g6.12xlarge가 약 3분 만에 생성됐습니다. 해결: 사용할 Region에서 다른 GPU 인스턴스 유형의 quota와 capacity를 확인하세요.

`did not pass the ping health check`¶

멀티컨테이너에서 인스턴스 메모리가 부족할 때 납니다. AWS 문서: 컨테이너 수에 비례해 MemoryUtilization, CPUUtilization 압박이 커집니다.

해결: 인스턴스를 키우거나 컨테이너 수를 줄입니다. SAGEMAKER_MODEL_SERVER_TIMEOUT과 ContainerStartupHealthCheckTimeoutInSeconds를 늘려 모델 다운로드 시간을 확보하세요.

Inference component 실패¶

`Number of accelerator devices required must be specified for ml.g5.xlarge`¶

GPU 인스턴스에서는 NumberOfAcceleratorDevicesRequired가 필수입니다.

`SageMaker was able to deploy 0 out of 1 requested copies`¶

GPU 장수를 초과했습니다. NumberOfAcceleratorDevicesRequired의 최솟값이 1이므로 (0.5는 ParamValidationError), GPU 장수가 컴포넌트와 사본 총합의 상한입니다.

이 제한은 model memory가 아니라 accelerator requirement 단위에서 발생합니다. 모델 3개 합이 fp16 1.9GB여도 GPU 한 장 인스턴스에는 component copy 하나만 배포됐습니다.

일부 copy만 배포되면 desired=2, current=1 상태로 InService를 유지할 수 있습니다. 현재 copy 수와 FailureReason을 함께 확인하세요.

해결: GPU 장수를 늘리거나(ml.g6.12xlarge = 4장), GPU 1장에 여러 개를 올리려면 LMI(04)를 씁니다.

`There is not enough memory available for this Inference Component`¶

MinMemoryRequiredInMb를 인스턴스 RAM 기준으로 잡으면 실패합니다. ml.g5.xlarge(16GB)에서 6144와 2048은 실패하고 1024로 낮춰야 떴습니다. 컨테이너와 모델 서버 오버헤드가 큽니다.

Scale to zero¶

`MinInstanceCount: 0`을 넣었는데 인스턴스가 안 줄어듭니다¶

endpoint_config 설정만으로는 축소되지 않습니다. Application Auto Scaling에 inference component의 copy 수를 scalable target으로 등록하고 scaling policy를 구성해야 합니다.

aas.register_scalable_target(
    ServiceNamespace="sagemaker",
    ResourceId=f"inference-component/{ic_name}",
    ScalableDimension="sagemaker:inference-component:DesiredCopyCount",
    MinCapacity=0,          # ← 이게 없으면 축소가 시작되지 않습니다
    MaxCapacity=2,
)

05_gpu_scale_to_zero/deploy.py가 세 가지를 모두 설정합니다. 자세한 내용은 05 Scale to zero.

0 으로 내려간 뒤 요청이 계속 실패합니다¶

ValidationError: Inference Component has no capacity to process this request

Copy가 0이면 요청은 대기하지 않고 실패합니다. 이 오류가 NoCapacityInvocationFailures metric을 기록하고 연결된 alarm이 scale-out action을 실행합니다.

복구가 아예 안 되는 경우는 StepScaling 정책과 그 알람이 없는 것입니다.

cw.put_metric_alarm(
    MetricName="NoCapacityInvocationFailures",
    Namespace="AWS/SageMaker",
    Dimensions=[{"Name": "InferenceComponentName", "Value": ic_name}],
    AlarmActions=[step_policy_arn],
    Period=30, EvaluationPeriods=1, Threshold=1,
    ComparisonOperator="GreaterThanOrEqualToThreshold",
    TreatMissingData="missing",
)

이 실험에서는 첫 요청부터 성공까지 471초, 95회 retry가 필요했습니다. client에서 해당 오류를 처리하고 retry하도록 구성하세요.

축소가 너무 오래 걸립니다¶

TargetTracking이 만드는 AlarmLow가 Period=10, EvaluationPeriods=90이라 10초 × 90 = 15분 연속으로 지표가 낮아야 축소가 시작됩니다. 게다가 축소가 두 단계입니다.

단계	실측
트래픽 중단 → IC copy 0	약 13분
copy 0 → 인스턴스 0 (과금 정지)	약 13분

비용은 인스턴스 기준이므로 copy가 0이어도 인스턴스가 회수되기 전까지 비용이 발생합니다. 짧은 유휴 구간에는 scale to zero가 적합하지 않을 수 있습니다.

Serverless Inference¶

`Worker died`가 반복되고 호출이 timeout됩니다¶

[WARN ] W-9000-model com.amazonaws.ml.mms.wlm.BatchAggregator - Load model failed: model, error: Worker died.
[INFO ] W-9000-model com.amazonaws.ml.mms.wlm.WorkerThread - Retry worker: ... in 3 seconds.

클라이언트에는 이렇게 보입니다.

botocore.exceptions.ReadTimeoutError: Read timeout on endpoint URL:
"https://runtime.sagemaker.us-east-1.amazonaws.com/endpoints/.../invocations"

Timeout은 model load 실패의 결과입니다. Worker process가 종료되고 model server가 retry하면서 응답이 반환되지 않습니다. retry 간격은 3초, 5초, 8초, 13초, 21초로 증가했습니다.

원인은 메모리 부족입니다. 실측에서 mdeberta ONNX(1137MB)를 MemorySizeInMB: 2048로 올렸을 때 발생하고, 6144MB(상한)로 올려야 정상 동작했습니다. 컨테이너와 PyTorch, Tokenizer 오버헤드까지 더하면 모델 크기의 몇 배가 필요합니다.

다음 조건 때문에 network timeout으로 오인할 수 있습니다.

Endpoint는 InService이고 생성도 성공합니다
CloudWatch에 OOM 이나 Killed 메시지가 없습니다 (02 의 real-time ONNX와 같은 증상)
클라이언트 에러가 ReadTimeoutError 라서 네트워크 문제로 오인하기 쉽습니다

해결: 메모리를 한 단계씩 올리세요. 받는 값은 1024, 2048, 3072, 4096, 5120, 6144 뿐입니다.

uv run python 06_cpu_serverless/deploy.py --memory 6144

콜드 스타트가 기본 read timeout을 넘습니다¶

서버리스 콜드 스타트가 botocore 기본 read timeout(60초)보다 길 수 있습니다. 실측에서 첫 호출이 12.8초였지만 조건에 따라 더 걸립니다.

from botocore.config import Config
rt = boto3.client("sagemaker-runtime", config=Config(read_timeout=300))

common/client.py의 CloudClient(read_timeout=...)로 조절합니다.

Benchmark p99가 수십 초로 측정됩니다¶

이 실험에서 --warmup 5의 p99는 31,478ms, --warmup 15의 p99는 253ms였습니다. warmup 조건을 결과에 함께 기록하고 충분한 횟수로 다시 측정하세요.

uv run python -m benchmark.run --mode cloud --endpoint <ep> --pad-to-max --warmup 15 -n 60

모니터링¶

CloudWatch 콘솔의 SageMaker AI Insights를 써야 하나요¶

CloudWatch에 SageMaker 전용 큐레이션 대시보드가 있습니다(콘솔 라우트가 #sagemaker-insights:endpoints, 공식 명칭은 CloudWatch SageMaker AI Insights). Performance, Capacity, Reliability 3개 탭으로 endpoint와 inference component를 봅니다.

기본 실습은 이 dashboard 없이 CloudWatch metric과 API polling으로 진행합니다.

항목	내용
활성화	`MetricsConfig.EnableDetailedObservability` (`EnableEnhancedMetrics` 아님)
추가 셋업	계정 수준 OTel enrichment 옵트인 필요
비용	콘솔 조회는 무과금이지만 OTel 지표 인제스션에 과금 (현재 기준 GB 당 $0.50)
토큰 지표	TTFT, TPS, KV cache는 vLLM과 SGLang 전용

Token metric은 인코더 model에 적용되지 않습니다 (인코더는 왜 다른가). 인코더에서 쓸 수 있는 것은 ModelLatency, Invocations, GPU/CPU 사용률 정도이고, 그건 기본 CloudWatch 지표로 충분합니다.

Scale to zero 구간은 describe_endpoint와 describe_inference_component polling으로 측정합니다. copy count와 instance count를 함께 보여 주는 전용 view는 확인한 문서에 없으며, AZ별 placement derived metric은 PromQL에서 개별 query가 제한됩니다 (05_gpu_scale_to_zero/measure_cold_start.py).

정보 기준 시점

2026-06-18 발표, 서울을 포함한 17개 리전. 플래그 이름과 단가는 바뀔 수 있으니 AWS 문서를 재확인하세요.

LMI / DJL Serving¶

`ModuleNotFoundError: No module named 'transformers'` (또는 `peft`)¶

djl-inference:0.35.0-cpu-full은 Java 엔진 위주라 Python 패키지가 없습니다.

해결: model artifact에 requirements.txt를 넣습니다.

transformers
torch
sentencepiece
protobuf
peft
accelerate

LMI(GPU) 이미지는 이미 포함하고 있어 불필요합니다.

첫 호출에 model load 시간이 포함됨¶

LMI는 요청 시점에 model을 load합니다. benchmark 전에 충분한 --warmup을 적용하고 첫 호출과 Warm latency를 구분해 기록하세요.

Triton Inference Server¶

`Expected ",", found "{"`로 서버가 기동하지 않습니다¶

Error parsing text-format inference.ModelConfig: 11:3: Expected ",", found "{".
error: creating server: Internal - failed to load all models

config.pbtxt는 JSON이 아니라 protobuf text format 입니다. 배열 원소를 쉼표로 구분해야 하는데, 개행만 넣으면 파싱이 실패합니다.

해결:

input [
  { name: "input_ids"      ... },     ← 쉼표 필요
  { name: "attention_mask" ... }      ← 마지막 원소는 없어야 합니다
]

스크립트로 생성한다면 "\n".join(...)이 아니라 ",\n".join(...) 입니다.

`unsupported display driver / cuda driver combination` (error 803)¶

System has unsupported display driver / cuda driver combination (error 803)

기본 추론 AMI의 NVIDIA 드라이버가 컨테이너 이미지의 CUDA 요구 버전보다 낮습니다. 최신 Triton 이미지(26.05-py3 등)에서 발생합니다.

해결: ProductionVariant.InferenceAmiVersion을 올립니다.

"InferenceAmiVersion": "al2023-ami-sagemaker-inference-gpu-4-1",   # 드라이버 580, CUDA 13.0

성공하면 컨테이너 로그에 forward compatibility가 켜진 것이 보입니다.

NOTE: CUDA Forward Compatibility mode ENABLED.
  Using CUDA 13.2 driver version 595.58.03 with kernel driver version 580.173.02.

버전 목록은 inference AMI 문서에 있습니다.

AMI를 올려도 CUDA minor는 여전히 낮습니다

al2023-ami-sagemaker-inference-gpu-4-1이 CUDA 13.0 인데 Triton 26.05 는 CUDA 13.2.1 기반입니다. AMI 쪽이 여전히 낮은데 동작하는 이유는 forward compatibility 입니다. 그래서 성공 로그에 CUDA Forward Compatibility mode ENABLED가 찍힙니다.

즉 이 조합은 "버전을 맞춘 것"이 아니라 "호환 모드로 넘긴 것"입니다. Triton 태그를 더 올릴 때 같은 방식이 계속 통한다는 보장은 없으니, 태그를 바꾸면 배포를 다시 확인하세요.

첫 호출이 배치 크기마다 다시 느려집니다¶

TensorRT는 batch shape 별로 엔진을 컴파일합니다. b=1 로 warmup을 마쳤어도 b=8 첫 호출에서 다시 컴파일이 돕니다.

호출	실측 (ml.g5.xlarge, mDeBERTa)
첫 단건 호출 (b=1)	47.7초
이후 단건	15~17 ms
첫 배치 호출 (b=8)	60초 초과로 `ModelError`
이후 배치	40~45 ms

b=8 첫 호출은 SageMaker 컨테이너 응답 제한을 넘겨 실패했습니다. 컨테이너 로그를 보면 컴파일 자체는 성공했고 그 뒤 호출은 정상입니다.

해결: 서비스 투입 전에 예상 batch shape을 모두 warmup 하세요. 또는 trtexec로 사전 compile한 .plan을 tensorrt backend로 배포합니다. .plan은 GPU architecture에 종속되므로 A10G에서 만든 file은 T4에서 실행할 수 없습니다.

trt_engine_cache_enable을 켜도 캐시 경로가 /tmp이면 컨테이너 재시작 후 사라집니다. 05 scale to zero와 함께 사용하면 복구할 때 engine을 다시 compile해야 합니다.

`failed to load all models` 인데 config는 정상입니다¶

Model artifact 안에 model.onnx가 없거나 잘렸을 가능성이 큽니다. 1GB 대 파일을 내려받다 중단되면 빈 버전 디렉터리가 남고, 그걸 그대로 tar로 묶어 올리면 이 에러가 납니다.

해결: 업로드 전에 크기를 확인합니다. build_ensemble.py는 이 검사를 내장했습니다.

onnx = list(repo_dir.rglob("model.onnx"))
if not onnx or onnx[0].stat().st_size < 1_000_000:
    raise SystemExit("model.onnx missing or truncated. rerun the build.")

`Invalid argument: unable to find backend library`¶

config.pbtxt의 backend 값과 파일 이름이 맞아야 합니다. onnxruntime 백엔드는 model.onnx, python은 model.py, tensorrt는 model.plan 입니다. 이름이 다르면 백엔드가 Artifact를 찾지 못합니다.

Model artifact 압축이 오래 걸립니다¶

ONNX는 압축률이 낮은 fp32 binary입니다. 200MB sample에서 gzip level 1과 9를 비교한 결과는 다음과 같습니다.

`compresslevel`	소요	결과 크기
1	4.5초	124 MB
9	63.2초	115 MB

Level 9는 level 1보다 14배 오래 걸렸고 결과 file은 5%p 작았습니다. 이 repository는 compress level 1을 사용합니다. SageMaker는 uncompressed tar archive도 지원합니다.

vLLM¶

`Model architectures ['DebertaV2ForSequenceClassification'] are not supported`¶

vLLM은 지원하지 않는 아키텍처를 받아들이지 않고 종료합니다. DeBERTa 계열은 레지스트리에 없고, Transformers backend 폴백 조건(_supports_attention_backend, ALL_ATTENTION_FUNCTIONS)도 modeling_deberta_v2.py가 충족하지 않습니다.

해결: HF DLC를 쓰거나, GPU에서 여러 모델을 co-host하려면 LMI를 씁니다(LMI는 거부하지 않고 HuggingFace Accelerate로 폴백합니다).

배포 전 확인: uv run python 08_engine_comparison/check_vllm_support.py

요청하지 않은 model이 서빙됨 (Qwen3-0.6B)¶

vLLM DLC는 CLI 인자를 받지 않습니다. sagemaker_entrypoint.sh가 SM_VLLM_FOO=bar를 --foo bar로 변환합니다. CLI의 --model argument는 entrypoint에서 사용되지 않아 기본 Model이 시작됩니다. Health check는 통과할 수 있으므로 log의 Resolved architecture와 /v1/models 응답을 확인하세요.

해결:

-e SM_VLLM_MODEL="$HF_MODEL_ID"
-e SM_VLLM_RUNNER=pooling
-e SM_VLLM_CONVERT=classify
-e SM_VLLM_MAX_MODEL_LEN=512

실행한 뒤 /v1/models로 실제 서빙 중인 모델을 확인하세요. 이 repository의 serve_local_vllm.sh는 요청한 모델과 다르면 실패로 처리합니다.

`/score` 엔드포인트가 404¶

vLLM에는 text_pair 개념이 없고 /score도 없습니다. /classify에 </s></s>로 이어 붙여 보냅니다. HF pipeline의 pair 처리와 결과가 일치하는지 확인했습니다(소수점 4자리까지).

이 separator는 XLM-RoBERTa 계열 기준입니다. BERT 계열은 [SEP]를 사용합니다.

ONNX 변환¶

`optimum[onnxruntime]` 설치가 의존성 충돌¶

optimum-onnx가 transformers>=4.36,<4.58을 요구해서 이 repository의 transformers 5.14.1과 충돌합니다.

해결: 변환과 서빙을 분리합니다.

단계	필요한 패키지	transformers 5.x
변환	`optimum[onnxruntime]`	❌ 별도 venv (1회성)
서빙	`onnxruntime`만	✅ 제약 없음

scripts/export_onnx.py가 별도 venv를 자동으로 만듭니다.

torch.onnx.export는 transformers 5.x 환경에서 실행할 수 있지만 이 실험에서는 optimum-onnx 경로보다 latency가 높았습니다(160ms와 52ms).

INT8 양자화 후 모든 예측이 `neutral`¶

이 mDeBERTa model은 dynamic INT8 quantization 후 검증 sample의 prediction이 모두 neutral로 바뀌었습니다. 원인으로 disentangled attention을 추정했지만 별도로 확인하지는 않았습니다.

해결: fp32를 씁니다. CPU에서는 fp16도 안 됩니다(DeBERTa ONNX 그래프에 Cast(to=FLOAT) 노드가 128개 있어 변환이 실패하고, ORT CPU EP는 fp16을 네이티브 실행하지 않습니다).

양자화 모델을 로드했는데 크기와 속도가 그대로¶

Could not find any ONNX files with standard file name model.onnx,
files found: [PosixPath('model_quantized.onnx')]

ORTModelForSequenceClassification.from_pretrained()가 기본 file name을 찾지 못하면 fp32 model을 load할 수 있습니다. Model size와 latency가 바뀌지 않았다면 실제 load한 file을 확인하세요.

해결: file_name="model_quantized.onnx"를 명시합니다.

벤치마크¶

Batching 후에도 throughput이 증가하지 않음¶

inputs에 리스트를 넣기만 하면 배칭되지 않습니다. transformers pipeline이 batch_size 미지정 시 한 건씩 순차 처리합니다.

batch 32, mdeberta, L40S	latency
`parameters` 없음	510 ms
`parameters.batch_size=32`	25 ms

해결: payload에 실어 보냅니다. common/payload.py의 build_batch_payload가 자동으로 넣어줍니다.

{"inputs": [...], "parameters": {"batch_size": 32}}

목표 workload보다 latency가 낮게 측정됨¶

Sequence length 조건을 확인하세요. 목표 workload가 512 고정인데 59-token sample로 측정하면 다음과 같은 차이가 발생했습니다.

조건	b=1 p50	b=8 p50	b=8 samples/s
실제 문장 길이	23.2 ms	23.9 ms	330/s
max_len=512 고정	25.8 ms	102.8 ms	78/s

batch=1에서는 1.1배, batch=8에서는 4.3배 차이가 났습니다. padding token도 연산에 포함되므로 목표 sequence length로 batch policy를 측정하세요.

해결: --pad-to-max를 줍니다(compare_cohost.py는 기본 활성).

p99가 비정상적으로 높음¶

Warmup이 부족합니다. 워커가 순차적으로 모델을 로드하는 동안 첫 요청들이 대기합니다. workers=4에서 warmup 3으로 재면 p99가 1611ms로 나오는데, warmup 20으로 늘리면 20.4ms입니다.

해결: 모든 worker가 model을 load한 뒤 측정을 시작하도록 warmup 횟수를 늘립니다. 이 실험의 workers=4 구성은 warmup 20회를 사용했습니다.

Microsoft Olive 적용 결과¶

OrtTransformersOptimization을 model_type: "bert", opt_level: 1로 실행:

19분 실행 후 중단. 결과 file이 생성되지 않았고 진행 log도 없었습니다(cache 36KB).
CPU 99.8%를 계속 쓰고 메모리는 최대 27GB까지 올라갔습니다.
추정 원인: BERT용 fusion 규칙이 DeBERTa의 disentangled attention과 매칭되지 않아 1.1GB 그래프(Cast 노드 128개)를 반복 스캔한 것으로 보입니다. 확증하지는 못했습니다.

optimum 변환은 23초에 끝나고 그것만으로 PyTorch 대비 6.6배를 얻습니다. Olive는 생성 LLM(Llama, Phi, Qwen, Gemma) 자동 최적화에 초점이 있어 인코더 분류 모델에는 검증이 더 필요합니다.