Texas IGNITE GPU Cluster

28-EQUI-RFP-1660

Addendum No. 2

The following are Questions & Answers submitted for this bid event:

1. Q: Storage Requirements - What is the total size/capacity of the required Storage? What is the expected performance of the Storage devices?

A: Storage architecture must support a high-performance, 500+ GPU scientific computation and training environment. While vendors are encouraged to propose recommended storage technologies, capacity, and performance characteristics based on the desired workloads, some minimums to consider are:

Fast tier (cluster storage) should include minimum 8 PB of usable NVMe-based storage supporting high-frequency checkpointing and massive random-read throughput.

Long-term tier (enterprise storage) should include minimum 12 PB or at least 150% of fast-tier capacity supporting artifact retention and dataset storage. Enterprise storage tier must also include connectivity to existing resources in Azure, AWS, and

GCP.

Proposed solutions must be scalable, allowing for non-disruptive capacity expansion.

2. Q: Texas Location and Residency Rules - Does “must live in Texas” mean physically hosted in a Texas facility (owned/leased by A&M), or is a Texas-based colocation acceptable?

A: Texas-based colocation is acceptable.

3. Q: Texas Location and Residency Rules - Any specific counties/campuses/regions required?

A: No, but consideration needs to be given to network connectivity between the co-location facility and Texas A&M Network points-of-presence. Utilization of Trans- Texas Digital Network (TTDN) or TX-BB will be a viable option

4. Q: Texas Location and Residency Rules - Any restrictions on remote management from outside Texas?

A: No. However, remote management should be from within the continental United States.

5. Q: Workload breakdown that drives GPU type (RTX vs L40S vs B200) For each workload:

training vs inference vs rendering/visualization vs VDI.

A: Workload breakdown will need to be flexible driven by scientific computation and training/inference.

6. Q: Workload breakdown that drives GPU type - Which workloads require B200-class (NVLink, FP8/FP16 training) vs L40S/RTX-class (inference/graphics)?

A: See answer to question #5.

7. Q: Workload breakdown that drives GPU type - What utilization profile is expected (steady-state vs burst)?

A: Workload is expected to be driven by a queue of jobs, but utilization may vary between jobs.

8. Q: Required Scale and Growth Curve - Day-1 GPU count by type and memory size, plus 12/24/36 month growth.

A: System is expected to be at full capacity Day 1.

9. Q: Required Scale and Growth Curve - Peak concurrency requirements (how many jobs/users at once?).

A: Depends on the request and number of GPUs needed per job.

10. Q: Required Scale and Growth Curve - Any hard “future max” sizing target? (ex: “must scale to X GPUs without redesign”).

A: Anticipate scaling to 1,000 GPUs with minimal redesign.

11. Q: Facility readiness - Available power per rack (kW/rack), total power budget, redundancy (N, N+1, 2N).

A: Facility options will be evaluated based on proposed system design and implementation plan. Estimate 1 – 2 MW.

12. Q: Facility readiness - Cooling type available (air, rear-door HX, liquid, CDU), supply temp limits.

A: See answer to question #11.

13. Q: Facility readiness - Rack depth/weight limits, floor loading, and whether high-density racks are allowed.

A: See answer to question #11.

14. Q: Network Fabric Requirements - Required topology: leaf-spine, number of tiers, target oversubscription.

A: We do not have a required topology.

15. Q: Network Fabric Requirements - Required bandwidth to each GPU node (25/100/200/400G) and latency targets.

A: 400 GB/s. Open to recommendations for latency targets based on scientific compute and training workloads.

16. Q: Network Fabric Requirements - Do they require RDMA (RoCE/IB) for training or is Ethernet-only acceptable?

A: Either is acceptable.

17. Q: Network Fabric Requirements - Separate fabrics needed for management vs storage vs compute?

A: As long as the proposed solution can meet multi-tenancy and security requirements, some flexibility here is acceptable. An ability to dynamically segment the fabrics and/or networks without physical cabling changes or extensive, manual switch reconfiguration is desirable.

18. Q: Storage Architecture & Performance - What’s the primary storage pattern: large sequential (training), small files (checkpoints), mixed, object-heavy?

A: Storage pattern depends on job. Generally expected to be mixed, and non-object-based, however.

19. Q: Storage Architecture & Performance - Required throughput (GB/s), IOPS, metadata ops/sec, and capacity by tier.

A: See answer to question #1.

20. Q: Storage Architecture & Performance - Are parallel file systems explicitly allowed/desired (Weka/Hammerspace/Lustre), and what are their requirements for HA/replication and multi-protocol (NFS/SMB/S3)?

A: For a computationally-focused storage system, parallel filesystems that can support very high amounts of read/write operations is strongly desired. SMB are not needed, nor is S3. However, if there is a requirement for an additional, non-computational storage system for cluster operation and/or persistent user home and project storage, that system should support NFS. S3 would be nice to have as well.

21. Q: Scheduler/Orchestration & Multi-Tenancy - Are they standardizing on Slurm, Kubernetes, both, or something else?

A: Both.

22. Q: Scheduler/Orchestration & Multi-Tenancy - Requirements for quotas, fair-share, reservations, chargeback/showback.

A: Yes.

23. Q: Scheduler/Orchestration & Multi-Tenancy - GPU partitioning requirements (MIG, vGPU, time-slicing, exclusive mode).

24. Q: Operations Model & Support Boundaries - Who runs what? A&M staff vs vendor managed services vs “co-managed.”

A: Provide options for all three. We are seeking a model that allows flexibility on the level of involvement based on current staff capacity. For vendor managed services, also provide an off-ramp strategy for knowledge transfer and transition. See section

2.1.6 of the RFP .

25. Q: Operations Model & Support Boundaries - Please provide the required response times, on-site support expectations, spares strategy, and RMA SLAs.

A: Looking for 24/7/365 services support with next business day on-site hardware support. Vendors should recommend key components and quantities to stock locally for timely repair.

26. Q: Operations & Support Boundaries - Upgrade policy: Can there be maintenance windows? Rolling upgrades required?

27. Q: Acceptance Testing & Benchmarking - What benchmarks or proofs are required for acceptance: NCCL all-reduce, IO500-ish storage tests, per-job time-to-train, inference throughput, multi-tenant contention tests?

A: At a minimum, repeatable NCCL, TOP-500, and IO-500 tests should be performed prior to handover and should be repeatable by the Owner. Demonstration of large, open-source LLM inference and multi-tenant utilization should also be validated and repeatable.

28. Q: Acceptance Testing & Benchmarking - What datasets/models are used for acceptance (customer-provided vs synthetic)?

A: Both.

29. Q: Acceptance Testing & Benchmarking - What does “pass/fail” look like, and who signs off?

A: This may somewhat depend on architectures proposed but some minimum criteria include, successful completion of industry standard benchmarks (e.g.

NCCL, Linpack, IO-500) and a stable, one-week full load stress test to ensure nodal consistency and operational reliability. Final sign-off by TEES will occur upon validation that all management, networking, storage, and compute nodes meet designed expectations without requiring intervention.

30. Q: For Section 2.1.7 (CMMC Level 2), is this a design requirement to support future compliance efforts, or must CMMC Level 2 be fully achieved prior to system handover?

A: CMMC Level 2 must be achieved by system handover to support current and future workloads.

31. Q: In Section 2.1.7, CUI and non-CUI workloads are specified to reside on shared infrastructure. What is the expected volume, data classification levels, and applicable regulatory frameworks for the CUI workloads, and is physical separation required?

A: CUI will be substantially smaller than non-CUI work but may increase over time.

CUI workload protections are guided by the NIST 800.171 framework.

32. Q: In Section 2.1.3, does the stated 8 PB of storage apply only to the performance tier, or does it include archival storage? If archival storage is separate, what is the expected capacity?

A: See answer to question #1

33. Q: Regarding LEARN network connectivity, will the organization procure and manage the circuit linking TEES to LEARN, or is that the vendor’s responsibility?

A: Yes, the agency will procure connectivity between the co-location facility and Texas A&M Network points-of-presence. The Trans-Texas Digital Network (TTDN), wide-area network provider for the Texas A&M System or TX-BB will be utilized.

While TTDN manages the circuit, co-location provider and vendor will work with them to ensure inter-connectivity.

34. Q: For Section 2.1.9 (Incubation Lab), must the incubation lab reside within the primary cluster, or may it be hosted in another facility or cloud environment? What is the minimum required GPU capacity?

A: See answer to question #53. GPU capacity should be significantly smaller but should well represent the primary capability.

35. Q: For Section 2.1.8 (Governance Framework), is the vendor expected to serve only in an advisory capacity, or to participate in governance post-deployment? Are there existing university governance models that must be integrated?

A: Serve in an advisory capacity. Based on vendor experience of deploying large-scale GPU capabilities in a higher education environments, provide a set of recommended committees to create for effective governance.

36. Q: Pricing - The portal requires individual pricing for items that may not apply to our solution. Can vendors submit their pricing in a spreadsheet (xlsx) or PDF format as a separate attachment? If so, would the vendors enter "0"'s for the amounts and add in the comments cell that the pricing is under separate file?

A: Yes, you would have to enter $0 for the lines that do not apply. Please leave a comment with an explanation and/or reference to another document.

37. Q: Section 2.1.5 Data Center - Would you consider options longer than 3 years?

A: Yes. However, not to exceed 5 years.

38. 1.3 para 3 page 8 - Q: Given research teams may be conducting Controlled Unclassified Projects, does the University require US Citizens or a Collateral Clearence or Background check?

39. Q: Due to the extended engagement period prior to full acceptance will the University accept Milestone Billing?

A: Yes, provided billing complies with the Texas Prompt Payment Act and milestones are clearly defined as service deliverables. Payment schedule to be agreed upon prior to formal execution of Services Agreement.

40. 2.1.5 Data Center Connectivity, page 16 - Q: Other than ability to connect to the TTDN as outlined are there any distance restrictions for the COLO facility?

A: Should be geographically located in Texas and reasonably accessible from College Station, TX within five hours of travel time.

41. 2.1.5 Data Center Connectivity, page 16 - Q: Are there any connectivity costs associated with the TTDN?

A: See answer to question #33.

42. 2.1.10 Vendor Quals, page 20 - Q: Will the University accept representative resumes for KP's?

43. 2.1.9 Incubation Lab, page 18 - Q: For the Incubation Lab, does the University anticipate needing a fully autonomous system with separate namespace storage, network and separate cooling?

A: See answer to question #53.

44. 8.1 Pricing, page 41 - Q: "In section 8.1 it states ""Provide itemized cost breakdown of all hardware required to deliver a turn-key, fully integrated, tested and workload ready GPU cluster." Would the University accept this cost broken out by Scalable Unit to deliver rather than itemized?"

A: Yes, provided vendor can articulate what hardware is included with a Scalable Unit.

45. Security-first architecture: To support a wide range of workloads with varied security requirements on shared infrastructure, the platform will be built on policy-driven multi-tenant architecture. This architecture eliminates the need for inefficient, physically isolated secure enclaves that often sit idle. Instead, it will use dynamic, attribute-based access controls ("ABAC") and network micro-segmentation to securely separate workloads. Research teams will be able to work on a Controlled Unclassified Information ("CUI") level project requiring a secondary identity one day and a non-CUI project the next, or at the same time, with security policies applied in real-time based on project context, not physical hardware, page 6 – Q: Are FedRAMP, or other State or Federal certifications required?

A: Yes. For any cloud-based product or service recommended as part of an accepted proposal, TX-Ramp certification is required.

Q: Are hardening strategies, such as DISA STIGs a requirement?

46. Include the ability to connect to cloud storage options (e.g. Microsoft 365 Commercial and GCC-High, Amazon S3, etc.) as destination targets for data entering and existing the storage ecosystem, page 9 –

Q: Please provide estimated bandwidth for each cloud interconnect required.

A: If connectivity to Texas A&M’s network is sufficient (at least 100 gb/s), then access to commercial cloud providers can utilize the Texas A&M network’s Internet capacity (>200bg/s) to reach these cloud providers. If there is not a 100 gb/s link to the campus, then at least 100 gb/s of burst connectivity will be needed from the system to the cloud providers.

Q: Are there any usage or connection fees to the offeror associated with the TTDN?

A: See answer to question #33

47. Section 2.1.5 - Racks: Respondent will provide all necessary racks for compute nodes, switches, management and utility/storage components, page 10 – Q: Will TEES require any customer premise equipment be installed in provided racks or in customer provided racks that need to be included in the co-location design? E.g.

switching, load balancers, IDS/IPS, domain controllers, etc.

A: Yes. Some switching may be required to facilitate connectivity to Texas A&M’s network.

Q: Does TEES expect the Provider to monitor and manage any customer provided hardware or software?

A: Outside of the primary capability, no.

48. Section 2.1.5 - Capacity: For co-location options, include the ability to reserve up to 30% additional capacity for future expansion, page 10 – Q: What is the metric aligned to the 30% reservation? GPU computational capacity, storage capacity or overall system footprint?

A: This metric is aligned on the desire to expand the capability which may include additional GPU, storage, and physical footprint. For example, going from a 500+ GPU cluster to a 750+ GPU cluster with equivalent increases in storage, nodes, etc.

49. Cluster operations: Propose vendor options to fully manage the cluster. Include server, storage, security, and operations management for a minimum of one (1) year with the option to either transition to an internal team or if needed, continue vendor cluster management services in one-year increments. Section 2.1.6 Page 11 – Q: Does this conflict with Section 1.5 which specifies a three (3) year term?

A: No. Three years is a recommended initial period.

50. Second and third bullets, Cluster Operations and Hardware support. Section 2.1.6 Page 11 – Q: Is it the intent of TEES to include all hardware, operating system, enterprise AI software, scheduler, etc. in the "Cluster Operations", while "Hardware Support" is limited to physical infrastructure?

51. Frameworks: Enforce an identity-centric, Attribute-based Access Control (ABAC) policy framework, ensuring that Controlled Unclassified Information (CUI) and non-CUI workloads can securely coexist on shared infrastructure. Section 2.1.7 page 11 –

Q: Will the University provide the hardware and or software to implement ABAC or is this expected from the Provider?

A: Vendor will need to provide.

52. Encryption: All data for cluster specific storage must be encrypted using FIPS 140-2-validated cryptographic modules. Section 2.1.7 page 11 – Q: This requirement seems to address data-at-rest. Are there in-transit encryption requirements as well? If so, please expand on the in-transit requirements.

A: Yes, in-transit encryption should follow the same. Post-quantum cryptography solutions should be considered for in-transit connectivity to/from the cluster.

Within the cluster, this will depend upon the strategy used for segmentation.

53. Section 2.1.9 pages 11, 12 – Q: Is the Incubation Lab environment to be co-located with the workload-ready environment or is this to be on University premises?

A: The incubation lab must be logically separate. Open to both co-location and on campus options, or a combination. Regardless of the location for core incubation lab hardware, the intent is to create or reinvent a space on campus to showcase the incubation lab and larger cluster capabilities to staff, faculty, sponsors, and visitors.

Q: Is it the expectation of the University that the Provider manage the Incubation Lab environment hardware and software?

A: Yes.

Q: If yes, does the Incubation Lab require 24x7x365 monitoring and management with NBD service for hardware repairs?

A: No.

Q: Can the Incubation Lab be utilized by the Provider for testing of patches and upgrades prior to moving to the production environment?

A: Yes.

Q: Will the Incubation Lab be utilized by the University for UAT of patches and upgrades prior to moving to the production environment?

A: This is a possibility, yes.

Q: What is the uptime requirement for the Incubation Lab?

A: We would prioritize uptime during core business hours with next business day support.

54. Incubation Lab, Section 2.1.9, pages 11 & 12 – Q: Will the Incubation Lab be utilized by the University for UAT of patches and upgrades with representative workloads prior to moving to the production environment?

A: This is a possibility, yes.

55. Section 4.11 page 18 – Q: Please provide a copy or URL for the referenced regulations.

A: https://www.tamu.edu/statements/privacy.html https://www.tamu.edu/statements/privacy.html

RELLIS campus Parking FAQs:

https://transport.tamu.edu/Parking/faqrellis.aspx#park Agency Rules and Standard Administrative Procedures | Texas A&M Engineering Experiment Station: https://tees.tamu.edu/compliance-operations/ethics-compliance/rules-procedures.html

56. Cloud Computing Services, Section 5.27 page 21 –

Q: Please provide a copy of documents found on:

https://iso.engr.tamu.edu/catalog.html A: Please refer to this link:

https://docs.security.tamu.edu/docs/security-controls/home/

Q: Does this solicitation fall under cloud services, and therefore require TX-RAMP certification?

A: If cloud services or products are included in a proposed solution, yes. TAMU does have a cloud service calculator that may provide some assistance:

https://tools.security.tamu.edu/cloud-service-calculator/

Q: If so, is this classified as a Level 1 or Level 2 certification requirement?

A: If included in proposed solution, Level 2

57. ITSM –

Q: Does the University require integration with existing ITSM?

A: Yes.

Q: If, so what level of integration is required? Simple read only access, standard bi-directional, or customized bi-directional integrations?

A: This will depend on the managed services selected. Anticipate a basic level of integration for ticket or problem escalation.

58. Security – Q: SIEM/logging is assumed to be a customer responsibility. Is this correct?

A: Yes. Proposed solutions should offer the capability to ship logs to our SIEM of choice. Sufficient local, centralized gathering and storage of logs should be provided as a part of the cluster solution. This is primarily to ensure that logs can be filtered for remote SIEM delivery.

Q: Will the University be responsible for any vulnerability and penetration testing and analysis or is this considered to be the responsibility of the Provider?

A: This will be a shared responsibility.

Q: If the Provider is responsible for vulnerability and penetration testing and analysis, will the University provide the software and licenses or is this a Provider responsibility?

A: This again will be a shared responsibility between the vendor and agency with each bringing their established security tools.

https://tees.tamu.edu/compliance-operations/ethics-compliance/rules-procedures.html https://tees.tamu.edu/compliance-operations/ethics-compliance/rules-procedures.html https://tees.tamu.edu/compliance-operations/ethics-compliance/rules-procedures.html https://tees.tamu.edu/compliance-operations/ethics-compliance/rules-procedures.html https://iso.engr.tamu.edu/catalog.html https://docs.security.tamu.edu/docs/security-controls/home/ https://tools.security.tamu.edu/cloud-service-calculator/

Q: Does the University require specific tools to comply with the testing and analysis? If so please list them.

A: No.

Q: What is the required frequency of vulnerability and penetration testing?

A: While vulnerability scanning may occur more frequently, penetration tests should be conducted periodically but no less than annual or after significant changes or upgrades.

59. Audit & Compliance – Q: Who will own the Audit & Review cycle for the enclaves?

A: The Texas A&M University System.

60. Observability and monitoring – Q: Is a combined monitoring solution (one that crosses all enclaves) acceptable?

A: Yes.

Q: Is all telemetry allowed to be transmitted off-site for processing?

A: Yes. Clarity on location, access, and security posture for the processing facility will be needed.

Q: Does the University require integration with existing observability and monitoring solutions?

A: No, but does require the ability to ship selected logs to a monitoring tool of choice.

Q: If, so what are those solutions and what data needs to be integrated?

A: N/A.

61. Data Protection – Regarding Cyber Liability (pg. 44, section E) – This clause puts the burden of data loss/compromise on the provider, but there is no part of the RFP that describes what or how the project data will be protected to mitigate loss or compromise in the first place.

Q: What backup/cyber resiliency product is currently planned for use in Project Ignite?

A: The agency has access to multiple backup/cyber resiliency platforms and will engage their use here, where appropriate.

Backup strategy for Project IGNITE will be considered in three tiers:

Tier 1: Core Infrastructure: The control plane ecosystem, including core software, orchestration metadata, and configuration data will be backed up regularly using already established tools and retention periods to facilitate rapid recovery.

Tier 2: Workload and active research: As a part of the proposal, cluster storage will include local convenience copies to mitigate accidental deletion or minor file corruption.

Tier 3: Long-term artifact storage: This data will be moved to the enterprise storage tier which will incorporate already well-established data backup and recovery processes and tools.

If none, please describe Project Ignite’s requirements around:

• The approximate percentage of total production data that must be backed up on a regular basis (e.g., daily/weekly).

A: See above.

•The number and types of backup copies required (e.g., local copies, offsite copies, immutable copies, cyber vaulted copies), and the retention periods for each.

A: See above.

•The regulatory, compliance, or internal policy standards (e.g., CJIS, HIPAA, CJIS like state standards, NIST, ISO, state or municipal records requirements) that these backups must meet, and any specific RPO/RTO or recovery assurance expectations.

A: Retention and data protection policies are guided by the NIST 800-53 and NIST 800-171 frameworks as well as the Retention Schedules for Texas State Agencies and Public Universities.

62. Section 8: Pricing, page 26 – Q: The pricing submission format in the portal only allows for 1 solution.

Please provide alternate submission instructions if more than 1 solution will be proposed.

A: Additional solutions should be submitted with the Proposal forms. Please clearly label any/all alternate solutions.

63. Section 1.6 Schedule of Events, page 7 –

Q: This vendor respectfully requests an extension to the current proposal deadline to allow for a more thoughtful and robust response. Specifically, would the University extend the Proposal Deadline to April 2, so that bidders have at least three weeks, from the release of the University’s response to questions and any final addenda, to thoughtfully absorb and implement that information, which will have a substantial impact on this vendors proposal?

A: The submission deadline has been extended to March 31, 2026, at 5:00 PM (CDT).

64. 3.6 Terms and Conditions. The Terms and Conditions (ref. Section 4) shall govern any

Agreement issued as a result of this solicitation RFP, page 14 – Q: Would TEES accept Vendor proposal that leverages terms and conditions of an existing statewide contract, such as the Dell NCPA 01-143, in lieu of the terms and conditions of GPU High Performance Computing Cluster RFP #28-EQUI-RFP-1660, to help facilitate and expedite negotiation of any resulting contract award, with the understanding that any additional provisions can be incorporated upon mutual agreement.

A: No, the terms and conditions of the RFP shall be made a part of and govern any Agreement/Purchase Orders resulting from this Request for Proposal. Per section

3.6 of the RFP - Additional or attached terms and conditions which are determined to be unacceptable to TEES may result in the disqualification of your proposal.

65. Section 2.1.3 Storage –

Q: What is the required storage capacity for the enterprise storage?

A: See answer in question #1

66. Section 2.1.3 Storage – Q: Regarding enterprise storage, what percentage split between high‑performance and archive storage are you anticipating?

A: See answer in question #1

67. Section 2.1.2 Networking – Q: The request does not indicate an in‑band network. Should one be included?

68. Section 2.1.9 Incubation Lab – Q: Please define "key" hardware that needs to be mirrored and how many users needed?

A: Recommend minimum hardware that 1) closely mirrors the full-scale production environment and 2) gives research teams an environment for training, experimentation, onboarding, and hands-on experience before transitioning to the workload-ready cluster.

69. Section 2.1 Technical Proposal – Q: Is there a preference for cluster management utility between commercially supported and open-source, e.g. Base Command Manager -vs.- xCAT?

A: No. A comparison, however, between BCM and xCAT would be appreciated so that the review team can understand the tradeoffs that were made when the proposed solution was selected.

70. Section 2 (Security requirements guided by NIST 800-171 & 800-53) — req text; see Scope & Security-first architecture - Q: Is NIST SP 800-53 required across the entire solution, or limited to the CUI enclave and supporting services?

A: The entire solution should meet a minimum NIST 800-53 baseline. The CUI enclave and supported services should meet a minimum NIST 800-171 baseline.

71. Section 2 – Security/multi-tenancy & CUI references; Acceptance of Work (ATP) – Q: Please confirm if NIST SP 800-171/CMMC L2 are mandatory and define the authoritative system boundary for CUI.

A: Yes, CMMC L2 is mandatory. Vendor should define the people, processes, and technologies used to implement secure multi-tenancy requirements to take advantage of shared infrastructure and prove cryptographic isolation of the CUI data within.

72. Section 5.29 – Cybersecurity Training Program – Q: Regarding the Cybersecurity Training Program requirement, can TEES specify a required training platform and the process for certifying and verifying completion for our project staff?

A: Texas DIR provides all the requested information here:

https://dir.texas.gov/information-security/statewide-cybersecurity-awareness-training

73. Section 2.1.8 – Governance & Data Management – Q: Does TEES have an existing data classification policy and data owner/steward structure, or is the expectation that our services will help develop this framework as part of the Data Classification & Lifecycle Policies activity?

A: Please see answers to questions #61 and #79.

74. Section 2 – Security-first multi-tenant architecture with ABAC – Q: Which IdP(s) will be authoritative (i.e., Entra ID, AD DS, Shibboleth), and what MFA standards are enforced?

A: For consistency, we would prefer to use Cloudflare to facilitate connectivity to multiple identity providers, including Entra ID (both Commercial and GCC-High) and the InCommon Federation. Phish resistant MFA is already enabled for all users.

75. Section 2 – Security-first ABAC model – Q: What user attributes (department, project, clearance, export-control) can be reliably sourced for ABAC?

A: Multiple user and project specific attributes are available.

76. Section 2 – Multi‑tenant/secure enclave requirements; fabric isolation – Q: Please confirm tenant archetypes (CUI, non‑CUI, sponsored, external collaborators) and expected isolation requirements.

A: All of these tenant archetypes are expected with the addition of export controlled.

Answer to question #71 also applies.

77. Section 2 – Multi‑tenant operations - Q: Are there workloads requiring cross‑tenant data sharing or burst capacity between enclaves?

A: No.

78. Section 2 – Interconnect native isolation; Section 2 – Acceptance of Work/ATP – Q: What are acceptance criteria to prove inter‑tenant traffic invisibility during ATP?

A: Specific tests may be solution dependent and TEES is open to criteria recommendations. Some base criteria can include demonstrating logical isolation within the network and compute fabric, including fabric-level partitioning using industry-standard methods to ensure traffic from one tenant’s job cannot be routed to or intercepted by nodes assigned to another tenant. Users of one tenant should not be able to ping, scan, or capture packets from another tenant’s partition.

Finally, a user in one tenant should not be able to list, read, or write to storage allocated to another tenant.

Additional acceptance criteria can be found in answers to questions #27, #28, and #29.

https://dir.texas.gov/information-security/statewide-cybersecurity-awareness-training https://dir.texas.gov/information-security/statewide-cybersecurity-awareness-training

79. Section 1.3 – Scope/Workloads & classifications; Section 2 – Storage requirements – Q: What data classifications will be present (including CUI, ITAR/EAR, HIPAA/FERPA), expected volumes by tier, and specific lifecycle needs (retention, deletion)?

A: Multiple data types could be present. Public, University-Internal, Confidential, and Critical. Confidential data will be the most common classification observed with a modest but growing level of Critical Data, including CUI and ITAR.

See this website for more: https://www.it.tamu.edu/security-and-policy/it-policy/it-policy-guides/data-classification.html

80. Section 2 – Storage & data lifecycle expectations – Q: What are the retention, legal hold, and defensible deletion policies for research data across tiers?

A: Data has different retention requirements based on type. See answer to question #61 for more detail.

81. Section 2 – Security: Encryption at rest/in transit (FIPS 140‑2) - Q: Which key management solution is authoritative and who owns key rotation and escrow procedures?

A: Open to vendor recommendations for key management and rotation.

82. Section 2 – Acceptance of Work/ATP – Q: Which performance and isolation benchmarks (HPL/MLPerf + security tests) must be evidenced in ATP?

A: See answers to questions #27, #28, and #29

83. Q: Section 1.3 (Scope of Work) & Section 2.1.7 (Security) - Regarding the requirement to use dynamic, attribute-based access controls (ABAC) to securely separate CUI and non- CUI workloads: Will TEES serve as the Authorizing Official (AO) for the NIST SP 800- 171/CMMC Level 2 assessment of these logical enclaves, or is the vendor expected to provide a Third-Party Assessment Organization (3PAO) certification prior to deployment?

Is the requirement consistent across the main cluster and the Incubation Lab?

A: Vendor provided 3PAO and requirement applies to the main, workload-ready cluster only.

84. Q: Section 2 (High-Performance Storage) - The RFP mandates a parallel file system with a "minimum of 8 PB usable capacity and 2 TB/s aggregate read bandwidth," and requests options for an "Enterprise File System" for long-term storage. Can TEES clarify the specific initial usable capacity requirements and the anticipated scaling rates over the contract term for both the high-performance parallel file system and the enterprise archive storage tier?

A: See answer from question #1.

85. Q: Section 2 (High-Performance Storage) - For the on-premises enterprise archive storage tier, if a high-density tape library solution is proposed, does TEES require backwards compatibility with older LTO media generations (e.g., LTO-8 or LTO-9) for existing university data, or is a next-generation (LTO-10) solution acceptable to maximize storage density despite its lack of backward compatibility? Additionally, how much https://www.it.tamu.edu/security-and-policy/it-policy/it-policy-guides/data-classification.html https://www.it.tamu.edu/security-and-policy/it-policy/it-policy-guides/data-classification.html simultaneous I/O throughput is required to support the anticipated backup and archival windows?

A: Next generation is acceptable.

86. Q: Incubation Lab - Section 2 of the RFP requests an "Incubation Lab" to serve as a small-scale replica of the main cluster. Will the Incubation Lab be a long-lived stand-alone facility, or is the hardware expected to eventually be incorporated into the main production cluster?

87. Q: Operations & Management - Section 2.1.8 includes a request for options to "fully manage the cluster." What is the exact demarcation line of responsibility between the vendor's managed services and the University's internal IT and research support teams?

A: Vendor should propose support options as outlined in section 2.1.6 of the RFP.

88. Q: Cluster Hosting - If a respondent identifies an alternative cluster hosting solution that would provide superior value or benefit to TEES beyond those outlined in the RFP, is the respondent permitted to propose that alternative solution in addition to, or in lieu of, the specified options?

A:Yes.

89. Q: Responding to Hosting Options - Are respondents required to submit a response addressing all cluster hosting options outlined in the RFP, or may a respondent limit their response to only the option(s) for which they have relevant capabilities and can provide a competitive solution?

90. Q: 1) What FPx precision workloads are you targeting? This will help us determine which GPU is more suitable for your needs. 2) Required Training [Section 2.1.6] – Is this hardware or software training credits? 3) There is an OOB management network requirement for 100 GbE. OOB is for IPMI, BIOS access, Power control, Thermal monitoring, etc. Usually 1G/10G speed is good enough to handle the networking. The concern is that 100 GbE OOB is extremely over-spec, expensive, powerhungry, and consumes system resources unnecessarily. It is far beyond what OOB management requires, and forces changes to NIC count and switch selection. Please confirm this with customers.

A: For FPx precision requirements, see section 2.1.1 of the RFP. For required training see answer to question #291. For OOB management network requirements, see answer to question #120.

91. Q: Cooling requirement vs budget - If direct-to-chip (DTC) cooling is a requirement in the RFP, will air-cooled alternatives be considered if DTC causes the solution to exceed the budget?

A: DTC liquid cooling is preferred, however, we may consider air cooled options if vendor can prove equivalent performance.

92. Q: Operations and support funding - How much of the project budget is allocated to support and operations (percentage and/or dollar amount)?

A: We cannot disclose the budget.

93. Q: Budget overrun plan - What is the plan if a solution that meets the RFP requirements exceeds the budget, or if OEM pricing cannot be held through procurement?

A: Vendors are encouraged to make their best good-faith offer.

94. Q: Schedule and lead times - How will the project be adjusted if lead times for core components exceed the RFP delivery date?

A: Present best-effort lead times. Project adjustments, if needed, will be collaboratively evaluated with awardee.

95. Q: Security and access question – Workload Scope - How many applications and/or AI models are planned for deployment?

A: The cluster will be used to support the research needs of the College of Engineering and is not planned for specific applications and/or AI models.

96. Q: Security and access question – User Population - How many users will have access to the system?

A: The expected number may range from 100-1000 and will change over time.

97. Q: Security and access question – What monitoring/telemetry information is required (system, application, security, performance)?

A: our cyber operations team has specific telemetry they require from system, application, and security.

98. Q: Security and access question – What alerting capabilities are required (threshold-based, anomaly detection, integrations, escalation workflows)?

A: threshold based and anomaly detection

99. Q: Security and access question - Is an agentless approach required for monitoring and/or security controls?

A: preferred but not required

100. Section 2.1.1 (Cooling / GPU performance) - Q: If a solution can demonstrate required GPU performance using air cooling, will that be accepted as a compliant response?

A: DTC liquid cooling options are preferred.

101. Section 2.1.3 (2 TB/s performance testing) - Q: 1.Could you clarify the specific performance metrics required for the 2 TB/s testing?

A: Open to vendor performance metric recommendations.

Q: 2.Does the 2 TB/s target refer to:

o Sustained, application-level, end-to-end throughput, or o Nominal aggregate bandwidth of the storage front-end Ethernet interfaces (or another definition)?

A: See above.

Q: 3.Can you provide details on the expected validation workload, including:

o Protocol mix (e.g., SMB vs NFS) o I/O patterns (sequential vs random) o Typical object/file sizes o Read/write ratios A: See above.

102. Section 2.1.9 (Incubation lab alignment to product - Q: To what extent must the incubation lab replicate the production GPU cluster architecture?

A: The incubation lab should mirror the production cluster as closely as possible to ensure maximum workload interchangeability. See answers to question #53 and #68 for more.

Q: Is a single node acceptable, or must clustering/high-availability characteristics be retained?

A: See above.

Q: Are there specific hardware or software components that must be identical to production, or are functional equivalents acceptable?

A:See above.

103. Q: Evaluation - Do you plan to use any AI tools to evaluate proposal responses? If so, could you let proposers know which tool you plan to use?

A: We cannot rule out the use of AI tools to assist with evaluation. No.

104. Q: Business/Research Workload - [LLM Model Scale] What is the maximum model scale (number of parameters, for example, 8B, 72B, 671B ) expected for LLM development or training on this platform?

A: A minority of the loads are likely to be associated with training LLMs. However, for the LLMs that are being trained, we estimate a model size of 30-100 billion parameters.

105. Q: Business/Research Workload - [Robotics / Digital Twin Simulation] Will the robotics or digital twin workloads require long term real-time simulation platforms such as Isaac Sim, Gazebo, or Unreal Engine? If yes, please indicate the expected scale of simulation (e.g., number of concurrent environments, i.e. 100, 1000…).

A: Compute characteristics and requirements are still being evaluated for digital twin workloads. However, long-term real-time simulation workloads are anticipated.

106. Q: Business/Research Workload - [AI Training Dataset Structure] What is the primary structure of the AI training datasets? Large files(>1MB) / Small files (<1MB) / Sharded datasets (e.g., tar / WebDataset) If possible, please indicate the typical file size range.

A: Depends on workload. Language models typically range from tens of MB to hundreds of GB. Vision models range from hundreds of GB to tens of TB. For vision tasks, the data is usually stored in WebDataset format with individual files around

100MB.

107. Q: Business/Research Workload - [Checkpoint / Simulation Output Size] What is the typical or maximum size of training checkpoints or simulation output files?(TB or PB) And how frequently are checkpoints written?

A: While checkpoint size and frequency will vary based on research workload, estimate output files of 30 - 40 GB up to 1 TB with checkpoints written roughly every 30 minutes.

108. Q: Business/Research Workload - [LLM training workloads] What sequence length is typically expected (e.g., 2k / 4k / 8k / longer)?

A: Minimum 2k but for reasoning LLMs or multi-turn agents, sequence length of 8k is a minimum and 16k and 32k are very common.

109. Q: Technical/Infrastructure - [Workload Distribution] What is the approximate expected distribution of different workloads across the platform (percentage estimate)? AI / ML training; Robotics / autonomy training; HPC simulation (e.g., CFD, hypersonic research);

LLM development.

A: A mix of workloads can be expected from scientific computation to LLM development. The system should be flexible enough to favor one workload today, another tomorrow, or a combination of.

110. Q: Technical/Infrastructure - [Future GPU Expansion] Are there plans to expand the GPU cluster in the future? If so, what approximate scale is anticipated?

A: Future expansion is a possibility. Plan on at least 30%.

111. Q: Technical/Infrastructure - [Object Storage Integration] Would integration with a private object storage system be acceptable for dataset management and archival purposes?

112. Q: Are there preferences on node to switch port mappings?

113. Q: Are there any preferences on node naming and switch naming?

114. Q: Are there preferences on network cable colors, PDU, and power cord colors?

A: No preference on color as long as it is maroon.

115. Q: Is there a preference for front or rear I/O implementation? If not, the default standard is rear I/O.

A: Vendor preference.

116. Q: Storage Requirements - What is the anticipated volume of data that will be generated and processed by our generative AI models?

A: Anticipated volume is workload and user dependent.

117. Q: Storage Requirements - Are there any data management or data governance considerations that need to be addressed in the storage architecture?

A: Provide a management framework to help us ensure data is stored where it is supposed to be, project-specific isolation, automated tiering, and policy-driven retention, classification, and deletion.

Also see answer to question #61.

118. Q: Regulatory Requirements - Are there audit trails or logging mechanisms in place to track and trace data access and usage for compliance and security purposes?

A: Vendor should recommend options for enabling this capability for the cluster.

119. Q: Has TEES already secured inventory of B200, or is it the expectation of TEES for the awarded responder to allocate with NVIDIA?

A: TEES has not secured GPU inventory with any vendor.

120. Q: Section 2.1.2 (page 9) - Is there a specific reason for the requirement for a 100GbE

OOB Management Network? Is there a specific concern it addresses?

A: The 100GbE specification is intended to facilitate burst headroom for rapid cluster re-provisioning to minimize downtime between research projects and some management, such as collecting telemetry and system logs without impacting the primary compute fabric. However, open to alternative designs (E.g. 25GbE) provided vendor can demonstrate that the proposed management fabric can support rapid cluster reconfiguration.

121. Q: Section 1.3 - Under what GPU concurrency assumptions should aggregate storage throughput be validated (e.g., full cluster concurrency or representative workload concurrency)?

A: Representative workload concurrency.

122. Q: Storage Requirements (Section 2.1.3) - Should the proposed design assume a defined sustained storage bandwidth per active GPU under concurrency, and if so, what sustained per-GPU bandwidth expectation (e.g., GB/s per GPU) should guide system sizing?

A: Open to vendor recommendations. For more, see answer in question #1.

123. Q: Storage Requirements (Section 2.1.3) - Are there expected checkpoint size and frequency characteristics that should inform aggregate write bandwidth modeling?

A: Expect large checkpoints at moderate to low frequency. For example, a project may have ~25 burst writes of ~40 GB every 30 minutes.

124. Q: Storage Requirements (Section 2.1.3) - Are expected workloads anticipated to include metadata-intensive patterns (e.g., large-scale small-file ingestion, directory fan-out, high-frequency file creation/deletion) requiring metadata services to scale independently from bulk data throughput?

125. Q: Storage Requirements (Section 2.1.3) - What usable capacity target should guide sizing of the parallel storage tier at initial deployment, and what capacity planning horizon and dataset growth assumptions should be used for sizing?

126. Q: Scope of Work (Section 1.3) - Given the RFP’s policy-driven multi-tenant architecture leveraging ABAC and network micro-segmentation, please confirm whether storage-layer isolation is expected to extend beyond identity and network-level controls, or if logical access controls within a shared parallel filesystem are sufficient.

A: As a part of a larger multi-tenancy strategy, micro-segmentation should exist at all layers, identity, network-level and storage.

127. Q: Storage Requirements (Section 2.1.3) - The RFP requires the solution to be capable of saturating the Ethernet storage fabric; for performance validation, should compliance be measured at the network layer (sustained near line-rate utilization of north-south storage links) or at the application layer (delivery of required aggregate storage throughput under defined GPU concurrency assumptions), and should this be demonstrated under a traffic model assuming simultaneous peak east-west collective communication and north-south storage traffic, or with these evaluated independently?

A: Open to vendor recommendations.

128. Q: Storage Requirements (Section 2.1.3) - Is cluster-specific scratch intended to function as a shared operational data tier accessible across nodes, distinct from node-local ephemeral storage?

129. Q: Storage Requirements (Section 2.1.3) - Are model artifacts and completed training outputs expected to transition to enterprise storage as part of defined governance processes, or remain resident within the parallel cluster tier for extended operational periods?

A: Primarily, completed training outputs are expected to transition to enterprise storage. We cannot, however, rule out the possibility of some workloads remaining resident for extended periods. Especially for model validation and testing.

130. Q: Storage Requirements (Section 2.1.3) - Beyond artifact retention, is the enterprise storage tier expected to participate directly in active research workflows (e.g., serving datasets back into the cluster), or operate strictly as a governance and retention domain?

A: Governance and retention.

131. Q: Storage Requirements (Section 2.1.3) - What initial usable capacity and projected annual growth rate should guide sizing of the enterprise storage tier, and should it accommodate full offload of parallel-tier capacity or selective retention of governed artifacts only?

A: See answer to question #1. Projected annual growth rate is being evaluated, however, the sizing should accommodate selective retention of governed artifacts.

132. Q: Storage Requirements (Section 2.1.3) - Should archive-class storage support tiering to public cloud object storage with recall into the enterprise namespace, or function as a standalone archival repository?

A: Either option is acceptable.

133. Q: usable scratch capacity on day 1 or any growth projections?

134. Q: Sustained/peak throughput targets for scratch reads and writes?

A: Storage solution must be capable of saturating the 400 Gb/s ethernet storage fabric and provide low-latency access to all GPUs.

135. Q: Top workloads on the scratch?

A: Not defined at this time. Anticipate a mixture of workloads ranging from scientific computation to LLM development.

136. Q: Access patterns (seq/random/LOSF)?

A: This will vary based on research project.

137. Q: Scope of Work (Section 1.3) - For CUI-level workloads operating within shared infrastructure, is the compliance boundary defined at the overall system level (cluster plus enterprise ecosystem), or must each storage tier independently satisfy applicable NIST SP 800-171 / CMMC Level 2 controls?

A: See answer in question #1 for context. Cluster storage must satisfy applicable NIST SP 800-171 / CMMC Level 2 controls. Existing enterprise storage for CUI already meets these requirements.

138. Q: Total file count (or average file size)?

A: Not defined at this time.

139. Q: Is there a Single namespace requirement?

A: Yes, as long as this is paired with strong, enforceable isolation controls.

140. Q: Any restrictions on linux kernels?

A: For consistency with other workload environments and established enterprise agreements, supported editions of RHEL and Ubuntu would be preferred.

141. Q: Any Datasets from scratch tier to enterprise storage?

A: Enterprise storage will primarily be for governance and retention. Data will need to move between Enterprise and Cluster storage and vise versa.

142. Q: For general storage (file repo) - capacity day 1, growth and performance requirements for hot and cold datasets ?

143.