My understanding is that a lot of AI data centers are still heavily relying on spinning HDDs, which is why seagate, western digital are selling more HDDs than ever before.
Spinning drives are still the "best" for data density and if the IO is sequential (which wouldn't surprise me with AI training workloads), the performance delta may not be that bad vs SSDs. As always, it depends on use case.
I know that a lot of cloud storage has tiered models, where the "expensive, but faster" tiers are SSDs, but then the slower cheaper tiers are HDDs, and the "cold storage" can be HDDs that are turned off all the way to tiers like AWS's S3 "deep archive glacier" tier being tape drives.
When you first built it, were you aware there was market for the data? Or was this something you discovered afterwards? It makes sense, but I wouldn’t have guessed it.
> 2. Talent & compute: due to #1, Silicon Valley can outbid Europe for the best talent and hardware. Watch an OpenAI launch video and listen to all the European accents.
There is definitely a lot of truth to that. Maybe a bit of an arbitrary measure, but these are the nationalites of the people that wrote the "Attention is all you need" paper. Pretty revealing I find:
Absolutely not. My wife could apply for German permanent residency as well as now German citizenship from within Germany. She has been living in Germany for 10 years now and at no point in the process did she have to go through a German consulate (she is a US citizen).
So, I experimented a little bit with smaller models and the problem I faced is that it would simply not call a tool that is available, but instead just describe the tool. Is this something that Forge can help with?
Within limits, yes. Forge has escalating nudges that will tell the model effectively "stop responding with text, you MUST call a tool" vibes. If the model is emitting something like "ok, let me call the tool: [valid json tool call in the middle of prose]" then we catch it with rescue parsing.
But at the end of the day, if the model keeps responding with text, there's nothing forge can do. I've run into that failure mode for sure, even with forge.
That works well enough for all the models shown in the eval here: relatively modern 8B+ models.
But some of the older generation (mistral 7b, that sort of thing) still can't be reliably used in something like a production setting.
Some of the older models did do this (like 3.5-era ish I think), and the harness would parse the results.
The newer way frontier has setup is structured tool calls. `tool_use` or `tool_calls`. The response is then received as a different tool_result rather than a regular message. That's a bit of the newer way of doing it.
The failure mode in question is more the model mixing the two: "Sure, I'll read the file: {"tool": "read", "args": {"path": "foo"}}" - that'll break stuff. Other failure modes are the json not parsing when sent it as a structured call, and in some cases the model just emitting text and forgetting the tool call.
I think it had more to do with the reality of the market. Solar panels have become incredibly cheap and that's because they are mass produced and standardized. Everything in the manufacturing process has been optimized. Now it is technically of course possible to make them other form factors, but artisinal solar panels are simply so much more expensive and cannot compete in any meaningful way with regular panels.
My understanding is that the US doesn’t really have an official category called “medium sized”. So I think the “small business” category is better compared to EU’s SME category (small-medium-enterprise), which is often lumped together.
I have recently played around with lots of data from measurements and one can totally dump everything into context and let Claude try to analyze data that way. It burns through a lot of tokens. It is smarter to save data to disk and let Claude write scripts that handles/analyzes the data. It’s much faster and the results are much better and you save a lot of tokens. But I guess Amazon prefers the first approach.
I don’t have any specific inside knowledge about Amazon, but I would hazard a guess that the first approach also provides better training material for the LLM.
I have been experimenting on using AI for hardware development. I showed some experiments on HN a couple of weeks ago (https://news.ycombinator.com/item?id=47801255). I am now trying to make my approach a little bit more comprehensive and structured, instead of several disjoint MCP servers, a single platform that connects lab instruments to AI assistants: https://teasel.tools/
As a demo, I repaired an old Philips PM5190 function generator (about 40 years old) and connected it to Claude Code. Lots of fun. Going to post a follow up video the next couple of days.
reply