AI 응답성 최적화하기: Amazon Bedrock 지연 시간 최적화 추론에 대한 실용적인 가이드

이 글은 AWS Machine Learning 블로그의 Optimizing AI responsiveness: A practical guide to Amazon Bedrock latency-optimized inference by Ishan Singh, Ankur Desai, Rupinder Grewal, Vivek Singh, and Yanyan Zhang의 한국어 번역입니다.

상용 생성형AI 애플리케이션에서 반응성은 모델의 성능(정확도)만큼이나 중요합니다. 시간에 민감한 문의 사항을 처리하는 고객 서비스 팀이든, 즉각적인 코드 제안이 필요한 개발자이든, 지연 시간(대기 시간)으로 알려진 1초의 지연도 상당한 영향을 미칠 수 있습니다. 기업들이 이러한 중요한 작업과 프로세스에 대규모 언어 모델(LLM)을 점점 더 많이 사용함에 따라, 기업들은 근본적인 문제에 직면하게 되었습니다. 바로 사용자가 기대하는 빠르고 반응성이 뛰어난 성능을 유지하면서 정교한 모델이 약속하는 고품질의 결과물을 제공하는 방법입니다.

지연이 사용자 경험에 미치는 영향은 단순한 불편함을 넘어서는 것입니다. 대화형 AI 애플리케이션에서 응답 지연은 자연스러운 대화 흐름을 방해하고 사용자 참여를 저해하며 궁극적으로 AI 기반 솔루션의 채택에 영향을 미칠 수 있습니다. 이 문제는 단일 문제를 해결하기 위해 여러 LLM 호출이 필요한 경우가 많은 현대의 LLM 애플리케이션의 복잡성이 증가함에 따라 더욱 악화되고 있으며, 이로 인해 총 처리 시간이 크게 늘어납니다.

2024년 re:Invent 행사 기간 동안, 저희는 Amazon Bedrock의 파운데이션 모델(FM)을 위한 지연 시간 최적화 추론을 출시했습니다. 이 새로운 추론 기능은 Anthropic의 Claude 3.5 Haiku 모델과 Meta의 Llama 3.1 405B 및 70B 모델에 대해 각각 표준 모델 버전보다 지연 시간을 줄여줍니다. 이 기능은 신속한 대응이 비즈니스에 중요한 시간 민감 작업들에 특히 유용합니다.

이 게시글에서는 Amazon Bedrock의 지연 시간 최적화 추론이 LLM 애플리케이션의 응답성을 유지하는 데 어떤 도움을 줄 수 있는지 살펴봅니다. 애플리케이션 성능을 최적화하고 사용자 경험을 개선하기 위한 전략을 자세히 살펴보겠습니다. 새로운 AI 애플리케이션을 구축하든 기존 애플리케이션을 최적화하든, 지연 시간 최적화의 기술적 측면과 실제 구현 방식에 대한 실질적인 지침을 찾을 수 있습니다. LLM 애플리케이션의 지연 시간에 대해 설명하는 것으로 시작하겠습니다.

LLM 애플리케이션에서 지연 시간 이해하기

LLM 애플리케이션의 지연 시간은 단순한 응답 시간을 넘어서는 다각적인 개념입니다. LLM과 상호 작용할 때 스트리밍 또는 비스트리밍 모드 중 하나로 응답을 받을 수 있습니다. 비스트리밍 모드에서는 누군가가 편지를 다 쓰기를 기다리는 것처럼, 어떤 출력을 받기 전에 완전한 응답을 기다립니다. 스트리밍 모드에서는 누군가가 실시간으로 입력하는 것을 보는 것처럼, 응답이 생성되는 대로 응답을 받습니다.

응답성을 위해 AI 애플리케이션을 효과적으로 최적화하려면, 지연 시간을 정의하는 핵심 지표와 이것이 사용자 경험에 미치는 영향을 이해해야 합니다. 이러한 지표는 스트리밍 모드와 비스트리밍 모드에서 다르며, 반응성이 뛰어난 AI 애플리케이션을 구축하려면 이러한 지표를 이해하는 것이 중요합니다.

첫 번째 토큰까지의 시간(Time to first token, TTFT)은 스트리밍 애플리케이션이 얼마나 빠르게 응답을 시작하는지를 나타냅니다. 이는 사용자가 요청을 제출한 후 응답(첫 번째 단어, 토큰 또는 청크)을 받기 시작할 때까지 걸리는 시간입니다. AI 애플리케이션의 초기 반응 시간이라고 생각하면 됩니다.

TTFT는 여러 가지 요인에 의해 영향을 받습니다.

• 입력 프롬프트의 길이(프롬프트가 길수록 TTFT가 더 커짐)
• 네트워크 상태와 지리적 위치(프롬프트가 다른 지역에서 처리되는 경우, 더 오래 걸림)

계산식 : TTFT = 첫번째 청크/토큰이 도달한 시각 – 요청이 제출 된 시각
결론 : 낮을수록 좋습니다

초당 출력 토큰(Output tokens per second, OTPS)은 모델이 응답을 시작한 후 새로운 토큰을 얼마나 빨리 생성하는지를 나타냅니다. 이 지표는 모델의 실제 처리량과 더 긴 문장을 생성하는 동안 응답 속도가 어떻게 유지되는지를 이해하는 데 매우 중요합니다.

OTPS는 다음의 영향을 받습니다.

• 모델 크기 및 복잡성
• 생성된 응답의 길이
• 작업 및 프롬프트의 복잡성
• 시스템 부하 및 리소스 가용성

계산식 : OTPS = 출력 토큰의 총 개수 / 총 생성 시간
결론 : 높을수록 좋습니다

종단간 지연 시간(End-to-end latency , E2E)은 요청에서 응답 완료까지의 총 시간을 측정합니다. 아래의 그림에 나와 있듯이, 이 시간은 전체 상호 작용을 포함합니다.

이 지표에 영향을 미치는 주요 요소는 다음과 같습니다.

• 입력 프롬프트 길이
• 요청된 출력 길이
• 모델 처리 속도
• 네트워크 상태
• 작업과 프롬프트의 복잡성
• 후처리 요구 사항(예: Amazon Bedrock Guardrails 또는 기타 정확도를 확인하는 도구)

계산식 : E2E 지연 시간 = 요청 완료 시각 – 요청 제출 시각
결론 : 낮을수록 좋습니다.

이 측정 기준은 지연 시간 이해를 위한 견고한 기반을 제공하지만, LLM 애플리케이션의 성능에 영향을 미칠 수 있는 추가적인 요소와 고려 사항이 있습니다. 이러한 측정 기준은 다음 다이어그램에 나와 있습니다.

토큰화의 역할

종종 간과되는 지연 시간의 원인으로 서로 다른 모델이 텍스트를 토큰화하는 방식에 따른 지연시간이 있습니다. 각 모델의 토큰화 전략은 훈련 과정에서 제공자에 의해 정의되며 수정할 수 없습니다. 예를 들어, 한 모델에서 100개의 토큰을 생성하는 프롬프트가 다른 모델에서는 150개의 토큰을 생성할 수 있습니다. 모델의 성능을 비교할 때, 이러한 고유한 토큰화 차이로 인해 모델의 효율성이 동일하더라도 인지된 응답 시간에 영향을 미칠 수 있다는 점을 기억하십시오. 이러한 차이를 인식하면 모델 간의 지연 시간 차이를 더 잘 해석하고 애플리케이션에 사용할 모델을 선택할 때 더 많은 정보를 바탕으로 결정을 내리는 데 도움이 될 수 있습니다.

사용자 경험 이해하기

생성형 AI 애플리케이션은 AI의 응답 지연시간에 따라 사용자 기대와 만족도에 흥미로운 패턴을 보입니다. 사용자는 요청의 맥락과 복잡성에 따라 응답 시간을 다르게 인식하는 경향이 있습니다. 복잡한 분석을 생성하는 데 약간의 지연이 발생해도 수용할 수 있지만, 대화를 나누는 상황에서 약간의 지연이 발생해도 방해가 될 수 있습니다. 이러한 이해는 다양한 유형의 애플리케이션에 적합한 최적화 우선순위를 설정하는 데 도움이 됩니다.

속도보다 일관성

대부분의 사람이 분당 225단어 이상을 읽을 수 없기 때문에 매우 빠른 응답은 사용자 경험을 저해할 수 있다는 점을 고려하여 사용자 경험을 벤치마킹을 통해 사용 사례에 가장 적합한 지연 시간을 찾아보세요.

사용자 참여 유지

처리 시간이 길어질 때, 특히 초기 응답 시간 동안 “요청 처리 중” 또는 “로딩 중”과 같은 간단한 메시지가 사용자의 참여를 유지하는 데 도움이 됩니다. 이러한 시나리오에서는 TTFT를 최적화해야 합니다.

속도, 정확도, 비용의 균형

출력 정확도는 종종 속도보다 더 중요합니다. 사용자는 빠르지만 신뢰성이 떨어지는 응답보다 정확한 응답을 선호합니다. 대부분의 사람이 분당 225단어 이상을 읽을 수 없기 때문에 매우 빠른 응답은 사용자 경험을 저해할 수 있다는 점을 고려하여 사용자 경험 벤치마킹을 통해 사용 사례에 가장 적합한 지연 시간을 찾아보세요.

이러한 맥락을 이해하면 더 나은 사용자 경험을 위해 생성형 AI 애플리케이션을 최적화하기 위한 정보에 기반한 결정을 내릴 수 있습니다.

지연 시간 최적화 추론 : 심층 분석

Amazon Bedrock 지연 시간 최적화 추론 기능은 더 높은 OTPS와 더 빠른 TTFT를 제공하도록 설계되어, 애플리케이션이 워크로드를 보다 안정적으로 처리할 수 있도록 합니다. 이 최적화는 Anthropic의 Claude 3.5 Haiku와 Meta의 Llama 3.1 모델(405B와 70B 버전 모두)을 포함한 일부 FM에 대해 us-east-2(오하이오) AWS 리전에서 사용할 수 있습니다. 이 최적화는 다음 모델을 지원합니다.

• 더 높은 OTPS – 모델이 응답을 시작한 후 더 빠른 토큰 생성
• 더 빠른 TTFT – 더 빠른 초기 응답 시간

구현

지연 시간 최적화를 활성화하려면 API 호출에서 latency 매개변수를 optimized로 설정해야 합니다.

# Using converse api without streaming
response = bedrock_runtime.converse(
    modelId='us.anthropic.claude-3-5-haiku-20241022-v1:0',
    messages=[{
            'role': 'user',
            'content': [{
                'text':'Write a story about music generating AI models'
                }]
              }],
    performanceConfig={'latency': 'optimized'}
)

For streaming responses:

# using converse API with streaming
response = bedrock_runtime.converse_stream(
       modelId='us.anthropic.claude-3-5-haiku-20241022-v1:0',
       messages=[{
            'role': 'user',
            'content': [{
                'text':'Write a story about music generating AI models'
                }]
              }],
        performanceConfig={'latency': 'optimized'}
    )

벤치마킹 방법론과 결과

TTFT와 OTPS의 성능 향상을 이해하기 위해, 하루 중 다양한 시간대와 여러 날에 걸쳐 약 1,600건의 API 호출을 통해 오프라인 실험을 실시했습니다. 시퀀스 카운팅, 스토리 작성, 요약, 번역 등 다양한 작업 유형으로 구성된 더미 데이터 세트를 사용했습니다. 입력 프롬프트는 100개에서 100,000개 토큰까지, 출력 토큰은 100개에서 1,000개 출력 토큰까지 다양했습니다. 이 작업들은 다양한 복잡성 수준과 다양한 모델 출력 길이를 나타내기 위해 선택되었습니다. 테스트 설정은 미국 서부(오리건) us-west-2 리전에서 호스팅되었고, 최적화된 모델과 표준 모델은 미국 동부(오하이오) us-east-2 리전에서 호스팅되었습니다. 이 교차 리전 설정은 현실적인 네트워크 가변성을 도입하여 실제 애플리케이션과 유사한 조건에서 성능을 측정할 수 있도록 도와줍니다.

결과를 분석할 때, 우리는 앞서 논의한 주요 지연 시간 지표인 TTFT와 OTPS에 초점을 맞췄습니다. 간단히 요약하자면, TTFT 값이 낮을수록 초기 응답 시간이 빠르다는 것을 의미하고, OTPS 값이 높을수록 토큰 생성 속도가 빠르다는 것을 의미합니다. 또한, 50번째 백분위수(P50)와 90번째 백분위수(P90) 값을 살펴봄으로써 일반적인 성과와 도전적인 상황이나 상한선 조건에서의 성과 경계선을 파악했습니다. 중심 극한 정리(central limit theorem)에 따라, 충분한 표본을 사용하면, 우리의 결과가 일관된 값으로 수렴되어 신뢰할 수 있는 성과 지표를 제공한다는 것을 관찰했습니다.

이 결과는 특정 테스트 환경과 데이터 세트에서 얻은 결과라는 점을 유의해야 합니다. 실제 결과는 특정 사용 사례, 프롬프트 길이, 예상 모델 응답 길이, 네트워크 상태, 클라이언트 위치, 기타 구현 구성 요소에 따라 달라질 수 있습니다. 자체 벤치마크를 수행할 때는 테스트 데이터 세트가 일반적인 입력 길이 및 예상 출력 패턴을 포함하여 실제 생산 작업 부하 특성을 나타내는지 확인하십시오.

벤치마킹 결과

지연 시간 최적화 모델을 사용한 실험 결과, TTFT 및 OTPS 지표에서 상당한 성능 향상이 나타났습니다. 다음 표의 결과는 Anthropic의 Claude 3.5 Haiku와 Meta의 Llama 3.1 70B 모델의 표준 버전과 최적화 버전을 비교한 것입니다. 각 모델에 대해 신뢰할 수 있는 신뢰할수 있는 성능을 위해 테스트 시나리오를 여러 번 반복했습니다. 특히, 높은 백분위수 측정에서 개선이 두드러졌는데, 이는 까다로운 조건에서도 더 일관된 성능을 보였음을 시사합니다.

이 결과는 두 모델의 모든 지표에서 상당한 개선을 보여줍니다. Anthropic의 Claude 3.5 Haiku 모델의 경우, 최적화된 버전은 TTFT P50에서 최대 42.20%, TTFT P90에서 최대 51.70%의 감소율을 달성하여 보다 일관된 초기 응답 시간을 나타냅니다. 또한, OTPS는 P50 수준에서 최대 77.34%, P90 수준에서 최대 125.50% 개선되어 토큰 생성이 더 빨라졌습니다.

Meta Llama 3.1 70B 모델의 이득은 더욱 인상적입니다. 최적화된 버전은 TTFT P50에서 최대 51.65%, TTFT P90에서 최대 97.10%까지 감소하여 일관되게 빠른 초기 응답을 제공합니다. 또한, OTPS는 P50 수준에서 최대 353.84%, P90 수준에서 최대 529.33%의 개선을 보이며 일부 시나리오에서 토큰 생성을 최대 5배 더 빠르게 할 수 있게 되었습니다.

이러한 벤치마크 결과는 지연 시간 최적화 추론의 강력한 영향을 보여 주지만, 최적화 퍼즐의 한 조각에 불과합니다. 이러한 성능 향상을 최대한 활용하고 특정 사용 사례에 대해 가능한 최고의 응답 시간을 달성하려면, 단순히 기능을 활성화하는 것 이상의 추가적인 최적화 전략을 고려해야 합니다.

LLM 지연 시간 최적화를 위한 종합 가이드

Amazon Bedrock 지연 시간 최적화 추론이 처음부터 큰 개선을 제공하더라도, 최고의 성능을 얻으려면 애플리케이션을 설계하고 구현하는 데 있어 다방면에 걸친 접근 방식이 필요합니다. 다음 섹션에서는 애플리케이션의 응답성을 최대한 높이기 위한 몇 가지 다른 전략과 고려 사항을 살펴봅니다.

지연 시간 최적화를 위한 신속한 엔지니어링

지연 시간 단축을 위해 LLM 애플리케이션을 최적화할 때, 프롬프트를 만드는 방식은 입력 처리와 출력 생성에 모두 영향을 미칩니다.

입력 프롬프트를 최적화하려면 다음 권장 사항을 따르십시오.

• 간결한 프롬프트 유지 – 입력 프롬프트가 길면 처리하는 데 시간이 더 걸리고 TTFT가 늘어납니다. 필요한 컨텍스트와 정보를 우선시하는 짧고 집중적인 프롬프트를 만드세요.
• 복잡한 작업 나누기 – 하나의 요청으로 큰 작업을 처리하는 대신, 관리하기 쉬운 작은 단위로 나누세요. 이 접근 방식은 작업의 복잡성에 관계없이 반응성을 유지하는 데 도움이 됩니다.
• 스마트한 컨텍스트 관리 – 챗봇과 같은 대화형 애플리케이션의 경우, 전체 대화 기록 대신 관련 컨텍스트만 포함하세요.
• 토큰 관리 – 서로 다른 모델은 텍스트를 다르게 토큰화합니다. 즉, 동일한 입력으로 다른 수의 토큰이 생성될 수 있습니다. 토큰 사용량을 모니터링하고 최적화하여 일관된 성능을 유지하십시오. 토큰 예산을 사용하여 컨텍스트 보존과 성능 요구 사항 간의 균형을 유지하십시오.

간결한 결과물을 얻기 위해 엔지니어링을 하려면 다음 권장 사항을 따르십시오.

• 간결함을 위한 엔지니어링 – 프롬프트에 명시적인 길이 제한을 포함합니다(예: “50단어 이하로 응답하세요”).
• 시스템 메시지 사용 – 시스템 메시지를 통해 응답 길이 제한을 설정합니다.
• 품질과 길이의 균형 – 응답 제한이 결과물의 품질을 떨어뜨리지 않도록 합니다.

AI 애플리케이션을 더 빠르게 느끼게 하는 가장 좋은 방법 중 하나는 스트리밍을 사용하는 것입니다. 스트리밍은 응답이 완전히 생성될 때까지 기다리는 대신, 누군가가 실시간으로 입력하는 것을 보는 것처럼 응답이 생성되는 즉시 표시합니다. 응답 스트리밍은 사용자 참여를 유지하면서 LLM 애플리케이션의 인지 성능을 향상시키는 가장 효과적인 방법 중 하나입니다.

이러한 기술은 토큰 사용량과 생성 시간을 크게 줄여 지연 시간과 비용 효율성을 모두 개선할 수 있습니다.

실 서비스용 AI 애플리케이션 구축하기

개별 최적화는 중요하지만, 생성형 애플리케이션에는 지연 시간 관리에 대한 전체론적 접근 방식이 필요합니다. 이 섹션에서는 다양한 시스템 구성 요소와 아키텍처 결정이 전체 애플리케이션 반응성에 어떤 영향을 미치는지 살펴봅니다.

시스템 아키텍처와 종단간 지연 시간 고려 사항

상용 환경에서 전체 시스템 지연 시간은 모델 추론 시간을 훨씬 초과합니다. AI 애플리케이션 스택의 각 구성 요소는 사용자가 경험하는 전체 지연 시간에 기여합니다. 예를 들어, Amazon Bedrock Guardrails를 통해 책임 있는 AI 관행을 구현할 때, 작은 추가 지연 시간 오버헤드를 발견할 수 있습니다. 콘텐츠 필터링, 사용자 인증 또는 입력 검증 레이어를 통합할 때도 유사한 고려 사항이 적용됩니다. 각 구성 요소는 중요한 목적을 수행하지만, 시스템 설계 시 지연 시간에 대한 누적 영향을 신중하게 고려해야 합니다.

지리적인 위치는 애플리케이션 성능에 중요한 역할을 합니다. 모델 호출 지연 시간은 호출이 다른 리전, 로컬 머신 또는 다른 클라우드 제공업체에서 시작되는지에 따라 상당히 달라질 수 있습니다. 이러한 차이는 네트워크를 통한 데이터 이동 시간과 지리적 거리에서 비롯됩니다. 애플리케이션 아키텍처를 설계할 때, 애플리케이션과 모델 엔드포인트 사이의 물리적 거리, 리전 간 데이터 전송 시간, 다른 리전의 네트워크 안정성 등의 요소를 고려해야 합니다. 데이터 상주 요건도 이러한 아키텍처 선택에 영향을 미칠 수 있으며, 특정 리전 배포가 필요할 수 있습니다.

통합 패턴은 사용자가 애플리케이션 성능을 인식하는 방식에 큰 영향을 미칩니다. 동기식 처리는 구현하기는 더 간단하지만, 항상 최상의 사용자 경험을 제공하지는 않습니다. 사용자 행동 패턴에 따라 예상 응답을 미리 가져오거나 중요하지 않은 구성 요소는 백그라운드에서 처리하는 등 적절한 경우 비동기식 패턴을 구현하는 것을 고려해 보십시오. 요청 일괄 처리를 통해 대량 작업을 처리하면 전체 시스템 처리량을 최적화하는 데 도움이 될 수 있지만, 응답 시간 요구 사항과 신중하게 균형을 맞춰야 합니다.

애플리케이션이 확장됨에 따라 추가적인 인프라 구성 요소가 필요해지지만, 이로 인해 지연 시간이 영향을 받을 수 있습니다. 로드 밸런서, 큐 시스템, 캐시 레이어, 모니터링 시스템은 모두 전체 지연 시간 예산에 기여합니다. 이러한 구성 요소의 영향을 이해하면 인프라 설계 및 최적화 전략에 대한 정보에 근거한 결정을 내리는 데 도움이 됩니다.

복잡한 작업은 종종 여러 모델 호출을 조정하거나 문제를 하위 작업으로 분해해야 합니다. 먼저 빠른 모델을 사용하여 개요를 생성한 다음, 서로 다른 섹션들을 병렬로 처리하고, 마지막으로 일관성 확인 및 개선을 위해 다른 모델을 사용하는 콘텐츠 생성 시스템을 생각해 보십시오. 이러한 조정 방식은 출력 품질을 유지하면서 누적된 지연 시간의 영향을 주의 깊게 살펴야 합니다. 각 단계마다 적절한 타임아웃과 폴백 메커니즘이 있어야 다양한 조건에서 안정적인 성능을 제공할 수 있습니다.

성능 향상을 위한 프롬프트 캐싱

이 게시글은 지연 시간 최적화 추론에 초점을 맞추고 있지만, Amazon Bedrock은 비용과 지연 시간 모두를 최적화하기 위해 프롬프트 캐싱(미리보기)도 제공한다는 점에 주목할 필요가 있습니다. 이 기능은 문서 기반 채팅 도우미 또는 반복적인 쿼리 패턴을 가진 애플리케이션과 같이 컨텍스트를 자주 재사용하는 애플리케이션에 특히 유용합니다. 프롬프트 캐싱은 지연 시간 최적화 추론과 결합될 때 자주 사용되는 컨텍스트의 처리 오버헤드를 줄임으로써 추가적인 성능 이점을 제공할 수 있습니다.

지능형 모델 에이전트 선택을 위한 신속한 경로 설정

프롬프트 캐싱과 마찬가지로, Amazon Bedrock 지능형 프롬프트 라우팅(미리보기)은 또 다른 강력한 최적화 기능입니다. 이 기능은 각 프롬프트의 복잡성에 따라 동일한 모델 패밀리 내의 다른 모델로 요청을 자동으로 보냅니다. 예를 들어, 간단한 쿼리는 더 빠르고 비용 효율적인 모델로 라우팅될 수 있고, 더 깊은 이해가 필요한 복잡한 요청은 더 정교한 모델로 라우팅됩니다. 이 자동 라우팅은 수동 개입 없이 성능과 비용을 최적화합니다.

아키텍처 고려 사항과 캐싱

애플리케이션 아키텍처는 전반적인 지연 시간 최적화에 중요한 역할을 합니다. 자주 요청되는 정보에 대한 응답 캐싱과 과거 대화 정보에 대한 스마트 컨텍스트 관리를 포함하는 다중 계층 캐싱 전략을 구현하는 것을 고려해 보십시오. 이것은 정확한 일치 항목을 저장하는 것뿐만 아니라 유사한 쿼리를 식별하고 응답을 제공할 수 있는 의미론적 캐싱을 구현하는 것을 고려해야 합니다.

모델의 정교함, 지연 시간, 비용 사이의 균형

생성형 AI 애플리케이션에서는 다음 그림에 나타나있는 것과 같이 모델의 정교함, 지연 시간, 비용 사이에서 끊임없이 균형을 유지해야 합니다. 더 발전된 모델이 더 높은 품질의 결과를 제공하는 경우가 많지만, 항상 엄격한 지연 시간 요구 사항을 충족하지는 않습니다. 이런 경우에는 덜 정교하지만 더 빠른 모델을 사용하는 것이 더 나은 선택일 수 있습니다. 예를 들어, 거의 즉각적인 응답이 필요한 애플리케이션의 경우, 출력 품질이 약간 떨어지더라도 지연 시간 목표를 충족하기 위해 더 작고 효율적인 모델을 선택해야 할 수 있습니다. 이 접근 방식은 AI 시스템의 비용, 속도 및 품질 간의 상호 작용을 최적화해야 하는 광범위한 요구 사항과 일치합니다.

Amazon Bedrock 지능형 프롬프트 라우팅과 같은 기능은 이러한 균형을 효과적으로 관리하는 데 도움이 됩니다. 요청의 복잡성에 따라 모델 선택을 자동으로 처리함으로써 개발자가 모든 요청에 대해 단일 모델을 사용하도록 할 필요 없이 품질, 속도, 비용의 세 가지 요소를 모두 최적화할 수 있습니다.

이 글에서 살펴본 것처럼, LLM 애플리케이션의 지연 시간을 최적화 하는 방법으로는 지연 시간 최적화 추론 기능과 프롬프트 캐싱 사용부터 지능형 라우팅 구현과 세심한 프롬프트 엔지니어링에 이르기까지 다양한 전략이 필요합니다. 핵심은 이러한 접근 방식을 여러분의 구체적인 사용 사례와 요구 사항에 가장 잘 맞는 방식으로 결합하는 것입니다.

결론

AI 애플리케이션을 빠르고 반응성 있게 만드는 것은 한 번의 작업이 아니라 테스트와 개선의 지속적인 과정입니다. Amazon Bedrock 지연 시간 최적화 추론은 훌륭한 출발점이 되어 주며, 지금까지 논의한 전략과 결합하면 상당한 개선 효과를 얻을 수 있습니다.

애플리케이션의 응답성을 높히고자 한다면 다음 과정을 수행하세요.

1. 노트북 샘플 코드를 사용해 특정 사용 사례에 대한 지연 시간을 벤치마킹해 보세요.
2. 애플리케이션 코드에서 지연 시간 최적화 추론을 활성화하세요.
3. 애플리케이션의 성능을 모니터링하기 위해 Amazon CloudWatch 지표를 설정하세요.

오늘날의 AI 애플리케이션에서는 스마트함만으로는 충분하지 않으며, 반응성도 마찬가지로 중요하다는 것을 기억하세요. 지금 바로 이러한 최적화 전략을 실행하고 애플리케이션의 성능이 향상되는 것을 지켜보세요.