inference/research
draftlow · 0.30updated 2026-10-08

Iluvatar CoreX BI-V150 (Tiangai 150) cloud GPGPU training accelerator

asic-other ivcore11 (Iluvatar self-developed general-purpose GPU architecture) 2023
This record is a draft. Not yet verified. Provisional. Treat every number on this page as provisional.

Fields

id
accelerators/iluvatar-bi-v150
Vendor
asic-other
Architecture
ivcore11 (Iluvatar self-developed general-purpose GPU architecture)
Release year
2023
Process (nm)
7
Form factors
pcie
Bandwidth basis
None available. Iluvatar publishes no memory capacity, type, bus width or bandwidth for the BI-V150. The mirrorfrog.com spec sheet estimates 32-64 GB HBM2/HBM3 but explicitly labels this as 'estimated, same as TianGai 100' and notes 'Detailed specifications of TianGai 150 are not fully disclosed by official sources.'
TDP (W)
350
Unified memory
no
Consumer part
no
notes
THE HIERARCHY POINT: the BI-V150 is Iluvatar's second-generation cloud GPGPU training accelerator, released in 2023 as an upgrade to the BI-V100 (Tiangai 100). It uses the ivcore11 architecture on 7nm with 2.5D CoWoS packaging. The vendor publishes almost no specifications — the mirrorfrog.com page explicitly warns that 'Detailed specifications of TianGai 150 are not fully disclosed by official sources' and labels its FP16 (150-200 TFLOPS), INT8 (300-400 TOPS), memory capacity (32-64 GB) and TDP (275 W) entries as estimates. The moark.com page (a Chinese cloud provider) states 350 W peak power. The BI-V150 has participated in actual large-scale training deployments: Zhiyuan Research Institute's Aquila2-70B-Expr large model hybrid training used a 120-node BI-V100 cluster + 8-node BI-V150 cluster, reaching 85.3% of theoretical peak. The BI-V150 is significant because it represents Iluvatar's attempt to compete in the cloud training market, but the lack of vendor-published specifications makes it difficult to evaluate. Vendor is 'asic-other' because 'iluvatar' is not in the schema enum. 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). No source located publishes a memory bus width for this part. Where the record exists on the strength of a single secondary mention, that is stated in its own notes above. 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

THE HIERARCHY POINT: the BI-V150 is Iluvatar's second-generation cloud GPGPU training accelerator, released in 2023 as an upgrade to the BI-V100 (Tiangai 100). It uses the ivcore11 architecture on 7nm with 2.5D CoWoS packaging. The vendor publishes almost no specifications — the mirrorfrog.com page explicitly warns that 'Detailed specifications of TianGai 150 are not fully disclosed by official sources' and labels its FP16 (150-200 TFLOPS), INT8 (300-400 TOPS), memory capacity (32-64 GB) and TDP (275 W) entries as estimates. The moark.com page (a Chinese cloud provider) states 350 W peak power. The BI-V150 has participated in actual large-scale training deployments: Zhiyuan Research Institute's Aquila2-70B-Expr large model hybrid training used a 120-node BI-V100 cluster + 8-node BI-V150 cluster, reaching 85.3% of theoretical peak. The BI-V150 is significant because it represents Iluvatar's attempt to compete in the cloud training market, but the lack of vendor-published specifications makes it difficult to evaluate. Vendor is 'asic-other' because 'iluvatar' is not in the schema enum. 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). No source located publishes a memory bus width for this part. Where the record exists on the strength of a single secondary mention, that is stated in its own notes above. 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 (1)