-
-
Notifications
You must be signed in to change notification settings - Fork 300
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
Streaming #189
Comments
Hi @kilimchoi, thanks for your question. Can you explain a bit more how this would work? |
I think you'd need to use something like ruby-eventsource to listen for the Server Sent Events and then in turn provide a stream api to the caller. |
@alexrudall in python you can do it as follows,
i don't believe this ruby library supports the streaming option as it uses httparty under the hood which doesn't support server-sent events. But if you added streaming, it would def help other devs who are looking to minimize the response wait time since streaming characters is much faster than waiting for the whole thing. |
have you implemented streaming using this library? If so, I'd appreciate if you could share a sample repository or even a gist. |
Thanks for more info. Looks like Typhoeus supports streaming, maybe that could work - thinking of switching from HTTParty to that in next major release anyway |
This is an example of a raw response when setting streaming to true
|
Made an example sinatra app that uses typhoeus to stream responses: https://gist.github.com/lucasluitjes/0bf82de475ac91fe2ad8e71d5c2df164 |
Maybe another http client that supports streams: https://github.com/httprb/http |
I'm happy to create a PR for this to help get it moving along as we need this right now. Would we want to use one of these libraries? HTTP Faraday Typhoeus |
I'd personally vote for HTTP or Faraday as most Rails apps I work on already use those, whereas Typhoeus isn't as popular. |
I have tried Typhoeus for this exactly (streaming) and it works phenomenally. It relies on libcurl (ten billion installations [1]) which is extremely good. Maybe we can default to Typhoeus through Faraday as Faraday is transport-agnostic. |
@gastonmorixe That sounds like a good path to me, taking that route in #234 |
xref #196 |
Thank you the good work and progress guys. We’ll definitely use it. Maybe I can help this week. One thing that it’s important to test and I did with lsof is that the TCP connection keep-alive really happen and that the connection is HTTP2. If the connection is reused the next request is really fast. If it doesn’t there’s a connection time and handshake delay of around half a second at least. I’m not sure if Typhoeus’ Hydra is thread safe, if it is I was planning to initiate one instance of Hydra in an initializer and somehow queue the requests through it. As it was the only way I found the TCP connection to keep-alive and be reused. There’s also a way to force the connection to be alive if you want to optimize this and be sure the next request doesn’t have to wait for the tcp connection. I will post how later as I’m in my mobile now. |
#234 adds streaming with Faraday - final reviews much appreciated 👍 |
ruby-openai v4 adds chat streaming with Faraday! Thanks everyone for your input and ideas! Let us know how you get on :) Streaming ChatGPTYou can stream from the API in realtime, which can be much faster and used to create a more engaging user experience. Pass a Proc to the client.chat(
parameters: {
model: "gpt-3.5-turbo", # Required.
messages: [{ role: "user", content: "Describe a character called Anna!"}], # Required.
temperature: 0.7,
stream: proc do |chunk, _bytesize|
print chunk.dig("choices", 0, "delta", "content")
end
})
# => "Anna is a young woman in her mid-twenties, with wavy chestnut hair that falls to her shoulders..." |
is there a way to stream the response from the api like how chatgpt streams one token at a time?
The text was updated successfully, but these errors were encountered: