FastSurfer runtime is <25 minutes on 7900X

[julii-a]

General Support Request

Description

I am trying to run the full FastSurfer pipeline (segmentation + surface) via the official Docker image, without using --seg_only or --surf_only.

On my machine, several subjects finish in about 20 minutes in total (around 2–3 minutes for segmentation and about 17–19 minutes for the surface pipeline including thickness and stats). According to the documentation, I would have expected runtimes closer to approximately 60-90 minutes, so I would like to confirm whether this fast runtime is within the expected range for my setup or if it might indicate that some steps are being skipped.

Steps that lead to your Issue

I am following the standard Docker usage described in the documentation (Quickstart and examples). My command for a representative subject is:

docker run --gpus all \
  --user root \
  -e FS_LICENSE=/fs_license/license.txt \
  -v /path/to/fs_license.txt:/fs_license/license.txt \
  -v /path/to/data:/data \
  -v /path/to/output:/output \
  --rm \
  deepmi/fastsurfer:latest \
  --t1 /data/sub-y003_ses-2/mri/orig_nu.mgz \
  --sid sub-y003_ses-2 \
  --sd /output \
  --3T \
  --tal_reg \
  --threads 10 \
  --allow_root

I am not using --seg_only or --surf_only, so my understanding is that this should run the full FastSurfer pipeline (segmentation + surface) and produce FreeSurfer‑conform outputs.

From the log files, segmentation takes about 2–3 minutes and the full surface pipeline (including thickness and cortical stats) about 17–19 minutes. All expected outputs appear to be present (aseg, aparc.DKTatlas+aseg.deep, white/pial surfaces, sphere.reg, thickness maps, and stats files), and the logs end with “finished without error”.

My expectations were that the full pipeline would take substantially longer (around 1–1.5 hours) based on the documentation and other user reports, so I would like to clarify whether these runtimes are reasonable for my hardware and data.

Questions:

1. Is a total runtime of roughly 20 minutes (segmentation + full surface) for 1 mm T1 data on this kind of hardware within the expected range, or is this unusually fast?

2. Does this runtime suggest that any steps might be skipped implicitly, or can it be considered a normal but very fast case given good hardware and clean data?

3. Do you recommend any specific strategy for choosing --threads (e.g. relative to physical cores) to balance speed and numerical stability of surface results?

Log Files / Screenshots

- log files: recon-all-status

status file for recon-all
Tue Feb  3 12:42:17 UTC 2026
#@# Merge ASeg Tue Feb  3 12:42:17 UTC 2026
#@# Intensity Normalization2 Tue Feb  3 12:42:17 UTC 2026
#@# Mask BFS Tue Feb  3 12:43:16 UTC 2026
#@# WM Segmentation Tue Feb  3 12:43:16 UTC 2026
#@# Fill Tue Feb  3 12:44:13 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:44:42 UTC 2026


#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:44:49 UTC 2026
#@# Inflation1 lh Tue Feb  3 12:44:49 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:44:49 UTC 2026
#@# Inflation1 rh Tue Feb  3 12:44:49 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:44:56 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:44:56 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:45:04 UTC 2026
#@# Fix Topology lh Tue Feb  3 12:45:04 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:45:05 UTC 2026
#@# Fix Topology rh Tue Feb  3 12:45:05 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:45:57 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:45:58 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:46:20 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:46:22 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:47:19 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:47:21 UTC 2026
#@# Smooth2 rh Tue Feb  3 12:47:33 UTC 2026
#@# Inflation2 rh Tue Feb  3 12:47:34 UTC 2026
#@# Curv .H and .K rh Tue Feb  3 12:47:40 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:47:46 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:47:48 UTC 2026
#@# Smooth2 lh Tue Feb  3 12:48:00 UTC 2026
#@# Inflation2 lh Tue Feb  3 12:48:01 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:48:05 UTC 2026
#@# Curv .H and .K lh Tue Feb  3 12:48:08 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:48:15 UTC 2026
#@# Sphere rh Tue Feb  3 12:48:15 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:48:32 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:48:42 UTC 2026
#@# Sphere lh Tue Feb  3 12:48:42 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:50:17 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:50:20 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:51:52 UTC 2026
#@# Jacobian white lh Tue Feb  3 12:51:52 UTC 2026
#@# AvgCurv lh Tue Feb  3 12:51:52 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:51:53 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:52:08 UTC 2026
#@# Jacobian white rh Tue Feb  3 12:52:08 UTC 2026
#@# AvgCurv rh Tue Feb  3 12:52:09 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:52:09 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:54:46 UTC 2026
#@# white curv lh Tue Feb  3 12:54:46 UTC 2026
#@# white area lh Tue Feb  3 12:54:46 UTC 2026
#@# pial curv lh Tue Feb  3 12:54:46 UTC 2026
#@# pial area lh Tue Feb  3 12:54:46 UTC 2026
#@# thickness lh Tue Feb  3 12:54:46 UTC 2026
#@# area and vertex vol lh Tue Feb  3 12:54:46 UTC 2026
#@# Curvature Stats lh Tue Feb  3 12:54:47 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:54:49 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:54:51 UTC 2026
#@# white curv rh Tue Feb  3 12:54:51 UTC 2026
#@# white area rh Tue Feb  3 12:54:51 UTC 2026
#@# pial curv rh Tue Feb  3 12:54:51 UTC 2026
#@# pial area rh Tue Feb  3 12:54:52 UTC 2026
#@# thickness rh Tue Feb  3 12:54:52 UTC 2026
#@# area and vertex vol rh Tue Feb  3 12:54:52 UTC 2026
#@# Curvature Stats rh Tue Feb  3 12:54:53 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:54:54 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:54:55 UTC 2026
#@# white curv lh Tue Feb  3 12:54:55 UTC 2026
#@# white area lh Tue Feb  3 12:54:55 UTC 2026
#@# pial curv lh Tue Feb  3 12:54:55 UTC 2026
#@# pial area lh Tue Feb  3 12:54:55 UTC 2026
#@# thickness lh Tue Feb  3 12:54:55 UTC 2026
#@# area and vertex vol lh Tue Feb  3 12:54:55 UTC 2026
#@# white curv rh Tue Feb  3 12:54:55 UTC 2026
#@# white area rh Tue Feb  3 12:54:56 UTC 2026
#@# pial curv rh Tue Feb  3 12:54:56 UTC 2026
#@# pial area rh Tue Feb  3 12:54:56 UTC 2026
#@# thickness rh Tue Feb  3 12:54:56 UTC 2026
#@# area and vertex vol rh Tue Feb  3 12:54:56 UTC 2026
#@# Cortical ribbon mask Tue Feb  3 12:54:56 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:56:35 UTC 2026

#New# invocation of recon-all 

status file for recon-all
Tue Feb  3 12:56:54 UTC 2026
#@# white curv lh Tue Feb  3 12:56:54 UTC 2026
#@# white area lh Tue Feb  3 12:56:54 UTC 2026
#@# pial curv lh Tue Feb  3 12:56:54 UTC 2026
#@# pial area lh Tue Feb  3 12:56:55 UTC 2026
#@# thickness lh Tue Feb  3 12:56:55 UTC 2026
#@# area and vertex vol lh Tue Feb  3 12:56:55 UTC 2026
#@# white curv rh Tue Feb  3 12:56:55 UTC 2026
#@# white area rh Tue Feb  3 12:56:55 UTC 2026
#@# pial curv rh Tue Feb  3 12:56:55 UTC 2026
#@# pial area rh Tue Feb  3 12:56:55 UTC 2026
#@# thickness rh Tue Feb  3 12:56:55 UTC 2026
#@# area and vertex vol rh Tue Feb  3 12:56:55 UTC 2026
#@# Relabel Hypointensities Tue Feb  3 12:56:55 UTC 2026
#@# APas-to-ASeg Tue Feb  3 12:57:01 UTC 2026
recon-all -s sub-y003_ses-2 finished without error at Tue Feb  3 12:57:04 UTC 2026

Environment

• FastSurfer Verions: 2.4.2
• Installation type: Docker
• OS: Windows (WSL2, Ubuntu 22.04)
• CPU: AMD Ryzen 9 7900X (12 cores)
• RAM: 32 GB
• GPU: NVIDIA GeForce RTX 4060

Additional Context

I observe similar runtimes (~20 minutes total) for several subjects, not just a single outlier.

I am not experiencing errors; I only want to confirm that such fast runtimes for the full pipeline are expected/acceptable and do not indicate a misconfiguration on my side.

Thank you very much for your time and for any clarification.

[dkuegler]

We have never tested on your hardware, if you enable enough threads and your CPU is clocked well and you process onto an SSD, this might be valid...

It is faster than expected though, even a full segmentation run only taking 2-3 minutes is fast as well.

[julii-a]

Is there a recommended way to confirm that all pipeline stages are being executed correctly and that none are being skipped or failing?

[dkuegler]

Generally, a look at <subject_dir>/scripts/recon-surf.log and <subject_dir>/scripts/deep-seg.log is sufficient.

In <subject_dir>/scripts/recon-surf.log you are looking at the last line: it should say

recon-surf.sh <sid> finished without error at <date and time>

In <subject_dir>/scripts/deep-seg-log you should search for ERROR and WARNING.
If they cannot be found, all should be fine. If WARNING is found, this may be fine, you would have to investigate the type of Warning.

Finally, you can check if all files that you expect/need exist.

[m-reuter]

FastSurfer
^^^^^
:-)

[julii-a]

I would like to ask whether the following log output indicates any problem with the surface reconstruction.
This is the execution performed with '--surf_only' and '--edits'

According to the log, recon-surf.sh finished successfully without error. However, an error occurs afterward when running extract_recon_surf_time_info.py, resulting in a KeyError: 'DONE'.

Could you please confirm whether this error affects the recon-surf results themselves, or if it is limited to the post-hoc runtime summary script and can be safely ignored?

For reference, the relevant log output is shown below.

@#@FSTIME 2026:02:04:02:32:26 recon_surf//fs_balabels.py N 4 e 11.94 S 1.69 U 11.91 P 113% M 470372 F 2 R 557207 W 0 c 102 w 36975 I 0 O 0 L 3.20 4.78 4.90 
@#@FSLOADPOST 2026:02:04:02:32:38 recon_surf//fs_balabels.py N 4 2.71 4.59 4.84 ================= DONE ========================================================= 
Started at Wed Feb 4 02:10:42 UTC 2026 
Ended at Wed Feb 4 02:32:38 UTC 2026 
#@#%# recon-surf-run-time-hours 0.000 recon-surf.sh sub-y004_ses-2 finished without error at Wed Feb 4 02:32:38 UTC 2026 python3.10 -s /fastsurfer/recon_surf/utils/extract_recon_surf_time_info.py -i /output/sub-y004_ses-2/scripts/recon-surf.log -o /output/sub-y004_ses-2/scripts/recon-surf_times.yaml 

@#@FSLOADPRE 2026:02:04:02:32:38 recon_surf/utils/extract_recon_surf_time_info.py N 4 2.71 4.59 4.84 
[INFO] Parsing file for recon_surf time information: /output/sub-y004_ses-2/scripts/recon-surf.log 

Traceback (most recent call last): File "/fastsurfer/recon_surf/utils/extract_recon_surf_time_info.py", line 245, in <module> recon_surf_commands[-1][current_recon_surf_stage_name].append(entry_dict) KeyError: 'DONE' 
Command exited with non-zero status 1 @#@FSTIME 2026:02:04:02:32:38 recon_surf/utils/extract_recon_surf_time_info.py N 4 e 0.05 S 0.02 U 0.02 P 85% M 16320 F 0 R 2704 W 0 c 4 w 89 I 0 O 0 L 2.71 4.59 4.84 
@#@FSLOADPOST 2026:02:04:02:32:38 recon_surf/utils/extract_recon_surf_time_info.py N 4 2.71 4.59 4.84

[m-reuter]

It just means that some log message output has probably changed and therefore we cannot extract the timing information from the log file afterwards. We should check this and fix it, but it does not indicate that anything went wrong with the processing.

[dkuegler]

Can you share the full recon-surf.log file for further analysis?
Only the FastSurfer team can read this issue dropbox https://nextcloud.dzne.de/index.php/s/Z2qtHW8c7p3NSJ5

[julii-a]

Can you share the full recon-surf.log file for further analysis? Only the FastSurfer team can read this issue dropbox https://nextcloud.dzne.de/index.php/s/Z2qtHW8c7p3NSJ5

I’ve uploaded the file. Please let me know if you can’t see it or if there are any issues.

[dkuegler]

I reviewed the logfile to make sure all is fine, but there are no errors in it and it seems to go through all the relevant steps.
Two things to note:

1. you are running FastSurfer with 10 threads (--threads 10) compared to --threads 2 for our reference runs (speedup is not linear, but there is a speedup) -- so it is good to see, that our parallelization efforts are bearing fruits.
2. you are using a 7900X CPU, which is considerably faster than the CPUs in our reference runs.