๊ฐ€์ž… ํ›„ ์ดˆ๋Œ€ ๋งํฌ๋ฅผ ๊ณต์œ ํ•˜๋ฉด ๋™์˜์ƒ ์žฌ์ƒ ๋ฐ ์ดˆ๋Œ€ ๋ณด์ƒ์„ ๋ฐ›์„ ์ˆ˜ ์žˆ์Šต๋‹ˆ๋‹ค.

cv usk
@cv_usk
AI / Software Research Notes AI Agent, LLMOps, MLOps, Software Architecture ๆŠ•็จฟใฏๅ€‹ไบบใฎๆ„่ฆ‹ใงใ™ใ€‚
๊ฐ€์ž… May 2026
284 ํŒ”๋กœ์ž‰ ์ค‘    434 ํŒฌ
TL;DR Routing between models at the token level looks great on paper, yet running it on today's serving stacks makes things slower. This paper fixes that with a purpose-built runtime. Accepted at NeurIPS 2026. Title: TokenRouter: Efficient Serving System for Token-Level LLM Routing URL: Points ๐ŸŽฏ R2R matches 32B quality while sending just 5% of tokens to the 32B model, versus roughly 40% of queries under query-level routing ๐Ÿงฑ But vLLM and SGLang assume every request is step-synchronous, so fast models idle waiting on slow ones and batches fragment on every switch โœ๏ธ Developers write only route, send, and receive, tracing how a single request flows, while the runtime handles async execution ๐Ÿ”€ Each model gets its own subserver, with client, decoding, and inter-model loops decoupled and KV-cache preserved across handoffs โณ Instead of firing on arrival, the scheduler buffers to a threshold; wait too long and the small model starves, so the optimum is derived from a discrete-time Markov chain ๐Ÿ“ˆ Wins on all 15 algorithm-by-workload combinations, with 2.01-64.15x higher throughput ๐Ÿงช Throughput holds steady when output grows from 2,048 to 8,192 tokens, where the standard baseline loses 58-85% of its own The range is wide though, and on Co-LLM and R-Stitch the 32B model alone still runs faster. Worth remembering this isn't a universal win. #LLM# #Inference#
๋” ๋ณด๊ธฐ