The official announcement from the Qwen team is also on HN right now.
1,855 karma · joined February 21, 2011
https://www.ubicloud.com/blog/building-infrastructure-contro...
On the data plane side, we use different open source components and our choice of programming language depends on them. For example for virtualization, we rely on Linux KVM and the Cloud Hypervisor. The former is in C and the latter in Rust.
https://github.com/deepseek-ai/DeepSeek-R1?tab=readme-ov-fil...
https://github.com/deepseek-ai/DeepSeek-R1?tab=readme-ov-fil...
We saw this in other questions as well. For example, if you asked o1 to write a "python function to download a CSV from a URL and create a SQLite table with the right columns and insert that data into it", it would immediately produce the answer. [4] If you asked it a hard math question, it would try dozens of reasoning strategies before producing an answer. [5]
[4] https://github.com/ubicloud/ubicloud/discussions/2608#discus...
[5] https://github.com/ubicloud/ubicloud/discussions/2608#discus...
They aren't only open sourcing R1 as an advanced reasoning model. They are also introducing a pipeline to "teach" existing models how to reason and align with human preferences. [2] On top of that, they fine-tuned Llama and Qwen models that use this pipeline; and they are also open sourcing the fine-tuned models. [3]
This is *three separate announcements* bundled as one. There's a lot to digest here. Are there any AI practitioners, who could share more about these announcements?
[2] We introduce our pipeline to develop DeepSeek-R1. The pipeline incorporates two RL stages aimed at discovering improved reasoning patterns and aligning with human preferences, as well as two SFT stages that serve as the seed for the model's reasoning and non-reasoning capabilities. We believe the pipeline will benefit the industry by creating better models.
[3] Using the reasoning data generated by DeepSeek-R1, we fine-tuned several dense models that are widely used in the research community. The evaluation results demonstrate that the distilled smaller dense models perform exceptionally well on benchmarks. We open-source distilled 1.5B, 7B, 8B, 14B, 32B, and 70B checkpoints based on Qwen2.5 and Llama3 series to the community.
We've been running qualitative experiments on OpenAI o1 and QwQ-32B-Preview [1]. In those experiments, I'd say there were two primary things going against QwQ. First, QwQ went into endless repetitive loops, "thinking out loud" what it said earlier maybe with a minor modification. We had to stop the model when that happened; and I feel that it significantly hurt the user experience.
It's great that DeepSeek-R1 fixes that.
The other thing was that o1 had access to many more answer / search strategies. For example, if you asked o1 to summarize a long email, it would just summarize the email. QwQ reasoned about why I asked it to summarize the email. Or, on hard math questions, o1 could employ more search strategies than QwQ. I'm curious how DeepSeek-R1 will fare in that regard.
Either way, I'm super excited that DeepSeek-R1 comes with an MIT license. This will notably increase how many people can evaluate advanced reasoning models.
I think Apple recently changed their stance on this. Now, they say that "source code for certain security-critical PCC components are available under a limited-use license." Of course, would have loved it if the whole thing was open source. ;)
https://github.com/apple/security-pcc/
> The goal of this system is to make it hard for both attackers and Apple employees to exfiltrate data from these devices.
I think Apple is claiming more than that. They are saying 1/ they don't keep any user data (data only gets processed during inference), 2/ no privileged runtime access, so their support engineers can't see user data, and 3/ they make binaries and parts of the source code available to security researchers to validate 1/ and 2/.
You can find Apple PCC's five requirements here: https://security.apple.com/documentation/private-cloud-compu...
Note: Not affiliated with Apple. We read through the PCC security guide to see what an equivalent solution would look like in open source. If anyone is interested in this topic, please hit me up at ozgun @ ubicloud . com.
I took extensive notes when playing around with o1 and QwQ-32B. When reading my notes later, I realized that I used the pronoun "they" to refer to a reasoning model. Somehow, it just didn't feel right to refer to o1 or QwQ-32B as "it."
Further, the rate of progress in this field was stunning. The Meta Chain-of-Thought paper that I linked in the Show HN came out last Friday.
So, if our AI overlords are reading this Show HN in the future, I'd like them to know that I landed on the right side of history on this one.
I think having a description of Apple's threat model would help.
I was thinking that open source would help with their verifiable privacy promise. Then again, as you've said, if Apple controls the root of trust, they control everything.
When asked why, she said, "When we give animals fruits that humans eat, they all develop diabetes."
"Why not just run Capistrano, Kubernetes or Docker Swarm?
...
Docker Swarm is much simpler than Kubernetes, but it’s still built on the same declarative model that uses state reconciliation. Kamal is intentionally designed around imperative commands, like Capistrano.
Ultimately, there are a myriad of ways to deploy web apps, but this is the toolkit we’ve used at 37signals to bring HEY and all our other formerly cloud-hosted applications home to our own hardware."
I had two questions just to learn more.
* What has been your experience with using local NVMes with K8s? It feels like K8s has some assumptions around volume persistence, so I'm curious if these impacted you at all in production.
* How does 'Reclaim the Stack' compare to Kamal? Was migrating off of Heroku your primary motivation for building 'Reclaim the Stack'?
Again, asking just to understand. For context, I'm one of the founders at Ubicloud. We're looking to build a managed K8s service next and evaluating trade-offs related to storage, networking, and IAM. We're also looking at Kamal as a way to deploy web apps. This post is super interesting, so wanted to learn more.
Thank you for the kind words!
Daniel has a few gems in this blog post and we tried to italicize some of them. My favorite one is around "There is no code without a theory of testing."
"If you have 100% branch coverage, it doesn't mean you've covered all the cases. But it does mean that, whenever an obscure fault is understood in production, or even merely observed in development, there is an incremental path to add it to the base of knowledge in the tests: there are no spans of code with no test model."
The book identifies uniqueness bias as an important reason for why most big projects overrun. (*) In short, this bias leads planners to view their projects as unique, thereby disregarding valuable lessons from previous similar projects.
(*) The book compiles 16,000 big projects across different domains. 99.5% of those projects overrun their timeline or budget. Others reasons for slipping include optimism bias, not relying on the right anchor, and strategic misrepresentation.
Our control plane is in Ruby, but our data plane uses different open source projects for managed services. For example, we use Linux KVM (C) and Cloud Hypervisor (Rust) for compute, SPDK (C) for block storage, Kubernetes (Go) well for Kubernetes.
My cofounder Daniel will talk about why we picked Ruby at the YC meetup next week. Maybe, we'll turn that into a blog post. Happy to hear your perspective as well!
Hey there, I know you meant something different, but I just wanted to chime in. At Ubicloud, we're building an open source cloud and our managed solution runs on Hetzner: https://www.ubicloud.com/docs
We're planning to tackle a managed k8s service next. If you have any feedback for our roadmap, could you drop us a line?
Still, you updated the above statement to, "Be aware that Ubicloud has a slightly lower CPU speed and somewhat variable queue times for x64 (but improving)."
Could you clarify what you meant by variable queue times?
According to the benchmarks, Ubicloud queue times for x64 were 18|44 secs at p50|p95 over the past month. I agree that our p95 number is higher. At the same time, RunsOn's AWS numbers are 31|36 secs. So I feel that driving a conclusion based on our p95 variance number for x64 is a bit unfair to Ubicloud.
Thank you for compiling this benchmark btw. Now, we'll follow it closely.
Looks like every GitHub Actions provider is on this thread. :) I also wanted to chime in with two thoughts.
First, we recently wrote about how we enabled arm64 VMs at Ubicloud. Any feedback on the technical details is more than welcome: https://news.ycombinator.com/item?id=40491377
Second, I feel runs-on's analysis is a bit unfair to us. Ubicloud's x64 / arm64 performance and queue times above are as good as any (we deprecated the AMD EPYC 7502 line). For example, RunsOn arm64 queue times are 31|42 seconds and Ubicloud queue times are 17|24 seconds.
But the analysis says the following, "Be aware that Ubicloud has low CPU speeds and high queue times, which means they won’t necessarily end up being cheaper than competitors." I fail to see this conclusion from the numbers above. What am I missing?
Who else would have run a PostgreSQL performance benchmark and discover a major security issue in the process?
Ubicloud runs on bare metal providers and they don't lease Mac hardware. Technically, we could run MacOS VMs on arm64. However, our interpretation of Apple's End User License Agreement (EULA) tells us that we can't do this.
This repo has some good references on the topic: https://github.com/kholia/OSX-KVM?tab=readme-ov-file#is-this...
We completely shut down the VM and remove the block device (all files associated with the block device).
We have dozens of customers using Ubicloud runners in production today. We’re now designing our caching layer (Docker instance registry, Docker layer cache, or package cache). We wanted to put this out there for any comments.
Also, if you have any points related to the broader topic of an open and portable cloud, please pass them along!
I agree with you on the sentiment about starting with a liberal license and then re-licensing once you gain enough adoption. We think it's only fair to our users that any re-licensing should go in the other direction.
I also had a clarification question, just to better understand. Which part of the Elastic V2 license do you find the most restrictive? (PS: We don't have license keys in Ubicloud. So, only directly competing against our managed service should apply.)
We didn't quote our prices in $ because the number of trailing zeros confused people. Maybe still go ahead and switch back to that?
Hey there, we offer Ubicloud Runners that are 10x cheaper than GitHub and bill them by the minute. You get a fresh VM with each job; and we use Hetzner as our underlying provider.
If you're already setting up a Hetzner box, I'd love to get your input. Any thoughts or feedback for us?
https://www.ubicloud.com/use-cases/github-actions
https://github.com/ubicloud/ubicloud/blob/main/routes/web/we... (our github actions integration is also openly available)
"The CLOUD Act asserts that U.S. data and communication companies must provide stored data for a customer or subscriber on any server they own and operate when requested by warrant, but provides mechanisms for the companies or the courts to reject or challenge these if they believe the request violates the privacy rights of the foreign country the data is stored in."
We use Postmark to send emails and we apparently ran out of our monthly email limit after hitting HN. We just upgraded our plan; and this should now work. If it doesn't, please feel to directly ping us at support @ ubicloud.com.
I had a quick question. If we provided a dual license, Elastic V2 and SSPL, would that help?
We're happy to clarify the meaning of third-party as "commercially competing with our managed service" once we have a website. Still, we likely won't edit the Elastic V2 license since it might risk creating a new obscure license.
For clarification, we weren't planning to launch until we had a proper looking website. Yesterday, I shared our GitHub repo on LinkedIn to get feedback from friends. Then, we saw this on HN - and realized that we haven't looked at our website in quite a while.
We're also trying to formulate a better point of view on the license and its implications. We Ask HN'ed several days ago, but there wasn't much input: https://news.ycombinator.com/item?id=36998888
In the end, we picked a more restrictive license. An important reason for that is, we feel that we can move from a restrictive to a more liberal license easily. Doing the inverse would feel like not doing the right thing by our users.