inference/research
verifiedmedium · 0.70updated 2026-10-08

Rebellions Rebel100

asic-other rebel100 (4-chiplet UCIe-Advanced) 2025

Fields

id
accelerators/rebellions-rebel100
Vendor
asic-other
Architecture
rebel100 (4-chiplet UCIe-Advanced)
Release year
2025
Form factors
oam
VRAM (GB)
144
Memory type
hbm3e
Memory bandwidth (GB/s)
4,800
Bandwidth basis
Vendor-published: 144 GB HBM3E at 4.8 TB/s. Separately, the same page claims the predictive DMA engine 'enables 2.7 TB/s effective bandwidth' for KV data - that is a different quantity (the achievable rate for KV prefetch on long-context decode) and is deliberately not recorded as the memory bandwidth figure.
Peak FLOPS
precisionfp16tflops1,024denseyesvendor_claimyessource_idasic-rebellions-rebel100basisvendor-spec-sheetbasis_detailVendor block labelled 'Compute (Dense)', verbatim '1,024 TFLOPS (FP16) 2,048 TFLOPS (FP8)' - present identically in the product page and in brochure v1.6, so the label 'Dense' is the vendor's own and dense:true is correct. NOTE FOR ANY FUTURE NUMERIC MATCH: the brochure prints '1,024' with a thousands separator, so a naive search for '1024' fails on the comma and would manufacture a false citation failure - the same trap that made this record look unsupported on an early pass of this audit. See w5a-rebellions-rebel100-brochure-16gbps-is-ucie-not-hbm for the full block and for the proof that the brochure's '16Gbps' is the UCIe-A chiplet link, not a DRAM pin rate, which is why memory_bus_bit correctly stays null.precisionfp8tflops2,048denseyesvendor_claimyessource_idasic-rebellions-rebel100basisvendor-spec-sheetbasis_detailVendor block labelled 'Compute (Dense)', verbatim '1,024 TFLOPS (FP16) 2,048 TFLOPS (FP8)' - present identically in the product page and in brochure v1.6, so the label 'Dense' is the vendor's own and dense:true is correct. NOTE FOR ANY FUTURE NUMERIC MATCH: the brochure prints '1,024' with a thousands separator, so a naive search for '1024' fails on the comma and would manufacture a false citation failure - the same trap that made this record look unsupported on an early pass of this audit. See w5a-rebellions-rebel100-brochure-16gbps-is-ucie-not-hbm for the full block and for the proof that the brochure's '16Gbps' is the UCIe-A chiplet link, not a DRAM pin rate, which is why memory_bus_bit correctly stays null.
TDP (W)
600
Unified memory
no
Consumer part
no
notes
memory_bus_bit CORRECTLY STAYS NULL, AND THE BROCHURE PDF NOW SUPPLIES THE PROOF. The rejection is confirmed by the document's own field grouping: brochure v1.6 prints 'Chiplet Interface (UCIe-A) | 16Gbps 1TB/s per channel' in a block SEPARATE from 'External Memory | HBM3E 144GB 4.8TB/s', and the product page repeats the identical grouping under the headings 'External Memory' and 'Chiplet Interface (UCIe-A)'. So '16Gbps' describes the external UCIe-A memory chiplet link, not the HBM3E DRAM interface. The arithmetic settles it independently: 4800 GB/s divided by 16 Gbps/pin is 2400 bits, and no HBM generation has a 2400-bit bus (HBM2, HBM2E, HBM3 and HBM3E are all 1024 bits per stack). A derivation that yields an interface width no generation of the memory it claims to describe has picked up the wrong denominator. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH - see the standing rule below. Vendor is asic-other because 'rebellions' is not in the schema enum; the real vendor is Rebellions (South Korea). Explicitly labelled 'Compute (Dense)' by the vendor, so both rows are genuinely dense. THE HIERARCHY POINT: this is one of the few parts where the inter-chiplet link, not the memory, is the architectural story. A full-chip on-chip mesh over UCIe-Advanced runs at 1 TB/s per bidirectional channel at 11 ns latency, so the four chiplets present as one virtual die with no software-visible boundary - 11 ns is roughly a register-to-register hop, which is the mechanism behind the 'no stalls in sparse or imbalanced workloads' claim. Against 4.8 TB/s of HBM3E at 144 GB, that gives 213 FLOP/byte FP16 and 427 FP8, so batch-1 decode remains memory-bound but 144 GB of capacity is enough to hold a large model resident, which is the combination large-model inference actually wants. The predictive, software-controlled DMA prefetching KV data ahead of the MXU is a software-visible optimization, so it is a tuning surface rather than a fixed property. Process node and die size are not published. Shipping status: RebelServer and RebelRack are in production with paying operators (SK Telecom's A.X K1 sovereign LLM ran on RebelServer per July 2026), and the vendor claims native PyTorch 2.x / vLLM / Triton support. Dense/sparse is not separately stated for FP8, and the vendor's own perf/watt claims (3.8x vs a current-gen GPU node) are marketing. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). NOT back-computed despite appearing derivable, and the reason is worth recording because it looks like a free win. The Rebel100 brochure prints 'HBM3E 144GB 4.8TB/s 16Gbps 1TB/s per channel', so a reader can divide 4800 GB/s by 16 Gbps/pin and get 2400 bits. 2400 bits IS NOT A REAL HBM INTERFACE WIDTH - no HBM generation has a 2400-bit bus - which shows the brochure's '16Gbps' is NOT a DRAM pin rate: it sits next to '1TB/s per channel' and describes the external UCIe-A memory chiplet link, not the HBM interface. Dividing by it would record a fictional number. Rebellions publishes no HBM bus width in bits, so it stays null. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch.

Notes

memory_bus_bit CORRECTLY STAYS NULL, AND THE BROCHURE PDF NOW SUPPLIES THE PROOF. The rejection is confirmed by the document's own field grouping: brochure v1.6 prints 'Chiplet Interface (UCIe-A) | 16Gbps 1TB/s per channel' in a block SEPARATE from 'External Memory | HBM3E 144GB 4.8TB/s', and the product page repeats the identical grouping under the headings 'External Memory' and 'Chiplet Interface (UCIe-A)'. So '16Gbps' describes the external UCIe-A memory chiplet link, not the HBM3E DRAM interface. The arithmetic settles it independently: 4800 GB/s divided by 16 Gbps/pin is 2400 bits, and no HBM generation has a 2400-bit bus (HBM2, HBM2E, HBM3 and HBM3E are all 1024 bits per stack). A derivation that yields an interface width no generation of the memory it claims to describe has picked up the wrong denominator. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH - see the standing rule below.

Vendor is asic-other because 'rebellions' is not in the schema enum; the real vendor is Rebellions (South Korea). Explicitly labelled 'Compute (Dense)' by the vendor, so both rows are genuinely dense. THE HIERARCHY POINT: this is one of the few parts where the inter-chiplet link, not the memory, is the architectural story. A full-chip on-chip mesh over UCIe-Advanced runs at 1 TB/s per bidirectional channel at 11 ns latency, so the four chiplets present as one virtual die with no software-visible boundary - 11 ns is roughly a register-to-register hop, which is the mechanism behind the 'no stalls in sparse or imbalanced workloads' claim. Against 4.8 TB/s of HBM3E at 144 GB, that gives 213 FLOP/byte FP16 and 427 FP8, so batch-1 decode remains memory-bound but 144 GB of capacity is enough to hold a large model resident, which is the combination large-model inference actually wants. The predictive, software-controlled DMA prefetching KV data ahead of the MXU is a software-visible optimization, so it is a tuning surface rather than a fixed property. Process node and die size are not published. Shipping status: RebelServer and RebelRack are in production with paying operators (SK Telecom's A.X K1 sovereign LLM ran on RebelServer per July 2026), and the vendor claims native PyTorch 2.x / vLLM / Triton support. Dense/sparse is not separately stated for FP8, and the vendor's own perf/watt claims (3.8x vs a current-gen GPU node) are marketing. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch.

MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). NOT back-computed despite appearing derivable, and the reason is worth recording because it looks like a free win. The Rebel100 brochure prints 'HBM3E 144GB 4.8TB/s 16Gbps 1TB/s per channel', so a reader can divide 4800 GB/s by 16 Gbps/pin and get 2400 bits. 2400 bits IS NOT A REAL HBM INTERFACE WIDTH - no HBM generation has a 2400-bit bus - which shows the brochure's '16Gbps' is NOT a DRAM pin rate: it sits next to '1TB/s per channel' and describes the external UCIe-A memory chiplet link, not the HBM interface. Dividing by it would record a fictional number. Rebellions publishes no HBM bus width in bits, so it stays null. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch.

Cross-references

Interconnect (2)