Been using it. Happy customer. It gave me sanity into otherwise very complex LLM infrastructure. We spend 60k+ every month on LLM calls, so having the backbone to debug when things go haywire has helped a lot.
Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
41–50 of 64 posts
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#42A happy Langfuse customer here! We've been building an agent platform and some of our customers wanted someway to exfil OTEL traces to their own setup. Initially we tried building our own but then realised Languse does exactly what we needed doing. So we offered it as a first class integration, (and started using it internally). Great product, and hope you guys continue to improve it!
Thanks! Really enjoyed working with you maintainers of other projects to help them offer more native LLM observability and evaluation to their users/communities. There is a lot that goes into making the observability/eval part scalable/useful and requirements change on a weekly basis with new advancements. Same applies to other projects and it makes a lot of sense to integrate.
Overview of community integrations: https://langfuse.com/docs/integrations/overview
Packages that depend on Langfuse: https://langfuse.com/faq/all/packages-depending-on-langfuse
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#43Earlier quoted context omitted.
What are other potential platforms?
Bunch of them : Langsmith, Lunary, Phoenix Arize, Portkey, Datadog and Helicone. We also picked Langfuse - more details here: https://www.nonbios.ai/post/the-nonbios-llm-observability-pi...
We launched Laminar couple of months ago, https://www.lmnr.ai. Extremely fast, great DX and written in Rust. Definitely worth a look.
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#44Earlier quoted context omitted.
Bunch of them : Langsmith, Lunary, Phoenix Arize, Portkey, Datadog and Helicone. We also picked Langfuse - more details here: https://www.nonbios.ai/post/the-nonbios-llm-observability-pi...
Thanks for sharing your blogpost. We had a similar journey. I installed and tried both Langfuse and Phoenix and ended up choosing Langfuse due to some versioning conflicts on the python dependency. I’m curious if your thoughts change after V3? I also liked that it only depended on Postgres but the scalable version requires other dependencies. The thing I liked about Phoenix is that it uses OpenTelemetry. In the end w…
As you mentioned, this was a significant trade-off. We faced two choices:
(1) Stick with a single Docker container and Postgres. This option is simple to self-host, operate, and iterate on, but it suffers from poor performance at scale, especially for analytical queries that become crucial as the project grows. Additionally, as more features emerged, we needed a queue and benefited from caching and asynchronous processing, which required splitting into a second container and adding Redis. These features would have been blocked when going for this setup.
(2) Switch to a scalable setup with a robust infrastructure that enables us to develop features that interest the majority of our community. We have chosen this path and prioritized templates and Helm charts to simplify self-hosting. Please let us know if you have any questions or feedback as we transition to v3. We aim to make this process as easy as possible.
Regarding OTel, we are considering adding a collector to Langfuse as the OTel semantics are currently developing well. The needs of the Langfuse community are evolving rapidly, and starting with our own instrumentation has allowed us to move quickly while the semantic conventions were not developed. We are tracking this here and would greatly appreciate your feedback, upvotes, or any comments you have on this thread: https://github.com/orgs/langfuse/discussions/2509
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#45This is actually one of the more interesting LLM observability platforms I've seen. Beyond addressing scaling issues, where do you see yourself going next?
What are other potential platforms?
One missing in the list below is Agenta (https://github.com/agenta-ai/agenta).
We're oss, otel compliant with stronger focus on evals and the enabling collaboration between subject matter experts and devs.
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#46Earlier quoted context omitted.
Bunch of them : Langsmith, Lunary, Phoenix Arize, Portkey, Datadog and Helicone. We also picked Langfuse - more details here: https://www.nonbios.ai/post/the-nonbios-llm-observability-pi...
We launched Laminar couple of months ago, https://www.lmnr.ai . Extremely fast, great DX and written in Rust. Definitely worth a look.
Congrats on the Launch!
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#47Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#48Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#49Been using Langfuse OSS for almost 15 months from the start. By far the best solution. No dark patterns found in other projects such as Portkey.
Re: Launch HN: Langfuse (YC W23) – OSS Tracing and Workflows to Improve LLM Apps
#50Been using Langfuse OSS for almost 15 months from the start. By far the best solution. No dark patterns found in other projects such as Portkey.
All core features are fully open-source and identical to those in Langfuse Cloud, with no limitations on capabilities or scalability (e.g. all v3 infrastructure changes).
We also offer some optional commercial add-on features that can help iterate faster or support very large teams using Langfuse. However, these features are entirely optional and we do our best to be transparent about this across our docs.