Do we need to make a copy in order to compute the centers in float? It's a bit weird but I guess it makes sense?
We could do sum on the ints and then divide to get float centers but that might be excessive?

Do we need to make a copy in order to compute the centers in float? It's a bit weird but I guess it makes sense?

That and the inertia I think.

We could do sum on the ints and then divide to get float centers but that might be excessive?

The larger problem is that a number of intermediary arrays are created in Kmeans/MinibatchKmeans with dtype=X.dtype (presumably to keep float32 / float64 unchanged),

$ rg "dtype=X.dtype" sklearn/cluster/k_means_.py
79:    centers = np.empty((n_clusters, n_features), dtype=X.dtype)
171:        return np.ones(n_samples, dtype=X.dtype)
331:        init = check_array(init, dtype=X.dtype.type, copy=True)
533:    distances = np.zeros(shape=(X.shape[0],), dtype=X.dtype)
670:        distances = np.zeros(shape=(0,), dtype=X.dtype)
751:        centers = np.array(init, dtype=X.dtype)
754:        centers = np.asarray(centers, dtype=X.dtype)
1499:            self.init = np.ascontiguousarray(self.init, dtype=X.dtype)
1516:            old_center_buffer = np.zeros(n_features, dtype=X.dtype)
1521:            old_center_buffer = np.zeros(0, dtype=X.dtype)
1523:        distances = np.zeros(self.batch_size, dtype=X.dtype)
1673:            self.init = np.ascontiguousarray(self.init, dtype=X.dtype)
1702:            distances = np.zeros(X.shape[0], dtype=X.dtype)
1706:                         np.zeros(0, dtype=X.dtype), 0,

sure in each of those we could do dtype conversions as necessary, depending on X.dtype but it would add complexity for, I think, not that common use case. A have not benchmarked it, but my guess is that a copy to float would be negligible with respect to the total run time, and that's what MinibatchKMeans.fit does already.

ok, seems reasonable.