An Abdominal CT Expert and a 32B Medical AI in One DGX Spark: MedPortal



A contrast-enhanced abdominal CT can contain hundreds of slices, dozens of organs, and a long list of potential findings that must not be missed. That is the everyday reality of radiology. Now imagine reviewing that information on one desktop system, while patient data never leaves the premises.

That is the idea behind MedPortal, built at OpenZeka. It unifies two large medical AI models in one web interface, both running on a single NVIDIA DGX Spark. This article looks at the system, its output on a live case, and the reasons DGX Spark is a strong fit for this workflow.

Completed RADAR analysis: CT slice viewer on the left and thresholded findings on the right

Live-system screenshot: RADAR’s official demo case (AC423ccbe) was run end to end. At slice 184/368 and a 0.50 threshold, three findings were surfaced: cardiomegaly 0.83, calcification 0.70, and atherosclerosis 0.58.

Two demanding models, one system

MedPortal keeps two high-capacity models available on the same DGX Spark:

  • RADAR provides expert-level analysis for contrast-enhanced abdominal CT. Upload a .nii.gz volume and it returns a score for each of 146 findings, along with an interactive slice viewer and CSV export. Published in Science (2026), the model was trained on more than 400,000 contrast-enhanced abdominal CT examinations and 15 million anatomy-aware image-text pairs.
  • ClinFusion-32B is a multimodal medical language model with strong visual capabilities, based on Qwen3-VL-32B. It accepts natural-language questions, 2D images, and 3D CT/MRI volumes, then preserves conversational context while the case is discussed.

Running both together is the key challenge. RADAR uses a 3D visual encoder, while ClinFusion carries roughly 180 GB of weights across its 32B base model, DINOv2 and CLIP-ConvNeXt visual encoders, and 3D positional encoding. For responsive interaction, those weights need to remain available in memory.

Live test: 146 scored findings in seconds

For a practical test, we loaded RADAR’s official demo case, AC423ccbe: a 368-slice contrast-enhanced abdominal CT. Uploading, viewing, and analysis all took place directly in the live portal.

Finding Organ Score
Cardiomegaly HEART 0.833
Calcification AORTA 0.697
Atherosclerosis AORTA 0.578

Reducing the threshold to 0.30 expanded the table to eight findings, including lipoma (0.41), rib fracture (0.39), aortic dissection (0.38), pericardial effusion (0.36), and mesenteric panniculitis (0.32). Once the model is loaded, analysis completes in the 10–30 second range. In this run, the table populated in seconds rather than minutes.

Findings table at a 0.30 threshold, showing eight findings

The same case at a 0.30 threshold for a more sensitive review. Slice navigation and soft-tissue, lung, and bone window controls appear at lower left.

The interface brings together tools that support a faster radiology workflow: organ-level grouping, finding-name search, quick chips for the highest scores, soft-tissue/lung/bone window presets, keyboard navigation (←/→ for one slice; PgUp/PgDn for ±10), mouse-wheel zoom, and CSV export for every score.

Portal on first load: upload area, slice viewer, and findings panel

Empty state: drag-and-drop upload, the viewer, and the 146-finding panel.

The image used in the upload demonstration is itself an abdominal CT collage:

Sample abdominal CT image uploaded for the demonstration

 

Discussing a case with ClinFusion

The second tab is designed for natural-language case discussion. Attach a 2D image (.jpg/.png) or a complete 3D volume (.nii.gz), then ask, for example, “What are the key findings here?” Attachments appear in the side panel, are marked “✓ sent,” and can be reused in follow-up questions. The conversation retains its context.

With a 3D volume, ClinFusion considers representative slices alongside the volume data. It is not simply an image classifier behind a chat box; it is a case-discussion assistant that takes volumetric information into account.

ClinFusion tab: attached CT image and a drafted question

The sample image is attached and the question is ready to send.

For the sample image, we asked: “Evaluate this contrast-enhanced abdominal CT image: which organs are visible and what are the key findings? Please give a short clinical assessment.” The model produced the following response live on the DGX Spark:

The CT scan shows the liver, spleen, kidneys, and portions of the gastrointestinal tract. The liver appears homogeneous with no focal lesions, and the spleen is normal in size and density. The kidneys are symmetrically positioned with no signs of hydronephrosis or masses. The gastrointestinal tract shows no significant distension or obstruction. The vertebral column and pelvic bones appear intact without fractures or lesions. Overall, the scan does not show any acute abnormalities.

Response shown in the portal: question and full model output

The portal renders the model response with the question and attachment context in view.

Why DGX Spark?

The system was not designed merely as a workload to place on a server. Its architecture reflects the constraints of the clinical environment.

Data stays on site. CT volumes are patient data, and sending them to the cloud raises both compliance and trust concerns. DGX Spark can sit on a desk; the portal is available on the local network and the images remain on the machine. This also removes network latency, recurring cloud costs, and the need for an additional data-processing agreement.

Unified memory fits the workload. The 32B model’s approximately 75 GB resident footprint, RADAR’s working set, and the operating system can coexist on one machine. The weights are loaded once and remain available, without CPU–GPU copy overhead or layer-by-layer disk offloading.

One GPU queue coordinates two capabilities. MedPortal serializes both models through a single GPU queue. Jobs do not interfere with each other, and the status bar indicates what is waiting. The same system supports radiological pre-review and case discussion.

The form factor belongs near the workflow. This is a quiet desktop system that can sit in a clinic, laboratory, or beside a radiology workstation—not a noisy rack in a server room. After startup with ./run.sh, use ./status.sh for health checks, ./stop.sh to release memory, and ./scripts/smoke.sh for an end-to-end check.

AArch64 is ready in practice. The project resolves the GB10-specific issues we encountered: the aarch64 FlashAttention wheel, selective dependency installation, and conda environment paths. The installers in scripts/ can reduce setup on a new Spark from hours to minutes. The UI uses plain HTML/JS, with no build step or CDN dependency.

Architecture: MedPortal as an orchestration layer

MedPortal does not store model weights or perform inference itself. It coordinates the workloads:

Copy to Clipboard
  • Uploads are managed in one place, while 3D volumes are sliced on the backend for the viewer.
  • RADAR runs as a separate process; ClinFusion is a persistent HTTP worker that holds its model in memory.
  • Paths and ports are configurable through environment variables, so the same checkout can move to another Spark unchanged.
  • On the development side, 74 tests validate the backend, and smoke.sh returns “146 findings + SMOKE OK” end to end.

Setup

One system, three steps: Miniconda, three codebases (medportal + RADAR + ClinFusion), and two setup scripts.

Copy to Clipboard

The operational details are documented in the project: only dependencies used by the inference path are installed; unavailable aarch64 wheels are skipped; the first 32B-model load takes about 14 minutes and is visible in logs/worker.log; and the setup scripts can show their planned work with --dry-run first.

Limits and appropriate use

In medical AI, stating the limits clearly is essential:

  • Scores are not clinical diagnoses or standalone probabilities. A RADAR score such as 0.71 for Liver_Cirrhosis is a model output based on imaging evidence; it does not directly express the patient’s probability of cirrhosis. Clinical judgment and the radiology report remain decisive, and a low score does not rule out a finding.
  • RADAR is for research use only. Its upstream CC BY-NC-SA 4.0 license does not clear it for commercial or clinical deployment. Outputs may be unreliable outside its training distribution, particularly beyond contrast-enhanced abdominal CT.
  • One analysis runs at a time. Because the GPU is shared, jobs pass through a queue. That is a deliberate choice for batch-oriented workloads.
  • This system is not a cleared medical device; it is a research and decision-support demonstration.

Conclusion

MedPortal demonstrates more than two models running side by side. It shows what a single desktop system can now carry: a resident 32B multimodal medical model alongside expert-level abdominal CT analysis—a combination that recently would have implied a server rack.

NVIDIA DGX Spark makes that capability available beside the clinical workflow, without sending data off premises and with a single-command startup. The question “What might I be missing in this abdominal CT?” no longer has to be explored in the cloud; it can be explored in the box beside the radiology desk.