이득:
- 스트리밍이 무엇인지, 이벤트 유형 및 스트리밍이 필요한 이유를 설명할 수 있습니다.
- max_tokens는 시간 초과 및 128K 긴 출력 관계를 파악합니다.
- 워크로드에 따라 스트리밍 요청과 비스트리밍 요청 중에서 올바른 선택을 할 수 있습니다.
채팅 인터페이스에서 응답은 단어별로 "입력"되어 있음을 알 수 있습니다. 이것은 시각적인 화려함이 아닙니다. 이는 스트리밍이라는 기술의 결과이며 프로덕션 품질의 LLM 통합에 필수적인 경우가 많습니다. 이 단원에서는 흐름이 무엇인지, 어떤 이벤트로 구성되어 있는지, 긴 출력 및 시간 제한과의 관계, 흐름을 언제 사용하고 사용하지 않을지에 대해 알아봅니다. 라이브 어시스턴트, 긴 보고서 생성, 일괄 처리 등 전문가의 실제 작업을 통해 주제를 다룰 것입니다.
흐름이란 무엇입니까?
비스트리밍(동기식) 요청의 경우 모델이 전체 응답을 생성할 때까지 기다립니다. 답변이 준비되면 한 덩어리로 도착합니다. 스트리밍 요청에서 서버는 모델이 생성됨에 따라 응답을 하나씩 보냅니다. 기술적으로 이는 서버에서 보낸 이벤트(SSE — 서버에서 보낸 이벤트, 열려 있는 연결을 통해 서버가 작은 이벤트를 연속적으로 보내는 방법)를 통해 수행됩니다.
차이점은 사용자 경험에서 분명해집니다. 8초가 걸리는 응답에서 비스트림 사용자는 8초 동안 빈 화면을 응시합니다. 스트리밍 사용자는 ~0.5초 안에 첫 번째 단어를 보고 텍스트가 흐르기 시작합니다. 인지된 대기 시간(사용자가 느끼는 대기 시간)은 크게 줄어들지만 총 시간은 변경되지 않습니다.
이벤트 흐름 유형
흐름은 일련의 사건이다. 개념적으로 일반적인 흐름은 다음과 같습니다.
사건
의미
메시지_시작
응답이 시작되었습니다. 모델, ID 등 헤더 정보가 도착했습니다.
content_block_start
콘텐츠 블록(예: 텍스트)이 시작되었습니다.
content_block_delta
작은 텍스트(델타)가 도착했습니다. 당신은 이것을 수집
content_block_stop
블록 완료
message_delta
stop_reason, 사용법 등 종료 정보 업데이트
message_stop
답장하다
코드는 content_block_delta 이벤트의 텍스트 조각을 순차적으로 결합합니다. 스트리밍되지 않은 응답과 정확히 동일한 텍스트가 표시됩니다. 사용량(토큰 번호)은 일반적으로 흐름이 끝나면 명확해집니다. 흐름이 끝나면 비용을 추적합니다.
팁: 대부분의 공식 SDK(소프트웨어 개발 키트 - 공급자의 기성 라이브러리)는 스트림을 수집하는 도우미(예: stream.get_final_message())를 제공합니다. 모든 트랙을 수동으로 관리할 필요는 없습니다. 전체 텍스트를 원하고 개별 이벤트를 처리하되 실시간 인쇄를 원하는 경우 이 도우미를 사용하세요.
긴 응답, max_tokens 및 시간 초과
스트리밍의 두 번째이자 보다 기술적인 원인은 시간 초과입니다. HTTP 요청이 일정 시간 내에 완료되지 않으면 클라이언트는 연결을 끊습니다. 모델에서 대규모 출력(예: 40,000개 토큰 보고서)을 요청하면 비흐름 호출이 이 제한을 초과하고 시간 초과될 수 있습니다. 요청이 실패하고 생성된 토큰에 대한 비용을 지불해야 합니다.
최신 모델은 단일 요청으로 최대 128,000개의 토큰을 출력할 수 있습니다. 그러나 경험상 법칙은 명확합니다. `max_tokens` 값이 높으면(대략 16,000 이상) 스트림을 사용하십시오. 스트리밍은 연결을 유지하고 시간 초과를 방지합니다. 진행 상황도 즉시 확인할 수 있습니다.
- `max_tokens`: 모델이 생성할 수 있는 최대 출력 토큰입니다. 딱딱한 천장. 인터럽트가 발생하면 stop_reason max_tokens가 반환됩니다.
- 컨텍스트 창: 입력 + 출력의 합이 맞아야 하는 창입니다. max_tokens는 출력의 최대값입니다. 두 가지를 섞지 마십시오.
주의: max_tokens가 큰 비흐름 요청을 던지는 것은 프로덕션에서 전형적인 실수입니다. 응답이 없으면 연결이 끊어지고 사용자에게 오류가 표시되며 토큰 비용이 낭비됩니다. 긴 출력 = 스트림.
언제 흐르고 언제 흐르지 않습니까?
상태
선호
왜?
라이브 채팅/어시스턴트
흐름
인지된 지연 시간 감소, 사용자에게 진행 상황 표시
장문의 보고서/문서제작
흐름
타임아웃 방지, 대용량 출력 안전하게 전달
짧은 분류(예: 단일 단어 태그)
흐름 없음
출력은 이미 작습니다. 추가적인 복잡성 불필요
일괄 처리
무흐름/배치
결과는 즉시 표시되지 않습니다. 7단원 참조
자동화 단계(백그라운드)
일반적으로 흐름이 없음
결과를 다음 단계로 전달하며 실시간 표시는 없습니다.
복사 가능한 프롬프트/템플릿
스트림 자체는 프롬프트가 아니지만 프롬프트는 스트림에서 생성된 출력을 관리하는 데 중요합니다. 길고 유동적인 생산에서는 전면에서 구조를 강조하면 품질과 추적성이 모두 향상됩니다.
# 긴 보고서를 섹션으로 나누어(흐름에서 진행 상황을 볼 수 있도록) 다음 제목을 사용하여 정확한 순서로 보고서를 작성합니다. 각 제목은 '##'으로 시작합니다:## 요약## 조사 결과## 권장 사항## 다음 단계
# 긴 생산에서 잘림을 피하기 위해 목표 길이를 제공합니다. 전체 텍스트는 약 800 단어입니다. 부분의 균형을 유지하십시오. 끝에 반 문장도 남기지 마세요.
# 스트리밍 도우미에게 즉시 첫 번째 문장을 제공합니다. 먼저 한 문장으로 직접 대답한 다음 자세히 설명하세요. 따라서 사용자는 기다리는 동안 즉각적인 결과를 볼 수 있습니다.
# 긴 출력을 구조적으로 유지합니다(나중에 구문 분석할 수 있도록) 출력을 이 섹션에 출력하고 각 섹션을 별도의 '### ' 헤더로 표시하여 프로그래밍 방식으로 구문 분석할 수 있도록 합니다. ### 소개 ### BODY ### 소스
약한 프롬프트 / 강한 프롬프트(장기 생산)
# WEAK이 주제에 대해 길고 자세한 보고서를 작성하세요.
# STRONG이 주제에 대해 약 900단어로 보고서를 작성하세요. 제목: ## 요약, ## 분석, ## 위험, ## 권장 사항. 각 제목은 최대 3문단이어야 합니다. 끝에 반 문장도 남기지 마세요.
강력한 버전; 길이, 구조, 마감 품질을 미리 결정합니다. 단면이 흐름에 따라 들어오면 사용자는 진행 상황을 명확하게 확인하고 모델 중단의 위험에 대비하여 스스로 길이를 관리합니다.
미니 케이스 3개
사례 1 — 빈 화면 불만 사항. 컨설팅 팀의 클라이언트 어시스턴트는 흐름 없이 응답했습니다. 평균 응답 시간은 7초이며, 사용자는 "멈추나요?"라고 묻습니다. 그는 불평했다. 일단 흐름에 들어가면 첫 번째 단어가 ~0.6초 안에 나왔습니다. 총 소요시간은 동일했지만, '느리다'는 불만은 거의 사라졌습니다.
사례 2 - 오래된 보고서. 한 재무팀에서 30페이지 분량의 분기 보고서를 작성하고 있었습니다. max_tokens: 30000을 사용하면 흐름 없음 요청이 60초 클라이언트 시간 초과로 인해 중단되고 요청이 실패하며 생성된 토큰이 송장에 기록됩니다. 그들은 흐름을 따라갔습니다. 연결은 계속 유지되었고, 보고서는 완전히 전달되었으며, 낭비되는 비용이 제거되었습니다.
사례 3 - 불필요한 흐름. 운영팀은 수신 이메일에 "긴급/정기"라는 라벨을 붙였습니다. 출력은 한 단어였지만 습관적으로 flow를 사용했습니다. 흐름은 한 단어 응답에서 이점을 제공하지 않았으므로 코드가 불필요하게 복잡해졌습니다. Flowless로 전환했을 때 코드는 단순화되었고 동작은 동일하게 유지되었습니다. 교훈: 스트리밍은 모든 곳이 아닌 장기/라이브 출력에서 가치가 있습니다.
일반적인 실수
- 긴 출력에서 스트림을 사용하지 않음: 시간 초과 및 낭비된 토큰 비용.
- 짧은 출력으로 스트리밍 사용: 불필요한 복잡성, 이점 없음.
- 스트림 끝에서 'stop_reason'을 확인하지 않음: max_tokens가 포함된 잘린 응답은 완료된 것으로 간주됩니다.
- 잘못된 델타 병합: SDK 도우미를 사용한 수동 합계로 인해 시퀀스/누락된 부품 오류가 발생합니다.
- 스트림 중간에 `사용`을 읽으려고 시도 중: 토큰 번호는 일반적으로 끝 부분에서 명확해집니다. 마지막에 비용을 추적하십시오.
- 스트리밍을 비용 절감으로 착각함: 스트리밍은 경험과 내구성을 향상시킵니다. 토큰 가격은 변경되지 않습니다.
심층: 흐름 중단 및 탄력성
스트리밍은 실시간 연결입니다. 이것이 강점이자 취약점입니다. 연결이 중간에 끊어지는 경우(네트워크 변동, 클라이언트 시간 초과) 지금까지 축적된 텍스트는 유지되지만 응답이 불완전해집니다. 프로덕션 품질 스트리밍 클라이언트는 이에 대비해야 합니다. 부분 텍스트를 "완료된 응답"으로 처리해서는 안 되며 message_stop 이벤트를 볼 때까지 응답이 완료된 것으로 간주해서는 안 됩니다.
두 번째 미묘함은 흐름이 비용을 변경하지 않는다는 것입니다. 스트리밍 여부에 관계없이 응답을 받는지는 토큰 가격에 영향을 주지 않습니다. 흐름은 경험과 지구력만을 향상시킵니다. 그렇다면 “스트리밍을 하면 더 저렴해질까요?” 질문에 대한 대답은 '아니오'입니다. 비용에 대해서는 5번째 및 6번째 장치(모델 선택, 캐시)를 살펴보십시오.
세 번째 요점은 실질적인 균형을 맞추는 것입니다. 라이브 어시스턴트를 사용하면 첫 번째 단어의 빠른 도착(지연 감지)이 매우 중요합니다. 따라서 모델에 직접 답을 입력하고 먼저 짧은 결과를 제공하도록 요청하면(4번째 단위의 시스템 프롬프트를 통해) 흐름의 이점이 배가됩니다. 사용자가 첫 번째 순간에 의미 있는 것을 발견하면 이후의 세부 사항을 참을성 있게 기다립니다. 반면에 흐름은 백그라운드에서 실행되는 작업에 기여하지 않으며 그 출력은 다음 자동화 단계로 이동합니다. 유일한 기준은 작업이 정확하고 완전하게 완료되었다는 것입니다.
요약하면
스트리밍은 응답을 하나씩 검색하여 감지된 대기 시간을 줄이고 대규모 처리량에 대한 시간 초과를 방지합니다. 라이브 어시스턴트 및 장문 문서 제작에 거의 필수입니다. 단편/백그라운드 작업에는 필요하지 않습니다. 장기간 생산 시 구조와 길이를 정면에서 즉각적으로 부과하면 품질과 추적성이 모두 향상됩니다. 흐름이 완료되면 stop_reason 및 사용량이 확실히 확인됩니다.
응용과제
두 가지 시나리오를 선택하세요. 라이브/장기(예: 고객에게 보고), 단편/백그라운드(예: 태그 지정). (1) 각각에 대해 흐름을 사용할지 여부를 결정하고 정당화합니다. (2) 긴 스크립트의 구조(제목 + 대상 길이)를 적용하는 프롬프트를 작성합니다. (3) max_tokens 값을 결정합니다. (4) 흐름 끝에서 stop_reason 및 사용법을 사용하여 수행할 검사를 나열합니다.
체크리스트
- [ ] 스트리밍이 무엇인지, 인지된 지연 시간을 어떻게 줄이는지 설명할 수 있습니다.
- [ ] 스트림 및 델타 조인의 기본 이벤트 유형을 이해했습니다.
- [ ] 대규모 max_tokens로 스트리밍해야 하는 필요성과 시간 초과 관계에 대해 알고 있습니다.
- [ ] 스트리밍을 사용할 워크로드와 사용하지 않을 워크로드를 결정할 수 있습니다.
- [ ] 스트림이 끝나면 stop_reason과 사용량을 확인할 수 있습니다.