Tbh, for most companies/orgs the cost/complexity of multi region just isn't worth it.
The cost of a work days worth of downtime is rarely enough to justify the expense of trying to deploy across multiple regions or clouds.
Esp if you are public facing and not internal. You just go 'well everyone else was down to because of aws' and your customers just go 'ah okay fair enough'
Cisco etc have truly insane pricing on optics, like $1000 for something generic that cost $20-50 from fs.com etc. The only difference is how it presents itself to the switch (ie, says its a Cisco optic), not actual difference in performance.
Often Cisco/etc will refuse support cases if you aren't using their optics, if the switches/routers even work with them in the first case, which isn't a given as often they'll refuse to work with non branded optics.
Really just a money grab by the big network vendors.
This box allows you to flash the firmware on the optic to say its from whatever brand you want (Cisco, Dell, Aruba, Juniper etc) so that you can get it to work in that companies switch/router.
For most SMEs, the brand of optics makes no difference. Maybe keep a few legit branded ones around for debugging and when you need to raise a support case. But otherwise, the generic ones flashed to look like branded ones work just fine.
> Often Cisco/etc will refuse support cases if you aren't using their optics, if the switches/routers even work with them in the first case, which isn't a given as often they'll refuse to work with non branded optics.
As others here have pointed out, Cisco reserves the right to do this but doesn't do it in practice. They don't even have a realistic chance to _detect_ a Cisco-programmed FS SFP, since it simply identifies the same as a genuine Cisco module.
If your case was directly related to the SFP (“I can't get a link on this fiber port”), then yes, they could probably refuse it. But if your case is about basically anything else on the switch, they won't care.
> If your case was directly related to the SFP (“I can't get a link on this fiber port”), then yes, they could probably refuse it.
I have zero doubt they will. But also you prove nothing and are doing yourself and the vendor a disservice if you fake it. There’s no telling what your 3rd party transceiver is doing incorrectly. Better to get one single supported sfp and get that fixed which will probably fix your other issue too.
FS is so big they’re probably fine. Another option is to get one supported sfp, find if it’s encoded to an oem part, then buy and install the oem part directly. Easy to twist the arm of your var to do this.
> But also you prove nothing and are doing yourself and the vendor a disservice if you fake it. There’s no telling what your 3rd party transceiver is doing incorrectly.
If I report an IS-IS problem and the root cause is an OEM SFP on a completely unrelated port, then the design of the switch is pretty awful. :-)
I’ve never heard of a vendor being so difficult. My comment applies only to interface errors. (Up/down status, rx/tx errors, fec issue, etc) Any vendor without an override for 3rd party sfp should be rejected after RFP.
"The only difference is how it presents itself to the switch (ie, says its a Cisco optic), not actual difference in performance."
That's not the only difference. I have had situations where I ran equivalent optics side-by-side, and then touched one and it was hot, and touched the other and it was not hot. They do contain different components. In the case of that test - the atgbics SFP was cool, and the other clone unit was hot. My dealer was able to get me in contact with someone technical at atgbics (the cool-running unit) who explained the difference, "The DSP might be say 13nm where more modern more expensive ones are 5nm."
But you definitely do not need to pay for "genuine" optics to get high-reliability optics. You just need to shop around the clones - atgbics is a clone.
All three (GB10, GB200 and GB300) are part of the Blackwell family, which means they have Compute Capability >= 10.X. You could potentially develop kernels to optimize MoE inference (given the large available unified memory, 128Gb, it makes the most sense to me) with CUDA >= 12.9 then ship the fatbins to the "big boys". As many people have pointed out across the thread, the spark doesn't really has the best perf/$, it's rather a small portable platform for experimentation and development
Aren't those netapp shelves pretty old at this point? See a lot of people recommending against them even for homelab type uses. You can get those 60 drive SuperMicro JBODs for pretty cheap now, and those aren't too old, would have been my choice.
Plus, the TCO is already way under the cloud equiv. so might as well spend a little more to get something much newer and more reliable
I can put some AWS Creds in my terminal and Claude Code is perfectly happy writing AWS CLI commands (or whole python scripts if necessary) to work out what it needs to about my infrastructure.
If you are trying to get facts out of an LLM you are using it wrong, if you want a fact it should use a tool (eg we search, rag etc) to get the information that contains the fact (Wikipedia page, documentation etc) and then parse that document for the fact and return it to you.
These tools are literally being marketed as AI, yet it presents false information as fact. 'using it wrong' can't be an argument here. I would rather then tool is honest about confidence levels and mechanisms to research further - then feed that fact back into 'AI' for the next step.
Although the RTX Pro 6000 is not consumer-grade, it does come with graphics ports (four Displayports) and does render graphics like a consumer card :) So seems the difference between the segments is becoming smaller, not bigger.
Sure, but it still sits in the 'business-grade hardware whose main purpose is AI training or running inference for LLMs" segment parent mentioned, yet have graphics connectors so the only thing I'm saying is that just looking at that won't help you understand what segment the GPU goes into.
I'd Like to point at the first revision AMD MI50/MI60 cards which were at the time the most powerful GPUs on the market at least by memory bandwidth.
Defining GPU as "can output contemporary display connector signal and is more than just a ramdac/framebuffer-to-cable translator, starting with even just some 2D blitting acceleration.
The cost of a work days worth of downtime is rarely enough to justify the expense of trying to deploy across multiple regions or clouds.
Esp if you are public facing and not internal. You just go 'well everyone else was down to because of aws' and your customers just go 'ah okay fair enough'