Hacker News • 43일 전

LLM 꼬리 지연시간의 간단한 해결책

IMP

6/10

핵심 요약

실시간 음성 에이전트에서 LLM 응답이 가끔 10~20초씩 느려지는 문제를, 비싼 우선 처리 티어(priority tier) 대신 각 요청을 두 번 보내고 빠른 응답을 취하는 방식으로 해결한 사례다. 실측 결과 이 방법은 우선 티어보다 최악의 응답 완료 시간을 9.8초에서 3.5초로 줄이며, 동일한 비용으로 더 나은 지연시간을 제공한다. 느린 응답이 드물고 독립적일 때 특히 효과적이다.

번역된 본문

LLM 응답이 실시간 사용 사례에 너무 느릴 때, 더 빠른 서비스 등급을 위해 2배의 비용을 지불하고 싶은 유혹을 느낄 수 있습니다. Anthropic의 Priority 티어, OpenAI의 우선 처리(priority processing), Gemini의 우선 추론(priority inference), LLM 제공사가 무엇이라 부르든 간에요. 하지만 더 간단한 해결책이 있습니다: 모든 요청을 두 번 보내고 더 빠른 응답을 취하는 것입니다.

음성 에이전트에 꼬리 지연시간(tail latency)이 중요한 이유

HOAi의 음성 에이전트는 전화를 받습니다. 대화의 모든 턴마다 LLM 요청이 발생합니다. 대부분의 응답은 1.5초 안에 돌아오지만, 가끔 1020초가 걸리는 경우가 있습니다. 전화 통화에서 그것은 10초간의 어색한 침묵이고, 충분히 오랫동안 침묵이 지속되면 발신자가 에이전트를 끊어버립니다. 이런 일은 생각보다 자주 일어납니다. 일반적인 전화 통화는 2030턴으로 구성됩니다. LLM 요청의 1%가 극도로 느리다면, 25턴짜리 통화는 약 22%의 확률로 긴 침묵을 겪게 됩니다.

우선 티어 vs 요청을 두 번 보내기

두 가지 선택지가 있었습니다.

OpenAI의 우선 티어로 업그레이드하고 토큰당 2배 비용을 지불하여 더 빠르고 일관된 응답 받기
표준 티어에 유지하되, 모든 요청을 두 번 보내고 더 빠른 응답 취하기

실제 운영 환경의 요청 50개를 두 설정에 대해 재현하고 두 가지 지표를 추적했습니다: 첫 토큰까지의 시간(에이전트가 말하기 시작하는 시점)과 전체 응답 완료 시간(툴 호출을 수행할 수 있는 시점)입니다.

첫 토큰까지의 시간:

	우선 티어	표준 티어, 두 번 전송
중앙값	0.61초	0.58초
p95	1.04초	0.68초
p99	4.2초	1.2초

전체 응답 완료 시간:

	우선 티어	표준 티어, 두 번 전송
중앙값	1.35초	1.35초
p95	3.4초	2.0초
p99	9.8초	3.5초
최악	9.8초	3.5초

요청을 두 번 보내는 방식이 명확히 우선 티어를 능가했습니다. 최악의 전체 응답 완료 시간이 9.8초에서 3.5초로 줄었습니다. 최악의 첫 토큰 시간은 4.2초에서 1.2초로 떨어졌습니다. 개별 요청 기준으로는 표준 티어가 더 느렸음에도 불구하고, 중앙값조차 우선 티어와 정확히 일치했습니다.

이 방법은 느린 응답이 드물고 서로 독립적일 때 효과가 있습니다. 요청을 두 번 보내면 같은 턴에 두 복사본이 모두 느릴 가능성이 낮아집니다. 이것이 발신자들이 겪던 10초짜리 침묵을 크게 줄였습니다.

교훈

실시간 대화형 LLM 제품을 만들고 있다면, 더 빠른 서비스 등급에 비용을 지불하기 전에 요청을 두 번 보내는 방식과 벤치마크를 해보세요. 동일한 비용으로 더 나은 지연시간을 얻을 수 있을지도 모릅니다.

원문 보기

원문 보기 (영어)

When LLM responses are too slow for your realtime use case, you may be tempted to pay double the cost for a faster service tier. Anthropic’s Priority tier , OpenAI’s priority processing , Gemini’s priority inference , whatever your LLM provider calls it. There’s a simpler solution: send every request twice and take the faster response. Why tail latency matters for voice agents Our voice agent at HOAi answers phone calls. Every turn in a conversation makes an LLM request. Most responses come back within 1.5 seconds, but occasionally one takes 10 to 20 seconds. On a phone call, that’s 10 seconds of awkward silence, and after enough silence, the caller hangs up on our agent. This happens more often than you’d think. A typical phone call has 20 to 30 turns. If 1% of LLM requests are catastrophically slow, a 25-turn call has roughly a 22% chance of hitting a long silence. Priority tier vs. sending each request twice We had two options. Upgrade to OpenAI’s priority tier and pay 2x cost per token for faster, more consistent responses. Stay on standard tier, but send every request twice and take the faster response. We replayed 50 real production requests against both setups and tracked two metrics: time to first token (when the agent starts speaking) and time to complete response (when it can act on tool calls). Time to first token: Priority tier Standard tier, sent twice median 0.61s 0.58s p95 1.04s 0.68s p99 4.2s 1.2s Time to complete response: Priority tier Standard tier, sent twice median 1.35s 1.35s p95 3.4s 2.0s p99 9.8s 3.5s worst 9.8s 3.5s Sending the request twice clearly outperformed the priority tier. Worst-case time to complete response dropped from 9.8s to 3.5s. Worst-case time to first token dropped from 4.2s to 1.2s. Even the median matched the priority tier exactly, despite the standard tier being slower per individual request. This works when slow responses are rare and independent. Sending the request twice makes it unlikely both copies are slow on the same turn. This significantly reduced the 10-second silences our callers were experiencing. The takeaway If you are building a realtime interactive LLM product, before you pay for the faster service tier, benchmark it against sending the request twice. You may get better latency at the same cost.

LLM 지연시간 음성 에이전트 실시간 처리 비용 최적화 엔지니어링