-
Notifications
You must be signed in to change notification settings - Fork 46
AIT-221: Document how token streaming interacts with rate limits #3092
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: AIT-129-AIT-Docs-release-branch
Are you sure you want to change the base?
Changes from all commits
78d8406
0fc6189
cb9876d
981464c
6774369
44ffbf0
127a97c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| --- | ||
| title: Token streaming limits | ||
| meta_description: "Learn how token streaming interacts with Ably message limits and how to ensure your application delivers consistent performance." | ||
| --- | ||
|
|
||
| LLM token streaming introduces bursty traffic patterns to your application, with some models outputting 150+ distinct events (i.e. tokens or response deltas) per second. Output rates can vary unpredictably over the lifetime of a response stream, and you have limited control over third-party model behaviour. Without planning, concurrent token streams across multiple channels risk triggering [rate limits](/docs/platform/pricing/limits). | ||
|
|
||
| Ably scales as your traffic grows, and rate limits exist to protect service quality in the case of accidental spikes or deliberate abuse. They also provide a level of protection to consumption rates if abuse does occur. On the correct package for your use case, hitting a limit is an infrequent occurrence. The approach to staying within limits when using AI Transport depends on which [token streaming pattern](/docs/ai-transport/features/token-streaming) you use. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph talks about limits scaling as your traffic grows, and the importance of being on the correct package for your use case. That applies to whole-account / quota / extensive limits. But the rest of this document is about the connection client-to-server message rate limit and the channel message rate limit, which are both local, intensive limits: they don't scale as traffic grows and don't change with your quota. So this paragraph seems like it might cause confusion in this context |
||
|
|
||
| ## Message-per-response | ||
|
|
||
| The [message-per-response](/docs/ai-transport/features/token-streaming/message-per-response) pattern includes automatic rate limit protection. AI Transport prevents a single response stream from reaching the message rate limit by rolling up multiple appends into a single published message: | ||
|
|
||
| 1. Your agent streams tokens to the channel at the model's output rate | ||
| 2. Ably publishes the first token immediately, then automatically rolls up subsequent tokens on receipt | ||
| 3. Clients receive the same number of tokens per second, delivered in fewer messages | ||
|
|
||
| By default, a single response stream will be delivered at 25 messages per second or the model output rate, whichever is lower. This means you can publish two simultaneous response streams on the same channel or connection with any [Ably package](/docs/platform/pricing#packages), because each stream is limited to 50% of the [connection inbound message rate](/docs/platform/pricing/limits#connection). You will be charged for the number of published messages, not for the number of streamed tokens. | ||
|
|
||
| ### Configuring rollup behaviour | ||
|
|
||
| Ably joins all appends for a single response that are received during the rollup window into one published message. You can specify the rollup window for a particular connection by setting the `appendRollupWindow` transport parameter. This allows you to determine how much of the connection message rate can be consumed by a single response stream and control your consumption costs. | ||
|
|
||
|
|
||
| | appendRollupWindow | Maximum message rate for a single response | | ||
| |---|---| | ||
| | 0ms | Model output rate | | ||
| | 20ms | 50 messages/s | | ||
| | 40ms *(default)* | 25 messages/s | | ||
| | 100ms | 10 messages/s | | ||
| | 500ms *(max)* | 2 messages/s | | ||
|
|
||
| The following example code demonstrates establishing a connection to Ably with `appendRollupWindow` set to 100ms: | ||
|
|
||
| <Code> | ||
| ```javascript | ||
| const ably = new Ably.Realtime( | ||
| { | ||
| key: 'your-api-key', | ||
| transportParams: { appendRollupWindow: 100 } | ||
| } | ||
| ); | ||
| ``` | ||
| </Code> | ||
|
|
||
| <Aside data-type="important"> | ||
| If you configure the `appendRollupWindow` to allow a single response to use more than your [connection inbound message rate](/docs/platform/pricing/limits#connection) then you will see [limit enforcement](/docs/platform/pricing/limits#hitting) behaviour if you stream tokens faster than the allowed message rate. | ||
| </Aside> | ||
|
|
||
| ## Message-per-token | ||
|
|
||
| The [message-per-token](/docs/ai-transport/features/token-streaming/message-per-token) pattern requires you to manage rate limits directly. Each token publishes as a separate message, so high-speed model output can consume message allowances quickly. | ||
|
|
||
| To stay within limits: | ||
|
|
||
| - Calculate your headroom by comparing your model's peak output rate against your package's [connection inbound message rate](/docs/platform/pricing/limits#connection) | ||
| - Account for concurrency by multiplying peak rates by the maximum number of simultaneous streams your application supports | ||
| - If required, batch tokens in your agent before publishing to the SDK, reducing message count while maintaining delivery speed | ||
|
|
||
| If your application requires higher message rates than your current package allows, [contact Ably](/contact) to discuss options. | ||
|
|
||
| ## Next steps | ||
|
|
||
| - Review [Ably platform limits](/docs/platform/pricing/limits) to understand rate limit thresholds for your package | ||
| - Learn about the [message-per-response](/docs/ai-transport/features/token-streaming/message-per-response) pattern for automatic rate limit protection | ||
| - Learn about the [message-per-token](/docs/ai-transport/features/token-streaming/message-per-token) pattern for fine-grained control | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence implies the danger is from concurrent token streams across multiple channels. But that's not the case: earlier in the paragraph you note that a single token stream can still give you 150 tokens per second, more than enough to hit rate limits just from the one stream. (And if you have multiple streams, for the purposes of the connection inbound rate limit it makes no difference whether they're on multiple channels or the same channel)